|
View previous topic :: View next topic
|
| Author |
Message |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
If your second file is sorted on the same key/keys as the first,
before you perform a search, you should check if the last found is equal to the new record-2.
but,
again,
if both files are sorted the same (no reason not to be),
then you can accomplish the requirement with a simple match of two files
and not have to deal with the problem of table overflow due to a very large number of file 1 records. |
|
| Back to top |
|
 |
arun nehra
New User
.jpg)
Joined: 29 Nov 2008
Posts: 62
Location: mumbai
|
|
|
|
Hi Bill,
In my case normally no of records remains more then 128 and i guess i can go with the one you have suggested above. Also I went through one of your old post where you had mentioned SYNTAX for the array declaration; but that was for a CICS program.
www.ibmmainframes.com/about43934.html
I need it for my program which is a normal COBOL module. Thanks in advance. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Arun Nehra wrote: |
| I need it for my program which is a normal COBOL module |
and the difference in syntax of an ARRAY in a CICS Cobol module and a normal
(what would be an abnormal COBOL module?)
COBOL module would be what? |
|
| Back to top |
|
|
arun nehra
New User
Joined: 29 Nov 2008
Posts: 62
Location: mumbai
|
|
|
|
Specifically:
what will be the equivalent of below code in cobol for getting space from main.
EXEC CICS GETMAIN
SET (WS-DYNAMIC-POINTER)
FLENGTH(WS-DYNAMIC-FLENGTH)
INITIMG(WS-DYNAMIC-INITIMG)
NOHANDLE
END-EXEC.
IF EIBRESP NOT = DFHRESP(NORMAL)
PERFORM GETMAIN-ERROR-RTN
GO TO END-OF-PROGRAM
END-IF.
SET ADDRESS OF LS-DYNAMIC-TABLE-REC TO WS-DYNAMIC-POINTER.
MOVE WS-DYNAMIC-NBR-RECS TO LS-DYNAMIC-NBR-RECS.
and also the size of linkage section variable
LS-DYNAMIC-REC PIC X(16777211).
as there was some confusion on this at that time. Thus what will be exact value i need to assign, (i remember it was 128 M) but what will be the exact figure similar to the one Bill has mentioned in above case. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
I realize that you don't like reading my posts,
as I tend to force people to think about things,
and to stop with their own preconceived notions about how to do things.
As well as the fact that your question was about syntax with respect to defining an ARRAY,
not about acquisition of storage:
LE Dynamic storage callable services
some other links that my be helpful:
LE Overview
All LE Documents
still did not answer the question about abnormal COBOL. |
|
| Back to top |
|
|
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: 8697
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: 3053
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 |
|
|
|
|
