View previous topic :: View next topic
|
Author |
Message |
harry143
New User
Joined: 05 Nov 2007 Posts: 21 Location: hyd
|
|
|
|
Hi,
Please see the below two points:
1) Random search in a VSAM File
2) Storing the VSAM file in an occurs table and Searching in it with the matching fields using perform statement.
Can any body suggest which one is the best when coming to performance issue??
I have a large amount of records to be searched. |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
It would depend. How many times are you going to be searching the table, how big would the table be, does the vsam file have a key to use for the search? |
|
Back to top |
|
|
harry143
New User
Joined: 05 Nov 2007 Posts: 21 Location: hyd
|
|
|
|
Craq Giegerich wrote: |
It would depend. How many times are you going to be searching the table, how big would the table be, does the vsam file have a key to use for the search? |
The table would be an occurs of 3000.
Yes the VSAm file has the key to search.
for each record nearly two to three times i have to serach. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
If there's someone in your shop that writes Assembler, you could call an Assembler sub-program (which issues a SHOWCB Macro) and it can return the number of records and (if needed) the LRECL of the target VSAM file which you want to load into memory.
Then, you can define your table in LINKAGE, with an OCCURS DEPENDING ON and acquire dynamic storage via the LE Callable Service routine "CEEGTST" or an Assembler sub-program which issues an MVS "GETMAIN".
By doing it this way, you won't have to worry about defining an OCCURS table in WS, which could spill over at 3:00am, causing someone to increase the OCCURS, re-compile the program and cross their fingers.
However, if it spills over once, it will spill over again.
Murphy is alive and well ya know.
HTH....
Regards,
Bill |
|
Back to top |
|
|
|