Cobol - Re: Cobol language dictionary page -- assignment complete?

Author

Re: Cobol language dictionary page -- assignment complete?

Christine Frayda

2005-10-18, 6:55 pm

<docdwarf@panix.com> wrote in message news:dj1h87$aih$1@reader2.panix.com...
> In article <qiX4f.62491$K91.29552@twister.nyroc.rr.com>,
> Christine Frayda <cfrayda@rochester.rr.com> wrote:
>
> [snip]
>
>
> It's usually much faster if someone else does your homework for you, sure!
>
> DD

And thanks to the group for the help with my homework! (I don't get paid
for this, afterall.)

Please take all of your sharp wits to the web page to critique our work. --
Constructive criticism will be accepted most quickly. :)
http://en.wikibooks.org/wiki/ Softw...> tionary:COBOL

It is a wiki, so you are welcome to fix problems in place too,
Chris

Arnold Trembley

2005-10-19, 3:55 am

Christine Frayda wrote:
> <docdwarf@panix.com> wrote in message news:dj1h87$aih$1@reader2.panix.com...
>
>
>
> And thanks to the group for the help with my homework! (I don't get paid
> for this, afterall.)
>
> Please take all of your sharp wits to the web page to critique our work. --
> Constructive criticism will be accepted most quickly. :)
> http://en.wikibooks.org/wiki/ Softw...> tionary:COBOL
>
> It is a wiki, so you are welcome to fix problems in place too,
> Chris

HA! Most of the items on that page come from me, in a private email
to Christine Frayda. Since I know next to nothing about
object-oriented programming, or C++ for that matter, and my point of
view might be rather limited, it would probably be a very good thing
for some other COBOL programmers to jump in and correct my flippant
comments. And possibly correct my examples, which were written very
hastily without any kind of syntax checking.

We wouldn't want our favorite programming language to be
misrepresented in the Wiki world, would we?

With kindest regards,

--
http://arnold.trembley.home.att.net/

James J. Gavan

2005-10-25, 3:55 am

Arnold Trembley wrote:
>
> HA! Most of the items on that page come from me, in a private email to
> Christine Frayda. Since I know next to nothing about object-oriented
> programming, or C++ for that matter, and my point of view might be
> rather limited, it would probably be a very good thing for some other
> COBOL programmers to jump in and correct my flippant comments. And
> possibly correct my examples, which were written very hastily without
> any kind of syntax checking.
>
> We wouldn't want our favorite programming language to be misrepresented
> in the Wiki world, would we?
>

Well Arnold, a valiant initial attempt at OO - BUT........, there's just
so damn much to cover. I've never checked, perhaps Bill or Chuck have -
but I doubt that OO has added more than 20 - 30 RESERVED WORDS to COBOL,
including extensions like :-

Procedural - set ContinueProgram to true

OO - set ThisNewObject to thisOldObject *> you can't MOVE objects

In my judgment, OO COBOL is more about a Conceptual approach, using a
combination of the OO RESERVED WORDS above. Not that it's put forward as
an idea, but I'm a strong advocate of REUSE associated with
polymorphism. (E.g. work out the general logic to retrieve different
elements in a collection, and with minor twiddling, the methods can be
applied to any other collection, be they collections of customers,
fruits, cheeses, car parts or whatever). There I go - both F/J and M/F
have collections, which as yet are not part of the J4 OO Standard !

If you think on it - why bother with a 'newie' like OO unless it's going
to give you some program development advantages. On the minus side -
design-wise you have got to figure out your support classes in advance,
which takes time when you are new to the topic - but when you get there
you quickly avoid the onerous task of having to think how to handle,
files, their file-status errors, SQL Tables and their SQLSTATE/ERRORs,
GUIs the Web, or whatever - you have these as a set of 'canned' or
'template' classes which then draw as necessary on utility classes
provided by the COBOL vendor.

My 'utility' classes never go wrong, but they can hiccup because of the
messages, (parameters) I send to them - and that's no different to
Procedural:-

CALL Program2 using a, c, d

when Program2 is anticipating receiving a,b,c,d
and returning e (not mentioned above)

No. Be much braver if I sat down and tried my hand at writing a book on
OO COBOL ! Then like Thane, once a month I could take my wife out to a
burger-joint on the royalties :-)

Jimmy

Howard Brazee

2005-10-25, 6:55 pm

On Tue, 25 Oct 2005 03:38:18 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:

>No. Be much braver if I sat down and tried my hand at writing a book on
>OO COBOL ! Then like Thane, once a month I could take my wife out to a
>burger-joint on the royalties :-)

I didn't know Thane knew your wife.

Chuck Stevens

2005-10-25, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:KMh7f.287612$oW2.107047@pd7tw1no...

> Well Arnold, a valiant initial attempt at OO - BUT........, there's just
> so damn much to cover. I've never checked, perhaps Bill or Chuck have -
> but I doubt that OO has added more than 20 - 30 RESERVED WORDS to COBOL,
> including extensions like :- ...

I just went through the reserved word lists for the '85 and '02 standards.

The '02 standard *adds* ADDRESS, ALIGNED, ALLOCATE, ANYCASE, AS, B-AND,
B-NOT, B-OR, B-XOR, BASED, BINARY-CHAR, BINARY-DOUBLE, BINARY-LONG,
BINARY-SHORT, BIT, BOOLEAN, CLASS-ID, COL, COLS, COLUMNS,
CONDITION,CONSTANT, CRT, CURSOR, DATA-POINTER, DEFAULT, EC, END-ACCEPT,
END-DISPLAY, EO, EXCEPTION-OBJECT, FACTORY, FLOAT-EXTENDED, FLOAT-LONG,
FLOAT-SHORT, FORMAT, FREE, FUNCTION, FUNCTION-ID, GET, GOBACK, GROUP-USAGE,
INHERITS, INTERFACE, INTERFACE-ID, INVOKE, LOCAL-STORAGE, LOCALE, METHOD,
METHOD-ID, MINUS, NATIONAL, NATIONAL-EDITED, NESTED, NULL, OBJECT,
OBJECT-REFERENCE, OPTIONS, OVERRIDE, PRESENT, PROGRAM-POINTER, PROPERTY,
PROTOTYPE, RAISE, RAISING, RESUME, RETRY, RETURNING, SCREEN, SELF, SHARING,
SOURCES, SUPER, SYSTEM-DEFAULT, TYPEDEF, UNIVERSAL, UNLOCK,
USER-DEFAULT, VAL-STATUS, VALID, VALIDATE, VALIDATE-STATUS, the operators
"&" (concatenation) and "::" (method invocation), the floating comment
indicator "*>", and the compiler directive indicator ">>".

By my count that's a total of 87 new entries in the reserved word list in
the '02 standard.

The '02 standard *drops* ALTER, AUTHOR, CLOCK-UNITS, COBOL (!),
DATE-COMPILED, DATE-WRITTEN, DEBUG-CONTENTS, DEBUG-ITEM, DEBUG-LINE,
DEBUG-NAME, DEBUG-SUB-1, DEBUG-SUB-2, DEBUG-SUB-3, ENTER, EVERY,
INSTALLATION, LABEL, MEMORY, MODULES, MULTIPLE, POSITION, PROCEDURES,
PROCEED, REFERENCES, RERUN, SECURITY, SEGMENT-LIMIT, TAPE, and WORDS for a
total of 29 entries that have been deleted from the reserved word list as it
was in the '85 standard.

I leave it as an exercize for the reader to figure out which of the new
reserved words are properly characterized as directly supporting OO.

> Procedural - set ContinueProgram to true
>
> OO - set ThisNewObject to thisOldObject *> you can't MOVE objects

Ah, but SET is hardly a new reserved word.

<<There I go - both F/J and M/F have collections, which as yet are not part
of the J4 OO Standard !>>

It is expected that the Collection Class Library proposal (currently WDTR
24717; the most recent update is J4/05-0214, available on
www.cobolportal.com/j4/), will, after a few further minor editorial tweaks,
be submitted as a DTR for international ballot Real Soon Now, and if the
national standards bodies agree, it will apply to the '02 standard.

WG4 has also requested that this TR along with the also-still-being-refined
Native COBOL Syntax for XML processing TR are to be "folded into" the draft
for the 2008 revision to the standard when they've passed their DTR process.
The Finalizer TR, which has already been approved, is also to be
incorporated into the draft.

