Question regarding uniqueness

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.

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

In article <f8cm2c$vpa$00$1@news.t-online.com>, "Roger While" <simrw@sim-basis.de> wrote:[c
olor=darkred]
>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?[/color]

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.

"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?

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

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 o
r
not.

--
Regards,
Doug Miller (alphag at milmac dot com)

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

"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.
 


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


MCM

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-b
asis.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.

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

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

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.