|
View previous topic :: View next topic
|
| Author |
Message |
RTE200
New User
Joined: 06 Nov 2024
Posts: 4
Location: Israel
|
|
|
|
Howdy, everyone.
I'm confused by the following REDEFINES triggering "redefines a smaller item" warning.
| Code: |
*
* 01 level item is not provided here, bc full structure is too big anyway,
* but there are lots of items before and after the 'problematic' REDEFINES.
*
03 AA16-TIME-PIC9 PIC 9(7) VALUE ZEROES. 304 310 7 3
03 AA16-TIME-PIC9-R9 REDEFINES AA16-TIME-PIC9. 304 322 19PR <
*ERROR* IGYDS1154-W "AA16-TIME-PIC9-R9" redefined a smaller item. The program was accepted as written.
05 FILLER PIC 9. 304 304 1
05 AA16-HH PIC 9(2). 305 306 2 K
05 AA16-MM PIC 9(2). 307 308 2 K
05 AA16-SS PIC 9(2). 309 310 2 K
* Enterprise IBM COBOL 4.2.0
|
The difference in size seems to be quite significant according to compiler output.
P.S.
I have found one IBM ticket, where the solution section is saying the following:
| Quote: |
| We intentionally did not diagnose the 01 level redefines. We only issue message 1154 if the redefines is a non 01 level because it changes the length of the 01 group item that contains the redefines item. This is working as designed. |
Does it (officially) mean 'redefines' statement applied to non-01-level item is 'messing' with the size of the resulting item ?
 |
|
| Back to top |
|
 |
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1050
Location: Richmond, Virginia
|
|
|
|
I'd like to see the code following your last shown line:
| Code: |
| * Enterprise IBM COBOL 4.2.0 |
|
|
| Back to top |
|
|
RTE200
New User
Joined: 06 Nov 2024
Posts: 4
Location: Israel
|
|
|
|
Thanks, Phil,
I've already found it, and just like you've said it was matter of the next item.
Next item had misleading formatting, something like this:
| Code: |
03 AA16-TIME-PIC9 PIC 9(7) VALUE ZEROES. 304 310 7 3
03 AA16-TIME-PIC9-R9 REDEFINES AA16-TIME-PIC9. 304 322 19PR <
05 FILLER PIC 9. 304 304 1
05 AA16-HH PIC 9(2). 305 306 2 K
05 AA16-MM PIC 9(2). 307 308 2 K
05 AA16-SS PIC 9(2). 309 310 2 K
* Enterprise IBM COBOL 4.2.0
05 NEXT-ITEM PIC 9(12).
05 REDEFINES NEXT-ITEM.
10 NEXT-DATE PIC 9(08).
10 NEXT-NUM PIC 9(04).
03 THIS-IS-WHERE-THE-SIZE-IS-BACK-TO-NORMAL . |
Looks like someone did a bad copy-paste, back in the day, when this routine was written. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1050
Location: Richmond, Virginia
|
|
|
|
Good catch. Pretty sloppy indentation.
The nice thing about the PL/I Optimizing Compiler was that source lines could be 100 characters long (obviously only useful with online source code). Byte 1 was for a comment "*", so the other 99 for code.
This allowed very deep indenting. |
|
| Back to top |
|
|
RTE200
New User
Joined: 06 Nov 2024
Posts: 4
Location: Israel
|
|
|
|
| Phrzby Phil wrote: |
The nice thing about the PL/I Optimizing Compiler was that source lines could be 100 characters long (obviously only useful with online source code). Byte 1 was for a comment "*", so the other 99 for code.
This allowed very deep indenting. |
I think there is something similar for COBOL, called "free format", but afaik it's only available for PC compilers, and this format never got popular, bc most of the COBOL codebase is following traditional "A, B areas" format.
P.S.
You made me curious now to find and to look at some COBOL project, which utilizes all the modern standard features, like OOP, bitwise operators, dynamic memory allocation, etc.
P.P.S.
Btw, I have spent about 2-3 intense hours before I figured out the item level issue, more than 20 recompiles, trying all kinds of mini-changes to the "problematic" lines, and then I've just took the whole structure into FILE-AID (option 8) and then I found it right away. FILE-AID forces its own formatting and has none of the compiler meta-data obviously, making it easier to drill the code.
 |
|
| Back to top |
|
|
|
|