-Chuck Stevens

James J. Gavan

2005-10-25, 6:55 pm

Chuck Stevens wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:KMh7f.287612$oW2.107047@pd7tw1no...
>
>
>
>
> I just went through the reserved word lists for the '85 and '02 standards.
>
> The '02 standard *adds* ADDRESS, ALIGNED, ALLOCATE, ANYCASE, AS, B-AND,
> B-NOT, B-OR, B-XOR, BASED, BINARY-CHAR, BINARY-DOUBLE, BINARY-LONG,
> BINARY-SHORT, BIT, BOOLEAN, CLASS-ID, COL, COLS, COLUMNS,
> CONDITION,CONSTANT, CRT, CURSOR, DATA-POINTER, DEFAULT, EC, END-ACCEPT,
> END-DISPLAY, EO, EXCEPTION-OBJECT, FACTORY, FLOAT-EXTENDED, FLOAT-LONG,
> FLOAT-SHORT, FORMAT, FREE, FUNCTION, FUNCTION-ID, GET, GOBACK, GROUP-USAGE,
> INHERITS, INTERFACE, INTERFACE-ID, INVOKE, LOCAL-STORAGE, LOCALE, METHOD,
> METHOD-ID, MINUS, NATIONAL, NATIONAL-EDITED, NESTED, NULL, OBJECT,
> OBJECT-REFERENCE, OPTIONS, OVERRIDE, PRESENT, PROGRAM-POINTER, PROPERTY,
> PROTOTYPE, RAISE, RAISING, RESUME, RETRY, RETURNING, SCREEN, SELF, SHARING,
> SOURCES, SUPER, SYSTEM-DEFAULT, TYPEDEF, UNIVERSAL, UNLOCK,
> USER-DEFAULT, VAL-STATUS, VALID, VALIDATE, VALIDATE-STATUS, the operators
> "&" (concatenation) and "::" (method invocation), the floating comment
> indicator "*>", and the compiler directive indicator ">>".
>
> By my count that's a total of 87 new entries in the reserved word list in
> the '02 standard.
>
> The '02 standard *drops* ALTER, AUTHOR, CLOCK-UNITS, COBOL (!),
> DATE-COMPILED, DATE-WRITTEN, DEBUG-CONTENTS, DEBUG-ITEM, DEBUG-LINE,
> DEBUG-NAME, DEBUG-SUB-1, DEBUG-SUB-2, DEBUG-SUB-3, ENTER, EVERY,
> INSTALLATION, LABEL, MEMORY, MODULES, MULTIPLE, POSITION, PROCEDURES,
> PROCEED, REFERENCES, RERUN, SECURITY, SEGMENT-LIMIT, TAPE, and WORDS for a
> total of 29 entries that have been deleted from the reserved word list as it
> was in the '85 standard.
>
> I leave it as an exercize for the reader to figure out which of the new
> reserved words are properly characterized as directly supporting OO.
>
>
>
>
> Ah, but SET is hardly a new reserved word.

No, wasn't suggesting it was - but pointing out it's now been 'extended'
to give the additional meaning in OO.

>
> <<There I go - both F/J and M/F have collections, which as yet are not part
> of the J4 OO Standard !>>
>
> It is expected that the Collection Class Library proposal (currently WDTR
> 24717; the most recent update is J4/05-0214, available on
> www.cobolportal.com/j4/), will, after a few further minor editorial tweaks,
> be submitted as a DTR for international ballot Real Soon Now, and if the
> national standards bodies agree, it will apply to the '02 standard.
>
> WG4 has also requested that this TR along with the also-still-being-refined
> Native COBOL Syntax for XML processing TR are to be "folded into" the draft
> for the 2008 revision to the standard when they've passed their DTR process.
> The Finalizer TR, which has already been approved, is also to be
> incorporated into the draft.
>
> -Chuck Stevens
>
>

Thanks for your efforts Chuck,

I guess the actual OO 'additives' are even less than I thought, taking
your list. I'm not sure of some, as they may also apply to Procedural,
but the following look like, and most are, definitely OO :-

AS, CLASS-ID, EO, EXCEPTION-OBJECT, FACTORY, INHERITS, INTERFACE,
INTERFACE-ID, INVOKE, METHOD, METHOD-ID, OBJECT (this also has a
Procedural connotation doesn't it ?), OBJECT-REFERENCE, OVERRIDE,
PROPERTY, SELF, SUPER and the *ugly* "::" (method invocation). A
possible 'maybe' without checking - BASED

Above is even smaller than I thought - 19 by my reckoning. Tends to
support my comment, it's not in the syntax, but how you 'join' the above
together.

Jimmy, Calgary AB

John Culleton

2005-10-26, 7:55 am

Christine Frayda wrote:

>
> <docdwarf@panix.com> wrote in message
> news:dj1h87$aih$1@reader2.panix.com...
>
> And thanks to the group for the help with my homework! (I don't get paid
> for this, afterall.)
>
> Please take all of your sharp wits to the web page to critique our work.
> -- Constructive criticism will be accepted most quickly. :)
>
http://en.wikibooks.org/wiki/ Softw...> tionary:COBOL

At a glance the wiki seems to concentrate on the (very interesting) trees
without showing a map of the forest. I would put the following up front:
----------------------------------
COBOL is a computer programming language whose layout and statements were
intended to resemble those of a written business procedure or a military
order. Hence it is divided hierarchically into DIVISIONs, SECTIONs, named
paragraphs, and sentence-like statements, each ending in a period. Although
recent versions have tended to stray from this original model the format
persists. Here is a skeleton of the structure of a typical COBOL program:
IDENTIFICATION DIVISION.
PROGRAM-ID. MYPROGRAM

(etc.)
-------------------------------------
I'll submit my own skeleton program in a separate posting, with specific
identifiers fictionalized of course.

COBOL doesn't do well when we try to put it in a FORTRAN or C++ context. It
isn't one of those.

But in general we should try to be helpful, even to engineers ;,).

--
John Culleton
Able Indexers and Typesetters

John Culleton

2005-10-26, 6:55 pm

Christine Frayda wrote:
[color=darkred]
>
> <docdwarf@panix.com> wrote in message
> news:dj1h87$aih$1@reader2.panix.com...

I haven't used it much recently but I was active in the language from about
1968 to about 1990 or so.

Here is my skeleton program:
-----------------------------
000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. TEMPLATE.
000030 AUTHOR. AUTHOR NAME.
000040 INSTALLATION. COMPANY NAME.
000045 Company address
000050*REMARKS.
000060* THIS IS A TEMPLATE FOR OPEN COBOL AND HTCOBOL.
000070 ENVIRONMENT DIVISION.
000080
000090 CONFIGURATION SECTION.
000100 SOURCE-COMPUTER.
000110 Linux.
000120 OBJECT-COMPUTER.
000230 Linux.
000140
000150 INPUT-OUTPUT SECTION.
000160 FILE-CONTROL.
000170 SELECT PRINTFILE ASSIGN TO PRINTER.
000180 DATA DIVISION.
000190
000200 FILE SECTION.
000210
000220 WORKING-STORAGE SECTION.
000230
000240 PROCEDURE DIVISION.
000250 001-MAIN-PROCEDURE.
000260 DISPLAY "TEMPLATE".
000270 STOP RUN.
-----------------------------------------------

--
John Culleton
Able Indexers and Typesetters

2005-10-26, 6:55 pm

In article <ubCdnav6dt8c5sLeRVn-jQ@adelphia.com>,
John Culleton <john@wexfordpress.com> wrote:

[snip]

>COBOL doesn't do well when we try to put it in a FORTRAN or C++ context. It
>isn't one of those.
>
>But in general we should try to be helpful, even to engineers ;,).

It just might be that engineers would have been taught a programming
language is a tool to accomplish a task and that no single tool is
appropriate to all jobs... well, then again there's the Swiss Army knife
and (position of reverence) Vise-Grip Locking Pliers... maybe I'll stop
now.

DD

Rick Smith

2005-10-26, 6:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:ocOdnbDjE_-A4MLeRVn-iA@adelphia.com...
> Christine Frayda wrote:
>
>
> I haven't used it much recently but I was active in the language from
about
> 1968 to about 1990 or so.

It seems to me that the subject page is about 'what is'
and not 'what was'. The skeleton program might well
have been appropriate for COBOL 74; but lacks the
'flavor' added by COBOL 85 and would not compile,
at all, under COBOL 2002, since some elements used
were obsolete in '85 and removed in 2002.

