You are on page 1of 20

BASIC PL/1 MULTI-PROCEDURE PROGRAMS

MODULE 13 Page 0 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
MODULE 13
Multi-Procedure
Programs
MODULE 13 Page 1 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
PROBLEMS WITH THE USE OF EXT
The use of EXT variables allows diferent EXT procedures to
communicate through the use of shared variables. Although this is often
enough, there are times when this technique has limitations. For
example,
If the called PROC is one from a library, that many procedures use,
then they all have to remember to use the same name and attributes
for the EXT variable.
It's difcult to see, if there are many or complex EXT variables, just
which items of data are being used on a given CALL
If the called PROC is calculating a value that the calling routine is
going to use immediately, it would be nice to be able to use the
PROC as if it were a Built-In Function, giving back a value that could
be used straight away.
These problems are solved by the use of the alternative technique of
data linkage between procedures: parameters and arguments.
MODULE 13 Page 2 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
DATA LINKAGE BY ARGUMENT
EXTENDING THE CALL STATEMENT
The basic CALL statement passes control only. We will now see the
extension to the CALL which allows data as well as control to be passed
to the subroutine.
CALL ZZ103A(A,B,C);
Here the name of the PROC in the CALL has been followed by, in
parentheses, a series of values. In this case they are presumably
variable names, but in general they simply need to be values. In
English, the CALL statement is saying "Pass control to the PROC called
ZZ103A, and pass also the values of A, B and C". These three values,
A, B and C are known as arguments, values that are passed to the
called routine. Whatever data values the calling routine wants the called
routine to know will be specifed as arguments.
The advantage of this technique over that of using EXT variables is that
it can easily be seen from the CALL the values to which the CALLed
routine will have access, instead of having to look at the EXT
declarations in both procedures to see which ones are common.
The corresponding disadvantage is that if the CALL occurs several times
in the one procedure, then the argument list will have to be repeated on
every CALL. A further disadvantage is that if the arguments are AUTO,
or expressions, then the setting up of the argument list is an extra time
penalty at execution time.
EXTENDING THE PROC STATEMENT
If the CALL statement is going to be extended by adding an argument
list, then a corresponding change will need to be made to the CALLed
routine, in order to tell it to expect values to be passed to it. This is done
by modifying the PROC statement, by adding a "parameter list".
ZZ103A: PROC(RATE,QUANTITY,DISCOUNT);
MODULE 13 Page 3 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
Instead of just saying PROC, we put, in this case 3, variable names
following the PROC. These form the parameter list. Each of these
variables - RATE, QUANTITY and DISCOUNT will need to be declared,
in the same way as any other variable, to give data type, dimensions etc.
But they must not have the STATIC, AUTO or BASED attributes. PL/1
sets up no storage for these variables. They are simply dummy
variables through which the coding in this procedure can access the
argument values passed by the calling procedure.
Example:
ZZ103:PROC OPTIONS(MAIN);
DCL A CHAR(20);
DCL B FIXED DEC();
DCL C(10) FIXED BIN(1);
DCL ZZ103A ENTRY;
1) CALL ZZ103A(A,B,C);
2) CALL ZZ103A(SUBSTR(A,1,!),B",C);
END ZZ103;
###############################################
ZZ103A: PROC(PA,PB,PC)
DCL PA CHAR(20);
DCL PB FIXED DEC();
DCL PC(10) FIXED BIN(1);
$% CODIN& %$
END ZZ103A;
1) You can see that the parameters, PA, PB and PC, have in fact
been declared with the same attributes that A, B and C have. So the
frst time that ZZ103A is called, the values of A, B and C are passed
(Note that the value of C is in fact an array value. This is perfectly valid -
as are structure values). So when in ZZ103A we refer to PA, we are in
fact not referring to an area of storage that PL/1 has set up in ZZ103A,
we are referring to the value of A that ZZ103 set up for us as part of the
call. Similarly references to B are references to the value of PB, and C
to PC.
2) When we come to the second call to ZZ103A, we are passing the
results of expressions. The calling routine will set up the result of
SUBSTR(A,1,7) as if it had been a variable, and then pass it. Similarly it
will work out the value of B-5 and pass that. There is no way that
MODULE 13 Page 4 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
ZZ103A is able to discover that one time its parameters are actual
variables and at other times the results of expressions.
This leads to a problem. The attributes of A are CHAR(20), and of B
FIXED DEC(5). The attributes of SUBSTR(A,1,7) are CHAR(7) and of
B-5 are FLXED DEC(6). If arguments with these attributes are passed
to the parameters that ZZ103A has declared - there'll be problems. The
ideal is to get ZZ103 to work out the values of the expressions, and
convert those expressions to the attributes of the parameters. As
ZZ103A is an external procedure, the compiler cannot see both of the
procedures at once. We therefore have "parameter descriptor lists" to
get around this problem.
MODULE 13 Page 5 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
EXTENDING THE ENTRY ATTRIBUTE
In the above, we declared ZZ103A as ENTRY, as we have done with all
our called external procedures. We can extend the ENTRY attribute to
show what sort of data the procedure expects as its arguments, ie. we
state how the parameters have been declared.
ZZ103: PROC OPTIONS(MAIN);
DCL A CHAR(20);
DCL B FIXED DEC();
DCL C(10) FIXED BIN(1);
DCL ZZ103A ENTRY(CHAR(20),
FIXED DEC(5,2),(10)FIXED BIN(15));
CALL ZZ103A(A,B,C)
CALL ZZ103A(SUBSTR(A,1,!),B",C);
END ZZ103;
###############################################
#
ZZ103A: PROC(PA,PB,PC);
DCL PA CHAR(20);
DCL PB FIXED DEC();
DCL PC(10) FIXED BIN(1);
$% CODIN& %$
END ZZ103A;
The extended declaration of ZZ103A now specifes the way that the
three parameters have been declared (and of course incidentally how
many of them there are). PL/1 now will take the responsibility, when
compiling ZZ103, to make certain that whenever ZZ103A is called that
the argument values passed match with what it has been told about the
parameters to which they will be passed.
The parameter descriptor list following the ENTRY attribute is like a DCL
statement without variable names. The names would be pointless, but
the data attributes are not. Note that if we want to specify array
dimensions for a parameter, then they have to be the frst thing specifed,
as in a DCL statement.
MODULE 13 Page 6 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
RETURNING DATA
RETURNS ATTRIBUTE AND OPTION
From the discussion on the previous sections, it is clear that arguments
and parameters are designed as a way of passing data from the calling
procedure to the called one. This is fne when we're coding something
like a print procedure, which simply accepts data and acts on it. Often,
however, we need not only to send data to the called procedure but also
get back an answer. We could use an EXT variable, but that would lose
us the advantage of relating the data linkage to the control linkage. We
can use a modifcation of the CALL with arguments to return data from
the called routine to the calling routine. We no longer use a CALL
statement, but treat our subroutine in the same way that we use Built-In
functions.
Example:
BI&DIF: PROC('1,'2,'3,'()
RETURNS(FIXED DEC(5));
DCL '1 FIXED DEC();
DCL '2 FIXED DEC();
DCL '3 FIXED DEC();
DCL '( FIXED DEC();
DCL WRK1 FIXED DEC(5);
DCL )R*2 FIXED DEC();
DCL MAX BUILTIN;
DCL MIN BUILTIN;
)R*1 # MAX ('1,'2,'3,'();
)R*2 # MIN ('1,'2,'3,'();
)R*1 # )R*1 " )R*2;
RETURN (WRK1);
END BI&DIF;
There are two new language features here, the RETURNS option on the
PROC statement, and the RETURN statement. They are related, in that
if you have one then you have the other.
The RETURNS option on the PROC states that when this procedure
terminates, and returns control to the calling procedure, then it will have
a value to pass back, and these are the attributes of that value.
MODULE 13 Page 7 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
MODULE 13 Page 8 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
RETURN Statement
The RETURN statement functions like the END statement of the PROC,
in that it causes control to return to the calling PROC, but it also
specifes the value to be returned. In this case the procedure will work
out the biggest diference between any pair of its four arguments, and
return that number.
If we're going to invoke BIGDIF, passing values and "catching" that
returned value, then there are two new things we have to learn about the
invoking PROC: The way in which we declare BIGDIF and the way in
which we use it.
DCL BI&DIF ENTRY(FIXED DEC(),
FIXED DEC(),FIXED DEC(),
FIXED DEC())
RETURNS(FIXED DEC());
X # BI&DIF (2,A$2,B,D(2);
We've added the RETURNS attribute on to the declaration of BIGDIF.
Not only do we say in the ENTRY attribute what sort of data will be
passed to BIGDIF, but we say in the RETURNS attribute what sort of
data we expect back from BIGDIF. The RETURNS attribute should
match exactly the RETURNS option on the PROC statement for BIGDIF
(which it does).
When we invoke BIGDIF we no longer use a CALL statement. Instead
we invoke it simply by reference to its name. In this example we have
assigned the returned value to the variable X, but we could equally well
have coded:
IF X # BI&DIF(A,B,C,D)
THEN +++
$% OR %$
SELECT (BI&DIF(Q,R,S,T));
)HEN +++
In fact we end up using it just like one of PL/1's own functions.
MODULE 13 Page 9 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
INTERNAL PROCEDURES
The procedures we've dealt with so far have been EXTERNAL. Every
procedure has been compiled separately and the linkage has been
through EXT variables and parameters. It is also possible to code an
INTERNAL procedure, one contained completely within another.
ZZ103: PROC OPTIONS(MAIN);
DCL A CHAR(20);
DCL B FIXED DEC();
DCL C(10) FIXED BIN(1);
DCL 'AR1 CHAR(20);
CALL ZZ103A(A, B, C);
CALL ZZ103A(SUBSTR(A,1,!),B",C);
###############################################
#
ZZ103A: PROC(PA,PB,PC);
DCL PA CHAR(20);
DCL PB FIXED DEC();
DCL PC(10) FIXED BIN(1);
$% CODIN& %$
END ZZ103A;
END ZZ103;
We have used this example before, but now the procedure ZZ103A is
inside ZZ103. The frst diference that we see is that the DCL statement
in ZZ103 for ZZ103A has gone. As PL/1 can see both of the procedures
at the same time, there is no need for the description. The coding for
ZZ103A remains unchanged. A less visible diference concerns the
scope of declarations.
The variable VAR1 is declared in ZZ103. It can therefore be referenced
throughout ZZ103. It can also be referenced in any procedure internal
to ZZ103. Any reference to VAR1 in ZZ103A would be to the declaration
in ZZ103.
MODULE 13 Page 10 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
ZZ103: PROC OPTIONS(MAIN);
DCL X CHAR(1); $%A%$
DCL Y CHAR(1); $%B%$
SL:;
CALL ZZ103A;
ZZ103A: PROC;
DCL Y CHAR(1) $%C%$
DCL Z CHAR(1); $%D%$
S2:;
END ZZ103A;
ZZ103B: PROC;
S3:;
END ZZ103B;
END ZZ103;
The scope of a variable (or a declaration) is:
the block in which it is declared
any block internal to a block which can access the variable, unless
that block redeclares the name.
From the above:
At S1, we can refer to X and Y, and those references will be to the
variables declared at a and b.
At S2, we can refer to Y and Z, and those references will be to the
variables declared at c and d.
At S2, we can also refer to the variable X, declared at a. We cannot refer
to the variable Y declared at b, because the same name ,Y, has been
redeclared within ZZ103A too.
MODULE 13 Page 11 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
At S1 we cannot access the variable Z declared at d, scope does not
extend "upwards".
Procedure ZZ103B declares no variables of its own. It can access X
and Y from ZZ103, but cannot access Y or Z from ZZ013A.
MODULE 13 Page 12 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
ENTRY ATTRIBUTE
Format: ENTRY(parameter-descriptor-list)
The rules
for the use of the ENTRY attribute are as stated in the unit on Block
Structure.
parameter-descriptor-list is a list, separated by commas, of parameter
descriptors. Each parameter-descriptor is a set of attributes equivalent
to those specifed for the parameter variable in the called procedure.
Efect:
As the ENTRY being declared is an EXT procedure, PL/1 cannot see the
parameter declarations when it is compiling the CALL statement or other
reference to the procedure. The efect of the parameter-descriptor-list is
to allow the compiler to ensure that argument values passed to the entry
point are suitable values for the parameters to access.
CALL STATEMENT
Format: CALL PNAME (arg-list);
PNAME is the name of a procedure (external or internal)
arg-list is a list of one or more values separated by commas.
Efect:
Control passes to PNAME and returns as for the simple form of the
CALL statement.
Each value in arg-list is evaluated, and the result of the evaluation
passed to PNAME If there is a declaration of pname including a
parameter descriptor list, then each argument is converted to the
attributes specifed in that list. If PNAME is an internal procedure, then
MODULE 13 Page 13 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
the arguments are converted if necessary to the attributes of the
corresponding parameters.
MODULE 13 Page 14 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
PROCEDURE STATEMENT
Format: PNAME: PROC (parameter-list);
PNAME is the procedure name. If the procedure is an external
procedure, then it must conform to the appropriate rules.
parameter-list is a list of variable names, separated by commas. Each of
the names acquires the unwritten attribute parameter.
All variables whose names appear in the parameter list must still be
declared like other variables. No storage is reserved for those variables,
as they are dummy variables used to access the values passed as
arguments to the procedure.
RETURNS ATTRIBUTE AND OPTION
Format: RETURNS option: RETURNS(attribute-list)
This may be placed only on the PROC statement, and normally only for
non-MAIN procedures. If the PROC statement also has a parameter list,
then the RETURNS option must follow it.
attribute-list describes the form of the value that this procedure expects
to return to the invoking procedure. Whatever value is specifed in the
RETURN statement will be converted to these attributes. Not all
attributes are allowed, only the following may appear in the RETURNS
option:
FIXED
DEC (precision)
BINARY (precision)
BIT (length)
CHARACTER (length)
PICTURE 'specifcation'
POINTER
Note that array and structure returned values are not allowed, and that
storage class attributes may not be specifed.
MODULE 13 Page 15 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
Format: RETURNS attribute:
RETURNS(attribute-list)
Exactly the same as the corresponding RETURNS option.
The RETURNS attribute may only be specifed for a name with the
ENTRY EXT attributes. It must correspond with the RETURNS option
on the PROC statement.
The attributes specifed are those that the invoking procedure expects
the returned value will have. The processing of the returned value
(assignment, comparison etc.) will be performed assuming these
attributes.
MODULE 13 Page 16 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
RETURN STATEMENT
Format 1: RETURN;
Format 2: RETURN (VALUE);
VALUE is any value (constant, variable or expression) that may be
converted to the attributes specifed in the RETURNS option on the
PROC statement. Note that this precludes array and structure values.
Efect:
Format 1 has exactly the same efect as executing the END of the
procedure, in that it returns control to the invoking routine.
IN FORMAT2, VALUE is evaluated, and converted if necessary to the
attributes specifed in the RETURNS option on the PROC statement.
Control returns to the point of invocation, and the (converted if
necessary)
value sent back.
MODULE 13 Page 17 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
INTERNAL AND EXTERNAL PROCEDURES
A non-MAIN procedure may be either INTERNAL or EXTERNAL. A
MAIN procedure is always EXTERNAL.
EXTERNAL PROCEDURES:
Are not contained in other procedures, and are compiled separately.
Have access to EXTERNAL variables if they are declared.
Have access to argument values through their parameters.
May return values, if invoked as Function Procedures.
INTERNAL PROCEDURES:
Are contained in other procedures, ie their PROC statement follows
another PROC statement, and their END statement precedes the
END statement for the other PROC.
Have access to all variables to which the encompassing procedure
has access, unless the names of those variables have been
redeclared in the internal procedure.
Have access to argument values through their parameters.
May return values, if invoked as Function Procedures.
Note that if procedure A contains procedure B, then B is internal to A.
B has access to the variables to which A has access, but A does not
have access to variables declared in B unless both A and B declare
those variables as EXT.
SCOPE OF NAMES
MODULE 13 Page 18 of 14
BASIC PL/1 MULTI-PROCEDURE PROGRAMS
The SCOPE of a declaration is defned as the part of the program within
which that variable can be accessed. It consists of:
The procedure in which it was declared.
Any procedure internal to a procedure which has access to the
variable, unless the procedure redeclares the variable's name.
MODULE 13 Page 19 of 14

You might also like