IBM 1130 User Manual page 502

COMMON Area
Unused
~
___
C~O_M_M_O~N~~-4~
Progra[n:area
LOCAL area
SOCAL area
Flipper
Basic area
Core Storage
The COMMON area, because it is not over-laid,
provides a means by which SOCALs, LOCALs, and
LINKs may communicate with each ot}ler via core
storage. SOCALs and LOCALs, because they are
subprograms, may also communicate through the
arguments in the CALLing statement. One LINK,
on the other hand, must use COMMON to pass data
to another LINK.
You must determine what data has to be passed
from one LINK to another. If BIG 1 obtains X from
a card, and BIG2 requires it for a computation, X
must be placed in COMMON. If BIGI obtains DATE
from a card, and BIG4 uses it in a printed summary,
DATE must be passed from BIGI to BIG2, from
BIG2 to BIG3, and from BIG3 to BIG4, even though
BIG2 and BIG3 do not need it. In other words, DATE
(or its equivalent) must appear in the same relative
position in a COMMON statement in all four LINKs.
To illustrate, suppose six items must be passed
from one program to another: DATE, TABLE, K,
X, Y, and ANS. The following table shows how the
four LINKs use these six items:
Variable
Description BIGI BIG2 BIG3 BIG4
- - - -
DATE Real variable
X X
TABLE Array of 100
X X X
items
K Integer
X X
X
Real variable
X X
Y Real variable
X X
ANS Real variable
X X
Section Subsections
Page
65
10
I
60
01
There are many different ways yo.u can accom-
plish this, the easiest being to compose one COM-
MON statement
COMMMON DATE, TABLE (100), K,X, Y,ANS
and include it in BIG1, BIG2, BIG3, and BIG4.
Another way would be to use the following COM-
MON statements:
in BIGI
in BIG2
in BIG3
in BIG4
COMMON DATE, TABLE (100)
COMMON DATE, TABLE (100), K, X, Y,
COMMON DATE, TABLE(lOO),K,X, Y,ANS
COMMON DATE, TABLE(lOO),K,X, Y,ANSWR
Here you see that the size of COMMON in BIGI and
BIG2 is reduced, since unneeded items are not
retained. Some unneeded items (like K in BIG3)
cannot be eliminated, since you must preserve the
relative location (structure) of COMMON from one
program to the next, not just the name.
Note that the name of the last variable changes
from ANS to ANSWR in LINKing from BIG3 to BIG4.
This does not matter, since only the relative posi-
tion in core storage is important, not the name.
There are many other ways in which COMMON
may be arranged. To take advantage of the fact
that BIG4 does not use X, Y, or the TABLE
array, we may use
in BIGI
inBIG2
inBIG3
in BIG4
COMMON DATE,K,ANS, TABLE(lOO),X, Y
COMMON DATE,K,ANS,
TABLE(lOO),~,
Y
COMMON DATE,K,ANS, TABLE (lOO)X,Y
COMMON DATE,K,ANSWR
which reduces the core requirements of BIG4 by
102x3 (or 2) words, depending on the precision
used.