> Here is my skeleton program:
[snipped program]

John Culleton

2005-10-26, 6:55 pm

Rick Smith wrote:

>
> "John Culleton" <john@wexfordpress.com> wrote in message
> news:ocOdnbDjE_-A4MLeRVn-iA@adelphia.com...
> about
>
> It seems to me that the subject page is about 'what is'
> and not 'what was'. The skeleton program might well
> have been appropriate for COBOL 74; but lacks the
> 'flavor' added by COBOL 85 and would not compile,
> at all, under COBOL 2002, since some elements used
> were obsolete in '85 and removed in 2002.
>
> [snipped program]

My skeleton compiles on two current flavors of COBOL, OpenCOBOL and
TinyCOBOL.

I suspect most compiler writers are more generous than the standards gurus,
in allowing obsoleted features to continue. But if you have a better
skeleton to offer by all means post it.

BTW I suspect that the features you object to can be fixed by putting
asterisks in column 7. AFAIK the only things in my skeleton that are
obsoleted by 20000 are some paragraph headers in the IDENTIFICATION
DIVISION.

It is possible to be a good COBOL programmer and yet au courant by
commenting these paragraphs.

John Culleton
Able Indexers and Typesetters

Chuck Stevens

2005-10-26, 6:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:xaudnUUVbZXtesLeRVn-jQ@adelphia.com...

> My skeleton compiles on two current flavors of COBOL, OpenCOBOL and
> TinyCOBOL.

I'm really kind of surprised that neither of your cited compilers seem to
notice that COBOL itself requires both a SELECT and an FD in order fully to
describe any file: "Each file described in the Data Division must be named
once and only once as file-name in the FILE-CONTROL paragraph. Each file
sepecified in the file control entry must have a file description entry in
the Data Division." (ANSI X3.23-1974 page IV-4, 2.1.2.3, The FILE-CONTROL
paragraph, Syntax Rule 2. The '85 standard echoes this sentiment, as does
the 2002 standard and the draft proposed for 2008. I even see strong
evidence that this required correspondence exists in the original COBOL-60
specification).

What "value add" do these compilers provide by allowing one without the
other? In other words, what "feature" useful to the end user or to the
programmer does allowing SELECT without an associated FD represent?

How *should* a compiler diagnose this? Does this skeleton program include
an extra SELECT statement, or does it have a missing File Description? If
the shoe were on the other foot -- a FD without an associated SELECT, would
either compiler complain? If so, why? If not, why not?

> It is possible to be a good COBOL programmer and yet au courant by
> commenting these paragraphs.

Well, yeah; but I'm a bit at a loss to understand what's "au courant" about
commenting out a SELECT statement in COBOL of *any* vintage just to get the
program to compile ...

-Chuck Stevens

William M. Klein

2005-10-26, 6:55 pm

Chuck,
Interesting point. I had to go check to see for myself that these rules do
still exist. It seems to ME that there is very little "use" in requiring these
matches *UNLESS* a file is referenced in the procedure division. I would have
thought that these restrictions would have been removed the same time ('85
Standard) that non-unique BUT non-referenced data-items were allowed.

Having a SELECT without an FD/SD or an FD/SD without a SELECT seems "harmless"
to me UNLESS there is a reference to the file in the Procedure Division.

The "good" that this would allow would be the same as for non-unique data-names,
i.e. that they would expand the use of some (admittedly relatively obscure) COPY
statements.

Having looked at a couple of compilers' documentation, I don't see this as a
DOCUMENTED extension. I know that OpenCOBOL (and I think Tiny COBOL) don't have
either FIPS or ANSI flagging, but I would be interested if any other compiler
that allows this does or does not flag it.

P.S. I really do NOT see this as sufficiently useful to suggest as a "future
enhancement" to the language, it just surprised me that the rules were still
there.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:djormc$27i3$1@si05.rsvl.unisys.com...
> "John Culleton" <john@wexfordpress.com> wrote in message
> news:xaudnUUVbZXtesLeRVn-jQ@adelphia.com...
>
>
> I'm really kind of surprised that neither of your cited compilers seem to
> notice that COBOL itself requires both a SELECT and an FD in order fully to
> describe any file: "Each file described in the Data Division must be named
> once and only once as file-name in the FILE-CONTROL paragraph. Each file
> sepecified in the file control entry must have a file description entry in
> the Data Division." (ANSI X3.23-1974 page IV-4, 2.1.2.3, The FILE-CONTROL
> paragraph, Syntax Rule 2. The '85 standard echoes this sentiment, as does
> the 2002 standard and the draft proposed for 2008. I even see strong
> evidence that this required correspondence exists in the original COBOL-60
> specification).
>
> What "value add" do these compilers provide by allowing one without the
> other? In other words, what "feature" useful to the end user or to the
> programmer does allowing SELECT without an associated FD represent?
>

Rick Smith

2005-10-26, 6:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:xaudnUUVbZXtesLeRVn-jQ@adelphia.com...
> Rick Smith wrote:
>
>
> My skeleton compiles on two current flavors of COBOL, OpenCOBOL and
> TinyCOBOL.
>
> I suspect most compiler writers are more generous than the standards
gurus,
> in allowing obsoleted features to continue. But if you have a better
> skeleton to offer by all means post it.

H'm, looks to me like 'agumentum ad ignorantiam'.
No thanks! I don't see a need for a skeleton program,
nor one that was elsewhere suggested to be typical.

> BTW I suspect that the features you object to can be fixed by putting
> asterisks in column 7. AFAIK the only things in my skeleton that are
> obsoleted by 20000 are some paragraph headers in the IDENTIFICATION
> DIVISION.

No, my objections run deeper. The inclusion of a
REMARKS paragraph, though commented out, is
an IBM-ism thus not typical (not representative of)
standard COBOL. The presence of the unnecessary,
such as the SOURCE-COMPUTER and
OBJECT-COMPUTER paragraphs (both required
under COBOL 74; but now only required in some
conditions under COBOL 85) and sequence numbers
(under COBOL 85 there is no requirement for the
content of the sequence number area to be numeric,
or even unique). [The presence of all that baggage
could scare away the uninitiated!]

Also, to supply a program in fixed-form reference
format, without also supplying one in free-form
reference format (2002), may be confusing to those
trying to get a sense of COBOL. [Those unfamiliar
with COBOL seems to be the intended audience for
the subject page!]

> It is possible to be a good COBOL programmer and yet au courant by
> commenting these paragraphs.

It is also possible to be a good COBOL programmer,
and current, by not including those paragraphs, at all.

Chuck Stevens

2005-10-26, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11m02ippdtgme4f@corp.supernews.com...
> No, my objections run deeper. The inclusion of a
> REMARKS paragraph, though commented out, is
> an IBM-ism thus not typical (not representative of)
> standard COBOL.

REMARKS in the IDENTIFICATION DIVISION was indeed standard COBOL according
to ANSI X3.23-1968 and a reference to it in ANSI X3.23-1974. So was the
NOTE statement in the PROCEDURE DIVISION. On those grounds, *both* REMARKS
and NOTE were *clearly* representative of standard COBOL.

What *wasn't* standard COBOL prior to '74 was the asterisk in Column 7.

Some might argue that the asterisk in Column 7 was an IBM-ism, based on its
presence as an extension in an IBM DOS/370 COBOL(68) reference manual I
happen to have, but I see evidence of that usage as well in an even earlier
*Burroughs* B6500 COBOL-60 reference manual, so I don't know who actually
originated the feature. And REMARKS and NOTES were in every pre-74 COBOL
I'm aware of *precisely* because they *were* "representative of" standard
COBOL at one time.

> ... and sequence numbers
> (under COBOL 85 there is no requirement for the
> content of the sequence number area to be numeric,
> or even unique). [The presence of all that baggage
> could scare away the uninitiated!]

Stated a different way, the '74 standard allowed the "sequence number area"
to contain "a sequence number, consisting of six digits ... to label a
source program line." The '85 standard did away with that silly suggestion
that the sequence number field actually might be a useful way to identify a
given line and its position within a source file using a numeric value, and
allowed it to contain whatever the *end user* wanted it to contain! What a
ridiculous idea, and what an onerous burden on the programmer! ;-)

