DCL I FIXED BIN(31,S) INIT(1);
7 REWRITE FILE (F);
1.
~1 READ FILE (P) INTO (X);
15 REWRITE FILE (F);
~9 REWRITE FILE (F) FROM (X);
Statement 7 will rewrite a record updated in the buffer.
Statement 15 will only rewrite exactly what was read, i.e.# i t will not change the data set at all.
Statement 19 will since there is READ statement.
raise ERROR, no preceding
There are two cases where i t is not possible to check for the KEY condi-tion on a LOCATE statement until transmission of a record is attempted.
(This will generally occur on execu-tion of the next PL/I output statement for this file.)
These are:
When there is insufficient room specified region to output the on a REGIONAL(3) V- or U-format Neither the record raising the tion nor the current record are mitted.
in the record file.
condi-
trans-2. When the embedded key differs from the KEYFROM in an ISAM file.
If this LOCATE statement is to trans-mit the last record before the file is closed, in case 1, the record is not transmitted, and in the second case, the embedded key is overwritten with the KEYFROM string, and the record is transmitted.
Thus the condition may be raised by a CLOSE statement or by an END statement that causes implicit closing. Until the error is corrected, the record cannot be transmitted nor can any further operation be carried out on the file.
If a LOCATE statement was used in the addition of KEYED records to any type of REGIONAL data set then. if RECORD condition is raised, the key value presented at subsequent operations must not be less than the current one.
(18) Allocation and ffe~ing of BASED Varia-bles: If a reference is made, at object time, to a BASED variable that has not been allocated storage, an unpredictable interrupt (protection, addressing or specification) may occur.
(19) Areas, pointers, offsets and struc-tures containing any of these cannot be used with STREAM I/O. PUT DATA cannot be used with BASED variables.
When a BASED variable is freed, the associated pointer no longer contains useful information. This pointer can only be used again if:
1. It is re-allocated with the same or another BASED variable, or,
2. A value is assigned to it from an offset or another pointer
A BASED variable allocated in an must be freed in that area.
example:
DCL A AREA, B BASED (X);
ALLOCATE B IN (A);
area For
FREE B;
FREE B IN (A); 1* ILLEGAL */
/* LEGAL */
In PL/I there are often several differ-ent ways of producing a given effect. One of these ways will usually be more effi-cient from a particular point of view than another, depending largely on the method of implementation of the language features concerned. However, it should be realized at the outset that a primary cause of program inefficiency occurs at the problem definition stage, before any actual pro-gramming is done: PLII cannot be used to full advantage unless the problem is defined in terms of PL/I.
The purpose of this section is to help the programmer make the best use of the PL/I (F) Compiler. The first two parts are presented from two different viewpoints:
a. Improving the speed of compilation b. Improving the speed of execution.
The remainder of the section is of common interest, and deals with methods of decreasing the dictionary size: use of storage; use of compile-time facilities;
use of input/output facilities; and addi-tional hints.
The following measures are suggested for use where compilation time is an important factor.
(1) Allocate as much storage to the com-piler as possible, using the SIZE=999999 option on the EXEC state-ment. This reduces the chances of bringing the spill mechanism into operation.
(2) Keep the number of BEGIN blocks and procedures to a minimum. Do not use BEGIN-END to effect statement group-ing; this is more simply obtained by use of DO-groups.
(3) Try to avoid LIST, DECK, options.
using and
the ATR, XREF, CHAR48 compiler (4) Avoid features which give rise to large dictionary entries and large amounts of text. For example,
DCL A PIC '(4000)X';
occupies block.
one complete dictionary (5) Use of the following features causes optional compiler phases to be loaded:
ALLOCATE, LIKE, USES/SETS. CHECK, iSUB defining, built-in functions with aggregate arguments, GENERIC entry names, DELAY/DISPLAY. If any of these features can be completely avoided without extensively increasing the source code, there will be a corres-ponding increase in compilation speed.
(6) On re-runs, further slight increases in efficiency can be obtained by
(a) removing all unreferenced labels and data;
(b) correcting §!ll source errors, and, where possible, m1n1m1zing the number of diagnostic messages pro-duced, including such messages as
"FILE/STRING option missing in GET/PUT statement";
(c) subdividing the program if the auxiliary storage has been used:
(d) specifying the NOSOURCE option:
(e) specifying the FLAGS option.
See also 2.c. Decreasing Size of Dic-tionary.
The following measures are suggested for use where execution time is an important factor. Note that while some of these measures may slow down the compilation, this is offset by the fact that others will accelerate it. In the main, there should be no serious increase in compilation time.
(1) Make use of the OPT=01 option.
the STMT option.
Avoid (2) Avoid unnecessary program segmentation and block structure; all procedures, ON-units and BEGIN blocks need prolo-gues and epiloprolo-gues, the initialization and housekeeping for which carry a considerable overheado (Prologues and epilogues are described in Appendix C of this publication.) Whenever possi-ble, use GOTO or IF statements to control program logic, rather than the CALL statement.
(3) Branching in IF statements can be improved by using DO and END state-ments to bracket a THEN clause, rather than using a GOTO statement in the THEN clause. For example:
IF A=B THEN DO;
C=D;
E=F;
END;
L: etc.
is more efficient than IF A,=B THEN GO TO L;
C=D;
E=F;
L: etc.
(4) When GO TO is used in an IF st~tement,
more efficient object code is produced by tha GO TO if i t refers to a label within the same block rather than to a label outside the block.
(5) Keep IF clauses simple; separate any multiple conditions into a series of simple IF statements. For example:
IF A=B
THEN IF C=D THEN IF E=F
THEN GO TO Mi is more efficient than
IF (A=B)&(C=D)&(E=F) THEN GO TO Mi
(6) Avoid extensive use of adjustable arrays and/or CONTROLLED storage.
(7) Use constants wherever instead of expressions.
possible
(8) Exercise care in specifying precision.
For example,
DCL A FIXED DEC(8,4), B FIXED DEC(10,2), C FIXED DEC(10,1);
C=A+Bi
This requires almost twice as much code as i t would if B had been declared (10,4), because tho: evalua-tion of A+B requires a scale factor of 4.
(9) Use the PICTURE attribute only when necessary. For example, use FIXED DECIMAL(5,2) instead of PIC'999V99'.
If a picture field is used in more than one arithmetic operation, convert i t once and then use the new form in each operation. This holds for any conversion required more than once.
If i t is necessary to use data with the PICTURE attribute in arithmetic expressions, use pictures that will be handled in-line, as this considerably reduces execution time. Pictures with all 9s, a V and a non-drifting sign are particularly useful. For example:
'999' '$99v99' , s99' 'V999'
(10) Internal switches and counters, and data involved in substantial computa-tion or used for subscripts, should be declared BINARY; data required for output should be kept in DECIMAL form.
(11) Keep data conversions to a minimum.
Some possible methods follow:
(a) Use additional variables. For example, if a problem specifies that a character variable has to be regularly incremented by 1,
DCL CTLNO CHAR(18);
CTLNO = CTLNO+1;
requires two conversions, while
DCL CTLNO CHAR(S), DCTLNO DEC FIXED:
DCTLNO=DCTLNO+1:
CTLNO=DCTLNO:
requires only one conversion.
(b) Take special care to make struc-tures match when i t is intended to move data from one structure to another.
(c) Avoid mixed mode arithmetic, espe-cially the use of character strings in arithmetic calcula-tions.
(12) Declare arrays in the procedure in which they are used, instead of pass-ing them as arguments. Declare sub-script variables in the block in which they are used, as FIXED BINARY.
(13) In multiple assignments to subscripted variables, restrict the assignment to three variables.
(14) If a subscripted item is referred tc more than once with the same sub-script, assign the element to a scalar variable:
R={A(I)+1/A(I»+A(I)**A(I) ; should be replaced by
ASUB=A(I)i
R=(ASUB+1/ASUB)+ASUB**ASUB;
(15) Bit strings should, if possible, be specified as multiples of eight bits.
Bit strings used as logical switches should be specified according to the number of switches required. In the examples below, (a) is preferable to
(b), and (b) to (c):
(a) DCL SW BIT(1) INIT ('1'B);
IF SW THEN DO:
(b) DCL SW BIT(S) INIT('1'B):
IF SW THEN DO;
(c) DCL SW BIT(S) INIT('1·B):
IF SW '10000000'B THEN DO;
2. M~l~~E1e s~~~ches
(a) DCL B BIT(8);
B '11100000'B:
IF B '11~OOOOO'B THEN DO;
(b) DCL B BIT(3);
B '111'B;
IF B = '11~'B THEN DO;
(c) DCL <SW1,SW2,SW3) BIT ( 1) ;
SW1, SW2", SW3, , l ' B i
IF SW1&SW2&SW3 THEN DO;
If bit string data is to be held in structures, such structures should be declared ALIGNED.
(16) Note that concatenation operations are time-consuming.
(17) Varying length strings are not as efficient as fixed length strings.
(1S) Fixed length strings are not efficient if their length is not known at com-pile time, as in the following exam-ple:
DCL A CHAR(N);
(19) Avoid using the SIZE, SUBSCRIPTRANGE, STRINGRANGE and CHECK ON-conditions, except during debugging. Debugging aids (see "Testing Programs" in this publication) should be removed from the program before running i t as a production job.
(20) Do not refer function more is expensive.
function once variable for instead of
to the DATE built-in than once in a run; i t Instead, refer to the and save the value in a
subsequent use; e.g.
PAGEA= TITLEAI IDATE;
PAGEB= TITLEBI IDATE;
i t is more efficient to write DTE=DATE;
PAGEA=TITLEAIIDTE;
PAGEB=TITLEBIIDTE;
(21) Allocate sufficient buffers to prevent the program becoming I/O bound.
(22) Use blocked output records.
(23) Open a number of files in a single OPEN statement.
(24) In STREAM input/output, use long data lists instead of splitting up input/output statements.
(25) Use EDIT-directed input/output in pre-ference to LIST- or DATA-directed.
(26) consider the use of overlay defining to simplify transmission to or from a character string structure. For exam-ple:
DeL IN,
2 TYPE CHAR(2),