Lengthy argument lists in subroutines and user-defined functions can occur
as modularised programs grow ever larger, requiring more and more information
to be passed between program units. The
COMMON block, a piece
of shared memory in the computer, is another method for passing information
between program units. Data stored in a
COMMON block is not
passed between program units via argument lists, but through the
COMMON statement near the beginning of each program unit.
There are two types of
COMMON blocks: blank and
named. A program may contain only one blank
block but any number of named
COMMON blocks. Every
COMMON block must be declared in every program unit in which
the information stored therein is needed. In addition, the unique
COMMON block must be declared in the main program.
COMMON block is set up with the statement
and the named
COMMON block is declared by
COMMON /name/ variable-list
where the name between the forward slashes is the name of the
Every subroutine or user-defined function that uses data stored in the
COMMON block, blank or named, must have a similar statement
to those above. The variable names do not need to match between program
units but it is vital that their types and the order in which they appear
in the list are identical.
PROGRAM MAIN INTEGER A REAL F,R,X,Y COMMON R,A,F A = -14 R = 99.9 F = 0.2 CALL SUB(X,Y) ... END SUBROUTINE SUB(P,Q) INTEGER I REAL A,B,P,Q COMMON A,I,B ... END
In this example, a blank
COMMON block holds three values: a
REAL number, an
INTEGER number, and another
REAL number. Memory is shared in the
block in the following way:
|Main Program||Common Memory Storage||Subroutine|
Note that the variable names for each memory area differ between the main program and the subroutine, but that the number and type of variables are the same as is the order in which they are listed.
COMMON blocks are used in much the same manner. Note
that a variable cannot appear in more than one named
block in a program unit.
COMMON blocks must be declared in the main program.
It is not necessary to declare named
COMMON blocks in the
main program unless they are used there.
COMMON blocks need not be the same length in
different program units. However, a named
COMMON block must
be exactly the same length wherever it appears. This means that
some knowledge about how the computer stores information is necessary.
That is, the programmer must know how much storage each variable or
array takes in order to ensure that the named
are the same length.
Variables in blank
COMMON blocks may be initialised with
READ or assignment statements but not with a
DATA statement. The same restrictions apply to named
COMMON blocks with one important difference: named
COMMON blocks may be initialised in a special nonexecutable
subroutine called a
When a subroutine or function is exited, local variables become
undefined. The same thing may happen with the variables stored in
COMMON blocks. Therefore, it is possible to
SAVE an entire named
COMMON block (but not
individual variables in the block) in a procedure with the command
SAVE /named common block1/, /named common block2/, ..., /named common blockn/
Variables in a blank
COMMON block never become undefined since
the it is declared in the main program. Similarly, if a named
COMMON block is declared in the main program, then it is
unecessary to use the
SAVE command in other program units.
Note that you cannot use the
SAVE command on a blank
BLOCKDATA subprogram consists of the
statement, any necessary type declarations, a list of the named
COMMON blocks and their variables, and one or more
DATA statements initialising one or more of the variables
appearing in the
COMMON blocks. Its sole purpose is to
initialise the values in named
BLOCKDATA SETUP INTEGER A,B,C REAL I,J,K,L COMMON /AREA1/ A,B,C COMMON /AREA2/ I,J,K,L DATA A,B,C,I,J,K,L/0,1,2,10.0,-20.0,30.0,-40.0/ END
The use of
COMMON blocks is discouraged unless there are
extremely large amounts of data to be passed between program units. The
reason for this is simple: it weakens modularity. Variables in
COMMON blocks are global in nature and when one
program unit alters a variable in this shared memory area, then it affects
all of the other program units which also use this shared area, often with
unexpected results. The debugging process becomes that much harder.