> Also, to supply a program in fixed-form reference
> format, without also supplying one in free-form
> reference format (2002), may be confusing to those
> trying to get a sense of COBOL. [Those unfamiliar
> with COBOL seems to be the intended audience for
> the subject page!]

2002 COBOL continues to support fixed-form reference format, as does the
proposed 2008 draft. There is no sign of a movement to migrate fixed-form
even into the "archaic" category, much less "obsolete". The formal
archaization of fixed-form reference format is *very* unlikely, given the
huge body of existing software that is in that form. Programmers are
welcome to write programs in free-form reference format if they desire, but
compliant compilers are required to continue to accept sources in fixed-form
reference format, and will almost certainly be required to do so until such
time as COBOL itself rides off into the sunset.

Why would supplying a program in the format with which COBOL programmers
have dealt for some forty-five years be confusing to anyone?

-Chuck Stevens

John Culleton

2005-10-26, 9:55 pm

Chuck Stevens wrote:

> "John Culleton" <john@wexfordpress.com> wrote in message
> news:xaudnUUVbZXtesLeRVn-jQ@adelphia.com...
>
>
> I'm really kind of surprised that neither of your cited compilers seem to
> notice that COBOL itself requires both a SELECT and an FD in order fully
> to
> describe any file: "Each file described in the Data Division must be
> named
> once and only once as file-name in the FILE-CONTROL paragraph. Each file
> sepecified in the file control entry must have a file description entry in
> the Data Division." (ANSI X3.23-1974 page IV-4, 2.1.2.3, The FILE-CONTROL
> paragraph, Syntax Rule 2. The '85 standard echoes this sentiment, as does
> the 2002 standard and the draft proposed for 2008. I even see strong
> evidence that this required correspondence exists in the original COBOL-60
> specification).
>
> What "value add" do these compilers provide by allowing one without the
> other? In other words, what "feature" useful to the end user or to the
> programmer does allowing SELECT without an associated FD represent?
>
> How *should* a compiler diagnose this? Does this skeleton program include
> an extra SELECT statement, or does it have a missing File Description? If
> the shoe were on the other foot -- a FD without an associated SELECT,
> would
> either compiler complain? If so, why? If not, why not?

As it happens one of the compilers (forget which) would complain if the
FILE-CONTROL paragraph was completely empty. My traditional skeleton does
not include either a SELECT or an FD because the skeleton is just a quicker
way to write a program. The usual headers, division, section and paragraph,
are there but not the stuff in between. My template is not an exercise in
theory abut a practical tool I use and have used for decades. You take the
template, copy it to another name, and then start filling in the blanks.
The usual headers are there and are spelled correctly etc.

>
> Well, yeah; but I'm a bit at a loss to understand what's "au courant"
> about commenting out a SELECT statement in COBOL of *any* vintage just to
> get the program to compile ...
>

Just consider the purpose, and the limitation of the compiler, as listed
above. I agree that this aberration need not appear in a skeleton to be
used by the engineers. I forgot to delete it.

--
John Culleton
Able Indexers and Typesetters

John Culleton

2005-10-26, 9:55 pm

Chuck Stevens wrote:

> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11m02ippdtgme4f@corp.supernews.com...
>
> REMARKS in the IDENTIFICATION DIVISION was indeed standard COBOL according
> to ANSI X3.23-1968 and a reference to it in ANSI X3.23-1974. So was the
> NOTE statement in the PROCEDURE DIVISION. On those grounds, *both*
> REMARKS and NOTE were *clearly* representative of standard COBOL.
>
> What *wasn't* standard COBOL prior to '74 was the asterisk in Column 7.
>
> Some might argue that the asterisk in Column 7 was an IBM-ism, based on
> its presence as an extension in an IBM DOS/370 COBOL(68) reference manual
> I happen to have, but I see evidence of that usage as well in an even
> earlier *Burroughs* B6500 COBOL-60 reference manual, so I don't know who
> actually
> originated the feature. And REMARKS and NOTES were in every pre-74
> COBOL I'm aware of *precisely* because they *were* "representative of"
> standard COBOL at one time.
>
>
> Stated a different way, the '74 standard allowed the "sequence number
> area" to contain "a sequence number, consisting of six digits ... to label
> a
> source program line." The '85 standard did away with that silly
> suggestion that the sequence number field actually might be a useful way
> to identify a given line and its position within a source file using a
> numeric value, and
> allowed it to contain whatever the *end user* wanted it to contain! What
> a ridiculous idea, and what an onerous burden on the programmer! ;-)
>
>
> 2002 COBOL continues to support fixed-form reference format, as does the
> proposed 2008 draft. There is no sign of a movement to migrate fixed-form
> even into the "archaic" category, much less "obsolete". The formal
> archaization of fixed-form reference format is *very* unlikely, given the
> huge body of existing software that is in that form. Programmers are
> welcome to write programs in free-form reference format if they desire,
> but compliant compilers are required to continue to accept sources in
> fixed-form reference format, and will almost certainly be required to do
> so until such time as COBOL itself rides off into the sunset.
>
> Why would supplying a program in the format with which COBOL programmers
> have dealt for some forty-five years be confusing to anyone?
>
> -Chuck Stevens
Amen

Fixed format is (minimally) more burdensome to write but easier to read.
After a layoff of more than a decade my first COBOL program was a little
ditty that takes a fixed format program an renumbers it in the usual way,
advancing the line number by ten digits for each succeeding line.

Since error messages sometimes reference lines by numbers it is not just a
useless exercise to number the lines.

As for "REMARKS" which became obsolete in I think '74, after PROGRAM-ID that
was the single most useful paragraph in the IDENTIFICATION DIVISION, the
one that said what the program did. So I will continue to use it, asterisks
and all. This follows the example given in Stern & Stern's textbook,
copyright 1985, which actually used the SECURITY header as a substitute for
the now illegal REMARKS header.

Until they pry my keyboard from my cold, dead fingers, I will strive to
write COBOL in a manner that compiles, executes correctly, is readable,
modifiable, and that Grace Murray Hopper would instantly recognize as
COBOL. The old girl was a lot smarter than most of her successors.
--
John Culleton
Able Indexers and Typesetters

Rick Smith

2005-10-26, 9:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:djp4fa$2cp0$1@si05.rsvl.unisys.com...
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11m02ippdtgme4f@corp.supernews.com...
>
> REMARKS in the IDENTIFICATION DIVISION was indeed standard COBOL according
> to ANSI X3.23-1968 and a reference to it in ANSI X3.23-1974. So was the
> NOTE statement in the PROCEDURE DIVISION. On those grounds, *both*
REMARKS
> and NOTE were *clearly* representative of standard COBOL.

Well, I find that to be most curious! Using Micro Focus
COBOL V 3.24, I compiled a program with a REMARKS
paragraph varying the compiler syntax. ANS74 and ANS85
syntax (with the flagging directive set) produced a flagging
message, OSVS and VSC2(2) did not; but VSC2(3) and
VSC2(4) produced a syntax error.

Was the "reference to it in ANSI X3.23-1974" to state that
it was removed from the previous standard?

> What *wasn't* standard COBOL prior to '74 was the asterisk in Column 7.
>
> Some might argue that the asterisk in Column 7 was an IBM-ism, based on
its
> presence as an extension in an IBM DOS/370 COBOL(68) reference manual I
> happen to have, but I see evidence of that usage as well in an even
earlier
> *Burroughs* B6500 COBOL-60 reference manual, so I don't know who actually
> originated the feature. And REMARKS and NOTES were in every pre-74
COBOL
> I'm aware of *precisely* because they *were* "representative of" standard
> COBOL at one time.

While I now accept that the REMARKS paragraph is not
an IBM-ism, it is, nonetheless, no longer standard COBOL
and appears not to have been for thirty years. I will reword
my objection to: The inclusion of a REMARKS paragraph,
though commented out, is obsolete and thus not
representative of recent standard COBOL.

