ACCBIAS=DO provides much the same value as BLSR for a single VSAM
file (see
<https://www.ibm.com/docs/en/zos/2.4.0?topic=buffering-processing-guidelines-restrictions>Processing
guidelines and restrictions - IBM Documentation). Both provide LSR
and can be optioned for deferred writes. And you have the same
restrictions if the VSAM file(s) are used by more than one task.
One thing to consider is how the application actually processed the
VSAM file. If the access is not truly random, but skip-sequential,
LSR buffers get flushed as part of the POINT. And if the sequential
reads are relatively short (couple of Cis), you would probably want a
moderate BUFND to keep from excessive I/O due to reading CIs that are
never used by the application or are flushed during the POINT and
then re-read with the next POINT.
Note that if you are processing multiple VSAM files or are
memory-constrained, BLSR provides some tools for tweaking an
application using details that SMB wouldn't know.
Depends on the nature of the failure. In catastrophic failures
(system crash, termination at end of memory, FORCE, etc.) un-written
data in the buffers is lost. Other, less severe issues may result in
the data being written to the file as part of task termination.
Restarting/re-running an application after failure will be governed
by how sophisticated the application is and whether updated records
have had field contents replaced or incremented/decremented.
General guidance on a failure with deferred writes enabled is to
restore the file(s). Even though that may be prohibitive.
The key to all of this is to know your application and how it is
actually accessing the data in the VSAM file(s).
Michael
At 03:51 PM 5/16/2022, Pommier, Rex wrote:
Michael,
Reading the JCL manual, it almost seems to me like ACCBIAS=DO is
calling BLSR under the covers. If I specify DO, I can also specify
a SMBDFR which defers writes until the dataset gets closed or the
buffers are needed.
If doing DEFERW, what happens if the job abends. Does the VSAM get
closed thereby flushing the buffers or do the changes simply disappear?
Long ago when disks were slow (think 3380s behind non-cached
controllers) I used BLSR with DEFERW in a specific situation to
shave 85-90% off wall clock and I/O counts for a VSAM update
job. BLSR by itself was responsible for about half the savings but
DEFERW did the rest.
Rex
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of Michael Oujesky
Sent: Monday, May 16, 2022 3:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem
AMP will be fine for setting BUFNI or BUFMD, but won't tell VSAM to
look-aside the data buffers. So, without a program product, either
the program needs to establish a LSR pool or use BLSR via JCL to get
look-aside.
I would urge caution in using deferred writes. Just be sure you
understand the implications to your application from lost updates
due to a failure. I have used deferred writes where I have a
temporary VSAM used to hold large arrays where the array is
initially empty and all records deleted before closing the VSAM file.
Michael
At 02:51 PM 5/16/2022, Pommier, Rex wrote:
>Thanks, all responders.
>
>Michael, so I'm not stuck in the mid '90s, just the BLSR documentation
>is. :-) "First Edition, June 1994"
>
>I have seen the references to BLSR in other documents, like a crypto
>manual and some SMP/E references to it, but until I found the 1994
>document, I couldn't find anything that actually explained it. That's
>where I was getting confused. I'll also need to check the AMP parm to
>see if that does the same thing. The DEFERW=YES option looks
>interesting (again).
>
>Rex
>
>-----Original Message-----
>From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
>Behalf Of Michael Oujesky
>Sent: Monday, May 16, 2022 2:23 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: [EXTERNAL] Re: IBM BLSR subsystem
>
>PDF -
>https://urldefense.com/v3/__http://publibz.boulder.ibm.com/epubs/pdf/ie
>a5j600.pdf__;!!KjMRP1Ixj6eLE0Fj!qkxYWCkBfDGHDC7oenAm5D9KqrxkJrY3t_3JVFd
>CVrbQCkmMcgu-pyPE7GDVRGTH5pXjbNntD-my9ikgUcff1KGO$
>
>
>BLSR will help principally if the access is random and the locality of
>reference of the data component is good. Otherwise, just increasing
>the BUFNI and/or BUFND will suffice. Note that for sequential access a
>BUFND of twice the CIs per CA plus two and just a few BUFNI five or so)
>usually provides about the best you can get (incudes over-lapping read
>I/O to the data component).
>
>I still see BLSR in the 2.5 IEFSSN00 member.
>
>Michael
>
>At 09:36 AM 5/16/2022, Pommier, Rex wrote:
> >Hi list,
> >
> >Is the BLSR subsystem (batch local shared resources) still a
> >viable/valuable thing or has it been replaced by something
> >bigger/better/faster? I seem to be stuck in the mid-90s because the
> >most current documentation I can find on it is from MVS/ESA 5.1 dated
> >1994. Is there more current documentation on how to use it and how
> >it works? Has it been replaced and deprecated? I just had a
> >developer use it last week and experienced a 40+ reduction in I/Os
> >but I wanted to read up on its limitations - especially around using
> >it on a shared VSAM dataset. However I can't find anything newer
> >than 25+ years old. I did multiple internet searches which is
> >where I found the ESA manual. I checked the knowledge center and my
> >own z/OS 2.2 and 2.4 collections all to no avail.
> >
> >Thanks,
> >
> >Rex
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>----------------------------------------------------------------------
>The information contained in this message is confidential, protected
>from disclosure and may be legally privileged. If the reader of this
>message is not the intended recipient or an employee or agent
>responsible for delivering this message to the intended recipient, you
>are hereby notified that any disclosure, distribution, copying, or any
>action taken or action omitted in reliance on it, is strictly
>prohibited and may be unlawful. If you have received this communication
>in error, please notify us immediately by replying to this message and
>destroy the material in its entirety, whether in electronic or hard
>copy format. Thank you.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
The information contained in this message is confidential, protected
from disclosure and may be legally privileged. If the reader of this
message is not the intended recipient or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any disclosure, distribution, copying,
or any action taken or action omitted in reliance on it, is strictly
prohibited and may be unlawful. If you have received this
communication in error, please notify us immediately by replying to
this message and destroy the material in its entirety, whether in
electronic or hard copy format. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
