Re: VSAM BLSR
On Tue, 3 Mar 2009 16:22:50 -0500 Scott Rowe wrote >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. You may be right on this. I am primarily a COBOL individual and am thinking in NSR terms as in the following from VSAM Demystified page 75 on NSR Then, for optimum performance, the number of index buffers should at least equal the number of high-level index set CIs plus one per string. This makes the entire high-level index set and one sequence set CI per string in virtual storage. Table 2-6 shows how adding index buffers improves performance. The elapsed time can vary according to the system workload. Note that additional index buffers are not use(sic) for more than one sequence set buffer per string. But I don't find anything in LSR (or BLSR or SMB for that matter) that specifically says that it will load more than one sequence set CI per string. The application uses an ALC subroutine and neither I nor my customer ( one outfit writes it, we beta it, and someone else uses it in production) have the source to any of it. I am trying to dig through the dump but cannot seem to find the VSAM Control Blocks info that I think used to be in DFSMS Using Data Sets. A pointer to same would be VERY much appreciated, I like to dig . If any of the VSAM Demystified authors are listening, page 235 at the end of Table 4-3 VSAM Data Set Parameters and Processing Options would be a LOVELY place for such a reference pointersigh! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
If possible, convert the file to extended format and use system managed buffering (covered in VSAM Demystified). It's easier to implement than BLSR. It will probably use more memory than BLSR, but that can be controlled easily if necessary. I've had great results with it. The programmers of the first application I tried it on were so happy they bought me a fruit basket for Christmas. ;-) db -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Farley, Peter x23353 Sent: Monday, March 02, 2009 6:53 PM To: IBM-MAIN@bama.ua.edu Subject: Re: VSAM BLSR > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of David Speake > Sent: Monday, March 02, 2009 6:29 PM > To: IBM-MAIN@bama.ua.edu > Subject: VSAM BLSR > > 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. I would agree that the BUFSI/BUFSD specifications do not appear to be helpful. I can't confirm if there would in fact be wasted memory, but my question to the customer would be, "Why specify BUFSI/BUFSD at all? Why not let the system use the actual values for the buffer sizes as it finds them?". Especially because they are, in fact, the same for both files. I can confirm that the BUFND specifications are in fact cumulative. When we first implemented a huge application with BLSR in the OS390 days, we had to be careful that for all SHRPOOL's added together, all the BUFND's times BUFSD did not exceed the 2GiB region limit. This was for RRDS's, so no BUFNI was involved, though I would assume the same is true for BUFNI as for BUFND. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
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 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/CA180
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 - dsn=tm2v@.hbbma.yw88mods,DISP=(
92 XXH99NPFLG DD SUBSYS=('BLSR','DDNAME=BLSRPFLG', *PFLG FILE *
XX 'BUFSI=4096,BUFSD=8192',
CISIZES --1536 --4096
DATA CI/CA180
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 - dsn=tm2v@.hbbma.mw88pflg,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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
>I would expect different SHRPOOLS to be cumulative, would probably bet big >money on it, even though I don't really know such from documentation much >less a dump. But what about multiple BLSR requests for the same SHRPOOL. >Does it sum them up and BLDVRP for the sum, just the largest, or what? The first ACB opened causes the BLDVRP to be done using the parameters for that DD only. You should receive message CSR024I indicating SHRPOOL 1 is being reused when the second ACB is opened. If H99NMODF is opened first, the buffer space is (4096*7972)+(8092*272) = over 33 meg. If H99NPFLG is opened first, the buffer space is (4096*4070)+ (8192*532) = over 20 meg. >No the concern is not performance, the concern is memory. We are a little >tight on what we allow in REGION around here and 48M in a SHRPOOL at least >50% of which seems to be TOTAL waste doesn't get it. The step sucks up >189M above the line and crashes. The JCL is a bit more reasonable on the 4 >or 5 files in the default SHRPOOL. I agree that the oversized buffers are wasting space. If the BUFSI and BUFSD are defaulted, then the space is 'minimized'. However, if the two files had different CI sizes, then your specification would not work if the one having the smaller CISIZE were opened first. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
On Mon, 2 Mar 2009 18:52:51 -0500 Peter Farley wrote >I can confirm that the BUFND specifications are in fact cumulative. >When we first implemented a huge application with BLSR in the OS390 >days, we had to be careful that for all SHRPOOL's added together, all >the BUFND's times BUFSD did not exceed the 2GiB region limit. This was >for RRDS's, so no BUFNI was involved, though I would assume the same is >true for BUFNI as for BUFND. I would expect different SHRPOOLS to be cumulative, would probably bet big money on it, even though I don't really know such from documentation much less a dump. But what about multiple BLSR requests for the same SHRPOOL. Does it sum them up and BLDVRP for the sum, just the largest, or what? On Mon, 2 Mar 2009 18:02:39 -0600 Dave Kopischke wrote >I assume you're perceiving a performance problem with this. Personally, I >wouldn't specify BUFSI, BUFSD, BUFNI nor BUFND. Let BLSR figure it out for >itself. No the concern is not performance, the concern is memory. We are a little tight on what we allow in REGION around here and 48M in a SHRPOOL at least 50% of which seems to be TOTAL waste doesn't get it. The step sucks up 189M above the line and crashes. The JCL is a bit more reasonable on the 4 or 5 files in the default SHRPOOL. On Mon, 2 Mar 2009 23:52:03 -0500 Jim Mulder wrote > For a particular SHRPOOL Id, nothing is cumulative. When the first >OPEN occurs for a specific SHRPOOL Id, BLSR creates the pool. If another >OPEN is done specifying the same SHRPOOL Id, the already created pool is >used, and the BUF* and RMODE parameters are irrelevant. Most peculiar! I have not the hubris to argue with the source but. I was hoping to be told that each time the "jobs INITIATOR issues the IEFSSREQ macro, invoking BLSR subsystem services, passing the information specified in the SUBSYS parameter." (page 93 "VSAM Demystified" SG24-6105-01) that the BLSR subsystem would note the parameters on each DD add them up and then issue a BLDVRP when it later gets control from the OPEN exit for the first file opened in each SHRPOOL. "When the application opens the VSAM DD ACB, the BLSR subsystem completes the conversion to LSR processing." (page 94 opcit). Oh idiot-moi !!! I HAVE a DUMP. Back later. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
IBM Mainframe Discussion List wrote on 03/02/2009
06:28:55 PM:
> 90 XXH99NMODF DD SUBSYS=('BLSR','DDNAME=BLSRMODF', *MOD FILE *
> XX 'BUFSI=4096,BUFSD=8192',
>CISIZES --1536 --4096
>DATA CI/CA180
>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 - dsn=tm2v@.hbbma.yw88mods,DISP=(
> 92 XXH99NPFLG DD SUBSYS=('BLSR','DDNAME=BLSRPFLG', *PFLG FILE *
> XX 'BUFSI=4096,BUFSD=8192',
>CISIZES --1536 --4096
>DATA CI/CA180
>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 - dsn=tm2v@.hbbma.mw88pflg,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.
For a particular SHRPOOL Id, nothing is cumulative. When the first
OPEN occurs for a specific SHRPOOL Id, BLSR creates the pool. If another
OPEN is done specifying the same SHRPOOL Id, the already created pool is
used, and the BUF* and RMODE parameters are irrelevant.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
On Mon, 2 Mar 2009 17:28:55 -0600, David Speake wrote:
>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/CA180
> 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 -
dsn=tm2v@.hbbma.yw88mods,DISP=(
> 92 XXH99NPFLG DD SUBSYS=('BLSR','DDNAME=BLSRPFLG', *PFLG FILE *
>XX 'BUFSI=4096,BUFSD=8192',
> CISIZES --1536 --4096
> DATA CI/CA180
> 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 - dsn=tm2v@.hbbma.mw88pflg,
I assume you're perceiving a performance problem with this. Personally, I
wouldn't specify BUFSI, BUFSD, BUFNI nor BUFND. Let BLSR figure it out for
itself.
It is my experience that a micromanaged specification is obsoleted soon after
it's made. But if you must, use BUFNI and BUFND only.
I limit my interference with BLSR to one specification; DEFERW=YES
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM BLSR
> -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of David Speake > Sent: Monday, March 02, 2009 6:29 PM > To: IBM-MAIN@bama.ua.edu > Subject: VSAM BLSR > > 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. I would agree that the BUFSI/BUFSD specifications do not appear to be helpful. I can't confirm if there would in fact be wasted memory, but my question to the customer would be, "Why specify BUFSI/BUFSD at all? Why not let the system use the actual values for the buffer sizes as it finds them?". Especially because they are, in fact, the same for both files. I can confirm that the BUFND specifications are in fact cumulative. When we first implemented a huge application with BLSR in the OS390 days, we had to be careful that for all SHRPOOL's added together, all the BUFND's times BUFSD did not exceed the 2GiB region limit. This was for RRDS's, so no BUFNI was involved, though I would assume the same is true for BUFNI as for BUFND. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VSAM BLSR
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/CA180
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 - dsn=tm2v@.hbbma.yw88mods,DISP=(
92 XXH99NPFLG DD SUBSYS=('BLSR','DDNAME=BLSRPFLG', *PFLG FILE *
XX 'BUFSI=4096,BUFSD=8192',
CISIZES --1536 --4096
DATA CI/CA180
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 - dsn=tm2v@.hbbma.mw88pflg,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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