>
> Stated a different way, the '74 standard allowed the "sequence number
area"
> to contain "a sequence number, consisting of six digits ... to label a
> source program line." The '85 standard did away with that silly
suggestion
> that the sequence number field actually might be a useful way to identify
a
> given line and its position within a source file using a numeric value,
and
> allowed it to contain whatever the *end user* wanted it to contain! What
a
> ridiculous idea, and what an onerous burden on the programmer! ;-)
>
>
> 2002 COBOL continues to support fixed-form reference format, as does the
> proposed 2008 draft. There is no sign of a movement to migrate fixed-form
> even into the "archaic" category, much less "obsolete". The formal
> archaization of fixed-form reference format is *very* unlikely, given the
> huge body of existing software that is in that form. Programmers are
> welcome to write programs in free-form reference format if they desire,
but
> compliant compilers are required to continue to accept sources in
fixed-form
> reference format, and will almost certainly be required to do so until
such
> time as COBOL itself rides off into the sunset.
>
> Why would supplying a program in the format with which COBOL programmers
> have dealt for some forty-five years be confusing to anyone?

Precisely because fixed-form is unfamiliar to
non-COBOL programmers who are familiar with
free-form source code. [See the above note
concerning what, to me, seems the intended audience
for the subject page.]

Judson McClendon

2005-10-27, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
> Having a SELECT without an FD/SD or an FD/SD without a SELECT
> seems "harmless" to me UNLESS there is a reference to the file in the
> Procedure Division.

Hi Bill. I rarely disagree with you on such issues but, if I understand you
correctly, I strongly disagree here. :-)

A SELECT without an FD or vice-versa is broken, incomplete code - quite
different from code that is not used. IMO, if it's in there, it dang well
better be correct, syntactically. You wouldn't suggest that improperly
formatted executable statements be excused because they were in paragraphs
that were never executed, would you?

Code that is not used/referenced can have specific reason, such as a
temporary change in a program, or a specific purpose, such as to maintain a
particular set of standardized code that is to be available for use within a
set of programs.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Howard Brazee

2005-10-27, 6:55 pm

On 26 Oct 2005 18:01:24 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>I found that line numbers were really useful - when source code was on
>boxes of punched cards. Now (for the last quarter century) I have a
>text editor that will go directly to any given line number.

The reason I like line numbers is because my listing's generated
numbers include copy members. So when I go from listing to source, I
sometimes have to search to find the line I want If the source has
unique line numbers, the search is instant.

Chuck Stevens

2005-10-27, 6:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:edCdnSEmEIfGhv3eRVn-tg@adelphia.com...

> As it happens one of the compilers (forget which) would complain if the
> FILE-CONTROL paragraph was completely empty.

As well it should; "file-control-entry" is enclosed in braces in the general
format for the FILE-CONTROL paragraph in the standards. If you have a
FILE-CONTROL, there has to be at least one SELECT. And as indicated
earlier, if there's a SELECT, there has to be a FD or SD corresponding to
it.

> My traditional skeleton does
> not include either a SELECT or an FD because the skeleton is just a
quicker
> way to write a program. The usual headers, division, section and
paragraph,
> are there but not the stuff in between. My template is not an exercise in
> theory abut a practical tool I use and have used for decades. You take the
> template, copy it to another name, and then start filling in the blanks.
> The usual headers are there and are spelled correctly etc.

OK, that's reasonable, but I like to make sure my programs compile. The
template I use is the minimum COBOL program that will compile and execute
with all of our current and past COBOL compilers, with the addition of the
not-strictly-necessary-but-almost-ubiquitous WORKING-STORAGE SECTION because
I have found through experience that if it's not there I go through an extra
cycle of syntax errors after adding data-description entries without it. I
too fill in the blanks in the skeleton as needed. Here's the "MINIMALTEST"
source file that I've been using for a decade or more:

000100 IDENTIFICATION DIVISION.
000200 ENVIRONMENT DIVISION.
000300 DATA DIVISION.
000400 WORKING-STORAGE SECTION.
000500 PROCEDURE DIVISION.
000600 MAIN-PARAGRAPH.
000700 STOP RUN.

-Chuck Stevens

Chuck Stevens

2005-10-27, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11m0b3e5nn5d564@corp.supernews.com...
>

> Was the "reference to it in ANSI X3.23-1974" to state that
> it was removed from the previous standard?

Depends on how you mean that, but I think the answer is "yes".

ANSI X3.23-1974 page XIV-31, 2.3.4, Elements Deleted From X3.23-1968:

REMARKS Paragraph (page 2-4). The REMARKS paragraph of the Identification
Division was deleted and the function replaced by the * comment line.

NOTE Statement (Pages 2-40 and 2-92). The NOTE statement was deleted and
the function replaced by the * comment line.

> While I now accept that the REMARKS paragraph is not
> an IBM-ism, it is, nonetheless, no longer standard COBOL
> and appears not to have been for thirty years. I will reword
> my objection to: The inclusion of a REMARKS paragraph,
> though commented out, is obsolete and thus not
> representative of recent standard COBOL.

Rewording the objection is not the same thing as admitting that the original
objection was based on two incorrect assumptions! Is this a case of "Don't
bother me with the facts; my mind is made up!"?

Don't get me wrong; I don't think adding the text "REMARKS." to the
beginning of the information contained in one or more * comment lines
describing a program's function in the IDENTIFICATION DIVISION adds
additional information to that explanatory text that is all that useful; I
am, however, a big fan of liberal comments *anywhere* in the program, and
not just in the IDENTIFICATION and PROCEDURE divisions, as the REMARKS
paragraph and the NOTE statement provided for in ANSI-X3.23-1968 and before.

I am also a huge fan of inline comments as described in ISO/IEC 1989:2002
(largely because the languages that our various compilers are written in
have had this capability for a *very* long time) and our '85 implementation
has had this feature added as an extension based on the '02 standard rules.

> Precisely because fixed-form is unfamiliar to
> non-COBOL programmers who are familiar with
> free-form source code. [See the above note
> concerning what, to me, seems the intended audience
> for the subject page.]

If the idea is to get non-COBOL programmers familiar with COBOL, it seems to
me a better idea to show them what COBOL has *historically* looked like
rather than show them COBOL using its latest gee-whiz features. Otherwise
they're not going to have a clue how to figure out what that all-caps
fixed-form sequence-numbered batch program that hasn't been changed for
forty years *actually does* or what needs to be done to make its main logic
talk to something written in Java ...

If you want to write in C++, write in C++. Don't expect a COBOL program to
look like a well-formed C++ program.

The single *worst* program I ever saw in any language was written in ANSI-68
COBOL. The logic was extremely complex, and it was written by a programmer
who (1) was intimately familiar with, and only comfortable with, very early
FORTRAN variable naming conventions, and who (2) had obviously just
discovered the joys of the ALTER verb and refused to use "fixed" GO TO's at
all anywhere in the program as a matter of principle.

"Clever" is not always "useful".

-Chuck Stevens

2005-10-27, 6:55 pm

In article <djqrmh$d8v$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:

[snip]

>If you want to write in C++, write in C++. Don't expect a COBOL program to
>look like a well-formed C++ program.
>
>The single *worst* program I ever saw in any language was written in ANSI-68
>COBOL. The logic was extremely complex, and it was written by a programmer
>who (1) was intimately familiar with, and only comfortable with, very early
>FORTRAN variable naming conventions, and who (2) had obviously just
>discovered the joys of the ALTER verb and refused to use "fixed" GO TO's at
>all anywhere in the program as a matter of principle.

'Real Programmers can write FORTRAN in any language'.

DD

Ian Dalziel

2005-10-27, 6:55 pm

On Thu, 27 Oct 2005 08:28:16 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>The single *worst* program I ever saw in any language was written in ANSI-68
>COBOL. The logic was extremely complex, and it was written by a programmer
>who (1) was intimately familiar with, and only comfortable with, very early
>FORTRAN variable naming conventions, and who (2) had obviously just
>discovered the joys of the ALTER verb and refused to use "fixed" GO TO's at
>all anywhere in the program as a matter of principle.

Eeuuuw!
--

Ian

Howard Brazee

2005-10-27, 6:55 pm

On Thu, 27 Oct 2005 08:06:18 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>OK, that's reasonable, but I like to make sure my programs compile. The
>template I use is the minimum COBOL program that will compile and execute
>with all of our current and past COBOL compilers, with the addition of the
>not-strictly-necessary-but-almost-ubiquitous WORKING-STORAGE SECTION because
>I have found through experience that if it's not there I go through an extra
>cycle of syntax errors after adding data-description entries without it. I
>too fill in the blanks in the skeleton as needed. Here's the "MINIMALTEST"
>source file that I've been using for a decade or more:
>
>000100 IDENTIFICATION DIVISION.
>000200 ENVIRONMENT DIVISION.
>000300 DATA DIVISION.
>000400 WORKING-STORAGE SECTION.
>000500 PROCEDURE DIVISION.
>000600 MAIN-PARAGRAPH.
>000700 STOP RUN.

