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 [[email protected]] on behalf of Frank Swarbrick [[email protected]] Sent: Thursday, April 6, 2023 3:57 AM To: [email protected] 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 <[email protected]> on behalf of Bernd Oppolzer <[email protected]> Sent: Thursday, April 6, 2023 1:18 AM To: [email protected] <[email protected]> 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 <[email protected]> > 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
