On Tuesday, July 19, 2022 at 5:53:17 PM UTC-4, Thomas David Rivers wrote:
> Bill Gunshannon wrote:
>
> > On 7/18/22 23:43, Thomas David Rivers wrote:
> >
> >> Bill Gunshannon wrote:
> >>
> >>>
> >>>> Is this a valid COBOL 2002 program? If not, can someone point me to
> >>>> the phrase/definition in the 2002 standard that makes it invalid?
> >>>
> >>>
> >>>
> >>> I am sure I could find where this is addressed given a chance to
> >>> read the actual standard. But I am certainly not going to pay
> >>> ISO more than $100 for the opportunity. I expect there is a place
> >>> where the standard addresses undefined data items. But it is
> >>> probably not where you are looking for it.
> >>>
> >>> bill
> >>>
> >>>
> >> Hi Bill!
> >>
> >> Your idea about "undefined" was a terrific one - I did look through
> >> the standard some more. There is even a section B.2 that explicitly
> >> lists all the undefined behavior.
> >
> >
> > "Undefined behavior" is something totally different. You want to
> > look for "Undefined Data Item" or something similar.
> Hi Bill!!
>
> I spent some time and looked at every occurence of "undefined" in the
> standard,
> there didn't seem (to me) to be any kind of statement like that.
> >
> >>
> >> Unfortunately - there is no prohibition against a forward reference
> >> to a constant.
> >
> >
> > Now you are calling it something else. If yo keep that up you'll
> > never find it. :-) What you are saying would make sense if, like
> > Pascal, COBOL had a FORWARD verb. :-) (No, FORWARD can not be used
> > for data items, even in Pascal.)
> Yes - you are right - I did call it something else. It is really
> important to
> have precise terms.
>
> Let's define a "forward reference" as a reference to a data definition that
> is not yet defined at its use, but is subsequently defined (to distinguish
> it from a name that is never defined.)
>
> Going back to my very first post on this, this example contains a "forward
> reference" to the constant-name 'B':
> IDENTIFICATION DIVISION.
> PROGRAM-ID. ALPHEDIT.
> ENVIRONMENT DIVISION.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 A CONSTANT 5.
> 01 CON CONSTANT A + B.
> 01 MYDATA PIC 9(CON).
> 01 B CONSTANT 6.
> PROCEDURE DIVISION.
> I can't find any reason in the standard why that shouldn't compile. I
> also can't
> find a statement about when the value of a constant is 'defined'.
>
> The standard, under the "General Rules" for a CONSTANT (section 13.9.3)
> says:
>
> 1) If literal-1 or compilation-variable-name-1 is specified, the
> effect of specifying
> constant-name-1 in other than this entry is as if literal-1 or
> the text represented by
> compilation-variable-name-1 were written where constant- name-1
> is written.
>
> ...
>
> 3) If arithmetic-expression-1, data-name-1, or data-name-2 is
> specified, the effect of
> writing constant-name-1 in other than this entry is as if an
> integer literal were
> written where constant-name-1 is written. This integer literal
> has the value specified in
> these general rules.
>
> It doesn't require that the definition be encountered before its use.
>
> I _think_ this is the about the only situation where "something" can be
> used
> before it's defined. That is, the WORKING STORAGE section appears before
> the PROCEDURE DIVISION, so any undefined (or unqualifiable) name is simply
> undefined when encountered in the PROCEDURE DIVISION.
>
> So, the reason I'm concerned about this, is I _think_ this is the first
> time such
> a situation could arise in COBOL? (I'd like to be found wrong on that
> idea, if
> someone cares to provide an example... )

Forward references have been part of COBOL since, like, forever.

For the ENVIRONMENT DIVISION, forward references occur for
FILE STATUS and RECORD KEY names. In the DATA DIVISION
FILE SECTION file-description-entry, the record-clause may refer
to a data-item in the WORKING-STORAGE SECTION for the length
of a record read or to be written. In the PROCEDURE DIVISION,
forward references to procedure-names are normal.

What is different with 2002, is the need to resolve all references
in the WORKING-STORAGE SECTION by potentially making multiple
passes before processing the PROCEDURE DIVISION.

> >> There doesn't seem to be a prohibition at all about a
> >> forward
> >> reference (although I'm hard-pressed to consider where that might
> >> happen?
> >> Perhaps in a VALUE clause for a pointer data-definition?)
> >
> >
> > If use of an undefined data item is covered somewhere in the standard
> > then there would be no reason to address a forward reference as at the
> > time the reference is made it is an undefined data item. Unless there
> > was a FORWARD verb. :-)
> Yes - that is a good point, I can't find anything in the standard that
> talks about that in terms of the point-of-reference. The standard seems
> to talk about compilation-data-name as being defined or not, but
> nothing else.
>
> I'm with you on the intuition that there must be something in the
> standard
> that speaks to this - but I can't find it.
> >
> >>
> >> As far as I can tell, the standard allows forward references to
> >> as-yet undefined
> >> constants.
> >
> > Where does the standard allow that? Where does the standard even
> > mention forward references? My guess is it does not and you are
> > merely assuming if it doesn't explicitly prohibit it then it allows
> > it. Bad assumption. I am pretty sure that the standard does not
> > prohibit inline assembler, but I doubt that means it would be allowed.