What utility does this template have? To test your compiler? It's
too simple to save work in writing a new program.

Chuck Stevens

2005-10-27, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:j9u1m1hdh5dve4p4ugq4dho2s5cmu6bo66@
4ax.com...

>
> What utility does this template have? To test your compiler? It's
> too simple to save work in writing a new program.

Yes, I use it as my standard starting point for the development of test
cases verifying the correction of compiler problems. And it does save the
amount of work required in typing those seven lines every time I have to
come up with a test case, just as the other proposed template saves the
amount of work required in typing it in in other contexts.

-Chuck Stevens

Chuck Stevens

2005-10-27, 6:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:djqqdb$ca1$1@si05.rsvl.unisys.com...

> 000100 IDENTIFICATION DIVISION.
> 000200 ENVIRONMENT DIVISION.
> 000300 DATA DIVISION.
> 000400 WORKING-STORAGE SECTION.
> 000500 PROCEDURE DIVISION.
> 000600 MAIN-PARAGRAPH.
> 000700 STOP RUN.

I feel obliged in the interest of fairness to point out that this program
doesn't quite conform to ANSI-'74 or ANSI-'68 COBOL either; in those
dialects the CONFIGURATION SECTION and its SOURCE-COMPUTER and
OBJECT-COMPUTER paragraphs are apparently required; in ANSI-'85 and
subsequent dialects they're not. It is an extension to the earlier
standards for an implementor to allow an empty ENVIRONMENT DIVISION as our
implementations do.

-Chuck Stevens

Rick Smith

2005-10-27, 6:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:djqrmh$d8v$1@si05.rsvl.unisys.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11m0b3e5nn5d564@corp.supernews.com...
>
>
> Depends on how you mean that, but I think the answer is "yes".

delete: to strike out or remove (something written or
printed); erase; expunge. -- RHCD

I intended the sense of "remove" shown in the above
definition of "delete" and the statement to be consistent
with the REMARKS paragraph as one of the "Elements
Deleted From X3.23-1968".

> ANSI X3.23-1974 page XIV-31, 2.3.4, Elements Deleted From X3.23-1968:
>
> REMARKS Paragraph (page 2-4). The REMARKS paragraph of the Identification
> Division was deleted and the function replaced by the * comment line.
>
> NOTE Statement (Pages 2-40 and 2-92). The NOTE statement was deleted and
> the function replaced by the * comment line.
>
>
> Rewording the objection is not the same thing as admitting that the
original
> objection was based on two incorrect assumptions! Is this a case of
"Don't
> bother me with the facts; my mind is made up!"?

If the correction of facts does not conflict with the
reasoning that led to the original conclusion, then nothing
significant has changed. The fact that the REMARKS
paragraph was in a prior standard (and therefore not
an IBM-ism) merely places it into the same category
as the AUTHOR, INSTALLATION, DATE-WRITTEN,
DATE-COMPILED, and SECURITY paragraphs,
as elements removed from standard COBOL. To
present, on the subject page, any of these paragraphs,
though commented out, as representative of what
COBOL is, is to do a disservice to the language and,
.... well ... to those who brought about the changes
that removed them. [I assume that J4, at that time,
carefully considered the affect of the removal (deletion
from the prior standard) of these paragraphs.]

However, what programmers do in the privacy of their
own programs, is none of my concern!

> Don't get me wrong; I don't think adding the text "REMARKS." to the
> beginning of the information contained in one or more * comment lines
> describing a program's function in the IDENTIFICATION DIVISION adds
> additional information to that explanatory text that is all that useful; I
> am, however, a big fan of liberal comments *anywhere* in the program, and
> not just in the IDENTIFICATION and PROCEDURE divisions, as the REMARKS
> paragraph and the NOTE statement provided for in ANSI-X3.23-1968 and
before.
>
> I am also a huge fan of inline comments as described in ISO/IEC 1989:2002
> (largely because the languages that our various compilers are written in
> have had this capability for a *very* long time) and our '85
implementation
> has had this feature added as an extension based on the '02 standard
rules.
>
>
> If the idea is to get non-COBOL programmers familiar with COBOL, it seems
to
> me a better idea to show them what COBOL has *historically* looked like
> rather than show them COBOL using its latest gee-whiz features. Otherwise
> they're not going to have a clue how to figure out what that all-caps
> fixed-form sequence-numbered batch program that hasn't been changed for
> forty years *actually does* or what needs to be done to make its main
logic
> talk to something written in Java ...

But, as I stated previously (and is now obliterated by
snipping), I see no need to present any program as
representative of COBOL; but, if a fixed-form program,
of the type described above, is provided, then, I think, an
equivalent free-form program should also be provided.
Again, I think the subject page is about "what is" and
not "what was" and "what is" includes free-form reference
format.

I think there is ample opportunity for those, having seen
the subject page and find COBOL to be "interesting",
to learn more about "historic" COBOL before actually
having to do anything with existing COBOL programs.

> If you want to write in C++, write in C++. Don't expect a COBOL program
to
> look like a well-formed C++ program.

Mr Stevens, as you are well aware (and I mention this
only as a reminder), one of the significant changes in
COBOL for 2002 was the improved ability to use
COBOL in a mixed-language environment. Those,
more familiar with free-form source in other languages,
might be more comfortable using free-form source
in COBOL. If that is reasonable, then those others
might prefer their own COBOL programs to look
more like their well-formed language-of-choice
programs.

As for me, I use language extensions to accomplish
in COBOL that which might normally be done in
other languages; so I have no need for my programs
to look like any other language.

John Culleton

2005-10-27, 6:55 pm

Ian Dalziel wrote:

> On Thu, 27 Oct 2005 08:28:16 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> Eeuuuw!

Well I have seen lots of bad programs over the years. For example there was
the consultant, recommended by IBM, who deliberately obfuscated his code
for job security reasons. He would have data fields names X1 X2 etc.
which were sometimes used as indexes, and other times used as accumulators,
all in the same program. I have seen enough spaghetti code to fill several
Italian Restaurants. There was the fellow who thought Yiddish slang was

for data field names. There were the recent college graduates, trained
in COBOL by professors who hated COBOL, who created code full of multiply
nested ifs, lots of COMPUTE statements, and of course our old friends X1,
X2 etc. There was the fellow who put the entire key punch procedure into
the REMARKS paragraph. It went on for pages and pages. He was the
programming supervisor. I found him another job in another agency of
government. Ah, those were the bad old days....

--
John Culleton
Able Indexers and Typesetters

John Culleton

2005-10-27, 6:55 pm

Rick Smith wrote:

>
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:djqrmh$d8v$1@si05.rsvl.unisys.com...
>
> delete: to strike out or remove (something written or
> printed); erase; expunge. -- RHCD
>
> I intended the sense of "remove" shown in the above
> definition of "delete" and the statement to be consistent
> with the REMARKS paragraph as one of the "Elements
> Deleted From X3.23-1968".
>
> original
> "Don't
>
> If the correction of facts does not conflict with the
> reasoning that led to the original conclusion, then nothing
> significant has changed. The fact that the REMARKS
> paragraph was in a prior standard (and therefore not
> an IBM-ism) merely places it into the same category
> as the AUTHOR, INSTALLATION, DATE-WRITTEN,
> DATE-COMPILED, and SECURITY paragraphs,
> as elements removed from standard COBOL. To
> present, on the subject page, any of these paragraphs,
> though commented out, as representative of what
> COBOL is, is to do a disservice to the language and,
> ... well ... to those who brought about the changes
> that removed them. [I assume that J4, at that time,
> carefully considered the affect of the removal (deletion
> from the prior standard) of these paragraphs.]

I am happy to stick big pins in effgies of all those people.
The IDENTIFICATION DIVISION was deliberately preformatted with specific
paragraph names to ensure that the information about who what when where
and why would be presented in a standardized manner. This information was
needed when GMH developed the language and it is still needed today.
Removing the standardized template was an exercise in futility. Whom did
this change benefit? The paragraphs were always optional. But having them
in the standard encouraged their use. Sorry but these J2 etc.people just
didn't know what they were doing.

