ons 
  
A DAI is a dynamically expandable set of directly accessible 
and - at least in general - sequentially stored records of 
information. There are more then 30 different types of 
information which may be classified by means of a three 
dimensional system according to fig. 1. where the shaded 
classes remain empty. 
A record is an integral multiple of a sector where the 
value of the integer depends on the type of information 
and there is an integer constant for each type of information 
identifying the corresponding records' lengths. The sectors 
of record. are counted O, 1,'2,' ... etc. from left to right 
and the relative sectoraddress of sector O of a record is 
also referred to as the relative record address or shortly 
record address, Certain different type of information 
records being or to be stored consecutively are occasionally 
referred to as so-called super-records for speeding up 
some access procedures. 
4. Storage access methods 
  
Any reasonable data file management requires some basic 
information on the current allocation to be main storage 
resident upon access. So does PODIUM. More exactly, about 
1 K bytes at the beginning of a DAI form a super-record 
called header (HDR) the record address of which being O. 
As will be explained in sections 8 and 9 a program refer- 
encing PODIUM may treat it as a single subroutine merely 
consisting of instructions and data to be used locally. 
I.e. all the main storage work space needed by PODIUM 
has to be allocated by the referencing program. This may 
be turned to advantage by a programmer according to his 
ability as follows: It is possible to make a program 
- simultaneously working any number of 
- different type of information records, 
- different DAI's, 
in an optimum manner 
- transferring asynchronously upon storing and retrieving. 
It is now obvious how to utilize HDR-records: Supply as 
many different HDR-buffers to PODIUM as there are 
different DAI's to be simultaneously worked. One should 
notice that the referencing program need not store or 
retrieve HDR-records itself nor has to manipulate the 
contents of HDR-buffers though it may utilize parameter 
values and printable text strings contained therein but 
only must allocate and maintain these HDR-buffers 
appropriately.