Same rule at my recent site;
with "new" PL/1, it is even possible to make all STATIC definitions NONASSIGNABLE
by default, so that you have to code STATIC ASGN, if you want a STATIC variable
to be ASSIGNABLE.
Often the PL/1 knowledge is dramatically limited by the site standards of the site
that you are working at ... sometimes for decades. I recall a site, where all variables
were static due to DEFAULT RANGE ... the reason behind that was, that AUTO variables
are harder to find in the SYSUDUMP (static variables are in the STATIC CSECT,
so no problem).
Or another site, where there were no internal PROCEDUREs allowed, only calls to
external modules, so the developers there knew nothing about local variables, the block
concept and even parameter passing mechanisms besides the very basic
passing of addresses of structures ... that's all they did, always to external modules.
Inside the modules, all variables were global, only one procedure, normally.
There were program blocks similar to procedures based on label variables, but without
When these colleagues were moved to another system at the same company,
which used kind of "standard" PL/1, they had to learn much of the PL/1 basics
from the start ... after working 20 years with "reduced" PL/1, in some cases.
Am 17.01.2015 um 16:36 schrieb P.H.:
> Difficult, if you start as a trainee at a company that decided to force that all STATIC variables
> be set to NONASSIGNABLE. They very much look like constants then. (Been there, seen that.)
> I admit it is not the STATIC but the NONASSIGNABLE keyword that makes the constants,
> but a trainee migth not yet appreciate that fine distinction.