Excuse me, what is gargantuan in moving to extended format?
Note: we are talking about *application* datasets, not ICF, SyS1.MANx,
system, VVDS or whatever.
Note2: it need NOT to be big bang approach, you can change definitions
for some/few datasets. And only for new allocations.
IMHO it is like walk to the park - the most gargantuan thing is to make
first step.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 19.05.2022 o 16:48, Michael Watkins pisze:
Thanks for the history and a definitive word on BLSR. From your (and others')
remarks, it seems obvious that BLSR has been supereceded by SMB. So why not
just implement SMB?
Doesn't SMB only work if the clusters whose buffers you want to manage are
defined as extended format? In contrast, BLSR does not require extended format,
correct?
Extended format datasets are the exception where I am employed, not the rule.
Recreating the DASD farm in extended format would be a gargantuan task,
requiring the buy-in of far-flung managers with limited technical acumen who'd
see such efforts as a lot of work for very little benefit. At this point,
implementing BLSR until SMB can be a reality might provide some immediate
relief.
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jim
Mulder
Sent: Thursday, May 19, 2022 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM BLSR subsystem
BLSR was initially developed by Washinton System Center as an assembler language sample
program to go along with a book they were writing about using the Subsystem Interface.
At the time, IBM was desperately looking for "ESA Exclusives" in order to sell
3090 machines vs the PCM manufacturers, who machines had not yet implemented ESA. This
sample program happened to use one BAKR/PR, which meant that it did require ESA.
So MVS management wanted to instead ship the program an OCO part of the MVS
BCP, and I was commanded to review the code to see what that would entail.
I raised several objections concerning the maintainability of the code, the
lack of serviceability (no ESTAEs, no dumping, no control block eyecatchers,
we didn't want new assembler code), no message IDs, lack of messages and
message control, an integrity exposure, etc, etc. Also, VSAM functionality was
not really in the BCP's bailiwick, and we would end up having to support this
code for decades.
So I recommended that we should not do this.
But, since selling machines trumps everything, I lost that argument, and was
instead assigned to remediate all of my objections to the sample code.
I recoded the whole thing in PL/AS and fixed all of the issues, and wrote lots
of testcases, and it got shipped as a PTF on top of MVS/ESA SP3.1.3.
MVS Project Management did contribute the "Batch LSR" name.
Decades later, we continue to support it and probably always will, but at
least the right solution eventually got implemented by SMB in DFSMS.
And now you know... the rest of the story.
James Harvey Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
