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
