Re: interesting use of NEXT SENTENCE vs. CONTINUE




"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:6Djue.102745$yp5.68075@xxxxxxxxxxxxxxxxxxxxxxxxx
> Chuck may or may not know this, but others may be interested.
>
> Almost ALL the "extensions" to the '85 Standard used by Pete and pointed
out by
> Chuck are valid in IBM COBOL(s) and those PC or workstation compilers that
> support "compatibility" with such.

I understood that from the beginning.

I believe strongly that the best way to write *portable* code using
implementations that purport to conform to a COBOL standard is to write
using *standard* COBOL rather than write to make use of
implementor-specific -- or even implementor-initiated -- extensions. Pete
seems to have posted his program with the idea that any old COBOL85 compiler
ought to be able to compile it, and 'tain't so. Some of the things he used
have made it into '02 COBOL, some didn't.

A couple of points:

<< Program name in quotes (allowed in '02 Standard)>>

Don't think so. "PROGRAM-ID. program-name-1 [AS literal-1] ...".
"Program-name" is a form of user-defined word; the rules say "literal-1, if
specified, is the name of the program that is externalized to the operating
environment". ISO/IEC 1989:2002 pages 67 and 186.

<<Some paragraphs in sections, some not (I *think* allowed in '02
Standard)>>

Don't think so. The syntax diagram on ISO/IEC 1989:2002 page 377 seems to
me to show a couple of things. If Declaratives exists it consists of
Sections, and in that case the nondeclarative code that exists begins with a
Section header. If Declaratives don't exist, there's executable
nondeclarative code, and a Section exists anywhere in that code, there must
be one at the beginning of the nondeclarative code. If there's no
nondeclarative code, neither Section nor paragraph is required. And it's
*paragraphs* that are optional in any case (with or without Sections, with
or without Declaratives, with or without nondeclarative code).

> Bottom-Line:
> Portability depends on where you plan to port (or more likely where you
end-up
> porting to but did NOT plan on <G>)

True. But if your goal is to provide "portable" code to the COBOL community
at large, presuming that that set of users is identical to the set of users
to which the code would be portable is a little disconcerting to those to
whose implementations don't share the same set of extensions. I had to
spend time weeding out a bunch of extensions from COBOL code that I was led
to believe was supposed to be portable to any implementation by someone with
a wide variety of architecture backgrounds. As far as I'm concerned, only
*standard-compliant* COBOL merits the presumption of portablility to
*standard-compliant* implementations.

-Chuck Stevens


.



Relevant Pages

  • Re: Corruption of COBOL.
    ... I am a programmer skilled in COBOL 85 or earlier. ... portability is a stumbling block. ... My general advice is to write in the 85 standard, ...
    (comp.lang.cobol)
  • Re: Method to force keeping of source
    ... It appears to me that your wish is that the COBOL standard should prevent ... environment for the compiler or in the execution environment. ... > implementor defined is one of the problems as I look at the situation as ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... Here's the problem with OO COBOL - it is still very incomplete.. ... realized that OO was incomplete without support ... It's about two years ago a former, retired M/F Manager, (not Bill Klein ... Micro Focus above - but he was referring to the fact that Standard ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... There are users of OO COBOL; they are just far fewer than either the vendors ... whether from the same vendor or not. ... disagreed with you that XML should be supported *first* by the OO features ... > being spent by J4 to provide these facilities through a standard that will ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... some aspects of OO COBOL have grown and evolved since then. ... Classes from ANY vendor on ANY platform can be "wrapped" (provided the ... 2002 standard implemented. ... I really don't care what J4 or WG4 or SG-1 ...
    (comp.lang.cobol)