In COBOL, 01 level takes more memory?

[ajinkya123]

Hi,

One of my colleague said that he has heard that 01 level in Cobol takes more memory and hence arrays cant be declared in 01 level. I am not convinced by this but I could not also find a reference to prove that it is not this way. But then how exactly it is? How internally Cobol stores all these levels information?

[Robert Sample]

An 01 level takes no more memory than any other level. The reason arrays cannot be declared at the 01 level is that COBOL requires each variable be able to be uniquely defined and an 01-level array violates that requirement. Variables (other than 01 level) in COBOL can have the same name and still be referenced AS LONG AS there is a unique variable name at a lower level number to uniquely qualify the variable -- DUP-VAR IN UNIQUE-VAR is the way it is referenced.

Internally, COBOL doesn't really store level information -- it uses the level information to organize variable in memory. If your program gets a dump, you won't find the level numbers in the dump (unless you have Abend-Aid providing the COBOL variable structure, in which case you're not really using a pure memory dump).

[William Collins]

In the past, an 01-level would always be allocated storage in multiples of eight bytes (a double-word). If your 01 was not a multiple of eight, there would be one to seven "slack bytes" following the last byte of your data.

In the past, a 77-level only defined the actual storage which was needed (subject to SYNC). So eight PIC X fields defined as 77s would take eight (consecutive) bytes of storage, and the equivalent 01-levels would have eight bytes of storage, intersperse and succeeded each by seven slack-bytes. So 64 bytes in total.

There days, with Enterprise COBOL, there is no difference in how 77s or 01s are allocated, they are both allocated how 01s used to be allocated.

So, it used to be true that an 01-level could require more storage than the length of the field but a 77 (except for SYNC) would not.

It is no longer true.

[ApexNC]

So, what exactly is the answer to the question?
"In the past..." and "These days" aren't compiler specifications.
Given the following, which takes more memory?

Code: Select all

______ (A) ________ | _______ (B) ___

01 FILLER PIC X. __ | __ 01 FILLER.
01 A PIC X. _______ | _____ 05 A PIC X. 
01 B PIC X. _______ | _____ 05 B PIC X.
01 C PIC X. _______ | _____ 05 C PIC X. 
01 D PIC X. _______ | _____ 05 D PIC X. 
01 E PIC X. _______ | _____ 05 E PIC X.
01 F PIC X. _______ | _____ 05 F PIC X.
01 G PIC X. _______ | _____ 05 G PIC X. 

The answer is (A) and this behavior has been consistent since the days of IEQCBL00.

[Akatsukami]

Of course; the first example specifies eight fields of one byte each, whilst the second specifies only seven.

[William Collins]

Seven 77's of PIC X used to take less space than your seven 05s, because you have one slack byte :-) Now they take the same amount of space as seven 01-levels of PIC X (56 bytes).

The question is also making a link between storage used by 77- and 01-levels and tables (OCCURS), which makes no sense because neither a 77 nor an 01 can have OCCURS.

So, an 01-level does not take more space than a 77-level. Neither can have an OCCURS.

[ApexNC]

the first example specifies eight fields of one byte each, whilst the second specifies only seven.

OK, I'll make the case a bit more clear:

Code: Select all

01 A PIC X. 
01 B. 
   05 FILLER PIC X(7). 

Now, which takes more memory, "A" or "B"? The answer is "A" and it's been that way since at least 1965. I assume "IBM mainframes" means System/360 and above?

I realize the OP mentioned arrays, but I think it's best to consider the occurs issue separately from the "takes more memory" issue, which arises from 01 levels being doubleword aligned (hence causing "slack bytes"). By itself, the occurs issue doesn't make it impossible to define a data array using
01 Levels. Consider the following 3-element array:

Code: Select all

WORKING-STORAGE SECTION.
01 A PIC X.
01 B PIC X.
01 C PIC X.
LINKAGE SECTION.
01 TABLE-NAME.
   05 TABLE-ELEMENT OCCURS 3. 
     10 TABLE-DATA PIC X.
     10 FILLER PIC X(7). 
PROCEDURE DIVISION.
SET ADDRESS OF TABLE-NAME to ADDRESS OF A.

Now TABLE-DATA(1), TABLE-DATA(2) and TABLE-DATA(3) all correctly address the values in A, B, and C.
It'll work, although course it's not the best way to do it.

The OPs question itself is not well worded. He writes: "... 01 level in Cobol takes more memory ..." But, "more memory" than what, exactly? Exactly what the 01 level is being compared to is a *huge* and crucial fact missing from his statement:

Does 01 A PIC X(8) take "more memory" than 05 A PIC X(8)? No.
Does 01 A PIC X(8) take "more memory" than 05 A PIC X(16)? No.
Does 01 A PIC X take "more memory" than 05 A PIC X? Definitely, Yes!

And how exactly did level 77s come into the discussion? :-)

[William Collins]

More memory than 77s. I don't see anything else which makes much sense. An 01 takes more (or less) memory than another 01? Certainly possible, even wildly common.

Also, for fun:

Code: Select all

LINKAGE SECTION.
01  A PIC X.
01  B.
    05  FILLER PIC X(7).

Which "takes more memory" now?

[ApexNC]

CODE: SELECT ALL
LINKAGE SECTION.
01  A PIC X.
01  B.
    05  FILLER PIC X(7).

Indeed, putting the definitions in the LINKAGE SECTION means no memory is "taken" at all!
It occurs to me there are even ambiguities in the meaning of "taking memory" which can cause much confusion here.
It could be argued that "01 A PIC X." only "takes" one byte, since that's how much data it actually describes, and thus no different from "05 A PIC X."
But that ignores the slack bytes caused by doubleword alignment of an 01 Level item.
So, in that sense, if we code "01 A PIC X." after *anything* which isn't aligned on a doubleword boundary, it doesn't really "take more memory" so much as it "gives more memory" to the variable preceding it!

Thus I strive to be as precise and concise as possible with my statements in fora like this, so as to avoid such confusion.