Except for the screen handling additions, (which by the way were done
clumsily), the PERFORM VARYING, the abolition of that assembly code clone
ALTER, and some clean up of indexed sequential file handling, I cannot think
of many changes from 68 on that I find useful. A single genius will
outdesign a committee any time.

I don't object to new features so long as the old features still work. But
COBOL programs as we all know last for decades. Any change that makes old
programs suddenly fail on recompile better have some strong arguments in
its favor. The step by step reduction of the IDENTIFICATION DIVISION had
none. They just did it because the didn't understand why it was needed. I
guess there weren't many DP Managers on those committees.
--
John Culleton
Able Indexers and Typesetters

Rick Smith

2005-10-27, 6:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:dM2dnfUTOpDM2PzenZ2dnUVZ_s-dnZ2d@adelphia.com...
> Rick Smith wrote:
[snip]
>
> I am happy to stick big pins in effgies of all those people.
> The IDENTIFICATION DIVISION was deliberately preformatted with specific
> paragraph names to ensure that the information about who what when where
> and why would be presented in a standardized manner. This information was
> needed when GMH developed the language and it is still needed today.
> Removing the standardized template was an exercise in futility. Whom did
> this change benefit? The paragraphs were always optional. But having them
> in the standard encouraged their use. Sorry but these J2 etc.people just
> didn't know what they were doing.

One could argue, as I recall hearing and reading about
some problems IBM had with their programs, that a
COPYRIGHT paragraph "was needed when GMH
developed the language and it is still needed today."
But where was it.

One could argue that the REMARKS paragraph
should only include a description of what the code does
and that a REVISION-HISTORY paragraph "was
needed when GMH developed the language and it is
still needed today." But where was it.

One could argue that the language was not developed
by GMH alone, but by a committee; that the committee
did the best they could given their knowledge at that
time; that subsequent revisions were necessary to
accommodate new knowledge; and that some of what
was thought necessary in earlier versions was best
deleted from future versions.

> Except for the screen handling additions, (which by the way were done
> clumsily), the PERFORM VARYING, the abolition of that assembly code clone
> ALTER, and some clean up of indexed sequential file handling, I cannot
think
> of many changes from 68 on that I find useful. A single genius will
> outdesign a committee any time.

I think a design developed by a single person may
well be the best design for that person and may well
be useless to others. Of course, I'm speaking from
my experience as a genius designer. <g>

> I don't object to new features so long as the old features still work. But
> COBOL programs as we all know last for decades. Any change that makes old
> programs suddenly fail on recompile better have some strong arguments in
> its favor. The step by step reduction of the IDENTIFICATION DIVISION had
> none. They just did it because the didn't understand why it was needed. I
> guess there weren't many DP Managers on those committees.

In 1968 and 1974, it could not be said, "COBOL
programs as we all know last for decades". Some of
my reference material on CODASYL describes
elements that first appeared in COBOL 85 as having
been recommended in the 1970s, not quite at the
"decades" point.

I seem to recall from earlier discussions, in this group,
that one of the changes, perhaps beginning in 1974,
was the inclusion of a list of obsolete elements and
that by having this list there would be ample time to
keep programs from suddenly failing when recompiled.
There has been twenty years to adapt to these changes,
yet I still see obsolete elements appearing in source
code posted to this group.

LX-i

2005-10-27, 9:55 pm

John Culleton wrote:
> I am happy to stick big pins in effgies of all those people.
> The IDENTIFICATION DIVISION was deliberately preformatted with specific
> paragraph names to ensure that the information about who what when where
> and why would be presented in a standardized manner. This information was
> needed when GMH developed the language and it is still needed today.
> Removing the standardized template was an exercise in futility. Whom did
> this change benefit? The paragraphs were always optional. But having them
> in the standard encouraged their use. Sorry but these J2 etc.people just
> didn't know what they were doing.

Who? Who cares who wrote it - what's important is that it works, and
comments can take care of who wrote it. I don't know about other shops,
but 1) pride of ownership is not really something you can afford to have
(although you can take pride in your fixes) and 2) Most programs, we can
tell who to ridicule by the style in which it is written. ;)

What? Again, easily handled with comments (although the PROGRAM-ID
could be considered part of the "what").

When? The time is now, baby... :) And, you can get a compiled
date/time from inspecting the output executable.

Where? Even less important than "who"...

Why? A question way outside the scope of even comments - system
requirements documents, specs, designs, use cases, and other
documentation does a lot better job of establishing the "why" than even
a REMARKS paragraph could.

I'm not knocking the folks that originally came up with that - they were
working in a different time, a different environment, with differently
trained users and a different customer base. But it's folly to think
that even though technology in general improves, a language is never
improved.

In place of the who/what/when/where/why, what the Identification
Division was being cleared out for was a host of new paragraph names,
used mostly to identify objects/classes/factories and repositories to
facilitate the OO additions of COBOL 2002.

Remember, too - we're just talking about the standard. Nothing is to
prevent IBM, MicroFocus, Fujitsu, Unisys, etc. from keeping support for
AUTHOR, DATE-WRITTEN, DATE-COMPILED, SECURITY, and INSTALLATION as
extensions to their yet-to-be-released 2002-compliant compilers. In
fact, their customers' needs have already driven OO implementations that
were around years before they were in the standards.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

John Culleton

2005-10-28, 6:55 pm

LX-i wrote:

> John Culleton wrote:
>
> Who? Who cares who wrote it - what's important is that it works, and
> comments can take care of who wrote it. I don't know about other shops,
> but 1) pride of ownership is not really something you can afford to have
> (although you can take pride in your fixes) and 2) Most programs, we can
> tell who to ridicule by the style in which it is written. ;)
>
> What? Again, easily handled with comments (although the PROGRAM-ID
> could be considered part of the "what").
>
> When? The time is now, baby... :) And, you can get a compiled
> date/time from inspecting the output executable.
>
> Where? Even less important than "who"...
>
> Why? A question way outside the scope of even comments - system
> requirements documents, specs, designs, use cases, and other
> documentation does a lot better job of establishing the "why" than even
> a REMARKS paragraph could.
>
> I'm not knocking the folks that originally came up with that - they were
> working in a different time, a different environment, with differently
> trained users and a different customer base. But it's folly to think
> that even though technology in general improves, a language is never
> improved.
>
> In place of the who/what/when/where/why, what the Identification
> Division was being cleared out for was a host of new paragraph names,
> used mostly to identify objects/classes/factories and repositories to
> facilitate the OO additions of COBOL 2002.
>
Those who are enamoured of OO programming should use an object oriented
programming language. True you can change the specs of COBOL sufficiently
to make it a clone of C++, but I submit that you no longer have COBOL but
rather a bad imitation of C++. GMH said in my hearing that we should not
ask COBOL to do a FORTRAN job and should not ask FORTRAN to do a COBOL job.
The principle remains. COBOL was not designed to be OO. If you load it down
with OO extensions then we are back to the tower of Babel. There are trad
programmers who can't make head nor tail out of an OO program and there are
newbie programmers who can't follow the logic of a traditional program. We
have two languages in effect under one cover.

All programmerw work within a subset consisting of those things they know
how to use. As you expand the superset you decrease the overlap of
individual subsets.

The suggestion that the paragraph names in the IDENTIFICATION DIVISION
needed to be "cleared out" to make room for OO paragraph names is
ridiculous. It is very easy to make a rule that says: "any paragraph name
in the IDENTIFICATION DIVISION is legal, and here are the traditional
ones." That is a quarter of a page of text in a manual somewhere and
effectively zero code in a complier.
> Remember, too - we're just talking about the standard. Nothing is to
> prevent IBM, MicroFocus, Fujitsu, Unisys, etc. from keeping support for
> AUTHOR, DATE-WRITTEN, DATE-COMPILED, SECURITY, and INSTALLATION as
> extensions to their yet-to-be-released 2002-compliant compilers. In
> fact, their customers' needs have already driven OO implementations that
> were around years before they were in the standards.
>
To answer some other posts, we had both relative and indexed files in 1968
in IBM compilers. The '74 changes blessed these, regularized them, and for
that we should give thanks. I-S access method is one of the few things that
COBOL has and other languages don't. Most have to interface with an
external DBMS to get that capability.

Now to answer the gent who didn't know why the programmer's name is
critical, consider this real-world situation, You work for agency X and
inherit a useful set of programs from Agency Y. No documentation of course.
It was lost when Agency Y reorganized and someone needed some file cabinet
space. You have some questions about the internal workings of the package.
Rather than reverse engineering the package you simply want to ask the
author a few questions. A name and hopefully an extension will be a big
help. Been there, done that.

