Cobol - Question regarding uniqueness

Author

Question regarding uniqueness

Roger While

2007-07-27, 7:55 am

IDENTIFICATION DIVISION.
PROGRAM-ID. t11.
DATA DIVISION.
WORKING-STORAGE SECTION.

01 K525-AII-DRVR-RSTRT-DATA.
03 VARIABLE1 PIC X(8) VALUE SPACES.
03 K525-FRMT-FILE-ARRAY.
06 K525-FRMT-FILE-ARRAY-ROW
OCCURS 6 TIMES
ASCENDING KEY IS VARIABLE1.
09 VARIABLE1 PIC X(8) VALUE SPACES.
09 OTHER-DATA-ITEM PIC S9(5).
PROCEDURE DIVISION.
GOBACK.

This compiles with big iron and MF.
Why?
Of course, this is a stupid definition.
Any attempt in the PROC div to reference any field
would lead to a compile failure.
OC throws this out at compile time.

2007-07-27, 6:55 pm

In article <f8cm2c$vpa$00$1@news.t-online.com>,
Roger While <simrw@sim-basis.de> wrote:
>IDENTIFICATION DIVISION.
>PROGRAM-ID. t11.
>DATA DIVISION.
>WORKING-STORAGE SECTION.
>
>01 K525-AII-DRVR-RSTRT-DATA.
> 03 VARIABLE1 PIC X(8) VALUE SPACES.
> 03 K525-FRMT-FILE-ARRAY.
> 06 K525-FRMT-FILE-ARRAY-ROW
> OCCURS 6 TIMES
> ASCENDING KEY IS VARIABLE1.
> 09 VARIABLE1 PIC X(8) VALUE SPACES.
> 09 OTHER-DATA-ITEM PIC S9(5).
>PROCEDURE DIVISION.
>GOBACK.
>
>This compiles with big iron and MF.
>Why?

I may be going out on a limb here... but I think that the reason the code
'compiles with big iron and MF' is that the code complies with their
implementation of the language standard.

>Of course, this is a stupid definition.
>Any attempt in the PROC div to reference any field
>would lead to a compile failure.

Good thing you didn't try to do that, eh?

DD

Doug Miller

2007-07-27, 6:55 pm

In article <f8cm2c$vpa$00$1@news.t-online.com>, "Roger While" <simrw@sim-basis.de> wrote:
>IDENTIFICATION DIVISION.
>PROGRAM-ID. t11.
>DATA DIVISION.
>WORKING-STORAGE SECTION.
>
>01 K525-AII-DRVR-RSTRT-DATA.
> 03 VARIABLE1 PIC X(8) VALUE SPACES.
> 03 K525-FRMT-FILE-ARRAY.
> 06 K525-FRMT-FILE-ARRAY-ROW
> OCCURS 6 TIMES
> ASCENDING KEY IS VARIABLE1.
> 09 VARIABLE1 PIC X(8) VALUE SPACES.
> 09 OTHER-DATA-ITEM PIC S9(5).
>PROCEDURE DIVISION.
>GOBACK.
>
>This compiles with big iron and MF.
>Why?

Because their parsers are broken.

>Of course, this is a stupid definition.
>Any attempt in the PROC div to reference any field
>would lead to a compile failure.

The duplicate definition of VARIABLE1 should lead to an immediate compile
failure on any Cobol compiler.

>OC throws this out at compile time.

As well it should. As should every Cobol compiler.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Michael Mattias

2007-07-27, 6:55 pm

Doug Miller

2007-07-27, 6:55 pm

In article <K3mqi.114$591.112@nlpi070.nbdc.sbc.com>, "Michael Mattias" <mmattias@talsystems.com> wrote:
>"Roger While" <simrw@sim-basis.de> wrote in message
>news:f8cm2c$vpa$00$1@news.t-online.com...
>
>Why not? the ASCENDING KEY clause must specify datanames which are part of
>the same group item, so *in context* VARIABLE1 is non-ambiguous.

The problem is the line right after that: duplicate definitions of VARIABLE1.

