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