COBOL OCCURS DEPENDING ON Storage usage

[Rob Wunderlich]

A of my colleague has asked me a COBOL (not my langauge) question. He is
using the construct below. His objective is to minimize storage
requirements. My RFTM does not make it clear if the use of DEPENDING ON
actually results in less getmained storage (assuming LP-TOKEN-COUNT <
99999) than without using DEPENDING ON.

Does anyone know for sure how this works? Will storage for 99999 occurences
be established regardless of the value of LP-TOKEN-COUNT?

Thanks,
Rob

01 LP-TOKEN-BYTE-CODE.
05 LP-TOKEN-X.
10 LP-TOKEN-COUNT PIC S9(9) COMP VALUE 0.
10 LP-TOKEN-ENTRY OCCURS 0 TO 99999 TIMES
DEPENDING ON
LP-TOKEN-COUNT.
15 LP-TOKEN-TYPE PIC S9(2) COMP.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Ray Mullins]

Hey Rob,

Shades of Computax. :-)

Assuming this is in WORKING-STORAGE (or, what's the new one - LOCAL-STORAGE?
Mr. Klein?)...

Yes. COBOL will get the storage - and all the BLW cells to go with it - in
this case, (4 + 2 * 99999) = 200002 / 4096 = 49 BLW cells. And if there are
data items beyond this 01 level, there will be BLW-hoppin' like crazy, not
to mention code generated to handle the size changes if LP-TOKEN-COUNT is
changed.

You can learn a lot from the LIST option (was PMAP in the Jurassic age)
output, such as how the compiler handles OCCURS DEPENDING ON.

As an aside, OCCURS 0 works best with record definitions, otherwise use 1.

Also, if this is the only large data item in the COBOL program, it should be
the last thing in WORKING-STORAGE. In spite of all the advances in the
compiler over the years, it still makes sense to cluster heavily-referenced
data items near the beginning of WORKING-STORAGE.

Later,
Ray

(P.S. Off-line - let me know the next time you come through Roseville.)

--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/
http://www.the-bus-stops-here.org/



> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Rob Wunderlich
> Sent: Wednesday 11 May 2005 16:10
> To: IBM-***@BAMA.UA.EDU
> Subject: COBOL OCCURS DEPENDING ON Storage usage
>
> A of my colleague has asked me a COBOL (not my langauge)
> question. He is using the construct below. His objective is
> to minimize storage requirements. My RFTM does not make it
> clear if the use of DEPENDING ON actually results in less
> getmained storage (assuming LP-TOKEN-COUNT <
> 99999) than without using DEPENDING ON.
>
> Does anyone know for sure how this works? Will storage for
> 99999 occurences be established regardless of the value of
> LP-TOKEN-COUNT?
>
> Thanks,
> Rob
>
> 01 LP-TOKEN-BYTE-CODE.
> 05 LP-TOKEN-X.
> 10 LP-TOKEN-COUNT PIC S9(9) COMP VALUE 0.
> 10 LP-TOKEN-ENTRY OCCURS 0 TO 99999 TIMES
> DEPENDING ON
> LP-TOKEN-COUNT.
> 15 LP-TOKEN-TYPE PIC S9(2) COMP.
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Joe Zitzelberger]

The compiler will getmain enough storage for the largest possible item
size, in this case, the full 200k.

psychedelic-***@mindless.com

This tagline intentionally left blank.

On May 11, 2005, at 7:10 PM, Rob Wunderlich wrote:

> A of my colleague has asked me a COBOL (not my langauge) question. He
> is
> using the construct below. His objective is to minimize storage
> requirements. My RFTM does not make it clear if the use of DEPENDING ON
> actually results in less getmained storage (assuming LP-TOKEN-COUNT <
> 99999) than without using DEPENDING ON.
>
> Does anyone know for sure how this works? Will storage for 99999
> occurences
> be established regardless of the value of LP-TOKEN-COUNT?
>
> Thanks,
> Rob
>
> 01 LP-TOKEN-BYTE-CODE.
> 05 LP-TOKEN-X.
> 10 LP-TOKEN-COUNT PIC S9(9) COMP VALUE 0.
> 10 LP-TOKEN-ENTRY OCCURS 0 TO 99999 TIMES
> DEPENDING ON
> LP-TOKEN-COUNT.
> 15 LP-TOKEN-TYPE PIC S9(2) COMP.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[john gilmore]

Joe Ziyzelberger writes:

>The compiler will getmain enough storage for the largest possible item
>size, in this case, the full
>200k.

and this is quite correct if this storage is declared in the WORKING-STORAGE
section. If, as its name suggests, this is scratch storage, it is better
allocated in the LOCAL-STORAGE section, in which case it will come off of
the LE stack. The overheads will be much smaller if this is the case. (In
the terminology of other statement-level procedural languages, this
distinction is that between the storage classes static and auto[matic]).

In either case the allocation will be for the maximal amount of storage that
may ever be required.

If economizing on storage is important, then lists should be used instead.
(This is now entirely possible in the COBOL language, but it may not be
possible for the COBOL programmer who posed this question. Still, this may
be the apposite occasion for teaching him/her about such things.)

John Gilmore
Ashland, MA 01721
U.S.A.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Andrews]

Rob, have your colleague place the record definition in the LINKAGE
SECTION, then allocate whatever storage you need from the LE heap. The
following code (snipped and edited from a program we run here) ought to
give you a head start:

