[open-cobol-list] Non-Standard Level Numbers (was: RCF - SC27-1408-03 - Enterprise COBOL LRM

[Bill Klein]

FYI,
  Here is the correspondence on what IBM is actually doing (and will now
document in their LRM) for "non-Standard level numbers".

NOTE:
  They do NOT "insert" a filler level, but instead (internally) renumber ALL
the levels.  (I can't - personally - think of much of a semantic difference,
but this does show up in the IBM "MAP" output) 

________________________________

To author of the COBOL LRM:

Please change the description of non-standard level numbers semantics in the
LRM.
Here is the reference:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr30/5.1.6.2 

Here is the text:

You can also define groups with subordinate items that have different
level-numbers for the same level in the hierarchy. The compiler renumbers
the levels
in a relative fashion, as can be seen in MAP output. For example, 05
EMPLOYEE-NAME
and 04 EMPLOYEE-ADDRESS in the following record description entry define the
same
level in the hierarchy:

01 EMPLOYEE-RECORD.
        05 EMPLOYEE-NAME.
                10 FIRST-NAME PICTURE X(10).
                10 LAST-NAME PICTURE X(10).
        04 EMPLOYEE-ADDRESS.
                08 STREET PICTURE X(10).
                08 CITY PICTURE X(10).

The following record description entry defines the same data hierarchy as
the
preceding record description entry:

01 EMPLOYEE-RECORD.
        02 EMPLOYEE-NAME.
                03 FIRST-NAME PICTURE X(10).
                03 LAST-NAME PICTURE X(10).
        02 EMPLOYEE-ADDRESS.
                03 STREET PICTURE X(10).
                03 CITY PICTURE X(10).




----- Forwarded by .../Santa Teresa/IBM on 01/24/2006 11:16 AM -----



        


                                "Bill Klein" <address@hidden> 

                                01/23/2006 09:30 PM

        


Bill,

Here is what the MAP output gives for your example:

94 1 EMPLOYEE-RECORD . . . . . BLF=00000 000 DS 0CL40 Group 
95 2 EMPLOYEE-NAME . . . . . BLF=00000 000 0 000 000 DS 0CL20 Group 
96 3 FIRST-NAME. . . . . . BLF=00000 000 0 000 000 DS 10C Display
97 3 LAST-NAME . . . . . . BLF=00000 00A 0 000 00A DS 10C Display
98 2 EMPLOYEE-ADDRESS. . . . BLF=00000 014 0 000 014 DS 0CL20 Group 
99 3 STREET. . . . . . . . BLF=00000 014 0 000 014 DS 10C Display
00 3 CITY. . . . . . . . . BLF=00000 01E 0 000 01E DS 10C Display 

Here is the corresponding source:

000094                01  EMPLOYEE-RECORD.                     
000095                    05  EMPLOYEE-NAME.                   
000096                        10  FIRST-NAME     PICTURE X(10).
000097                        10  LAST-NAME      PICTURE X(10).
000098                    04  EMPLOYEE-ADDRESS.                
000099                        05  STREET    PICTURE X(10).     
000100                        05  CITY      PICTURE X(10).    

So, it is not internal at all to tell what we really do!




Tom,
 You certainly COULD document it showing what you internally do.
However,
I am still unclear as to WHAT semantics problems using the "FILLER"
explanation would cause.  I thought about various combinations of
SYNC stuff
(implicit and explicit) and I still think that placing a "new"
Filler group
item above the first entry is how it works (from an external point
of view).
Can you provide me an example of how what you do (internally) works
any
differently than what would happen if a new FILLER item were
inserted?

As I don't have a compiler to "play with", what do you show in the
MAP
output for this type of structure?  I can imagine that this WOULD be
one
time that the "filler" explanation might not work, but I don't know
if the
renumbering one corresponds or not to what MAP shows.  If it does,
then that
is probably what you need to explain.


________________________________



Bill,

You have a point, your example makes our description insufficient. I
disagree
with your assertion of how the compiler behaves, because FILLER has
different
semantics from just changing the specified level-numbers. I am not
sure how 
best to word what we do, though, maybe you can help. What we do is
re-level
EVERYTHING in relative terms, so that what is subordinate to level 1
is always
Level 2. So, in your example:

Consider the following variation of the sample provided in the LRM:

    01   EMPLOYEE-RECORD.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
         04  EMPLOYEE-ADDRESS.
             05  STREET     PICTURE  X(10).
             05  CITY       PICTURE  X(10).

We need to explain to the user that this source code would be
treated 
as if it were coded:

    01   EMPLOYEE-RECORD.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
         05  EMPLOYEE-ADDRESS.
             10  STREET     PICTURE  X(10).
             10  CITY       PICTURE  X(10).

Or, to reveal our internals:

     01   EMPLOYEE-RECORD.
         02  EMPLOYEE-NAME.
             03  FIRST-NAME PICTURE  X(10).
             03  LAST-NAME  PICTURE  X(10).
         02  EMPLOYEE-ADDRESS.
             03  STREET     PICTURE  X(10).
             03  CITY       PICTURE  X(10).


So, we re-level the subordinate levels below EMPLOYEE-ADDRESS to 
correspond to the new level of EMPLOYEE-ADDRESS. So, should we
say we re-level everything in relative terms?

Thanks,
Tom 


"Bill Klein" <address@hidden>


01/22/2006 02:31 PM



To: Reader Comments/Silicon Valley/Contr/address@hidden



Title: Enterprise COBOL for z/OS V3.4 Language Reference
Document Number: SC27-1408-03
Build Date: 07/14/05 12:02:24

This is an RCF (Readers Comment Form) on the information at:



http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3lr30/5.1.6.2 

concerning non-Standard (IBM extension) level numbers which I
believe is
misleading at best and potentially wrong.

The documentation is CORRECT when it states,

"You can also define groups with subordinate items that have
different
level-numbers for the same level in the hierarchy."

However, as the LRM never tells exactly what happens when this is
coded, the
example *IMPLIES* (or I infer) that the 2nd occurrence of a
group/elementary
item using the "lower-number" level number is treated AS IF it were
coded
with the first (higher-level) number, e.g. in the example at this
page:

04  EMPLOYEE-ADDRESS.

is treated as if the programmer had coded

05  EMPLOYEE-ADDRESS. 

I maintain that this is NOT how the compiler works.  Rather, the
compiler
actually works as if

05  EMPLOYEE-NAME.

were immediately preceded by a source line of:

 04  Filler.

(i.e. as if it were a subordinate group under a group at the same
level as
the second item.)

   ***

How can one (an IBM user) determine which of these ways the compiler
is
working?

Consider the following variation of the sample provided in the LRM:

    01   EMPLOYEE-RECORD.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
         04  EMPLOYEE-ADDRESS.
             05  STREET     PICTURE  X(10).
             05  CITY       PICTURE  X(10).

Given the information currently provided in the LRM, a programmer
would
THINK that this source code would be treated as if it were coded:

    01   EMPLOYEE-RECORD.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
         05  EMPLOYEE-ADDRESS.
             05  STREET     PICTURE  X(10).
             05  CITY       PICTURE  X(10).

If that were true, then this code would receive a compiler error as 

 05  EMPLOYEE-ADDRESS.

would need to be treated as an elementary item with no PICTURE (or
USAGE)
clause because it is immediately followed by another 05-level item.

However, the compiler issues no such warning/error - and instead the
compiler treats the original code AS IF it were coded:

    01   EMPLOYEE-RECORD.
      04  Filler.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
      04  EMPLOYEE-ADDRESS.
             05  STREET     PICTURE  X(10).
             05  CITY       PICTURE  X(10).

 ***

Note:
 When/if this text is "corrected" and the actual IBM extension is
(well)
documented, then the text at:




http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR30/APPENDIX
1.1 

should also be reviewed - where it states,

"Specifying level numbers that are lower than other level numbers at
the
same hierarchical level in a data description entry."

Again, although this is correct, it doesn't actually tell what the
extension
DOES.

 ***

Final NOTE:
  There is one other problem (implication) with the current LRM
documentation - when/if IBM ever implements the '02 Standard.
Consider the
following "variation" on the original code:

    01   EMPLOYEE-RECORD.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
         04  EMPLOYEE-ADDRESS  Value "12345".
             05  STREET     PICTURE  X(02).
             05  CITY       PICTURE  X(03).

If the current documentation (implication) were correct, this code
would be
treated as if the programmer coded:

    01   EMPLOYEE-RECORD.
         05  EMPLOYEE-NAME.
             10  FIRST-NAME PICTURE  X(10).
             10  LAST-NAME  PICTURE  X(10).
         05  EMPLOYEE-ADDRESS  Value "12345".
             05  STREET     PICTURE  X(02).
             05  CITY       PICTURE  X(03).

Unlike with the '85 Standard, this is VALID (conforming) source code
with
the '02 Standard.  The reason is that when an alphanumeric literal
is coded
as a VALUE clause the picture clause is OPTIONAL for an elementary
item.
However, I would maintain that this '02 conforming "interpretation"
of the
original code is VERY different from what the (current) IBM compiler
does -
and from what "upward compatibility" would require IBM to do with
future
compilers.

 ***

P.S.  You may want to check the COBOL/400 documentation, for
comparable
problems issues - as I believe this extension exists there as well.