|
View previous topic :: View next topic
|
| Author |
Message |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
The maximum length of earlier COBOL (COBOL2, COBOL/370) for an "01" level LINKAGE SECTION item is 16777215.
Subtracting the length of the ODO fullword (of four), leaves 16777211.
I was demonstrating when you define the "01" level with a length of 16777215 or below, you won't ever have to change it.
However, this was only an example and doesn't really portray real life (at least, I hope not).
In more current COBOL, the maximum length of an "01" level LINKAGE item is much higher (if I'm not mistaken).
Bill |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| What troubles me is that post-compile cobol binary depends on included copybooks. |
Actually, no it does not. The load module is complete and stands alone without reference to the source code -- although dynamic calls may require a run-time load module library to be accessed. If you ever need to recompile the module, THEN you need the copybooks. As long as your site can keep track of the the copybooks, there's no reason to not have the ODO table in a copybook that I can think of. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
Sorry Robert, I split that post from this thread, obviously as you were busy typing away.
Oh well, c'est la vie  |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| arun nehra wrote: |
| Actually the second file referred above contains Approx 40 Million records. And i need to compare each of that record with input (usually 1500-2000 in number) file |
| arun nehra wrote: |
| i need to compare all records of File A (1500-2000 records) with each record of File B (40 M records) and update File B if there is match found. |
Hold your horses !!!!!!!!!
Why on earth do you need to keep the whole file in memory ???
Do you really plan to read all 40 M records and search each record in the table ???
I strongly suggest we stop talking about ODO and start doing some serious thinking...
To think correctly, we need at least two more things:
You didn't told us which kind of file is your "40 M records" file,
And how do you (plan to) update it with the new data? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Marso,
| Quote: |
| Why on earth do you need to keep the whole file in memory ??? |
Because that is the easiest way to write the code. . .
d |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
marso,
the TS wants to table the 1500-2000 record in memory.
that in itself is not to bad.
this thread became very lengthy because the TS wanted to beable to potentially hold 100,000 records in memory.
then we took off on ODO vs Fixed internal cobol tables and then whether to use working-storage or dynamically access storage via LE routines.
etc.........
all we get out of the TS is BS questions and no answers.
The TS has avoided providing anything remotely associated with enough info to suggest a good design.
The TS wants and internal COBOL table and screw us and our ideas about better design.
Have fun. |
|
| Back to top |
|
|
wimpey
New User
Joined: 03 Jun 2021
Posts: 2
Location: Netherlands
|
|
|
|
| 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). |
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.
Gretes, Willem |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3051
Location: NYC,USA
|
|
|
|
wimpey, Welcome!
Please start a new post and refer this post in that fi you would like instead of tailgating old topics. |
|
| Back to top |
|
|
|
|
