MVSFORUMS.com

hellohatim · Beginner Joined: 12 Apr 2007 Posts: 28 Topics: 7

Hi,

We have a job which was recently changed in production. One step has contributed to significant increase in I-O as well as CPU consumption. This step before changes had 3 KSDS files, to which one more KSDS was added (ZIPSMSA file). These KSDS were created inline in JCL itself w/o using DEFINE IDCAMS.

The read/write counts of various files is as follows:

After changes

hellohatim · Beginner Joined: 12 Apr 2007 Posts: 28 Topics: 7

I forgot to add a few more statictics for this step.

After

dbzTHEdinosauer · Posted: Tue Aug 07, 2007 11:40 pm Post subject:

just guessing, but before the addition of the file, your job parms were tuned to allocate the necessary resources to run the job. you added a new file, did you change your job parms? or add any to increase what is provided by default at your installation?
_________________
Dick Brenholtz
American living in Varel, Germany

blitz2 · Beginner Joined: 23 Jan 2007 Posts: 84 Topics: 14

Bill Dennis · Posted: Wed Aug 08, 2007 8:06 am Post subject:

The CPU time more than doubled and the I/O counts (EXCP) more than doubled! You need to understand how the new file affected the program logic path.

FYI,
VIO is a method of allocating active, temporary (usually small!) files in memory instead of on DASD. This reduces elapsed time usually spent waiting for DASD I/O. There is usually a special name, such as UNIT=VIO, to get this or SMS may be doing it for you.
_________________
Regards,
Bill Dennis

Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.

jsharon1248 · Posted: Wed Aug 08, 2007 3:24 pm Post subject:

I always suspect CI and CA splits when performance problems creep into VSAM applications. It's been a while since I worked with VSAM, but I think you can get the CI/CA split counts from a LISTCAT. Also, you might benefit from adding BUFNI and BUFND parms to the JCL.

vak255 · Intermediate Joined: 10 Sep 2004 Posts: 384 Topics: 79

Some tips from Optimization Manual:

When using VSAM files, increase the number of data buffers (BUFND) for sequential access or index
buffers (BUFNI) for random access. Also, select a control interval size (CISZ) that is appropriate for the
application. A smaller CISZ results in faster retrieval for random processing at the expense of inserts,
whereas a larger CISZ is more efficient for sequential processing. In general, using large CI and buffer space
VSAM parameters may help to improve the performance of the application.
In general, sequential access is the most efficient, dynamic access the next, and random access is the least
| efficient. However, for relative record VSAM (ORGANIZATION IS RELATIVE), using ACCESS IS
| DYNAMIC when reading each record in a random order can be slower than using ACCESS IS RANDOM,
| since VSAM may prefetch multiple tracks of data when using ACCESS IS DYNAMIC. ACCESS IS
| DYNAMIC is optimal when reading one record in a random order and then reading several subsequent
| records sequentially.
Random access results in an increase in I/O activity because VSAM must access the index for each request.
If you use alternate indexes, it is more efficient to use the Access Method Services to build them than to use
the AIXBLD run-time option. Avoid using multiple alternate indexes when possible since updates will have
to be applied through the primary paths and reflected through the multiple alternate paths.
| VSAM buffers can be allocated above the 16 MB line if all of the following are true:
| the programs are compiled with VS COBOL II Release 3.0 or higher, COBOL/370 Release 1.0 or
| higher, or IBM COBOL for MVS & VM Release 2.0 or higher
| the programs are running with LE/370 Release 3.0 or higher, or IBM Language Environment for MVS
| & VM Release 5.0 or higher

hellohatim · Beginner Joined: 12 Apr 2007 Posts: 28 Topics: 7

Hello Everyone,

Thanks for all your replies. I will add some more information here.

I had defined KSDS inside the JCL itself like this...

dbzTHEdinosauer · Posted: Thu Aug 09, 2007 2:52 am Post subject:

zip file is 18 x 100000 - that only 1,800,000; Cobol table can hold that. create one module that you call, that only contains the table and logic (1) to load at beging of job, (2) do a search all to replace the random read.

either that or create the zip ksds so that the ordering is the same as the acess. Unless the ksds zip file is being accessed seq (albeit dynamic) prefetch will never have enough in memory to preclude physical i/o.
_________________
Dick Brenholtz
American living in Varel, Germany

blitz2 · Beginner Joined: 23 Jan 2007 Posts: 84 Topics: 14

There are only 99999 records in the file but the statistics indicate 6921105 reads. Dbz's approach is one solution. Another may be to load the cobol table dynamically as you read from the file i.e. Search the cobol table first and then do a random read if there is no row in cobol table. Populate the cobol table whenever you read the file. I'm sure atleast the number of reads will reduce drastically... If you try it out, please post the findings.
________
Lamborghini Lma002 Specifications

dbzTHEdinosauer · Posted: Thu Aug 09, 2007 6:57 am Post subject:

blitz2,

loading the table dynamically means an unordered table, which defeats the SEARCH ALL.
_________________
Dick Brenholtz
American living in Varel, Germany

Terry_Heinze · Posted: Thu Aug 09, 2007 9:25 am Post subject:

If a large percentage of your reads are going after a previously unread record, I'd go with Dick's suggession. If you find that you are reading the same record many times throughout the execution of your program, I'd go with blitz2's. I've used both methods and a lot depends on how often you end up rereading the same record. In my case it was a DB2 table that was being read, but the same idea holds true for a VSAM file. As Dick mentioned, the 2nd method precludes the use of a binary search.
_________________
....Terry

blitz2 · Beginner Joined: 23 Jan 2007 Posts: 84 Topics: 14

yes, with a dynamic load, binary search would not work but a serial search would... final goal being to reduce I/O operations.
________
MONTANA MEDICAL MARIJUANA DISPENSARY

jsharon1248 · Posted: Thu Aug 09, 2007 9:55 am Post subject:

I'm thinking that the KSDS access should not create a performance issue. If you can apply changes to the code, store the record read from the KSDS file in WS. When you need to read again, check to see if the record is already in WS. This alone could reduce the number of total reads required.

Also, I'd try a smaller CI size. 4096 will store 150+ records. If your access is truly random, you're move 150+ records to the buffer to get the one you want. Try something like 1024 or 512. One more thing is to increase the BUFNI and BUFND. I don't remember the exact formulas, but I think the defaults are too low.

dbzTHEdinosauer · Posted: Thu Aug 09, 2007 10:16 am Post subject:

These files possibly need to be tuned for more than 1 process: Random and Sequential. Tuning for 1 type precludes optimum tuning for the second.

There are 3 other files:
PLANIND
TM
ZIPDMA
that are only read. if the files are also capable of being loaded into separate cobol modules (3), the binary search in memory will beat I/O any day of the week, regardless of the vsam restructuring.

OP needs to sit down and detemine all of his requirements. VSAM structuring for one type of process and program redesign (tabling) for another.
_________________
Dick Brenholtz
American living in Varel, Germany