The reference VARIABLE1 OF K525-FRMT-FILE-ARRAY OF K525-AII-DRVR-RSTRT-DATA is
not ambiguous, but the reference VARIABLE1 OF K525-AII-DRVR-RSTRT-DATA *is*,
and thus the duplication should cause a compile-time error. It's an illegal
construct, regardless of whether it's referenced in the Procedure Division or
not.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Michael Mattias

2007-07-27, 6:55 pm

"Doug Miller" <spambait@milmac.com> wrote in message
news:H0mqi.26842$bz7.24027@newssvr22.news.prodigy.net...
> Because their parsers are broken.
>
>
> The duplicate definition of VARIABLE1 should lead to an immediate compile
> failure on any Cobol compiler.
>
>
> As well it should. As should every Cobol compiler.

I am afraid you are incorrect, sir.

Both VARIABLE1 data items are subordinate to group items, and therefore may
be qualified within the procedure division to eliminate ambiguity.
[color=darkred]

The first reference is VARIABLE1 OF K525-ALL-DRVR-RSTST-DATA, the second is
VARIABLE1 OF K525-FRMT-FILE-ARRAY-ROW (subscript).

MCM

Binyamin Dissen

2007-07-27, 6:55 pm

On Fri, 27 Jul 2007 13:01:32 GMT spambait@milmac.com (Doug Miller) wrote:

:>In article <f8cm2c$vpa$00$1@news.t-online.com>, "Roger While" <simrw@sim-basis.de> wrote:
:>>IDENTIFICATION DIVISION.
:>>PROGRAM-ID. t11.
:>>DATA DIVISION.
:>>WORKING-STORAGE SECTION.

:>>01 K525-AII-DRVR-RSTRT-DATA.
:>> 03 VARIABLE1 PIC X(8) VALUE SPACES.
:>> 03 K525-FRMT-FILE-ARRAY.
:>> 06 K525-FRMT-FILE-ARRAY-ROW
:>> OCCURS 6 TIMES
:>> ASCENDING KEY IS VARIABLE1.
:>> 09 VARIABLE1 PIC X(8) VALUE SPACES.
:>> 09 OTHER-DATA-ITEM PIC S9(5).
:>>PROCEDURE DIVISION.
:>>GOBACK.

:>>This compiles with big iron and MF.
:>>Why?

:>Because their parsers are broken.

Not at all.

:>>Of course, this is a stupid definition.
:>>Any attempt in the PROC div to reference any field
:>>would lead to a compile failure.

:>The duplicate definition of VARIABLE1 should lead to an immediate compile
:>failure on any Cobol compiler.

Why? Must unused fields be unique?

:>>OC throws this out at compile time.

:>As well it should. As should every Cobol compiler.

Why?

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

SkippyPB

2007-07-27, 6:55 pm

On Fri, 27 Jul 2007 07:56:16 -0500, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>"Roger While" <simrw@sim-basis.de> wrote in message
>news:f8cm2c$vpa$00$1@news.t-online.com...
>
>Why not? the ASCENDING KEY clause must specify datanames which are part of
>the same group item, so *in context* VARIABLE1 is non-ambiguous.
>
>Methinks you'd have some problems if you referred to VARIABLE1 anywhere in
>the PROCEDURE DIVISION, but I don't see a problem just compiling the DATA
>DIVISION.
>
>MCM
>
>

Not if you said VARIABLE1 OF K525-AII-DRVR-RSTRT-DATA or VARIABLE1 OF
K525-FRMT-FILE-ARRAY. However, if in the PROCEDURE DIVISION you
referenced just VARIABLE1, you would get a compile error.

>
>
>

Regards,
////
(o o)
-oOO--(_)--OOo-

** Norm's Greetings on US TV Show "Cheers" **

SAM: "What'll you have Normie?"
NORM: "Well, I'm in a gambling mood Sammy. I'll take a glass of whatever
comes out of that tap."
SAM: "Looks like beer, Norm."
NORM: "Call me Mister Lucky."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

John Reagan

2007-07-27, 6:55 pm

I think it is ambiguous.

