Re: LE runtime
I've never had issues with inlined code when using IBM Debugger. I've never explicitly checked its behavior, but I've never run in to an issue. We use OPT(1) [for some probably bad reason not OPT(2)]. The only times I've seen the issue Tom is referring to are: 1. We backed out the latest production version and replaced it with the previous version. We then can no longer see the source code of the failed (backed out) version. 2. When testing we've already implemented an updated version and are trying to analyze the dump from a prior version. Using IBM Fault Analyzer for both. I don't consider them to be huge problems, and certainly not a reason to, say, have multiple versions of the load module and/or debug information. Just something to be aware of and live with, as little as it happens. From: IBM Mainframe Discussion List on behalf of Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime That would be a failure of your development lifecycle process. Anything running in production MUST have compile listings available of the exact version running in production, and it doesn't hurt to retain the binder listing too. If you are still running an "older version" in production and you also have a newer version in production at the same time without retaining the older version listing somewhere, that's a process failure. As for debugging production COBOL code, there are hurdles there too even if your listing is available. In my experience, the compiler option INLINE (default for higher levels of OPTIMIZE) absolutely prevents interactively stopping in any inlined paragraph. At least not using the CA Intertest debugger, which is all we have available to us at my employer's site, so I don’t know what the IBM debugger is capable of. I have found that using compiler option TEST(SOURCE) in production compiles subtracts very little from optimization and greatly aids debugging of production code (except for INLINE's - nothing helps that except re-compiling in test with NOINLINE and hoping the bug doesn't disappear with the test version). Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, April 7, 2023 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Yes, it will. And if you are debugging an abend that occurred with an older version of the program, the listing is no longer available in the program object. -- Tom Marchant On Fri, 7 Apr 2023 18:33:18 +, Seymour J Metz wrote: >Won't that replace the NOLOAD segments with the new ones? > > >-- >Shmuel (Seymour J.) Metz > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >behalf of Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu] >Sent: Friday, April 7, 2023 2:31 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: LE runtime > >Until the program is recompiled and relinked. > >-- >Tom Marchant > >On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross >wrote: > >>With the >>NOLOAD class program segmenets in new COBOL the debugging data is >>always available, always in sync -- 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
Re: LE runtime
While this is true, in that you can't look at, say, Fault Analyzer if it's dump is for a previous version, even having a separate debug file won't generally save you from that. Because you'd usually put the new version there as well. From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 7, 2023 12:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Until the program is recompiled and relinked. -- Tom Marchant On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross wrote: >With the >NOLOAD class program segmenets in new COBOL the debugging data is always >available, always in sync -- 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: LE runtime
That would be a failure of your development lifecycle process. Anything running in production MUST have compile listings available of the exact version running in production, and it doesn't hurt to retain the binder listing too. If you are still running an "older version" in production and you also have a newer version in production at the same time without retaining the older version listing somewhere, that's a process failure. As for debugging production COBOL code, there are hurdles there too even if your listing is available. In my experience, the compiler option INLINE (default for higher levels of OPTIMIZE) absolutely prevents interactively stopping in any inlined paragraph. At least not using the CA Intertest debugger, which is all we have available to us at my employer's site, so I don’t know what the IBM debugger is capable of. I have found that using compiler option TEST(SOURCE) in production compiles subtracts very little from optimization and greatly aids debugging of production code (except for INLINE's - nothing helps that except re-compiling in test with NOINLINE and hoping the bug doesn't disappear with the test version). Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, April 7, 2023 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Yes, it will. And if you are debugging an abend that occurred with an older version of the program, the listing is no longer available in the program object. -- Tom Marchant On Fri, 7 Apr 2023 18:33:18 +, Seymour J Metz wrote: >Won't that replace the NOLOAD segments with the new ones? > > >-- >Shmuel (Seymour J.) Metz > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >behalf of Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu] >Sent: Friday, April 7, 2023 2:31 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: LE runtime > >Until the program is recompiled and relinked. > >-- >Tom Marchant > >On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross >wrote: > >>With the >>NOLOAD class program segmenets in new COBOL the debugging data is >>always available, always in sync -- 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: LE runtime
Are you talking about a scenario where you can't reproduce the ABEND in the recopmiled version? If not, why do you want the old symbol table, etc.? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu] Sent: Friday, April 7, 2023 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Yes, it will. And if you are debugging an abend that occurred with an older version of the program, the listing is no longer available in the program object. -- Tom Marchant On Fri, 7 Apr 2023 18:33:18 +, Seymour J Metz wrote: >Won't that replace the NOLOAD segments with the new ones? > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu] >Sent: Friday, April 7, 2023 2:31 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: LE runtime > >Until the program is recompiled and relinked. > >-- >Tom Marchant > >On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross >wrote: > >>With the >>NOLOAD class program segmenets in new COBOL the debugging data is always >>available, always in sync -- 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: LE runtime
Yes, it will. And if you are debugging an abend that occurred with an older version of the program, the listing is no longer available in the program object. -- Tom Marchant On Fri, 7 Apr 2023 18:33:18 +, Seymour J Metz wrote: >Won't that replace the NOLOAD segments with the new ones? > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu] >Sent: Friday, April 7, 2023 2:31 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: LE runtime > >Until the program is recompiled and relinked. > >-- >Tom Marchant > >On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross >wrote: > >>With the >>NOLOAD class program segmenets in new COBOL the debugging data is always >>available, always in sync -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
Won't that replace the NOLOAD segments with the new ones? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Marchant [000a2a8c2020-dmarc-requ...@listserv.ua.edu] Sent: Friday, April 7, 2023 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Until the program is recompiled and relinked. -- Tom Marchant On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross wrote: >With the >NOLOAD class program segmenets in new COBOL the debugging data is always >available, always in sync -- 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: LE runtime
Until the program is recompiled and relinked. -- Tom Marchant On Fri, 7 Apr 2023 10:48:04 -0700, Tom Ross wrote: >With the >NOLOAD class program segmenets in new COBOL the debugging data is always >available, always in sync -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
>BTW: I didn't say "strange debugging option"; what is strange IMO is the=20 >fact >that COBOL requires the modules in PDSEs not because the language needs=20 >this, >but only to support some debugging tools, which could IMO store their=20 >information >at another place. But the COBOL community seems to have accepted this move. There are many reasons why new COBOL programs have to be Program Objects and cannot be Load Modules. As a result of requiring Program Objects, we were able to also solve a long-standing problem for customers: Keeping the debugging data in sync with the executable and making that data available. With the NOLOAD class program segmenets in new COBOL the debugging data is always available, always in sync, and does not negatives impacl load performance. Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
I didn't say anything about creating a LM or PO directly. I don't know specifics on how it's done, but the debug data ends up as a NOLOAD segment of a PO if the TEST(NOSEPARATE) option is specified. From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Thursday, April 6, 2023 6:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Are you sure that any of them can directly create load modules or program objects? I suspect that they still produce object modules, albeit in a modern format, and require, e.g., the Binder, as a final step. Does anybody remember SQUOZE <https://en.wikipedia.org/wiki/SQUOZE>? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Thursday, April 6, 2023 3:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime The "strange debugging option" for COBOL is, I believe, the ability to store the compressed source code data in a NOLOAD segment of a program object; something not supported with legacy load modules. A very useful thing, in my opinion. Much better than having the debug data in a separate module in a separate library. From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Thursday, April 6, 2023 1:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. With C++ (I guess), this is due to the fact that (writable) static data can be initialized not only by static initializers (which could be implemented by CSECT formatting), but by function calls, which needs init functions called after program load or task creation. So with C++, the requirement for program objects is driven by the language definition. But I'm not sure about this. For COBOL, it is kind of strange, and as I understood, it is only driven by some sort of debugging option which only can be handled by program objects. The PL/1 compiler group, FWIW, stated that they don't plan to require program objects in the near future. By the way: NORENT C can produce load modules, too. We still use NORENT C generating load modules (without the compiler options RENT, DLL, LONGNAME). I hope that this will be supported in the future, too ... and that "normal load modules" won't go away soon (I don't think it will be possible). It would by interesting, again, what PL/X does. Maybe the new fancy stuff is only for the customers :-) Kind regards Bernd Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: > Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN > could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and > C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 > modules had naming conflicts with very old pre-LE runtimes, while SCEERUN > modules did not. > > On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick > wrote: > >> What is the major difference between the SCEERUN and SCEERUN2 libraries? >> Is RUN2 for XPLINK and RUN for non-XPLINK? >> -- 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 -- 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: LE runtime
I would be tempted to just switch to PDSE and be done with it. Of course, that doesn't help with the C++ issue, but it's still one less thing to worry about. From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Thursday, April 6, 2023 8:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime I recall that if you use certain language constructs, the binder complains about "this object requires PO format 3 and cannot be stored in a load module"; maybe if you initialize a static value using a function call (which is not valid in ANSI C). I once had the need to convert such a C++ function to ANSI C, because one branch of my customer doesn't allow C++ ... the other branch does, and I had to copy a routine which creates UUIDs from the other branch. To do this in C, I had to get rid of the initialization of the (writable) static data by using a function call. In C, it is not possible to do function calls when initalizing static data; static data is initialized at enclave creation time, and the C language description allows only constants at this time, no function calls. Load modules (in the NORENT case) initialize their static data at compile time by CSECT formatting. With RENT, a compiler created initialization routine is called, but with C, it is not possible that this routine calls "user" routines. Of course, if you don't do this and you use only features that could also be simulated using ANSI C, you maybe don't have this problem. So my opinion is: not all C++ programs require PDSEs, but there are some, which require program objects format 3, and these will, of course, require PDSEs. Kind regards Bernd Am 07.04.2023 um 02:12 schrieb Charles Mills: > C++ can produce object code that can be linked into a traditional load module > in a PDS. I do it all the time. > > Charles > > On Thu, 6 Apr 2023 09:18:28 +0200, Bernd Oppolzer > wrote: > >> Thanks. >> >> This (to me) seems related to the fact that PL/I still can produce >> "classic" load modules, >> while COBOL and C++ create program objects, which must reside in PDSEs. > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
I recall that if you use certain language constructs, the binder complains about "this object requires PO format 3 and cannot be stored in a load module"; maybe if you initialize a static value using a function call (which is not valid in ANSI C). I once had the need to convert such a C++ function to ANSI C, because one branch of my customer doesn't allow C++ ... the other branch does, and I had to copy a routine which creates UUIDs from the other branch. To do this in C, I had to get rid of the initialization of the (writable) static data by using a function call. In C, it is not possible to do function calls when initalizing static data; static data is initialized at enclave creation time, and the C language description allows only constants at this time, no function calls. Load modules (in the NORENT case) initialize their static data at compile time by CSECT formatting. With RENT, a compiler created initialization routine is called, but with C, it is not possible that this routine calls "user" routines. Of course, if you don't do this and you use only features that could also be simulated using ANSI C, you maybe don't have this problem. So my opinion is: not all C++ programs require PDSEs, but there are some, which require program objects format 3, and these will, of course, require PDSEs. Kind regards Bernd Am 07.04.2023 um 02:12 schrieb Charles Mills: C++ can produce object code that can be linked into a traditional load module in a PDS. I do it all the time. Charles On Thu, 6 Apr 2023 09:18:28 +0200, Bernd Oppolzer wrote: Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. -- 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: LE runtime
C++ can produce object code that can be linked into a traditional load module in a PDS. I do it all the time. Charles On Thu, 6 Apr 2023 09:18:28 +0200, Bernd Oppolzer wrote: >Thanks. > >This (to me) seems related to the fact that PL/I still can produce >"classic" load modules, >while COBOL and C++ create program objects, which must reside in PDSEs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
IMO, the other languages (PL/I, C) also support building program objects and very large programs (> 16 MB), but COBOL with the newest compiler version REQUIRES even small programs to live in PDSEs (as program objects) and does not allow old (classic) load modules. I'm not sure about this, but IMO in some places in the OS "old" load modules are still required and program objects living in PDSEs cannot be used, maybe because PDSE support requires some help from the OS, and this is not available in the very early stages after IPL. Maybe, OTOH, nobody wants COBOL programs there ... these modules are probably PL/X or ASSEMBLER or Metal C ... I cannot imagine a monolithic program with code size larger than 16 MB, and a program which has static tables bigger than 16 MB is, IMHO, a design failure. But this is maybe an old school point of view ... Kind regards Bernd Am 07.04.2023 um 01:09 schrieb Attila Fogarasi: Cobol first started to use PDS/E in 2001 when exploiting new Cobol support for long program names, object-oriented programs and for using the Binder for DLLs instead of the prelinker. Program objects also cured the 16MB maximum load module size which was becoming a problem (PO size limit is 1GB). There are probably other Cobol language features which require PDS/E. I'm pretty sure this was just after Y2K, so over 20 years ago now. Getting old enough to be called legacy :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
Cobol first started to use PDS/E in 2001 when exploiting new Cobol support for long program names, object-oriented programs and for using the Binder for DLLs instead of the prelinker. Program objects also cured the 16MB maximum load module size which was becoming a problem (PO size limit is 1GB). There are probably other Cobol language features which require PDS/E. I'm pretty sure this was just after Y2K, so over 20 years ago now. Getting old enough to be called legacy :) On Thu, Apr 6, 2023 at 11:46 PM Bernd Oppolzer wrote: > I don't know much about the specific output formats that the compilers > produce, > but in the installations I know, the Binder is used to produce the load > modules; > this is necessary because run time objects have to be linked together > with the > output coming from the compiler. > > In my historic MVS environment, I see that the compiler output is recfm > FB 80; > the well known ESD - RLD - TXT format. Don't know if this is still in > use today (in modern > environments). The record format of the load libraries is something like > U 19069 > (valid until today, AFAIK). > > GOFF, AFAIK, is a more modern output format ... don't know if this applies > to the PL/1 and C compilers and to the output of the compilers in general > (and input to the linkers or binders). > > BTW: I didn't say "strange debugging option"; what is strange IMO is the > fact > that COBOL requires the modules in PDSEs not because the language needs > this, > but only to support some debugging tools, which could IMO store their > information > at another place. But the COBOL community seems to have accepted this move. > > Kind regards > > Bernd > > > Am 06.04.2023 um 14:25 schrieb Seymour J Metz: > > Directly, or via GOFF to Binder? > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] > > Sent: Thursday, April 6, 2023 3:18 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: LE runtime > > > > Thanks. > > > > This (to me) seems related to the fact that PL/I still can produce > > "classic" load modules, > > while COBOL and C++ create program objects, which must reside in PDSEs. > > > > With C++ (I guess), this is due to the fact that (writable) static data > > can be initialized not only by > > static initializers (which could be implemented by CSECT formatting), > > but by function calls, which > > needs init functions called after program load or task creation. So with > > C++, the requirement > > for program objects is driven by the language definition. But I'm not > > sure about this. > > > > For COBOL, it is kind of strange, and as I understood, it is only driven > > by some sort of > > debugging option which only can be handled by program objects. > > > > The PL/1 compiler group, FWIW, stated that they don't plan to require > > program objects > > in the near future. > > > > By the way: NORENT C can produce load modules, too. We still use NORENT > > C generating > > load modules (without the compiler options RENT, DLL, LONGNAME). I hope > > that this will > > be supported in the future, too ... and that "normal load modules" won't > > go away soon > > (I don't think it will be possible). > > > > It would by interesting, again, what PL/X does. Maybe the new fancy > > stuff is only > > for the customers :-) > > > > Kind regards > > > > Bernd > > > > > > Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: > >> Originally SCEERUN2 contained LE modules that had to be PDS/E while > SCEERUN > >> could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol > and > >> C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 > >> modules had naming conflicts with very old pre-LE runtimes, while > SCEERUN > >> modules did not. > >> > >> On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick < > frank.swarbr...@outlook.com> > >> wrote: > >> > >>> What is the major difference between the SCEERUN and SCEERUN2 > libraries? > >>> Is RUN2 for XPLINK and RUN for non-XPLINK? > >>> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.
Re: LE runtime
I don't know much about the specific output formats that the compilers produce, but in the installations I know, the Binder is used to produce the load modules; this is necessary because run time objects have to be linked together with the output coming from the compiler. In my historic MVS environment, I see that the compiler output is recfm FB 80; the well known ESD - RLD - TXT format. Don't know if this is still in use today (in modern environments). The record format of the load libraries is something like U 19069 (valid until today, AFAIK). GOFF, AFAIK, is a more modern output format ... don't know if this applies to the PL/1 and C compilers and to the output of the compilers in general (and input to the linkers or binders). BTW: I didn't say "strange debugging option"; what is strange IMO is the fact that COBOL requires the modules in PDSEs not because the language needs this, but only to support some debugging tools, which could IMO store their information at another place. But the COBOL community seems to have accepted this move. Kind regards Bernd Am 06.04.2023 um 14:25 schrieb Seymour J Metz: Directly, or via GOFF to Binder? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Thursday, April 6, 2023 3:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. With C++ (I guess), this is due to the fact that (writable) static data can be initialized not only by static initializers (which could be implemented by CSECT formatting), but by function calls, which needs init functions called after program load or task creation. So with C++, the requirement for program objects is driven by the language definition. But I'm not sure about this. For COBOL, it is kind of strange, and as I understood, it is only driven by some sort of debugging option which only can be handled by program objects. The PL/1 compiler group, FWIW, stated that they don't plan to require program objects in the near future. By the way: NORENT C can produce load modules, too. We still use NORENT C generating load modules (without the compiler options RENT, DLL, LONGNAME). I hope that this will be supported in the future, too ... and that "normal load modules" won't go away soon (I don't think it will be possible). It would by interesting, again, what PL/X does. Maybe the new fancy stuff is only for the customers :-) Kind regards Bernd Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 modules had naming conflicts with very old pre-LE runtimes, while SCEERUN modules did not. On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick wrote: What is the major difference between the SCEERUN and SCEERUN2 libraries? Is RUN2 for XPLINK and RUN for non-XPLINK? -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
Directly, or via GOFF to Binder? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Thursday, April 6, 2023 3:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. With C++ (I guess), this is due to the fact that (writable) static data can be initialized not only by static initializers (which could be implemented by CSECT formatting), but by function calls, which needs init functions called after program load or task creation. So with C++, the requirement for program objects is driven by the language definition. But I'm not sure about this. For COBOL, it is kind of strange, and as I understood, it is only driven by some sort of debugging option which only can be handled by program objects. The PL/1 compiler group, FWIW, stated that they don't plan to require program objects in the near future. By the way: NORENT C can produce load modules, too. We still use NORENT C generating load modules (without the compiler options RENT, DLL, LONGNAME). I hope that this will be supported in the future, too ... and that "normal load modules" won't go away soon (I don't think it will be possible). It would by interesting, again, what PL/X does. Maybe the new fancy stuff is only for the customers :-) Kind regards Bernd Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: > Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN > could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and > C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 > modules had naming conflicts with very old pre-LE runtimes, while SCEERUN > modules did not. > > On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick > wrote: > >> What is the major difference between the SCEERUN and SCEERUN2 libraries? >> Is RUN2 for XPLINK and RUN for non-XPLINK? >> -- 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: LE runtime
Are you sure that any of them can directly create load modules or program objects? I suspect that they still produce object modules, albeit in a modern format, and require, e.g., the Binder, as a final step. Does anybody remember SQUOZE <https://en.wikipedia.org/wiki/SQUOZE>? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Thursday, April 6, 2023 3:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime The "strange debugging option" for COBOL is, I believe, the ability to store the compressed source code data in a NOLOAD segment of a program object; something not supported with legacy load modules. A very useful thing, in my opinion. Much better than having the debug data in a separate module in a separate library. From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Thursday, April 6, 2023 1:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. With C++ (I guess), this is due to the fact that (writable) static data can be initialized not only by static initializers (which could be implemented by CSECT formatting), but by function calls, which needs init functions called after program load or task creation. So with C++, the requirement for program objects is driven by the language definition. But I'm not sure about this. For COBOL, it is kind of strange, and as I understood, it is only driven by some sort of debugging option which only can be handled by program objects. The PL/1 compiler group, FWIW, stated that they don't plan to require program objects in the near future. By the way: NORENT C can produce load modules, too. We still use NORENT C generating load modules (without the compiler options RENT, DLL, LONGNAME). I hope that this will be supported in the future, too ... and that "normal load modules" won't go away soon (I don't think it will be possible). It would by interesting, again, what PL/X does. Maybe the new fancy stuff is only for the customers :-) Kind regards Bernd Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: > Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN > could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and > C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 > modules had naming conflicts with very old pre-LE runtimes, while SCEERUN > modules did not. > > On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick > wrote: > >> What is the major difference between the SCEERUN and SCEERUN2 libraries? >> Is RUN2 for XPLINK and RUN for non-XPLINK? >> -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
The "strange debugging option" for COBOL is, I believe, the ability to store the compressed source code data in a NOLOAD segment of a program object; something not supported with legacy load modules. A very useful thing, in my opinion. Much better than having the debug data in a separate module in a separate library. From: IBM Mainframe Discussion List on behalf of Bernd Oppolzer Sent: Thursday, April 6, 2023 1:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. With C++ (I guess), this is due to the fact that (writable) static data can be initialized not only by static initializers (which could be implemented by CSECT formatting), but by function calls, which needs init functions called after program load or task creation. So with C++, the requirement for program objects is driven by the language definition. But I'm not sure about this. For COBOL, it is kind of strange, and as I understood, it is only driven by some sort of debugging option which only can be handled by program objects. The PL/1 compiler group, FWIW, stated that they don't plan to require program objects in the near future. By the way: NORENT C can produce load modules, too. We still use NORENT C generating load modules (without the compiler options RENT, DLL, LONGNAME). I hope that this will be supported in the future, too ... and that "normal load modules" won't go away soon (I don't think it will be possible). It would by interesting, again, what PL/X does. Maybe the new fancy stuff is only for the customers :-) Kind regards Bernd Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: > Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN > could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and > C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 > modules had naming conflicts with very old pre-LE runtimes, while SCEERUN > modules did not. > > On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick > wrote: > >> What is the major difference between the SCEERUN and SCEERUN2 libraries? >> Is RUN2 for XPLINK and RUN for non-XPLINK? >> -- 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: LE runtime
Thanks. This (to me) seems related to the fact that PL/I still can produce "classic" load modules, while COBOL and C++ create program objects, which must reside in PDSEs. With C++ (I guess), this is due to the fact that (writable) static data can be initialized not only by static initializers (which could be implemented by CSECT formatting), but by function calls, which needs init functions called after program load or task creation. So with C++, the requirement for program objects is driven by the language definition. But I'm not sure about this. For COBOL, it is kind of strange, and as I understood, it is only driven by some sort of debugging option which only can be handled by program objects. The PL/1 compiler group, FWIW, stated that they don't plan to require program objects in the near future. By the way: NORENT C can produce load modules, too. We still use NORENT C generating load modules (without the compiler options RENT, DLL, LONGNAME). I hope that this will be supported in the future, too ... and that "normal load modules" won't go away soon (I don't think it will be possible). It would by interesting, again, what PL/X does. Maybe the new fancy stuff is only for the customers :-) Kind regards Bernd Am 06.04.2023 um 00:26 schrieb Attila Fogarasi: Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 modules had naming conflicts with very old pre-LE runtimes, while SCEERUN modules did not. On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick wrote: What is the major difference between the SCEERUN and SCEERUN2 libraries? Is RUN2 for XPLINK and RUN for non-XPLINK? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
Thanks! From: IBM Mainframe Discussion List on behalf of Attila Fogarasi Sent: Wednesday, April 5, 2023 4:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE runtime Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 modules had naming conflicts with very old pre-LE runtimes, while SCEERUN modules did not. On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick wrote: > What is the major difference between the SCEERUN and SCEERUN2 libraries? > Is RUN2 for XPLINK and RUN for non-XPLINK? > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE runtime
Originally SCEERUN2 contained LE modules that had to be PDS/E while SCEERUN could be PDS. Also for PL/I and Fortran only SCEERUN is needed; Cobol and C/C++ needs SCEERUN2 as well as SCEERUN. Finally some of the SCEERUN2 modules had naming conflicts with very old pre-LE runtimes, while SCEERUN modules did not. On Thu, Apr 6, 2023 at 7:59 AM Frank Swarbrick wrote: > What is the major difference between the SCEERUN and SCEERUN2 libraries? > Is RUN2 for XPLINK and RUN for non-XPLINK? > > -- > 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
LE runtime
What is the major difference between the SCEERUN and SCEERUN2 libraries? Is RUN2 for XPLINK and RUN for non-XPLINK? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
Assuming that you are starting without #PHUFCA1 in the load module . REPLCAE csect-that-contains-IGZXFCA1 CHANGE IGZXFCA1(#PHUFCA1) INCLUDE lmod-lib(original-lmod) INCLUDE lmod-lib(#PHUFCA1) INCLUDE csect-containing-IGZXFCA1 ORDER however ENTRY where-ever NAME original(R) On Wed, 21 Dec 2016 11:34:16 +0100 Peter Hunkeler wrote: :>Cross-posted to IBM-Main and Assembler-List :> :>This thread is actually about hooking into existing load modules using the Binder's CHANGE and REPLACE funtions. It's been long time since I had to use the Binder to manipulate modules, so please bear with me. :> :> :> :>A bit of information on why I want to do this is provided for the ones interested. :> :> :>*However*, the reason for posting is mainly to understand if my idea how to manipulate load modules using the Binder should work the way I think it does. :> :> :>Please keep this thread related to the subject. Thanks. :> :> :> :> :> :>I'm back to the quest for the code that sets the decimal overflow mask bit in the PSW causing S0CA abends later on (see "How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)" thread started late November). :> :> :>Environment is Cobol V4 & V5. All CALLs are dynamic. Some hundred modules may well be loaded when the problem occurs. Modifying the to help diagnosing is not an option. :> :> :>I understand that LE has two sections of code dealing with dynamic CALLs: :> :>o IGZCFCC for pre V5.x Cobol :>o IGZXFCA1 for Cobol V5.x and later :> :> :>Those functions are always seen in a LE trackback at point where Cobol code makes dynamic CALLs. :> :> :>What I'm trying to do is to hook into those functions, and have some of my own code running before forwarding the call to either IGZCFCC or IGZXFCA1. My code would make an entry into an instorage wrap around trace table that I could investigate when the S0CA happens. :> :> :>I found IGZCFCC to be a CSECT in runtime module IGZCPAC, and IGZXFCA1 to be an ENTRY in CSECT IGZ@DCS2 in load module IGZXLPKA. IGZXFCA1 is being referred to from a couple of places. :> :> :> :>Using the Binder I want to have all references to IGZXFCA1 be redirected to my code, say #PHUFCA1. The code in #PHUFCA1 has a V-con to IGZXFCA1 so that it can forward the call later. :> :>I think I cannot simply CHANGE IGZXFCA1 to #PHUFCA1, because that would also change the reference to IGZXFCA1 in my own code, and this is not what I want. I currently think I need three Binder runs as follows: :> :> :>1. Remove Csect IGZ@DCS2 from IGZXPLKA and at the same time change references to IGZXFCA1 to #PHUFCA1 by specifying: :> :>REPLACE IGZ@DCS2 :>CHANGE IGZXFCA1(#PHUFCA1) :>INCLUDE SYSLIB(IGZXPLKA) :>NAME IGZPLKA#(R) :> :> :>and run the binder with NCAL, because some references to labels in IGZ@DCS2 other than IGZXFCA1 will stay unresolved. SYSLIB is CEE.SCEERUN, SYSLMOD is my own load library. :> :> :>2. Extract Csect IGZ@DCS2 from IGZXPLKA: :> :>REPLACE IGZ@INI2 :>... :>REPLACE CEEBINT :>INCLUDE SYSLIB(IGZXPLKA) :>NAME IGZ@DCS2(R) :> :> :>One REPLACE for each Csect in IGZXPLKA, except from IGZ@DCS2. :>Again run with NCAL and libraries as in step 1. :> :> :> :>3. Create new IGZXPLKA including my code in the ASMACL job: :> :>INCLUDE SYSLIB(IGZXPLK#)from step 1 :>INCLUDE SYSLIB(IGZ@DCS2) from step 2 :>object deck from the assembly creating #PHUFCA1 :>NAME IGZXPLKA(R) :> :> :>SYSLIB and SYSLMOD is my own load library. :> :> :> :>I'm not getting the desired result. I'm getting abends before my code is invoke, so I be missing something or missinterpreting how the binder works. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Using the Binder to hook into an LE runtime module.
>A likely place that this is set is in the ESPIE service routine because that PIC was one of the interrupts for which ESPIE management was requested. Peter, I'm not sure I understand what you want to tell me. In a pure Cobol environment, the decimal overflow mask is not set, because Cobol does not want overflows to thow an exception. LE seems to handle this properly. On the other hand C/C++ requires an exception to be thrown, so the program mask bit is set by LE. I understand that LE always set the ESPIE to catch decial overflow exceptions (00A) (and others). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
For those interested: I have some working code. The code uses a Name/Token pair to a) understand whether called the first time or not, and b) to keep the address of a (wrap around) trace table (obtained upon first call). It then writes some information including the program mask obtained via IPM instruction into the table. The address of the trace table is displayed via WTO so that the table can be inspected in a dump. I'm curious whether I will, and what I will find. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Using the Binder to hook into an LE runtime module.
>The issue Peter is facing is that a certain amount of confusion ensues when a >particular piece of software notices the 00A coming from a COBOL program, >because the overflow bit has become set on and has somehow avoided means to >turn it off before a C/C++ program returns to COBOL. Reduced to the minimum: Another software's condition handler is getting control *before* LE's. This one does *not* ignore the program check 0A, but closes, backs out and disconnects, then percolates to LE. LE in turn knows it should ignore the program check 0A for Cobol, and returns control to the application code. The application later fails with random symptoms because of the "closing" actions. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Using the Binder to hook into an LE runtime module.
>z/OS Language Environment Programming Reference SA38-0683-0CEEHDLR registers a user-written condition handler for the current stack frame. Oh, I see. Now I understand what you meant. I know about the CEEHDLR, but I do not need a contition handler. What I need is kind of a "trace of the PSWs program mask call by call". This is not something that LE is prepared to support (why would it?). But thanks anyway. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
The problem with attempting to use an LE Handler from a COBOL program, as was covered in the previous topic, is that LE knows that COBOL doesn't "respect" the 00A, so LE just spends some time ignoring it, rather than presenting it to a registered handler. So for inter-language communication to C/C++ and PL/I, there is a heavy performance hit if there is a lot of "overflow" in the COBOL program(s), which is the time taken by LE to "ignore" it, because of COBOL. See https://share.confex.com/share/116/webprogram/Handout/Session8833/S8833TR.pdf pp19-20, for instance. The issue Peter is facing is that a certain amount of confusion ensues when a particular piece of software notices the 00A coming from a COBOL program, because the overflow bit has become set on and has somehow avoided means to turn it off before a C/C++ program returns to COBOL. I think I've got that right... :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
Check out z/OS Language Environment Programming Reference SA38-0683-0CEEHDLR registers a user-written condition handler for the current stack frame. The user condition handler is invoked when: It is registered for the current stack frame by CEEHDLR, and The Language Environment condition manager requests the condition handler associated with the current stack frame handle the condition. My understanding is it allows one to get control before LE during certain events. I do not have any more details than that. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Hunkeler > Sent: Wednesday, December 21, 2016 11:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: AW: Re: Using the Binder to hook into an LE runtime module. > > > >There is an LE User Handle Function that should allow you to insert > >what you > want to do. > > > Not sure exactl what function you mean, but I doubt LE is offering an official > way to do what I need. Can you tell me more about that function? I'd like to > read it up. > > > > >Otherwise, this seems to be a question better for IBM LE to respond to. > >Lots of > knowledge on the lists, but this may wander closer to internal IBM information > on how LE would work in this case. > > > Unfortunately, I'm not in the position to directly talk to IBM. If I was, I > had long opened a non-defect PMR to discuss the problem and possible ways to > get hold of the cause with IBMs LE lab people. I don't want to go into more > detail on why this does not happen here. > > > So, here am I with my idea, and as said in a later post, I am a big step > further once I found (the stupid) error I made. Going to code the traceing im > my module now > > > -- > Peter Hunkeler > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
I'm back to the quest for the code that sets the decimal overflow mask bit in the PSW causing S0CA abends later on (see "How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)" thread started late November). A likely place that this is set is in the ESPIE service routine because that PIC was one of the interrupts for which ESPIE management was requested. 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
AW: Re: Using the Binder to hook into an LE runtime module.
>There is an LE User Handle Function that should allow you to insert what you want to do. Not sure exactl what function you mean, but I doubt LE is offering an official way to do what I need. Can you tell me more about that function? I'd like to read it up. >Otherwise, this seems to be a question better for IBM LE to respond to. Lots >of knowledge on the lists, but this may wander closer to internal IBM information on how LE would work in this case. Unfortunately, I'm not in the position to directly talk to IBM. If I was, I had long opened a non-defect PMR to discuss the problem and possible ways to get hold of the cause with IBMs LE lab people. I don't want to go into more detail on why this does not happen here. So, here am I with my idea, and as said in a later post, I am a big step further once I found (the stupid) error I made. Going to code the traceing im my module now -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
There is an LE User Handle Function that should allow you to insert what you want to do. Otherwise, this seems to be a question better for IBM LE to respond to. Lots of knowledge on the lists, but this may wander closer to internal IBM information on how LE would work in this case. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Hunkeler > Sent: Wednesday, December 21, 2016 3:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Using the Binder to hook into an LE runtime module. > > Cross-posted to IBM-Main and Assembler-List > > This thread is actually about hooking into existing load modules using the > Binder's CHANGE and REPLACE funtions. It's been long time since I had to use > the Binder to manipulate modules, so please bear with me. > > > > A bit of information on why I want to do this is provided for the ones > interested. > > > *However*, the reason for posting is mainly to understand if my idea how to > manipulate load modules using the Binder should work the way I think it does. > > > Please keep this thread related to the subject. Thanks. > > > > > > I'm back to the quest for the code that sets the decimal overflow mask bit in > the PSW causing S0CA abends later on (see "How to Identify modules as C/C++ or > Cobol, or ASM from dump (SYSMDUMP)" thread started late November). > > > Environment is Cobol V4 & V5. All CALLs are dynamic. Some hundred modules may > well be loaded when the problem occurs. Modifying the to help diagnosing is > not an option. > > > I understand that LE has two sections of code dealing with dynamic CALLs: > > o IGZCFCC for pre V5.x Cobol > o IGZXFCA1 for Cobol V5.x and later > > > Those functions are always seen in a LE trackback at point where Cobol code > makes dynamic CALLs. > > > What I'm trying to do is to hook into those functions, and have some of my own > code running before forwarding the call to either IGZCFCC or IGZXFCA1. My code > would make an entry into an instorage wrap around trace table that I could > investigate when the S0CA happens. > > > I found IGZCFCC to be a CSECT in runtime module IGZCPAC, and IGZXFCA1 to be an > ENTRY in CSECT IGZ@DCS2 in load module IGZXLPKA. IGZXFCA1 is being referred to > from a couple of places. > > > > Using the Binder I want to have all references to IGZXFCA1 be redirected to my > code, say #PHUFCA1. The code in #PHUFCA1 has a V-con to IGZXFCA1 so that it > can forward the call later. > > I think I cannot simply CHANGE IGZXFCA1 to #PHUFCA1, because that would also > change the reference to IGZXFCA1 in my own code, and this is not what I want. > I currently think I need three Binder runs as follows: > > > 1. Remove Csect IGZ@DCS2 from IGZXPLKA and at the same time change references > to IGZXFCA1 to #PHUFCA1 by specifying: > > REPLACE IGZ@DCS2 > CHANGE IGZXFCA1(#PHUFCA1) > INCLUDE SYSLIB(IGZXPLKA) > NAME IGZPLKA#(R) > > > and run the binder with NCAL, because some references to labels in IGZ@DCS2 > other than IGZXFCA1 will stay unresolved. SYSLIB is CEE.SCEERUN, SYSLMOD is my > own load library. > > > 2. Extract Csect IGZ@DCS2 from IGZXPLKA: > > REPLACE IGZ@INI2 > ... > REPLACE CEEBINT > INCLUDE SYSLIB(IGZXPLKA) > NAME IGZ@DCS2(R) > > > One REPLACE for each Csect in IGZXPLKA, except from IGZ@DCS2. > Again run with NCAL and libraries as in step 1. > > > > 3. Create new IGZXPLKA including my code in the ASMACL job: > > INCLUDE SYSLIB(IGZXPLK#)from step 1 > INCLUDE SYSLIB(IGZ@DCS2) from step 2 > object deck from the assembly creating #PHUFCA1 NAME IGZXPLKA(R) > > > SYSLIB and SYSLMOD is my own load library. > > > > I'm not getting the desired result. I'm getting abends before my code is > invoke, so I be missing something or missinterpreting how the binder works. > > -- > Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module. (Solved)
I have found the mistake. Sorry for bothering you. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Using the Binder to hook into an LE runtime module.
>What abends? S0CA or others? Do you see other messages, say on SYSLOG? As said, I would like to understand if a) what I want to do is feasible with the binder, and b) if whether my approach should work. The abend is not of interest, it only documents that my code is not being invoked at the point I thought is should be. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder to hook into an LE runtime module.
Peter Hunkeler wrote: >I'm not getting the desired result. I'm getting abends before my code is >invoke, so I be missing something or missinterpreting how the binder works. What abends? S0CA or others? Do you see other messages, say on SYSLOG? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Using the Binder to hook into an LE runtime module.
Cross-posted to IBM-Main and Assembler-List This thread is actually about hooking into existing load modules using the Binder's CHANGE and REPLACE funtions. It's been long time since I had to use the Binder to manipulate modules, so please bear with me. A bit of information on why I want to do this is provided for the ones interested. *However*, the reason for posting is mainly to understand if my idea how to manipulate load modules using the Binder should work the way I think it does. Please keep this thread related to the subject. Thanks. I'm back to the quest for the code that sets the decimal overflow mask bit in the PSW causing S0CA abends later on (see "How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)" thread started late November). Environment is Cobol V4 & V5. All CALLs are dynamic. Some hundred modules may well be loaded when the problem occurs. Modifying the to help diagnosing is not an option. I understand that LE has two sections of code dealing with dynamic CALLs: o IGZCFCC for pre V5.x Cobol o IGZXFCA1 for Cobol V5.x and later Those functions are always seen in a LE trackback at point where Cobol code makes dynamic CALLs. What I'm trying to do is to hook into those functions, and have some of my own code running before forwarding the call to either IGZCFCC or IGZXFCA1. My code would make an entry into an instorage wrap around trace table that I could investigate when the S0CA happens. I found IGZCFCC to be a CSECT in runtime module IGZCPAC, and IGZXFCA1 to be an ENTRY in CSECT IGZ@DCS2 in load module IGZXLPKA. IGZXFCA1 is being referred to from a couple of places. Using the Binder I want to have all references to IGZXFCA1 be redirected to my code, say #PHUFCA1. The code in #PHUFCA1 has a V-con to IGZXFCA1 so that it can forward the call later. I think I cannot simply CHANGE IGZXFCA1 to #PHUFCA1, because that would also change the reference to IGZXFCA1 in my own code, and this is not what I want. I currently think I need three Binder runs as follows: 1. Remove Csect IGZ@DCS2 from IGZXPLKA and at the same time change references to IGZXFCA1 to #PHUFCA1 by specifying: REPLACE IGZ@DCS2 CHANGE IGZXFCA1(#PHUFCA1) INCLUDE SYSLIB(IGZXPLKA) NAME IGZPLKA#(R) and run the binder with NCAL, because some references to labels in IGZ@DCS2 other than IGZXFCA1 will stay unresolved. SYSLIB is CEE.SCEERUN, SYSLMOD is my own load library. 2. Extract Csect IGZ@DCS2 from IGZXPLKA: REPLACE IGZ@INI2 ... REPLACE CEEBINT INCLUDE SYSLIB(IGZXPLKA) NAME IGZ@DCS2(R) One REPLACE for each Csect in IGZXPLKA, except from IGZ@DCS2. Again run with NCAL and libraries as in step 1. 3. Create new IGZXPLKA including my code in the ASMACL job: INCLUDE SYSLIB(IGZXPLK#)from step 1 INCLUDE SYSLIB(IGZ@DCS2) from step 2 object deck from the assembly creating #PHUFCA1 NAME IGZXPLKA(R) SYSLIB and SYSLMOD is my own load library. I'm not getting the desired result. I'm getting abends before my code is invoke, so I be missing something or missinterpreting how the binder works. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Guys, Do you know if the program can test for CEEOPTS ? Scott On Thursday, March 31, 2016, Frank Swarbrick wrote: > Oh! > I guess we either had that by default, or we changed it some time in the > distant past. > > D CEE,CEEROPT > CEE3745I 17.18.59 DISPLAY CEEROPT > CEE=(00) 092 > PARMLIB(CEEPRM00) CEEROPT (ALL) > > > > Date: Thu, 31 Mar 2016 13:16:06 -0500 > > From: peter_tene...@farmfamily.com > > Subject: Re: Custom LE runtime parms for an entire batch job > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > I was able to get this working by issuing the SETCEE CEEROPT,ALL > command. Now finding my custom CEEWROPT table within the JOBLIB. > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Oh! I guess we either had that by default, or we changed it some time in the distant past. D CEE,CEEROPT CEE3745I 17.18.59 DISPLAY CEEROPT CEE=(00) 092 PARMLIB(CEEPRM00) CEEROPT (ALL) > Date: Thu, 31 Mar 2016 13:16:06 -0500 > From: peter_tene...@farmfamily.com > Subject: Re: Custom LE runtime parms for an entire batch job > To: IBM-MAIN@LISTSERV.UA.EDU > > I was able to get this working by issuing the SETCEE CEEROPT,ALL command. Now > finding my custom CEEWROPT table within the JOBLIB. > > -- > 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: Custom LE runtime parms for an entire batch job
I was able to get this working by issuing the SETCEE CEEROPT,ALL command. Now finding my custom CEEWROPT table within the JOBLIB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Tom Marchant wrote: >Do you have a STEPLIB? MVS will use JOBLIB or STEPLIB, not both. Very true. In z/OS 2.1 JCL Ref, this quote to clarify: "If you include a STEPLIB DD statement for a job step and a JOBLIB DD statement for the entire job, the system first searches the step library and then the system library for the requested program. The system ignores the job library for a step that has a STEPLIB DD statement." Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
I have assembled CEEROPT into a PDS that is in the JOBLIB statement of the job. I have a small program running in the job that abends... when I look in the LE dump for the job at the current LE runtime settings, I do not see my changes (overrides). For example here is the report from the job… ALL31 should have been changed to on: Run-Time Options Report: LAST WHERE SET OPTION --- Installation default ABPERC(NONE) Installation default ABTERMENC(ABEND) PARMLIB(CEEPRM00) NOAIXBLD PARMLIB(CEEPRM00)ALL31(OFF) PARMLIB(CEEPRM00)ANYHEAP(32768,16384,ANYWHERE,FREE) Installation default NOAUTOTASK PARMLIB(CEEPRM00)BELOWHEAP(32768,16384,FREE) Installation default CBLOPTS(ON) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
On Thu, 31 Mar 2016 10:09:28 -0500, Peter Ten Eyck wrote: >Hmm, that's I what I thought. Does not seem to be picking up my LE changes? Do you have a STEPLIB? MVS will use JOBLIB or STEPLIB, not both. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Hmm, that's I what I thought. Does not seem to be picking up my LE changes? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
That's exactly how it works. The first CEEROPT module found in the JOBLIB concatenation will be respected. > Date: Thu, 31 Mar 2016 09:38:43 -0500 > From: peter_tene...@farmfamily.com > Subject: Re: Custom LE runtime parms for an entire batch job > To: IBM-MAIN@LISTSERV.UA.EDU > > Yes, thanks. I was hoping reference CEEROPT in a batch job(s) by placing it > in a PDS within the JOBLIB concatenation. Can I do this? ...or do I need to > add a DD name to the JCL? > > -- > 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: Custom LE runtime parms for an entire batch job
Yes, thanks. I was hoping reference CEEROPT in a batch job(s) by placing it in a PDS within the JOBLIB concatenation. Can I do this? ...or do I need to add a DD name to the JCL? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
Yep, we have STC we do that with using a park override or the external file specified with the ddname. Scott On Wednesday, March 30, 2016, Frank Swarbrick wrote: > As an example, here is a version of the CEEWROPT example job that will > create a CEEROPT module and store it in a library named > PGMR.TOOLSIB.RTEREUS: > > //CEEWROPT JOB 1,'5694-A01',MSGLEVEL=(1,1),NOTIFY=&SYSUID > //STEP1 EXEC PGM=ASMA90 > //SYSPRINT DD SYSOUT=* > //SYSLIN DD DSN=&&TEMPOBJ,DISP=(,PASS) > //SYSLIB DD DSN=CEE.SCEEMAC,DISP=SHR <<<<<< > // DD DSN=SYS1.MACLIB,DISP=SHR ++ > //SYSIN DD * > CEEROPT CSECT , > CEEROPT RMODE ANY > CEEXOPT RTEREUS=((ON),NONOVR) > END CEEROPT > /* > //STEP2EXEC PGM=IEWL, > // PARM='NCAL,RENT,LIST,XREF,LET,MAP,SIZE=(K,96K)' > //SYSPRINT DD SYSOUT=* > //SYSLMOD DD DSNAME=PGMR.TOOLSLIB.RTEREUS(CEEROPT),DISP=SHR > //SYSLIN DD DSN=&&TEMPOBJ,DISP=(OLD,PASS) > > > > Date: Wed, 30 Mar 2016 15:56:11 -0600 > > From: frank.swarbr...@outlook.com > > Subject: Re: Custom LE runtime parms for an entire batch job > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > I think you should be able to use a CEEROPT (Region-Specific Run-Time > Options Load Module). > > > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/createropt.htm%23createropt > > > > > > > Date: Wed, 30 Mar 2016 12:54:37 -0500 > > > From: peter_tene...@farmfamily.com > > > Subject: Custom LE runtime parms for an entire batch job > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > > > How would I run a batch job (all steps) with a unique set of LE > runtime parms without using CEEOPTS in each step? > > > > > > Could I point to a custom CEEDOPT via JOBLIB? > > > > > > Note: OS - z/OS 1.13 > > > > > > -- > > > 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 > > -- > 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: Custom LE runtime parms for an entire batch job
As an example, here is a version of the CEEWROPT example job that will create a CEEROPT module and store it in a library named PGMR.TOOLSIB.RTEREUS: //CEEWROPT JOB 1,'5694-A01',MSGLEVEL=(1,1),NOTIFY=&SYSUID //STEP1 EXEC PGM=ASMA90 //SYSPRINT DD SYSOUT=* //SYSLIN DD DSN=&&TEMPOBJ,DISP=(,PASS) //SYSLIB DD DSN=CEE.SCEEMAC,DISP=SHR <<<<<< // DD DSN=SYS1.MACLIB,DISP=SHR ++ //SYSIN DD * CEEROPT CSECT , CEEROPT RMODE ANY CEEXOPT RTEREUS=((ON),NONOVR) END CEEROPT /* //STEP2EXEC PGM=IEWL, // PARM='NCAL,RENT,LIST,XREF,LET,MAP,SIZE=(K,96K)' //SYSPRINT DD SYSOUT=* //SYSLMOD DD DSNAME=PGMR.TOOLSLIB.RTEREUS(CEEROPT),DISP=SHR //SYSLIN DD DSN=&&TEMPOBJ,DISP=(OLD,PASS) > Date: Wed, 30 Mar 2016 15:56:11 -0600 > From: frank.swarbr...@outlook.com > Subject: Re: Custom LE runtime parms for an entire batch job > To: IBM-MAIN@LISTSERV.UA.EDU > > I think you should be able to use a CEEROPT (Region-Specific Run-Time Options > Load Module). > > https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/createropt.htm%23createropt > > > > Date: Wed, 30 Mar 2016 12:54:37 -0500 > > From: peter_tene...@farmfamily.com > > Subject: Custom LE runtime parms for an entire batch job > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > How would I run a batch job (all steps) with a unique set of LE runtime > > parms without using CEEOPTS in each step? > > > > Could I point to a custom CEEDOPT via JOBLIB? > > > > Note: OS - z/OS 1.13 > > > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Custom LE runtime parms for an entire batch job
I think you should be able to use a CEEROPT (Region-Specific Run-Time Options Load Module). https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/createropt.htm%23createropt > Date: Wed, 30 Mar 2016 12:54:37 -0500 > From: peter_tene...@farmfamily.com > Subject: Custom LE runtime parms for an entire batch job > To: IBM-MAIN@LISTSERV.UA.EDU > > How would I run a batch job (all steps) with a unique set of LE runtime parms > without using CEEOPTS in each step? > > Could I point to a custom CEEDOPT via JOBLIB? > > Note: OS - z/OS 1.13 > > -- > 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
Custom LE runtime parms for an entire batch job
How would I run a batch job (all steps) with a unique set of LE runtime parms without using CEEOPTS in each step? Could I point to a custom CEEDOPT via JOBLIB? Note: OS - z/OS 1.13 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
