wimpey
New User
Joined: 03 Jun 2021
Posts: 2
Location: Netherlands
|
|
|
|
Copied from thread "Varying array length dynamically in the cobol program":
| Quote: |
Bill O'Boyle wrote:
Only an ARRAY in LINKAGE is a true ODO. If you define this ARRAY as an ODO 1 to 3000 and you determine you only have 100 entries, then only the actual storage will be allocated.
Example: (100 * entry-length) + 4. The four is the binary-fullword (this is my own preference) that contains the high-water mark for the ODO (a value of 100). |
| Quote: |
What you wrote here (ages ago, but I just bumped into it thru a google search...) is strongly related to what's puzzling me.
To use your example: if your Cobol PGM is called (by e.g. a Java-service) and contains an "input" internal table in LINKAGE with ODO 1 to 3000, the calling service might be able to determine you only need 100 instead of 3000.
Hence, calling service passes on the value of 100 and the Cobol PGM is provided with the info it needs to construct an internal table of 100 instead of 3000.
Had an issue with nested occurs within internal table causing havoc and using ODO resulted in significant improvement of performance. Happy.
However: if your Cobol PGM is called and contains an "output" internal table in LINKAGE with OCCURS 1 to 3000 DEPENDING ON IN1 (defined as PIC S9(9) BINARY)...
Upon execution, I see an internal table of 3000 being constructed. To stick with your example: run of Cobol PGM results in 100 entries (as "output") only.
My question would be:
is there any way - within my Cobol PGM - to use my "output" internal table (in LINKAGE) in a dynamical way? Hence: run the PGM, determine we need 100 instead of 3000 and construct the "output" internal table accordingly?
I hoped I've phrased the issue correctly and understandably. Thanks in advance for any feedback.
Greetings, Willem |
Any feedback reg. this issue'd be highly appreciated!
|
|
