Prev: S0C4 x'4' abend while reading VSAM KSDS file
Next: COBOL: Don`t Call It a Comeback
From: Frank Swarbrick on 11 Jul 2008 20:36
Can anyone give me a good reason why this copybook should give an error?

01 SQLLINK.
05 SQL-ERROR-INFO-IN PIC X(20).
05 REDEFINES SQL-ERROR-INFO-IN.
10 SQL-ERROR-ACTION PIC X.
05 SQL-ERROR-INFO-OUT PIC X(20).
05 REDEFINES SQL-ERROR-INFO-OUT.
10 SQL-ERRLOC-LEN PIC S9(3) COMP-3.
05 ERRLOC PIC X(60).
05 SQL-ERRLOC REDEFINES ERRLOC.
10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN.

Here's what I get:
IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS DEPENDING
ON"
CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS
DISCARDED.

Now I'm not asking if it is in the standard or anything. I want to know
*why*. It seems to me to be harmless, as long as the max occurance doesn't
make the redefine exceed the length of the field it is redefining, and as
long as there are no 05 levels following it.

Not that it matters. If I can't do it then I can't do it. But it bugs me!
:-)

Frank


From: Arnold Trembley on 12 Jul 2008 03:32
Frank Swarbrick wrote:
> Can anyone give me a good reason why this copybook should give an error?
>
> 01 SQLLINK.
> 05 SQL-ERROR-INFO-IN PIC X(20).
> 05 REDEFINES SQL-ERROR-INFO-IN.
> 10 SQL-ERROR-ACTION PIC X.
> 05 SQL-ERROR-INFO-OUT PIC X(20).
> 05 REDEFINES SQL-ERROR-INFO-OUT.
> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3.
> 05 ERRLOC PIC X(60).
> 05 SQL-ERRLOC REDEFINES ERRLOC.
> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN.
>
> Here's what I get:
> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS DEPENDING
> ON"
> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS
> DISCARDED.
>
> Now I'm not asking if it is in the standard or anything. I want to know
> *why*. It seems to me to be harmless, as long as the max occurance doesn't
> make the redefine exceed the length of the field it is redefining, and as
> long as there are no 05 levels following it.
>
> Not that it matters. If I can't do it then I can't do it. But it bugs me!
> :-)
>
> Frank
>
>

Frank, is this IBM COBOL on DOS/VSE or z/VSE? I'm not sure if that
should make any difference compared to Enterprise COBOL for z/OS.

I tried this with Realia COBOL 1.0 from 1990, and it only gave a
warning message "Variable length OCCURS accepted in REDEFINES".

It seems odd to me that the level 10 data item that has OCCURS
DEPENDING ON has no data name, and therefore must default to FILLER.
How could you ever reference it?

You might try changing it to look like this, just to see if you get a
different result:

05 ERRLOC PIC X(60).
05 SQL-ERRLOC REDEFINES ERRLOC.
10 SQL-ERRLOC-BYTE
OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN
PIC X.

I'm not sure how having the ODO helps you, versus simply redefining
the ERRLOC field as a fixed-length array of 60 bytes.

With kindest regards,


--
http://arnold.trembley.home.att.net/
From: Vince Coen on 12 Jul 2008 09:03
Hello Frank!

12 Jul 08 01:36, Frank Swarbrick wrote to All:

FS> Can anyone give me a good reason why this copybook should give an
FS> error?

FS> 01 SQLLINK.
FS> 05 SQL-ERROR-INFO-IN PIC X(20).
FS> 05 REDEFINES SQL-ERROR-INFO-IN.
FS> 10 SQL-ERROR-ACTION PIC X.

Assuming the compiler puts in an implicit filler of x(19).

FS> 05 SQL-ERROR-INFO-OUT PIC X(20).
FS> 05 REDEFINES SQL-ERROR-INFO-OUT.
FS> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3.

Same as above.

FS> 05 ERRLOC PIC X(60).
FS> 05 SQL-ERRLOC REDEFINES ERRLOC.
FS> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN.

remove the '10' ie a redefines b pic x occurs 0 to 60 etc.

FS> Here's what I get:
FS> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS
FS> DEPENDING ON"
FS> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS
FS> DISCARDED.

FS> Now I'm not asking if it is in the standard or anything. I want to
FS> know *why*. It seems to me to be harmless, as long as the max
FS> occurance doesn't make the redefine exceed the length of the field it
FS> is redefining, and as long as there are no 05 levels following it.

FS> Not that it matters. If I can't do it then I can't do it. But it
FS> bugs me!
FS> :-)

FS> Frank


See what happens then.

Vince


From: Robert on 12 Jul 2008 18:33
On Fri, 11 Jul 2008 18:36:21 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com>
wrote:

>Can anyone give me a good reason why this copybook should give an error?
>
> 01 SQLLINK.
> 05 SQL-ERROR-INFO-IN PIC X(20).
> 05 REDEFINES SQL-ERROR-INFO-IN.
> 10 SQL-ERROR-ACTION PIC X.
> 05 SQL-ERROR-INFO-OUT PIC X(20).
> 05 REDEFINES SQL-ERROR-INFO-OUT.
> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3.
> 05 ERRLOC PIC X(60).
> 05 SQL-ERRLOC REDEFINES ERRLOC.
> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN.
>
>Here's what I get:
>IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS DEPENDING
>ON"
> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS
>DISCARDED.
>
>Now I'm not asking if it is in the standard or anything. I want to know
>*why*. It seems to me to be harmless, as long as the max occurance doesn't
>make the redefine exceed the length of the field it is redefining, and as
>long as there are no 05 levels following it.
>
>Not that it matters. If I can't do it then I can't do it. But it bugs me!
>:-)

You don't need ERRLOC. Delete ERRLOC and the redefines clause.
From: William M. Klein on 12 Jul 2008 19:56
Frank,
You didn't ask how to "fix" this code, but (as I understand it) WHY there was
such a restrction.

I don't recall this being dissussed (and I'll bet it has been in the Standard
since '74 if not '68). However, my best GUESS would be that:

Because the "object of the ODO" - SQL-ERRLOC-LEN - in this case MAY get
"out-of range" (greater than 60) during the exectuion of the program, that this
mighr have been viewed as something to avoid at run-time (larger item redefining
a smaller item - which has always been illegal - although some vendors allow it
as an extension).

As I recall there was a difference introduce either in the '85 or '02 Standards
as to when "out-of-range" ODO values were detected (and gave unpredictable
results). At one time, these conditions were detected when the ODO field was
"used" and at another time, it was detected when the ODO item was set.

Again, this is just guessing. As the Standard explicitly allows a smaller (or
same-size) field to redefine a "larger" (or same size) field, it would LOOK to
me as if what have coded would make sense.

***

FYI,
Frank did NOT ask for it, but if anyone wants to know the relevant "Standard"
rule it is (from the '02 Standard),

"Neither the original definition nor the redefinition shall include a
variable-occurrence data item."

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote in message
news:4877A825.6F0F.0085.0(a)efirstbank.com...
> Can anyone give me a good reason why this copybook should give an error?
>
> 01 SQLLINK.
> 05 SQL-ERROR-INFO-IN PIC X(20).
> 05 REDEFINES SQL-ERROR-INFO-IN.
> 10 SQL-ERROR-ACTION PIC X.
> 05 SQL-ERROR-INFO-OUT PIC X(20).
> 05 REDEFINES SQL-ERROR-INFO-OUT.
> 10 SQL-ERRLOC-LEN PIC S9(3) COMP-3.
> 05 ERRLOC PIC X(60).
> 05 SQL-ERRLOC REDEFINES ERRLOC.
> 10 PIC X OCCURS 0 TO 60 DEPENDING ON SQL-ERRLOC-LEN.
>
> Here's what I get:
> IGYDS1169-S "REDEFINES" SUBJECT "SQL-ERRLOC" CONTAINED AN "OCCURS DEPENDING
> ON"
> CLAUSE OR WAS VARIABLE-LENGTH. THE "REDEFINES" CLAUSE WAS
> DISCARDED.
>
> Now I'm not asking if it is in the standard or anything. I want to know
> *why*. It seems to me to be harmless, as long as the max occurance doesn't
> make the redefine exceed the length of the field it is redefining, and as
> long as there are no 05 levels following it.
>
> Not that it matters. If I can't do it then I can't do it. But it bugs me!
> :-)
>
> Frank
>
>


 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: S0C4 x'4' abend while reading VSAM KSDS file
Next: COBOL: Don`t Call It a Comeback