The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition
of MYDATA.
But - I can't find where this would be an invalid COBOL program according
to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
Using any data item before it is defined is an error and GnuCOBOL flags
it (in the obscure way it flags most undefined item errors. :-)
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?
Not having a copy of the 2002 standard I can't help with that
but then I wonder why it matters as long as the compilers are
getting it right. Do you have a compiler that doesn't?
bill
The absence of an explicit statement about definition-before-use (I've
perused
the IBM and Microfocus documentation on this, as well as the 2002 standard) seems to be the problem here.
And - without such a prohibition, the second program (above) would be
valid,
and GnuCOBOL would be in error.
That's really what I'm asking...
Just what is the fundamental language requirement here - and where is that articulated/documented.
Or - much more likely - I'm missing something somewhere...
The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition
of MYDATA.
But - I can't find where this would be an invalid COBOL program according
to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition
of MYDATA.
But - I can't find where this would be an invalid COBOL program according
to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
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
Bill Gunshannon wrote:
Hi Bill!
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
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.
Unfortunately - there is no prohibition against a forward reference
to a constant.
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?)
As far as I can tell, the standard allows forward references toWhere does the standard allow that? Where does the standard even
as-yet undefined
constants.
So, a compiler would be required (as Rick mentioned) to make multiple passes for resolving forward constant references.
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.
On 7/18/22 23:43, Thomas David Rivers wrote:
Bill Gunshannon wrote:
Hi Bill!
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
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.
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.)
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. :-)
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.
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
Bill Gunshannon wrote:
On 7/18/22 23:43, Thomas David Rivers wrote:
Bill Gunshannon wrote:
Hi Bill!
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
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 toHi Bill!!
look for "Undefined Data Item" or something similar.
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'llYes - you are right - I did call it something else. It is really
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.)
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... )
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 standardYes - that is a good point, I can't find anything in the standard that
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. :-)
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.
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.
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.
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...
On 7/18/22 01:41, Thomas David Rivers wrote:
(SNIP)
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
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.
The standard doesn't mention forward references because they are
part of COBOL, or indeed any programming language.
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.
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.
The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the
definition of MYDATA.
But - I can't find where this would be an invalid COBOL program
according to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
- Thanks! -
- Dave Rivers -
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
Rick Smith wrote:
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.
Many thanks Rick for pointing these out!
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.
Yes - that's what I was kinda getting at, albeit very indirectly;
but if you can allow a forward reference then multiple passes would
be needed.
So, then, we can assert that the example I posted with the forward
reference _should_ compile by a 2002/2014 conforming compiler?
The standard doesn't mention forward references because they are
part of COBOL, or indeed any programming language.
They aren't part of many programming languages - which is where I
was coming from. Many languages require a declaration/definition
before a use.
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.
Yes - I was wondering why the constants aren't part of a new section,
instead
of sprinkled-in with the other data-definitions from the existing
section. It
was somewhat confusing, to me, that constants "live" in WORKING STORAGE, LOCAL STORE or LINKAGE. Is this simply an artifact of being a
data-definition
and those various sections cause no distinction in a CONSTANT data-definition?
(I _think_ that's what you are saying above?)
The 2002 standard was not broadly implemented. Most are using the
current 2014 standard. The next revision, currently 202X, may be approved >this year.
Oh my! I didn't even realize - I've since made a trip to the ANSI store
for the 2014 standard... thanks for pointing that out!
Bill Gunshannon wrote:
On 7/18/22 23:43, Thomas David Rivers wrote:
Bill Gunshannon wrote:
Hi Bill!
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
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... )
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.
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".
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
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
(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.
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.
- Dave Rivers -
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...
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition
of MYDATA.
But - I can't find where this would be an invalid COBOL program according
to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
- Thanks! -
- Dave Rivers -
On 18/07/2022 17:41, Thomas David Rivers wrote:
The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition
of MYDATA.
But - I can't find where this would be an invalid COBOL program according to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
- Thanks! -
- Dave Rivers -
Please excuse the simple question of an old man:The CONSTANT RECORD clause may be specified at the 01 level anywhere in the Working-Storage and Linkage sections in the 2014 standard.
Don't constants in COBOL need to be defined in the DATA DIVISION after WORKING-STORAGE as...
DATA DIVISION.
... WORKING-STORAGE SECTION.
...
CONSTANT SECTION.
...
PROCEDURE DIVISION.
etc...?
I'm not familiar with the 2002 standard in COBOL and I don't have a copy
of it, but in the flavours of COBOL I have seen where CONSTANTS are supported, they do require to be defined in the CONSTANT SECTION.
Having so defined them, they then acquire a "read only" quality and
cannot be set to anything other than the initial value. (Compiler
diagnostic if you try...)
Of course, with the never-ending efforts to make COBOL more like
NOT-COBOL, this constraint may well have been abolished.
Might be worth checking what the 2002 standard says about the CONSTANT SECTION (if anything...)
Cheers,
Pete.
--
I used to write *COBOL*; now I can do *anything*...
On Wednesday, July 27, 2022 at 2:39:56 PM UTC+1, dash...@enternet.co.nz wrote:
On 18/07/2022 17:41, Thomas David Rivers wrote:
The COBOL 2002 standard adds constant-entry to the various
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define *when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition of MYDATA.
But - I can't find where this would be an invalid COBOL program according to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined. But - the 2002 standard doesn't seem to make that illegal.
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?
- Thanks! -
- Dave Rivers -
I should have added that there is also a constant entry that consists of a single elementary item with the keyword CONSTANT, which is what I now think was the subject of the question. It may be anywhere in the data division.Please excuse the simple question of an old man:
Don't constants in COBOL need to be defined in the DATA DIVISION after WORKING-STORAGE as...
DATA DIVISION.
... WORKING-STORAGE SECTION.
...
CONSTANT SECTION.
...
PROCEDURE DIVISION.
etc...?
I'm not familiar with the 2002 standard in COBOL and I don't have a copy
of it, but in the flavours of COBOL I have seen where CONSTANTS are supported, they do require to be defined in the CONSTANT SECTION.
Having so defined them, they then acquire a "read only" quality and
cannot be set to anything other than the initial value. (Compiler diagnostic if you try...)
Of course, with the never-ending efforts to make COBOL more like
NOT-COBOL, this constraint may well have been abolished.
Might be worth checking what the 2002 standard says about the CONSTANT SECTION (if anything...)
Cheers,
Pete.
--The CONSTANT RECORD clause may be specified at the 01 level anywhere in the Working-Storage and Linkage sections in the 2014 standard.
I used to write *COBOL*; now I can do *anything*...
On Wednesday, July 27, 2022 at 2:39:56 PM UTC+1, dash...@enternet.co.nz wrote:
On 18/07/2022 17:41, Thomas David Rivers wrote:The CONSTANT RECORD clause may be specified at the 01 level anywhere in the Working-Storage and Linkage sections in the 2014 standard.
The COBOL 2002 standard adds constant-entry to the variousPlease excuse the simple question of an old man:
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition
of MYDATA.
But - I can't find where this would be an invalid COBOL program according >>> to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined.
But - the 2002 standard doesn't seem to make that illegal.
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?
- Thanks! -
- Dave Rivers -
Don't constants in COBOL need to be defined in the DATA DIVISION after
WORKING-STORAGE as...
DATA DIVISION.
... WORKING-STORAGE SECTION.
...
CONSTANT SECTION.
...
PROCEDURE DIVISION.
etc...?
I'm not familiar with the 2002 standard in COBOL and I don't have a copy
of it, but in the flavours of COBOL I have seen where CONSTANTS are
supported, they do require to be defined in the CONSTANT SECTION.
Having so defined them, they then acquire a "read only" quality and
cannot be set to anything other than the initial value. (Compiler
diagnostic if you try...)
Of course, with the never-ending efforts to make COBOL more like
NOT-COBOL, this constraint may well have been abolished.
Might be worth checking what the 2002 standard says about the CONSTANT
SECTION (if anything...)
Cheers,
Pete.
--
I used to write *COBOL*; now I can do *anything*...
On Thursday, July 28, 2022 at 3:19:35 PM UTC+1, Robert Jones wrote:
On Wednesday, July 27, 2022 at 2:39:56 PM UTC+1, dash...@enternet.co.nz wrote:I should have added that there is also a constant entry that consists of a single elementary item with the keyword CONSTANT, which is what I now think was the subject of the question. It may be anywhere in the data division.
On 18/07/2022 17:41, Thomas David Rivers wrote:The CONSTANT RECORD clause may be specified at the 01 level anywhere in the Working-Storage and Linkage sections in the 2014 standard.
The COBOL 2002 standard adds constant-entry to the variousPlease excuse the simple question of an old man:
storage sections for defining compile-time constants.
However, I doesn't (at least in my scouring of the document) define
*when* these are extent and when they can be used.
For instance, this seems like a reasonable use:
IDENTIFICATION DIVISION.
PROGRAM-ID. ALPHEDIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A CONSTANT 5.
01 B CONSTANT 6.
01 CON CONSTANT A + B.
01 MYDATA PIC 9(CON).
PROCEDURE DIVISION.
Where the constant CON is used for the picture-string in the definition >>>> of MYDATA.
But - I can't find where this would be an invalid COBOL program according >>>> to the 2002 standard:
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.
In this second example, the constant 'B' is used before it is defined. >>>> But - the 2002 standard doesn't seem to make that illegal.
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?
- Thanks! -
- Dave Rivers -
Don't constants in COBOL need to be defined in the DATA DIVISION after
WORKING-STORAGE as...
DATA DIVISION.
... WORKING-STORAGE SECTION.
...
CONSTANT SECTION.
...
PROCEDURE DIVISION.
etc...?
I'm not familiar with the 2002 standard in COBOL and I don't have a copy >>> of it, but in the flavours of COBOL I have seen where CONSTANTS are
supported, they do require to be defined in the CONSTANT SECTION.
Having so defined them, they then acquire a "read only" quality and
cannot be set to anything other than the initial value. (Compiler
diagnostic if you try...)
Of course, with the never-ending efforts to make COBOL more like
NOT-COBOL, this constraint may well have been abolished.
Might be worth checking what the 2002 standard says about the CONSTANT
SECTION (if anything...)
Cheers,
Pete.
--
I used to write *COBOL*; now I can do *anything*...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 98:55:39 |
| Calls: | 6,700 |
| Calls today: | 5 |
| Files: | 12,232 |
| Messages: | 5,349,601 |