"At some sites, the most gargantuan thing about making a change like this is getting past the politics of getting managers who don't want to change anything." Exactly, and any little burp will be evidence the platform isn't as reliable as it's cracked up to be and/or that the people administering it aren't competent. All existing SLAs are being met, so the attitude tends toward 'If it ain't broke, why fix it?'.
Higher management in this organization once refused funds to upgrade the mainframe operating system. Their reasoning was 'the mainframe is due to be replaced next year and the new machine will come with the upgraded operating system already installed, so why do this now?' Ever feel like you're wading in molasses? -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Farley, Peter x23353 Sent: Friday, May 20, 2022 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. When change means being able to more consistently meet your contractual SLA's and handle ever-increasing client input volume that tends to make the politics a lot easier. Missed SLA's hit their bottom line, so that's where they tend to focus. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Pommier, Rex Sent: Friday, May 20, 2022 9:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem At some sites, the most gargantuan thing about making a change like this is getting past the politics of getting managers who don't want to change anything. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Radoslaw Skorupka Sent: Thursday, May 19, 2022 6:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] 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 -- 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...@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