Here's what the OpenVMS HP COBOL compiler says:

$ cobol x

ASCENDING KEY IS VARIABLE1.
...........................^
%COBOL-F-AMBIGSYM, Ambiguous reference - check name qualification
at line number 11 in file HIYALL$:[REAGAN]X.COB;1
%COBOL-F-ENDNOOBJ, HIYALL$:[REAGAN]X.COB;1 completed with 1 diagnostic -
object deleted

--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company

Doug Miller

2007-07-27, 6:55 pm

In article <FXmqi.130$ER7.88@nlpi068.nbdc.sbc.com>, "Michael Mattias" <mmattias@talsystems.com> wrote:
>"Doug Miller" <spambait@milmac.com> wrote in message
>news:H0mqi.26842$bz7.24027@newssvr22.news.prodigy.net...
>
>I am afraid you are incorrect, sir.

I disagree. :-)
>
>Both VARIABLE1 data items are subordinate to group items, and therefore may
>be qualified within the procedure division to eliminate ambiguity.
>
>
>
>The first reference is VARIABLE1 OF K525-ALL-DRVR-RSTST-DATA, the second is
>VARIABLE1 OF K525-FRMT-FILE-ARRAY-ROW (subscript).

Right -- and since the ASCENDING KEY phrase doesn't include *either*
qualifier, that's an ambiguous reference. The compiler should flag either
that, or the second instance of VARIABLE1, but to leave them both unflagged is
incorrect behavior.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Rick Smith

2007-07-27, 6:55 pm

"Roger While" <simrw@sim-basis.de> wrote in message
news:f8cm2c$vpa$00$1@news.t-online.com...
> IDENTIFICATION DIVISION.
> PROGRAM-ID. t11.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
>
> 01 K525-AII-DRVR-RSTRT-DATA.
> 03 VARIABLE1 PIC X(8) VALUE SPACES.
> 03 K525-FRMT-FILE-ARRAY.
> 06 K525-FRMT-FILE-ARRAY-ROW
> OCCURS 6 TIMES
> ASCENDING KEY IS VARIABLE1.
> 09 VARIABLE1 PIC X(8) VALUE SPACES.
> 09 OTHER-DATA-ITEM PIC S9(5).
> PROCEDURE DIVISION.
> GOBACK.
>
> This compiles with big iron and MF.
> Why?

A data-name need not be unique unless it is referenced.

Current rules are at FDIS ISO/IEC 1989:2002 page 83,
8.4.1 Uniqueness of reference,
"Every user-defined name in a source element is assigned, by
the user, to name a resource that is to be used in solving a
data processing problem. (See 8.3.1.1.1, User-defined words.)
In order to use a resource, a statement shall contain a reference
that uniquely identifies that resource. In order to ensure
uniqueness of reference, a user-defined name may be qualified,
subscripted, or reference modified as described in the following
paragraphs."

One question that I considered is whether "VARIABLE1" in
the KEY phrase is unique, without explicit qualification.
According to the OCCURS clause, SR(3), this use of
"VARIABLE1" meets the requirement that it "shall be the name
of either the entry containing the OCCURS clause or an entry
subordinate to the entry containing the OCCURS clause" and,
therefore, need not be explicitly qualified; though it may be so
qualified under SR(2).

> Of course, this is a stupid definition.
> Any attempt in the PROC div to reference any field
> would lead to a compile failure.

Not according to my tests with Micro Focus COBOL 3.2.
These statements work when inserted into the given code.
-----
move "a" to variable1 of k525-frmt-file-array-row (1)
display variable1 of k525-frmt-file-array-row (1)
-----
That is, these statements appear to meet the current standard
as well as the rules published in the LRM for that compiler.

Roger While

2007-07-27, 6:55 pm

