Fastest VSAM Logic

Post your questions related to VSAM

Moderator: Moderator Group

Post Reply
chris d
Member
Posts: 3
Joined: Fri Apr 22, 2011 6:32 am

Fastest VSAM Logic

Post by chris d » Fri Apr 22, 2011 7:03 am

Hi,

I have to search a vsam file. Could be a partial or full key. Problem is I have 16 million input records and currently 10 vsam records to search. Customer wants vsam for added flexibility as search records grow. Ugh. This search is part of a much bigger cobol module that already takes 5 hours to run and must remain as part of the module.

There are 12 fields to the key but many times all it will take are 2 fields as a partial key to get a hit. Occasionally, all fields will be required for a hit.

I figure I have 2 options (that I can think of):

1. Prime the key and search the vsam file for every record.

2. At startup, load the high qualifiers of the vsam keys into a ws-table and then do a binary search on that partial key against the ws-table (for many records, thats all it will take to get a hit). If I get a hit THEN prime the key and search the vsam. Seems like double work, but with 16 million records to process and currently only 10 possible hits, I'm trying to minimize processing time.

So question: Is it faster to do a binary search against the working storage table or just do a search all on the vsam every time?

Thanks for any advice.

chris d
Member
Posts: 3
Joined: Fri Apr 22, 2011 6:32 am

Post by chris d » Fri Apr 22, 2011 7:33 am

A quick clarification. Just realized I wrote 'search' vsam, but I mean read. Still thinking in terms of flat file.

User avatar
dbzTHEdinosauer
Moderator
Posts: 981
Joined: Mon Oct 02, 2006 8:31 pm

Post by dbzTHEdinosauer » Sat Apr 23, 2011 12:12 am

are you asking which process has the least amount of CPU usage:
  1. bouncing a register up and down local COBOL memory
  2. Suspending your program multiple times while requesting the API/I-O service routine
    1. yet another task is started within the system
    2. cpu resources are expended starting and maintaining the new task
    3. the new task also requires services
    4. that require new services
    5. ...
By the way, on a mainframe you read and do not search a "flat file" (QSAM?)

been sitting here thinking:

use DFSORT JOINKEYS (syncsort also has JOINKEYS)
  1. repro the vsam file to qsam
  2. use JOINKEYS to reformat for ouptut
never have to worry about file growth
never have to worry about efficiency - a sort can read a qsam file (60,000,000 requests?) much faster that a COBOL program.

If you are not allowed to right a JOINKEYs application
  1. repro the vsam to qsam
  2. your cobol program
    • reads the sorted 60,000,000 requests
    • reads the the qsam version of the vsam file
does a simple match-of-two-files with your cobol program.

I would BUFNO the DD Statements for the two QSAM files
Last edited by dbzTHEdinosauer on Sat Apr 23, 2011 12:56 am, edited 2 times in total.
Dick Brenholtz
JCL, SQL and code in programs have an irritating habit of doing what you say,
not what you meant.

chris d
Member
Posts: 3
Joined: Fri Apr 22, 2011 6:32 am

Post by chris d » Sat Apr 23, 2011 12:48 am

It actually would be a search because the flat file would be loaded into a table upon open.
Yeah, as I thought about it, it made sense that I/O would cause more process time. But, now specs have changed anyway. Whoopee!

Thanks for the advice tho.

Post Reply

FREE TUTORIALS

Tutorials
Free tutorials from mainframegurukul
  • JCL Tutorial
    Covers all important JCL concepts.
  • Cobol Tutorial
    This tutorials covers all Cobol Topics from STRING to COMP-3.
  • DB2 Tutorial
    DB2 Tutorial focuses on DB2 COBOL Programming.
  • SORT Tutorial
    This Tutorial covers all important aspects of DFSORT with examples
  • CICS Tutorial
    This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions



Other References
Mainframe Tools and others