Oppolzer - Informatik / Blog

We had the rule for some 20 years that it is forbidden or at least
not recommended to do calls to internal procs. Two reasons for that:

a) performance; the management of the save areas, DSAs, auto storage
by the PL/1 runtime seemed far too expensive. Some measurements in the
early 80s told about a factor of 5, compared to normal OS linkage as
done in our ASSEMBLER programs

b) dump reading; the auto storage of the lower procs was hard to find,
because the compiler listing did not support the SYSUDUMP analysis well,
and the forward chain of the save areas was broken in this case

Instead, our system programmers build some sort of lightweight procedures
(without local storage) based on PL/1 label variables using clever macros.
This was much faster - in the 1980s - than normal procs.

(of course, there were always - dynamic - calls to external procs. The
recommendation was: split your module in more little parts, if it grows
too large, and call the parts dynamically. But don't code large modules
which use internal procs)

We had to kick this recommendation in the 200x years, when the EP compilers
appeared and we discovered, that the use of the label variables disturbed
the optimizing effort of the new compilers. When there are too many label
variables in the program, the new compiler simply switches off the
optimization. So we had to do a complete turn-around and move into the
other direction. In the meantime, most of the programs are converted to
"normal" procs. The "label variable lightweight proc mechanism" is now
flagged with a return code of 8 on the compile and has to be corrected.

Kind regards

Bernd




Am Mittwoch, 7. März 2012 14:59 schrieben Sie:
>
> History is often a strange animal where the result is
> never forgotten, but the cause becomes lost in the smoke.
> Many PL/I do/don't 'rules' were because of this.  Another
> example was the use of small subroutines and CALLs rather
> than writing the same code with GO TO...
>
> Again, I'm not advocating; just stating some [unfortunate]
> facts.
>
> C.
>