Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
Adding that library second in the STEPLIB using MODS with no DD name allows the alternate version in the first STEPLIB library allows the alternate version to be loaded. A good demonstration of the danger of assumptions. Apparently the module was not fetched from the LNKLST, but was fetched from the STEPLIB. I didn't notice anyone asking if the module in question was the copy that fetching from STEPLIB would have chosen. Anyway, I'm glad you figured it out. The other "normal" case if the observation were correct, is that the LOADer is authorized and the tasklib/steplib/joblib concatenation is not authorized, in which case the taslkib/steplib/joblib would not have been eligible. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
Problem resolved. Programmer error or ECC memory check in the programmer's brain (take your pick). The "global application library" is actually TWO libraries, one PDSE (current application target library) and one PDS (modules not recently recompiled). The E15 / E35 exit programs are located in the PDSE library. Adding that library second in the STEPLIB using MODS with no DD name allows the alternate version in the first STEPLIB library allows the alternate version to be loaded. Apologies for wasted bandwidth and no disrespect to the vendor. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Friday, August 30, 2019 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue Thanks Peter. In this case both exit programs are resident in LINKLIST and the global application library in LINKLIST is (AFAIK) also LLA/VLF managed. The precise sequence is a little more complicated than I first thought. Here is the sequence: JCL Invokes SYNCSORT SYNCSORT invokes COBOL EXIT program from LINKLIST library COBOL EXIT program dynamically calls assembler subroutine (also in LINKLIST global application library) Assembler subroutine LOAD's a "data" load module containing a small amount of application-specific data and displays that data via WTO. The "data" load modules are the ones that are incorrectly coming from LINKLIST instead of from MODLIB/STEPLIB/JOBLIB where I provide an alternate version of the "data". The LINKLIST version of the "data" module is always loaded. I will open an issue with the vendor on this. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Friday, August 30, 2019 8:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue I know nothing about SYNCSORT, but it is possible (and if so they should document) that the way they ask the system to fetch the module specifically indicates not to use tasklib/steplib/joblib. When the system does that it is typically to be using its copy of the named module rather than someone else's (since you'd have to out of your way, for example, to get your copy into LPA or ahead of the system's copy in the LNKLST. Since in your case it is "your module", such program logic would seem kind of strange. Peter Relson z/OS Core Technology Design -- 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
Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
Thanks Massimo, I did try that and got the same results - only the LINKLIST version gets loaded even when the MODS statement uses a specific DD name. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Massimo Biancucci Sent: Friday, August 30, 2019 4:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue Peter, I've tried the same on a customer site running Syncsort 2.1.5.0R on zOS 2.3 and it seems everything works fine. You can try (only a try) to code the DDNAME on E15/E35, add the DD with LOADLIB and see if anything changes. MODS E15=(EXITE15M,2048000,MYDDN,C),E35=(EXITE35M,2048000,MYDDN,C) Double check if PDS are in LLA/VLF and finally open an issue to Syncsort. Good luck. Max -- 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
Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
Thanks Peter. In this case both exit programs are resident in LINKLIST and the global application library in LINKLIST is (AFAIK) also LLA/VLF managed. The precise sequence is a little more complicated than I first thought. Here is the sequence: JCL Invokes SYNCSORT SYNCSORT invokes COBOL EXIT program from LINKLIST library COBOL EXIT program dynamically calls assembler subroutine (also in LINKLIST global application library) Assembler subroutine LOAD's a "data" load module containing a small amount of application-specific data and displays that data via WTO. The "data" load modules are the ones that are incorrectly coming from LINKLIST instead of from MODLIB/STEPLIB/JOBLIB where I provide an alternate version of the "data". The LINKLIST version of the "data" module is always loaded. I will open an issue with the vendor on this. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Friday, August 30, 2019 8:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue I know nothing about SYNCSORT, but it is possible (and if so they should document) that the way they ask the system to fetch the module specifically indicates not to use tasklib/steplib/joblib. When the system does that it is typically to be using its copy of the named module rather than someone else's (since you'd have to out of your way, for example, to get your copy into LPA or ahead of the system's copy in the LNKLST. Since in your case it is "your module", such program logic would seem kind of strange. Peter Relson z/OS Core Technology Design -- 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
Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
Exit loadlib should be listed in the MODLIB DD statement. Page 380 / 4.27 in https://mysupport.syncsort.com/largefiles/mfx14pg.pdf On Fri, Aug 30, 2019 at 7:19 AM Peter Relson wrote: > > I know nothing about SYNCSORT, but it is possible (and if so they should > document) that the way they ask the system to fetch the module > specifically indicates not to use tasklib/steplib/joblib. When the system > does that it is typically to be using its copy of the named module rather > than someone else's (since you'd have to out of your way, for example, to > get your copy into LPA or ahead of the system's copy in the LNKLST. Since > in your case it is "your module", such program logic would seem kind of > strange. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
I know nothing about SYNCSORT, but it is possible (and if so they should document) that the way they ask the system to fetch the module specifically indicates not to use tasklib/steplib/joblib. When the system does that it is typically to be using its copy of the named module rather than someone else's (since you'd have to out of your way, for example, to get your copy into LPA or ahead of the system's copy in the LNKLST. Since in your case it is "your module", such program logic would seem kind of strange. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue
Peter, I've tried the same on a customer site running Syncsort 2.1.5.0R on zOS 2.3 and it seems everything works fine. You can try (only a try) to code the DDNAME on E15/E35, add the DD with LOADLIB and see if anything changes. MODS E15=(EXITE15M,2048000,MYDDN,C),E35=(EXITE35M,2048000,MYDDN,C) Double check if PDS are in LLA/VLF and finally open an issue to Syncsort. Good luck. Max Il giorno gio 29 ago 2019 alle ore 23:53 Farley, Peter x23353 < peter.far...@broadridge.com> ha scritto: > I have a confusing issue with using COBOL E15/E35 exit programs where the > exit programs dynamically call application-specific subroutines in a JCL > SYNCSORT. The issue is from which library the exit programs are actually > loading the dynamically called subroutines. It seems that the dynamic > subroutines always load from LINKLIB, and not from STEPLIB or JOBLIB. What > I EXPECTED to happen was that the version of the dynamically called > application-specific subroutines in the STEPLIB or JOBLIB would be used, > not the version in LINKLIB. > > The JCL sort in question has a STEPLIB pointing to a small PDS with > application-specific versions of certain dynamically called subroutines. > The MODS statement is coded like this: > > MODS E15=(EXITE15M,2048000,,C),E35=(EXITE35M,2048000,,C) > > When each of the exits (both are compiled with Enterprise COBOL V5.2) > EXITE15M or EXITE35M is called by SYNCSORT, the only version of those exit > programs available is in the LINKLIST in a global application library. > Both exits dynamically call one of the application-specific subroutines as > one of the first things that they do. > > The application-specific subroutine performs a WTO as part of its normal > operation (ROUTCDE=11,DESC=7) to allow identification of which version of > the subroutine was actually loaded and executed. > > Even with a STEPLIB (and I also tried a JOBLIB) pointing to a library with > DIFFERENT VERSIONS of the application-specific subroutine than are in the > global application library in the LINKLIST, only the GLOBAL VERSION in the > LINKLIST application library is ever used, as evidenced by the WTO message > generated. > > Is this a misunderstanding on my part of how dynamic calls from a MODS > exit program should work, or is this a potential issue for a call to > SYNCSORT support? > > SYNCSORT level is 2.1.6.0N, z/OS V2.2. > > TIA for any assistance or advice you can provide. > > Peter > > > > 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
