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
local variables.
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.
Kind regards
Bernd
Am 17.01.2015 um 16:36 schrieb Peter Hunkeler:
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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN