Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
After reviewing VSAM Demystified, you should understand how an optimized CISZ (which blossoms into a CA) and its relationship with the RECSZ and FSPC, is something that must be taken into serious consideration. Bad VSAM components/definitions can have adverse effects for both CICS and Batch.
Many times, I'll find programmers who just copy an existing VSAM DELETE/DEFINE and then modify the RECSZ, CISZ, FSPC, etc.
This is all well and good, providing that a review of these components will fit well with this new (or existing) DEFINE.
But, if it's just a COPY and little review is done, you could be perpetuating bad DEFINE's and cause an uninvited (and perhaps, continued) ripple effect across the system.
Joined: 06 Jun 2008 Posts: 8165 Location: East Dubuque, Illinois, USA
To add to dick and bill's comment, it is not at all clear what you mean. Are you referring to an increase in the CI size? an increase in the number of CI's allocated? an increase in the number of CI's used? something else -- if so, what?
What do you mean by "performance" -- CPU time used, I/O counts, CI splits, CA splits, elapsed time of the job, or something else entirely? Performance impacts can be very different for batch and online applications using VSAM files so that would also be a factor in any answer we could give you. Not to mention whether or not the file is LSR or NSR, the access pattern (sequential, skip sequential, or random), buffer allocation, and so forth. There are many factors that can affect 'performance" so the first step is usually to determine what performance means in a given context.