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 ha
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 -070
st
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 th
-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
y, 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 prog
a.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 dat
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
-
>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 see
f 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 Bin
il 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 (w
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++ func
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 a
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
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) s
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
S
: 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 d
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 r
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 c
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
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
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
mo
21 matches
Mail list logo