The standard doesn't mention forward references because they are
part of COBOL, or indeed any programming language.

> >> So, a compiler would be required (as Rick mentioned) to make
> >> multiple passes for resolving forward constant references.
> >
> >
> > No, the compiler is only required to do the things explicitly covered
> > in the standard. And, as I said, I would be willing to bet that there
> > is a specific reference somewhere in the standard to "undefined data
> > items".
>
> >
> >>
> >> I'm not sure what that would mean for constants that appear in
> >> different
> >> sections? Can a constant in a WORKING STORAGE section reference a
> >> constant in a LINKAGE section? What does that mean? What does it
> >> mean
> >> if the constant is declared in the LINKAGE section of a sub-program with
> >> the GLOBAL clause? Can it be referenced in the enclosing program?
> >> Can it
> >> be referenced at a point in the enclosing program when the values of
> >> data
> >> in the LINKAGE section of a sub-program are explicitly undefined?
> >> When does
> >> a compile-time constant become "undefined"?
> >>
> >> The 2002 standard only seems to say:
> >>
> >> 5) Neither the value of literal-1 nor the value of any of the
> >> literals in
> >> arithmetic-expression-1 shall be dependent, directly or
> >> indirectly,
> >> upon the value of constant-name-1.
> >>
> >> (constant-name-1 is the name being defined as a constant, with
> >> arithmetic-expression-1
> >> being the value.) And - since they mention "indirectly" - that
> >> would seem to
> >> imply the possibility of a forward reference to an
> >> as-yet-to-be-defined constant (as I think
> >> that would be about the only way to "indirectly" reference the
> >> constant being defined...
> >> wouldn't it?)
> >>
> >> So - it would seem to explicitly disallow a recursive constant
> >> definition
> >> (so the program snippet I posted is invalid) but - it appears to have
> >> nothing to say
> >> about the use of a constant before it's defined... and thus would
> >> allow it.
> >>
> >> If that understanding is correct, the GnuCOBOL compiler needs to
> >> make an
> >> adjustment for that. Microfocus implements level-78 "constants",
> >> I'm not sure
> >> what they do with any forward reference (if someone happens to have
> >> that available
> >> it might be nice to check what they do.)
> >> But - I think some clarifications of what a "constant" is, and just
> >> when it is
> >> defined and available might be useful.
> >>
> >
> > I still think you are making a mountain out of a molehill. I do not
> > think that forward references are allowed. I have never seen any
> > mention of them in previous COBOL language references and I am unaware
> > of any mention of them in the 2002 standard. You are dealing with an
> > undefined data item at the time of its use and the result of that is
> > handled by the compiler as it always has been. Being a CONSTANT doesn't
> > impart any magical powers. It is still just a data item.
> >
> > bill
> >
> Yeah - maybe I am... but with the strange phrase in the standard about
> directly or indirectly referencing the name being defined, it seems to me
> that the authors were actually _intending_ to allow a forward-reference
> (as that would be the only way to arrive at an indirect reference - I
> think.)
> So, if the intent is to allow a forward reference, and there isn't anything
> in the standard that disallows it, would it then be safe to say it's
> allowed?
>
> Also - there are some questions I still have about constants defined in
> a sub-program's WORKING STORAGE or LINKAGE sections with the GLOBAL
> clause attached. Are such constants visible in the containing program?
> The standard is clared that such data is "undefined" when the sub-program
> is not active (which makes absolute sense) but does not prohibit the
> reference
> to them. Only that if you do, you are entering the "realm of undefined" if
> the sub-program is not active (also, this begs a question about _which_ one
> you are referencing if the sub-program is at all RECURSIVE - but that's a
> different question.) So - what does this mean about CONSTANTs defined
> in such sections? Are they globally visible at compile-time - or only
> intended
> to be visible when the sub-program is active? I can't imagine that's
> the intent,
> but that seems to be what one can consider from the verbiage in the
> standard.

A CONSTANT, defined anywhere in the DATA DIVISION, may be referenced
anywhere a value may be used in the DATA DIVISION (and as I recall, possibly
in the ENVIRONMENT DIVISION). It may be referenced in the PROCEDURE
DIVISION.

If the CONSTANT has the GLOBAL attribute, it may be referenced in any
contained program; however, it may not be referenced in any containing
program.

> If the standard is really just a "set of guidelines" - then, I guess
> I'll just have
> to be disappointed.
>
> I was hoping someone from the committee might be lurking here with
> some rationale, or perhaps could tell me where my interpretation is wrong
> and why it is wrong... clearly, like you say, I'm confused somewhere....
>
> Of course - it may all be moot - how many COBOL 2002 compliant
> implementations
> are there? If no-one bothers to implement the features the way the
> standard
> indicates, then what's the point? I may be absolutely making the problem
> bigger than reality suggests.

The 2002 standard was not broadly implemented. Most are using the
current 2014 standard. The next revision, currently 202X, may be approved
this year.

> p.s. Does anyone know a way to contact the COBOL standard committee to
> ask about this stuff? Is there a newsgroup or other facility
> where the
> committee members might "hang out"? Perhaps I need to be redirected
> to such a forum...

AFAIK the committee members communicate using a restricted access
site. Any questions about the standard would have to be sent "snail mail"
to the committee through INCITS (for the US) or ISO (international). I don't
have specific information and haven't cared to look for it.