For applications using *SAM, it may be a walk in the park for most cases, but for applications using EXCP it is much more work.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Radoslaw Skorupka [r.skoru...@hotmail.com] Sent: Thursday, May 19, 2022 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM BLSR subsystem 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