****
**** Feedback area for LE functions.
****

01 FC.
05 PIC X(8).
COPY CEEIGZCT SUPPRESS.
05 PIC X(4).

****
**** Parameters used when we call CEE3ABD, (ABEND).
**** - U0100 indicates that heap allocation failed,
**** - U0200 says that storage deallocation failed.
**** A cleanup code of 0 means to terminate immediately,
**** a value of 1 means to do normal enclave termination
**** processing first. I'm using the latter.
****

01 CEE3ABD-PARAMETERS.
05 U0100 COMP PIC S9(8) VALUE +0100.
05 U0200 COMP PIC S9(8) VALUE +0200.
05 CLEANUP-CODE COMP PIC S9(8) VALUE +1.


****
**** Parameters used in call to CEEGTST (storage allocation)
**** and CEEFRST (storage deallocation).
****

01 CEEGTST-CEEFRST-PARAMETERS.
05 HEAP-ID COMP PIC S9(8).
05 HEAP-LENGTH COMP PIC S9(8).
05 HEAP-ADDR POINTER.

**** Get some storage off the heap to hold your record.
**** If storage allocation fails, then abend U0100.
**** Establish addressability for your record in
**** linkage section.
****

MOVE [record length] TO HEAP-LENGTH.
MOVE 0 TO HEAP-ID.
CALL "CEEGTST" USING HEAP-ID, HEAP-LENGTH, HEAP-ADDR, FC.
IF NOT CEE000 THEN
CALL "CEE3ABD" USING U0100, CLEANUP-CODE
END-IF.
SET ADDRESS OF [record] TO HEAP-ADDR.

****
**** Deallocate heap storage, ABEND U0200 if unsuccessful.
****

CALL "CEEFRST" USING HEAP-ADDR, FC.
IF NOT CEE000 THEN
CALL "CEE3ABD" USING U0200, CLEANUP-CODE
END-IF.

--
David Andrews
A. Duda and Sons, Inc.
***@duda.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Bill Klein]

The other way to "minimize" storage is to use Linkage Section - and LE
services to "getmain" only the storage needed - and to then use the ODO
(Occurs Depending ON). Like the list suggestion, this may not be something
that the "average" COBOL application programmer wants to do - but it is
possible.

"john gilmore" <***@ibm-main.lst> wrote in message
news:<BAY104-***@phx.gbl>...
> Joe Ziyzelberger writes:
>
> >The compiler will getmain enough storage for the largest possible item
> >size, in this case, the full
> >200k.
>
> and this is quite correct if this storage is declared in the
WORKING-STORAGE
> section. If, as its name suggests, this is scratch storage, it is better
> allocated in the LOCAL-STORAGE section, in which case it will come off of
> the LE stack. The overheads will be much smaller if this is the case.
(In
> the terminology of other statement-level procedural languages, this
> distinction is that between the storage classes static and auto[matic]).
>
> In either case the allocation will be for the maximal amount of storage
that
> may ever be required.
>
> If economizing on storage is important, then lists should be used instead.

> (This is now entirely possible in the COBOL language, but it may not be
> possible for the COBOL programmer who posed this question. Still, this
may
> be the apposite occasion for teaching him/her about such things.)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Howard Brazee]

On 11-May-2005, ***@ibm-main.lst (Ray Mullins) wrote:

> Also, if this is the only large data item in the COBOL program, it should be
> the last thing in WORKING-STORAGE. In spite of all the advances in the
> compiler over the years, it still makes sense to cluster heavily-referenced
> data items near the beginning of WORKING-STORAGE.

Why?

(I've done this with interpreted languages, but not with compiled languages).

[Harold Zbiegien]

If it is a batch program don't worry about 200k, its 2005 not 1980, If it's
not referenced then the pages it occupies is not paged in.

What is not said is how often does LP-TOKEN-COUNT change. Is it set once
for the life of the program? or does it change for every transaction/record
read. And how often is the table referenced. If you allocate memory and
then free it every time you read a record then the overhead may out weigh
the few extra bytes you use. I'd be more worried about how he is using this
table, SEARCH verb, subscriptiing? what does the subscript look like.
Sometimes the code that is generated for a "variable" length table is poor
and it almost is better to define the table as a fixed lenght table and
populate the table with a value that will naturally terminate a SEARCH.

Just some more thoughts
----- Original Message -----
From: "Rob Wunderlich" <***@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-***@BAMA.UA.EDU>
Sent: Wednesday, May 11, 2005 7:10 PM
Subject: COBOL OCCURS DEPENDING ON Storage usage


> A of my colleague has asked me a COBOL (not my langauge) question. He is
> using the construct below. His objective is to minimize storage
> requirements. My RFTM does not make it clear if the use of DEPENDING ON
> actually results in less getmained storage (assuming LP-TOKEN-COUNT <
> 99999) than without using DEPENDING ON.
>
> Does anyone know for sure how this works? Will storage for 99999
occurences
> be established regardless of the value of LP-TOKEN-COUNT?
>
> Thanks,
> Rob
>
> 01 LP-TOKEN-BYTE-CODE.
> 05 LP-TOKEN-X.
> 10 LP-TOKEN-COUNT PIC S9(9) COMP VALUE 0.
> 10 LP-TOKEN-ENTRY OCCURS 0 TO 99999 TIMES
> DEPENDING ON
> LP-TOKEN-COUNT.
> 15 LP-TOKEN-TYPE PIC S9(2) COMP.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html