It is clear that somehow the banks just described have to be mapped on to physical computer storage, or memory. This is achieved in ZEBRA by declaring to the system one or more common blocks which are to provide the actual storage for the data structures. It is often sufficient for off-line programs to declare a single large common block; it is for on-line applications, or for certain large off-line applications that the possibility to define several distinct blocks is foreseen. A typical declaration has the following form:
Declaration of the ZEBRA storage
COMMON /MYSTOR/ IFENCE(10),LINKS(10),LINKR(20),ISTORE(10000)
DIMENSION LQ(999),IQ(999),Q(999)
EQUIVALENCE (LINKS(9),LQ(9),IQ(1),Q(1))
An actual common block is declared to ZEBRA by a call to MZSTOR,
and in ZEBRA is termed a dynamic store.
The actual layout of memory in a store declared by the example above is shown
in figure 
.
The layout of the ZEBRA default store
Within the common block just described, we notice that the effect of th
EQUIVALENCE statement is to offset the arrays Q and
LQ by eight locations.
This permits in the references to the data words and to the
links a simple form of subscript, namely that each data word is
addressed as Q(L+n),
as already seen, and that each link is referenced as LQ(L-m).
This may be better appreciated by studying the layout of an
actual bank, whose layout is detailed in Figure ,
where the various sections of the bank may be seen, in particular the
data and the links.
Figure: The format of a ZEBRA bank
The total number of links NL plus a constant plus the number of the
optional, so-called extra I/O words, stored
in the lower part of the first word of the bank (see below),
is required to step over the link
region to reach the central area during a sequential scan
through the store.
The upper part of the first word contains the I/O control-byte.
Together with the extra I/O words, if any, it constitutes the
``I/O characteristic'', describing the nature of the bank contents,
as needed for conversion if the bank is written to a file for reading
on some other computer, and also for interpretative du.gif
(see the description of routine MZFORM).
The central part of the bank starts with the next link,
accessed as LQ(L).
The up link at LQ(L+1) points to the header bank supporting
the linear structure of which the bank is a member;
it is zero if the bank is a primary header bank.
The origin link at LQ(L+2) points to the link
through which the bank is reached.
The origin link is not usually of interest to the user,
its sole purpose is to free the user from having to remember the
supporting link. These three links, next, up and origin are present
in every bank and are not counted in NL and NS.
The two words IQ(L-5) and IQ(L-4) contain the numeric and Hollerith bank
identifiers, IDN and IDH.
Usually all the banks of a linear structure
have the same IDH, but different IDN's to permit ready
identification of a particular bank in interactive work.
Words IQ(L-3) and IQ(L-2)
hold the total number of links (NL) and the number of structural
links (NS), respectively,
and word IQ(L-1) holds the number of data words (ND).
The status word at IQ(L) provides in positions
1 to 18 for user status bits,
while positions 19 to 32 are reserved for system use. In particular
bits 19 to 22 contain the number of extra I/O descriptor words NIO,
needed to go backwards from the centre to the start of a bank.
With this format the smallest possible, but useless, ZEBRA
bank (NL=NS=ND=0) occupies 10 words.
So far we have seen how banks are stored in a dynamic store. In fact, a dynamic store may physically be subdivided into divisions. The purpose of the division is to enable ZEBRA to manipulate gro.gif of logically associated banks efficiently, for instance for input-output or for dropping banks, and also to allow it to handle links more efficiently when it knows that they are restricted to a single division.
When a store is initialized by MZSTOR, it automatically creates three divisions, one for itself and two for the user. Further divisions may be created explicitly by a call to MZDIV.
It should be noted that stores and divisions are identified by means of a store/division index whose value never changes. These indices should be maintained in, for instance, the common block to which they refer, for reasons of data integrity.
It is possible for a user to store bank addresses or links, for ease of manipulation, in a user-defined area, or link area. These should be kept in a common block, and a call to MZLINK or MZLINT is necessary to declare these areas to ZEBRA, which will then maintain them in the event of a bank relocation. For this reason, the link areas associated with different stores have to be kept separately.
It happens frequently in a program that some temporary working space is required, perh.gif for use within one or two routines. ZEBRA permits a user to ask for such working space by a call to MZWORK. The necessary storage is made physically available at the beginning of the relevant store, and may contain reference links and data. It should be noted that the first division in the store is logically part of the working space, and its existing contents are destroyed by a call to MZWORK. Normally, therefore, the first division should itself be used only for banks which are very short term.
