IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Varying array length dynamically in the cobol program


IBM Mainframe Forums -> COBOL Programming
Post new topic   This topic is locked: you cannot edit posts or make replies.
View previous topic :: View next topic  
Author Message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

PostPosted: Wed Mar 31, 2010 10:31 pm
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8584
Location: Dubuque, Iowa, USA

PostPosted: Wed Apr 07, 2010 8:09 pm
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Wed Apr 07, 2010 8:12 pm
Reply with quote

Sorry Robert, I split that post from this thread, obviously as you were busy typing away.

Oh well, c'est la vie icon_sad.gif
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1349
Location: Israel

PostPosted: Wed Apr 07, 2010 11:38 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19245
Location: Inside the Matrix

PostPosted: Wed Apr 07, 2010 11:49 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6967
Location: porcelain throne

PostPosted: Thu Apr 08, 2010 12:09 am
Reply with quote

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
View user's profile Send private message
wimpey

New User


Joined: 03 Jun 2021
Posts: 2
Location: Netherlands

PostPosted: Thu Jun 03, 2021 7:20 pm
Reply with 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).


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
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 2772
Location: NYC,USA

PostPosted: Thu Jun 03, 2021 9:15 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   This topic is locked: you cannot edit posts or make replies. View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming Goto page Previous  1, 2

 


Similar Topics
Topic Forum Replies
No new posts how to convert and use 1 bit hex-numb... COBOL Programming 10
No new posts VB file copy COBOL program gives erro... COBOL Programming 3
No new posts Cobol program to determine the sequen... COBOL Programming 2
No new posts COBOL 6.2 vs 6.3 COBOL Programming 1
This topic is locked: you cannot edit posts or make replies. COBOL-Common routine that contains al... COBOL Programming 4
Search our Forums:

Back to Top