Re: BLSR question
> I found a thread from 2012 discussing BLSR and whether or not it > supports dynamic changes via the SETSSI command. That thread > indicated that BLSR had been updated to support SETSSI, and that > upon a SETSSI ACT, the subsystem would be added and activated. That > part appears to work, but now I can't deactivate it! How's this for bizarre? > > SETSSI ADD,S=BLSR,I=CSRBISUB > CSR002I BATCH LSR SUBSYSTEM BLSR INITIALIZATION COMPLETE. > IEFJ022I SETSSI ADD COMMAND FOR SUBSYSTEM BLSR COMPLETED > SUCCESSFULLY > > > SETSSI DEACT,S=BLSR > IEFJ023I SETSSI DEACTIVATE COMMAND FOR SUBSYSTEM BLSR COMPLETED WITH > ERRORS > IEFJ036I SUBSYSTEM BLSR IS NOT ENABLED FOR THE SETSSI COMMAND > > > D SSI,SUB=BLSR > IEFJ100I 10.56.35 SSI DISPLAY 588 > SUBSYS=BLSR >DYNAMIC=YES STATUS=ACTIVE COMMANDS=REJECT > > > I'm hoping this won't cause any conflicts with the VSAMTune product > e are running here. It shouldn't since it requires JCL changes to > actually use it. BLSR was implemented as a PTF on top of MVS/ESA SP3.1.3 in 1989. That was years before SETSSI was implemented on SP5.2.0. SETSSI ADD works for BLSR because BLSR didn't need to do anything to make it work. BLSR knows nothing about SETSSI. SETSSI DEACTIVATE requires the subsystem to provide support, and we have no intention of doing any BLSR enhancements. As you hoped, there is no need or reason to deactivate BLSR. It is invoked only when requested via SUBSYS=(BLSR,etc.) in JCL or SVC 99. It does not use SSI functions to monitor messages, commands, task terminations, memory terminations, or any other SSI stuff. Jim Mulder Former BLSR Developer 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
Re: BLSR
On 30 December 2013 18:47, Jim Mulder wrote: > BLSR was originally written at Washington Systems Center as > an assembler language subsystem, which was going to be included > with the book "The Subsystem Interface in MVS/SP Version 3 > GC66-3131-00 August 1989" as a sample > program, and named PHPD after the authors (Penny Heming, Paul Dorn). (I just replied to an old thread by mistake, but it won't hurt to have it there and here.) I'm guessing this should be GG66-3131. Trivia, and I may well be wrong, but I'm including it here so it becomes searchable. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLSR
Makes sense. Thank you! Frank > > From: Jim Mulder >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Monday, December 30, 2013 4:47 PM >Subject: Re: BLSR > > > >> This is just a curious question about how the JCL DD SUBSYS paramater >works. >> With BLSR you allocate a file to use BLSR with something like this: >> >> //INETACC DD SUBSYS=(BLSR,'DDNAME=INETACC@ MSG=I', >> // 'RMODE31=ALL BUFND=256 BUFNI=64 DEFERW=YES') >> //INETACC@ DD DSN=&DSNENV..INET.INETACC, >> // DISP=SHR >> >> Is there a specific reason why its not the more obvious (to me!) waylike >this? >> >> //INETACC DD DSN=&DSNENV..INET.INETACC,DISP=SHR, >> // SUBSYS=(BLSR,'MSG=IRMODE31=ALL BUFND=256 BUFNI=64 >DEFERW=YES') > > BLSR was originally written at Washington Systems Center as >an assembler language subsystem, which was going to be included >with the book "The Subsystem Interface in MVS/SP Version 3 >GC66-3131-00 August 1989" as a sample >program, and named PHPD after the authors (Penny Heming, Paul Dorn). >That was done without the involvement of >MVS or DFP development, so there was no opportunity to >modify operating system code. > > That code ended up being rewritten in PL/AS, renamed as >Batch LSR, and shipped as a PTF on top of MVS SP 3.1.3. > > With the syntax, you are proposing, >an OPEN for INETACC would be treated as a subsystem OPEN, >and control would be routed to the BLSR subsystem. But there >would be no DDNAME for which BLSR could subsequently do a >VSAM OPEN. Now, maybe it would have been possible for BLSR to >retrieve the necessary information and do a dynamic allocation >to create its own DDNAME for the VSAM data set. I don't know >if the original PHPD authors ever considered that possibility. >It would have been considerably more complex, and probably >beyond the scope of what they were trying to accomplish. > >Jim Mulder z/OS System 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
Re: BLSR
> This is just a curious question about how the JCL DD SUBSYS paramater works. > With BLSR you allocate a file to use BLSR with something like this: > > //INETACC DD SUBSYS=(BLSR,'DDNAME=INETACC@ MSG=I', > // 'RMODE31=ALL BUFND=256 BUFNI=64 DEFERW=YES') > //INETACC@ DD DSN=&DSNENV..INET.INETACC, > //DISP=SHR > > Is there a specific reason why its not the more obvious (to me!) waylike this? > > //INETACC DD DSN=&DSNENV..INET.INETACC,DISP=SHR, > // SUBSYS=(BLSR,'MSG=IRMODE31=ALL BUFND=256 BUFNI=64 DEFERW=YES') BLSR was originally written at Washington Systems Center as an assembler language subsystem, which was going to be included with the book "The Subsystem Interface in MVS/SP Version 3 GC66-3131-00 August 1989" as a sample program, and named PHPD after the authors (Penny Heming, Paul Dorn). That was done without the involvement of MVS or DFP development, so there was no opportunity to modify operating system code. That code ended up being rewritten in PL/AS, renamed as Batch LSR, and shipped as a PTF on top of MVS SP 3.1.3. With the syntax, you are proposing, an OPEN for INETACC would be treated as a subsystem OPEN, and control would be routed to the BLSR subsystem. But there would be no DDNAME for which BLSR could subsequently do a VSAM OPEN. Now, maybe it would have been possible for BLSR to retrieve the necessary information and do a dynamic allocation to create its own DDNAME for the VSAM data set. I don't know if the original PHPD authors ever considered that possibility. It would have been considerably more complex, and probably beyond the scope of what they were trying to accomplish. Jim Mulder z/OS System 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
