Ground Operations Aerospace Language
GOAL
Final Report
Volume III
Data Bank
(SASA-CE-1 36779) GBOOHD OBEBATIOHS N74-15889
AEBOSFACE LiNG0A6� (GOAL). VOLUHE 3:
DiaA BAIIK final fieport rinternational
Business Hachines Corp.) 139 p BC $9.00 Unclas
CSCX 09B G3/08 28967
31 July 1973
Ground Operations Aerospace Language
GOAL
Final Report
Volume III
Data Bank
Contract NAS 10-6900
Approved ^"1 J^L-^^yiiAiif^
//3. W, Hantfley, Manager
L/ Systems Programming and
Advanced Programs
===?= Federal Systemi Division 31 July 1973
TABLE OF CONTENTS
Section Title Page
1.0 INTRODUCTION� 1-1
2.0 CONVENTIONAL PROGRAM I/O DEVICE ADDRESSING 2-1
2.1 Early Binding - 2-1
2.2 Modified Early Binding 2-1
2.3 Late Binding 2-2
3.0 MEASUREMENT ADDRESSING IN SENS0R-6ASED PROGRAMMING- 3-1
3.1 Binding in Saturji/Apollo Software 3-1
3.2 Binding in the Goal Language 3-2
3.3 Extensions of Data Bank Usage Into Other
Areas � 3-2
4.0 IMPLEMENTATION OF LATE BINDING 4-1
4.1 Late Binding in Goal 4-2
4.2 Late Binding in a Goal System-Examples 4-2
5.0 MISCELLANEOUS - 5-1
5.1 Another Requirement for an Online Data Bank- 5-1
5.2 The Effect of Measurement Names on Data
Bank Usage - 5-2
5.3 Multiple Addressing Conventions for Online
Keyboard Usage 5-3
5.4 Implications of a Two-Data Bank System 5-6
APPENDIX A The Data Bank File Design - A-1
APPENDIX B The Data Bank Functional Design B-1
APPENDIX C DASD Size Estimates for Goal Data Bank
Implementation C-1
APPENDIX D Program Module Uescriptions D-1
APPENDIX E Data Record Formats - - E-1
TABLE OF CONTENTS (Cont)
Section Title Page
APPENDIX F Sample Control -Card Input F-1
APPENDIX G Data Bank Maintenance Module Error Messages- G-1
APPENDIX H Pre-Processor Error Message List H-1
APPENDIX I Data Bank Pre-Processor Syntax Tables I-l
n
1.0 INTRODUCTION
The GOAL (Ground Operations Aerospace Language) test programming language
was developed for use in ground checkout operations in a space vehicle
launch environment. To insure compatibility with a maximum number of
applications, a systematic and error-free method of referencing command/
response (analog and digital) hardware measurements is a principle feature
of the language. Central to the concept of requiring the test language
to be independent of launch conqslex test equipment and terminology is
that of addressing measurements via symbolic names that have meaning
directly in the hardware units being tested. To form the link from test
program through test system interfaces to the units being tested the con-
cept of a data bank has been Introduced. The data bank Is actually a
large cross-reference table that provides pertinent hardware data such
as interface unit addresses, data bus routings, or any other system values
required to locate and access measurements.
Three aspects of future aerospace operations can be considered key when
determining whether single or multiple data bank(s) can be justified.
First, the management of a very large number of sensor based measurements
at distinct facilities constitutes a large engineering management effort.
Secondly, verification and launch checkout of future ground and flight
hardwares will require use of this large measurements base in conjunction
with the generation of a large body of automation and test program software
packages. A third problem area is then created when combining certain aspects
of the first two - when hardware modifications are required as a result of
normal or abnormal operations these changes must be carried over into the
software programs also. The solutions to any or all of these problems are
further degraded when confronted with the potential space shuttle environ-
ment of tight launch schedules involving multiple vehicles.
Little can be accomplished in alleviating the problems of the large measure-
ments base or the large number of required test programs as these items are
controlled by engineering factors not under direct control of ground data
processing systems. Data processing equipments can be effectively used in
the support of the ground checkout and launch "business" just as they have
been in other applications of the scientific and commercial world. The
GOAL test programming language has evolved as an attempt at alleviating
the problem of generating and managing a large number of test programs.
The use of a data bank in conjunction with the GOAL language is vital since
its sole purpose is to assist the programmer in dealing with a large and
variable set of measurements and to make as easy as possible the intro-
duction of the effects of hardware changes into the test programming system.
Accordingly, throughout the remainder of this document, the aspect of mean-
ingful use of measurements and the software impacts of hardware measurements
changes will be discussed over and over again. A significant portion of this
document will deal with suggestions as to improvement of operations using
the GOAL language compiler data bank and extending the use of a measurements
data bank into online use in ground operations.
1-1
2.0 CONVENTIONAL PROGRAM I/O DEVICE ADDRESSING
2.1 EARLY BINDING
In general, software communication with any external computer accessible
device is considered an input/output operation. The process of associating
actual device addresses with input/output instruction sequences is known
as "binding" 1n data processing parlance. The binding of device addresses
to I/O instruction can be effectively accomplished at or before program
execution.
"Early binding" techniques have been customary in the past with compiled
high level languages such as FORTRAN. Thus, at the time that the pro-
grammer coded the sequence
WRITE (6,10) A, B, C
directing output to symbolic device #6, it had already been determined
(usually by compiler decree) that device #6 was to be, for instance, a
tape drive at device address A. Once compiled, only tape drive A could
be used as a target for the output operations directed to device #6. If
for unseen reasons tape drive A was not operational, the early binding
of this device address A to the symbolic name 6 forces one of the follow-
ing two alternates:
1. If at all possible, the program run is held in abeyance until
the required tape drive becomes operational.
2. If the program must be run, a workaround for the required hard-
ware address change must be effected. In the traditional early binding
situation for FORTRAN, the following steps are required:
Assign an alternate tape drive to replace the non-
operational drive A. Assume that tape drive C
(symbolic address #8) was available.
The FORTRAN source program is then modified such
that every WRITE statement addressing device #6
is redirected to device #8. The statements of
concern must be repunched.
The revised source program must then be recompiled
prior to its use.
2.2 MODIFIED EARLY BINDING
A significant Improvement to the classic early binding problem can be
effected by associating symbolic device addresses with actual hardware
addresses via compiler control cards or special source program control
cards at compile time. Thus, with "modified early binding" the problem
2-1
of the previous FORTRAN example would be resolved by modifying a device
control card and recompilation of the source program. Note that modifi-
cations to the actual source program are no longer required in this
instance - this could amount to a significant number of changes in many
programs. Several progranming languages have directly or indirectly
adopted this technique of improved early binding. For instance, the
sole purpose for the ENVIRONMENT DIVISION Section of a COBOL program
is to implement this feature.
2.3 LATE BINDING
"Late binding" became a reality with some of the more advanced Operating
Systems available late in the so-called 2nd Generation era of software.
With late binding, the actual hardware address versus symbolic address
linkage is to be made after compilation. Thus, the salient feature of
this type of binding is that no source program modifications or re-
compilations are required to accommodate device address changes. Late
binding is usually one of the service functions of an Operating System.
The actual binding or device selection is customarily performed imme-
diately before execution of the program involved. In the selection of
specific devices for allocation to a program, the Operating System may
follow control card direction as to exactly which device is desired;
some Operating Systems are capable of selecting any appropriate device
from a pool of available devices.
2-2
3.0 MEASUREMENT ADDRESSING IN SENSOR-BASED PROGRAMMING
The data processing environment in which a sensor-base (process control)
program must operate 1s 1n many areas parallel with the traditional batch
scientific or commercial environment. As such, many of the tried and true
solutions to traditional batch programming problems can be expected to
bear similar fruit in the process control environment. The two environ-
ments are not the same, however, and It should not be surprising if some
of the solutions to the past problems do not yield equivalent results;
in some instances, new solutions to new problems must be sought.
Sensor-base measurements (discrete and analog inputs/outputs) form a set
of simple input/output devices to manipulate - the measurements problem
In the process control environment is not one of complexity but one of
sheer bulk. As the total number of Input/output device addresses grows
larger, the possibility of an individual address change becomes more
significant. Experience has also shown that the negative aspects of the
software binding techniques discussed previously become more intractable
for the case of managing a system of process control programs. For instance,
a single discrete measurement address change may require several hundred
changes to a dozen or so programs - all of which must then be recompiled
and reintroduced to the online system before run time.
3.1 BINDING IN SATURN/APOLLO SOFTWARE
In the process-control environment of SATURN/APOILO, the discrete or analog
measurement symbolic name and measurement hardware address were synonymous.
By the choice of such a symbolic naming scheme, early binding of symbolic
name and hardware address was forced on the process -control software - at
the assembler language level as well as at the high-order language level.
Thus, the following succession of events could be anticipated following a
hardware change - possibly as minor as a single address modification:
The first problem falls properly in the area of configu-
ration management - that of finding from a system of (n)
software modules just which ones access the measurements
whose addresses have been changed. In general , a manual
search of program listings has been the only method of
solving this problem.
Having determined which program(s) require modification,
the imposing task of source program modification can ensue.
Two factors accentuate the difficulty of this endeavor.
First, It is common for a single measurement to be mentioned
many (possibly, hundreds) of times within the bounds of a
single program; the problem of finding and making all of the
required changes is a very real problem. Often, "almost all"
of the changes are located and made. Secondly, the modifi-
cation task must in many instances be attended to by personnel
not responsible for coding the original programs; this adds
a factor of difficulty to any program change.
^-1
All. of the modified software modules must then be re-
assembled or recompiled prior to use. Some may also
require revalidation of program operation after changes.
Once the update process has completed, the updated
modules will replace the currently active modules in
the online system.
If the measurement address changes were only temporary,
the above sequence of operations must be reversed to
return the software system to its original configuration.
3.2 BINDING IN THE GOAL LANGUAGE
The disadvantages of early binding in the existing SATURN/APOLLO computer
languages were well known when specifications were first drafted for GOAL
(Ground Operations Aerospace Language). This high level language, intended
for use in the post SATURN/APOLLO time frame introduced the concept of a
"data bank" as a repository for all sensor-base hardware procedural,
addressing, and routing data. With the initial implementation of the
GOAL language, this data bank took the form of a disk-resident file from
which the GOAL compiler could randomly access data relative to all avail-
able measurements. GOAL also introduced a meaningful symbolic naming
scheme for all hardware measurements and classifies such devices as
"function designators." As an example, the discrete signal that
activates/deactivates 28 volt stage power might have been addressed
in the SATURN/APOLLO software via its hardware address, e.g., DISCRETE
OUTPUT #414 - early binding of the hardware address is thus completed.
The same measurement could be addressed in a GOAL program by the symbolic
function designator name "28V STAGE POWER." Using the function desig-
nator name as a search argument, the GOAL compiler would query the data
bank during compilation and determine that a discrete output measurement
at hardware address 414 was being referenced. This GOAL implementation
of a modified early binding technique eliminates many of the frustrations
of accommodating measurement address changes. All such changes will be
introduced to the GOAL system by an update to the data bank. Recompila-
tion of the appropriate test programs will then effect the required
modifications in the programs.
3.3 EXTENSIONS OF DATA BANK USAGE INTO OTHER AREAS
One of the basic design philosophies of the GOAL language stipulates that
a GOAL test program must have the ability of addressing measurements and
specifying test points at the lowest level possible within the bounds of
a given system configuration. It was recognized that the level of access
or the method of accessing a particular measurement could vary significantly
- dependent upon the physical or geographic site at which the program was
to operate.
3-2
As an example, consider a flight component called "Box A". A test program
is developed that will issue stimuli to Box A and measure subsequent Box A
responses in a fashion that will verify the internal operational status
of Box A. As illustrated in Figure 3-3-1, both the type as well as quantity
of test hardware which might exist between the test program host computer
and Box A could vary significantly at three geographical sites at which
testing of Box A is required.
At the manufacturing site, the final acceptance test
interface is shown as comprising a simple hybrid set- "^
up solely dedicated to the testing of Box A.
At the launch site, Box A assumes the role of a single
component within a complex vehicular hardware system.
The test interface in this instance is quite complex
since it addresses the entire vehicle - only a small
portion of the overall interface can be dedicated to
the control or testing of Box A.
During preventive or fault isolation maintenance, a
third variant of interface exists between the test
program and Box A. In this instance, controllable
diagnostic test hardware has been introduced. Al-
though Box A is shown as being the sole object of
test, maintenance testing could well have been
directed at a larger system within which Box A was
a minor component.
In each of the instances in the example, the contents and operation of
the test program could be assumed to be constant, i.e., the procedure
used for the internal verification testing of Box A is the same ir-
respective of the location of Box A. The method of sensor-based
measurement address binding now becomes most significant. If early
binding is chosen, the test program must be programmed in a unique
manner in each of the locations of the example. This implies unique
program coding as well as unique verification of the proper operation
of the program at each site. The function designator naming scheme
and data bank concept of GOAL combine to make it possible to fulfill
the test program obligations of all three sites with a single source
program. Since each site will support its own version of the GOAL
data bank, a compilation of the same program at each site will result
in an executable module tailored to each of the distinct interface
requirements.
3-2
Test
Computer
^
Box A
Test
Program
">
Box
A
Hybrid Test
Harness
FINAL ACCEPTANCE TEST AT MANUFACTURING SITE
Test
Computer
\ Box A
Test
Program
< >
Ground
Interfaces
! Additional
' Computers
Hardwire and
RF Linkages
e
�>
Vehicle
Test
Computer
Box A
Test
Program
LAUNCH COHPLEX PRE-FLIGHT TESTING
^ -
^
Di agnostic
Test
Hardware
PREVENTATIVE OR FAULT ISOLATION MAINTENANCE
Figure 3-3-1. SAMPLE HARDWARE CONFIGURATIONS
3-4
4.0 IMPLEMENTATION OF LATE BINDING
The single inconvenience encountered in a system which incorporates early
or modified early binding is that of requiring program re-compilation to
adjust for input/output addressing changes. Put in other words, the
actual binding operation takes place during (and only during) compilation.
To effect late binding, the binding process must ensue after compilation;
this essentially divorces the compiler from binding responsibilities but
introduces the requirement that another program accomplish the binding.
In many modern systems this binding responsibility will be delegated as
a utility service task for the Operating System. Generally, lack of late
binding resources within a given data processing system can be attributed
to one or more of the following reasons:
Occasional recompilation of a program to adjust for
input/output device reassignment is not considered
by some users to be an inconvenience worth mentioning.
That which could be cleanly designated as an "Operating
System" Is absent in many small or so-called "mini" systems.
The high-level language compiler {if any) of such a system
must produce a program module that is completely self-
supporting - it can be loaded and carried through all
phases of execution without assistance from other pieces
of software. Manual assistance, e.g., control-card
direction after compilation is almost r\Q\/er required,
nor, in most instances, possible.
A method will be presented later in this document in
Section 4.2 to demonstrate that late binding can be
effectively implemented on a system which hosts only
a computer of small capability. This would seem in
contradiction with the statements preceding, however,
the "small" computer of Section 4.2 will be augmented
considerably by offline support of a larger system on
which the burden of compilation and software binding
will be placed.
In some systems the effort associated with implementing
a late binding scheme was simply not justified in the
minds of the system designers. Not only must the high-
level language compilers and the Operating System software
be of greater scope, but the use of a late binding system
is generally more complex for the programmer.
4-1
4.1 LATE BINDING IN GOAL
Two features must be present in the GOAL execution -time, i.e., online,
system if late binding is to be effected. The first is the software
module that will actually accomplish the binding operation. This can
be conveniently delegated to either a utility program or a utility
service of the online operating system. The second need Is that of a
large cross-reference table that can be used to relate symbolic measure-
ment names to actual hardware accessing data; in other words, an online**
data bank is required.
Two positive factors make the operation of late binding in the GOAL
language system distinct from the implementation customarily found in
scientific and commercial data processing systems. First, the compile
of a GOAL program and the execution of the same program will probably
be accomplished on different computer systems. This means, for instance,
that the qualifications that must be met by the computer system that
hosts compiler operations need not be reflected or duplicated by the
execution-time computer systems, or vice versa. Secondly, for the GOAL
system, no appreciable user effort is required to effect or control the
binding operation whereas traditional late binding techniques customarily
Involve modest to extensive control -card direction by the progranmer.
4.2 LATE BINDING IN A GOAL SYSTEM - EXAMPLES
Piguj-e 4-2-1 illustrates the process flow of the production of a loadable
program module v1a the first Implemented GOAL compilation process. The
file marked "intermediate text" In this case Is the source program In
another more readily processable format. Within the intermediate text
file is the reformatted source program plus all applicable hardware
addressing or usage data as supplied by the compiler data bank. In the
Instance of Figure 4-2-1, the translator program provides the interface
between online SYSTEM-X and the general -purpose intermediate text form
of the user program. Each distinct online system will require a unique
translator program. The program module shown as output from the trans-
lator Is complete; function designator hardware binding was accomplished
at the GOAL compilation step - in this Instance, modified early binding.
The final step of the programming sequence is the introduction of the
tailored program module to the program library associated with the online
computer of SYSTEM-X.
**"Online" is perhaps a poor choice (as will be seen later) to attach to
the data bank associated with the binding task. For the present, let it
suffice to say that the word "online" Is used strictly to establish a
distinction between the online data bank and the data bank associated
with compiler operations (the compiler data bank).
4-2
A possible method of accomplishing the transition from the current GOAL
modified early binding system to a late binding variant is demonstrated
in Figure 4-2-2. This diagram can be seen to differ significantly from
that of the current modified early binding system of Figure 4-2-1 in the
flow logic following the translator phase. Preceding the translator,
the compiler data bank now contains no hardware binding data. Function
designator data consists of symbolic name and associated hardware type
(discrete, analog, etc.), description. The translator program of the
late binding system accomplishes the same general functional task as
before, i.e., translating the intermediate text format of the user pro-
gram into an acceptable form for use on the online system. The output
of the translator is unique In the late binding system - declared data
and program text (direct or Indirectly executable code) are combined
into a distinct output labeled the "program module." Associated with
each program module is a second output from the translator - the
"measurements table." This table will contain no_ entries for those
programs which make no reference to external input/output devices
(including sensor-base devices). For any other program which will
require binding of function designator name to hardware address, the
measurements table will contain Individual table entries - one for
each unique function designator mentioned in the program. Each table
entry will indicate the function designator symbolic name In con-
junction with table space (reserved, but not filled In at translate
time) sufficient to hold any associated hardware addressing, usage,
accessing, scaling, or routing data. The symbolic function designator
name will be used as a search argument when seeking hardware binding
data from the online data bank.
Shown in Figure 4-2-2 as a peripheral to the computer online SYSTEM-Y
is the data bank (called the "online" data bank) from which the hard-
ware binding data** can be extracted. Introduction of the entire program
to the online computer program library takes place in the following two-
step operation:
1. The program module Is transferred and edited Into the online
computer program library in exactly the same fashion as with the modified
early binding system.
2. The measurements table will be entered into the measurements table
library via a utility program entitled the "table editor" in Figure 4-2-2.
The table editor will locate each function designator In the online data
bank by using its name as a search argument. Once a function designator
has been found In the online data bank, all pertinent hardware accessing
data (binding data) will be filled into the space reserved for it in the
measurements table. The completed table will then be written into the
measurements table library.
**There Is a definite need for an online data bank for use in areas other
than late binding support. More on this later, in Section 5.1.
4-3
The "program fetch" (locating and fetching a program into computer storage
prior to its execution) operation of the online computer Operating System
as shown in Figure 4-2-2 will require modification to accommodate location
and load of both the program module and its associated measurements table.
Even though late binding involves a distinction between program module and
measurements table, no more computer memory should be required at execution
time to support a late binding operation than that which would have been
used in an early or modified early binding system.
Online SYSTEM-Z as depicted in Figure 4-2-3 is offered as an example of
extending late binding capability into a hardware system of unusually small
capacity. The computer of online SYSTEM-Z is assumed incapable of support-
ing an online data bank as a normal peripheral device. A practical instance
of this situation might be in the case of a so-called "mini" computer system.
Even in this instance, ability to accomplish late binding has significant
advantages - predominant is the ability to accomplish binding without re-
quiring program recompilation. The late binding operation in this system
occurs at translate time on a computer of higher capability than the online
mini system. The translator data bank is labeled "online" to distinguish
it from the compiler data bank. The program module produced for use on the
target online computer would be complete, i.e., all binding accomplished.
The program module is not shown as entered to a program library since a
computer system of this minimal size suggests that such a program library
might also be beyond the support capability of the system. Tape (magnetic
or paper) or punched cards could be an acceptable storage media for the
program module.
4-4
4i
cr
GOAL
Source
._.-J^
GOAL
Compiler
n
7K
N
Compiler
Data Bank
/
Intermediate
Text
File
>
SYSTEM-X
Translator
jii.
Complete
Program
Module
_-N
Online SYSTEM-X
Utility
Program
SYSTtM-X \
Program
Library
Online
Computer
Figure 4-2-1. - GOAL Program Production Flow
As Implemented with Modified Early binding
Online SYSTEM- Y
r
I
0-,
GOAL
Source
Program
-M
Intermediate
Text
File
Compiler
Data Bank
Figure 4-2-2-
GOAL Program Production Flow
Demonstrating a Possible Late
Binding Implementation Scheme
Program
Moc
SYSTEM-Y
"^ Translator
Measurements
Table
Uti 1 i ty
Program
; Table
-^ Editor
IK
SYSTEM- Y
Program
Library
n
- J
SYSTEM-Y
Measurements
Table Library
Online
Data Bank
L
n
Online
Computer
I GOAL
I Source
I Program
A^.
GOAL
Compiler
-Ps-
I
W
Online SYSTEM-Z
1
-^
SYSTEM-Z
7=' Translator
Intermediate
Text
File
":^"
Compiler
Data Bank
Complete
Program
Module
Online
Computer
Online
Data Bank
Figure 4-2-3. - Entending Late Binding Support to an Online
tiOAL System whicn Hosts a "Mini" Computer
5.0 MISCELLANEOUS
5.1 ANOTHER REQUIREMENT FOR AN ONLINE DATA BANK
Previous experience with the computer environment of SATURN/APOLLO has
indicated that the execution of many process-control programs requires
continual man-machine monitoring and communication. In particular, test
programs used in fault Isolation tasks generally rely on their human
counterpart for redirection and specific remedial actions in the detection
and reporting of hardware anomalies. Some type of keyboard-driven terminal
appears to be the most effective man-machine communication medium. Many
actions that originate as a keyboard request or entry deal actively,
passively, or both, with the status of sensor-base hardware measurements.
If the launch complex terminal operator is to have the capability of
formulating queries relative to the status of measurements via his key-
board (either associated with or divorced from the operational requests
of any test program which may be running at the time), a measurement ad-
dressing or name convention must be established.
As discussed previously, the SATURN/APOLLO era approach to measurement
naming centered about hardware dependent terminology, e.g., the discrete
measurement controlling "2nd stage LOX vents" would be referred to via its
hardware routing "discrete output number 414" (or, simply "DO 414"). The
rationale has already been presented as to why the GOAL test programming
language addresses measurements by meaningful symbolic function designator
names rather than by hardware dependent terms. The same justifications
can be extended into the keyboard operations are to enable selection of
a meaningful measurement convention.
That the measurement addressing technique associated with keyboard operations
should be the same symbolic scheme as that which has been chosen for the GOAL
test programming language seems almost indisputable. To do otherwise would
make it mandatory that a single unique measurement be addressable by one
name within the bounds of a test program but require still another distinct
"name" be used in making keyboard referral to the same measurement. The
implications of such an incompatibility can be readily projected into the
amount of additional training required for keyboard operator and test program
writer personnel; a significant amount of additional hard copy support docu-
mentation would also be required to keep track of legitimate synonymous
measurement names and to draw parallels between the names used in manual
keyboard operations procedural documentation and the names to be found in
test program listings.
When making keyboard access to measurements by hardware descriptive symbols,
e.g., "DO 2344" (discrete output # 2344), the terminal software can easily
transform the symbolic address to an actual hardware address. Even an
extreme such as the more cryptic 14-character name convention used for
Digital Data Acquisition System (DDAS) measurements in the SATURN/APOLLO
system lends itself to ready conversion by a strictly software method into
its physical routing equivalent. Any type of name convention whereby certain
or all of the characters of the name impart hardware relations or processing
b-1
information will always appeal to those personnel whose principal tasks
involve heavy reliance on circuit diagrams or other systems drawings or
prints. To the keyboard operator, such a name scheme severely lacks many
human factors attributes. First of all, it is admitted that such schemes
yield names that are quite cryptic and therefore easily entered via key-
board - but, such names because of their cryptic nature are difficult to
remember exactly. Secondly, with a truly symbolic name such as "28VDC
GROUND POWER", a spelling error (even a single character error) almost
always results in an illegal name and the keyboard operator can be so
notified via an appropriate error response from the online computer oper-
ating system. On the other hand, a single character misspelling with a
hardware codified name can many times result in a syntactically legal
name and the logical error can pass by undetected. Consider the example
of the single character misspelling of "DO 4144" in lieu of "DO 4145" -
both could be completely legal references to actual measurements. The
terminal or operating system software packages have no method whatsoever
of making the distinction between what was requested and what was intended.
A third difficulty arises when a measurement must be rerouted and its
addressing changed. In the case of codified measurement names, physical
address modification dictates revision of the symbolic measurement name
also. Such changes in turn force "red-line" or permanent editing of
references to the rerouted measurements in system drawings and hard-
copy documentation.
The introduction of function designator type name standards for keyboard
usage implies that some type of data bank be online available to at least
the, computer that accomplishes keyboard request processing. This require-
ment can be merged with the desire for late binding facilities in the
online system; a single online data bank can fulfill all obligations of
both tasks.
5.2 THE EFFECT OF MEASUREMENT NAMES ON DATA BANK USAGE
As a general rule-of- thumb, when a file is used as a repository of variable
data, it should be searched using search arguments that do not change, i.e.,
constant search arguments. Consider the everyday use of a telephone direc-
tory; a constant name is used as a search argument to locate variable data
(address and phone number). Assume that an individual named "J. Doe"
maintains residences in 20 locations. It would be possible to query the
appropriate 20 telephone directories with the constant name "J. Doe" and
retrieve 20 variable phone numbers. Now, if the directories were restruc-
tured to be ordered by telephone number rather than by surname, their
usefulness (at least by human beings) becomes severely curtailed. For
instance, with the present example, the task of determining the location
of 20 occurrences of the constant "J. Doe" is resolved in one of two ways.
The first technique requires that the 20 variable phone numbers (which are
now the search arguments) be already known - in which case, of what use
are the telephone directories? The second method dictates a serial search
of the 20 directories; a messy proposition, even with the assistance of
data processing equipment.
5-2
The above concept of utilizing constant search arguments to retrieve
variable file contents is vital from an efficiency standpoint when
considering the design of either the compiler or the online data banks.
Specifically, measurement (function designator) names used as search
arguments into data banks should be constant. This indicates that any
name convention which uses characters of the symbolic name as indications
of hardware routing or other access information is unacceptable for names
used as data bank search arguments. The hardware indication characters
of such names are subject to change, thus making the entire name a variable.
Violations of the constant search argument principle leads to one or more
of the following ramifications:
The possibility of the keyboard operator utilizing one
measurement name convention and the test program writer
another implies that at least two or more symbolic names
must exist for each single measurement. The net effect
is that all readability between measurement names as they
exist on program listings and what appears at the output
of operations terminals disappears.
If one name convention is used for keyboard operations and
another for offline compiler usage, then two data banks of
entirely distinct format and usage conventions must be
maintained. The very real possibility of each data bank
being in a different state of update becomes a constant
maintenance headache - more so because such errors of
incompatibility are virtually impossible to diagnose or
prevent by installing software maintenance safeguards.
In the unlikely event that the GOAL language is forced to
relinquish the function designator name convention and adopt
a variable name scheme, then the present GOAL test programming
luxury of addressing the "system under test" rather than the
"test system" must be abandoned.
5.3 MULTIPLE ADDRESSING CONVENTIONS FOR ONLINE KEYBOARD USAGE
In the keyboard operations area there is a definite need for an abbreviated
method of addressing measurements. The test program writer can afford the
time required to code with pencil long (up to 32 characters) function
designator names. A keyboard operator will find entry of such names a
time consuming process - particularly during the times when he must address
several measurements in rapid succession. In an effort to establish a
name scheme that will be useful and acceptable to a wide variety of users,
it is obvious that more than one distinct conventions are required. The
most important consideration to remember is that these distinct methods
can coexist and not be in contention with one another (if implemented
properly). If, on the other hand, one name scheme must be selected thus
excluding all other(s), then the resulting compromises and drawbacks must
5-3
also be acceptable since one name convention will simply not fulfill the
needs and desires of all users in an equitable manner. In the following
paragraphs, a technique will be demonstrated to prove that several name
conventions can be used in a compatible manner. The conventions themselves
plus their individual methods of implementation must be carefully selected
to prevent the negative aspects of one convention/implementation from
carrying over into another area. In some aspects of the system illustrated
below, the negative aspects of one convention/implementation can be effec-
tively cancelled by the positive features of one or more of the other
convention/implementations.
Consider each sensor-based hardware measurement to be addressable as
follows:
1. By symbolic function designator name, e.g.,
<GROUND POWER COOLING PUMP>.
2. By a unique "measurement number", e.g., 1436.
3. By a symbolic name in which the characters indicate hardware
routing of accessing information, e.g., 10/A14C2/16.
The function designator version will follow the current GOAL language
requirements of one to thirty-two characters enclosed within brackets.
The measurement number mentioned in 2., above, will be a constant number
which has been assigned to this particular measurement; each measurement
in the system will have such a number assigned to it, starting the se-
quence at one, 1. Of prime importance is that this number be considered
just as "constant" as the symbolic function designator name - absolutely
no hardware implications are present in these nuntiers. The hardware-
dependent symbolic name mentioned in 3., above, can be formed using any
rules suitable to the user group concerned with such terminology. The
example extended above was generated strictly as an example. Since this
name version utilizes hardware-dependent characters in its formation,
the resulting name is not a constant. Certain drawbacks associated with
using variable names as data bank search arguments were presented hitherto
In Section 5.2. When a variable name version is used in conjunction with
a fixed convention, most of the negative aspects of the sole use of the
variable technique are nullified. The problem remains of assuring that
the variable name is updated in a timely and precise manner whenever the
inevitable measurement hardware changes occur.
Specific rules in regards the use of the three names presented In the
example above are as follows:
The function designator and measurement number are
constant and will not change throughout the life of
the measurement. The hardware dependent version can
be expected to change if hardware accessing modifi-
cations are required.
b-4
Only the function designator name convention can be
used in the GOAL test programming language.
All three name versions can be used interchangeably
for addressing measurements via keyboard terminal.
The use of all versions at the online terminals implies that a variety of
users can be serviced - each using the convention most suitable to his
needs. All three versions will seek hardware accessing and scaling infor-
mation from the appropriate measurements record of the online data bank.
The function designator and hardware dependent versions will require a
data bank directory search prior to locating the required measurements
record. A significant feature associated with the measurements number
name version is that the number can point directly to the measurements
record. In the example, a measurement number of 1436 would lead to access
of the 1436th data bank record; thus, no prior directory search would be
required. The use of measurements number names would be feasible in place
of the function designator types in the measurements table application
mentioned in Section 4.2. This would result in an appreciable time savings
In the update of the measurements table library; elimination of the direc-
tory search decreases the total number of input/output operations required
to locate a given measurements record In the data bank by approximately 75%.
As an example of terminal output, using any one of the three names mentioned
previously will result in the following terminal sequences:
(keyboard
input) <GROUND POWER COOLING PUMP>?
(terminal
response) <GROUND POWER COOLING PUMP> = M1436 = 10/A14C2/16 = ON
Thus, use of any one name will result in appearance at the terminal of the
selected name plus the other two versions in addition to the measurement
status. The output format illustrated above was chosen carefully since
certain drawbacks of using individual name conventions can be eliminated.
Consider the following advantages and features:
It was mentioned previously that a short name convention
(like the measurement number) can be very attractive to
a keyboard user from the standpoint of brevity and rapid
entry. Such names are subject to misspelling errors that.
In general, cannot be detected. For example, consider the
following input/output sequence:
(Inquiry) Ml 436?
(Response) Ml 436 = ON
If the user had entered the 1436 measurements number in
error thinking that it was associated with the "STAGE II
LOX VENTS", no Indication of error can be ascertained in
5-5
abbreviated output sequence above. The extended output
illustrated in the previous example would have served as
an error indication when the terminal operator noted that
the <GROUND POWER COOLING PUMP> name was not what he intended.
If a user was in doubt as to the exact spelling of one name
version of a given measurement, and he knew either of the
other two, then a simple keyboard query using the known
name will suffice to determine the unknown version(s). This
gives the online keyboard operator a convenient method of
cross referencing measurement names. Consider the instance
of a technician 1n a remote location who required the hardware
dependent name for the "Ground Power Cooling Pump" for use in
circuit diagram reference. Intercom correspondence with any
available launch complex terminal operator will provide the
required name.
5.4 IMPLICATIONS OF A TWO-DATA BANK SYSTEM
Consider an automation system which is supported by a general purpose GOAL
compiler. For each active and distinct online system there also exists a
separate translator program whose function is to tailor the general-purpose
GOAL program module as produced by the compiler to the specific needs of
each online system. Within the same system framework there exists a data
bank to support compiler operations called the "compiler data bank". Each
distinct online system will be supported by a separate "online data bank".
The following salient features and considerations attendant to such a system;
Maintenance of the compiler data bank with regard to function
designators is considerably simplified in a system with two
data banks. For each function designator, the compiler data
bank need contain only symbolic function designator name plus
measurement type (discrete, analog, etc.), data. Specifically,
no addressing data is to be present in this data bank; there-
fore, hardware addressing changes have no maintenance implica-
tions in this data bank. Function designator maintenance within
the compiler data bank involves only addition and deletion of
measurements.
Absence of hardware measurement data in the data bank asso-
ciated with the compiler implies that only one logical data
bank need be used at compile time to store measurement
information for all programs. All measurement names for all
distinct online systems can be present in the same compiler
data bank.
Presence of an "online data bank" implies that the keyboard
language and the offline compiled test program language have
consistent name conventions.
t>-b
To inject late binding capabilities into the GOAL test
programming system, translator production of both a
program module plus a separate measurements table were
discussed in Section 4.2. As an indirect advantage of
having the measurements used within each test program
isolated as a separate data structure, consider the
following hypothetical problem: "...the Stage-II AC
Bus Overload Indicator is faulty, but cannot and need
not be replaced until tomorrow. What test programs,
if any, would be effected by unavailability of this
measurement?..." Such a question could be introduced
to the online system via keyboard. A relatively simple
software utility routine could be devised to search the
tables located in the measurements table library for an
occurrence of the measurement name(s) of concern. The
name(s) of the test programs containing such measurements
would then be output to the terminal that initiated the
search. The attractive aspect of seeking an online
solution to such problems is that the answers so derived
are generated very rapidly and 100% confidence can be
placed in the accuracy of the results. Such information
can form the basis for a great many technical and manage-
rial decisions that would otherwise be either impossible
to resolve, or so time consuming as to be impractical.
Measurement addressing changes are introduced to the
online system via a two-step process. First, a utility
program is used to inject addressing modifications to
the online data bank. This program could be run on a
computer system distinct from the computer associated
with the online data bank. This would be quite feasible
in the event that the data bank was to reside on a remov-
able disk pack. The utility operation could also be
accomplished in an interactive manner with commands
entered via keyboard terminal. The data bank update
process involves locating the required measurement record
in the online data bank by using the function designator
name as the search argument. Once the record has been
found, the required measurement addressing data can be
modified and the revised record rewritten back to the
data bank. Once all data bank update (s) have taken
place, the second step involves starting a utility
service program to propagate any measurement addressing
changes into the measurements table library. The action
of this service process would be as follows:
* Fetch a measurements table from the library.
5-7
* Compare each function designator name in the
table against the list of modified function
designators. If present in the table, revise
the table addressing data accordingly.
* If any table revision has been necessary, rewrite
the table back to the measurement table library
and proceed with the next table. If no changes
were required in the current table, proceed im-
mediately with the processing of any remaining
table(s) in the library.
Modification of a program's measurement table would likely
be logged as a significant data processing event. If the
data bank update was accomplished online, the keyboard
operator would be notified of the results of the update
by an appropriate output message indicating program name
and the function designator(s) that underwent change. Such
changes could be introduced into an online and operational
system in a convenient and timely manner - the concept of
introducing an expedient temporary hardware change or over-
ride that is destined to remain in effect for a short
duration {say, a manner of hours) and then reverting to a
normal system configuration becomes an attractive and
practical possibility. A crude estimate of the time re-
quired to accomplish a data bank update appears in the
following example:
Let: P = 100 = Total number of test programs in
the current online program library
R = 10 = Average number of DASD read operations
required to completely access a mea-
surements table for a single program
M = 50/i = Percentage of programs whose measurement
tables will require modification due to
recent measurement addressing change
W = 3 = Average number of rewrite operations
required for those tables to be modified
T = 8 = Average number of read/write operations
that can be accomplished per second on
the DASD used for the measurement table
library
Negligible computer central procesor time required for
all operations involved in the measurement table update
b-b
Then;
Total time required for
measurements table = P R + P W x M
library update (seconds) T T TOO
= 100(10) + 100(3) X 50
_^ -^-/ ,^
= 143.75 Seconds
5-9
APPENDIX A
THE DATA BANK FILE DESIGN
A. INTRODUCTION
Within this Appendix are indicated the criteria which evolved into the
functional design of the data bank file of the first GOAL compiler
Implementation. Although the original implementation utilized IBM
Direct Access Storage Devices (DASD) and support software, it 1s felt
that the file design could be successfully transcribed to the DASD of
other manufacturers. Specifically, the file design relies on no fea-
tures that are found only on IBM DASD or support software. In general,
the following functional DASD capabilities must be present to support
the current data bank design:
The DASD must be capable of supporting a data set
organization of fixed length logical records.
Random read and write access to any one of the (n)
records within a data set of (n) total records must
be possible by specifying the relative record number
utilizing the first record of the data set as the
origin. With the additional requirement of fixed
length logical records, the absolute address of a
given record can be easily determined by knowing the
relative record position.
To accomplish data bank maintenance in the same fashion
as that of the current IBM implementation, a general
purpose sort utility program is required. If in another
system such a program Is not available or feasible,
adequate computer storage must be available to accomplish
the sort operation in a memory resident fashion.
A.l GENERAL FILE DESIGN
The records of any file must be logically organized such that they can be
inserted or retrieved for processing. In the selection of a certain file
structure, all of the following are to be considered:
File Creation - separate program(s) must usually be
developed to Initialize the first copy of a file.
Thereafter, a revised or new copy of the file is
created by update of an existing version. The GOAL
data bank requires a special initialization program
to prepare the DASD storage before records can be
inserted.
A-1
File Use - Usually, a given file application will
dictate that the file be usable either to read records
from or to write into. The data bank application
requires both read and write capability within the
same program.
File Maintenance - Very few files can be envisioned
that will not require either periodic or sporadic
maintenance. The term "maintenance" Is generally
construed to mean the addition, replacement, changing,
or deletion of records. The data set design will in
some ways dictate and other ways be constrained by the
maintenance techniques or requirements. In the case
of the data bank, the existence of a sort utility program
makes directory maintenance immensely easier.
File Backup - This may be as simple a process as copying
the file on to another medium (magnetic tape Is popular
for this usage) to enable partial or complete recovery
from an unforeseen disaster to the file prime copy. The
GOAL data bank system has been structured such that the
directory data set can be completely destroyed and
successfully recovered using the contents of the data
bank set alone. The data bank data set must be backed
up by copy to another medium such as tape. As this
time, no specific software modules have been provided
to effect these recoveries.
A. 2 DATA FILE CHARACTERISTICS
The following inherent characteristics form the basis for selecting an
efficient method of file organization:
Size - A file so large that it cannot be all online
{available to the system) at one time dictates very
specific organization and processing techniques. The
data bank was designed with the intent of having all
of the file online, but resident on DASD. Generally,
only one record at a time will be of interest 1n data
bank utilization. These records must be randomly
accessible.
Growth Potential - It was convenient to size the original
data bank at a capacity (8000 entries) considerably above
that currently being used (approximately 2000 entries).
Thus, the data bank may expand significantly without
requiring an overall size increase of the data set. If
and when an increase in overall capacity is required,
this can be accomnodated with modest effort within the
framework of the original data bank design. The original
data bank support and maintenance modules were written
A-2
in FORTRAN - because of FORTRAN language constraints,
a data bank resizing will require changes to the
declarations section of several modules. Except at
very infrequent intervals, it is considered unlikely
that resizing will be required; the inconveniences
resulting from these software changes were not there-
fore, considered prohibitive.
Activity - In regards the amount of activity, an inactive
file may be referred to so infrequently that the particular
file structure or processing technique chosen does not matter.
The GOAL data bank is considered a file which typifies the
other extreme, i.e., an active file to be heavily used by
the GOAL compiler. The file structure was chosen carefully
to avoid an inordinate amount of time searching for desired
records .
The percentage of activity is also a factor of consideration.
The data bank is an application which requires retrieval of
only a low percentage of the available records in a file
during an average processing run. This use implies a random
type organization such that any record can be located con-
veniently without having to scan all or a large number of
other records In the file. In the GOAL data bank each
record may be essentially considered an independent data
entity having no relationship {physical or logical) with
any other record of the file.
In some instances the activity distribution can be a file
design factor. If some group of records are more frequently
significant than others, some method of locating these
records is in order so that they can be effectively fetched.
The Data Bank Reference Records in the GOAL data bank are an
example of records of this type; they have been located in
a fixed specific area within the file so that they can be
efficiently searched and processed,
A. 3 FILE PROCESSING CHARACTERISTICS
The usage of a file usually dictates the type of processing In which the
file will be involved. Sequential processing of a file implies that the
records will be processed in a monotonically Increasing or decreasing
sequence. A deck of cards or magnetic tape is ideally suited to this
application type. To be effective, the records of a sequentially
processed file must be sorted according to the sequence to be followed
in processing. The records are then written in a physically contiguous
fashion in the file. Thus, the next record to be processed is always
immediately adjacent to the current record. Although sequential processing
can be extremely rapid in many applications, its use demands that all input
transactions be batched (collected) and sorted to the same physical key
sequence as the file before processing.
A-3
Random processing allows (or, rather, requires) that all records of the
file be accessible and writeable in a random order. No collection or
sorting of input transactions is required before processing. The same
could be said of the records within the file itself, i.e., there is no
required record sort sequence or rules concerning which records need be
physically adjacent. The GOAL compiler requires access to the data bank
in a strictly random manner; the actual method chosen for implementing
the data bank allows sequential processing also.
A. 4 DATA BANK CONTENTS
GOAL compiler support was the prime function of the data bank in the first
implementation of the GOAL language. This encompasses data records of
the following type:
Function Designators - In almost all instances, a
function designator record contains sensor-base
hardware data such as measurement type (discrete/
analog, input/output, etc.) and physical hardware
addresses.
Note - The term "function designator" is used
within the GOAL language for purposes
other than symbolic names for sensor-
based measurements.
GOAL Subroutine References - These records provide
abbreviated system dependent names for GOAL sub-
routines.
GOAL Macros - These records contain user-written
and system macros to be used as writer aides during
compilation of a GOAL test program.
The functional design presented in Appendix B indicates a few other record
types in the data bank file used for file structuring and searching aids.
Most (possibly, 99+%) of the data bank file records will be function
designator records. A direct access (random) file structure for relative
record retrieval must contain fixed length logical records. Since the
file contains records of varying data context, the fixed record length
must be large enough to accommodate all of the data of the largest record
type.
Records of other tyoes will then utilize only a portion (and, consequently,
waste the remainder) of the total record capacity. Fortunately, the record
type requiring the largest record capacity was the function designator type;
total waste space will therefore be minimized in the file. An individual
function designator will require only one data record for Its description.
A GOAL subroutine will require only one record for its name reference. A
macro will require two or more records.
A-4
A. 5 DATA BANK USAGE
The GOAL language stipulates that each function designator, macro, or
subroutine Is identified by a unique 1 - 32 character symbolic name.
The GOAL compiler queries the data bank providing only this 1 - 32
character name. Using this name as a search argument (record key), the
data bank software must either locate and retrieve the required record
or signify that a record associated with the supplied key does not exist
within the data bank.
Features of the GOAL language also require that a number of uniquely named
'data banks' is resident in one data bank file.
A-t)
APPENDIX B
THE DATA BANK FUNCTIONAL DESIGN
B . INTRODUCTION
Within this Appendix is presented a functional description of the data
bank design as implemented for use by the initial version of the GOAL
compiler.
B.l BASIC SPECIFICATIONS
The principal functions of the tiOAL data bank are outlined in the following:
The data bank shall provide for the storage and retrieval
of uniquely named GOAL function aesignator records, macro
records, and subroutine reference records.
Function designator, macro, and subroutine records are to
be individually retrievable by specifying: (1) the name
of the aata bank in which the record is assumed to reside,
and; (2) the unique record name. Record names are assumed
to be unique only within the bounas of the specific data
bank in which they are found, e.g., the record called A
can be the only record with that name within the data bank
in which it is found. There can be, for instance, a record
A within a data bank called X; another record A can exist
in data bank Y, etc.
The data bank system shall provide a file organization
capable of supporting and selectively using several
uniquely named independent data banks. The total number
of data banks to be supported at any one time shall be
selectable at file initialization time. Provision has
been made to allow increase of the number of allowed data
banks after file initialization without requiring complete
reinitialization of the system; utility software has not
been provided to accomplish this extension at this time.
B.2 GENERAL APPROACH
The data bank will be a disk resident file constructed primarily for random
(non-sequential) processing.** The file structure is to support random access
to any uniquely named record (member) by supplying the record's symbolic name
(record key). To support this operation, two disk resident data sets will be
required. One will be referred to as the "data bank," "data bank file," or
**The file structure chosen allows for sequential as well as random processing.
6-1
"data file." This data set will contain the GOAL function designator,
macro, and subroutine records. The second data set will be deemed the
"data bank directory," or "directory." The directory will contain an
index to all named records in the data bank. Each index entry will
consist of the record name, an indication of the uniquely named data
bank in which the record logically resides, and the relative record
position of the record within the data bank data set. All of the index
entries within the directory shall be sorted in a manner that is
conducive to efficient search.
The operational concept of the data bank Is analogous in e'^ery way except
physical record layout to the technique required to use an everyday
telephone directory. The telephone number and address are the data
records of the telephone directory; the names are the record keys. If
one is to conduct an efficient search through so large an assortment of
keys, the keys must be placed in a physical structure in such a way that
some type of search is strategically possible. For alphanumeric keys
(such as human names or data bank record names), sorting the keys into
alphanumeric collating sequence is a method which allows effective human
or machine search.
Figure B-1 illustrates the functional relationship between the distinct
elements of the data bank system. In the data bank design, the data portion
of the file 1s resident In the data bank data set while the sorted grouping
of record keys is to be found In a distinct data set called the directory.
Accompanying each key in the directory is the record location (in the data
bank) where the data associated with that key is to be found. This split
arrangement of keys in one data set and data in another has four distinct
maintenance advantages over the combined record technique of the telephone
book, to wit:
The directory must be in sorted key sequence for search
reasons. When maintenance decrees the addition or deletion
of records, the directory must be re-sorted to accommodate
the new keys and to eliminate the old. It is to be noted
that the keys must be sorted to accomplish this aim - there
is no requirement that the data be rearranged in any manner.
By involving only the contents of the data bank directory in
the maintenance key sort operation, the speed at which both
the sort and the directory data set reconstruction can be
accomplished is significantly enhanced.
With distinct directory and data bank data sets a larger
number of keys can be present in a given size of record than
would be possible if both keys and data were present in the
Scune size record. The speed at which the directory search
can be accomplished will be almost wholly dependent on how
many input operations are required to fetch records contain-
ing keys.
B-Z
If a small number of keys are present in each record,
then many records may be required, etc. A crude analogy
exists in the example of the telephone directory - if the
current directory page size were increased to newspaper
size sheets, one would have to turn fewer pages to find a
given key. In contrast, if the telephone directory were
reprinted on 3 x 5 cards, a great deal of page turning
would be required.
Although the directory must be maintained in sorted order,
there is no reason why the effort must be expended to
maintain a sorted data bank file {containing the data).
Put in another way, the data records, once entered into
the data bank, need never be reshuffled to accommodate
new or deleted records. This feature leads to a signifi-
cant savings in maintenance time. As an illustration to
the contrary, consider the maintenance required for a non-
random sequentially organized data set, e.g., a magnetic
tape. The time spent in reshuffling (recopying) the entire
data set to accommodate one record addition/ deletion/change
could comprise 99.99% of the total maintenance time. This
disproportionate time mix degrades even further as the data
set size increases.
By avoiding a reshuffle operation on record addition/ deletion
in the case of the data bank file, it was possible to adopt
a scheme for effectively reclaiming the space vacated by
deleted records. Once a record has been deleted, the record
position becomes available for use in adding a new record in
a subsequent maintenance run. During data bank initialization,
all free records are chained together to form what is referred
to as the "free record queue," i.e., all record spaces avail-
able for use. When a record is to be added to the file, the
first available record on the free queue is removed from the
chain and used for the addition. When a record is deleted,
the record space is reinserted to the head of the free queue
chain, thus making the space reusable.
B.3 GENERAL DIRECTORY STRUCTURE
The illustration of Figure B-1 depicts the directory as a single table con-
taining one entry for each record in the data bank. Such a directory that
contains (n) entries for (n) record references is deemed an "inverted"
directory. If it were possible for the table to be totally memory resident
at use or maintenance time, access to any record of the file would proceed
at maximum speed - a simple memory table search followed by one I/O read
B-3
would be required. Unfortunately, such a single-level table becomes
prohibitively large even for a relatively modest size data bank file.
It must therefore be broken into segments of a size such that any one
can be conveniently contained in computer memory.
Figure B-2 indicates an example of a directory that has been structured
into a series of blocks ("directory blocks" or "directory records") in
two levels. In general, two types of blocks are present - one "master"
block and several "lower level" blocks. The lower level blocks accumu-
latively represent the single inverted directory table broken into
segments of a more practical size. Each individual entry in a lower-
level block consists of a record name and a pointer (record number) to
that record in the data bank file. If the directory contained only lower-
level blocks, any one of which could be memory- resident at a given time,
then a block-by-block serial search would be required to locate a record
in the directory. Access of any one directory block would require one I/O
read operation. As a method of eliminating the serial search and thus
enhancing overall directory search speed, a master directory block has been
introduced as shown in Figure B-2. This block indicates the contents of
all of the lower-level blocks of the directory. Each master block entry
points to a lower block and indicates the highest (in collating sequence)
named entry in that block. If the master block can be made memory- re si dent,
a search for a given record proceeds as follows:
1. Via the master block, determine the lower-level block which
must contain the sought none. In the example of Figure B-2,
a name "D" must be contained in block 3 since block 2 contains
as the highest entry "B", and block 3 as the highest entry "G".
2. Access the required lower- level block.
3. Search the lower- level block for the required name.
4. After finding the directory entry containing the record name
in the lower-level block, use the record number portion of
the entry to fetch the sought record from the data bank file.
The above process requires only two I/O read operations to find and retrieve
any given named record from the data bank file; note that the assumption has
been made in this instance that the master block was memory- resident before
the search started.
Since the directory itself is a direct-access (randomly organized) data set,
it will be significantly easier to manipulate if all records (blocks) are of
constant or fixed record length. This results in a "balanced" directory -
each block contains a constant number of directory entries. The unbalanced
directory of Figure B-2 has been rearranged to a balanced form in Figure B-3.
b-4
The "directory blocking factor" (N), i.e., the total and constant number
of directory entries possible per directory block, for this illustration is
four (4). Note that for a two-level balanced directory there will always be
(N) blocks at the lowest level; this then implies the following size
relationships;
Given a directory blocking factor (N);
Total number of blocks
in the directory data set = N + 1
Directory block size (words
or bytes) = N x (Directory entry size in
words or bytes)
= the amount of computer memory that
must be present for one directory
block
Total number of named records
that can be referenced in the
directory = N
Using the above as a basis for determining directory blocksize, assume that a
data bank to support a total of 8,000 entries is required;
Let (N) = 90
Total entries supported = N^ = 8,100
Directory blocksize = N x (directory entry size)
= 90 X 7b (current implementation
directory entry size)
= 6,840 bytes
The directory blocksize in the above instance has grown to a \/ery large entity-
requiring a large memory block for support. If the master block is to remain
memory- resident, and the lower-level blocks retrieved as required one-at-a-time,
a total of 13,680 bytes of computer memory would be required to support
directory operations alone. This is considered a severe cost to service a data
bank file of 8,000 records. The eventual size of the operational GOAL data
bank could run as high as 30,000 to 100,000 entries. A two-level directory to
support such a sizeable data bank would require directory blocks of enormous
capacity.
The solution selected to obviate the above sizing problem is illustrated In
Figure B-4. Here, the two-level directory has been expanded vertically into
a three-level balanced version. Figure B-5 represents a tabular comparison
b-b
of the size potentials between two- level and three- level directories. The
calculations are related to an IBM 2314 disk unit which supports a total
track capacity of 7,294 bytes (data plus inter-record gaps, as required).
The directory blocking factor (N) was considered in the range of 10 to 50
entries per block - this upper limit will support a data bank of 125,000
entries with a three-level directory.
B.4 GENERAL CONTENTS OF DIRECTORY RECORDS
Figures B-6 and B-7 depict the layout of the master, upper-level, and the
lower-level directory blocks. Each block is seen to be composed of a block
header and (N) directory entries. The block header indicates:
the record (block) number in the directory file
the total number of entries possible in the block (N)
the total number of directory entries currently in use in the
block
Each directory entry is seen to contain:
A delete field - used during maintenance to delete reference
to an existing record
A record name - consisting of a data bank reference number
and a 1-32 alphanumeric character symbolic name
A pointer to another record (record number) either in the
directory data set (master and upper-level blocks) or to
the data bank file (lower-level blocks only)
As indicated above, the total record name contains two significant portions -
the data bank reference number and the proper alphanumeric name. Each uniquely
named data bank is assigned a unique reference number when the data bank is
originally created. This reference number becomes the first 32 bits of the
names of all records contained within that data bank. The data bank reference
number is actually the record number of the applicable Data Bank Reference
Record in the data bank file.
Figure B-8 indicates pictorial ly the relative positioning of all blocks to be
found in the directory data set. The actual block numbering scheme and order
of loading is indicated in Figure B-9.
B.5 DATA BANK FILE CONTENTS
Figures B-10 and B-11 tabul arize the general record types and contents of the
records to be found in the data bank file. The relative positioning of the
records within the file was indicated in Figure B-8. All data bank records are
fixed in length and each contains a header followed by a data segment.
B-b
B.5.1 Data Bank Capcity Record
This record is the first record of the file. The data bank Initialization
program composes this record in accordance with control card input when the
data bank file is first established. Figure D-1 indicates the initialization
action. Only a portion of the header and none of the data portion is used in
this record type. A brief description of the field contents is given below;
the exact record format is to be found in Appendix E.
Record Number - This record is located first in the file so
that the use and maintenance modules can find it without search.
Total number of Records Available (RAVAIL) - This is the total
number of record spaces which were allocated for the data bank
file when it was originally created. This value is established
during initialization (read from a control card).
Total Number of Records Still Unused (FQTOT) - This field represents
the total number of records remaining on the Free Queue for use in
adding new records to the data bank. This is initialized to the
total number of records reserved for the entire file minus those used
for the capacity record and the data bank reference records.
Symbolically:
FQTOT = RAVAIL - (D3MAX + 1)
Pointer to Head of Free Queue (FQPTR) - A field indicating the first
record available for allocation in the data bank. The next time that
a new record is added, the record at the head of the Free Queue is
used. This field is initialized to point to the first record beyond
the data bank reference records in this file. Symbolically:
FQPTR = DBMAX + 2
Maximum Number of Allowed Data Banks (DBMAX) - This is the total number
of uniquely named data banks that will be allowed to exist. DBMAX is
initialized to the amount read in via control card during initialization
plus one more to allot for a mandatory data bank called "SYSTEM." This
SYSTEM data bank will become a part of the system at initialization time.
Total number of Data Banks Now in Use (DBCUR) - This field reflects
how many data banks are currently being used. The value is initialized
to one (1) - to account for the mandatory SYSTEM data bank.
Directory Blocking Factor (DBF) - This value has been hardcoded into the
data bank initialization program and is set at 20 for the current
implementation. A change of this value will dictate several changes to
different program modules - discussion of these changes is covered in
this document, Appendix C.
B-7
B.5.2 Data Bank Reference Records
These records follow the capacity record in the data bank file. One
reference record exists per allowed data bank - the user specifies via
control card during data bank initialization as to the total desired. A
factor of thirty (30) will be used for the original implementation. The
first data bank reference record (record number 2) will be initialized for
the data bank called "SYSTEM." All other reference records are initialized
to the unused state and will remain so until data bank(s} are established
during normal maintenance. A detailed discussion of the record fields is
given in Appendix E. A brief coverage of the general contents is below:
Record Number - This set of records appears in the data bank
starting at record position number 2. The data bank called
SYSTEM will be initialized at record position 2. Record positions
will be assigned to subsequently established data banks on a first-
come, first- serve basis.
Forward Chain - All data bank reference records will be chained
together at initialization time. This chain provides an efficient
method of serial search to determine if a given data bank exists
or not. Also, when adding a new data bank reference, the chain is
followed until an unused reference record is located.
Type Field - All but the type field associated with the reference
record for the mandatory SYSTEM data bank will be initialized to
one (1), which implies the record is unused and free for use. When
maintenance requires the addition of a new data bank, the reference
record chain is followed until a vacant (type =1} record is located;
this record position will then be used for the new data bank.
Maximum Number of Allowed Data Banks ~ Established during file
initialization.
Data Bank Number - The data bank reference numbers are established
during initialization to be equal to the record numbers in which
the fields appear. Each named data bank Is referenced by the user
via a symbolic (alphanumeric) name. Within the data bank software,
all references to data banks are made by use of data bank reference
numbers. This number becomes a portion (the leading 32 bits) of
each record name in the system that "belongs to" or is associated
with that data bank.
Data Bank Name - The 1-32 alphanumeric character data bank name.
The first character must be a letter.
Revision Label - This field is optional with any given data bank.
If present, it is a 1-32 character name. If the revision label is
not used In a given record, this field will be totally blank.
b-y
B.5.3 Other Data Bank File Record Types
Table B-12 tabul arizes the functional contents of all record types to be
found in the data bank file. Data Bank Reference records have already been
discussed. The remaining record types consist, in general, of a header and
a data area. Function Designator and Subroutine Name records will always
occur singularly - accordingly, the header (see Figure B-ll) for these types
will be consistent in format as indicated in the following:
Record Number - As required
Forward Chain - Always null (zero)
Type Field - See Table B-12; as required
Total Number of Records This Chain - Always one (1)
Pointer to Last Record, This Chain - Always points to this record
number (the record containing the field)
Data Bank Number and Record Name Fields - Always used
Print Expansion - One to 32 character name; record name as it is to
appear on compiler listings; this may or may not be the same as the
record name field
Data Portion - Used as required for record type; Appendix E indicates
an exact record description.
Macros will be represented in the data bank file by a Macro Header record
followed by one or more Macro Skeleton records. The records pertaining to
one macro will be linked via their respective forward chain fields. Figure
B-11 indicates that the header of the Macro Skeleton records is abbreviated
from the type normally found on other record types. The macro skeleton card
image occupies a portion of the header as well as all of the normal data
segment. The maintenance processing program will scan each macro skeleton
card, locate each occurrence of a formal parameter, and replace each occurrence
with the following character sequence:
1st Character = '& (ampersand)
2nd Character = Single digit, 1-0, representing formal parameters
one through 10, inclusive
3rd Character = � (ampersand)
4th through
Next to Last = & (ampersand)
Last Character = Blank
A maximum of ten (10) formal parameters will be allowed for any given macro
in the current implementation.
b-9
o
,<i-
<-
"THE DATA BANK'
->f
DATA BANK DIRECTORY
Record
Name
ALPHA
BETA
DELTA
GAMMA
Record
Location
4213
10
11
7211
^
DATA BANK FILE
Record
Location
10
11
4213
7211
Beta Record
Delta Record
Alpha Record
Gamma Record
^^
Figure B-1. FUNCTIONAL RELATIONSHIP OF DATA BANK ELEMENTS
Block 1
SIMPLIFIED TWO-LEVEL INVERTED
DIRECTORY ~
f TYPICAL LOWER-LEVEL BLOCK ENTRY
Databank
Record
Name
Pointer (Record
Number to the
Databank file
/
/
/
B
2
G
3
K
4
M
5
T
6
X
7
Block
2
BlVk 3
/
Bloc
k 4
A
B
D
G
J
K
DIRECTORY MASTER
BLOCK
Highest
(Col 1 ating
Sequence)
Record Name
Pointer (Block
Number) to one of
the lower level
Directory Blocks
TYPICAL MASTER BLOCK ENTRY
Block
5
Block
6
Bloc
k 7
L
M
Q
T
W
X
Figure B-2.
ILLUSTRATION OF TWO-LEVEL
BALANCED DIRECTORY
I
TTT
(N)
Entri es
_^
Block 1
G
2
M
3
X
4
N/U
N/U
DIRECTORY MASTER
BLOCK
(N) = Directory Blocking Factor;
total number of directory
entries per directory block
N/U" = Not Used At Present;
Available for Future Use
Block 2
Block 3
Block 4
Block 5
. A
**
B
D
G
J
K
L
M
"TfT
(N)
Entries
^
Q
T
W
X
N/U
N/U
N/U
N/U
1
** Pointers to Databank File Omitted
in this Illustration
Figure B-3.
or
t
CO
MASTER
BLOCK
(3) (4)
(n) (12)
(7)
Directory Blocking Factor = N
Maximum # Databank Member Names = H =27 (Only 20 used in this example)
Total # Directory Blocks Required = (N)^ + (N) +1 = 13 in this example
Directory Block (Record) Numbers Shown in Parenthesis Above
3 in this example
,3
(N)
UPPER
LEVEL
BLOCKS
LOWER
LEVEL
BLOCKS
Figure B-4. SAMPLE DATABANK DIRECTORY SHOWING BLOCK STRUCTURE
*** ASSUMING 7&-BITE DIRECTORY EiiTRY SIZE
***BLOCKSIZE IIJCLUDES 12-BYTE HEADER
*=
BLOCK
WASTE
*
PER
PER
TOTAL
/�/
BLOCKSIZE
TRACK
TRACK
ENTRIE
10
772
8
1118
100
11
848
7
1358
121
12
924
5
17 50
144
13
1000
6
1294
159
m
107G
6
838
196
15
1152
5
1534
225
15
1228
5
1154
256
17
1304
5
7 74
28 9
18
1380
4
1774
324
19
145G
4
14 70
361
20
1532
4
1166
400
21
1506
4
862
441
22
16(14
4
558
404
23
1760
3
2014
529
24
183C
3
1785
576
25
1912
3
1558
525
26
1988
3
1330
675
27
2054
3
1102
7 29
28
2140
3
874
7 84
29
2216
3
646
841
30
2292
3
418
900
31
2368
2
2558
961
32
2444
2
2406
1024
33
2520
2
2 2 54
1089
34
259G
2
2102
1156
35
2 67 2
2
1950
1225
36
27 48
2
17 9
1296
37
2824
2
1G4G
13 59
38
29
2
1 4 9 4
1444
39
2 97 G
2
1342
1521
*********** 2 -LEVEL **********
* *
TOTAL TOTAL *
DIRECTORY SPACE
BLOCKS ALLOCATION
*********** 3-LEVEL **********
* *
* TOTAL TOTAL *
TOTAL DIRECTORY SPACE
ENTRIES BLOCKS ALLOCATION
11
2
12
2
13
3
14
3
15
3
16
4
17
4
18
4
19
5
20
5
21
6
22
G
23
6
24
e
25
9
25
9
27
9
28
10
29
10
30
10
31
11
32
16
33
17
34
17
35
18
36
IS
37
19
38
19
39
20
40
20
Figure B-5.
(1 Of
1000
1331
1728
2197
2744
3375
4095
4913
5832
6859
8000
9261
10648
12167
13824
15525
17576
19683
21952
24389
27000
29791
32768
35937
39304
42875
4 6 6 5 6
50G53
54872
59319
111
133
157
183
211
241
273
30 7
343
3 81
421
463
507
553
601
651
703
757
81 3
871
931
993
1057
1123
1191
1261
1333
1407
1483
1561
14
19
27
31
36
49
55
62
86
96
106
116
127
185
201
217
235
2 5 3.
271
291
311
497
529
562
59G
631
657
704
742
781
***ASSUMIUG lb-BYTE DIRECTORY ENTRY SIZE
***BLOCKSIZE li'^CLUDES 12-BYTE HEADER
* 4r * * * * * ** * *
*
2- LEVEL
N
40
41
42
43
44
45
4G
47
48
49
50
ULOCKSIZE
3052
312 8
3204
3280
3350
3432
3508
3584
3560
373G
3812
BLOCK
PER
TRA CK
2
2
2
2
2
2
2
1
1
1
1
WASTE
PER
TRACK
1190
1038
88 6
734
582
430
270
3710
3634
3558
3482
TOTAL
ENTRIES
1600
1681
1764
1849
19 36
2025
211G
2209
2304
2401
2500
TOTAL
DIRECTORY
BLOCKS
41
42
43
44
45
46
47
48
49
50
51
**********
*
TOTAL *
SPACE
ALLOCATION
21
21
22
22
23
23
24
48
49
50
51
*********** Z- LEV EL **********
* *
* TOTAL TOTAL *
TOTAL DIRECTORY SPACE
ENTRIES BLOCKS ALLOCATION
64000
68921
74088
79507
85184
91125
97336
103823
110 5 9 2
117649
125000
1641
1723
1807
1 893
1981
2071
2153
2257
2353
2451
2551
821
862
904
947
991
103G
1082
2257
2353
2451
2551
Figure B-b. (2 of 2)
I
^
(N) Individual Directory Entries Per Block
BLOCK HEADER
DIRECTORY
ENTRY # 1
\
X
TYPICAL BLOCK HEADER FOR \
.MASTER (RECORD #1) AND . ^
fUPPER-LEVEL BLOCKS
Block
(Record)
Number
Total #
Entries
Possible in
this Block
Total #
Entries now
in Use in
this Block
^� Header Length = 12 Bytes
^
DIRECTORY
ENTRY # 2
/
-^
DIRECTORY
ENTRY # (N)
^
^
A TYPICAL DIRECTORY ENTRY FOR MASTER
OR UPPER-LEVEL BLOCKS
(N) = Directory Blocking
Factor
Pointer (Block #)
to Block at Next
Lower Level
Delete
Field
Databank
Reference
Number
Search Key
(Member
Name)
(32-Chars)
Length of Individual Entry = 76 Bytes
M
Figure B-6. DATABANK DIRECTORY: MASTER AND UPPER-LEVEL BLOCK LAYOUT
CD
e
(N) Individual Directory Entrsjes Per Block
BLOCK HEADER
ENTRY # 1
ENTRY # 2
\
\
\
\
Block
(Record)
Number
Total #
Entries
Possible 1
this Bl ock
Total #
Entries novj
in Use in
this Block
^Header Length = 12 Bytes
^
y
�>
y
X
X
X
X
ENTRY # (N)
(N) = Directory Blocking
Factor
Pointer (Record #)
to Member Record
in Databank File
Delete
Field
Databank
Reference
Number
Search Key
(Member Name)
(32-Chars)
^
Length of Individual Entry = 76 Bytes
^
Figure B-7. DATABANK DIRECTORY; LOWER-LEVEL BLOCK LAYOUT
Record #1
Master
Block
i
00
(N) Upper-Level Directory
Blocks
(N) Lower-Level Directory
Blocks
DATABANK
DIRECTORY
N = Directory Blocking Factor = 20 in Release Version
Record Size = FIXED = (N) x {Directory Entry Size) + 12
= (20) X (76) + 12 = 1.532 Bytes in Release Version
Record #1
Databank
Capaci ty
Record
(M) Databank Name
Reference
Records
(N)
(M+1)
Individual
Member
Records
DATABANK
FILE
M = Total # Allowed Individual Databanks = 30 in Release Version
Record Size = FIXED = 172 Bytes
Figure B-8. PICTORIAL LAYOUT OF DATABANK FILE AND DIRECTORY
(N) LOWER-
BLOCKS
LEVEL
Record #1 Rec #2
(N) LOWER-LEVEL
BLOCKS
Master
Block
Fi rst
Upper
Block
= UB#1
UB#1 I
1 I
CO
I
IJD
Records #
(UB#1 ) + 1 to
(UB#1 ) + (N),
Inclusive � - �
A
Record # UB#2
Second
Upper
Block
= UB#2
A
UB#1 + N + 1
Records # {UB#2) + 1 to
(UB#2) + (N) ,
I ncl usi ve
(N) LOWER-LEVEL
BLOCKS
A
DATABANK
DIRECTORS
(N)
Directory Blocking Factor
Figure B-9, DATABANK DIRECTORY: BLOCK NUMBERING ALGORITHM
[MACRO]
f
Header
MACRO
Name
Total #
Formal
Parameters
Header
Skeleton Card Image
(80 Chars)
...{as many Skeleton Card Records as required)
Header
Skeleton Card Image
(80 Chars)
[SUBROUTINE]
Header
GOAL
Subrouti ne
Name
FORTRAN
Subrouti ne
Name
[FUNCTION-
DESIGNATOR]
Header
FD
Name
Print
Expansion
FD
Type
FD
Address
[DATABANK
REFERENCE
RECORD]
Header
Databank
Reference
Number
[DATABANK
CAPACITY
RECORD]
Header
Figure B-10. DATABANK FILE: FUNCTIONAL RECORD CONTENTS
B-20
DATABANK CAPACITY RECORD
RAVAIL FQTOT
FQPTR
DBMAX
DBCUR
DBF
r
Record
# 1
Total #
Avai 1 abl e
Records
Total #
Records
Still
Unused
Pointer
to First
Record on
Free
Queue
Maximum
Number
Al lowed
Databanks
Total #
Databanks
Currently
In Use
Directory
Blocking
Factor
Unused
DATABANK REFERENCE RECORD
Record
#
Forward
Chain
Type = 1
(Unused)
Type = 2
(In Use)
Maximum
Number
Allowed
Databanks
Pointer
to Last
Databank
Reference
Record
Databank
#
Databank
Name
Rev-ision
Label ^
(or blank
)
Unused
I
HEADER OF ALL OTHER RECORD TYPES - EXCEPT MACRO SKELETON RECORD
Record
#
Forward
Chain
Type
Total #
Records
on This
Chain
Pointer
to Last
Record ,
This
Chain
Databank
#
Record
Name
Print
Expansion
Data Portion
of Record
MACRO SKELETON RECORD
Record
#
Forward
Chai n
Type = 5
Macro Skeleton Card Image
Figure B-11. GENERAL CONTENTS OF THE HEADER PORTION OF DATABANK RECORDS
DATA BANK FILE
GENERAL CONTENTS OF RECORDS
Type General Contents
Field Record Description Header Data Portion of Record
1 Data Bank Reference Hybrid Unused
(Unused)
2 Data Bank Reference Hybrid Unused
(In Use)
3 Function Designator Standard FD Type
FD Address or Subroutine Name
4 Macro Header Standard Total Number of Formal
Parameters in Macro
5 Macro Skeleton Hybrid Macro Skeleton Card Image
6 Subroutine Name Standard Equivalent FORTRAN
Subroutine Name
NOTES : (1) Explicit record contents by field are to be
found described in APPENDIX E
Figure b-12.
B-22
APPENDIX C
DASD SIZE ESTIMATES FOR GOAL DATA BANK IMPLEMENTATION
C. INTRODUCTION
As indicated in Appendix B, the physical storage space required by the data
bank on external DASD is directly proportional to the blocking factor of the
data bank directory file. Table C-1 of this Appendix illustrates the total
DASD space requirements for both the data bank and the directory files in
terms of directory blocking factor (N). Table C-1 also illustrates the
implications of using a 2-level versus a 3-level directory structure. The
relatively ineffective use of DASD storage in the case of a 2-level system
was the deciding factor that led to the use of a 3-level directory in the
original GOAL data bank implementation.
Table C-1 is intended for use as follows:
1. Determine the total number of named entries to be supported
in the GOAL data bank.
2. Find an equal or higher value entry in the "TOTAL ENTRIES"
column of the 3-level directory section of the table.
3. From the entry selected in Step 2, the blocking factor (N)
can be determined. The total amount of IBM 2314 Disk unit
space {in physical tracks) required to support a data bank
of the chosen size is indicated on the same line as the
blocking factor.
Use of Table C-1 is demonstrated in the following example:
A data bank is required to support 30,000 named entries.
The value of closest proximity to 30,000 in the TOTAL
ENTRIES column of the 3-level directory section is 32,768.
This corresponds to a blocking factor of 32.
A data bank and a directory file to support 30,000 (the
chosen system will actually accommodate up to 32,768) named
entries will require a total of 1,790 disk tracks.
For the initial GOAL data bank implementation, a blocking factor of 20 was
selected in sizing the data bank. This will allow support of a total of
8,000 named entries and require a total of 414 disk tracks.
One IBM 2314 disk pack can provide 4,000 data tracks of DASD storage.
Table C-1 indicates that data banks selected with blocking factors in
excess of 42 will require that more than one physical disk pack be used.
C-1
Table C-1. (1 of 2)
** khL SIZES IN BYTES
** {N) = U UMBER OF DIRECTORY ENTRIES PER DIRECTORY BLOCK
172: DATA BANK PHYSICAL RECORD SIZE
26: TOTAL DATA BANK RECORDS PER TRACK
76: DIRECTORY ENTRY SIZE
N
************ 2- LEVEL *************
* *
TOTAL DATA DIRECTORY TOTAL
ENTRIES TRACKS TRACKS TRACKS
************ 3-LEVEL *************
* *
TOTAL DATA DIRECTORY TOTAL
ENTRIES TRACKS TRACKS TRACKS
10
100
4
2
6
1000
39
14
53
11
121
5
2
7
1331
52
19
71
12
141+
6
3
9
1728
67
27
94
13
169
7
3
10
2197
85
31
115
m
195
8
3
11
2744
106
36
142
15
225
9
4
13
3375
130
4 9
179
15
256
10
4
14
4095
158
55
213
17
289
12
4
16
4913
189
62
251
18
324
13
5
18
5832
225
86
311
c;
19
361
14
5
19
6859
264
96
360
r\3
20
400
16
6
22
8000
308
106
414
21
441
17
6
23
9261
357
115
473
22
484
19
6
25
10648
410
127
537
23
529
21
8
29
12167
468
165
653
24
576
23
9
32
13824
532
201
733
25
625
25
9
34
15625
601
217
818
26
676
26
9
35
17576
676
235
911
27
729
29
10
3 9
19683
758
253
1011
28
784
31
10
41
21952
845
271
1116
29
841
33
10
43
24389
939
291
1230
30
900
35
11
46
27000
1039
311
1350
31
961
37
16
53
29791
1146
497
1543
32
1024
40
17
57
32768
1261
529
1790
33
1089
42
17
59
35937
1383
562
1945
3U
1156
4 5
18
63
39304
1512
596
2108
35
1225
48
18
66
42875
1650
631
2281
36
1206
50
19
69
46656
1795
667
2462
37
1369
53
1 9
72
50653
1949
704
2653
38
1444
55
20
76
54872
2111
742
2853
39
1521
59
20
79
59319
2282
7 SI
3063
Table C-1. (2 of 2)
** ALL SIZES IN BYTES
** (//) = BlIMBBR OF DIRECTORY ENTRIES PER DIRECTORY BLOCK
172
26
76
DATA BANK PHYSICAL RECORD SIZE
TOTAL DATA BANK RECORDS PER TRACK
DIRECTORY ENTRY SIZE
************ 2-LEVEL ************* ************ Z-LEVEL *************
* * * *
TOTAL DATA DIRECTORY TOTAL TOTAL DATA DIRECTORY TOTAL
N ENTRIES TRACKS TRACKS TRACKS ENTRIES TRACKS TRACKS TRACKS
o
)
Co
HO
1600
62
21
83
64000
2452
821
3283
41
1681
55
21
86
68921
2651
862
3513
42
1764
58
22
90
74088
2850
904
3754
43
1849
72
22
9 4
79507
3058
947
4005
44
1936
75
23
98
85184
3277
991
4268
45
2025
78
23
101
91125
3505
1036
4541
46
2116
82
2 4
106
97336
3744
1082
4826
47
2209
85
48
133
103823
3 994
2257
6251
48
2304
89
49
138
110592
4254
2353
6607
49
2401
93
50
143
117649
4525
2451
6976
50
2500
97
51
148
125000
4808
2551
7359
C.l
MODIFICATION OF GOAL DATA BANK MAINTENANCE PROGRAMS
The GOAL data bank maintenance programs were generated using FORTRAN as
the implementation language. Sizing modifications of data bank capacity
by altering the directory blocking factor are effected by changes to
FORTRAN declaration type statements in the maintenance program modules.
Blocking factor modification must then be extended to the Operating System
/360 Job Control Language (JCL) statements that govern the physical size
allocation of the data bank and data bank directory files on disk.
Table C-2 is a list of the FORTRAN declaration statements that will require
modification due to blocking factor change. Variables indicated with an
"N" prefix, e.g., N, Nl , N2, etc., will be replaced with the appropriate
numeric constants from Table C-4. In all data bank maintenance program
modules where the declarations appear, they must be so modified and the
programs recompiled.
Table C-3 is a list of the Operating System/ 360 JCL statements effected by
blocking factor change.
Table C-4 is a tabular list of constants that are to replace the "N" prefix
variables of Tables C-2 and C-3. Substitution constants are provided for
blocking factors ranging from 10 to 50. For the relation of blocking factor
versus total number of supported data bank entries, see Table C-1.
C.2 FORTRAN DECLARATION STATEMENTS AFFECTED BY DIRECTORY BLOCKING
FACTOR CHANGES
The following FORTRAN declaration statements are directly affected by block-
ing factor modifications within the GOAL data bank directory file. Variables
that appear below with an "N" prefix, e.g., N, N2, etc., are to be replaced
with appropriate values from Table C-4. In any data bank maintenance program
module in which these declarations appear, they must be modified, replaced,
and the programs recompiled when data bank size changes occur.
GIVEN:-
N = Directory Blocking Factor
INTEGER
INTEGER
INTEGER*2
EQUIVALENCE
DEFINE FILE
DEFINE FILE
DEFINE FILE
DEFINE FILE
DEFINE FILE
DBLOCK ( Nl )
ENT ( 2, N )
SK { 34. N )
{ ENT(1,1), DBL0CK(4)
{ SK{1,1), DBLOCK( N2
10 ( N3. 172, L, AVDB
11 { N4, N5, L, AVOIR
13 ( N4, N5, L, AVUTL
18 ( N3, 172, L, AVDB
19 ( N4, N5. L, AVOIR
Table C-2.
C-4
C.3 OPERATING SYSTEM/360 JOB CONTROL LANGUAGE STATEMENTS FOR GOAL
DATA BANK CREATION
The following JCL statements are directly effected by changes to the GOAL
data bank directory file blocking factor. Names that appear below with an
"N" prefix, e.g., N, Nl, N2, etc., are to be replaced with appropriate
constants from Table C-4. The JCL statements are presented in the format
usually adopted when creating the data bank and the data bank directory
data sets from scratch. It is to be noted that the IBM 2314 disk pack
supports 4,000 physical data tracks. A blocking factor (N) of value 42
(as presented In Table C-1) requires 3,724 tracks total. For blocking
factors in excess of 42, the JCL statements presented below must reflect
allocation of the data bank and the data bank directory data sets to two
(2) or more disk volumes.
Table C-3.
//FT 2 OFOOl DD DSN^GOAL .DATAB^
// UNIT=SYSDA,BOL=SER=XXXXX^
// SPACE= ( 1 72^ (N3}^j CONTIG) ,
// DCB= (RECFM=F, LRECL=1 72 � BLK�IZE=1 72),
// DISP= (NEW, CATLG^ DELETE)
//FTl IFOOl DD DSN=GOAL . DATAD,
// UNIT=SYSDA, VOL^SER^XXXXXy
// SFACE= (NS, (m)^, CONTIG) ,
// DCB= (RECFM=F, LRECIr=N5, BLKSIZE=N5)^
// DISP=^ (NEW, CATLG, DELETE)
//FT18F001 DD DSN^GOAL.DATABl^ .
// UNIT=-SYSDAj, VOL=SEE=XXXXXy
// SPACED (772, (N3) , , CONTIG) ,
// DCB^(EECFM=F,LBECL^172,BLKSIZE=172),
// DISP=-- (NEW, CATLG, DELETE)
//FT19F001 DD DSN=G0AL.DATAD1,
// UNIT=^SYSDA, VOL=SER=XXXXX_,
// SPACE= (N5, (N4),, CONTIG) ,
// DCB= (RECFM=F, LRECL=N5, BLKSIZE=N5),
// DISF^ (NEW, CATLG, DELETE)
C-b
C.4 BLOCKING FACTOR CONSTANTS TO BE APPLIED IN THE DECLARATIVES OF
TABLE C-2 AND THE JOB CONTROL LANGUAGE STATEMENTS OF TABLE C-3
In the table presented below, (N) is the data bank directory blocking factor.
The table below covers the same range of blocking factor (range of 10 to 50)
as that of Table C-1.
Table C-4.
N in N2 in n^ N'5
10
19 3
24
1000
111
772
11
212
26
1331
133
846
12
231
28
1728
157
9 24
13
250
30
2197
163
1000
14
269
32
2744
211
107 5
15
2B8
3 4
3375
241
1152
15
307
36
4096
27 3
1228
17
32G
38
4913
307
1304
18
345
40
5832
343
1380
19
364
42
6859
381
1456
20
383
44
8000
421
1532
21
402
46
9261
463
1608
22
4 21
48
10648
507
1684
23
440
50
12167
553
1760
24
4 59
52
13824
601
1836
25
478
54
15625
651
1912
26
49 7
56
17576
703
1988
27
516
50
19583
757
2064
28
535
60
21952
813
2140
29
554
62
24389
871
2216
30
573
64
27000
931
2292
31
59 2
66
29791
993
2368
32
611
68
32768
1057
2444
33
630
70
35937
1123
2520
34
649
72
39304
1191
2596
35
668
74
42875
1261
2672
36
687
76
4 6 5 5 5
1333
2748
37
706
78
50553
1407
2824
38
725
80
54872
1483
2900
39
744
82
5 9 319
1561
2976
40
763
84
64000
1641
3052
41
782
86
68921
1723
3128
42
801
88
74088
1807
3204
43
820
9
79507
1893
3280
44
839
9 2
85184
1981
3356
45
858
94
91125
2071
3432
46
877
96
97336
2163
3508
47
09 6
98
103823
2257
3584
48
915
100
110592
2353
3660
49
934
102
117649
2451
3736
50
953
104
125000
2551
3812
C-fa
APPENDIX D
PROGRAM MODULE DESCRIPTIONS
D. INTRODUCTION
Included in this Appendix are short verbal descriptions of all of the
program modules required to generate and support the GOAL data bank
system. In this Appendix:
Figure D-1 Indicates the functional flow during data bank
and data bank directory initialization.
Figure D-2 is the functional diagram of the data bank
maintenance process.
Figure D-3 represents the elements involved in the data bank
initialization process. Also indicated on this diagram is
the operation of the data bank print utility program. The
operation and use of these two programs is completely inde-
pendent of one another - they have been included on the same
diagrams for convenience.
Diagrams D-4, D-5, and D-6 depict the three phases of the data
bank maintenance process.
Following the above diagrams are descriptions (one module per
page) of the programs and subroutines required to support the
data bank. The program modules and their system names are as
follows:
Data Bank Print Utility
Mainline = SUPERD
Subroutines =
SLEW
Data Bank Initialization Program
Mainline = DBI
Subroutines =
None
Data Bank Maintenance Program
Mainline = MAINT
Subroutines =
BEGDB
NAMESR
RCRETN
BUST
SPECFY
VMME
DELDB
DBEND
COMPAR
DELETE
DBSEEK
SPACE
MACRO
FIND
SVSAVE
U-1
Data Bank Pre- Processor
This module is actually the GOAL canpiler; action as
a data bank pre- processor is achieved by providing
the proper syntax tables. Documentation covering the
GOAL compiler module is in separate documentation.
The syntax tables required for data bank maintenance
usage are included in this document as Appendix I.
u-z
DATABANK
CAPACITY RECORD
DATABANK
INITILIZATION
CONTROL CARDS
Type(l)
Card
>
"^
DATABANK
INITILIZE
PROGRAM
\
1
u
f
* Writes Dummy
Blocks
* Writes Zeroed
Block Headers
X
Directory Blocking
Factor from Constant
Compiled into the
Ini ti 1 ization Program
X
>
\
V
x^
* Writes Capacity
Record "^
* Writes Dummy Databank
Name Reference
^
Records
* Forms Remaining Records
on to Free Queue
DATA
i BANK
i
<-
Record
Number
= 1
Total Number
of Records
Aval 1 able
in Databank
Fi 1 e
Total Number
Records Now
Available on
Free Queue
Pol nter
(Record #) to
First Record
on Free Queue
Maximum
Number of
Al lowed
Databanks
Total Number
of Databanks
Currently in
Use
Directory
Bl ocking
Factor
DATABANK INITIALIZATION
Figure U-1
U-3
CONTROL
CARDS
��\
>
DATABANK
MAINT-
ENANCE
PROGRAM
New Member Records
are Added to the
Databank File
Old Members to be
Deleted are Removed
from the Databank
4i.
DATA
BANK
NEW
DIREC-
TORY
ENTRIES]
Entries to be
Deleted are Marked
in the Directory
^
SORTED NEW
DIRECTORY
ENTRIES
DIREC-
TORY
.-^
DIRECTORY
CONSTRUCT
PROGRAM
If Merge Successful
Final Operation is
Replacement of the
Old Directory with
the New Di rectory
-li^
^
MERGE OLD DIRECTORY WITH NEW BY:
* Removing Entries Marked for
Deletion
* Inserting New Entries
4.
I
<^
TEMPORARY
NEW
DIRECTORY
Figure D-2. DATABANK MAINTENANCE PROCESS
L...,
e
Data Bank
Di rectory
Work Data Set
o
Ini ti al izatinn
Control
Parameters
//FT05F001
.^
^
//FT13F001
Data Bank
Initial i zatlon
Program
(OBI)
//FT06F001
//FTllFOOl
//FT10F001
Data Bank
D i r e c 1 ry
�
Data Bank
File
//FTllFOOl
^
//FTlOFOOl
A
Data Bank Print
Utility Program
(SUPERD)
v!2
>
Maintenance
Listing
L.
) Letters in circles are
Data Set Reference
Numbers; see
APPENDIX E for
record formats
//FT06F001
Printer Dump
All
Data Banks
DATA BANK
IN_ITIALI2ATI0N AND
PRINT UTILITY
PROGRAMS
NOTE - PROGRAMS (DBI) AND (SUPERD) MAY
BE RUN INDEPENDENTLY OF ONE
ANOTHER
U-b
Figure U-3.
Ar
Control
Deck
//FT05F001
�^
Data Bank
Pre-Processor
Program
f^A2^
//FT06F001
>
Pre-
processor
L i s t i n ci�
//FT20F001
Fixed-Format
Control Card
Images
G)
//FT09F001
^
Alpha
Character
Reference
Data Bank
Mai ntenance
Program
(MAINT)
New
Unsorted
Directory
Entries
//FT12F001
7^r~7K
//FT06F001
//FTIlFOOl
//FT10FD01
�^
�
Q
^
Maintenance!
Listing I
Data Bank
Di rectory
Data Bank
File
o
To PHASE-2
Mai ntenance
Process
Letters in circles are Data Set Reference
Numbers; see APPENDIX E for record
formats
U-6
PHASE-1 DATA BANK
MAINTENANCE
PROCESS
Figure D-4
From
PHASE-1
Maintenance
Process
^ F )
New
Unsorted
Di rectory
Entries
//SORTWKOl
//S0RTWK02
//S0RTWK03
�^
�
//SORTIN
�e
Three (3) Intermediate
SORT Work Data Sets
a
Control
Card
//SYSIN
^
Standard
OS/360
Sort/Merge
Utility
Program
(IERRC0OO)
//SORTLIB
Standard
OS/360
Sort
Library
il
//SYSOUT
-^
Statistics
Listing
//SORTOUT
^
Sorted
Di rectory
Entries
O
Letters in circles are
Data Set Reference
Numbers; see
APPENDIX E for
record formats
To
PHASE-3
-^ Maintenance
Process
PHASE-2 DATA BANK
MAINTENANCE
PROCESS
Figure U-5,
D-7
From
PHASE-2
Maintenance
Process
New
Sorted
Di rectory
Entries
//FT12F001
Data Bank Directory
Construct Maintenance
Program
(DCON)
7F
//FT13F001
7K
//FT06F001
V
a
1
Matntenanc
^ Listing
//FTllFOOl
O
Data Bank
Directory
Directory
Work
Data Set
o
Letters in circles are Data Set
Reference Numbers; see
APPENDIX E for record
formats
PHASE-3 DATA BANK
MAINTENANCE
PROCESS
Figure 0-6.
D-B
GOAL DATA BANK ROUTINE
NAME - SUPERD
TYPE - FORTRAN Mainline
FUNCTION - Provides printer dump of the current data bank
contents
CALLED BY - Not Applicable
SUBROUTINES
CALLED - SLEW
DESCRIPTION - This module prints the contents of all active
data banks. Using the directory, all members of
each data bank are listed in alphabetic order by
member (record) name.
D-9
GOAL DATA BANK ROUTINE
NAME - SLEW
TYPE - FORTRAN Subroutine
FUNCTION - Provides paging and title strips for SUPER data bank
print utility program
CALLED BY - SUPERD
SUBROUTINES
CALLED - None
DESCRIPTION - Provides paging and title strip printing for the
SUPERD print utility program.
u-10
GOAL DATA BANK ROUTINE
NAME - DBI
TYPE - FORTRAN Mainline
FUNCTION - Data bank file and data bank directory ini ti 1 i zati on
(record pre-formatting )
CALLED BY - Not Applicable
SUBROUTINES
CALLED - None
DESCRIPTION - Under control-card control, this module pre-formats
the records of the data bank file and the data bank
directory by:
composing and writing the data bank capacity
record ;
initializing and writing all data bank reference
records; these records also require chaining
together;
filling the remainder of the data bank with
a chain of dummy records;
writing dummy blocks into the data bank
directory and directory utility data set.
u-11
GOAL DATA BANK ROUTINE
NAME - MAINT
TYPE - FORTRAN Mainline Program
FUNCTION - Mainline root program for all phase 1 maintenance
actions; reads control card input and invokes the
proper subroutine for further processing
CALLED BY - Not Applicable
SUBROUTINES
CALLED - DELDB, DBEND, SPECFY, SVSAVE, MACRO, DELETE,
BEGDB, NAMESR, BUST
DESCRIPTION - This module serves to process input cards, determine
their nature, and invoke the proper subroutine for
completion of the processing. Each subroutine, after
accomplishing its required action, returns control to
MAINT for further processing of the input stream.
U-12
GOAL DATA BANK ROUTINE
NAME - BEGDB
TYPE - FORTRAN Subfoutine
FUNCTION - Process a BEGIN DATABANK control card; open a
Data Bank for maintenance
CALLED BY - MAINT
SUBROUTINES
CALLED - VNAME, DBSEEK, BUST
DESCRIPTION - This subroutine is utilized to process a BEGIN
DATABANK control card. The named Data Bank is sought
within the current Data Bank data set. If it already
exists, the Data Bank open flag (DBN) is set with the
Data Bank reference number. If the Data Bank is new,
the DBN flag is set in the same manner; the new Data
Bank Reference Record is composed and written into the
Data Bank before return to the caller.
Lj-13
GOAL DATA BANK ROUTINE
NAME - BUST
TYPE - FORTRAN Subroutine
FUNCTION - Output to the printer a standard error number
diagnostic message.
CALLED BY - MAINT, BEGDB, DELDB, DELETE. MACRO, NAMESR, SPECFY,
DBEND, DBSEEK, FIND, VNAME, SPACE
SUBROUTINES
CALLED - RCRETN
DESCRIPTION - An error message number provided as a parameter by the
caller module is printed in a standard error message
format. A non-zero Return Code is established in the
OS/360 via a call to RCRETN from this subroutine.
U-14
GOAL DATA BANK ROUTINE
NAME - DELDB
TYPE - FORTRAN Subroutine
FUNCTION - Process a DELETE DATABANK control card
CALLED BY - MAINT
SUBROUTINES
CALLED - VNAME, DBSEEK, BUST
DESCRIPTION - The reference number of the required Data Bank is
located via the DBSEEK subroutine. Using this number
and the Data Bank Directory, all members of the named
Data Bank are returned to the record Free Queue in the
Data Bank data set. The existing Directory references
to the deleted members are marked for deletion.
U-15
GOAL DATA BANK ROUTINE
NAME - DELETE
TYPE - FORTRAN Subroutine
FUNCTION - Deletes a named member from the current open
Data Bank; processes a DELETE control card
CALLED BY - MAINT
SUBROUTINES
CALLED - VNAME, FIND, BUST
DESCRIPTION - The Data Bank Directory is used to locate the
control card named member in the Data Bank currently
opened. Once the required record is located, it is
returned to the Data Bank Free Queue. The applicable
Directory entry is marked for deletion.
U-lb
GOAL DATA BANK ROUTINE
NAME - MACRO
TYPE - FORTRAN Subroutine
FUNCTION - Processes MACRO control cards; enters the new
MACRO into the Data Bank currently open
CALLED BY - MAINT
SUBROUTINES
CALLED - VNAME, SPACE, BUST
DESCRIPTION - Processing of all MACRO input cards is accomplished
in this subroutine. Space is retrieved within the
currently open Data Bank, and the new MACRO records
composed and inserted.
0-17
GOAL DATA BANK ROUTINE
NAME - NAMESR
TYPE - FORTRAN Subroutine
FUNCTION - Provides processing for Subroutine Name Records
CALLED BY - MAINT
SUBROUTINES
CALLED - VNAME, SPACE. BUST
DESCRIPTION - Subroutine name control cards are parsed and processed
via this subroutine. Subroutine name record construction
is accomplished and the new record written into the
currently open Data Bank.
U-18
GOAL DATA BANIC ROUTINE
NAME - SPECFY
TYPE - FORTRAN Subroutine
FUNCTION - Used to process SPECIFY control cards j creates new
Function Designator Records
CALLED BY - MAINT
SUBROUTINES
CALLED - SPACE, BUST
DESCRIPTION - New Function Designator records are created by this
subroutine. All parsing of the SPECIFY card contents
is accomplished within this subroutine.
U-19
GOAL DATA BANK ROUTINE
NAME - DBEND
TYPE - FORTRAN Subroutine
FUNCTION - Closes an open Data Bank; this subroutine processes
an END DATABANK control card
CALLED BY - MAINT
SUBROUTINES
CALLED - BUST
DESCRIPTION - This subroutine is invoked to process an END DATABANK
control card. The data bank open flag (DON) is set
to the zero (off) state. Only DELETE DATABANK control
cards will be recognized by the MAINT mainline until
another Data Bank is opened (via a BEGIN DATABANK
control card).
U-20
GOAL DATA BANK ROUTINE
NAME - DBSEEK
TYPE - FORTRAN Subroutine
FUNCTION - Determines if a named Data Bank already exists
CALLED BY - BEGDB, DELDB
SUBROUTINES
CALLED - BUST
DESCRIPTION - Using a Data Bank name (name plus revision label, if
appropriate), this subroutine returns one of three
pieces of information to the caller:
(1) If the Data Bank already exists, the caller is
informed of the Data Bank reference number;
(2) If the Data Bank does not yet exist, the caller
is informed of a Data Bank reference record
number that is available for establishing a new
Data Bank;
(3) If the Data Bank does not exist and all usable
Data Bank reference records have been utilized,
an appropriate error indication is given.
U-21
GOAL DATA BANK. ROUTINE
NAME - FIND
TYPE - FORTRAN Subroutine
FUNCTION - Locate a specific member of a given Data Bank
CALLED BY - DELETE
SUBROUTINES
CALLED - COMPAR, BUST
DESCRIPTION - Using the Data Bank Directory, this subroutine locates
a required member. The name of the member is supplied
as a calling parameter; the required Data Bank reference
number is provided as the first four bytes of the name.
Upon finding the required member, the sought record is
brought into memory and the caller informed of its
relative record number within the Data Bank data set.
U-22
GOAL DATA BANK. ROUTINE
NAME - RCRETN
TYPE - Assembler Language Subroutine
FUNCTION - The function of this subroutine is to establish the
OS/360 Return Code upon termination of the MAINT phase
1 maintenance module. Execution (go/nogo) of the
programs in subsequent job steps is controlled via this
Return Code.
CALLED BY - BUST
SUBROUTINES
CALLED - None
DESCRIPTION - Non-error execution of the MAINT module results in a
zero Return Code indication upon MAINT termination.
Subsequent phases of the maintenance process can use
this code as an indication that normal execution can
continue. Should an error occur during MAINT execution
that would render execution of the subsequent maintenance
steps inappropriate, a non-zero Return Code is
established by call to the RCRETN subroutine from the
error diagnostic subroutine BUST.
u-23
GOAL DATA BANK ROUTINE
NAME - VNAME
TYPE - FORTRAN Subroutine
FUNCTION - Validates and isolates a name bounded by parenthesis
CALLED BY - BEGDB, DELDB, DELETE, MACRO, NAMESR
SUBROUTINES
CALLED - BUST
DESCRIPTION - This subroutine scans an indicated portion of an input
card and attempts to isolate a standard name bounded by
parenthesis. The name can be 1 - 32 characters in
length. The first character must be a letter; subsequent
characters can be letters and/or digits. An appropriate
error message is issued if an error is detected in
either the name contents or in the delimeters.
U-2A
GOAL DATA BANK. ROUTINE
NAME - COMPAR
TYPE - Assembler Language Subroutine
FUNCTION - Perform a logical {non-arithmetic) compare of
two EBCDIC names
CALLED BY - FIND
SUBROUTINES
CALLED - None
DESCRIPTION - This subroutine is used as a FORTRAN function
subprogram. It is designed to be used in an
arithmetic FORTRAN statement; the value returned to
the caller is either (-1), (0), or (+1). Two named
parameters are compared logically with the following
impl i cations:
Parameter
Rel ation Return
A < B -1
A = B
A > B +1
D-25
GOAL DATA BANK ROUTINE
NAME - SPACE
TYPE - FORTRAN Subroutine
FUNCTION - Finds a place to write a new record Into the
Data Bank data set
CALLED BY - MACRO, NAMESR, SPECFY
SUBROUTINES
CALLED - BUST
DESCRIPTION - This subroutine locates the next available singular
record space in the Data Bank. The Data Bank Free Queue
total and pointer fields are updated and the Data Bank
Capacity Record re-written with the adjusted totals.
The record selected for availability has been read
into memory and is ready for use when return to the
caller is effected.
0-26
QOAL DATA. BANIC ROUTINE
NAME - SVSAVE (Alternate entry point to RCRETN subroutine)
TYPE - Assembler Language
FUNCTION - The memory address of the OS/360 Supervisor is
established via this entry to the RCRETN subroutine.
This address is required for subsequent correct operation
of the RCRETN subroutine.
CALLED BY - MAINT
SUBROUTINES
CALLED - None
DESCRIPTION - The address of the OS/360 Supervisor is required for
operation of the RCRETN subroutine; this address is
used as a RCRETN return point. The address is establishel
as a part of the initil ization sequence of the MAINT
mainline program.
u-27
APPENDIX E
DATA RECORD FORMATS
E.l INTRODUCTION
This Appendix contains record descriptions for all of the data sets re-
quired for data bank and data bank directory initialization, maintenance,
and usage. Each of the data sets is referred to by a "file reference
letter". The reference letters are those used in the functional flow
illustrations of Appendix E. They are itemized in the table following:
Data Set Description
Pre-processor program control card input
Pre-processor program listing
Fixed- format control card images
Maintenance program alphanumeric character
set reference
File
Reference
Letter
See
Figure
Al
D-4
A2
D-4
A
D-4
B
D-4
C
D-4
D
D-3
D-4
D-6
Phase-1 maintenance program listing
Data bank directory
E D-3 Data bank file
D-4
D-6
F D-4 New unsorted directory entries
D-5
G D-5 Standard OS/360 Sort/Merge utility program
library (SySl.SORTLIB)
H D-5 Sort/merge utility program listing
I D-5 Sort/merge utility program intermediate work
data sets
J D-5 Sort/merge utility program control card
E-1
File
Reference
Letter
See
Figure
K
D-5
D-6
L
D-6
M
D-6
N
D-3
D-3
P
D-3
Data Set Description
Sorted new directory entries
Directory work data set
Directory construction program listing
Initialization program control card input
Initialization program listing
Printer dump of data bank
Figures E-1 through E-4 inclusive, form a sequential sample of the printer
listings that might occur as the result of a data bank maintenance operation.
E-2
;OAL COMPILER SOURCE RECORD LISTING
OJ
RECORD
1
2
3
4
5
6
7
8
9
10
II
12
13
14
15
16
17
18
19
20
21
22
23
SOURCE RECORD
BEGIN DATABANK (SAHPLED8) REVISION A
SPECIFY <PRIMARY SSCU ON SWITCH> AS L
SPECIFY <VENT MOTOR F1ELD> AS LOAD TY
SPECIFY <CDC SET CKT> AS LOAD TYPE CL
SPECIFY <MANIFOLD PRESSURE LOW LAMP>
SPECIFY <IU COOLANT PRESS> AS SENSOR
SPECIFY <EST> AS SENSOR TYPE CLOCK AD
SPECIFY <LINE PRINTeR> ALSO AS <360/P
SPECIFY <CRr2> AS SYSTEM TYPE CRT ADD
SPECIFY <LOG> AS SYSTEM TYPE TAPE ;
SPECIFY <P�INTER BUSY> AS SYSTEM TYPE
SPECIFY <PROCEDURE IN PROGRESS FLAG>
SPECIFY <GOAL SR NAME> AS SUBROUTINE
NAME (POWER ON � SUBROUTINE IFDRT4) ;
NAME (ABCDEFG) PROGRAM IFQRT25) ;
BEGIN MACRO ABC t A > , ( B I , t C ) t<A> ;
(ABC) = (A)
<DEF) = (8�
IGHIJ = (C)
tJKL) = <A>
END MACRO ;
END DATABANK ;
FINIS
OAO TYPE DISCRETE ADDRESS 252 ;
PE ANALOG ADDRESS 0063 ;
OCK ADDRESS 0040 ;
AS SENSOR TYPE DISCRETE ADDRESS 4123
TYPE ANALOG ADDRESS 0049 ;
DRESS 6 ;
RINTER> AS SYSTEM TYPE PRINTER ;
RESS I ;
INTERRUPT ;
AS SYSTEM TYPE
(F0RT23) ;
FLAG I
Figure E-1 .
SAMPLE DATA BANK
PRE-PRQCESSOR
LISTING
Refer to File Reference Letter A2
GOAL COMPILER DIAGNOSTIC SUMMARY
TOTAL NUMBER OF SOURCE RECORDS:
TOTAL NUMBER OF STATEMENTS: 19
TOTAL NUMBER OF WARNINGS:
TOTAL NUMBER OF ERRORS :
HIGHEST CONDITION CODE WAS
23
I
DATABANK (SAMPLEDB)
SPECIFY <PRIMARyGSCUONSWITCH>
SPECIFY <VENTMOTORFieLO>
SPECIFY <CDCSETCKT>
SPECIFY <HAMIFOLDPRESSURELOWLAMP>
SPECIFY <IJCOOLANTPRESS>
SPECIFY <EST>
SPECIFY <LINEPRINTER>
<360/PRINTER>
SPECIFY <CRT2>
SPECIFY <LOG>
SPECIFY <PRIMTERBUSY>
SPECIFY <PROCEDUREINPROGRESSFLAG>
SPECIFY <GDALSRNAME>
NAME tPOWERON)
NAME (ABCOEFG)
MACRO (ABC)
I A )
(B)
(C)
<A>
(ABC) = (A)
(DEF) = (B)
(GHIJ = (C>
<JKL> = <A>
END MACRO
END DATABANK
(A)
LOAD
DISCRETE
0252
LOAD
ANALOG
0063
LOAD
CLOCK
00^0
SENSOR
DISCRETE
^123
SENSOR
ANALOG
00'^9
SENSOR
CLOCK
0006
SYSTEM
PRINTER
SYSTEM
CRT
0001
SYSTEM
TAPE
SYSTEM
INTERRUPT
0000
SYSTEM
FLAG
0001
SUBROUTINE
tF0RT23)
SUBROUTINE
(F0RT4)
SUBROUTINE
(F0RT25)
Figure E-2
SAMPL E PHASE
FTIETT
1 MAINTENANCE PROGRAM
FORMAT CONTROL-CARD IMAGES
Refer to File Reference Letter A
?*? TOTAL DIRECTORY ENTRIES GENERATED = 15 **?
**? TOTAL DIRECTORY ENTRIES DELETED = ***
I
IEft036I - B = 90
IER037I - G = 700
IER038I - NMAX = 17460
IER045I - END SORT PH
IER049I - SKIP MERGE PH
IER054I - RCD IH 17, OUT
IER052I - EOJ
17
Figure E-3.
SAMPLE SORT/MERGE PRINTER OUTPUT
Refer to File Reference Letter H
[iEtt_i3ia�aiQa3t_iIAIiSIiti
20: DBF
14: rtMAX
239: DRTOT
224: QLDTOT
0: DELTQT
15: SORTOT
Figure E-4.
SAMPLE PHASE-3 MAINTENANCE PROGRAM LISTING
Refer to File Reference Letter M
0: ZERO BALANCE
I
DATABANK MAHE:
revision:
REFERENCE �:
SAMPLEDS
A
U
MENdER
(IUtiaE&
RECORD
eiutiBEa
RECORD
I3tE�
�QEitglEIiaM�
&flQ&�S&.
t]�(iaEa_tl&ll�.
225
509
MACRO
< 4 PARAMETERS)
ABC
225
510
MACRO
SKELETON
(ABCI
� tl i
225
511
MACRO
SKELETON
lOEFI
* G2 :
225
512
MACRO
SKELETON
(GHH
m t3 i
225
513
MACMO
SKELETON
(JKLI
> e4 :
22b
508
SUBROUTINE
F0RT25
ABCDEFG
227
*97
<FD>
LOAD CLOCK
40
CDCSETCKT
228
502
<F0>
SYSTEM CRT
1
CRT2
229
500
<FD>
SENSOR CLOCK
6
ESI
230
506
<FD>
SUBROUTINE
FORT23
GOALSRNAME
231
499
<FD>
SENSOR ANALOG
49
lUCOOLANTPRESS
232
501
<FD>
SYSTEM PRINTER
LINEPRINTER
233
503
<FD>
SYSTEM TAPE
LOG
234
496
<FD>
SENSOR DISCRETE
4123
MANIFOLOPRESSURELOWLAMP
235
507
SUBROUTINE
FaRT4
POWERON
236
495
<F0>
LOAD DISCRETE
252
PRINARVGSCUONSWITCH
237
504
<F0>
SYSTEM INTERRUPT
PRINTEHBUSy
23S
505
<FD>
SYSTEM FLAG
1
PROCEDURE I NPROGRESSFLAG
239
496
<FD>
LOAD ANALOG
63
VENTHOrORFIELO
.E&lHI-EXEiliSlQB
CDCSETCKT
CRT2
EST
GOALSRNAME
lUCOOLANTPRESS
360/PRINTER
LOG
MANIFOLOPRESSURELOWLAMP
PRIMARYGSCUONSMITCH
PRINTERBUSY
PROCEDURE I NPROGRESSFLAG
VENTHOTQRFIELD
^
Figure E-5
SAMPLE DATA BANK PRINTER DUMP LISTING
Refer to File Reference Letter P
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Control Card Input
Al, A2, A
Not Applicable
Not Applicable
These three data sets form the control input for the data bank maintenance
process. They are discussed separately below;
(Al) Pre-Processor Program Control Card Input
These control cards direct the maintenance process. They are totally
free-form in conformity with the syntax diagrams presented in this
document as Appendix I. A sample listing of control card variations
is to be found in Figure E-1.
(A2) Pre-Processor Program Listing
The pre-processor program is actually the GOAL compiler module directed
by a suitable syntax table. The listing that is output is an 80-80 list-
ing of the control cards input, plus any errors that may have been
detected in the control -card input. The pre-processor error messages
are to be found in this document in Appendix H. Figure E-1 provides an
example of the listing.
(A) Phase-1 Maintenance Program Control -Card Input
This data set forms the input control for the Phase-1 data bank main-
tenance program (MAINT). The card images may be punched and entered
directly to MAINT, or, the images may be artificially generated as a
normal output from the data bank pre-processor program.
The control image consists of a total of six (6) distinct fields in
fixed positions. Not all fields are required for any control card type.
Figure E-6 describes the bounds of the six fields.
A sample of the variations of control images possible is illustrated in
Figure E-7. Usage of the various types is discussed in the following
paragraphs:
A data bank is opened for maintenance by the appearance of a
DATABANK control card; the same data bank is closed by an END
DATABANK card.
All control variations, with the single exception of a delete
data bank (DELETEDB) option, are legal only between a DATABANK
and an END DATABANK pair. The DELETEDB option is legal only
when a data bank has been closed.
E-7
All function-designator types except for PRINTER, CRT, TAPE,
and SUBROUTINE require an address field (see "Fb" field, Figure
E-6). This address field is a mandatory four-digit field - lead-
ing zero(s) to be supplied as applicable.
For the examples of function designators indicated in Figure E-7,
the print expansion field and the function designator name fields
are identical. If the print expansion field is to be unique, two
control images will be required. See page 2 of Figure E-7.
The total number of formal parameters allowed on a macro will be
ten {10). Each parameter may be a GOAL name or function designator.
E-8
1
2
H
3
t
5
&
1
3
9
(0
tl
12
'
m
15
IG
n
IS
19
20
21
22
23
2.
2J
26
21
28
29
30
31
32
33
at
35
36
37
38
39
..
;^
m
M3
MM
M5
MG
M7
MB
\^
50
51
52
53
5^5i
5.
57
58
59
eo
El
62
E3
5M 65
66
67
6B
69
70
71
72
73
7M
75
76
77
7�
79
to
-
r
^
F
i
F
z
F3
"?
F?
L
1
-
�^
^
*
.
-
-
^
��(
�i
-
F<i
.....
...
�
' � 1
j
n
^4 [ [ �
^ t 1
n ' �
�..
m
!
y3
Figure E-6. FIXED FIELD LAYOUT - DATA SET REFERENCE LETTER "A'
DATABANK (ILLUSTRATIONS)
SPECIFY <PRIMARY GSCU ON SWITCH>
SPECIFY <VENT MOTOR FIELD>
SPECIFY <CDC SET CKT>
SPECIFY <MANIFOLD PRESSURE LOW LAMP>
SPECIFY <IU COOLANT PRESS>
SPECIFY <EST>
SPECIFY <LINEPRINTER>
SPECIFY <CRT2>
^ SPECIFY <LOG>
SPECIFY <EVENT12>
SPECIFY <REMEMBER
SPECIFY <GOAL SR NAME>
MACRO (SAMPLEMACRONAME)
(PARMl )
READ <GMT> AND SAVE AS (PARMl) ;
END MACRO
END DATABANK
Figure E-7 SAMPLE FIXED-FORMAT CONTROL-CARD IMAGES
(Page 1 of 2) (DATA SET REFERENCE NUMBER "A"!
LOAD
DISCRETE
0252
LOAD
ANALOG
0063
LOAD
CLOCK
0040
SENSOR
DISCRETE
4123
SENSOR
ANALOG
0049
SENSOR
CLOCK
0006
SYSTEM
PRINTER
SYSTEM
CRT
0013
SYSTEM
TAPE
SYSTEM
INTERRUPT
0000
SYSTEM
FLAG
0614
SUBROUTINE
(FORT23)
DELETE (OLDNAME)
DELETE <OLD FUNCTION DESIGNATOR> (More control-card samples)
DELETEOB (OLDDATABANK) (REV IS I ONXXX )
Note: The print expansion field and the function designator name are identical on
all of the samples presented on page 1 of this figure.
The following example is presented to illustrate the format required to enter
a function designator with unique name and print-expansion formats - 2 cards
SPECIFY <NORMAL FD NAME> (Note - remainder of first card left blank)
<FD PRINT EXPANSION NAME - 2ND CARD> SENSOR ANALOG 0049
Figure E-7. (Page 2 of 2) SAMPLE FIXED-FORMAT CONTROL-CARD IMAGES
Refer to File Reference Letter A
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Alphabetic Character Reference
B
CHRTAB
Not Applicable
This dataset forms the character reference to be used in scanning
control-card records. The dataset consists of a single card image
to be punched as follows:
Card
Card
Card
Column
Character
Col umn
Character
Col umn
Character
1
1
21
K
41
<
2
2
22
L
42
(
3
3
23
M
43
)
4
4
24
N
44
' (ap
5
5
25
45
+
6
6
26
P
46
-
7
7
27
Q
47
*
8
8
28
R
48
1
9
9
29
S
49
1
10
(zero)
30
T
50
#
n
A
31
U
51
$
12
B
32
V
52
-^
13
C
33
w
53
&
14
D
34
X
54
15
E
35
Y
55
s
16
F
36
z
56
*
17
G
37
=
57
blank
18
H
38
:
58-80
blank
19
I
39
>
20
J.
40
>
E-12
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Databank Maintenance Module Listing
C
Not Applicable
Not Applicable
The output from this module is basically a single-spaced printer listing
of the input card deck (File Reference Letter = A).
If the step terminates due to error, the following message will appear on
the same line as the last input card processed:
*****
ERROR # NNN OCCURRED *****
For a description of the error message numbers ("NNN" 1n the above message),
see the standard error message listing section of this document.
If the step proceeds normally to conclusion (no errors), the following totals
are printed after the last control card:
*** TOTAL DIRECTORY ENTRIES GENERATED = NNNNNN ***
*** TOTAL DIRECTORY ENTRIES DELETED = NNNNNN ***
For an example of this listing, see Figure E-2.
E-13
Symbol ic-
Bytes-
i^� Directory Header Block
HRN
HTA
I
-* �
HTU
4
Di rectory
Block #
Total #
Entries
Possi ble
(N)
Total #
Entries
Used
^'
1^
A Directory Block
(N Directory
Entries)
_^
A
r
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Directory Block
D, L
DBLOCK (383)
DIR (19)
Not Applicable
/
^
Symbol i c � ^
Bytes � >
A Directory Entry
->
ENT(1 .N)
ENT(2,N) I SK(1,.N)_
4 i 2
SK(2.N) JSK(3-34,N)
2 i 64 (32-char)
Record
Poi nter
Delete
Field
0=acti ve
1=DELETE
Databank #
Search Key
<
m
I
Recoj"d Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Fomat Number
FW
Subscript
1
2
3
4
5
6
7
8-43
HW
Subscript
1
3
5
7
9
11
13
15-86
Field
Length
(Bytes)
4
4
4
4
4
4
4
144
Databank Capacity Record
E
CAPCTY (43)
Rl
Type:
A=Alpha
N=Numer1c
N
N
N
N
N
N
N
Symbolic
Name Field Description
Rl Record number; always = 1 for Capacity Record
RAVAIL Total # record allocated for databank
FQTOT Total # records on FREE-QUEUE
FQPTR Pointer to first record that is on the FREE-Q
DBMAX Total # databanks allowed
DBCUR Total # databanks currently in use
DBF Directory blocking factor
NOT USED IN THIS RECORD FORMAT
m
I
Oi
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
FW
Subscript
1
2
4
5
6
7
23
HW
Subscrip t
1
3
7
9
11
13
45
Field
Length
(Bytes)
4
4
4
4
4
64
64
Databank Name Reference Record
E
DBREC (43)
R2
Type:
A=Alpha
N=Nunieric
N
N
Symbolic
Name
DBRN
PNEXT
RTYPE
N
RECTOT
N
PLAST
N
SDB
A
SER
A
EPR
Field Description
Record Number
Pointer to next Databank Reference Record; if this
is the last record in the chain, PNEXT =
= 1 (one) means record currently not in use
= 2 (two) means record in use
Set to equal the total number of allowed databanks
Pointer to last Databank Reference Record
Databank reference number; set to equal the current
record number (DbRN)
32-character databank search key (member name); in
FORTRAN 32A1 (halfword) format
32-character databank name REVISION title; if none
specified, field is blank; in 32A1 FORTRAN halfword
format
39-43
77-86
40
NOT USED WITH THIS RECORD FORMAT
m
I
Recofd Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Foimat Number
FW
Subscr
ipt
HW
Subscn
pt
Field
Length
(Bytes)
1
1
4
2
3
4
3
5
4
4
7
4
5
9
4
6
n
4
7
13
64
23
45
64
39
77
2
Function Designator Record
E
DBREC (43)
R3
Type:
A^Alpha
H=Numer1c
N
N
N
N
N
N
A
A
N
Symbolic
Name_
DBRN
PNEXT
RTYPE
RECTOT
PLAST
SDB
SER
ERR
GPDATA (1)
Field Description
Record number
Always zero with this record type
Record type = 3 indicates a Function Designator
Always = 1 for this record type
Pointer to last record in this sequence; for this
record type, always set to point to this record,
i.e., PLAST = DBRN
Databank reference number of the databank of which
this Function Designator is a member
32-character Function Designator search key; in
FORTRAN (32A1) halfword format
32-character Function Designator print expansion
name in FORTRAN (32A1 ) halfword format
Function Designator type:
1 = Load Discrete
2 = Load Analog
3 = Load Clock
4 = Sensor Discrete
5 = Sensor Analog
6 = Sensor Clock
7 = System Printer
8 = System CRT
9 = System Tape
10 = Issue Subroutine
n = System Interrupt
12 = System Flag
CO
Recofd Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Function Designator Record (Continued)
E
DBREC (43)
R3
Field Type:
FW HW Length A=Alpha Symbolic
Subscript Subscript (Bytes) N=Numeric Name Field Description
* * For Function Designator Types 1 through 9, inclusive, and 11, 12 * *
N/A 78 2 N GPDATA (2) Function Designator hardware address
40-43 79-86 16 NOT USED WITH THIS RECORD VARIATION
* * For Function Designator Types 10 * *
M/A 78 2 N GPDATA (2) Subroutine FORTRAN name lengtn (1 to b, max)
40-42 79-84 2-12 A GPDATA (3) Subroutine FORTRAN name; one to six halfwords
through (8)
43 85 4 NOT USED WITH THIS RECORD VARIATION
Recoird
Name
� MACRO
Header Record
File Reference
Letter
; E
FORTRA^
t Symbol
ic Base
Declaration
: DbREC
(43)
Record
Format
Number
; R4
FW
Subscri
HW
pt Subscript
1
Field
Length .
(Bytes)
4
Type:
A=Alpha
N=Nuiiieri c
N
Symbolic
Name
1
UbRN
2
3
4
N
PNEXT
3
5
4
N
RTYPE
m 4
7
4
N
RECTOT
lO
b
9
4
N
PLAST
6
11
4
N
SDB
7
13
64
A
SER
23
45
64
A
�PR
39
77
Field Description
Record Number
Always non-zero with this record type; points to
first I'^CRO Skeleton record (type = b) of the MACRO
Record type - 4 means MACRO Header Record
Total # records for this MACRO; sum of all MACRO
Skeleton (type = 5) + 1 for MACRO Header record
Points to last MACRO Skeleton (type =5) record
belonging to this MACRO
Databank reference number of the databank to which
this MACRO belongs
32-character MACRO name in FORTRAN (32A1) fomat
32-character blank (field unused in this record type)
field in (32A1) FORTRAN format (nalfwords)
GPDATA(l) Total # of format parameters aeclarea witn this
MACRO, NOTE - it is possible for a MACRO to have
no (zero) formal parameters
N/A
78-85
18
NOT USED WITH THIS RECORD TYPE
Recopd Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
o
FW
Subscript
1
2
3
4-43
HW
Subscript
1
3
5
7
Field
Length
(Bytes)
4
4
4
160
MACRO Skeleton Record
E
DBREC (43)
R5
Type:
A=Alpha
N=Numeric
N
N
N
A
Symbol i c
Name
DBRN
PNEXT
RTYPE
IMAGE
Field Uescription
Record Number
If not last skeleton record for this i^CRO, points
to next skeleton image; if last, PNEXT =
Record type = 5
Scanned and processed MACRO skeleton caro-iniage
in FORTRAN (80A1) format
I
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Fomat Number
Subroutine Name Record
E
DBREC (43)
Rb
Field Type:
FW HW Length A=Alpha Symbolic
i"^s<^'^^P^ ^"bsc'^TPt (Bytes) N=Nunieric Name Field Description
1 1 4 N UBRN Record Number
2 3 4 N PNEXT Zero
3 5 4 N RTYPE Record type = 6
4 7 4 N RECTOT Always = 1 for this record type
5 9 4 N PLAST Points to this record number (DBRN)
6 n 4 N SDB Databank reference number of the databank to which
this subroutine belongs
7 13 64 A SER 32-character subroutine GOAL name in FORTRAN {32A1 )
half word format
EPR Unusea in this record type
i3puATA(l) Unused in this recora format
GPDATA(2) Number of characters in subroutine FORTRAN namei
range is 1 to b
GPDATA(3) Subroutine FORTRAN name; one to six nalfworas witn
thru (S) characters in FORTRAN (Al) format
NOT USED IN THIS RECORD FORMAT
23
45
64
A
39
77
2
N
N/A
78
2
N
40-42
79-84
2-12
A
43
85
4
N
Record Name
File Reference Number
FORTRAN Symbolic Base Declaration
Record Format Number
New Directory Entry
F, K
SORT (20)
Not Applicable
I
[SI
l\3
Symbol ic
Bytes
<r
->[ STY PE
->* 4
Sort
Record
Type
One New Directory Entry-
DRPTR
DELF
DDBN
SERCH (32)
64 (32-char)
->
Record ; Delete Databank Search Key
Pointer Field Reference (in (32A1 ) |
' = Number FORTRAN halfword'
(active) format
1 = Process Record (DRPTR = total # new directory entries)
2 = Normal Directory Entry
3 = EOF (End-of-Fi le) Dummy Record
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Standard Sort/Merge Library
G
Not Applicable
Not Applicable
This dataset is the standard Sort/Merge Utility Program library required
for operation un-er 05/360. This dataset is generated as a portion of
the Operating System and is customarily cataloged under the data set name
"SYSl.SORTLIB".
E-23
Record Name : Sort/Merge Utility Printer Output
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
H
Not Applicable
Not Applicable
Indicated below is a sample of the output as produced by a successful run of
this utility program. Space allocation for the three intermediate work
datasets (File Reference Letter = I) was 100 tracks for tfiis run.
IER036I - B = 90
IER037I - G = 625
IER038I - NMAX =
IER045I - END SORT PH
IER049I - SKIP MERGE PH
IER054I - ROD IN 30,0UT 30
IER052I - EOJ
The exact meaning of the above numbered messages is contained In the following
OS/360 Reference Manual :
IBM System/360 Operating System
Sort/Merge
Form # GC28-6543-6
The only real significance that this message sequence has to the GOAL compiler
is that no error messages are present.
E-24
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Sort/Merge Intermediate Storage
I
Not Applicable
Not Applicable
These three datasets form the intermediate workspace reguired for the Sort/
Merge Utility program operation. The total disk space (1n tracks) for a
2314 Disk sort is given by the following formula:
SPACE = 3 (# of directory entries to be sorted -_max)
+ 6
This computed space is to be divided evenly between the three datasets. The
formula above is a condensation of the standard Sort/Merge computation covered
in Section 2, pp 43 of the following 03/360 reference manual:
IBM System/ 360 Operating System
Sort/Merge
Form # GC28-6543-6
Figure E-8 of this document tabul arizes the storage requirements for the sort
work data sets for directory blocking factors ranging from 10 to 50.
E-25
Figure E-8. {Page 1 of 2)
THE FOLLOWIIjG IS A TABLE IIWICATIIIG THE DISK WORK SPACE
REQUIBEV TO SORT NEW DIRECTORY ENTRIES III THE SECOHD
STEP OF THE DIRECTORY -UPDATE PROCESS. THE TOTAL TRACKS
INDICATED BELOW ARE TO BE DIVIDED EQUALLY {EOUIWIUG UP
IF REQUIRED) BETWEEll THE THREE WORK SPACE ALLOCATIODS .
*** FIXED LEIJGTH SORT lEPUT/ OUTPUT RECORD SIZE
*** TOTAL liUMDEE IHTERMEDIATE SORTWFJUi
*** li = DIRECTORY ULOCKIEG FACTOR
(BYTES)
AREAS
80
3
/;
**** 2 -LEVEL *****
* *
TOTAL SORTWKHN
EliTRIES TRACKS
**** Z- LEVEL *****
* *
TOTAL SORTWKVV
EU TRIES TRACKS
10
100
G
1000
24
11
121
9
1331
29
12
141+
9
1728
35
13
169
9
2197
44
Ik
196
10
2744
54
15
225
10
3375
65
16
256
11
4096
77
17
2Q9
J. i
4913
91
18
324
12
5832
107
19
361
13
6G59
125
20
400
13
8000
144
21
441
14
9261
155
22
4B4
15
1054B
, 190
23
529
16
12167
216
24-
57G
16
13824
245
25
525
17
15625
27G
26
67G
18
17G7C
310
27
729
19
19683
346
20
704
20
21952
385
29
841
21
24389
427
30
900
22
27000
472
31
961
23
29791
520
32
1024
24
32768
571
33
1089
25
35937
626
34
1156
26
3 9 3 4
6B4
35
1225
28
42B7S
746
36
1296
29
45655
811
37
1369
30
50553
880
38
1444
31
54872
953
39
1521
33
59319
1029
ifO
1600
34
64000
1110
E-26
Figure E-8. {Page 2 of 2)
*** FIXED LEUGTH SORT ILPUT / OUTPUT RECORD SIZE {BYTES) : 8
*** TOTAL NUMBER INTERMEDIATE SORTWKNE STORAGE AREAS : 3
*** /; = DIRECTORY BLOCKING FACTOR
**** 2 -LEVEL ***** **** 2 -LEVEL *****
* * * *
TOTAL 50RTWKUIJ TOTAL SOBTIIKNE
N ENTRIES TRACKS ENTRIES TRACKS
'tl ICBl 35 GU921 1105
^2 17G4 37 74088 1284
43 1049 3B 79^07 1377
44 193G 40 85184 1475
45 2025 41 91125 157^
46 2116 43 9 7336 1C05
47 2 20 9 4 5 103 023 1797
48 2304 4G 1105G2 1913
49 2401 48 117C49 2035
50 2500 50 125000 2162
E-27
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Sort/Merge Utility Control-Card Input
J
Not Applicable
Not Applicable
This dataset contains a single control-card with entry as depicted below.
This entry commences in card- column 2 and extends through card-column 55,
inclusive. The only blank character between column 2 and 55 is that between
the words "SORT" and "FIELDS".
cc
2
cc5
6
SORT FIELDS=(1.4.BI.A,13,4,BI,A,17,64,CH.A),SIZE=E10Q0
This causes the Unsorted Directory Entry File (File Reference Letter = F) to
be sorted by the following sequence:
Primary Sort - Sort Record Type (Ascending)
2 - Databank Reference Number (Ascending)
3 - 32-character Entry Name (Search Key) (Ascending)
E-28
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Directory Construct Listing
M
Not Applicable
Not Applicable
An exanple of the listing of concern is to be found in Figure E-4 of this
Appendix. In general, the following results from a correct and complete
directory construction operation:
NEW DIRECTORY STATISTICS
20: DBF
14: WMAX
239: DRTOT
224: OLDTOT
0: DELTOT
15: SORTOT
0: ZERO BALANCE
The meaning of the symbolic counts depicted above are as follows:
DBF
WMAX
DRTOT
OLDTOT
DELTOT
SORTOT
ZERO BALANCE
Directory blocking factor of the current directory
Maximum number of directory blocks containing any entries
Total number of named entries currently supported in the
directory data set
Total number of entries that were supported in the directory
before the current additions/deletions were made
Total number of directory entries that were deleted as a
result of the current maintenance action
Total number of sorted new directory entries that were
processed from the input data set (File Reference Letter K)
A cross check made of the above counts to attempt error
checks; the balance will always be zero for a correct
maintenance process. Numerically,
ZERBAL = DRTOT - (OLDTOT - DELTOT) - SORTOT
E-29
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Databank Initialize Control-Caras
N
None
The following two control-cards are required for each databank initialization
run:
cc
1
cc
1
5
8000 TYPE-1 CARD: TOTAL # RECORDS AVAILABLE IN DATABANK.
30 TYPE- 2 CARD: TOTAL # DATABANKS TO BE ALLOWED.
The first type card indicates via the integer (right-justified to column 10)
the total # of records allocated for the databank {File Reference Letter = E).
This number must be the cube of the Directory Blocking Factor. Thus the
example above indicates the total for a Blocking Factor of 20.
The second control-card Indicates the total # of databanks to be allowed. The
integer is right-justified to card-column 10.
The commentary shown on both card types as beginning in column lb is optional
and may be omitted. No data beyond card-column 10 is processed by the
initialization module.
E-30
Record Name
File Reference Letter
FORTRAN Symbolic Base Declaration
Record Format Number
Initialization Program Printer Output
Not Applicable
Not Applicable
The following printer sequence ensues upon successful completion of the
initialization sequence. The example below indicates a databank Initialized
with 8000 records total, 30 databanks allowed, and a Directory Blocking Factor
of 20.
DATABANK CAPACITY RECORD
RECORD #
TOTAL # RECORDS ALLOCATED
TOTAL # RECORDS ON FREE-QUEUE
HEAD OF FREE- QUEUE RECORD CHAIN
MAXIMUM # OF ALLOWED DATABANKS
TOTAL # DATABANKS CURRENTLY IN USE
1
8000
7969
32
30
E-31
APPENDIX F
SAMPLE CONTROL-CARD INPUT
F. INTRODUCTION
The purpose of this Appendix is to provide a sample of the control-
card input to the data bank pre-processor program. In this regard,
refer to Appendix D, Figure D-4, which pictorially represents the
data flow during data bank maintenance. The following is to be noted:
The control-card input, data set reference letter
Al of Figure D-4 is represented by the sample input
shown in Figure F-1 of this Appendix.
Figure F-2 is a sample of the fixed- format control
card images as produced by the pre-processor program.
Refer to data set reference letter A of Figure D-4.
The exact content of the card-image records is given in Appendix E
(Data Set Record Formats) for data set reference numbers Al and A.
F-1
SAMPLE PRE-PROCESSOR CONTROL-CARD INPUT
** J
This example of Pre-Processor Program input results in the output of the
fixed-format card images shown on Figure F-2.
BEGIN DATABAMK (SAMPLE) REVISION A ;
SPECIFY <PRIMARY GSCU ON SWITCH> AS LOAD TYPE DISCRETE ADDRESS 252 i
SPECIFY <VENT MOTOit FIELD> AS LOAD TYPE ANALOG ADDRESS 0063 ;
SPECIFY <CDC SET CKT> AS LOAD TYPE CLOCK ADDRESS 00^0 S
SPECIFY <MANIF0LD PRESSURE LOW LAMP> AS SENSOR TYPE DISCRETE ADDRESS ^123
SPECIFY <IU COOLANT PRESS> AS SENSOR TYPE ANALOG ADDRESS 0049 ;
SPECIFY <EST> AS SENSOR TYPE CLOCK ADDRESS 6 ;
SPECIFY <LINE PRINTER> ALSO AS <360/PRlNTER> AS SYSTEM TYPE PRINTER ;
SPECIFY <CRT2> AS SYSTEM TYPE CRT ADDRESS I i
SPECIFY <LOG> AS SYSTEM TYPE TAPE ;
SPECIFY <PRrNTER BUSY> AS SYSTEM TYPE INTERRUPT D ;
SPECIFY <PROCEDURE IN PROGRESS FLAG> AS SYSTEM TYPE FLAG 1 ;
SPECIFY <GOAL SR NAME> AS SUBROUTINE (F0RT23I I
NAME (POWER ON) SUBROUTINE <F0RT4) ;
NAME (ABCOEFG) PROGRAM (FDRT25) ;
BEGIN MACRO ABC ( A ) , t B) , ( C ) �<A> ;
(ABC J = (A)
(DEF) = (B)
(GHI) = (C)
tJKL) = <A>
END MACRO ;
END DATABANK ;
FINIS
Figure F-1.
SAMPLE PRE-PROCESSOR PROGRAM CONTROL-CARD OUTPUT
** The fixed card images shown below are the Pre-Processor program
output resulting from the input card set shown on Figure F-1 .
DATABANK
(SAMPLE)
(A)
SPECIFY
<PRIMARYGSCUONSWITCH>
LOAD
DISCRETE
0252
SPECIFY
<VENTMOTaRFieLD>
LOAD
ANALOG
0063
SPECIFY
<CDCSETCKT>
LOAD
CLOCK
0040
SPECIFY
<MANIFOLDPRESSURELOWLAHP>
SENSOR
DISCRETE
*123
SPECIFY
<IUCOOLANTPRESS>
SENSOR
ANALOG
0049
SPECIFY
<EST>
SENSOR
CLOCK
0006
SPECIFY
<LINEPRINTER>
<360/PRINTER>
SYSTEM
PRINTER
-n
SPECIFY
<CRT2>
SYSTEM
CRT
0001
to
SPECIFY
<LOG>
SYSTEM
TAPE
SPECIFY
<PRIMTERBUSY>
SYSTEM
INTERRUPT
0000
SPECIFY
<PROCEOUREINPROGftESSFLAG>
SYSTEM
FLAG
0001
SPECIFY
<GOALSRNAME>
SUBROUTINE
(FORT23J
NAME
(POHERDN)
SUBROUTINE
(F0RT4)
NAME
(ABCOEFG)
SUBROUTINE
(F0RT25)
MACRO
(ABC)
(A)
(B)
(C)
<A>
(ABC)
=� (A) '
(OEF)
= (B) ,
(GHI)
= (C) ;
(JKLJ
= <A> ,
EMD
MACRO
END
DATAB/
\HK
Figure F-2,
APPENDIX G
DATA BANK MAINTENANCE MODULE ERROR MESSAGES
G. INTRODUCTION
Presented in a tabular form in this Appendix is a listing of the possible
error messages that can be generated from the data bank maintenance programs.
It is to be noted that the error messages for the pre-processor program are
listed separately in this document in Appendix H.
G-1
3
DBEND
4
VNAME
BEGDB
5
VNAME
BEGDB
6
VNAME
7
VNAME
8
BEGDB
9
BEGDB
Error Program
Number Module Description
1 MAINT Control card type unknown - a data bank has
not yet been opened (a BEGIN DATABANK statement
has not yet been encountered)
2 MAINT Control card type unknown - a data bank has
been opened (a BEGIN DATABANK statement has alreadj|
been processed)
END DATABANK control card contents invalid
Too many characters in a name, or, the
rightmost name delineator was omitted
Leftmost delineator in a name is not the
expected character or is missing
A character found in a name is not a valid
letter of the alphabet or a valid digit (0-9) �
The first character in a name is not a letter
Keyword error on a BEGIN DATABANK statement
Trying to initilize a new data bank but the
maximum number of allowed data banks has
already been reached
10 DBSEEK Wrong record type (not type = 1 or 2) found
when searching through the data bank reference
record chain in the data bank file
11 DBSEEK Chaining error in the data bank reference records
section of the data bank file
12 SPECFY Keyword error, missing, or out of sequence on
a SPECIFY statement
13 SPECFY Delineator problem (missing or invalid) on
a function designator name
14 SPECFY End-of-file found on input data set while
attempting to read the second card of a
SPECIFY statement
15 SPECFY Error encountered in parsing a subroutine name
or in the delineators surrounding a subroutine name
16 SPECFY Discrete/analog/clock/interrupt/flag address field
contains an illegal {non digit) character
\^-2
Error
Number
17
18
19
20
Program
Modul e
FIND
SUPERD
SUPERD
SUPERD
21
NAMESR
22
NAMESR
23
MACRO
24
MACRO
25
MACRO
26
MACRO
27
MACRO
28
MACRO
29
MACRO
30
SPECFY
31
DELETE
32
DELETE
33
DELETE
Description
Program logic error when attempting a data bank
directory search
A data bank function designator record has been
found but the function designator type field is
zero or negative
Same problem as 18, above, however the function
designator type field is greater than 11
A macro skeleton record has been found in a
macro chain in the data bank file, but the record
type is not type = 5
Keyword error on NAME SUBROUTINE control card
Error encountered in parsing a FORTRAN-equi val ent
subroutine name
Error in one of the keyword fields on a macro
Error in a parameter field parse on the BEGIN
MACRO statement
End-of-file found in input data set before the
end of a macro was found
Too many formal parameters found on a BEGIN
MACRO statement (more than 10)
Ran out of space in the data bank file while
entering a macro
Program logic error encountered when processing
the macro header record chain
A macro has no skeleton cards
Error encountered in parsing a SYSTEM type keyword,
i.e., PRINTER, TAPE, CRT, INTERRUPT, FLAG
Keyword error found on a DELETE control card
Delimeter error on the name field
Member named for deletion is not in the data bank
ti-3
Error Program
Number Modul e Description
34 DELETE A function designator was scheduled for deletion
(the name on the DELETE card was bounded by
brackets); the record found in the data bank
is not a function designator (type = 3) record
35 DELETE Name to be deleted was bounded by parenthesis,
indicating that the record type was not a function
designator; the record found in the data bank
has a function designator type field (type = 3,
or less)
Logic error encountered while attempting to
make a directory deletion
Error in address field - non-numeric characters
in a digit field
Record sequencing error in the sorted directory
entries data set
End-of-f1le found on sort input data set before
first record read and processed
End-of-file record missing in the sort data set
Duplicate record name in the directory {a single
data bank contains two records with the same
alphanumeric names)
46 DELDB Keyword contents invalid on a DELETE DATA BANK
control card
47 DELDB Cannot locate the data bank to be deleted
48 DELDB Logic error in data bank deletion process; cannot
locate the required data bank reference record
by using the data bank reference number
36
DELETE
37
SPECFY
40
DCON
41
DCON
42
DCON
43
DCON
G-4
APPENDIX H
PRE-PROCESSOR ERROR MESSAGE LIST
H. INTRODUCTION
As mentioned in Appendix D, Program Module Description, the data bank
pre-processor progrsffn is actually the GOAL compiler module driven by a
suitable syntax table. The syntax equations required are covered in
Appendix I. The error messages to be generated are taken from the
standard GOAL compiler message list, a copy of which is included in this
Appendix. The actual message numbers of concern for the data bank pre-
processor program are:
131
844
911
800
847
918
804
903
927
808
904
939
829
909
952
836
910
999
H-1
COMPLETE GOAL COMPILER MESSAGE LIST (Page 1 of 5)
100 INVALID ROW DESIGNATOR OR KEYWORD �RDW� IS MISSIMG .
101 INVALID C3LLJMN IMDEX NAME OR CDLUMN INTEGER NUMBER.
102 INVALID ROW INDEX NAME OR ROW INTEGER NUMBER.
103 INVALID LIST INDEX NAME OR LIST INTEGER NUMBER.
lO't INVALID REFERENCE OR KEYWORD FOLLOWING KEYWORD 'SEND' OR �APPLY*.
106 INVALID OR MISSING EXTERNAL DESIGNATOR -FROM-
108 INVALID OR MISSING EXTERNAL DESIGNATOR - TO -
110 INVALID INTERNAL NAME WHICH MUST BE DECLARED AS A STATE VALUE.
112 INVALID INTERNAL NAME OR STATE WHICH MUST BE DECLARED AS STATE VALUES.
11^ INVALID INTERNAL NAME WHICH MUST NOT BE DECLARED AS STATE OR TEXT .
122 INVALID INTEGER NUMBER OF ENTRIES.
12^ INVALID INTERNAL NAME OR STATE .
12B INVALID NUMBER NAME.
=?^ 129 INVALID NUMBER NAME. THIS NAME IS PREVIOUSLY DEFINED.
�^ 130 INVALID NUMBER PATTERN OR NUMBER.
131 INVALID NUMERIC VALUE - MUST BE 1-4 DIGITS.
132 INVALID QUANTITY NAME.
133 INVALID QUANTITY NAME. THIS NAME IS PREVIOUSLY DEFINED .
134 INVALID QUANTITY VALUE.
138 INVALID STATE VALUE.
140 INVALID TEXT NAME.
141 INVALID TEXT NAME. THIS NAME IS PREVIOUSLY DEFINED,
142 If^VALlD NUMERIC LIST NAME.
143 INVALID NUMERIC LIST NAME. THIS NAME IS PREVIOUSLY DEFINED.
L44 INVALID NUMERIC TABLE NAME
145 INVALID NUMERIC TABLE NAME . THIS NAME IS PREVIOUSLY DEFINED.
146 INVALID INTEGER NUMBER OF COLUMNS.
147 INVALID INTEGER NUMBER OF COLUMNS. THE LIMITS ARE THROUGH 45.
148 INVALID INTEGER NUMBER OF ROWS.
149 INVALID INTEGER NUMBER OF ROWS. THE LIMITS ARE I THROUGH 45.
150 INVALID COLUMN NAME.
151 INVALID COLUMN NAME OR KEYWORD 'CDLUMN' IS MISSING.
152 INVALID QUANTITY LIST NAME.
153 INVALID QUANTITY LIST NAME. THIS NAME IS PREVIOUSLY DEFINED.
GOAL COMPILER MESSAGE LIST (Page 2 of 5)
IS'f INVALID QUAMTITy TABLE NAME.
155 INVALID QUANTITY TABLE NAME. THIS NAME IS PREVIOUSLY DEFINED.
156 INVALID STATE LIST NAME.
157 INVALID STATE LIST NAME. THIS NAME IS PREVIOUSLY DEFINED.
158 INVALID STATE TABLE NAME.
159 INVALID STATE TABLE NAME. THIS NAME IS PREVIOUSLY DEFINED.
160 INVALID INTERMAL NAME OR NUMBER PATTERN .
162 INVALID TEXT LIST NAME.
163 I^JVALID TEXT LIST NAME. THIS NAME IS PREVIOUSLY DEFINED.
16*^ INVALID INTEGER NUMBER OF CHARACTERS.
165 INVALID INTEGER NUMBER OF CHARACTERS. THE LIMITS ARE 1 THROUGH 132.
166 INVALID TEXT TABLE NAME.
167 INVALID TEXT TABLE NAME. THIS NAME IS PREVIOUSLY DEFINED.
168 INVALID DELAY STATEMENT FOLLQv^ING THE VERB DELAY OR WAIT.
172 INVALID REFERENCE OR KEYWORD FOLLOWING THE VERB ISSUE .
173 INVALID LEAVE SFATEMENT - LEAVE CAN ONLY BE USED WITHIN A SUBROUTINE
^ 174 INVALID RESUME STATEMENT.
^ 175 INVALID LEAVE STATEMENT.
176 INVALID PERFORM SUBROUTINE STATEMENT FOLLOWING THE SUBROUTINE NAME.
IBO INVALID RECORD DATA STATEMENT FOLLOWING THE KEYWORD D I SPLAY, PR INT OR RECORD.
182 INVALID STEP NUMBER OR KEYWORD 'ALL* IS MISSING.
1B4 INVALID TEXT, NAME OR FUNCTION DESIGNATOR FOLLOWING THE VERB REPLACE.
186 IVJVALID TEXT OR KEYWORD 'ENTRY' IS MISSING FOLLOWING THE VERB REQUEST.
190 INVALID REFERENCE OR KEYWO'^D 'PRESENT VALUE 0F� FOLLOWING THE VERB SET.
195 INVALID WHEN INTERRUPT STATEMENT FOLLOWING THE KEYWORD 'OCCURS'.
200 THE NUMBER OF ENTRIES INITIALIZED EXCEEDS THE NUMBER SPECIFIED.
201 THE NUMBER OF COLUMN TITLES EXCEEDS THE SPECIFIED NUMBER OF COLUMNS.
202 THE NUMHER OF ENTRIES INITIALIZED IS LESS THAN THE NUMBER SPECIFIED.
203 THE NUMBER OF COLUMN TITLES IS LESS THAN THE SPECIFIED NUMBER DF COLUMNS.
204 THE FUNCTION DESIGNATOR SPECIFIED IS NOT DEFINED IN THE DATA BANK,
206 INVALID ROW FUNCTION DESIGNATOR. IT IS PREVIOUSLY DEFINED IN THIS TABLE.
210 INVALID COLUMN TITLE NAME. THIS NAME IS PREVIOUSLY DEFINED IN THIS TABLE.
212 EXECUTION RATE AS SPECIFIED IS GREATER THAN TEN MINUTES.
214 CONCURRENT STATEMEMT DOES NOT HAVE A STEP NUMBER.
216 CORRESPONDENCE IS INVALID (SHOULD BE 1 TO I, 1 TO MANY OR MANY = MANY)
218 INVALID NUMERIC FORMULA {UNBALANCED PARENTHESES)
220 INVALID INTERNAL NAME (NOT DECLARED AS NUMERIC OR QUANTITY*
222 INVALID INTERNAL NAME (NOT A SINGLE ELEMENT)
GOAL COMPILER MESSAGE LIST (Page 3 of 5)
22^ INVALID NUMERIC FORMULA (SIZE EXCEEDS COMPILER CAPACITY)
228 FUNCTION DESIGNATOR SPECIFIED IS NOT A SUBROUTINE PARAMETER.
300 INVALID MACRO LABEL- DOES NOT START WITH A LETTER.
301 INVALID MACRO LABEL- LONGER THAN 32 CHARACTERS.
302 INVALID MACRO LABEL- CONTAINS AN ILLEGAL CHARACTER.
303 INVALID MACRO LABEL- MACRO LABEL IS MULTI-DEFINED.
304 INVALID MACRO PARAMETER - DOES NOT START WITH A LETTER.
305 INVALID MACRO PARAMETER - LONGER THAN 32 CHARACTERS.
306 INVALID MACRO PARAMETER - CONTAINS AN ILLEGAL CHARACTER.
307 INVALID MACRO PARAMETER - MACRO PARAMETER IS MULTI-DEFINED.
308 EXPECTED SEMICOLON <;� NOT FOUND AFTER PROCESSING THE 10 MAXIMUM PARAMETERS.
309 EITHER COMMA � , � OR SEMICOLON �;� WAS OMITTED.
310 LEFT PARENTHESIS M' MISSING ON PARAMETER FOLLOWING COMMA.
311 MACRO TO BE EXPANDED AND/OR EXECUTED IS NOT DEFINED.
312 MACRO TO BE EXPANDED AND/OR EXECUTED NEEDS PARAMETERS - NONE WERE SUPPLIED.
313 INVALID SJBSTITUTION PARAMETER - CONTAINS AN ILLEGAL CHARACTER.
3r 314 INVALID SJBSTITUTION PARAMETER - CONTAINS NO CHARACTERS.
*. 315 NUMBER OF PARAMETERS IN STATEMENT AND MACRO ARE NOT THE SAME.
316 NUMBER OF PARAMETERS IN STATEMENT EXCEEDS NUMBER OF PARAMETERS IN MACRO.
317 INVALID SJBSTUTUTION PARAMETER - LONGER THAN 79 CHARACTERS.
318 INVALID MACRO BODY - CONTAINS NO CHARACTERS.
350 INVALID CHARACTER STRING - CONTAINS AN ILLEGAL CHARACTER,
351 INVALID CHARACTER STRING - CONTAINS MORE THAN 32 CHARACTERS.
352 INVALID REPLACEMENT CHARACTER STRING. CONTAINS MORE THAN 80 CHARACTERS.
353 INVALID REPLACEMENT CHARACTER STRING, CONTAINS AN ILLEGAL CHARACTER.
354 REPLACEMENT NAME, CHARACTER STRING OR FUNCTION DESIGNATOR IS MULTI-DEFINED.
400 NUMBER DF DATA BANKS IN USE HAS EXCEEDED THE MAXIMUM OF 10.
402 DATA BANK SPECIFIED IS ALREADY IN USE.
406 INVALID DATA BANK NAME. THE DATA BANK NAME IS MULTI-DEFINED.
408 UNABLE TO FREE DATA BANK AS NONE IS BEING USED AT THIS TIME.
410 SPECIFIED DATA BANK NAME DOES NOT EXIST.
412 UNABLE TO FREE DATA BANK AS IT IS NOT IN USE AT THIS TIME.
413 LABEL ERROR - THE STATEMENT FOLLOWING AN UNCONDITIONAL GO TO IS NOT NUMBERED
414 STRUCTURAL ERROR ** PREAMBLE STATEMENT FOUND IN PROCEDURAL BODY.
415 SYMBOL TABLE OVERFLOW HAS OCCURRED. A MAXIMUM OF 9999 ENTRIES IS ALLOWED.
800 INVALID ADDRESS - MUST BE 1-4 DIGITS.
802 INVALID COMPARISON TEST.
804 INVALID DATA BANK NAME.
GOAL COMPILER MESSAGE LIST [Page 4 of 5)
805 INITIALIZATION OF REFERENCED **SU8R0UTINE PARAMETER** NAME IS NOT ALLOWED.
806 INVALID Oti MISSING EXTERNAL DESIGNATOR.
y07 END PROGRAM STATEMENT IS INVALID DURING A SUBROUTINE COMPILATION.
808 INVALID FUNCTION DESIGNATOR.
809 END SUBROUTINE STATEMENT IS INVALID DURING A PROGRAM COMPILATION.
810 istVALiD NUMBER, NUMBER PATTERN ,OUANT I TY, STATE, TEXT OR INTERNAL NAME.
812 INVALID INTEGER NUMBER.
81^ INVALID INTERNAL NAME.
816 INVALID OR MISSING REFERENCE FDLL3WING THE COMMA.
826 INVALID NUMERIC FORMULA.
828 INVALID OUTPUT EXCFPTiON.
829 INVALID NAME OR FUNCTION DESIGNATOR.
830 IMVALID SUBROUTINE PARAMETER (NAME OR FUNCTION DESIGNATOR).
832 INVALID OR MISSING PROGRAM NAME.
834 INVALID QUANTITY OR INTERNAL NAME .
836 INVALID REVISION LABEL,
n: 838 INVALID ROW DESIGNATOR.
a 041 INVALID STEP NUMBER. THIS STEP NUMBER IS PREVIOUSLY DEFINED.
842 INVALID STEP NUMBER.
843 INVALID PERFORM PROGRAM OR PERFORM SUBROUTINE STATEMENT.
844 INVALID SUBROUTINE NAME.
845 BEGIN PROGRAM OR BEGIN SUBROUTINE FOUND DURING A PROGRAM COMPILATION,
846 INVALID TABLE NAME.
847 INVALID FORTRAN SUBROUTINE NAME.
848 INVALID TEXT CONSTANT.
849 A TEXT CONSTANT ENTRY EXCEEDED THE MAXIMUM NUMBER OF CHARACTERS SPECIFIED.
850 INVALID TIME VALUF-
852 INVALID FUNCTION DESIGNATOR TYPE IN THE SPECIFY STATEMENT.
853 INVALID ROW FUNCTION DESIGNATOR TYPE. MUST BE A LOAD OR SENSOR ANALOG.
854 INVALID ROW FUNCTION DESIGNATOR TYPE. MUST BE A LOAD OR SENSOR DISCRETE.
855 INVALID ROW FUNCTION DESIGNATOR TYPE. MUST BE A SYSTEM FUNCTION DESIGNATOR.
856 THE NUMBER OF ROW FUNCTION DESIGNATORS EXCEEDS THE NUMBER OF ROWS.
857 THE NUMBER OF ROW FUNCTION DESIGNATORS IS LESS THEN THE NUMBER OF ROWS.
900 KEYWORD NOT FOUND - AND.
901 KEYWORD NOT FOUND - RETURN.
902 KEYWORD NOT FOUND - AND SAVE AS.
903 KEYWORD NOT FOUND - ADDRESS,
904 KEYWORD NOT FOUND - AS.
907 KEYWORD NOT FOUND - READINGS OF.
GOAL COMPILER MESSAGE LIST (Page 5 of 5)
a.
908
909
910
911
912
913
914
916
918
920
922
92^^
925
926
927
930
934
938
939
940
941
944
945
946
948
952
954
986
987
988
989
990
991
992
993
994
995
996
998
999
KEYWORD
KgYWORO
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
NOT
NOT
NOT
NOT
NOT
NOT
P40T
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
NOT
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
FOUND
OR SYSTEM.
BEGIN PROGRAM OR
CHARACTERS.
CRTt PRINTER, TAPE, INTERRUPT, OR FLAG.
DATABANK iJR MACRO.
ANALOG, CLOCK, OR DISCRETE.
ENTRIES.
EXCEPTIONS.
EQUAL TO OR =,
FROM
LOAD OR SENSOR
OCCURS.
UNTIL.
PRESENT VALUE
COLUMNS.
ROWS AND.
REVISION.
SUBROUTINE,
TIMES.
TO
TYPE,
WITH,
WITH ENTRIES.
WITH A MAXIMUM OF, EQUAL TO
BEGIN SUBROUTINE FOUND DURING
OF.
OR =.
A SUBROUTINE
COMPILATION,
KEYWORD
KEYWORD
KEYWORD
KEYWORD
KEYWORD
INVALID
INVALID
INVALID
INVALID
INVALID
INVALID
INVALID
INVALID
NOT FOUND - PERFORM PROGRAM, VERIFY, DISPLAY, PRINT, OR RECORD.
NOT FOUND - NUMBER, QUANTITY, STATE OR TEXT,
NOT FOUND - PROGRAM OR SUBROUTINE,
NOT FOUND - AND INDICATE RESTART LABELS OR SEMICOLON *;'.
NOT FOUND - THEN OR COMMA ',' ,
PAGE NUMBER FOLLOWING THE WORD PAGE. LIMITS ARE 1-999.
LINE SIZE FOLLOWING PAGE SIZE. LIMITS ARE 80-110.
PAGE SIZE FOLLOWING THE WORD LINE. LIMITS ARE 1-32767.
DATE TEXT CONSTANT FOLLOWING THE WORD DATE. LIMITS ARE 1-8.
TITLE TEXT CONSTANT FOLLOWING THE WORD TITLE.
SEQUENCE FIELD NUMBER FOLLOWING THE WORD SEQ.
COMPOUND COMPILER CONTROL CARD.
COMPILER CONTROL CARD,
THIS STATEMENT IS NOT RECOGNIZED AS A GOAL STATEMENT
EXPECTED DOUBLE DOLLAR SIGN �*$� NOT FOUND
EXPECTED COMMA ',� NOT FOUND.
EXPECTED SEMICOLON �;' NOT FOUND.
LIMITS
LIMITS
ARE 1-100.
ARE 0-10.
APPENDIX I
DATA BANK PRE-PROCESSOR SYNTAX TABLES
I. INTRODUCTION
As mentioned in Appendix 0, Program Module Description, the data bank pre-
processor program is actually the GOAL language compiler program. Syntax
tables have been provided which direct the GOAL compiler in its action as
pre- processor. The current documentation relative to the compiler and its
syntax tables are to be found in Volumes I and II. The syntax tables
utilized for the release version have been entered as table nunber 8 in
the syntax table library. These syntax equations are indicated in symbolic
form on the pages following in this Appendix.
I-l
PRE-PROCESSOR INPUT CONTRQL-CARD SYNTAX DIAGRAMS (Page 1 of 5)
DATABANK
INPUT
^r
BEGIN
DATABANK
_]'
STATEMENT
TYPES
END
DATABANK
DELETE
DATABANK
FINISH
SPECIFY
STATEMENT
TYPES
DELETE
STATEMENT
NAME
SUBROUTINE
MACRO
DEFINITION
1-2
PRE-PROCESSOR INPUT CQNTRQL-CARD SYNTAX DIAGRAMS (Page 2 of ^
� � � ' � ~'" "' " '~ -.1-. I � � I | _ t il � . V .J f
SPECIFY
SPECIFY-
FUNCTION
DESIGNATOR
ALSO AS �
FUNCTION
DESIGNATOR
T
:>
^-
AS
SENSOR
LOAD
SYSTEM
SUBROUTINE
SYSTEM
TYPES
FORTRAN*
NAME
TYPE
?LIMITED FORTRAN NAME
DISCRETE
ANALOG �
CLOCK �
ADDRESS
1-3
PRE-PROCESSOR INPUT CONTRQL-CARD SYNTAX DIAGRAMS (Page 3 of 5)
PRINTER
SYSTEM
TYPES
TYPE
NUMERAL
ADDRESS
ADDRESS
NUMERAL
LETTER
?LIMITED FORTRAN NAME
LETTER
NUMERAL
i-4
PRE-PRQCESSOR INPUT CONTROL>CARD SYNTAX DIAGRAMS (Page 4 of 5)
NAME
SUBROUTINE
NAME
SUBROUTINE
PROGRAM
DELETE
DATABANK
DELETE DATABANK
DELETE
STATEMENT
DELETE
FUNCTION
DESIGNATOR
MACRO
DEFINITION
BEGIN MACRO
STATEMENT
MACRO
SKELETON
END
MACRO
END MACRO
I-b
PRE-PROCESSOR INP UT C ONTROL ^CARD SYNTAX DIA6RAMS (Page 5 of 5)
1 ' �� � * I � I ' I ^ I . . I I � - � - � - ^ ' -� I I � W � � � ^ H V �. � � . ' ,� r I L I* " I �' . *
MACRO
SKELETON
May not include
words 'END MACRO'
Must not have more
than 40 cards without
a seni colon
1-6
PRE-PRQCESSOR SYNTAX TABLES (Page 1 of 2)
18 0-1
*** DATA BANK PREPROCESSOR SYMTAX TABLE � SYNTAX TABLE #Q
*
*
<D8 PROOUCTION> = #5225 <D8 STMT> #10 ;
<DB STHT> = <MACRO DEFN MODE> I <BEGIM STMT> | <END STMT> | <SPECIFy> |
<DELETE STMT> I <SUBRTN NAME> | <FIMIS> ;
<MACRQ DEFN MOOE> = #56 <MOM0i> ;
<M0M01> = <MDMQ2> 1 ff502 ;
<MDM02> = �END MACRO* #503 $999 �;* ;
?
<BE6IN STMT> = �BEGIN' $910 <B1> ;
<B1> = <B2> ) <B3> ;
<B2> = *MACRO' #501 ;
<B3> = 'DATABANK' $80^ <NAM�> #5201 $927 <REVISION LABFL>
$999 �;� #5202 ;
*
<END STMT> = 'END DATABANK* $999 ';' #5203 ;
*
<SPECIFY> = 'SPECIFY' $808 <FUNCTION DESIGNATOR> #5204 <ALT FORM>?
$904 'AS' $9ia <SP1> $999 �;' #5205;
<SPl> = <SP2> 1 <SP3> 1 <SUBRTN> ;
<SP2> = <SP4> $939 'TYPE' $911 <SP5> $903 'ADDRESS'
$800 <SP7> ;
<SP7> = <ADDRESS> #5217 ;
<SP4> = <LDAD> 1 <SENSOR> ;
<LOAD> = 'LOAD* #5206 ;
<SENSOR> = 'SENSOR' #5207 ;
<SP5> = <DISCRETE> I <ANALOG> | <CLQCK> :
<D1SCRETE> = 'DISCRETE' #5209 :
<ANALaG> = 'ANALOG' #5210 ;
CCLOCK> = 'CLOCK' #5211 ;
<SP3> = 'SYSTEM' #5208 $939 'TYPE' $909 <SP6> ;
<SP6> = <PRINTER> t <TAP�> 1 <CRT> |
<INTERRUPT> 1 <FLAG> i
<PRINTER> = 'PRINTER' #5212 ;
<TAPE> = 'TAPE' #5214 ;
<CRT> = 'CRT' #5213 $903 'ADDRESS' $800 <SP7> ;
<INTERRUPT> = 'INTERRUPT' $131 <SP9> ;
<SP9> = #23 #5222 ;
<FLAG> = 'FLAG' $131 <SP8> ;
<SP8> = #23 #5223 ;
<SUBRTN> = 'SUBROUTINE' $847 <FORTNM> #5218 ;
*
<DELETE STMT> = <DELETED8> 1 <DELETE> ;
<DELETEDB> ~ 'DELETE DATABANK' $804 <NAME> #5201 $927
<REVISION LABEL> $999 �;� #5220 ;
<OELETE> = 'DELETE' $829 <FD OR NAME> $999 ';' #5221 ;
1-7
PRE-PROCESSOR SYNTAX TABLES (Page 2 of 2)
*
4>
*
�
<SUBRTN NAME> = 'NAME* $8AA <NAME> #5201 $952 <SN1>
$847 <FORTNM> #5218 $999 �;* #5224 ;
<SN1> = 'SUBROUTINE' I 'PROGRAM' ;
<ALT FORM> = 'ALSQ' $904 <AF1> ;
<AF1> = 'AS* $808 <FUNCTIOM DESIGNATOR> #5216 ;
<AODR�SS> = #23 ;
<REVISION LABeL> = 'REVISION* $836 #27 #5219 ;
<FD OR NAME> = <F0> | <NM> i
<FD> = <FUNCTI0f4 DESIGNATOR> #5204 ;
<NM> = <NAME> #5201 ;
<FORTNM> = #29 #5226 ;
<NAM�> = #29 ;
<FUNCTION DeSIGNATOR> = #20 ;
<FINIS> = 'FINIS* #5215 ;
*
*
* #5201 - MOVE DB NAME TO OUTPUT BUFFER
* #5202 - WRITE FIXED FORM 'DATABANK' RECORD
* #5203 - WRITE 'END DATABANK* STMT
* #5204 - HOVE FUNCTION DESIGNATOR TO OUTPUT BUFFER
* #5205 - WRITE FIXED FORM 'SPECIFY* RECORD
* #5206 - #5214 MOVE FD TYPES INTO OUTPUT BUFFER
* #5215 - SET ENDFLG = 1 AND RETURN
* #5216 - SUPPORT ALTERNATE FORM FD - OUTPUT FIRST LINE
* #5217 - MOVE ADDRESS INTO OUTPUT AREA
* #5218 - MOVE SUBROUTINE NAME INTO OUTPUT AREA
* #5219 - MOVE REVISION LABEL TO OUTPUT AREA
* #5220 - WRITE FIXED FORM 'DELETEDB' RECORD
* #5221 - WRITE FIXED FORM 'DELETE' RECORD
* #5222 - MOVE 'INTERRUPT' AND VALUE TO OUTPUT AREA
* #5223 - MOVE 'FLAG' AND VALUE TO OUTPUT AREA
* #5224 - OUTPUT 'NAME SUBROUTINE' RECORD
* #5225 - SET PREFLG = 1
* #5226 - LIMIT FORTRAN SUB NAME TO SIX CHARACTERS
*
END ;
1-8