I question your logic with regard to BUFNI. If the access pattern is truely dynamic, then the ideal would be to have space for the index sets and all of the sequence sets, so that it never reads an index CI more than once. I have done this on many occasions to save huge amounts of time.
>>> David Speake <[email protected]> 3/2/2009 6:28 PM >>> I have a customer with what they perceive as a memory problem, Reviewing their JCL I feel otherwise. There are some VSAM BLSR values that I seriously question. I have written a response but am now having insecurity issues - its been a while and although "VSAM Demystified" and "DFSMS Using Data Sets" seem to confirm most of my material, I'd sure like to see a z/OS R1.9 VSAM PLM for a few hours. I have my beach towel handy in case the egg on my face get real deep. Comments and pointers appreciated. Cut/Paste 90 XXH99NMODF DD SUBSYS=('BLSR','DDNAME=BLSRMODF', *MOD FILE * XX 'BUFSI=4096,BUFSD=8192', CISIZES --------------1536 ------4096 DATA CI/CA----------------180 KEYLEN---------------------14 XX 'BUFNI=7972,BUFND=272', XX 'RMODE31=ALL','MSG=I', XX 'SHRPOOL=01') 91 XXBLSRMODF DD DSN=&V1..HBBMA.YW&PL.MODS, * MODIFIER FILE * XX DISP=(SHR,KEEP,KEEP) IEFC653I SUBSTITUTION JCL - [email protected],DISP=( 92 XXH99NPFLG DD SUBSYS=('BLSR','DDNAME=BLSRPFLG', *PFLG FILE * XX 'BUFSI=4096,BUFSD=8192', CISIZES --------------1536 ------4096 DATA CI/CA----------------180 KEYLEN-----------------8 XX 'BUFNI=4070,BUFND=532', XX 'RMODE31=ALL','MSG=I', XX 'SHRPOOL=01') 93 XXBLSRPFLG DD DSN=&V1..HBBMA.MW&PL.PFLG&NODE, *PROC STUB FILE* XX DISP=(SHR,KEEP,KEEP) IEFC653I SUBSTITUTION JCL - [email protected],DISP=( Note that the JCL above is TEST and that the files are small but the values are intended for PROD volumes. Since the two data sets are the only ones that have SHRPOOL=01 we consider them together as a start. All the others default to SHRPOOL=0. As they are both have INDEX ----1536 and DATA ---4096 CISIZES, I do not understand the use of 'BUFSI=4096,BUFSD=8192'. It would seem that (4096 - 1536) = 2560 bytes = 62% of each INDEX and (8192 - 4096) = 4096 bytes = 50% of each DATA buffer is unusable and thus a total waste. Assuming that the BUFNI/BUFND requests for each SHRPOOL are cumulative BUFNI=7972 and BUFNI=4070 together request 12038 buffers for the INDEX SET, plus ONE SEQUENCE SET CI and ONE reserved CI for splits, even if the data set is opened INPUT. Note that the INDEX is composed of two distinct logical components,1) the SEQUENCE SET which has exactly one CI for each data component CA, and 2) the INDEX SET. To the best of my knowledge it is useless to allocate more BUFNI than the number of buffers required to hold the INDEX SET plus the 2 mentioned above. This is EXPLICITLY affirmed in the documentation for NSR and nowhere, that I can find, contradicted for LSR. This much BUFNI would allow a DATA component of a bit more than 2 million 166 thousand cylinders or 66+ M27 volumes for the two files and still keep the entire INDEX SET for both files in main storage. If they are NOT cumulative then the figure drops to about 67 * .66 = 44 or so M27 volumes. In either case I'd have to see it (the files) to believe it. Even by today's standards this is HUGE volume. Be back at my desk about 10:00 Tuesday ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
