Re: SV: STEPLIB problems - was: PDSE
On 1/25/2012 10:12 AM, Juergen Keller wrote: Thomas, STEPLIB from CBTTAPE works, I've tested it but its not supported/recommended. There was a discussion about DYNAMIC STEPLIB last year and Jim Mulder wrote: The only supported mechanism in MVS for adding to the module library search order within as address space is an ATTACH with a TASKLIB. This is the only supported way to set TCBJLB. Any program which modifies TCBJLB in an existing TCB is wrong to do so. I would recommend against having any such program installed on your system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY regards Juergen Juergen, The dynamic STEPLIB products you pay for also violate Jim's restriction. That's why IBM doesn't have its own Dynamic STEPLIB, because they will not modify TCBJLB. TSOLIB is the best they will do. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: STEPLIB problems - was: PDSE
Yes, I'm aware of that. With open eyes... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK > -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Juergen Keller > Skickat: den 25 januari 2012 16:00 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: SV: STEPLIB problems - was: PDSE > > Thomas, > > STEPLIB from CBTTAPE works, I've tested it but its not > supported/recommended. There was a discussion about DYNAMIC STEPLIB last > year and Jim Mulder wrote: > > The only supported mechanism in MVS for adding to the module library > search order within as address space is an ATTACH with a TASKLIB. This is > the only supported way to set TCBJLB. > Any program which modifies TCBJLB in an existing TCB is wrong to do so. I > would recommend against having any such > program installed on your system. > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > regards Juergen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: STEPLIB problems - was: PDSE
Thomas, STEPLIB from CBTTAPE works, I've tested it but its not supported/recommended. There was a discussion about DYNAMIC STEPLIB last year and Jim Mulder wrote: The only supported mechanism in MVS for adding to the module library search order within as address space is an ATTACH with a TASKLIB. This is the only supported way to set TCBJLB. Any program which modifies TCBJLB in an existing TCB is wrong to do so. I would recommend against having any such program installed on your system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY regards Juergen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: STEPLIB problems - was: PDSE
Thomas Berg wrote: > > > -Ursprungligt meddelande- > > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Don > > Poitras > > Skickat: den 25 januari 2012 13:11 > > Till: IBM-MAIN@bama.ua.edu > > Ämne: Re: STEPLIB problems - was: PDSE > > > > In article > > > > you wrote: > > > The original case by Juergen touches the main shortcoming of IBM's > > STEPLIB-stance. > > > > > There are cases when putting steplib(s) in linklist simply do not work! > > And where the alternative of putting it in the logon procedures is working > > nearly as bad. > > > I have several times seen those cases luckily (= allowed by management) > > been solved by dynamic steplib functions from outside IBM. > > > > > This happens when You must use conflicting software or software > > versions. One such case was when we were upgrading DB2 and during that > > period was the different test/development DB2 systems on different release > > levels. Another case was when we had different software (in the TSO > > development environments) that relied on the same set of "SAS/C" modules > > for I/O and other things - but of different releases of these modules. > > (At least one of those SW was IBM's.) And other cases. > > > > Did you try putting the then-current SAS/C release in linklist? If that > > didn't > > work, you could have opened a problem report with SAS and we would have > > tried to fix it. For the WSA (back when it was written in SAS/C), we > > actually > > prefixed the library so that you could put two (or more) versions in > > linklist without disrupting running programs. > > IIRC, these "SAS/C" modules was delivered as a part of these SW's own > libraries, not as a part of the SAS product. > (I call these "SAS/C" as that was what I saw when browsing the loadmodules.) > In fact, one of the SW's was ISPF/WSA and the other (IIRC) was a product > called ProEdit. > > BTW, what do You mean by "prefixed the library" ? SAS/C != SAS. The "SAS/C Transient Library" contains portions of the C run-time library and is freely distributable by ISVs. We ask that they distribute it as provided, but we can't force them to do so. Back in '96, we worked with IBM to take advantage of a feature that was already present. In order to allow the CICS transient library to co-exist with the non-CICS version, the calling code was written to use a prefix for each load module. "LSH" for CICS and "LSC" for non-CICS. These names are actually aliases of the L$C prefix that we use for zapping the modules with maintanence. User programs would pick up the prefix by linking with the appropriate link library. For IBM, we externalized this feature and they started delivering the transient library with (as I recall) "ISP" as the prefix. The idea being that IBM wouldn't be forced to use a newer transient library (or back-level if the customer for some reason did that.) A few other ISV's used this as well. > > > Regards, > Thomas Berg > _ > Thomas Berg Specialist A M SWEDBANK -- Don Poitras - zSeries R & D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: STEPLIB problems - was: PDSE
Thomas Berg wrote: >In fact, we usually do *not* have //STEPLIB in our logon procs. (Partly of >performance reasons.) Good that you can avoid them. I agree about performance reasons, why allocate something if you don't use it at all in your session? >> Please tell me more about this dynamic steplib functions? >There are several. One can be found in CBTTAPE, others is the late Gilbert >Saint-Flour's and more. >E g CBTTAPEs dynamic steplib is used by issuing commands like these in TSO >(/rexx/clist): >1: "STEPLIB ALLOCATE DATASETS(dsname list) SHR REUSE" >2: Run the (ISPF) application >3: "STEPLIB FREE" I'm aware of them, I was wondering if you're using something exotic and elegant! ;-D One benefit is that you have fewer users to ask to logoff (or is that 'rockoff'? ;-D ) because you want to do something disruptive on a dataset. >Unfortunately this doesn't help when the users need to use both the "old" and >the "new" things at the same time... Ouch ... I feel your pain ... Thomas, many thanks for kindly answering my questions, I really appreciate it much! Please keep it up! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: STEPLIB problems - was: PDSE
> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Shmuel Metz (Seymour J.) > Skickat: den 25 januari 2012 14:22 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: STEPLIB problems - was: PDSE > > In > , > on 01/25/2012 >at 11:43 AM, Thomas Berg said: > > >This happens when You must use conflicting software or software > >versions. > > For that case, why can't you set it up from the READY prompt prior to > going into ISPF? Because I need to use both at the "same time" (in ISPF). Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: STEPLIB problems - was: PDSE
> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Barbara Nitz > Skickat: den 25 januari 2012 13:11 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: STEPLIB problems - was: PDSE > > >Our TSO users select the 'environment' they like to work in, i.e. > DEVL/PROD, DB2ID etc. and during logon we allocate to the different ISP* > ddnames the libraries required for that envrionment. At least 'dynamic' > during logon, not during the life of the session. > > That only works if the ISPF application supports ISPLLIB (see the dynamic > steplib discussion). If ISPLLIB is not supported, then the needed library > must be in STEPLIB. I think there was also some mention of ALTLIB (which I > never fully grasped) and which basically means a new logon in most > installations. ITYM IBMs "TSOLIB" function/command. Which must be used under "native" TSO before starting ISPF. Which means that it's unusable except as an alternative to different logon procs - with the inconvenience to have to issue the command(s) every logon... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: STEPLIB problems - was: PDSE
> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Elardus Engelbrecht > Skickat: den 25 januari 2012 13:17 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: STEPLIB problems - was: PDSE > > Thomas Berg wrote: > > >There are cases when putting steplib(s) in linklist simply do not work! > > Please elaborate on those cases. Is it about mixing of APF and non-APF > libraries? Or is it something else? Se below. > > >And where the alternative of putting it in the logon procedures is > working nearly as bad. > > Having a ***tested*** logon proc with the minimum libraries (Base TO/ISPF, > SDSF and RACF) never ever hurts. ;-D In fact, we usually do *not* have //STEPLIB in our logon procs. (Partly of performance reasons.) > >I have several times seen those cases luckily (= allowed by management) > been solved by dynamic steplib functions from outside IBM. > > Please tell me more about this dynamic steplib functions? There are several. One can be found in CBTTAPE, others is the late Gilbert Saint-Flour's and more. E g CBTTAPEs dynamic steplib is used by issuing commands like these in TSO (/rexx/clist): 1: "STEPLIB ALLOCATE DATASETS(dsname list) SHR REUSE" (allocates a new steplib & closes/frees the old) 2: Run the (ISPF) application 3: "STEPLIB FREE" (closes/frees the old steplib) > >This happens when You must use conflicting software or software versions. > One such case was when we were upgrading DB2 and during that period was > the different test/development DB2 systems on different release levels. > > Groan... This is why I always insist to 'them' to have two set of procs > and logon procs. One with 'old' things and another one with 'new' things. > But no, no-one listens to me and rather howls like a poor rejected doggy > when the jobs fail... ;-D Unfortunately this doesn't help when the users need to use both the "old" and the "new" things at the same time... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: STEPLIB problems - was: PDSE
> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Don > Poitras > Skickat: den 25 januari 2012 13:11 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: STEPLIB problems - was: PDSE > > In article > > you wrote: > > The original case by Juergen touches the main shortcoming of IBM's > STEPLIB-stance. > > > There are cases when putting steplib(s) in linklist simply do not work! > And where the alternative of putting it in the logon procedures is working > nearly as bad. > > I have several times seen those cases luckily (= allowed by management) > been solved by dynamic steplib functions from outside IBM. > > > This happens when You must use conflicting software or software > versions. One such case was when we were upgrading DB2 and during that > period was the different test/development DB2 systems on different release > levels. Another case was when we had different software (in the TSO > development environments) that relied on the same set of "SAS/C" modules > for I/O and other things - but of different releases of these modules. > (At least one of those SW was IBM's.) And other cases. > > Did you try putting the then-current SAS/C release in linklist? If that > didn't > work, you could have opened a problem report with SAS and we would have > tried to fix it. For the WSA (back when it was written in SAS/C), we > actually > prefixed the library so that you could put two (or more) versions in > linklist without disrupting running programs. IIRC, these "SAS/C" modules was delivered as a part of these SW's own libraries, not as a part of the SAS product. (I call these "SAS/C" as that was what I saw when browsing the loadmodules.) In fact, one of the SW's was ISPF/WSA and the other (IIRC) was a product called ProEdit. BTW, what do You mean by "prefixed the library" ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: STEPLIB problems - was: PDSE
> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Vernooij, CP - SPLXM > Skickat: den 25 januari 2012 12:24 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: STEPLIB problems - was: PDSE > > I see what you mean. What are 'dynamic steplib functions from outside > IBM'? Some third party product? Yes. (We have actually changed from one to another due to z/OS changes.) > > Our TSO users select the 'environment' they like to work in, i.e. > DEVL/PROD, DB2ID etc. and during logon we allocate to the different ISP* > ddnames the libraries required for that envrionment. At least 'dynamic' > during logon, not during the life of the session. > > Kees. > > "Thomas Berg" wrote in message > news: se>... > > The original case by Juergen touches the main shortcoming of IBM's > STEPLIB-stance. > > > > There are cases when putting steplib(s) in linklist simply do not work! > And where the alternative of putting it in the logon procedures is working > nearly as bad. > > I have several times seen those cases luckily (= allowed by management) > been solved by dynamic steplib functions from outside IBM. > > > > This happens when You must use conflicting software or software > versions. One such case was when we were upgrading DB2 and during that > period was the different test/development DB2 systems on different release > levels. Another case was when we had different software (in the TSO > development environments) that relied on the same set of "SAS/C" modules > for I/O and other things - but of different releases of these modules. > (At least one of those SW was IBM's.) And other cases. > > > > This experience coupled by some recent contacts with development labs at > IBM give me the impression that IBM lacks contact with "the reality" out > here... ;) > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
