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.ua.edu with the message: INFO IBM-MA
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
