Editing PL/I (section)

==Special topics in PL/I==

===Storage classes===
PL/I provides several 'storage classes' to indicate how the lifetime of variables' storage is to be managed{{snd}} <code>STATIC</code>, <code>AUTOMATIC</code>, <code>CONTROLLED</code>, and <code>BASED</code>, and <code>AREA</code>.

<code>STATIC</code> data is allocated and initialized at load-time, as is done in [[COBOL]] "working-storage" and early [[Fortran]]. This is the default for <code>EXTERNAL</code> variables (similar to C “extern” or Fortran “named common"),

<code>AUTOMATIC</code> is PL/I's default storage class for <code>INTERNAL</code> variables, similar to that of other block-structured languages influenced by [[ALGOL]], like the "auto" storage class in the [[C (programming language)|C]] language, the default storage allocation in [[Pascal (programming language)|Pascal]], and "local-storage" in IBM COBOL. Storage for <code>AUTOMATIC</code> variables is allocated upon entry into the procedure, <code>BEGIN</code>-block, or <code>ON</code>-unit in which they are declared. The compiler and runtime system allocate memory for a [[stack frame]] to contain them and other housekeeping information. If a variable is declared with an <code>INITIAL</code>-attribute, code to set it to an initial value is executed at this time. Care is required to manage the use of initialization properly. Large amounts of code can be executed to initialize variables every time a scope is entered, especially if the variable is an array or structure. Storage for <code>AUTOMATIC</code> variables is freed at block exit.

<code>STATIC</code>, <code>CONTROLLED</code>, or <code>BASED</code> variables are used to retain variables' contents between invocations of a procedure or block. 

<code>CONTROLLED</code> storage is managed using a stack, but the pushing and popping of allocations on the stack is managed by the programmer, using <code>ALLOCATE</code> and <code>FREE</code> statements.

Storage for <code>BASED</code> variables is also managed using <code>ALLOCATE</code>/<code>FREE</code>, but instead of a stack these allocations have independent lifetimes and are addressed through <code>OFFSET</code> or <code>POINTER</code> variables. <code>BASED</code> variables can also be used to address arbitrary storage areas by setting the associated <code>POINTER</code> variable, for example following a [[linked list]].

The <code>AREA</code> attribute is used to declare programmer-defined [[heap (programming)|heaps]]. Data can be allocated and freed within a specific area, and the area can be deleted, read, and written as a unit.<ref name="IBMLR43">{{cite book |publisher=IBM |title=Enterprise PL/I for z/OS PL/I for AIX Rational Developer for System z PL/I for Windows: Language Reference |date=September 2012 |edition=Third |id=SC14-7285-02 |url=https://publibfp.dhe.ibm.com/epubs/pdf/ibm4lr02.pdf |access-date=July 9, 2023}}</ref>{{rp|pp.235– 274}}

===Storage type sharing===
There are several ways of accessing allocated storage through different data declarations. Some of these are well defined and safe, some can be used safely with careful programming, and some are inherently unsafe or machine dependent.<ref name=IBMLR43 />{{rp|pp.262–267,178–180}}

Passing a variable as an argument to a parameter by reference allows the argument's allocated storage to be referenced using the parameter. The {{tt|DEFINED}} attribute (e.g., <code>DCL A(10,10), B(2:9,2:9) DEFINED A</code>) allows part or all of a variable's storage to be used with a different, but consistent, declaration. The language definition includes a {{tt|CELL}} attribute (later renamed {{tt|UNION}}) to allow different definitions of data to share the same storage. This was not supported by many early IBM compilers. These usages are safe and machine independent.

Record I/O and list processing produce situations where the programmer needs to fit a declaration to the storage of the next record or item, before knowing what type of data structure it has. Based variables and pointers are key to such programs. The data structures must be designed appropriately, typically using fields in a data structure to encode information about its type and size. The fields can be held in the preceding structure or, with some constraints, in the current one. Where the encoding is in the preceding structure, the program needs to allocate a based variable with a declaration that matches the current item (using expressions for extents where needed). Where the type and size information are to be kept in the current structure ("self defining structures") the type-defining fields must be ahead of the type dependent items and in the same place in every version of the data structure. The {{tt|REFER}}-option is used for self-defining extents (e.g., string lengths as in <code>DCL 1 A BASED, 2 N BINARY, 2 B CHAR(LENGTH REFER A.N.)</code>, etc {{snd}} where {{tt|LENGTH}} is used to allocate instances of the data structure. For self-defining structures, any typing and {{tt|REFER}}ed fields are placed ahead of the "real" data. If the records in a data set, or the items in a list of data structures, are organised this way they can be handled safely in a machine independent way.

PL/I implementations do not (except for the PL/I Checkout compiler) keep track of the data structure used when storage is first allocated. Any {{tt|BASED}} declaration can be used with a pointer into the storage to access the storage{{snd}} inherently unsafe and machine dependent. However, this usage has become important for "pointer arithmetic" (typically adding a certain amount to a known address). This has been a contentious subject in computer science. In addition to the problem of wild references and buffer overruns, issues arise due to the alignment and length for data types used with particular machines and compilers. Many cases where pointer arithmetic might be needed involve finding a pointer to an element inside a larger data structure. The {{tt|ADDR}} function computes such pointers, safely and machine independently.

Pointer arithmetic may be accomplished by aliasing a binary variable with a pointer as in
<pre>DCL P POINTER, N FIXED BINARY(31) BASED(ADDR(P));
N=N+255;</pre>
It relies on pointers being the same length as <code>FIXED BINARY(31)</code> integers and aligned on the same boundaries.

With the prevalence of C and its free and easy attitude to pointer arithmetic, recent IBM PL/I compilers allow pointers to be used with the addition and subtraction operators to giving the simplest syntax (but compiler options can disallow these practices where safety and machine independence are paramount).

===ON-units and exception handling===
When PL/I was designed, programs only ran in batch mode, with no possible intervention from the programmer at a terminal. An exceptional condition such as division by zero would abort the program yielding only a hexadecimal core dump. PL/I exception handling, via {{tt|ON}}-units, allowed the program to stay in control in the face of hardware or operating system exceptions and to recover debugging information before closing down more gracefully. As a program became properly debugged, most of the exception handling could be removed or disabled: this level of control became less important when conversational execution became commonplace.

Computational exception handling is enabled and disabled by condition prefixes on statements, blocks (including {{tt|ON}}-units) and procedures. – e.g., <code>(SIZE, NOSUBSCRIPTRANGE): A(I)=B(I)*C; </code>. Operating system exceptions for Input/Output and storage management are always enabled.

The {{tt|ON}}-unit is a single statement or {{tt|BEGIN}}-block introduced by an {{tt|ON}}-statement. Executing the {{tt|ON}} statement enables the condition specified, e.g., <code>ON ZERODIVIDE ON</code>-unit. When the exception for this condition occurs and the condition is enabled, the {{tt|ON}}-unit for the condition is executed. {{tt|ON}}-units are inherited down the call chain. When a block, procedure or {{tt|ON}}-unit is activated, the {{tt|ON}}-units established by the invoking activation are inherited by the new activation. They may be over-ridden by another {{tt|ON}}-statement and can be reestablished by the {{tt|REVERT}}-statement. The exception can be simulated using the {{tt|SIGNAL}}-statement – e.g., to help debug the exception handlers. The dynamic inheritance principle for {{tt|ON}}-units allows a routine to handle the exceptions occurring within the subroutines it uses.

If no {{tt|ON}}-unit is in effect when a condition is raised a standard system action is taken (often this is to raise the {{tt|ERROR}} condition). The system action can be reestablished using the {{tt|SYSTEM}} option of the {{tt|ON}}-statement. With some conditions it is possible to complete executing an ON-unit and return to the point of interrupt (e.g., the {{tt|STRINGRANGE}}, {{tt|UNDERFLOW}}, {{tt|CONVERSION}}, {{tt|OVERFLOW}}, {{tt|AREA}}, and {{tt|FILE}} conditions) and resume normal execution. With other conditions such as <code>(SUBSCRIPTRANGE)</code>, the {{tt|ERROR}} condition is raised when this is attempted. An ON-unit may be terminated with a <code>GO TO</code> preventing a return to the point of interrupt, but permitting the program to continue execution elsewhere as determined by the programmer.

An {{tt|ON}}-unit needs to be designed to deal with exceptions that occur in the {{tt|ON}}-unit itself. The <code>ON ERROR SYSTEM;</code> statement allows a nested error trap; if an error occurs within an {{tt|ON}}-unit, control might pass to the operating system where a system dump might be produced, or, for some computational conditions, continue execution (as mentioned above).

The PL/I {{tt|RECORD}} I/O statements have relatively simple syntax as they do not offer options for the many situations from end-of-file to record transmission errors that can occur when a record is read or written. Instead, these complexities are handled in the {{tt|ON}}-units for the various file conditions. The same approach was adopted for {{tt|AREA}} sub-allocation and the {{tt|AREA}} condition.

The existence of exception handling {{tt|ON}}-units can have an effect on optimization, because variables can be inspected or altered in {{tt|ON}}-units. Values of variables that might otherwise be kept in registers between statements, may need to be returned to storage between statements. This is discussed in the section on Implementation Issues above.<ref name=IBMLR43 />{{rp|pp.249–376}}

===GO TO with a non-fixed target===
PL/I has counterparts for COBOL and FORTRAN's specialized GO TO statements.

Syntax for both COBOL and FORTRAN exist for coding two special two types of {{mono|GO TO}}, each of which has a target that is not always the same.
* {{tt|ALTER}} (COBOL), {{tt|ASSIGN}} (FORTRAN):
** {{code|ALTER paragraph_name_xxx TO PROCEED TO para_name_zzz|cobolfree}} (“altered go to”).<ref name=COB.IBM>{{cite web
 |url=https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpsalte.htm
 |title=ALTER statement|website=[[IBM]] |date=24 September 2021}}</ref>
**: There are other/helpful restrictions on these, especially "in programs ... {{tt|RECURSIVE}} attribute, in methods, or .. {{tt|THREAD}} option."<ref name=COB.IBM/>
** {{code|ASSIGN 1860 TO IGOTTAGO|fortran}} (“assigned go to”)<ref name=ONLY2THESE>{{cite web
 |url=https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9j/index.html
 |title=GO TO (Assigned)}}</ref><br />{{code|GO TO IGOTTAGO}}
**: One enhancement, which adds built-in documentation, is {{code|GO TO IGOTTAGO (1860, 1914, 1939)}}
**:: (which restricts the variable's value to "one of the labels in the list.")<ref name=ONLY2THESE/>
* {{tt|GO TO}} ... based on a variable's subscript-like value.
** {{code|GO TO (1914, 1939, 2140), MYCHOICE}} (“computed go to”)<ref>{{cite web
 |url=https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9l/index.html
 |title=GO TO (Computed)}}</ref>
** {{code|GO TO para_One para_Two para_Three DEPENDING ON IDECIDE|cobol}} (“go to depending on”).<ref>{{cite web
 |url=https://www.tutorialride.com/cobol/go-to-statement-in-cobol.htm
 |title=GO TO Statement in COBOL}}</ref>

PL/I has statement label variables (with the {{tt|LABEL}} attribute), which can store the value of a statement label, and later be used in a {{tt|GOTO}} statement.<ref>{{cite book
 |title=Digital Research PL/I Language Programmer's Guide
 |page=103}}</ref><ref name="gc33-0009-4"/>{{rp|54}}<ref name="gc33-0009-4"/>{{rp|23}}
<pre>
LABL1: ....
.
.
LABL2: ...
.
.
.
MY_DEST = LABL1;
.
GO TO MY_DEST;
</pre>

The programmer can also create an array of static label constants by subscripting the statement labels.
 GO TO HERE(LUCKY_NUMBER); /* minus 1, zero, or ... */

 HERE(-1): PUT LIST ("I O U"); GO TO Lottery;
 HERE(0): PUT LIST ("No Cash"); GO TO Lottery;
 HERE(1): PUT LIST ("Dollar Bill"); GO TO Lottery;
 HERE(2): PUT LIST ("TWO DOLLARS"); GO TO Lottery;

Statement label variables can be passed to called procedures, and used to return to a different statement in the calling routine.