Try to move to the VARIABLE1 at 03 :-)
I can't do it with MF SE 2.2 and 4.x :-)

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:13akbf86979gc4c@corp.supernews.com...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:f8cm2c$vpa$00$1@news.t-online.com...
>
> A data-name need not be unique unless it is referenced.
>
> Current rules are at FDIS ISO/IEC 1989:2002 page 83,
> 8.4.1 Uniqueness of reference,
> "Every user-defined name in a source element is assigned, by
> the user, to name a resource that is to be used in solving a
> data processing problem. (See 8.3.1.1.1, User-defined words.)
> In order to use a resource, a statement shall contain a reference
> that uniquely identifies that resource. In order to ensure
> uniqueness of reference, a user-defined name may be qualified,
> subscripted, or reference modified as described in the following
> paragraphs."
>
> One question that I considered is whether "VARIABLE1" in
> the KEY phrase is unique, without explicit qualification.
> According to the OCCURS clause, SR(3), this use of
> "VARIABLE1" meets the requirement that it "shall be the name
> of either the entry containing the OCCURS clause or an entry
> subordinate to the entry containing the OCCURS clause" and,
> therefore, need not be explicitly qualified; though it may be so
> qualified under SR(2).
>
>
> Not according to my tests with Micro Focus COBOL 3.2.
> These statements work when inserted into the given code.
> -----
> move "a" to variable1 of k525-frmt-file-array-row (1)
> display variable1 of k525-frmt-file-array-row (1)
> -----
> That is, these statements appear to meet the current standard
> as well as the rules published in the LRM for that compiler.
>
>
>

Rick Smith

2007-07-27, 6:55 pm

"Roger While" <simrw@sim-basis.de> wrote in message
news:f8dked$bpd$03$1@news.t-online.com...
> Try to move to the VARIABLE1 at 03 :-)
> I can't do it with MF SE 2.2 and 4.x :-)

Neither can I because that VARIABLE1 can not be made
unique without changing the record description or the
data-name. You wrote "Any attempt ... to reference any field";
but, in fact, only that VARIABLE1 can not be referenced.
I even went so far as to investigate the KEY phrase and,
while it can not be used with a SEARCH statement (no
index data item), it may be used with a table sort (extension
in some compilers and added to COBOL 2002).

[color=darkred]
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:13akbf86979gc4c@corp.supernews.com...

William M. Klein

2007-07-28, 3:55 am

I believe that any compiler conforming to the '85 Standard needs to compile this
cleanly. See page XV88-42, which states,

"(8) Uniaueness of reference (1 NUC). A user-defined word need not be unique or
be capable of being made unique unless referenced."

This was a substantive change from the '74 Standard. (The reason that it was
done - as I recall it - was to allow for COPY members with non-unique, not
possible of being mad eunique, but unreferenced data items).

There certainly MIGHT be a question about whenther
"ASCENDING KEY IS VARIABLE1"

is a reference to VARIABLE1, but I do not believe that such uses are considered
a "reference" in COBOL syntax.

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:f8cm2c$vpa$00$1@news.t-online.com...
> IDENTIFICATION DIVISION.
> PROGRAM-ID. t11.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
>
> 01 K525-AII-DRVR-RSTRT-DATA.
> 03 VARIABLE1 PIC X(8) VALUE SPACES.
> 03 K525-FRMT-FILE-ARRAY.
> 06 K525-FRMT-FILE-ARRAY-ROW
> OCCURS 6 TIMES
> ASCENDING KEY IS VARIABLE1.
> 09 VARIABLE1 PIC X(8) VALUE SPACES.
> 09 OTHER-DATA-ITEM PIC S9(5).
> PROCEDURE DIVISION.
> GOBACK.
>
> This compiles with big iron and MF.
> Why?
> Of course, this is a stupid definition.
> Any attempt in the PROC div to reference any field
> would lead to a compile failure.
> OC throws this out at compile time.
>
>
>

William M. Klein

2007-07-28, 3:55 am

You can ignore my last post (which was a different change). The change that
relates to this is in the '02 Standard, page 827 which states,