More later. The boss beckons. (Even retired folks have bosses.)
--
John Culleton
Able Indexers and Typesetters

Chuck Stevens

2005-10-28, 6:55 pm

Some further thoughts on free-form reference format in COBOL. Rick Smith
wrote:

> Also, to supply a program in fixed-form reference
> format, without also supplying one in free-form
> reference format (2002), may be confusing to those
> trying to get a sense of COBOL. [Those unfamiliar
> with COBOL seems to be the intended audience for
> the subject page!]

From discussions I have overheard, I don't think the biggest issue leading
to the addition of free-form reference format to the 2002 COBOL standard was
that the people who most likely would be writing COBOL were more comfortable
looking at arbitrary-length source lines.

Rather, I think, the proliferation of source editors and application
development environments that were developed around *other* languages that
*did* have this feature -- and that avoided the historical "sequence number
area" concept as well -- created a clumsy environment for editing and
debugging traditional COBOL fixed-length-record fixed-form reference format
programs.

I think COBOL needed to provide arbitrary-length source lines and free-form
reference format in order to be *usable* in the modern program development
environment -- with modern tools of the class of the .NET environment,
Visual Studio, and Eclipse.

-Chuck Stevens

William M. Klein

2005-10-28, 6:55 pm

The actual reason that "free from reference format" was in the "must have"
category for the '02 Standard was continuation of DBCS (later MOCS, later
NATIONAL) literals. In the original design (based on what IBM had done - as I
recall) they did NOT introduce a "new" format for continuation of literals.
This meant that when source code was ported from some (many) mainframes to some
(many) workstation environments different length "shift-in/out" (or other
control characters) need to be added to or subtracted from lines.

With the '85 (and for fixed format still available) OLD style continuation
rules, one MUST know where the R-margin is/was - and converting source code from
environments without such control characters to those with them could not be
done (or couldn't be done easily).

Now, adding free form reference format provided MANY benefits beyond this - and
was (in fact) in use (as an extension) in non "NATIONAL" environments.

Furthermore, the '02 Standard (after free form reference format was initially
designed) added a NEW style of literal continuation that solves the older
problem (as well as solving problems with X'0A' or X'0D' in alphanumeric
literals). However, just so "history" is reflected in this thread, it was the
NATIONAL character/control character insertion deletion problem with literal
continuation that actually CAUSED free form reference format to be in the '02
Standard.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:djtpk7$26hk$1@si05.rsvl.unisys.com...
> Some further thoughts on free-form reference format in COBOL. Rick Smith
> wrote:
>
>
> From discussions I have overheard, I don't think the biggest issue leading
> to the addition of free-form reference format to the 2002 COBOL standard was
> that the people who most likely would be writing COBOL were more comfortable
> looking at arbitrary-length source lines.
>
> Rather, I think, the proliferation of source editors and application
> development environments that were developed around *other* languages that
> *did* have this feature -- and that avoided the historical "sequence number
> area" concept as well -- created a clumsy environment for editing and
> debugging traditional COBOL fixed-length-record fixed-form reference format
> programs.
>
> I think COBOL needed to provide arbitrary-length source lines and free-form
> reference format in order to be *usable* in the modern program development
> environment -- with modern tools of the class of the .NET environment,
> Visual Studio, and Eclipse.
>
> -Chuck Stevens
>
>

Chuck Stevens

2005-10-28, 6:55 pm

Cool! Thanks for the clarification, Bill!

In any event, it wasn't because e.g. Pascal programmers couldn't read COBOL
unless it was free format COBOL ...

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Qcx8f.359896$cw3.140146@fe01.news.easynews.com...
> The actual reason that "free from reference format" was in the "must have"
> category for the '02 Standard was continuation of DBCS (later MOCS, later
> NATIONAL) literals. In the original design (based on what IBM had done -
> as I recall) they did NOT introduce a "new" format for continuation of
> literals. This meant that when source code was ported from some (many)
> mainframes to some (many) workstation environments different length
> "shift-in/out" (or other control characters) need to be added to or
> subtracted from lines.
>
> With the '85 (and for fixed format still available) OLD style continuation
> rules, one MUST know where the R-margin is/was - and converting source
> code from environments without such control characters to those with them
> could not be done (or couldn't be done easily).
>
> Now, adding free form reference format provided MANY benefits beyond
> this - and was (in fact) in use (as an extension) in non "NATIONAL"
> environments.
>
> Furthermore, the '02 Standard (after free form reference format was
> initially designed) added a NEW style of literal continuation that solves
> the older problem (as well as solving problems with X'0A' or X'0D' in
> alphanumeric literals). However, just so "history" is reflected in this
> thread, it was the NATIONAL character/control character insertion deletion
> problem with literal continuation that actually CAUSED free form reference
> format to be in the '02 Standard.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:djtpk7$26hk$1@si05.rsvl.unisys.com...
>
>

John Culleton

2005-10-29, 6:57 pm

Chuck Stevens wrote:

> Some further thoughts on free-form reference format in COBOL. Rick Smith
> wrote:
>
>
> From discussions I have overheard, I don't think the biggest issue leading
> to the addition of free-form reference format to the 2002 COBOL standard
> was that the people who most likely would be writing COBOL were more
> comfortable looking at arbitrary-length source lines.
>
> Rather, I think, the proliferation of source editors and application
> development environments that were developed around *other* languages that
> *did* have this feature -- and that avoided the historical "sequence
> number area" concept as well -- created a clumsy environment for editing
> and debugging traditional COBOL fixed-length-record fixed-form reference
> format programs.
>
> I think COBOL needed to provide arbitrary-length source lines and
> free-form reference format in order to be *usable* in the modern program
> development environment -- with modern tools of the class of the .NET
> environment, Visual Studio, and Eclipse.
>
> -Chuck Stevens
Just FYI I use Gvim as an editor and it has syntax highlighting for about
200 languages, including COBOL. However it only recognizes the traditional
format. It interprets every line of the free format as an error and shows
them it in white characters on a bright red background.
--
John Culleton
Able Indexers and Typesetters

Michael Wojcik

2005-10-31, 6:55 pm

In article <x-OdnZOoAuhbmfneRVn-pA@adelphia.com>, John Culleton <john@wexfordpress.com> writes:
>
> Just FYI I use Gvim as an editor and it has syntax highlighting for about
> 200 languages, including COBOL. However it only recognizes the traditional
> format. It interprets every line of the free format as an error and shows
> them it in white characters on a bright red background.

This is true with at least stock Vim 6.3, though it was the decision
of the person who wrote the cobol.vim syntax file. It's trivially
amended to allow free-form source by commenting out all the match
lines for "cobolBadLine" and the "cobolBAD" match for "junk in
columns 1-6", as the comment in cobol.vim has it.

Or just comment out the lines that highlight "cobolBadLine" and
"cobolBAD" ("HiLink cobolBAD Error", etc).

If I'm feeling ambitious sometime I might actually fix the file so
that it recognizes both fixed-form and free-form, either heuristically
based on file contents or using a user setting. Probably not, though,
since I generally write free-form unless I'm maintaining existing
fixed-form code, and in that case I find format checking in the editor
of little utility.

Vim isn't entirely suited to working with fixed-form COBOL anyway.
It'd be nice if it let you set arbitrary tabstops, for example.

--
Michael Wojcik michael.wojcik@microfocus.com

Thus, the black lie, issuing from his base throat, becomes a boomerang to
his hand, and he is hoist by his own petard, and finds himself a marked man.
-- attributed to a "small-town newspaper editor in Wisconsin"

Oliver Wong

2005-11-11, 6:55 pm

"John Culleton" <john@wexfordpress.com> wrote in message
news:TcudnWj68fFBsf_eRVn-vg@adelphia.com...
>
> It is very easy to make a rule that says: "any paragraph name
> in the IDENTIFICATION DIVISION is legal, and here are the traditional
> ones." That is a quarter of a page of text in a manual somewhere and
> effectively zero code in a complier.

It might be confusing to the compiler if you allow "ENVIRONMENT
DIVISION", "DATA DIVISION" or "PROCEDURE DIVISION" as legal paragraph names
in the identification division though.

- Oliver

Sponsored Links