There may have been issues with LCS (Large Core Storage).
Our site had 128K core with 1 Mb LCS.
OS/360 took up almost all the core storage.
Access to LCS was much slower than to core store.
We therefore made local PL/I variables static
(except for arrays, which typically had variable dimensions).
On 2023-09-07 13:32, Bernd Oppolzer wrote:
Thinking a little bit more about this:
the insurance company used auto variables heavily, BUT:
until the 2010 time frame, they didn't allow (or: suggested not to use)
INTERNAL PL/1 procedures !!
Instead they had some home grown macros based on label variables, which
worked much the same like
procedure calls, but the "program blocks", which were built using these
macros - of course - didn't have local variables;
all variables are GLOBAL.
Using this technique, performance issues during procedure startup are
no problem, of course.
In 2010, one of my co-workers (and a friend of mine) checked out the
performance of these "program blocks"
and found out that the heavy use of label variables COMPROMISES the
optimizing strategies of the modern compilers,
so that now the "program blocks" based on label variables are MUCH
SLOWER than original PL/1 procedures.
That's why the company now changed the recommendation and asked all
programmers to change the
programs from the old "program blocks" to normal procedures (when doing
maintenance to the programs).
This led to significant better performance in some cases (especially in
large Batch programs with many "program blocks").
There are still many programs using the old "program blocks", and we
are now thinking about forcing
the transformation process in the next months. When compiling a program
using the old feature,
you get a return code of 8 and a compiler message, but the code is
produced, anyway.
Kind regards
Bernd
Am 07.09.2023 um 05:13 schrieb Bernd Oppolzer:
Am 07.09.2023 um 01:40 schrieb Leonard D Woren:
Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each
subroutine call. Too much overhead to call even one subroutine for
each of 30K records on a 360/91 & MVT.
Well, my recollection is that if you had only Static storage, no
Automatic storage, it didn't do a GETMAIN.
Or was that an enhancement in the new PL/I compiler? Was that PLIX?
Yeah, not using stuff for decades can cause memory fade.
/Leonard
I first came into contact with PL/1 in the end of the 1980s at the
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced
pretty amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company
started with PL/1 in the beginning of the 1980s,
before that is was an ASSEMBLER only shop. (C came later, from 1992
on).
1992 (and 1994 again) I was asked to do a dump analysis class in
another PL/1 company. They indeed had
DEFEAULT RANGE(*) STATIC;
in almost every program. I didn't understand the reason at that time
and thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load
module) are much easier to find than
auto variables (living in the stack). But now I have the impression
that this could have simply been a performance
issue in the beginning.
Kind regards
Bernd
----------------------------------------------------------------------
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