"67) Implicit qualification of data-names within the same group. Data-names
referenced in a data description entry need not be qualified when they are
defined in the same group as the subject of the entry, unless qualifiers are
needed to establish uniqueness within that group."

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:f8cm2c$vpa$00$1@news.t-online.com...
> IDENTIFICATION DIVISION.
> PROGRAM-ID. t11.
> DATA DIVISION.
> WORKING-STORAGE SECTION.
>
> 01 K525-AII-DRVR-RSTRT-DATA.
> 03 VARIABLE1 PIC X(8) VALUE SPACES.
> 03 K525-FRMT-FILE-ARRAY.
> 06 K525-FRMT-FILE-ARRAY-ROW
> OCCURS 6 TIMES
> ASCENDING KEY IS VARIABLE1.
> 09 VARIABLE1 PIC X(8) VALUE SPACES.
> 09 OTHER-DATA-ITEM PIC S9(5).
> PROCEDURE DIVISION.
> GOBACK.
>
> This compiles with big iron and MF.
> Why?
> Of course, this is a stupid definition.
> Any attempt in the PROC div to reference any field
> would lead to a compile failure.
> OC throws this out at compile time.
>
>
>

Alistair

2007-07-28, 7:55 am

Doug Miller wrote:
> In article <f8cm2c$vpa$00$1@news.t-online.com>, "Roger While" <simrw@sim-basis.de> wrote:
>
> Because their parsers are broken.
>
>
> The duplicate definition of VARIABLE1 should lead to an immediate compile
> failure on any Cobol compiler.
>
>
> As well it should. As should every Cobol compiler.
>

If the duplicate definition should lead to a compile time error then
why does every compiler allow the use of the duplicated FILLER?

Michael Mattias got it right (somewhere above this) when mentioning
QUALIFICATION.

Doug Miller

2007-07-28, 6:55 pm

In article <1185622971.861842.12870@22g2000hsm.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:

>If the duplicate definition should lead to a compile time error then
>why does every compiler allow the use of the duplicated FILLER?

Because FILLER does not actually name anything.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Alistair

2007-07-29, 6:55 pm

Doug Miller wrote:
> In article <1185622971.861842.12870@22g2000hsm.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>
> Because FILLER does not actually name anything.

So I couldn't use qualification to reference a FILLER? I have always
taken FILLER as being a non-unique data-name.

LX-i

2007-07-29, 6:55 pm

Alistair wrote:
> Doug Miller wrote:
>
> So I couldn't use qualification to reference a FILLER? I have always
> taken FILLER as being a non-unique data-name.

So how exactly would you code a qualified reference to a filler? :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Pete Dashwood

2007-07-29, 9:55 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1185732137.913365.17310@b79g2000hse.googlegroups.com...
>
> Doug Miller wrote:
>
> So I couldn't use qualification to reference a FILLER? I have always
> taken FILLER as being a non-unique data-name.
>

You can't reference FILLER with or without qualification. That is why it's a
.... filler :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Doug Miller

2007-07-30, 7:55 am

In article <1185732137.913365.17310@b79g2000hse.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>Doug Miller wrote:
> <alistair@ld50macca.demon.co.uk> wrote:
>
>So I couldn't use qualification to reference a FILLER? I have always
>taken FILLER as being a non-unique data-name.
>
No, you can't. FILLER can't be referenced at all, with or without
qualification.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

LX-i

2007-07-30, 6:55 pm

Doug Miller wrote:
> In article <1185732137.913365.17310@b79g2000hse.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:
> No, you can't. FILLER can't be referenced at all, with or without
> qualification.

Well, as "FILLER" anyway...

01 myVar.
12 myVar1 pic X(07).
12 pic X(03).
....
move "___" to myVar (8:)

But, at that point, you're not directly referencing "filler", you're
reference-modifying a group-level item.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Howard Brazee

2007-07-30, 6:55 pm

On Sat, 28 Jul 2007 03:25:18 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>I believe that any compiler conforming to the '85 Standard needs to compile this
>cleanly. See page XV88-42, which states,
>
>"(8) Uniaueness of reference (1 NUC). A user-defined word need not be unique or
>be capable of being made unique unless referenced."

I've never come across a compiler error with such variables, but I
have only noticed such variables rarely.

I did come across a working program once with every single FILLER
spelled FILER.

Sponsored Links