ESD TR 68 452_JOVIAL_Evaluation_Project_Oct68 452 JOVIAL Evaluation Project Oct68
ESD-TR-68-452_JOVIAL_Evaluation_Project_Oct68 ESD-TR-68-452_JOVIAL_Evaluation_Project_Oct68
User Manual: ESD-TR-68-452_JOVIAL_Evaluation_Project_Oct68
Open the PDF directly: View PDF 
.
Page Count: 296
| Download | |
| Open PDF In Browser | View PDF |
ESD RECORD COPY
c.
i cite o
ESD-TR-68-452
RETURN TO
SCIENTIFIC X, TECHNICAL INFORMATION DIVISION
£3
fa f*.
in
JOVIAL EVALUATION PROJECT
William M. O' Brien
ESD ACCE!
;iQN USlT
ESTl Call No.__
Copy No.
/—
of
')
cys
15 October 1968
COMMAND SYSTEMS DIVISION
ELECTRONIC SYSTEMS DIVISION
AIR FORCE SYSTEMS COMMAND
UNITED STATES AIR FORCE
L. G. Hanscom Field, Bedford, Massachusetts
This document has been
approved for public release and
sale; its distribution is
unlimited.
(Prepared under Contract No. AF I9628-68-C-0II0 by Data Dynamics, Inc.,
9800 S. Sepulveda Boulevard, Los Angeles, California 90045.)
1
/\U W •' #
LEGAL NOTICE
When U. S. Government drawings, specifications or other data are used for any
purpose other than a definitely related government procurement operation, the
government thereby incurs no responsibility nor any obligation whatsoever; and
the fact that the government may have formulated, furnished, or in any way supplied the said drawings, specifications, or other data is not to be regarded by
implication or otherwise as in any manner licensing the holder or any other person
or conveying any rights or permission to manufacture, use, or sell any patented
invention that may in any way be related thereto.
OTHER NOTICES
Do not return this copy.
Retain or destroy.
ESD-TR-68-452
JOVIAL EVALUATION PROJECT
William M. O' Brien
15 October 1968
COMMAND SYSTEMS DIVISION
ELECTRONIC SYSTEMS DIVISION
AIR FORCE SYSTEMS COMMAND
UNITED STATES AIR FORCE
L. G. Hanscom Field, Bedford, Massachusetts
This document has been
approved for public release and
sale; its distribution is
unlimited.
(Prepared under Contract No. AF 19628-68-C-0H0 by Data Dynamics, Inc.,
9800 S. Sepulveda Boulevard, Los Angeles, California 90045.)
FOREWORD
This report is the result of an extensive evaluation of Air Force Manual 100-24,
Standard Computer Programming Language for Air Foce Command and Control Systems.
The evaluation centered on user experience with operational JOVIAL systems. It was
accomplished by the use of both interview and questionnaire techniques.
The work has been performed as part of Project 6917 Task 04 under contract
number F19628-68-C-011 0 for Electronic Systems Division U.S. Air Force Systems
Command. The project monitor was Capt. Martin J. Richter, Hq ESD (ESLFE).
The report contains detailed recommended changes to AFM 100-24 in Section 3.
This report has been reviewed and is approved.
MARTIN J. RIC
Project Moni
ER, Capt., USAF
WILLIAM F. HEISLER, Col., USAF
Chief, Command Systems Division
Directorate of Planning & Technology
ii
ABSTRACT
The results of the evaluation of the JOVIAL Language as specified in Air Force
Manual (AFM) 100-24 are contained in this report. This evaluation was based
primarily on experience of users of JOVIAL Language dialects. The goal of this
evaluation was to recommend deletions, retentions, modifications, and extentions
to the JOVIAL language as specified in AFM 100-24 based on the users experience.
The methodology of the evaluation consisted of collecting user experience data by
means of a "JOVIAL Application Questionnaire" and interviews; and evaluating this
data based on criteria established and documented in the "Approach for Change". This
report contains a list of JOVIAL features recommended for deletion and retention and
detailed specifications of recommended modifications and extentions to the JOVIAL
language. In addition, the report contains the detailed interview notes and
questionnaire responses which were the basic data used to arrive at the recommendations.
•<•
in
TABLE OF CONTENTS
Page
FOREWORD
ABSTRACT
SECTION I
*>•
in
SECTION
SECTION
SECTION IV
APPENDIX
APPENDIX
APPENDIX
APPENDIX
I
II
III
IV
INTRODUCTION
1 .1
Project Overview
1 .2
List of Features and Concepts Considered
1.3
Method of Analysis
1.3.1
Philosophy of Language and Language
Standardization
1.3.2
Method of Analysis of JAQ Responses
1.3.3
Method of Analysis of Inter Responses
CONCLUSION
2.1
JOVIAL Language Extention
2.1 .1
List of Extentions
2.1 .2
Remarks on Extentions
2.2
Deletions
2.3
List of Nucleus Features
2.4 List of Optional Features
2.5
Observations
EXTENSION SPECIFICATIONS
3.1
General
3.2
Recommendations
3.2.1
Deletions
3.2.2
Additions and Modifications
3.2.3
Nucleus Features
3.2.4
Optional Features
ADDITIONAL RECOMMENDATIONS
4.1
Specific Study Topics
4.2
General Concepts
4.3
Specific Concepts
4.4
Language/Compiler Design Goals
Interviewee Directory and Notes
JAQ Feature Resolution and Analysis
Interview Questions
Interview Response Analysis
IV
1
1
2
6
6
8
10
11
11
11
12
13
14
16
17
19
19
19
19
20
77
79
81
81
81
81
82
83
127
235
253
SECTION
INTRODUCTION
1 .1
Project Overview
The JOVIAL Evaluation Project consisted of a study of the Standard Computer
Programming Language for Air Force Command and Control System (J3 dialect),
as specified in AFM 100-24. The goal of this study is to recommend deletions,
retentions, modifications, and propose extensions to the features of the Standard
JOVIAL language dialect as specified in AFM 100-24 on the basis of command and
control programming requirements.
The study has been carried out by soliciting information from a community of users
of JOVIAL. Members of this community were selected to obtain as broad a crosssection of those JOVIAL command and control programming groups as possible.
There are thirteen members in the community canvassed — they are identified
in Appendix 1 . It is important to note that several of the military members are nonAir Force and that the list also includes two industrial groups using JOVIAL for
non-military applications. It is felt that the information obtained from such a diverse
community has produced a blueprint for a "globally" useful command and control
programming language.
Information was solicited from the members of the community by two means:
(1)
a JOVIAL Application Questionnaire (JAQ), ESD-TRand
(2)
an in-person interview conducted by DDL
The JAQ contained comprehensive descriptions of the features defined by
AFM 100-24 with questions designed to determine
(1)
deviations of the JOVIAL dialects currently in use from the
standard, and
(2)
the degree of usage of those features which did not deviate
significantly from their standard counterparts. (Respondents could
either estimate the number of usages of the feature in their application
or give an exact number.)
Information pertaining to hardware configuration, operating procedures, programmer
experience levels, etc., were also solicited in the JAQ. One or more copies of the
JAQ were sent to each member of the community. In most cases, each of many
sub-groups of a given user group responded to a JAQ. Such responses were made
with respect to the particular program subsystem for which the sub-group was
responsible. In some instances, different sub-groups used aifferent compilers (dialects);
1
in other instances, the same compiler (dialect) was used by many or all of the
sub-groups. (Note that "members of the community" or groups and sub-groups are
alternately referred to in this document as "applications".)
Interviews were conducted by DDI personnel with each of the members of the
community to determine the need for additional features to the language and the
need for modifications and extensions to certain existing features. Some questions
at the interviews were asked in order to gain insight into broad command and control
programming requirement areas. The typical interview lasted for approximately three
hours. A list of the questions asked at each interview may be found in Appendix 3.
Respondents to the JAQ and the interview questions were generally enthusiastic and
dilligent in providing the great amounts of information requested of them. We wish
to acknowledge the cooperative efforts of all of those who participated in this study.
1 .2
List of Features and Concepts Considered
This paragraph contains a list of those features and concepts which were considered
in the study and about which information was solicited. The word "concept" as used
here refers to functions performed by command and control programmers rather than
explicit language facilities or features. Concepts were explored during the interviews
along with certain additional features. An example of a concept is "Dynamic Storage
Allocation". It was the point of the interviews to identify and develop features —
explicit language facilities — from those concepts which the members of the
community thought relevant to the solution of their problems.
Selection of features and concepts is relatively subjective. No claim is made that
those chosen for investigation are exhaustive. In the interest of economy, certain
Standard JOVIAL features were deliberately left out of the list because it was felt
that little utility could be gained from their study.
The features and concepts have been organized into "function modules" and sub modules
in order to clearly point up functional relationships between them. This organization
serves to impose a perspective on the large number of features and concepts being
evaluated.
In the following list of features and concepts the notation "(Q)" denotes a feature
about which information was solicited in the JAQ and "(I)" denotes a feature or
concept about which information was solicited at the interviews.
(1)
Function Module: Data
a)
Item Data (Non-Structured Data)
•
Literal Items
Standardized Expanded Character Set (I)
(Expanded JOVIAL sign set)
(2)
(3)
Item Type Hollerith (Q)
Item Type Standard Transmission Code (Q)
Character Data Size Attribute (Q)
User Definable
Character Set/Encoding Scheme (I)
•
Status Items (Q)
•
Status Formulas (Q)
•
Explicit Status Size Attribute (Q)
•
Item Type Bit String (I)
b)
Data Structures (Aggregates of Items)
•
Structure Array (Q)
•
Structure Table (Q)
Table Variability Attribute - Rigid (Q)
Table Variability Attribute - Variable (Q)
NENT(Q)
NWDSEN (Q)
Structure String
Structure GROUP (I)
Structure SET (I)
c)
Dynamic Allocation of Data (I)
Function Module: Referencing Data
BIT (Q)
BYTE (Q)
CHAR/MA NT (Q)
Subscripting
Subscripting Expressed as Complex Numeric Formula (Q)
Nested Subscripting (Q)
Table Entry Referencing (ENTRY/ENT) (Q)
Table Entry Referencing Notation - ENT (Q)
Function Module: Representing Data in the Standard JOVIAL J3 Memory
Computer Representation of Data (Q)
Importance of Storage Allocation Facilities (I)
Importance of Machine Independence (I)
Memory "Model" (Q)
Signed Magnitude Representation of Numbers (I)
Octal Constant (Q)
Hexadecimal Constants (I)
Basic Table Structure Attribute - Parallel (Q)
Basic Table Structure Attribute - Serial (Q)
Generalized Packing (I)
Ordinary (Table) Packing - Medium and/or Dense (Q)
Ordinary Packing - Medium (Q)
Ordinary Packing - Dense (Q)
"No Packing" Notation - " N" (Q)
(4)
(5)
(6)
(7)
(8)
•
Defined (Table) Packing (Q)
•
Independent Overlay Declaration (Q)
•
Subordinate Overlay Declaration (Q)
•
'LOC (Q, I)
•
Absolute addresses (OVERLAY, PROGRAM)
(I)
Function Module: Numeric Items and Arithmetic Operations
•
Item Type Integer (Q)
•
Item Type Fixed Point (Q)
•
Item Type Fixed Point
Scale in Declaration Blank or Zero (Q)
•
Range Attribute (Q)
•
Item Type Floating Point (Q)
•
Sign Attribute (Signed and Unsigned) (Q)
•
Double Precision
(also called Extended Precision) (I)
•
Parenthesized Numeric Formulas (Q)
•
Mixed Item Types in Numeric Formulas (Q)
•
Prefix + and - (Q)
•
Precedence of Prefix + and - (I)
•
Exponentiation Operator (Q)
•
Exponentiation Notation - ( * * ) (Q)
•
Absolute Value Operator (Q)
•
Absolute Value Notation - (//) (Q)
•
REM (Q)
•
REMQUO (Q)
Function Module: Dual Items and Dual Arithmetic Operations
•
Item Type Dual (Q)
•
Dual Arithmetic Operations (Q)
•
Structure Operators - Arrays, Tables (I)
•
Structure Operator - Matrix (I)
•
Structure Operator - Complex (I)
Function Module: Testing Operations
•
Hollerith Comparisons (I)
•
Relational Formulas (excluding chained) (Q)
•
"Chained" Relational Formulas (Q)
•
ODD (I)
Function Module: Boolean Items and Logical Operators AND, OR, and
NOT
•
Boolean Formulas-with AND, OR, NOT (Q)
•
Boolean Items (Q)
Function Module: Assignment
•
Numeric Item Type Conversion in Assignment Statements (Q)
•
Rounded Numeric Assignment (I)
(9)
Round Attribute (Q)
Boolean Assignment Statement (Q)
Item Preset (Q)
Array Preset (Q)
String Preset (Q)
Exchange Statement (Q)
Function Module: Program Structure and Execution of Program Structure
a)
Parallel Processing (I)
b)
Compound Statement (Q)
c)
GOTO Statement (Q)
d)
Stopping and Pausing
STOP (Q)
STOP (Modification) (I)
STOP Statement'label (Pausing) (Q)
Pausing (I)
e)
Conditional Transfer of Control
IF Statement (Q)
IFEITH/ORIF (Q)
Index Switch (Q)
Item Switch (Q)
Label Items (I)
Switch Names within Switch Declarations (Q)
Close Names within Switch Declarations (Q)
Parallel "Monitoring" (I)
f)
FOR Statements (Iteration)
FOR Loop - One Factor (Q)
FOR Loop - Two Factor (Q)
FOR Loop - Three Factor (Q)
FOR Loop - Decrementing (Q)
Test Statement (Q)
g)
Closed Subprograms and their Execution
Program (Q)
Procedure (Excluding Function) (Q)
Alternate Procedure Entrances (Q)
Close in Parameter List (Q)
Statement Label in Parameter List (Q)
Function (Q)
Close (Q)
Closed Subprogram (Delete Close in Favor of Proc?) (I)
Return Statement (Q)
'PROGRAM Declaration (Q)
Recursive Subprograms (I)
h)
Direct Code (Q)
(10)
(11)
(12)
1 .3
Function Module: Input/Output
Structure File
Structure File — Hollerith or Binary (Q)
Structure File — Record Length Variability (Q)
Input/Output - POS (Q)
Input/Output - OPEN Statement with Operand (Q)
Input/Output - OPEN Statement without Operand (Q)
Input/Output - SHUT Statement with Operand (Q)
Input/Output - SHUT Statement without Operand (Q)
Input/Output - Input Statement (Q)
Input/Output - Output Statement (Q)
Stream Oriented I/O (I)
Functional Files (I)
Device Oriented I/O (I)
Functiion Module: Naming Data and Program Structures
Proc-•like Name Scopes (I)
Multiple Statement Labels (Q)
Defini on Facilities
Define Directive (Q)
Extended Define Directive (I)
Mode Directive (Q)
Extended Mode Directive (I)
Like Table Declaration (Q)
Macro Facilities (I)
Method of Analysis
This subsection describes the philosophy of language and language standardization
which is central to the methods of this analysis. In addition, the method of analysis
of the JOVIAL Application Questionnaire and Interview Responses is described.
1.3.1
Philosophy of Languages and Language Standardization
Very briefly, a
structure of the
both
•
a
•
a
language is a notational system with a community of users. The
language "sentences" and the meanings associated with them reflect
set of problems shared by members of the community, and
set of tools which make the problems tractable.
To standardize a language means to determine the problems faced by all, or a
substantial subset, of the members of the community and to obtain a consensus as to
the tools to be employed in solving the common problems. Clearly, a language
standard should not support tools designed for coping with problems peculiar to a
small subcommunity nor should the standard support a variety of different sets of
tools designed to handle the same set of common problems. The importance of
standardizing a language lies in the fact that more efficient communication of
problems and problem solution will, in general, ensue. Standardization creates a
common frame of reference for the members of the community of users.
The language which is the object of this study is, of course, the JOVIAL J3 dialect
of JOVIAL specified in AFM 100-24. The community of users consists of all those
applications personnel who are employing JOVIAL in computerized command and
control systems. The problem solving tools are the JOVIAL language features
themselves and, equally important, sets of features which in this document are referred
to as function modules. It is felt that evaluation of individual features in an isolated
fashion is insufficient because many related features, or tools, are generally brought
to bear in concert to solve command and control problems. Thus, the significance of
fixed point items, say, can be meaningfully understood only in the context of the other
numeric items (integer and floating point), since the numeric items are functionally
connected.
Similarly, the significance of numeric items can be better understood when examined
in the context of arithmetic operations. "Numeric Items and Arithmetic Operations"
constitute a subsystem of individual JOVIAL features which address the general problem
of representing numeric entities and doing arithmetic with them. This study then relies
heavily on the concept of problem solving subsystems, or function modules, to clarify
command and control programming processes and to aid in the evaluation of individual
features.
The analysis techniques employed in the evaluation of the JOVIAL language resulted
in the partitioning of the JOVIAL features into three subsets:
•
•
•
A Nucleus subset which includes features used to deal with the
problems faced by a substantial majority of the members of the
community,
An Optional subset which includes the features used to deal with
the problems faced by a significant number of members of the community,
and a
Deleted subset consisting of those features which are used infrequently
or not at all by all but a very few members of the community.
It is our intention that all implementations of Standard JOVIAL J3 contain the
features of the Nucleus subset; that implementors select all or none of the features
in the Optional subset — depending on their requirements; that no implementation
of Standard JOVIAL J3 contain any of the Deleted subset features.
The technique used to determine if a feature is to be in the Nucleus, Optional, or
Deleted subsets is called the "resolution". Concepts may be thought of as placed in
Nucleus or Optional concept subsets. Features — explicit language facilities —
are then placed accordingly in the Nucleus or Optional feature subset. The word
"resolution" will be used to describe the process of disposition of concepts as well
as features. With respect to both JAQ and interview response analysis, retention
as nucleus will be recommended if two thirds or more of the (effective) respondents
show a high degree of appreciation for the feature/concept; retention as optional will
be recommended if fewer than two thirds but not fewer than one third show a high
degree of appreciation. "High degree of appreciation" is defined separately for
JAQ and Interview Analysis.
1.3.2
Method of Analysis of JAQ Responses
The Standard JOVIAL J3 features about which information was collected in the
JAQ's has been divided into two classes:
•
Class 1
the features in this class have been "Accepted as
nucleus" features a priori; they are deemed so
important that retention without question is recommended
and they are automatically placed in the Nucleus feature
subset.
•
Class 2
the features in this class are all those features not
in Class 1 . Their placement in the Nucleus, Optional,
or Deleted subsets must be determined on the basis of
the JAQ responses.
In almost every case, the function performed by a Class 2 feature can be performed
by one or more Class 1 features. The resolution of each Class 2 feature is performed
using a cost-effectiveness technique based upon a "usage rate", or resolution equation,
and comparison of the usage rate with a "usage rate threshold". It should be noted
that a distinct usage rate and usage rate threshold have been defined for all of the
Class 2 features considered in the study. The usage rate is either the number of
times the feature was reported used in the JAQ or it is a function of this number.
In most cases the function is a simple ratio with the number of uses appearing as the
numerator. Ratios of this kind serve to measure the fraction of times a feature was
used, where it could have been used to satisfy a certain application requirement. For
example, in those cases where some "recurrent" data structure is required to fulfill
an application requirement, the utility of using tables, given that both tables and arrays
will satisfy this requirement, may be measured by the usage rate,
N(TABLES)
N(TABLES) + N(ARRAYS)
Q78
Q78 + Q74
where
N(TABLES) represents the number of occurences of a TABLE
declaration in an application as contained in JAQ question Q78, and
N(ARRAYS) represents the number of occurences of an ARRAY
declaration in an application as contained in JAQ question Q74.
If the usage rate for tables, when evaluated with JAQ response data for a specific
application, is greater than one half, say, we infer that the application programmers
find their "recurrent" data structure problems more readily tractable in terms of tables
than arrays in more than one half of the instances in which a recurrent data structure
is required. Two facts regarding usage rate evaluation must be noted.
(1)
(2)
In cases where both the numerator and denominator are 0,
the usage is taken as 0 by convention
Because the JAQ permits usage responses which are estimates
rather than exact counts, such ratios as the one in the example
above may yield values greater than one on evaluation. In such
cases the evaluated usage rate may be thought of as a "preference
indicator".
The usage rate threshold is a number against which usage rates, evaluated for a
given application, are compared. With respect to a given feature, the usage
rate threshold is constant for each application. If the usage rate for a given
application is greater than or equal to the threshold specified for the feature,
we infer that the application programmers obtain a reasonable degree of utility
(i.e., a high degree of appreciation) from the feature; otherwise, we infer that the
utility gained does not offset the "cost" of the feature. It must be noted that it is
impossible to arrive at precisely accurate thresholds since no accurate means exist
to measure costs and utilities. Indeed, DDI has specified thresholds subjectively, based
upon our own experience with command and control applications and knowledge of the
compilation process. Where we have specified a high threshold, we feel that the cost
outweighs the utility; a low threshold indicates that the utility is worth the cost. Usage
rate thresholds, then, have been arrived at subjectively by weighing the cost of each
Class 2 feature against its effectiveness or utility. Examples of characteristics which
drive up the cost of a feature are:
(1)
(2)
The feature is redundant — its function can be performed by other
(Class 1) features. The redundancy requires a more complex compiler
and more learning (with possibly more errors made) by the programmer.
The feature is context sensitive, introducing certain levels of complexity
into the compilation process (e.g., status constant).
A Class 2 feature is, in general, effective in that it provides a programmer convenience.
Thus the exchange statement
AA = = BB $
is more convenient to the programmer than
TEMP = BB $
BB = AA $
AA = TEMP $
though an expense is incurred in the implementation of the exchange feature.
Because of the subjectivity involved in specifying thresholds, we have deliberately
leaned toward low values for thresholds. The low values of thresholds reflects
an underlying philosophy maintained throughout this study, namely that the error incurred
by accidently deleting or making optional a useful feature was far more serious than the
error of retaining a non-useful features.
The usage rates and thresholds for each feature are given with the response summaries
for the feature in Appendix 2. There, usage rate threshold is denoted by Tl .
1 .3.3
Method of Analysis for Interview Responses
A concept or proposed new feature was retained as nucleus if more than two thirds of the
members of the community responding responded positively. Tht concept or proposed
new feature was retained as optional if there were from one third to two thirds positive
responses and it was deleted if less than one third responded positively. The Interview
Response Analysis may be found in Appendix 4.
10
SECTION
CONCLUSION
This section contains recommendations, based on both the JAQ and Interview
Response Analysis, for alteration of the Standard JOVIAL (J3) language dialect.
The recommendations include a list of JOVIAL language extensions along with
a list of deletions of features currently specified in AFM 100-24. Additionally,
all current and extended features are classified as either Nucleus or Optional . Finally,
this section contains a discussion, in general terms, of our observations on command and
control programming language requirements.
2.1
JOVIAL Language Extensions
2.1 .1
List of Extensions
DDI recommends that the following extensions, described fully in the indicated
subsections of Section 3, be incorporated into the Standard JOVIAL J3 language
as Nucleus or Optional features:
(1)
(2)
(3)
(4)
(5)
(6)
Hexadecimal Constants (3.2.2.1)
(Optional — User may implement hexadecimal, or octal, or
both, but either hexadecimal or octal must be implemented.)
Simplified Hollerith Constant Form (3.2.2.2)
(Optional — Removes the requirement to count the number of
hollerith characters.)
User Definable Character Encoding (3.2.2.3)
('CHARCODE Directive)
(Optional — Provides facility for defining a character set and
encoding scheme for each character in it.)
Operations on Literal Data (3.2.2.4)
(Nucleus — Establishes facility for Hollerith and other Literal
Comparisons as well as conversion between Literal item types on
assignment.)
Computer Representation of Numeric Constants and Variables (3.2.2.5)
(Nucleus — loosens the machine dependent restrictions on representation
of numeric data.)
Precedence of Unary Operators (3.2.2.6)
(Nucleus — Changes the precedence of prefix + and - to next
highest after exponentiation.)
11
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
2.1 .2
2.1.2.1
Extended Define Directive (3.2.2.7)
(Optional — Allows "arguments" to be included with a DEFINE
identifier.)
Extended Mode Directive (3.2.2.8)
(Optional — Allows mode directive to select item description on basis
of first letter of name.)
Alternate Entrances to Procedures and Functions (3.2.2.9)
(Nucleus)
Extended Precision Numeric Items and Constants (3.2.2.10)
(Optional, with hardware — Permits declaration of double precision
floating point numbers.)
Device Oriented Input/Output Module (3.2.2.11.1)
(Optional — Provides framework for commanding and responding
to I/O devices.)
Functional File Input/Output Module (3.2.2.11 .2)
(Optional — Provides framework for functional (("logical")) file
processing.)
Data Editing and Conversion (Formatting) (3.2.2.11 .3)
(Nucleus - - provides FORTRAN-like formatting capability.)
Stop Statement (3.2.2.12)
(Nucleus — Alters the meaning of STOP to suspend processing
wherever executed.)
Pause Statement (3.2.2.13)
(Optional — Provides pausing facility.)
Rounded Assignment Statement (3.2.2.14)
(Optional — Provides the facility for declaring rounding in an
assignment statement, not in the item declaration.)
Extension to Program (3.2.2.15)
(Optional — Allows the ability to declare a procedure as a "standalone" subrouti ne.)
Remarks on Extensions
Input/Output
The proposed (optional) Device Oriented I/O module and Functional File module
are intended to supercede the File Structure and Operators currently specified in
AFM 100-24. The two modules proposed, force a separation of hardware considerations
from function or logical file elements with the intent of providing much greater
flexibility and power than that offered by the current file system of the standard. It
must be pointed out, however, that the Functional File Module is very loose and
therefore highly "participational" in nature. The applications programmer must write
his own set of support programs to do all the real file manipulation work; however,
12
it is anticioated that user installations fix on a standard set of suDport orograms which
would be used by all aoplications programmers. The Functional File Module is loose
for the reason that we are unable at this time to fully identify functional file oroperties,
This was due to the fact that the Inout/OutDut information obtained in the study was
SDarse , and the latter fact may be true because I/O at this level tends to be comolex.
We recommend that this area be studied further, in the light of command and control
aoplications.
The formatting module has been made independent of the other I/O modules, since it
is nucleus, while the others are optional .
2.1.2.2
Overriden Extensions
Certain features and conceDts were well received at interview and should, by all
rights be oroDOsed as either nucleus or optional extensions now. These features and
conceots are:
Item Type Bit String
(Data) Structure GROUP
Structure SET
Dynamic Storage Allocation Facilities
Generalized Packing
Label Item
Recursive Suborograms
Our action — to make no recommendation at this time — is based on arguments
discussed under observations (sub-section 2.5, below) and also on the fact that the
addition of these new structures would result in some complex ramifications which
are unresolved at this time involving currently available structures.
2.2
Deletions
The criteria utilized to determine which JOVIAL features should be deleted is given
in Section 1 (1 .3). Based on these criteria and the data summarized in the JOVIAL
Feature Resolution Analysis contained in Appendix 2 as qualified by the Interview
Resoonse Analysis contained in Appendix 4, Data Dynamics recommends that the
following features be deleted from the JOVIAL Soecifications AFM 100-24.
The number in oarenthesis in the list below is the Aoproach for Change (AFC) reference
number which references the Resolution Analysis of each SDecific feature.
1)
2)
3)
4)
5)
Item Type Standard Transmission Code
Standard Transmission Code Formulas
Structure String
CHAR/MANT
Table Entry Referencing Notation - ENT
(ENTRY only may be used)
13
AFC §
(Al .1.1. 2)
(Al .1.1 2)
(Al .2.5)
(A 2 .3)
(A 2 •6)
AFC'
6)
7)
8)
9)
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2.3
Ordinary Packing - Medium
(Only Dense Packing is allowed)
Ordinary Packing - No packing specified
Subordinate OVERLAY Declaration
Round Numeric Assignment Range Attribute
Exponentiation Notation - (* *)
(Only ** may be used)
Absolute Value Notation (//)
(Only ABS may be used)
REM
REMQUO
Item Type Dual
Dual Formulas
String Preset
Round Attribute
Stop Statement Label
Switch Names within Switch Declarations
Close Names within Switch declarations
Structure File
Structure File - Hollerith or Binary
Structure File - Record Length Variability
Open Statement with Operand
Open Statement without Operand
Shut Statement without Operand
Shut Statement with Operand
Input Statement
Output Statement
7AX47
(A3.4)
(A3.6)
(A4.3)
(A4.6)
(A4.8)
(A4.9)
(A4.9)
(A5)
(A5)
(A8.1)
(A8.2)
(A9.3)
(A9.4.3)
(A9.4.3)
(A10)
(A10)
(A10)
(A10)
(A10)
(A10)
(A10)
(A10)
(A10)
List of Nucleus Features
Based on the criteria and data as indicated in sub-Section 2.2, the features listed
below are recommended for inclusion in the Nucleus. The numbers in parenthesis
reference the AFC number in the JOVIAL feature resolution analysis in Appendix 2
and references to sub-Sections of Section 3.
1)
2)
3)
4)
5)
6)
7)
8)
Item Type Hollerith (Al. 1.1.1)
Hollerith Formula (Al. 1.1.1)
Character Data Size Attribute (Al .1 .1 .3)
Operations on Literal Data (3.2.2.4)
Explicit Size Attribute (Al .1 .3)
Structure Table (Al .2.2)
Table Variability Attribute - Rigid (Al .2.3)
Table Variability Attribute - Variable (Al .2, 3)
14
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
36)
37)
38)
39)
40)
41)
42)
43)
44)
45)
46)
47)
NENT (Al.2.3)
BYTE (A2.2)
Subscripting - Expressed as Complex Numeric Formula (A2.4)
Subscripting - Nested (A2.4)
Table Entry Referencing (A2.5)
(ENTRY only may be used)
Computer Representation of Data (A3)
Computer Representation of Numeric Items and Constants (3.2.2.5)
Octal Constants (A3.1, 3.2.2.1)
Hexadecimal Constant (Must implement one or the other,
may implement both)
Basic Table Structure Attribute - Parallel (A3.3)
Basic Table Structure Attribute - Serial (A3.3)
Defined (Table) Packing (A3.5)
Independant Overlay Declaration (A3.6)
'LOC (A3.8)
Parenthesized Numeric Formulas (A4)
Mixed Item Types in Numeric Formulas (A4)
Item Type Integer (A4)
Item Type Fixed Point (A4)
Item Type Fixed Point - Scale in Declaration Blank or Zero (A4)
Item Type Floating Point (A4)
Sign Attribute (A4.4)
Prefix + and - (A4.5)
Precedence of Unary Operators (3.2.2.6)
(Alteration of precedence of +, -)
Exponentiation Operator (A4.5)
(Notation ** only)
Relational Formulas (excluding chained) (A6.1)
Boolean Formulas - with AND, OR, NOT (A7.1)
Item Type Boolean (A7.2)
Numeric Item Type Conversion in the Assignment Statement (A8)
Boolean Assignment Statement (A8)
Item Preset (A8.1)
Table Preset (A8.1)
Compc jnd Statement
GOTO Statement (A9.2)
STOP Statement (A9.3, 3.2.2.12)
IF Statement (A9.4.1)
FOR-loop-One Factor (A9.5)
FOR-loop-Two Factor (A9.5)
FOR-loop-Three Factor (A9.5)
FOR-loop-Decrementing (A9.5)
Test Statement (A9.5.4)
15
48)
49)
50)
51)
52)
53)
54)
55)
56)
57)
58)
2.4
Program (A9.6, A9.7)
Procedure (Excluding Function) (A9.6.1)
Function (A9.6.1)
Alternate Entrances to Procedures and Functions (3.2.2.9)
CLOSE (A9.6.2)
Return Statement (A9.6.3)
Direct Code (A9.8)
Data Editing and Conversion (3.2.2.11 .3)
Multiple Statement Labels (Al 1 .2)
ALL (A 12.5)
COMPOOL (A12.6)
List of Optional Features
Based on the criteria and data as indicated in sub-section 2.2, the following features
are recommended to be included as optional features:
1)
2)
3)
4)
5)
6)
7)
8)
9)
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Hexidecimal Constants (3.2.2.1)
Simplified Hollerith Constant Form (3.2.2.2)
User Definable Character Encoding Scheme ('CHARCODE) (3.2.2.3)
Item Type Status (Al .1 .2)
\
Status Formulas (Al .1 .2)
> (Must be implemented together)
Explicit Status Size Attribute (Al .1 .3) )
Structure Array (Al.2.1)
NWDSEN(A1.2.4)
BIT (A2.1)
Ordinary Packing (Dense only is allowed) (A3.4)
Absolute Value Operator (ABS only is allowed) (A4.7)
Extended Precision Numeric Items and Constants (3.2.2.10)
Chained Relational Formulas (A6.2)
Array Preset (A8.1)
Exchange Statement (A8.3)
IFEITH/ORIF Statements (A9.4.2)
Index Switch (A9.4.3)
Item Switch (A9.4.4)
CLOSE in Parameter List (of Procedure) (A9.6.1)
Statement Label in Parameter List (of Procedure) (A9.6.1)
'PROGRAM Declaration (A9.7)
Item Declaration (Al 1.1)
Define Directive (A12.1)
Extended Define Directive (3.2.2.7)
MODE Directive (A12.2)
Extended MODE Directive (A12.2, 3.2.2.8)
Like Table Declaration (A12.4)
16
28)
29)
30)
31)
Device oriented I nput/Output Module (3.2.2.11.1)
Functional File Input/Output Module (3.2.2.11.2)
Pause Statement (3.2.2.13)
Extension to Program ("Stand-alone" procedure) (3.2.2.15)
2.5
Observations
2.5.1
Array
The only feature accepted as nucleus originally in the Approach for Change which did not
find reasonable user support was the Array. We have therefore made Array an optional
feature. Users found Table far more useful.
2.5.2
Data Structures
Interview responses regarding proposed new data structures (GROUP, SET, etc.) together
with the heavy use of Tables inclined us toward the belief that command and control
programmers require the ability to manipulate highly complex data structures. We feel
that it is unwise to simply pile on new structures at this point. Rather, we believe, the
command and control language should contain structure building primitive operators
which would allow for the definition and creation, either at compile time or execution
time, of a wide variety of complex structures, these structures taking a form specified
by the applications programmer. We are not currently able to identify these primitives
but feel that the task of such identification should be pursued.
2.5.3
Resource Allocation
Because of the enthusiasm of interviewees for packing capabilities, and the proposed
generalized packing, it has become clear that the command and control programmer
requires the ability to manage the memory space resouces available to him. We note
the remark of ADPAC, requesting a special "fast-executing" subset of JOVIAL for
real time application, and conclude that management of execution time resources is
probably important as well. We feel that a command and control language should
probably have even more resource management facilities than JOVIAL and that these
should be connected with ease to the data structure building primitives described
in sub-section 2.5.2.
17
SECTION
EXTENSION SPECIFICATIONS
3.1
General
This section contains a complete description of the deletions, modifications, and
additions to the JOVIAL J3 language as specified in AFM 100-24 resulting from the
analysis phase of this project. In addition, the section contains a complete list of
all recommended nucleus and optional features along with a cross reference of each
feature to the appropriate section in the "JOVIAL Application Questionnaire" and
the "Approach Fcr Change" documents.
During this project many JOVIAL language requirements evolved which DDI was
unable within the scope of the project to investigate in detail. An example of
such a requirement includes language features which would allow constructing new
types of data structures and allocating these structures and computer programs in
terms of a specified optimizalion of time and space. Other examples as included
in Section 4 below, such as including real time concepts and list processing
capabilities, were also not within the scope of the project. However, considering
these limitations, DDI is confident that JOVIAL Extention Specifications, described
in this section, is a significant improvement over the current JOVIAL J3 (AFM 100-24)
Specifications.
3.2
Recommendations
The following are DDI's recommendations for modifications to JOVIAL Specifications
as contained in AFM 100-24.
3.2.1
Deletions
The following features are recommended for deletion from the JOVIAL Language. The
criteria used for deletion of these features is described in Section 1 and the specific
resolution analysis of each feature is contained in Appendix 2. The references for each
feature is to the sub-section relating to the feature in the JOVIAL Application Questionnaire
(JAQ) and to the Approach For Change (AFC) documents. As the JOVIAL Feature Resolution
Analysis in Appendix 2 is organized by AFC numbers, the referenced AFC can be utilized
to find the specific resolution or justification for deletion of each of the following features:
Features
1)
2)
Item Type Standard Transmission Code
Standard Transmission Code Formulas
19
JAQ
AFC
J3.5.1.1 1.2
J3.5.2.5
Al.1.1.2
Al .1 .1 .2
Features
3)
4)
5)
6)
7)
8)
9)
11
12
13
14
15
16
17)
18
19
20
21
22
23
24
25
26
27
28
29
JAC*
Structure String
CHAR/MA NT
Table Entry Referencing Notation-ENT
(ENTRY only may be used)
Ordinary Packing - Medium
(Only Dense Packing is allowed)
Ordinary Packing - No packing specified
Subordinate OVERLAY Declaration
Range Attribute
Exponentiation Notation - (* *)
(Only * * may be used)
Absolute Value Notation (//)
(Only ABS may be used)
REM
REMQUO
Item Type Dual
Dual Formulas
String Preset
Round Numeric Assignment-Round Attribute
Stop Statement Label
Switch Names within Switch Declarations
Close Names within Switch Declarations
Structure File
Structure File - Hollerith or Binary
Structure File - Record Length Variability
Open Statement with Operand
Open Statement without Operand
Shut Statement without Operand
Shut Statement with Operand
Input Statement
Output Statement
AFC'
J3.5.1.4
Al.2.5
J3.5.2.2.2.3-4 A2.3
J3.5.2.2.1
A2.6
J3.5.1.3.6.1
A3.4
J3.5.1.3.6.
J3.5.1.7.2
J3.5.1 .1.8
J3.5.2.3.3
A3.4
A3.6
A4.3
A4.6
J3.5.2.3.4
A4.8
J3.5.4.9
J3.5.4.7
J3.5.1.1.7
J3.5.2.4
J3.5.1.6.4
J3.5.1.1.10
J3.5.5.7
J3.5.5.2
J3.5.5.2
J3.5.1 .5
J3.5.1.5
J3.5.1.5
J3.5.3.3
J3.5.3.3
J3.5.3.3
A4.9
A4.9
jo.o.o.o.
J3.5.3.3
J3.5.3.3
A5
A5
A8.1
A8.2
A9.3
A9.4.3
A9.4.3
A10
A10
A10
A10
A10
A10
A10
A10
A10
3.2.2 Additions and Modifications
3.2.2.1
Hexadecimal Constants
For some computers, the specification of address or "bit pattern" information is more
conveniently expressed by use of the hexadecimal (base 16) number system than by the
octal system. Depending on their needs, implementors may incorporate hexadecimal
constants, octal constants, or both.
20
A hexadecimal:constant is composed of hexadecimal:numerals. A hexadecimal:numeral
is one of the following sixteen JOVIAL numerals or letters:
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F
The correspondence between hexadecimal numerals and bit patterns is:
Hexadecimal Numeral
Bit Pattern
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
A hexadecimal :constant is formed by the letter X, followed by a left parentheses,
followed by a string of hexadecimahnumerals, followed by a right parentheses:
X(string:of:hexadeci ma I: numerals)
Examples of hexadecimahconstants are:
X(777)
X(F)
X(01A9)
X(FAD)
A hexadecimal :constant is represented as a string of bits, equal in length to four times
the number of hexadecimahnumerals making up the string:of:hexadecimal:numerals in th e
constant form; four bit groups making up the bit string correspond to and have the same
ordering as the hexadecimal:numerals making up the hexadecimal:constant as shown in the
table above.
21
Hexadecimal:constants may be used in the same places as octal constants and have
corresponding meanings. More specifically: Hexadecimal:constants rrcy be used in
machine address specifications (as in OVERLAY), preset specifications in numeric:
or litcrahitem, array:/ or table :ite redeclarations, and in literal assignment statements.
3.2.2.2
Simplified:Hollerith:Constant Form
A hoi lerith constant is either a regular:hollerith:constant or a simplif?ed:hollerith:
constant. A regular:hollerith:constant has the form number H(string:of:hollerith:
characters) (see CED 2418, AFM 100-24 under hollerithconstant). A simplified:
hollerith:constant has the form
H(string:of:hol lerith characters)
with the restrictions on the string:of:hollerith:characters that, in scanning from left to
right through string, the number of r?ght:parentheses encountered at any given position
must never exceed the number of I eft: parentheses encountered, and the total number of
left-parentheses included in the string must equal the total number of right:parentheses.
Examples of simpl if ?ed:hol lerith constants are
H(NO MORE COUNTING WITH MOST HOLLERITH CONSTANTS)
and
H(NO MORE COUNTING WITH (MOST) HOLLERITH CONSTANTS)
3.2.2.3
User Definable Character Encoding ('CHARCODE)
This facility allows the programmer to define a variety of character sets and encoding
schemes, and is a compiler directive in the sense of the JOVIAL MODE and DEFINE
features. A 'CHARCODE directive shows a correspondence between each member of
a user selected set of characters and a user determined "bit pattern" memory representation
for that character.
The set of all characters from which the programmer may choose in building a
character set/encoding scheme contains at least the JOVIAL signs, and possibly
some implementation dependent characters as well; additionally this "set of all
characters" has an implementation dependent "bit pattern" memory representation or
encoding scheme. In JOVIAL terminology, this character set/encoding scheme is
referred to by the adjective hoi lerith.
22
It is anticipated that the two major uses for 'CHARCODE will be
•
•
to provide a means for interfacing with many kinds of I/O devices
(each of which may have different bit pattern representations for a
character set), and
to permit the specification of user defined collating sequences.
A charcode:direct?ve is:
'CHARCODE 9* charcode :letter 0 fill character 6
BEGIN 0 char:code:correspondence:list 6 END 0 $
Chorcode:letter means any of the letters excluding I, A, F, H, B, S, O, X, or V;
char:code:coiTespondenee:list means either: Char:code:correspondenee or char:code:
correspondenee:Iist 9; char:code correspondence means:
Hollerith:character 0 = 0 hex:or:octal:constant
hex:or:octal:constant means an octal constant, if the implementation supports octal:
constants, hexadecimal:constant if the implementation supports hexa:decimalconstants,
or either if the implementation supports both octal and hexadecimal. Fill character
and holler?th:character are single hollerith characters expressed as hollerith:constants one
character in length. The meaning of fill:character will be explained in connection with
l?teralxiss?gnment:statements and literal comparisons in sub-section 3.2.2.4. It is
required that fill character appear in the char :code correspondence: I ist.
The charcode:direct?ve serves to define a new item type with a name "abbreviation"
specified by charcode:letter, in the same sense that "H" is the (built-in) literal.-item
type hollerith-! The adjective literal will henceforth be applied to items, constants,
arrays, etc., for which either the adjective hollerith applies, or where the data involved
are defined with respect to a charcode:directive.
While a charcodedirective is active, it is possible both to declare items and to express
constants for the literal:item type defined by that charcode:directive. ltem:declarations
and constants for literahitem types defined by charcode:directives are formed precisely
as hollerith:item:declarations and constants, except that "H" in such declarations and
constants is replaced by charcode:letter; also the string of characters appearing in such
constants must be made up only of those characters which appear in the directive.
"0 means that a space is required or permitted.
23
Regarding the computer memory representation of charcode defined character sets,
these character set are represented in byte strings in the same manner as Hollerith
characters, each byte being t*i bits in length (see AFM 100-24, Figure 24-1 and
CED 2419.6). Further, the encoding of characters within bytes is, of course, as
specified in the charcode:directive.
Regarding the char;code;correspondence;li5t;
•
•
•
A given hollerith character may appear once and only once in any
charcode:directive.
A given hexadecimal or octal encoding may appear once and only
once in any charcode :directive«
If a hex:or:octal:constant has a size (number of bits in length)
greater than the implementation specific u> bits per byte, only the
rightmost bits of the byte are used to define the encoding; if the size
is less than t*> , as many bits with value 0 are added to the left to
make a bit pattern u> in length.
Regarding the scope of a charcode:directive: The effect begins at that point in the
source code where the directive appears and terminates at the TERM statement or at
the next charcode:directive with the same charcoae:letter, whichever comes first.
An example of a charcodeidirective will be given in which Standard Transmissam Code
is defined in terms of hollerith:
•CHARCODE
BEGIN
T
1H(
)
1H( ) = 0(0), 1H(A)=0(6),
1H(B)= Q{7), lH(C) = O(10),
1H(D) = 0(11), 1H(E)=0(12),
1H(F) = 0(13), 1H(G)=0(14),
1H(H) = 0(15), 1H(.I) = 0(16),
1H(J) = 0(17), lH(K) = O(20),
1H(L) = 0(21), 1H(M) = 0(22),
1H(N) = 0(23), 1H(0) = 0(24),
1H(P) = 0(25), 1H(Q) = 0(26),
1H(R) = 0(27), lH(S) = O(30),
1H(T) = 0(31), 1H(U) = 0(32),
1H(V)=0(33), 1H(W) = 0(34),
1H(X) =0(35), 1H(Y) = 0(36),
1H(Z) = 0(37), 1 H()) = 0(40),
1H(-)=0(41),
lH(+) = 0(42), 1H(=) = 0(44),
1H($) = 0(47), lH(*) = O(50),
lH(0 = O(51), 1H(,)=0(56),
24
1H(0)
1H(2)
1H(4)
1H(6)
lH(8)
1H(')
1H(.)
= 0(60), 1H (1) = 0(61),
= 0(62), 1H(3) = 0(63),
= 0(64), 1H(5) = 0(65),
= 0(66), 1H(7) = 0(67),
= O(70), 1H(9) = 0(71),
= 0(72), lH(/) = 0(74),
= 0(75) END $
The above example shows how a chare ode: directive may be used to define a
"standardized" character set and encoding scheme for interchange between both
human and mechanical processors — another example might have shown a definition
for the ASCII code. The following brief example shows a charcode:directive for
defining an "inverted" collating sequence for the digits 0 through 9:
'CHARCODE
BEGIN
Q
1 H(0)
1H(0) = O(ll), 1H(1) = 0(10),
1H(2) = 0(7), 1H(3) = 0(6),
1H(4)=0(5), 1H(5) = 0(4),
1H(6) = 0(3), 1H(7) = 0(2),
1H(8) = 0(1), 1H(9) = 0(0) END $
3.2.2.4
Operations on Literal Data
3.2.2.4.1
Literal :Assign me nt Statements
Literal:assignment:statements have the form:
literal:variable
6 = 8 literal:formula
0
$
where literal:formula is either a literal :variable, a literahconstant, a literal function,
an octal:constant or a hexadeci mal :constant. Note that a literal:variable or a literaiT
constant means either a hollerith:variable or hollerith:constant or a variable or constant
defined with respect to a charcode:directive .
If, in a literal :assignment:statement, both l?teral:variable and the evaluated literal:
formula have the same length, the following facts apply:
•
•
No conversion of one literal:item type to another takes place if
literahvariable and literal :formula are either both hollerith or both
defined with respect to the same ch~arcode:directive, or if literal:formula
is a hexadecimal:constant or an octahconstant.
Otherwise, a conversion takes place, byte by byte, according to the
one or more charcode directives which may be involved.
25
A literahformula byte is converted to a literal:variable byte in the following way:
First, it is determined if the bit string content of the literal :formula byte is a member
of the bit string set of the encoding scheme associated with the literahformula. If not,
the corresponding literal:var?able byte is filled with the bit string representation of
the filhcharacter associated with the literal: variable. If the bit string content of the
literahformula byte is a member of the encoding scheme associated with the literal:
formula, it is determined if the character from the character set associated with the
literahformula which correspondes to this bit string is also a member of the character
set associated with the literal:variable. If so, the literahvariable byte is filled
with that bit string from the encoding scheme associated with the literahvariable which
corresponds to this character. If not, the literahvariable byte is filled with the
fill character bit string associated with the literahvariable. Note that, by definition,
the filhcharacter associated with the hollerith character set/encoding scheme is a space,
If, in l?terahassignment:statements, a literahvariable is shorter than the evaluated
literahformula, excess bytes are truncated starting at the left for the purposes of
assignment. (Conversions are made as required.) If, in literahassignment:statements,
literahvariable is longer than the evaluated literahformula, excess bytes of literal:
variable are filled with the filhcharacter associated with the literahvariable.
(Conversions are then made, as required.)
Note that in procedure:calI.-statements, assignments of literahformulas used as
actuahinput:parameters to formahinpuhparameters takes place according to the
above rules, as do assignments of literahformulas to actuahoutpuhparameters.
3.2.2.4.2
Literal Comparisons
Comparisons of literal data are effected by means of literahrelationahformjlas of the
form:
literahformula
0
relational :operator
6
literahformula
(Note that "chained" relational formulas may also be used — the description above
is used for simplicity and applies to the chained case by extension.)
When a literahrelationahformula is evaluated, first the literahformulas are evaluated.
Then, if one of the literahformulas is of a literal type different from the other, both are
converted to hollerith character strings, and the literahrelationahformula is evaluated by
comparing the hollerith strings. Otherwise, no conversion is made. (No conversion takes
place if either literahformula is an octal: or a hexadecimal:constant.) The literahformulas
so evaluated are compared, in effect, byte by byte from left to right. This is not meant
to imply that implementations are required to perform actual byte by byte comparisons,
but a given implementation's means of comparison must yield the same result'.
26
One byte is
equal to
j less than
greater than
bit pattern of the first byte is
another byte according as the
equal to
less than
greater than
the bit pattern of
the second byte, where both bit patterns are treated as unsigned:integers, ...o
bits in length.
Two literal:formulas of the same length are compared from left to right, a byte
at a time. The two formulas are equal if all bytes are equal . Otherwise, the
literahformula on the left of the relational:operator is i less than
\)
the
an
I greate r than f
literal :formula on the right of the relational roperator, if the byte by byte comparison
finds at some byte position, that a byte in the left literahformula is ( less than
) the
(.greater than >
corresponding byte in the right literahformula.
If the two literahformulas are of differing lengths, the following rules apply:
•
•
If the shorter literahformula is an octahconstant or hexadecimahconstant,
it is made to be the same size as the larger by adding the appropriate
number of zero bits at the left of the shorter literahformula.
If the shorter literahformula is not an octahconstant or a hexadecimal:
constant it is made to be the same size as the larger by adding one or more
fill characters of the associated character set/encoding scheme at the
left of the shorter literahformula.
Once the two literahformulas are made the same size, they are compared according
to the scheme described above for literahformulas of the same length. When evaluated,
a literahrelationahformula yields the value "true" if and only if the relationahoperator is
EQ
NQ
LS
. s~
LQ
GR
GQ
, .
....
and the comparison
yields
r
'
equal to
less than, greater than
less than
.
.
.
equal to, less than
greater than
equal to, greater than
Otherwise, the literahrelationahformula yields the value "false".
3.2.2.4.3
Byte
When BYTE operates on a named:literahvariable a literahvariable is produced with the
same type as the named:literahvariable operand. If the named:literahvariable is of type
Hollerith, so is the BYTE literal:var!able . If the namedrliteral :variable is of a
type declared in a charcodedirective, the BYTE literal:variable is of the same type.
3.2.2.5
Computer Representation of Numeric Constants and Variables
The functional characteristics of all manipulations involving numeric constants and
variables are described in terms of a signed magnitude representation. The implementor's
representation need not be signed magnitude, but the implementor's representation
should, in essence, cause the program and the computer to impinge upon the environment
in the same way as would occur if the actual representation were signed magnitude.
However, it is recognized that it is infeasible in practice to ensure a signed magnitude
equivalent effect in all areas. For example, an implementor using a one's complement
fixed point representation may decide that the cost of guaranteeing that
BIT($1,5$) (ALPHA)
will produce the magnitude of the integer ALPHA as declared by
ITEM ALPHA I
6 S
$
is not warranted by the compatability which would be gained Implementors, then, may
depart from a total signed magnitude simulation, but in doing so must publish warnings
where these departures are concerned.
3.2.2.6
Precedence of the Unary Operators
The precedences of the arithmetic:operators in the evaluation of a numericrformula,
from highest to lowest will be changed as follows:
Current
New
Unary**
**
Unary -
V
V
+-
+ -
Note that this means that -x**2 = -4 when x = 2 not + 4.
The precedences
of the arithmetic:operators complies with the conventions of algebra.
3.2.2.7
Extended:define:directive
This facility extends the capability of the define:directive in that it allows the
programmer to include a parameter list with the defined name.
28
3.2.2.7.1
Form of the Extended:define:directive
An extended:define:directive means either:
DEFINE
0
name
0
"symbols"
0
$
DEFINE
0
name
0 (0 formal:define:parameter:list 0) 0 "symbol" 0 $
or
A formal :def?ne:parameter:list is either a forma I: define: para meter or a formal: define:
parameter:!ist 0 , 0 formal:define:parameter. A formal :define:parameter is a name.
Symbols denotes a string of one or more of the JOVIAL symbols and space or spaces. Note
that two consecutive primes are not allowed in the symbols string; also the last symbol
before the second set of primes must not be a prime.
Note that no comment may appear in the extended:def?nedirective between the right:
parenthesis and the first " . The names making up the formal:define:parameter:list must be
unique within the formal: define: para meter: I ist but may appear anywhere else in the program
in any context whatever.
A name appearing in a formal:define:parameter:list serves no other purpose than to
define an argument for the extended:define:direct?ve. Formal:define:parameter:!ist
names may each appear any number of times (or not at all) inside the quoted string of
symbols appearing with the formal:def?ne:parameter:!ist in the extended:define:directive.
3.2.2.7.2
Scope of the Definition
The scope of the definition of an extended:define:directive begins at that point in the
source text where it occurs and ends at the end of the program (TERM) or at some subsequent
point where another extended:define:directive with the same defined:name occurs, or where
a define:directive with the same defined:name occurs. Note that the scope of a define:
directive terminates at a subsequent point in the program where an extended:def?ne:d?rect?ve
for the same name occurs.
3.2.2.7.3
Extended:define invocation
An extended:define:invocation has the form
defined:name 0 (0 actual:defined:parameter:list 0)
or
defined:name 0 (0)
29
and may appear anywhere within the scope of the extended:define:directive with
which defined:name is associated except within another extended:define:directive.
Note that the extended:define:invocation is not recognized as such when it appears
within a status:constant, a cerement, or literaltconstant.
An actual :define;parameter:list is actual :define:parameter or, actual :define:parameter:list
0 , 9 actual :define:parameter.
An actual :define:parameter is "symbols".
Symbols denotes a string of one or more of the JOVIAL symbols and space or spaces.
Note that two consecutive primes are not allowed in the symbols string; also the last
sign before the second set of primes must not be a prime.
If the actual:formal:parameter:l?st contains a larger number of actual;define:parameters
than there are formal;define:parameters in the formal:define:parameter:list, the right
most excess actual:define:parameters are ignored. If the number of formal:define:
parameters exceeds the number of actual :define:parameters, the right most missing
actual :define: para meters are assumed to be "space". In either case a warning to the
programmer will be generated.
The effect produced by an extended:define:invocation is as follows:
1)
2)
3)
A copy of the quoted symbol string associated with the extended:
define:directive is made,
Each formal:define:parameter appearing in the copy is replaced with
the symbols of its correspondent actual:define:parameter, and
The extendedrdefine:invocation is replaced by the expanded copy.
At this point the compiler will process the expanded copy at its leftmost space, spaces,
or symbol in exactly the same way as if it were part of the source text being input from
the source text input unit. A name which followed DEFINE in a (currently active)
define:directive which now appears in the expanded copy is treated at the time it is
encountered in exactly the same manner as it would be treated had it appeared in the
source text input stream. The same is true for extended:define:invocations, define:
directives, and extended:definedirectives which may have appeared in the expanded
copy.
Note that names appearing after DEFINE in a define:directive, extended:define:
invocations, define:directives, and extended:define:directives may appear in the
expanded copy produced by an extended:definedirective" A~s~with the use of a define:
directive, the use of an extended:definedirective must not result in circular definitions.
30
Note that the symbols making up an actual:define:parameter, as well as the symbols
in the symbols string of an extended:definedirective, may contain names which appeared
after DEFINE in a (currently active) definerdirective, or definerdirectives, or extended:
define:directives, or extended:define:invocations. These names, directives, or invocations
are treated simply as symbols in this context and do not produce replacements or expanded
copies until after the expanded copies replace the extended:define:invocations which
produced them.
Example:
The extended:define:directive
DEFINL AA (XX, YY, ZZ) " BB (S SIN(ZZ), YY,XX$) + XX " S
causes
CC = BETA +AA ("PI", "P2", "P3+P4") $
to be "read" by the compiler as
CC = BETA +
BB ($SIN (P3+P4), P2, PI $)+ PI $
3.2.2.8
Extended Mode Directive
This facility extends the mode:directive of AFM 100-24 in that it allows the
programmer to select an item:description for an undeclared name on the basis of the
first letter of that name. The form of an extended:mode:directive is MODE 9
extended:mode:list 6 $.
An extended:mode:list is
extended:mode:list:element 9,0
extended:mode:list:element
or
extended:mode:list 9, 9 extended:mode:list:element
An extended:mode:list:element is either a letter:mode:specification or a simple:mode:
specification; the latter must appear as an extended:mode:list:element in the extended:
mode:list but it must appear only once.
31
A simple:mode:specification is either itemtdescription or item:description 8 P 8
optional ly:signed:constant.
A letter:mode:specificat?on is letter 6 = 8 simple:mode:specification.
If more than one letter:mode:specif?cation appears as an extended:mode:list:element,
the letters in these letter:mode:specifications must be distinct.
The scope of effect of an extended:mode:directive beings at the place in the source
text where it appears and ends as the end of the program (TERM) or at the next
mode:d?rect?ve or extended:mode:directive. Any name appearing within the scope of
the extended:mode:directive, which has not been formally declared elsewhere is acted
on by the extended:mode:directive in the following ways: If the first letter of the name
matches a letter appearing in one of the letter:mode:specifications, the name is
automatically declared as an item with the associated simple:mode":specification, otherwise,
"free standing" simple:mode:specification.
Note that an extended:modedirective serves to terminate the scope of effect of any
mode:directive which occurred previously in the source text.
Example:
The following extended:modedirective will mode declare all undeclared names in its
scope beginning with I, J, K, L, M, or N as integerritems and all other undeclared
items in its scope as floating.
MODE
I = I 48 S, J = I 48 S, K = I 48 S
L =1 48S,M = I 48 S, N = I 48 S,
F$
The following two examples are equivalent to the extended:mode:directive above:
MODE
F, I =1 48 S, J = l 48 S
K =1 48 S, L = 1 48 S,
M = l 48 S, N = l 48 S $
MODE
I = I 48 S, F, J = I 48 S,
K = I 48 S, L = I 48 S,
M = I 48 S, N = I 48 S $
3.2.2.9
Alternate Entrances to Procedures and Functions
Frequently it is desirable to enter a procedure (or function) at some point other than the
beginning. This facility provides such a capability.
32
3.2.2.9.1
Alternate: Procedure: Entrance: Declaration
An alternate:procedure:entrance:declaration has the form
'ENTRANCE 6 alternate:entrance:name 0 $
or
'ENTRANCE 0 alternate:entrance:name 0
(0 optional:formal:input:parameter:list 0) 0 $
or
1
ENTRANCE 0 alternate:entrance:name 0
(0 optional:formal:?nput:parameter:l?st 0 = 0 formal :output:parameter:
list 0) 0 $
An alternate .-entrance: name is a name.
An alternate:procedure:entrance:declaration is meaningful only if it appears in a
procedure:declaration or a function^eclaration, either in the procedure sheading or
procedure:body of those declarations. (The containing procedureror function:declaration
is called the mastendeclaration.)
As many a I ternate: procedure :entra nee :declarat?ons as desired may be made within
a mastendeclaratiorT!
For each name declared as an alternate entrance by an alternate:procedure:entrance:
declaration, there must be a matching statement:name within the procedure: or function:
body part of the mastendeclaration. The position of this statement:name in the body
defines the point of entry into the body when the procedure or function is invoked by its
alternate:entrance:name.
Any a I ternate: procedure :entra nee declaration must occur prior to its associated
state me nhlabel.
Note that there must not be a statement:name in the body of the master:declarat?on
which is the same as the name defined as a procedure: or function:name of the master:
declaration.
Formal :parameter:names associated with an alternate:procedure:entrance:declaratIon may
appear as formal:parameter:names in the master:declarat?on or in any other alternate":
rocedure:entrance:declaration; formal:input:parameters in any one such declaration may
e formal:output:parameters in any other such declaration, and vice-versa.
I
33
However, as with procedure zdeclarations, names appearing as formal; para meters in any
alternate:procedure:entrance:declaration may be formal:input:parameters or formal;
output:parameters, but not both.
All formal:parameter:names (other than statement or close:names) whether they appear
in the master:declaration or in a I ternate:procedure;entra nee zdeclarations, must appear
in data zdeclarations prior to their first reference in the body of the masterzdeclaration.
Note that, with respect to the mainzprogram, an alternatezentrancezname is a
global Category 3 name. That is, it may only be referenced in an alternatezprocedure:
call or in an alternatezfunctionzcalI and is not regarded as a statementzname.
From within the body of the masterzdeclaration, a statementzname which matches an
alternatezentrancezname is treated as a local statementzname when it appears as a
switchzdesignator or as the object of a GOTO.
(Note that a I ternatezprocedurezentra nee zdeclarations can be embedded in function:
declarations as well as procedurezdeclarations.)
3.2.2.9.2
Alternate Procedure Calls
The form of an alternatezprocedurezcall is precisely like that of a procedure zeal I,
and the same restrictions as to the matching of number, position, and type of
formalzparameters with actualzparameters apply. Prior to entry, actualzinputzparameters
are evaluated as required and bound to formalzinputzparameters. Then, control is passed
to the associated statementzname within the body of masterzdeclaration.
At this p )int, execution takes place in exactly the same manner as occurs when a procedure
with no a I ternatezprocedurezentra nee zdeclarations embedded in its declaration is invoked.
If the flow of execution causes reference to be made to a formal zpara meter which is not
a formal zpara meter of the al ternatezprocedurezentra nee zdeclarati on associated with an
alternatezprocedurezcall, then such a reference is undefined.
On normal exit (exit achieved by other than a direct or indirect transfer to a mainzprogramz
statementzname not an actual zpara meter), forma I zoutput zparameters associated with the
entrance invoked are bound to their actual zoutputzparameters, and control is returned as
it would be from a procedure or a function with no alternatezprocedurezentrancezcalls
embedded in its declaration.
3.2.2.9.3
AI ternatezFunctionzEntra nee z Declaration
An alternatezfunctionzentrancezdeclaration has the same form as an a I te mate: proce du re:
entrancezdeclaration except that no formalzoutputzparameterzlist is allowed; also an item
with the same name as the alternatezfunctionzentrancezname must be declared prior to its first
34
reference. Otherwise, all the rules applying to alternate:procedure:entrance:declarations
apply to alternate:function:entrance:declarations.(Note that alternate:function:entrance:
declarations may be embedded in procedure:declarations as well as function:declarations.)
3.2.2.9.4
Alternate Function Calls
The form of an alternate:function:call has the same form as a function.-call. All remarks
regarding actions initiated by an alternate:function:ca!l parallel the remarks made regarding
alternate:procedure:calls except those involving the binding of output: para meters; exit
in this case results in the "replacing" the alternate:function:call with the value output
as a result of that call.
3.2.2.9.5
Example
PROC CFM (FEET = MILES) $ "CONVERT FEET TO MILES"
ITEM FEET F $
ITEM MILES F $
'ENTRANCE CMF (MILES = FEET) $ "CONVERT MILES TO FEET"
BEGIN
ITEM FEET 'PER* MILE F P 5280.0 $
MILES = FEET/FEET 'PER' MILE $
RETURN $
CMF.
FEET = MILES * FEET 'PER' MILE $
END
3.2.2.10
Extended Precision
Many computers programmed with JOVIAL have "double" precision hardware capabilities.
In Standard J3, no means exist for making use of such capabilities. The feature described
in this paragraph permits specification of an extended precision floatingpoint:item. It is
expected that the great majority of command and control extended precision computational
requirements can be met by an extended precision floatingpoint facility and, therefore, no
extended precision fixed:point or integer capabilities are proposed; further, it is assumed
that the exrad of an extended precision floating:point:number is the same size as the exrad
of an ordinary floating point number.
/> is used to denote the implementation dependent number of bits in the signicand of the
extended precision floating:point:number. cf is used to denote f> -1 . The number of
35
bits per exrad of both ordinary and extended precision floating numbers is represented by
S . The adjective extended:prec?sion will be used to describe extended precision
float!ng;point data and the adjective ordinary will be used to describe floatingpoint data
which are not of extended precision.
Descriptions for all ordinary:floating attributes will be found in AFM 100-24 wherever the
floating adjective is used in that document.
Neither adjective will be used if it is clear from the context which kind of floatingpoint
is meant nor will adjectives be used if it is clear from the context that either or both
kinds are meant.
3.2.2.10.1
Constant Form
The form of an extended:prec?sion:floating:constant is ordinary:floating:constant D.
Examples are:
3.D
3.14159D
.14159D
3.14159E-10D
.14159E-10D
3.E-10D
3.2.2.10.2
Declaring Extended:precis?o.i:float?ng;iterns
Extended:precision:flooting:!terns are declared in item:, array:, and table:
declarations by means of the extended:precision:floating:item:description, the form
which is either
F 6 D
or
F 9 D 9 R
(Where R specifies rounding on assignment to the declared datum.)
3.2.2.10.3
Computer Representation of Extended:Floating Constants and Variables
Extended:precision:f looting constants and extended:floating:items are represented as two
signed numbers. The signicand is represented in /» bits; the exrad in "J bits.
36
3.2.2.10.4
Numeric:formulas and Numeric:assignment
A unary arithmetic:operator (unary minus, absolute value) operating on an extended:
precision floating variable produces an extended: precisi on :f looting result. A binary
arithmetic:operator between two operands, one of which is extended:precision:flooting
produces an intermediate result which is extended:precis?on:floating. Thus, an
extended: precisi on floating result is generated if one operand is ordinary:floating and the
other extended:precision:flooting.
All calculations in extended:precision:floating form are truncated to O" significant
bits unless the statement calls for rounded assignment. Then, each calculation is carried
out to p significant bits and rounded by adding the extra bit into bit u> , discarding the
extra bit, and renormalizing if necessary. The result of the rounding must be to produce
the same effect as ordinary floating rounding requirements, i.e., rounding must either
produce the same value as would be obtained by truncation or else put the value further
from zero.
Necessary conversions between extended floating integer and fixed data are carried
out automatically when these data appear as operands in a numeric:formula or
numeric:assignment statements.
All remarks applying to ordinary floating data in numeric:formulas and numeric:
assignment statements not specifically contradicted by the remarks above apply to
extended:precision:flooting data as well.
3.2.2.10.5
Relational Operations
When a fixed, integer, or ordinary floating operand appears on either side of a
relational :operator and the other operand is extended:precision:flooting, the fixed,
integer or ordinary:floating operand is converted to extended:precision:floating for
the purposes of the comparison.
3.2.2.10.6
Allocation of Extended:precision:floating:items
Simple:extended:precision:floating:items are allocated as many full S bit consecutive
words as are required to contain the items (* + *>f bits. Any remaining bits in the
container are set to zero.
Each element of an extended:prec?sion:floating:array is allocated space in the same
manner as for simpleTextended:precision:floating:items. Extended:precision:flooting:
items which appear in a non-packed ordinary:table are allocated space in the same manner
as si mple:extended:precisi on floating: items. Medium-packed and dense-packed ordinary:
tables may cause extended:precision:floating:items to cross word boundaries. This is true
for defined:entry:tables as well. Parallel structuring of tables may, of course, cause parts
of exte nded: precisi on :f looting: items to be placed in non-consecutive words.
37
3.2.2.11
JOVIAL Input/Output Module
The proposed standard JOVIAL Input/Output MODULE (JIO) consists of four
submodules: A file manipulation submodule (JFILE), a submodule which permits
I/O devices to be controlled by the programmer (JDEV), a formatting submodule
(JFORMAT), and a service routine submodule (JSERVICE). All submodules except
JSERVICE consist of formal language features. JSERVICE is composed of a set of
routines prepared to satisfy the requirements of a specific application by the programmers
of that application.
In the descriptions of the submodules given below, reference is made to processors
called DPEP, PFILE, and PFORM. These processors serve only as an aid in the
description of actions taken by the execution of certain JIO statements; descriptions
of them are not intended to be taken as specifications for subroutines which must be
included in any implementation of the standard.
3.2.2.11.1
JDEV
The features in JDEV consist of:
•
•
•
device procedures
device tprocedu re :execution:statements
a device:procedure execution processor (DPEP)
Devices are external equipments or other processor/memory configurations and are
labeled by unique non-negative numbers. Device procedures are actions or set of
action which devices may be commanded to perform. "Rewinding" and "initiating a
read operation" are examples of device procedures which a tape transport device may
be commanded to perform, for example. The commanding process will be described
subsequently as "assigning a device procedure to a device for execution".
Device procedures are implementation dependent. A given device procedure defined
for a given installation may be assigned to more than one device for execution. "Rewind"
and "initiate read" will typically be executable by all or most tape drive devices in a
particular installation.
Device procedures may have both input and output parameters associated with them
much in the same manner as the ordinary JOVIAL procedures defined by procedure;
declarations.
Note that formal:input:parameters and formal:output:parameters associated with a
device procedure are of the same type as formal:intput:parameters and formaltoutput:
parameters associated with ordinary procedures.
38
A device procedure is assigned to a device for execution by means of a devicerprocedure:
execution:statement the form of which is
'EXECUTE
device:procedure:call
($ devicetnumber $)
optional :completion:call S
A device .-procedure :cal I has exactly the same form as a procecurercall statement
except that the terminating "$" of the procedure:cal Irstatement does not appear;
all rules relating formal: para meters to actual: para meters in a procedure:cal I statement
apply correspondingly to a device:procedure :ca11. A device:procedure:name is a global
Category 1 name. (Category 1, in fact, contains only device:procedure:names.)
Dev?ce:number is a numeric:formula. A complet?on:call is either a close:name or
procedure :ca 11 where procedure :ca 11 takes the form of a procedure :ca 11 statement without
the terminating "$" . All rules relating formal .-parameters to actual :parameters in a
procedure :ca 11 :state me nt apply correspondingly to procedure :cal Is.
DPEP is a mechanism which provides an interface between devices and the execution
of device procedures by means of device:procedure:execution:statements. DPEP must
be able to determine:
•
The status of each device at any time.
The set of device procedures which may be executed by a given
device (This set is in general a subset of the set of all possible device
procedures).
The set of device procedures which may be executed on a device when
any given device procedure is currently being executed by that device.
A device procedure is "currently being executed" from that moment
when step (d), below, is entered until the device signals completion of
execution of the device procedure as indicated in step (g) below. (Note
that it may be possible to execute a device status checking device procedure
ori a device, while the device is executing another device procedure, for
example.) A device is said to be "available" to a device procedure if that
device procedure is a member of such a set as described above; otherwise,
the device is "unavailable" to the device procedure.
Associated with each device procedure is an "execution time" property. Some device
procedures (such as device status checking) may have an execution time of zero — they
execute "instantaneously". Other device procedures have a non-zero execution time —
they execute "non-instantaneously". DPEP is designed in such a way as to allow the
programmer to perform processing in parallel with the execution of non-instantaneous
device procedures and to perform interruption processing when these device procedures
have signaled completion. It is the implementor's decision which of the device procedures
are defined to be instantaneous and which are to be non-instantaneous.
39
A device :procedure:execut?on:statement causes the following operations to be
performed:
1)
2)
3)
Any actual;input:parameters associated with the device:procedure:calI will
be evaluated in precisely the same manner as actual tinput:parameters are
evaluated in a procedure:call:statement.
The devIce:number:numer?c:formula will be evaluated exactly as if the
numerictformula were being used as subscript.
The DPEP mechanism will perform the following operations in the order
indicated:
(a)
If the dev?ce:number does not correspond to any of the device:numbers
allowed, DPEP ceases processing and returns control to the next statement
following the device procedure :execution:statement. (Attempt to execute
the device procedure results in a no-operation)
(b)
DPEP determines if the device procedure specified in the device:procedure:
call may be executed by the device specified by device:number. (A device
procedure for backspacing a tape record cannot be executed on a card
reader, for example) If the device procedure cannot be executed on the
device, DPEP returns control to the next statement following the device:
procedure:executionstatement. (Attempt to execute the device:procedure
results in a no-operation.)
(c)
DPEP determines if the device is "available" to the specific device procedure.
If not, DPEP returns control to the next statement following the device:
procedure execution:statement. (Attempt to execute results in a no-operation.)
(d)
If the device procedure specified is non-instantaneous, DPEP takes all
necessary steps to regain control from any program segment which may be
operating when the device signals that it has terminated execution of the
device procedure.
(e)
DPEP assigns the device procedure to the device for execution. If the
device procedure executes instantaneously on the device, control is returned
to the statement following the device:procedure:execution:statement. Then,
steps (g) - (i) are never entered. If the device procedure is non-instantaneous,
control is passed to step (f).
(f)
DPEP returns control to the statement following the device procedure:
execution:statement.
(g)
On the signal (interruption) from the device that it has completed processing
of the device procedure, execution of the program segment currently
op rating is suspended, DPEP ensures that any actual :output:parameters
associated with the device procedure are evaluated, and control is passed
to step (h) below,
(h)
DPEP evaluates any actual :input:parameters associated with the completion:
call, if a completion:call was supplied. (Evaluation takes place exactly as
if the completion:call were an ordinary procedure:call.) If no completion:
call was specified, DPEP resumes processing at step (i). Otherwise, the
40
(i)
•
•
•
•
close or procedure specified by the completiomcall is invoked and
DPEP awaits its termination. Upon termination of the completion:call
execution, DPEP passes control to step (i).
DPEP returns control to that point immediately following the last
execution which occurred prior to regaining control on the termination
signal from the device. Note that:
A complet?on:call associated with an instantaneous device procedure
is never operated (see step "e").
If the completionzcall procedure or close does not return control to DPEP
at step (g), further DPEP processing is undefined.
If the complet?on:call specified invocation of a close which was
declared within a FOR statement which does not contain the device:
procedure:executIon:statement, and if that close manipulates the loop:
variable defined by the FOR statement, the complet?on:call invocation
step (g) is undefined.
If the completion:call specifies invocation of a procedure, and if one or
more of the actual:parameters contains a loop:variable then the device:
procedure:execution:statement must appear within the scope of definition
of the loop:variables.
Examples of device:procedureexecution:statements are:
'EXECUTE REWIND ($23$) $
'EXECUTE REWIND ($1+7$) $
"THE ABOVE TWO STATEMENTS WILL REWIND THE TAPES ON DEVICES 23 AND
1+7."
'EXECUTE DISKREAD (DISKADDRESS, MEMORY 'BUF, BUF'LENGHT
= DISKREAD 'STATUS)
($ DISKA $) INTRUPT'L() $
"THE ABOVE STATEMENT CAUSES A READ FROM DISKADDRESS TO BE INITIATED. THE
DISKREAD DEVICE PROCEDURE WILL FILL DISKREAD 'STATUS WITH A VALUE DESCRIBI NG
THE STATUS OF THE READ ON COMPLETION. THEN THE PROC INTRUPT'L IS OPERATED."
3.2.2.11.2
JFILE
The file processing submodule, JFILE, consists of the following features:
•
•
•
•
the file:declaration
file manipulation statements
a control mechanism, the File Processor (PFILE)
two built-in interface procedures, TLB and TBL
41
•
•
the functional :modifier POS
the functional:modifier 'FILENUM.
These features described fully in 3.2.2.11 .2.4 have been designed and organized
in such a manner as to reflect a point of view founded on a specific definition of
file, and on the notion that files so defined have both "functional" and "representational" characteristics which can, and should be separated. The definition of file
is:
•
a collection of distinguishable objects, or records, called a
record set, and
•
the processes by which records in the record set are stored into
and retrieved from storage media.
A file characteristic is "functional" if it applies to a record set or storage/retrieval
processes independently of particular storage media and transmission devices. A file
characteristic is "representational" if it applies to particular properties of a record set
in some specific, physical storage medium or if it describes storage/retrieval processes
in terms of some specific, physical transmission device. JFILE is so structured as to
separate the functional characteristics of a file as completely as possible from the
representational characteristics, thus rendering functional processes and representation
characteristics independent.
3.2.2.11.2.1
3.2.2.11.2.1.1
The Functional File
The Functional Record Set
Each record in the functional record set is thought of as a "logical" or functional
entity independently of its relationship to any other information group; functional
records are generally defined by the programmer on the basis of certain functional
characteristics of his program. Each (functional) record in the record set has no
particular structure and is composed of no particular type of information as such. The
programmer gives structure and information type to a record by the manner in which his
program deals with its "main memory" image.
A record set contains n functional records, where n is some finite positive
integer or 0. If n=0, the record set is called "empty". (In practice, the programmer
does not ordinarily know the value of n.) Associated with each record in a (nonempty) record set is a unique non-negative integer k which comes from the set
k ( k = 0,.. ,,n-l) where n is the number of records in the record set. This set of
numbers is called the functional "reference set".
3.2.2.11.2.1.2
The Functional Storage/Retrieval Processes
This paragraph describes the referencing process consisting of four basic storage/retrieval
processes (Input, Output, Insert, Delete), and two processes (Open, Shut) which serve
42
to initialize and terminate other storage/retrieval processes. When "transmission"
is used below it means only the movement of information and implies no alteration of
that information. Thus, transmission of a record image from the main memory to an
external storage medium, followed by transmission of the same record back to main
memory, should produce an identical record image in main memory if the transmission
in each case is performed under the same set of conditions. ("Main memory" refers to
the storage medium which contains the invocation command for a storage/retrieval
process.)
Note that no notions of transmission initiation, transmission occurring in parallel
with computation, and interruption on completion of transmission are associated with
the functional storage/retrieval and initialization/termination processes, though, indeed,
any representation of these functional processes will have to deal with such notions.
From the point of view of the programmer, the execution of any functional process
involving a transmission causes the transmission to take place and does not terminate
before the transmission is completed; also, when a functional storage/retrieval or
initialization/termination process completes execution, program control is passed
to the statement following the process invocation. Further, this should be true for
any representation of the functional processes.
A record in a record set is "referenced" by specifying the appropriate integer k
from the reference set. A record is referenced when it is desired to use it as an
operand in a storage/retrieval process. If a record k is referenced with k(0)
or k(n-l)the result of the reference is, in general, undefined. (With respect
to the basic functional storage/retrieval processes described below, this will be
true unless explicitly stated as otherwise.) The following paragraphs describe the
functional processes:
a)
b)
c)
"Input record k" is a retrieval process which causes the record referenced
by k in the record set to be transmitted to the main memory. "Input
record k" is undefined if n=0, i.e., if the record set is empty.
"Output as record k" is a storage process which causes information to be
transmitted from the main memory to a storage medium. If the record
set in the storage medium already contains a record k, it is replaced
by the transmitted information; the transmitted information is then
established as record k of the record set. If k=n, the transmitted
information is appended to the record set and the number of records in
the record set is increased to n + 1 .
"Insert as record k" is a storage process which causes information to be
transmitted to the storage medium. If k = n, "Insert as record k" has
the same meaning as "Output as record k". Otherwise, the transmitted
information is established as record k of the record set. All those records
of the record set which were referenced by j *k prior to the invocation
of "Insert" are referenced by j + 1 subsequent to the invocation of "Insert".
"Insert" causes the number of records in the record set to be increased from
n to n + 1 .
43
d)
e)
f)
"Delete record k" is a storage process which causes record k of the
record set to be removed from the record set. Records of the record
set which were referenced by j > k prior to the invocation of "Delete"
are referenced by j-1 after invocation of "Delete". If n = 1, "Delete"
causes the record set to be made empty.
"Open file" is an initialization process which causes the record set and
the storage/retrieval processes of the file to be readied for processing. The
storage/retrieval processes "Input", "Output", "Insert", and "Delete"
may be invoked only after "Open file" has been invoked.
"Shut file" is a termination process which causes the record set and the
storage/retrieval processes to be brought to a state of inactivity. Once
"Shut file" has been invoked, "Input", "Output", "insert", or "Delete"
may not be invoked until "Open file" is invoked once again.
3.2.2.11.2.2
3.2.2.11.2.2.1
The Representational File
The Representational Record Set
Each record in the representational record set is an information group the attributes
of which reflect properties peculiar to a particular storage medium and transmission
(e.g., parity mode). Such information group attributes may also reflect the programmer's
desire to conserve space in the storage medium, as when he blocks many functional
records together into one representational record.
Representational records will have a structure and information type peculiar to the
associated storage medium and transmission device. A representational record set
may contain greater or fewer records than the number of records in the functional
record set being represented. A representational record set has an associated reference
set that is peculiar to the particular storage medium and transmission device being
used. Such a reference set may consist of disk or drum addresses, or it may contain
"position" numbers which specify where the record is on a tape, in a card reader, or
on a printer.
It is important to note that a given functional record set may have associated with
it a wide variety of representational record sets if the functional record set is to
be represented in a variety of different storage media and transmitted by a variety of
different transmission devices.
3.2.2.11.2.2.2
The Representational Storage/Retrieval Processes
"Transmission", as used in this paragraph may involve some alteration of information, as
for example, conversions between internal and external hollerith encoding techniques.
44
The actual transmission associated with an Input or Output typically requires initiation
of an Input or Output Operation and processing of theinterrupt signal returned by the
transmission device when it has completed the transmission. Thus, representational storage/
retrieval processes may allow other forms of processing to occur between transmission
initiation and completion. Device manipulations of all kinds may be required to effect
the transmission; these manipulations may indeed be commanded by device rprocedure:
executionrstatements, (JDEV).
A representational record is referenced by specifying its associated reference set element.
This element may be an explicit disk or drum address or it may appear implicitly in a
command, as in "read the next tape block". The following describes the representational
storage/retrieval processes.
a)
b)
c)
To "Input" or "Output" a representational record will involve commanding
some transmission device to move the representational record between
main memory and a storage medium. Device commanding requires, of course,
the specification of a variety of device specific parameters. "Outputing"
a record may involve "Inputing" other records of the record set, as when
dealing with disk records which are "linked" by disk addresses embedded
in each record as part of the data of that record. Representational
"Inputing" and "Outputing" may also involve commanding devices to
perform non-transmission processes, e.g., backspacing, rewinding,
positioning read/write heads, etc.
"Inserting" representational records may involve both "Inpuling" and
"Outputing" as may "Deleting" representational records.
"Opening" a representational file may involve securing a device,
allocating main memory buffer space, initiating the "Input" of a
physical record, and the like. "Shuting" a representational file may
involve releasing a device and main memory buffer space.
It is clear that different representational storage/retrieval processes will need to be applied
against the same functional record set represented in different storage media and transmitted
by different devices. Also, it is clear that certain functional processes will be feasible
for one file representation and not for another so that a functional file may be limited
in the number of representations that can be defined for it. For example, a file requiring
"Output" to "rewrite" a record cannot usually be represented feasibly where magnetic
tape is a storage medium.
3.2.2.11.2.3
Functional and Representational Specifications and Interfaces in JFILE
JFILE allows for the manipulation of files in both a functional and a representational manner.
Explicit language features are provided to deal with files functionally (see 3.2.2.11 .2.4,
below). The functional record set and reference set as well as the functional storage/retrieval
processes of paragraph 3.2.2.1 1 .2.1 are embodied in these language features. The
45
representational particular file aspects are dealt with in terms of "Service Routines" which
are tailored to the specific storage media and transmission devices of a particular application.
Service Routines are either closes or procedures which are written by the programmers for
a specific application.
A Service Routine is associated with each of the functional storage/retrieval processes
which will be carried out during the processing of the file; the association of Service
Routine with functional process is effected by means of the file;declaration.
Service Routines handle all representational aspects of the file. In general, embedded
within their structure will be facilities for effecting the following:
device assignment
recording modes and densities
record set labelling
internal buffering
initiation of device procedure executions
interrupt processing
external storage media allocation and management
transmission error checking and recovery procedures
sequential or random access
(Note that device manipulations might typically be handled by device:procedure:
execution:statements)
The set of all Service Routines is referred to as the JSERVICE submodule of JIO. It is
anticipated that a given application will fix on a set of (application) standard Service
Routines, or use such Service Routines as are provided by an operating system. A Service
Routine specified for a given functional storage/retrieval process should simulate and
preserve all the functional characteristics of files as described in 3.2.2.11 .2.1, though
there is no way to guarantee that this be so. (For example, the Service Routine associated
with "Input record k" should be so written as to make the correspondence between the
functional reference k and any physical reference, and cause transmission of functional
record k to occur as described in 3.2.2.11 .2.1 .2(a) regardless of any (representational)
device manipulations or internal buffering techniques which may be required to do so).
The syntactic entity, serv?ce:call, is the mechanism provided for specifying the invocation
of a Service Routine when performing a functional file operation. A service:call is a
close:name or a procedure:call. A procedure: call is the same as a procedure: call statement
except that it does not contain a terminal "$". When a service:call is said to be "operated"
in paragraph 3.2.2.11.2.4, the effect obtained is exactly that obtained by either
GOTO close:name $
or
procedure:calI $
46
Note that any actual :input:para meters of the procedure real I are evaluated in the usual
way at the time the service:call is operated, and not before. If the operation of a
service:call causes a close to be invoked which was declared in a FOR statement and
which references the loop:variable of the FOR statement, the effect of the close
invocation is undefined.
If the service :ca 11 is a procedure: call and if one or more of the actua I: para meters
contains a loop:variable, the file:declaratiort containing the service:call must also
be within the scope(s) of definition of the loop:variable(s). Also any open:, input:,
output:, insert:, delete:, or shuhstatement which, when executed, will cause such a
serv?ce:call to be operated must be within the scope(s) of definition of the loop:variable(s);
otherwise the operation of the service:call is undefined.
3.2.2.11.2.4
The File:Declaration and File Statements
3.2.2.11.2.4.1
The File:Declaration
A file:declaration is
FILE 8 file:name 9 file:process:!ist 0 $
Flle:name is a Category 3 name which serves to identify the file.
is either
file:process
or
file:process:list 9 file:process
A file:process:llst
A file:process is
MODE 9
mode:integer 6
open:process:clause 9
optional:pos:process:clause 9
optional:input:process:clause
optional:output:process:clause
optional:insert:process:clause
opt?onal:delete:process:clause
shut:process:clause 0
9
9
9
9
Note that at least one of the optional clauses in a file:process must be included in file:process,
Mode:integer is an unsigned:integer which servies to identify the f?le:process in which it is
contained; if more than one file:process appears in the file: process: I ist, the mode:integer
of any one must be different from the mode:integer of any other.
A flle:process is, in effect, a specification for a particular "mode" of file initialization,
storage/retrieval and termination processes which will be carried out together; the
47
file:process:list allows as many such "modes" as desired to be specified in the
file:declaration.
The purpose of the clauses in file:process is to show a correspondence between the
functional file operators OPEN, POS, INPUT, OUTPUT, 'INSERT, 'DELETE, and
SHUT, and the representational service:calls by which they are realized as indicated
below.
Open:process:clause
pos:process:clause
input: process: clause
output :process:c I ause
insert :process:clause
delete :process:clause
shut:process:clause
OPEN e
POS 9
INPUT 9
OUTPUT 9
'INSERT 6
'DELETE 6
SHUT 6
service:cal I
service:call
service:call
service:call
service :call
service :call
service:call
Service:calls are not operated at the time a file:declaration is made, but rather at the
time a file statement is executed, as described below. Note that at execution time, PFILE,
the file processing mechanism, has access to all information declared by a filetdeclaration.
3.2.2.11.2.4.2
File Statements
Statements performing file processing are:
>pe n:statements
inpuhstatements
ipu
output statements
inse restatements
delete statements
shut:statements
Additionally,file processing operations may take place whenever a value is assigned
to the functional:modifier POS.
Open:, input:, output:, insert:, delete:, and shut statements are the JOVIAL features
provided for effecting the functional file processes "Open", "Input", "Output", "Insert",
"Delete", and "Shut" discussed in 3.2.2.11 .2.1 .2. References to records in the functional
record set are made by assigning values to functional:mod?f?er POS (see 3.2.2.11 .2.4.3).
Thus, the invocation of the functional retrieval process "Input as record k" is carried
out by first assigning k to POS and then executing an ?nput:statement. Note that:
•
file statements do not automatically change the value of POS when they
are executed (though the associated Service Routines may be written
in such a way to perform this action if desired)
48
•
assignment of a value to POS does not automatically cause positioning
of the storage medium with respect to the transmission device (though
Service Routines may produce this result if desired).
A opentstatement is
OPEN 9 filername 0 MODE 0 moderformula 9
$
where moderformula is a numeric:formula .
An input:statement is
INPUT 9 filename 0 iorlist 0 $
An outpuhstarement is
OUTPUT 0 f?le:name 0 io:list 0 $
An insert:statement is
'INSERT 0 filename 0 io:list 0 $
A dele restatement is
"DELETE 0 filename 0 $
A shuhstatement is
SHUT 0 file:name 0 $
An io:list is
io:operand
or
io:list 0,
0 ioroperand
An io:operand is either a namedrvariable or tablername or array:name.
Note that the phrase "currently opened" will be used subsequently to describe any
file whose filername appears in an open statement which has been executed and where
no execution of a shuhstatement with the same file:name has yet taken place.
3.2.2.11.2.4.3
Functional:Modifier POS
POS is a functional modifier which designates an unsigned:integer:variable when applied
to a file:name and can therefore be assigned values. POS may appear in two forms:
POS 0 (0 filename 0)
or
POS
49
When the second form of POS is used, a filetname is automatically supplied. That
file:name is supplied which refers to a currently opened file and which appeared in the
last openlstatement, ?nput;statement, output;statement, insert;statement, or delete:statement
executed prior to the POS reference. POS is undefined if used when no file is currently
opened or when a specific file:name (form 1) used refers to a file not currently opened.
The value taken by POS is the reference number of a (logical) functional record in the
functional record set associated with fjlejname. POS provides the mechanism for
functional "Referencing" as described in 3.2.2.11 .2.1 .2. A further description of POS
is given in 3.2.2.11.2.4.5.7 below.
3.2.2.11.2.4.4
Functional:Modifier'FILENUM
'FILENUM is a functionahmodifier which produces an unsigned:?nteger when applied
to a file:name. 'FILENUM does not designate a variable and cannot be assigned values
in any JOVIAL J3 program. 'FILENUM may appear in two forms:
'FILENUM 0 (0 filename 9)
or
'FILENUM
When the second form is used, a file:name is automatically supplied. That fjlejname
is supplied which refers to a currently opened file and which appeared in the last
open statement, input:statement, outpuhstatement, insert: statement, or delete statement
executed prior to trie 'FILENUM reference. 'FILENUM is undefined if used when no
file is currently opened or if a specific file:name (form 1) is used which refers to a file
not currently opened.
Values taken by 'FILENUM always lie in the range 0. . .m, where m + 1 is the
maximum number of files ever "currently opened" during the course of program execution.
'FILENUM is undefined if file:name refers to a file not currently opened.
The purpose of 'FILENUM is to provide an interface between file manipulation statements
and the Service Routines by which they are realized. Thus a set of Service Routines might
be so written as to reference file parameters maintained in a table, with the parameter
sets for distinct files stored in distinct entries. Service Routines, when operated, would
determine the appropriate set (entry) of file parameters to use by means of 'FILENUM,
e.g., FILE 'PARAM ($ 'FILNUMlT.
3.2.2.11.2.4.5
PFILEand File Statements
PFILE supervises the execution of all file statements.
50
3.2.2.11 .2.4.5.1
Execution of the Open:Statement
The following functions are performed in the execution of the open:statement.
(a)
(b)
(c)
(d)
(e)
(f)
(g)
PFILE determines if the file called file:name has already been establised
as "currently opened". If so, execution of the open statement is undefined.
PFILE creates a unique non-negative integer and assigns it to the 'FILENUM
associated with this file. As previously stated, the value of 'FILENUM is
in the range 0. . .m where m + 1 is the maximum number of files ever
"currently opened" during the course of program execution.
The mode:formula of the open:statement is evaluated in the same manner
as if it were a subscript.
PFILE determines if a file:process identified by the value yielded by
evaluation of the mode:formula has been included in the file:declaration
for the file called file:name. If no such file:process was included in the
declaration, execution of the open-.statement is undefined. Otherwise,
PFILE establishes the file:process so identified as the "current file:process"
for the file called file:name.
PFILE establishes the status of the file called file:name as "currently opened".
PFILE operates the service:call given in the open:process:clause of the current
file:process.
When the service:calI returns control to PFILE, PFILE returns control to the
first statement following the open:statement .
3.2.2.11.2.4.5.2
Execution of the lnput:Statement
The following functions are performed in the execution of the input:statement.
(a)
(b)
(c)
(d)
(e)
PFILE determines if the status of File called file:name is "currently opened".
If not, execution of the input statement is undefined.
PFILE then determines if an input:process:clause is included in the current
file:process established for the file called file:name. If not, execution of
the inpuhstatement is undefined.
The io: list of the input statement is established as the "current io:list" by
PFILE. Subscripts of named:subscripted:var?ables appearing in the io:l ist
are evaluated at this time, in the same manner that they would be evaluated
had the named:subscripted:variables appeared in any other statement. Also,
subscripts for named:subscripted:variables are evaluated in the same left
to right order that the named:subscript:variables appear in the io:list. Note
that these remarks about subscript evaluation apply whenever the phrase
"established as the current io:list" appears in subsequent paragraphs.
PFILE operates the service:call associated with the input:process:list in the
curre nt :process: I i st.
When the service:call returns control to PFILE, PFILE returns control to the
first statement following the input:statement.
51
3.2.2.11.2.4.5.3
Execution of the OutputiSntat-emenf
The description of output:statement execution is identical to the description of
input:statement execution (3.2.2.11 .2.4.5.2) except that every occurrence of the
word input should be replaced by the word output.
3.2.2.11 .2.4.5.4
Execution of the InsertrStatement
The description of lnsert:Statement execution is identical to the description of
lnput:Statement execution (3.2.2.11 .2.4.5.2) except that every occurrence of the
word input should be replaced by the word insert.
3.2.2.11 .2.4.5.5
Execution of the Delete:Statement
The description of delete:statement execution is identical to the description of
input:statement execution (3.2.2.11.2.4.5.2) except that subparagraph (c) does
not appear (a delete:statement has no iojlist) and every occurrence of the word input
should be replaced by the word delete.
3.2.2.11 .2.4.5.6
Execution of the ShuhStatement
The following functions are performed in the execution of the shut:statement.
(a)
(b)
(c)
PFILE determines if the file called filename has been established as
"currently opened". If not, execution of the shutrstatement is undefined.
Then PFILE operates the service :ca 11 given in the shut:process:clause of
the current file:process for the file file:name.
When the service:call returns control to PFILE, PFILE establishes the status
of the file file:name as "not currently opened" and returns control to the
first statement following the shutrstatement.
3.2.2.11 .2.4.5.7
Execution of Assignment to POS
The following functions are performed in the execution of the assignment to POS.
(a)
(b)
(c)
(d)
PFILE determines if file file:name has been established as "currently opened".
If not, any reference to POS is undefined (see 3.2.2.11 .2.4.3).
The value to be assigned to POS for file filername is assigned.
If a pos:process:clause is present in the current file:process for file file:name,
PFILE operates it. Otherwise PFILE returns control to the first program step
following the assignment to POS.
When the servicercall returns control to PFILE, PFILE returns control to the
first program step following assignment to POS.
52
(e)
Note that the reason for allowing a service;calI to be operated when a
value is assigned to POS is to allow a "repositioning" of the transmission
device over the representational record set well in advance of the next
access to a record. A programmer requiring random access to a disk, say,
might do a POS assignment (with servtce:call), then some computations,
and finally execute an inpuhstatement, realizing that the computations
will be carried on while a disk read-head is "repositioning".
3.2.2.11.2.5
The Built-in Procedures TBL and TLB
TBL (Transmit Buffer to io:list) and TLB (Transmit io:list to Buffer) allow the applications
programmer writing Service Routines to transmit between functional records (which have
been brought into main memory from an external storage medium or which will be
transmitted from main memory to a storage medium) and the internal data structures
which are named in the io:list of input:, output;, and inserestatements.
The following functions are performed in the execution of TBL and TLB which
operate under the control of PFILE.
(a)
TBL is invoked by
TBL (BUFFER, DISPLACEMENT, LENGTH) $
TLB is invoked by
TLB (BUFFER, DISPLACEMENT, LENGTH)
$
BUFFER is table:name or array:name denoting the (main memory) buffer area
which will receive the functional record from the io:list (TLB) or which contains
the functional record to be transmitted to the iotlist (TBL).
DISPLACEMENT is an integenvariable which is an increment from the
first word address of BUFFER: TBL, and TLB add DISPLACEMENT to the first
word address of BUFFER to produce the first word address of the functional
record storage area.
LENGTH is an unsigned:integer:var?able representing the length in words
of the functional record storage area.
(b)
TBL causes the functional record characterized by the inpuhparameters to
be transmitted to the internal data structures of the "current io:list". the
"current iorlist" is established by PFILE as described in 3.2.2.11 .2.4.5.
TBL treats the functional record as a bit string and the elements of the
53
"current io:11st" as a set of bit strings, one for each namedrvariable,
table, or array making up the "current io;list". A bit string corresponding
to a namedrvariable consists of all bits required to represent the variable,
including any filler bits. Bit strings corresponding to tables and arrays
are composed of those (contiguous) blocks of words used to represent the
tables and arrays. In the case of tables, the contiguous block contains
the NENT word as the first word; even if the table is variable, the
length of the block is based on the total number of words required to
represent the table, regardless of the current value of the NENT. The
transmission behaves as if the "current io:list" bit strings formed one
contiguous bit string, concentrated together in the same order that the
named:var?ables, tables, and arrays appear in the "current iorlist".
Each functional record bit, starting with the left most record bit, is moved
one at a time to a corresponding bit in the (contiguous) "current iorlist"
bit string, starting with the left most current ?o:list bit. The move
terminates when the functional record bit string is exhausted or when the
"current io:list" bit string is exhausted, whichever happens first.
(c)
(d)
3.2.2.11.3
(The description of the transmission as a bit by bit move is given only
to indicate the functional characteristics of the move. An implementation
scheme which achieves the same functional end is permissible.
TLB causes the "current To:11st" structures to be moved to a functional
record storage area whose first word address and size are characterized
by the TLB input parameters. The effect of the transmission is identical
to the TBL transmission except, of course, that the move is from the
(contiguous) "current iorlist" to the functional record storage area.
It should be noted that the iorlist, however complex, is treated as one
functional record.
JFORMAT
The JFORMAT submodule is composed ofr
•
•
•
the formatrvariable
the encode rstate me nt and the decoder statement
the format processor, PFORM
The purpose of the JFORMAT features is to provide the facilities for converting data
in hollerith character string representations to internal representations and vice-versa.
A decoderstatement is used to convert data represented as hollerith character strings
to their corresponding internal representation. An encode rstate me nt is used to convert
data from their internal representations to hollerith character string representations. The
purpose of the formatrvariable is to supply the necessary conversion and editing specifications.
54
Encode: and decode:statements are thought of as executed under the supervision of
the processor PFORM.
3.2.2.11.3.2.1
The FormahVariable
A formatrvariable is either a hollerith:constant or a named:hollerith:variable.
PFORM interprets format:variables to determine what conversions and editings are
to take place. The hollerith characters making up the content of a formatrvariable
need have no particular structure until PFORM is called upon to interpret the format:
variable during the execution of an encode:statement or a decode statement. Note
that all or part of any format:variable may be modified at execution time by any of
the character manipulation features of the language; this allows for varying conversion
and editing specifications at execution time.
When a formahvariable is being interpreted, the hollerith characters comprising it
must take the form of a specification'list. (Note: Prime, and not colon, will be used
in the syntactic specifications of the content of a formahvariable to draw attention to
the fact that such specifications apply at execution time and not at compile time. Prime
plays the same role played by colon in the compile time metalanguage specifications; all
other compile time metasyntactic symbols have the same meaning when used in execution
time metasyntactic symbols.)
A specification'list is a
conversi on'or'edi ting'specifier
or a
specification'list 9,
6 conversion'or'editing'specifier.
A conversion'or'editing:specifier is a
conversi on'specifier
or
editing'specifier or iterator 0 (9 specification'list 0).
Iterator is a number.
A conversion'specifier is one of the forms
W_
W_
W_
W_
W_
W
9
9
9
9
9
9
I
A
F
D
S
B
9 _d_
9 J_
9 d_
9 d_
55
w_e o
wex
W9H
W6H6L
A ffxed:field:l 1st is either
fixed:fie Id :ele merit
or
f?xed:field:list 8,
0 fixed:field:element.
A free:field:list is either
free:field:element
or
free:field:list 0,
0 free:field:element
A fixed:field:element is a namedrvariable. A free;field:element is either a
named:variable, table:name, or arraymome. Note that an arraytnome may be used
in fixed:field:list as long as it is appropriately subscripted and that a table:name
may not appear at all in a fixed:field:list.
Conversions are termed "free field" if they are specified by an encode: or decode:
statement with a free:field:conversion:clause; otherwise they are termed "fixed field".
3.2.2.11 .3.3
Fixed Field Conversions
"Field" means a substring of the buffer associated with an encode: or decode statement.
Bufferrname is either the name of a literahitem, a table or array. If buffer:name is the
name of a literal :item, that item must be not less than 41 bytes in length and must begin
in byte 0 of a word. Further, if the structure called buffenname is greater than one word
in length, it must occupy consecutive words. When the structure called bufferrname is
used in an encode: or decode statement, it is treated as a string of hollerith characters,
no matter how it may have been declared. (The structure called buffenname is referred
to subsequently as the buffer.)
A conversion:clause is either a fixed:field:conversion:clause or a free:field:conversion:
clause.
A fixed:field:conversion:clause is either
(0 format:variable 0) 0 fixed:field:list
or
(0 formahvariable 0, 0
service tea 11 0) 0 fixed:f?eld:list
56
A free:field:convers?on:clause is either
(9) 9free:field:list
or
(0 ,
9 service:ca11 9) free:field:list
An editing'specifier is one of the forms
W
- 9 W_
W 9 C
h~ollerith:constant
W denotes a number, the value of which must be non-zero; d denotes a number. The
meaning of conversion'specifiers and editing'specifiers, and-the role played by iterator
will be explained in 3.2.2.11.3.3, 3.2.2.11 .3.4, and 3.2.2.11.3.5.
3.2.2.11.3.2
The Encode:Statement and Decode:Statement
An encode:statement is
'ENCODE 9 buffer:name 9 conversiontclause 9 $
A dec ode statement is
'DECODE 9 buffering me 9 conversion:clause 9 $
3.2.2.11.3.3.1
Description of Conversion'specifiers
The number denoted by W always represents the field width in terms of number of
character positions. The number denoted by d represents an implied negative power
of ten when used in conjunction with a decode:statement; when used in conjunction
with an encode statement, d denotes the number of digits to the right of the decimal
point. The letter following W in a conversion'specifier indicates the "conversion type'
L used in W 9 H 9 L, means "left-justified". If W 9 H is used, "right-justified" is
implied. "Left-justified" and "right-justified" are defined in 3.2.2.11 .3.3.2 and
3.2.2.11.3.3.3.
3.2.2.11.3.3.2
Conversion with a Decode:Statement
The execution of a decode statement causes a field of the buffer to be converted
from a hollerith representation to an internal representation which is then assigned
to an associated named:variable. The form of the internal representation is defined by
the item:declaration given for that named:variable which is associated with the conversion'
specifier during the execution of the decode:statement.
57
The conversion of a hollerith representation to an internal representation takes place
according to the same rules and is subject to the same restrictions as would apply if
the conversion were effected by an assignmentrstatement of the form:
namedtvariable 0 = 8 constant 8 $
where constant is simply the contents of the field being converted. However, it
must be added that if the contents of the field form an ?nteger:constant and the
conversion type is A, F, or D, then the converted value obtained above is multiplied
by 1 0-d before assignment to the namedtvariable. Note that, with the exception of
fields defined by conversion'specifier W 8 H, leading spaces and trailina spaces in
the field are not regarded as part of the datum. The character configurations which
the field may take for any given conversion type are shown in paragraphs (a) - (f). The
conversion is undefined if the character configuration of the field is not one of those
specified as allowable in (a) - (f).
(a)
Conversion Type I, A, F, or D
If the conversion type is I, A, F, or D, the allowable character configurations
of the field being converted are:
optional ly:signed:integer;constant
optional ly:s?gned:fixed:constant
opt i o na I ly:signed: floating: constant
optional ly:signed:extended;precision:f I oating:constant
spaces (all characters)
hexadecimal xonstant
octal: constant
If the character configuration is spaces, the field is treated as if the single
digit 0 appeared.
(b)
Conversion Type S
The allowable character configurations are:
status:constant
name
When name is used, the field is treated as if its character configuration
were V(name).
58
(c)
Conversion Type B
The allowable character configurations are:
0
1
T
F
T and F are treated as if they were 1 and 0, respectively.
(d)
Conversion Type O
The allowable character configurations are:
octal :constant
octahdigits
When octal:digits are used, the field is treated as if its contents were O (octal
digits).
(e)
Conversion Type X
The allowable character configurations are:
hexadecimal:constant
hexadecimal: digits
If the latter is used, the field is treated as if X (hexadecimal :digits) appeared.
(f)
Conversion Type H
The allowable character configuration is any string of hollerith characters. If
the string of hollerith characters, once stripped of any leading and trailing spaces,
forms a hoilerith:constant, the contents of the field are treated as if they were
that hollerith-.constant. Otherwise,
•
•
•
3.2.2.11 .3.3.3
If the field is defined as right-justified (W 0 H), any trailing
spaces are recognized as part of the datum.
If the field is defined as left-justified (W9H 9L), trailing spaces
are not recognized as part of the data.
The contents of the field are treated as if they were number H
(string:of:hol lerith:characters) where the value of number is the
number of characters in the string of hollerith characters.
Conversion with an encode:statement
The execution of an encode statement causes named:variables to be converted from their
internal representations to hollerith character string representations which are inserted into
the buffer. The internal representations are defined by the item:declarations given for the
named:variables. The hollerith character string representations are defined by the parameters
59
of the conversion'specifiers as associated with the namechvariables during the execution
of the encode:statement. The number W of the conversion'specifier indicates the width
of the field into which the hollerith character string produced by the conversion will be
placed. The number d indicates the number of digits to the right of the decimal point
in the generated character string. The conversion type describes the format of the
generated character string. Associated with a given conversion type are a set of
allowable item types. A named:var?able being converted with respect to a given
conversion type must admit to one of the allowable item types; if not, the effect of the
conversion is undefined. Allowable item types and hollerith character string representation
formats are described in paragraphs (a) - (h) below.
(a)
Conversion Type I
Allowable item types of named;var?ables which may be converted with
conversion type I are:
integer
fixed
floating
extended :precision:f looting
The format of the hollerith character string generated by means of this conversion
is:
S I. . .1
where S specifies sign and I. . .1 specifies integer digits. If the item converted
is signed and non-negative, or unsigned, S is a space; otherwise S is "-".
(b)
Converson Type A
Allowable item types which may be converted are:
v
integer
fixed
floating
extended :precis?on:f looting
The format of the hollerith character string is
S I. . .1 . F. . .F
S and I. . .1 are as described above; F. . .F are the fractional digits.
number of fractional digits is equal to d.
(c)
Conversion Type F
Allowable item types are:
integer
fixed
floating
extended: precis?on:f looting
60
The
The format is
S • F. . .F E ±e. . .e
S and F. . .F are as described above. E - e. . .e represents the exponent.
The number of digits making upe. . .e is implementation dependent,
(d)
Conversion Type D
Allowable item types are:
integer
fixed
floating
extended: precision floating
The format is
S • F. . .F E ±e. . .e D
S, F. . .F and e. . .e are as described above.
extended:precision:floating.
(e)
Conversion Types O and X
The terminal letter D denotes
Any of the item types that are allowed. The format produced by type O is O. . .O,
where O is an octal:digit. The format produced by type X is X. . .X, where
X is a hexadecimal :digit.
(f)
Conversion Type S
The only allowable item type is status. The format is status:constant:signs where
status:constant:signs are those signs which appeared in any of the constants V
(status:constant:signs) when the status:item was declared.
(g)
Conversion Type B
The only allowable item type is boolean. The format is "T" or "F" according
as the value of the boolean item is "true" or "false",
(h)
Conversion Type H
The only allowable item types are literal. The format is C. . .C where C
denotes a hollerith character; the number of characters making up C. . .C
equals the length of the literal item converted.
3.2.2.11.3.4
Description of Editing'specifiers
An editing'specifier does not control conversion, but rather serves to describe to the
format processor, PFORM, certain actions to take when processing the buffer when
it is used with either an encode statement or a de code: state me nt.
(a)
The form W means "skip forward in the buffer over the next W character
positions",
61
(b)
The form - 0 W means "skip backward in the buffer over the next W
character positions. If W is large enough to cause repositioning to the
left of byte 0 of the buffer, the meaning is "skip back to byte 0 of the
buffer".
When editing'specifier, hollerith:constant is used with an encode:statement, the
meaning is "insert the character string contents of the constant into the buffer". When
used with a decoderstatement, the meaning is "skip forward in the buffer a number of
character positions equal to the length of the constant". When the editing'specifier
W 8 C is used with an e ncode: state me nt, the meaning is "insert W spaces into the buffer";
wFien used with a decoderstatement, the meaning is "skip forward in the buffer W character
positions".
3.2.2.11.3.5
Description of Iterator
When iterator is used in the conversion'or'editing'specifier form
iterator 9 (0 specification'list 0)
it has the effect of replicating the contents of the parenthesized specification'list
that number of times specified by the value of iterator. Thus 38(5A2/ 3, 41) will produce
the same result when processed by PFORM as 5A2, 3, 41, 5A2, 3, 41, 5A2, 3, 41.
3.2.2.11.3.6
Execution of Encode: and Decode:Statements
The execution of encode: and decode:statements with either fixed:field: or free:field:
conversion:clauses takes place under the supervision of the format processor PFORM.
3.2.2.11 .3.6.1
Fixedrfield Execution
This paragraph describes the execution of encode: and decode:statements with fixedrfield:
conversionslauses. The action of PFORM causes three "pointers" to be manipulated.
The buffer pointer points to a character position in the buffer. The format pointer points
to a conversion'or'editing'specifier in the formatrvariable. The list pointer points to a
fixed:field:list:element in the fixedrfieldrllst. The bjffer is said to be exhausted if the
buffer points to the right of the rightmost buffer character position. The fixed:field:list
is said to be exhausted if the list pointer points to the right of the rightmost fixed:field:
l?st:element. The format:variable is said to be exhausted if the format pointer points to
the right of the rightmost conversTon'or'edi ting'specifier. Note that in the following
description, it is assumed that the format:variable data has the form specified by
specification'list; if not, the resultant action is undefined. The sequence of events,
which take place when an encode: or decoderstatement with a fixed:fieldrconversionrclause
is executed, is as follows:
62
(a)
(b)
(c)
(d)
(e)
(f)
PFORM sets the buffer pointer to point to byte 0 of the buffer, the format
pointer to point to the leftmost conversian'or'editing specifier in the format'
variable, and the list pointer to point to the leftmost fixed:field:list: element
of the fixed:Field:list.
If the conversion'or'editing'specifier specified by the format pointer is an
editing^specifier, the action called out by it is performed (resetting the
buffer point by the value W) and control is passed to step (e). Otherwise,
control is passed to step (c).
If the conversi on'or'edi ting'specifier is an iterated sub-expression (form:
iterator 8 (9 specification'list 6) ), it is, in effect, replaced by its expansion
as described in 3.2.2.11 .3.5, and control is passed to step (b). (No pointer
is altered) Otherwise control is passed to step (d).
The conversi on'or'edi ting'specifier is a conversi on'specifier. Any subscript
associated with the fixed:field:list:element specified by the list pointer
is evaluated and the conversion specified by the conversion'specifier
is performed using that fixed:field:list:element. This causes the buffer
pointer to be modified by the amount W. Then, both the list and format
pointers are advanced one position toTrie "right" and control is passed
to step (e).
If the formahvariable is exhausted, PFORM returns control to the statement
following the encode: or decode statement. The same action is taken if
the fixed:field:list is exhausted. If the buffer, fixed:field:list, and format:
variable are not exhausted, control is passed to step (b). If the fixedtfieldrlist
and the formahvariable are not exhausted, control is passed to step (f).
If a service:call has been supplied in the fixed:field:conversion:clause, it is
operated. On completion of the service:call execution, PFORM sets the
buffer pointer to point to byte 0 of the buffer and passes control to step (b).
It should be noted that the primary purposes of the service:call are to allow the programmer
the facility for refilling the buffer (decodestatement) as when converting card reader records,
or to output the buffer, as to a line printer (encode:statement).
3.2.2.11.3.6.2
Free:field Execution
This paragraph describes the execution of encode: and decode statements with
free:field:conversion:clauses.
3.2.2.11.3.6.2.1
Free:field Decode statement Execution
The actions taken by PFORM in the execution of the decode:statement in the order
shown are:
(a)
A "virtual" fixed:field:list is constructed by PFORM from the free:field:list.
This construction takes place by moving left to right through the free:field:list
63
copying the named;variables where they are found and replacing each
table:name and array:name with a list of subscripted item:names. In the
case of a table:name, the item list is composed of sublists the number of
which is governed by the current value of the table NENT. Each sublist
is composed of the table:item:names, subscripted by a constant, in the same
order that they appeared between the BEGIN and END in the table:declaration.
The subscripts of the table:?tem:names in a given sublist are the same value;
subscripts for the table:item:names in different item sublists increase from
0 to NENT (table:name) - 1 as the sublists appear from left to right. (Each
sublist corresponds to a table entry) Note that all item:names between the
BEGIN and END brackets of the table:declaration will appear in the sublist
for each entry, regardless of any overlaying which may have been specified.
(b)
(c)
In the case of arrays, a list of subscripted arrayingmes replaces the
array:name; that list contains the same number of subscripted array:names
as there are elements in the array. Subscripts of the array:names vary
in such a way that the named:subscripted:array elements appear in the same
left to right order that would occur if the constants of an array:declaration
for the particular array were replaced by their correspondent subscripted
array:names.
A virtual formativariable is constructed. This formahvariable contains
only conversion'specifiers; the number of conversion'specifiers equal the
number of named:variables In the virtual fixed:field:list constructed in (a).
The conversion type is generated on the basis of the item:descriptions of
the named:var?ables. The parameter d is established as zero; hollerith
conversion'specifiers are established as right-justified.
Now, in effect, PFORM substitutes the virtual format:variable into the
free:field:conversion:clause of the decode:statement and replaces the
free:field:list with the virtual fixed:field:list in such a manner as to
transform the free:field:conversion:clause into a fixed:field:conversion:clause.
Then, PFORM executes the transformed decode statement exactly as it executes
any decode:statement with a fixed:field:conversion:clause, except that the
field width W is determined dynamically as PFORM sweeps the buffer from
left to right. Each string of consecutive non-blank characters encountered
in the buffer is taken as a field of length (W) which is the number of ^non-blank)
characters in the string.
3.2.2.11.3.6.2.2
Free:field Encode statement Execution
The actions taken by PFORM in the execution of the encode:statement In the order
shown are:
(a)
A virtual f?xed:f?eld:list is constructed in exactly the same manner as
described in 3.2.2.11.3.6.2.1 (a).
64
(b)
A virtual format:variable is constructed on the basis of the item:
declarations of the named:variables in the virtual fixed:field:lisr.
The formattvariable contains a number of conversion 'specifiers
equal to the number of named:variables in the virtual fixed:field:list.
For a given conversion type, the field width W (and th~e
paramater d) are fixed but implementation dependent. In addition
to conversion 'specifiers, editing 'specifiers are inserted into the
virtual format:variable.
These editing'specifiers are selected in such a way as to guarantee
that:
•
•
•
(c)
3.2.2. 11.4
for named:variables in the free:field:list, the decode:
statement will produce the variable:name followed
by an equal :sign followed by the value
for table:names appearing in the free:field:list, the
decode:statement will produce, each in a different
buffer image,
the table:name
the names of each table:item, as if in a
column header
the value of each item for a given entry
with the entry number
for array:names appearing in the free:field:list, the
decode:statement will produce, each in a different
buffer image,
the array:name, plane number, and column
count for each column in the plane
each row in the plane
(Planes are repeated as often as required.)
PFORM now substitutes the virtual formahvariable into the
free:field:conversion:clause of the encode statement and replaces
the free:field:I ist with the virtual fixed :field :1 ist in such a manner
as to transform the free:field:conversion:clause into a fixed:
fie Id conversion :clause. Then PFORM executes the encode:
statement exactly as it executes any encode statement with a
fixed :fie Id conversion :clause.
Example
The example in this section illustrates the various facilities provided by JIO and
a hypothetical set of standardized application Specific Service Routines.
65
These Service Routines consist of a family of IOCS (Input/Output Control System)
procedures and a family of I OBS (Input/Output Buffering System) procedures.
The IOCS routines appear as service:calls in the fle:declarations. They cause
information to be moved between internal buffers and the io:lists in file manipulation
statements. The IOCS family calls upon the IOBS family to transmit information
between the buffers and tapes or disks by use of tape drives and disk drives. The
following facts serve to clarify the example:
•
•
•
•
There are 15 transmission devices in the hypothetical system.
These are devices 1 through 15. Device 0 is the central
processor itself. Devices 1 - 7 are tape drives. Devices
8-15 are disk drives.
There are two files which are available to the programmer.
These are SYSINP, the system input file, and SYSOUT,
the system output file. SYSINP and SYSOUT are, respectively,
permanently assigned to tapes 1 and 2.
IOCS and I OBS make reference to five (global) tables.
FPT (File Parameter Table) contains file parameters. FPTW
is a like table with the same structure as FPT. FPTW is a
"working" file parameter table. DFT is a device/file table.
There is one entry for each device. In a given entry, the
item DFA is "true" if the device whose number is the ordinal
of the entry is assigned to a currently opened file. If DFA
is true, DF contains the value of the 'FILENUM which was
generated by PFILE for that file. File buffers are always
maintained in a special (global) table called SYSBUF'TABLE.
A buffer for a file is allocated in SYSBUF'TABLE by means
of a system function called RESERVE'SYSBUF; the example
assumes that SYSBUF'TABLE never runs out of space. (Note
that the full computer word of this system takes 32 bits — each
SYSBUF'TABLE entry is one 32 bit word in length.) The
table BFT (Buffer/File Table) relates the index of the first
SYSBUF word of a file buffer to the 'FILENUM of the file;
the ordinal of a BFT entry is, in fact, the 'FILENUM value.
The I OCS and IOBS Service Routines shown adhere to the following conventions:
•
•
•
Both functional and representational records are fixed length.
A representational record may be a block of one or more
functional records, but the block must always contain the
same number of functional records.
A buffer for a file consists of the number of words in a
representational record plus one word.
The first word of the buffer is a buffer control word; its value
is always the device status as determined by the device
procedure STAT'CHECK.
66
•
•
•
No multiple buffering is permitted; only one representational
record at a time may be maintained in a file buffer.
One and only one device is ever associated with a file.
Only 15 files may ever be currently opened simultaneously.
Reading always begins at the first record in the functional
record set and proceeds from record to record in the order
of increasing reference number; no backspacing is allowed.
POS is always assigned values from within the IOCS routines.
Note that, for the purposes of simplicity, many important details have not been
included in the example. It is for simplicity's sake also that the conventions
above are used. Thus, this example is purposefully simplified and is not to be
construed as a full-scale model for a set of Service Routines and is included on the
following pages.
67
EXAMPLE
START $
"FILE PARAMETER TABLE"
TABLE FPTV 100 S $
BEGIN
ITEM FILE NAME H 24 $ "NAME OF FILE"
BEGIN H(SYSINP) H(SYSOUT) END
ITEM FUNC'RECLENGTH I 15 U $
"NUMBER WORDS PER FUNC RECORD"
BEGIN 20 30 END
"20 WORDS = 80 CARD COLUMNS,
30 WORDS = 120 CHARACTER PRINT LINE"
ITEM FUNCS'PER'REP I 15 U $
"NUMBER OF FUNC RECORDS IN
REPRESENTATIONAL RECORD"
BEGIN 1 1 END
"SYSINP,SYSOUTARE UNBLOCKED"
ITEM BASE/NUM I 32 U $
"IF STORAGE IS DISK, BASE'NUM = DISK
ADDRESS OF ZERO-TH REP RECORD.
IF STORAGE IS TAPE, BASE'NUM = FILE NUM ON TAPE"
BEGIN 0 0 END
"SYSINP/OUT ARE TAPE, EACH FILE NUMBER 0 ON THE REEL"
ITEM DEVICE I 15 U $
"NUMBER OF DEVICE ATTACHED"
BEGIN 1 2 END
END "FPT"
"NOTE THAT THE PRESETS IN FPT ARE FOR SYSINP AND SYSOUT"
ITEM NENT'FPT I 32 S P 2 $
OVERLAY NENT'FPT = FPT $
"ESTABLISH NENT (FPT) AS 2 TO ACCOUNT FOR PREDEFINED SYSINP,
SYSOUT ENTRIES"
"NOW DEFINE A 'LIKE' WORKING FPT"
TABLE FPTW R I 6 S L $
"DEVICE/FILE TABLE — ONE ENTRY PER DEVICE"
TABLE DFT R I 6 S $
BEGIN
ITEM DF I 32 S $
"DF ($ DEVICE NUMBER $) = FILENUM OF ASSOCIATED FILE"
ITEM DFA B $ "DFA ($ DEVICE NUMBER $)
- TRUE IF DEVICE IS ASSIGNED TO A FILE, OTHERWISE FALSE
BEGIN "PRESET DFA TO FALSE"
00000000
oooooooo
8
END "PRESET"
END "DFT"
"BUFFER/FILE TABLE — ONE ENTRY PER CURRENTLY OPENED FILE"
TABLE BFT R | 6 S $
BEGIN
ITEM BFC I 32 U $
"BFC ($ 'FILENUMS) = INDEX OF FIRST SYSBUF
WORD WHERE BUFFERS AND CONTROL WORDS FOR Fl LE
'FILENUM BEGIN"
END
"SYSTEM BUFFER AREA"
TABLE SYSBUF' TABLE V^/S $
BEGIN
ITEM SYSBUF I 32 S $
END
"SYSINP AND SYSOUT ARE ASSUMED OPENED"
FILE AIRFIELD
MODE 9
OPEN lOCSOPEN'INP (H(AIRFIELD))
INPUT IOCSINP ( = AIRFIELD'STAT)
SHUT lOCSSHUT'lNP ( )$
ITEM AIRFIELD'STAT I 32 S $
"THE FOLLOWING THREE ITEMS AND THE AF'PARAMS TABLE CONSTITUTE THE
AIRFIELD FILE RECORD STRUCTURE"
ITEM AF'NAME H 8 $
"2 WORDS"
ITEMAF'LATFS
"1WORD"
ITEM AF'LONG F $
"1WORD"
TABLE AF'PARAMS V I 2 P $ "25 WORDS WITH NENT"
BEGIN
ITEM AF/PARAM'l I 32 S $
ITEM AF'PARAM'2 F $
END
"FUNCTIONAL RECORD LENGTH IS 29 WORDS"
"DECLARE SYSINP BUFFER"
ITEM SYSINP'BUF H 8 0$
"NOW, BRING IN THE REPRESENTATION PARAMETERS FOR AIRFIELD FILE FROM
SYSINP. THESE PARAMS ARE FREE FIELD. THE GROUP OF THEM CONSTITUTES
AN FPT ENTRY. THE PARAMS ARE
AIRFIELD
29
10
3
9
AIRFIELD IS THE HOLLERITH FILE NAME
29 IS THE WORDS PER FUNC REC
10 INDICATES THAT THE REPRESENTATIONAL RECORD IS A BLOC OF 10 FUNC RECORDS
3 MEANS THE FILE IS THE FOURTH FILE ON A TAPE REEL (0 - ORIGIN INDEXING)
9 MEANS TAPE DRIVE 9 IS THE DEVICE
69
"NOTE THAT IT IS A SIGNIFICANT FEATURE OF THE JSERVICE ROUTINES OF THIS
EXAMPLE THAT FILE PARAMETERS MAY BE 'BOUND' AT EXECUTION TIME"
"BRING IN FIRST SYSINP RECORD"
GOTO BUF'FILLER $
'DECODE SYSINP'BUF (,BUF'FILLER)
FILE NAME ($2$), FUNC'REOLENGTH ($2$), FUNCS'PER'REP ($2$),
BASE'NUM ($2$), DEVICE ($2$) $
CLOSE BUF'FILLER $
BEGIN
"THIS CLOSE KEEPS THE BUFFER FILLED (FROM SYSINP) FOR
THE 'DECODE STATEMENT ABOVE"
INPUT SYSINP "FILE RECORD TO" SYSINP'BUF $
END
"NOTE THAT FPT ENTRY 2 NOW CONTAINS THE AIRFIELD FILE PARAMS. IOCS
WILL TRANSFER THESE PARAMS TO AN ENTRY IN FPTW WHEN THE FILE IS OPENED.
IOCS AND IOBS WORK WITH THE PARAMS AS THEY APPEAR IN FPTW"
'OPEN THE FILE"
OPEN AIRFIELD MODE 0$
"READ FROM THE FILE"
INPUT AIRFIELD
AF'NAME, AF'LAT, AF'LONG, AF'PARAMS$
"CHECK FOR EOF"
IF AIRFIELD'STATEQ 3$
BEGIN "EOF CODE" END
IF AIRFIELD'STATEQ 2 $
BEGIN "BAD TRANSMISSION CODE" END
"THE FOLLOWING EXAMPLE ILLUSTRATES ANOTHER USAGE TO WHICH THE
'EXECUTE STATEMENT MAY BE PUT. THIS USAGE MONITORS ARITHMETIC OVERFLOWS'
'EXECUTE ENABLE (OVERFLOW) ($0$) OVF'l.$
'EXECUTE DISABLE (OVERFLOW) ($0$) $
"THE FIRST 'EXECUTE INFORMS THE CPU (DEVICE 0) TO BEGIN MONITORING FOR
OVERFLOWS. THE SECOND 'EXECUTE CAUSES OVERFLOW MONITORING TO BE
SUSPENDED. THE MONITORING IS PERFORMED FOR ALL STATEMENTS BETWEEN
THE TWO 'EXECUTES. OVF'l NAMES A CLOSE WHICH WILL BE INVOKED WHEN AN
OVERFLOW OCCURS"
SHUT AIRFIELDS
70
PROC lOCSOPEN'INP(NAME'OF'FILE) $ "OPEN INPUT SERVICE"
'ENTRANCE ICCSCPEN'OUT (NAME'OF'FILE) $ "OPEN INPUT SERVICE"
ITEM NAME'OF'FILE H 24 $ "HOLLERITH FILE NAME"
'ENTRANCE IOCSINP (=FILESTAT) $ "INPUT SERVICE"
'ENTRANCE IOCSOUT ( ) $ "OUTPUT SERVICE"
•ENTRANCE IOCSINS () $ "INSERT SERVICE"
'ENTRANCE IOCSDELO $ "DELETE SERVICE"
'ENTRANCE lOCSSHUT'lNP S "SHUT SERVICE FOR INPUT"
ITEM FILESTAT I 32 S $ "FILE STATUS FLAG"
BEGIN "IOCS COMPLEX"
"WORKING PARAMS"
ITEM FPT'INDEX I 32 U $
ITEM SYSIND I 32 S $
lOCSOPEN'INP.
"LOOK UP NAME'OF'FILE IN FPT TO FIND INDEX OF ENTRY WITH NAME'OF'FILE'
FOR I = ALL (FILENAME) $
BEGIN
IF FILENAME ($ 1$) EQ NAME'OF'FILE $
BEGIN
FPT'INDEX = I $
GOTO IOCSOPEN' I $
END
END
"NAME'OF'FILE NOT IN FPT — ERROR CODE HERE"
IOCSOPEN'1.
"NOW MOVE FPT ENTRY AT FPT'INDEX TO FPTW ENTRY AT 'FILENUM FOR LATER
EASE OF ACCESS"
ENTRY (FPTW ($ 'FILENUM $) = ENTRY (FPT ($ FPT 'INDEX $)) $
"NOW GO ASSIGN (AND POSITION) DEVICE AND RESERVE BUFFER SPACE
IOBSOPEN'INP()$
RETURN $
"END OF lOCSOPEN'INP^'
IOCSINP. "CODE FOR INPUT SERVICE"
"GET THE NEXT LOGICAL RECORD"
IOBSINP( = SYSIND) $
"WAS THERE A TRANSMISSION ERROR"
IF SYSIND EQ -1 $
FILESTAT = SYSIND $
"WAS THERE AN END OF FILE"
IF SYSIND EQ -2$
FILESTAT = SYSIND $
"TRANSMISSION WAS OK — NOW MOVE BUFFER TO IO
OPERAND (S) SPECIFIED IN INPUT STATEMENT"
TBL (SYSBUF, SYSIND, FUNC'REC'LENGTHW($'FILENUM $) ) $
RETURN $
"END OF IOCSINP"
71
lOCSSHUT'lNP. "ENTRANCE TO SHUT FILE"
IF DEVICE W ($ ' FILENUM $) LS 8 $
BEGIN "REWIND TAPE"
WAIT'SHUTo
'EXECUTE STAT'CHECK ( = TEMPI)
($ DEVICEW ( $ 'FILENUM $) $)$
IF TEMPI EQ 0 $ GOTO WAIT'SHUT $
"INITIATE REWIND"
'EXECUTE REWIND ( )
($ DEVICEW ($ ' FILENUM $ ) $
END
"NOW UNRESERVE DEVICE"
DFA ($ DEVICE ($ 'FILENUM $) $) = 0 $
RETURN $
"NOTE —
DEVICE PROCEDURE
STAT'CHECK ( = STAT)
IS PERFORMED INSTANTANEOUSLY
STAT = 1
IF DEVICE READY WITH NO ERRORS
= 2
IF DEVICE READY BUT LAST TRANSMISSION OPERATION
RESULTED IN ERROR
= 3
IF DEVICE READY BUT LAST TRANSMISSION WAS A
READ WHICH ENCOUNTERED AN END OF FILE MARK
= 0
IF DEVICE NOT READY
STAT TAKES ONLY 0 AND 1 AS VALUES IF THE LAST OPERATION ON THE
DEVICE WAS NOT A TRANSMISSION (e.g., REWIND)
PROC lOBSOPEN'INP ( ) "ASSIGN DEVICE AND POSITION"
'ENTRANCE IOBSINP ( = SYSBUF'INDEX) $
ITEM SYSBUF'INDEX I 32 S $
BEGIN "IOBS COMPLEX"
ITEM TEMPI I 32 U $
ITEM TEMP2 I 32 U $
"CODE FOR lOBS'OPEN'INP FOLLOWS"
"CHECK TO SEE IF DEVICE HAS ALREADY BEEN ASSOCIATED WITH A FILE"
IF DFA ($ DEVICEW ($'FILENUM$) $ ) $
BEGIN "IN USE"
"ERROR CODE HERE"
END
"NOW SET DFA TO SHOW DEVICE IS ASSIGNED TO FILE. ALSO SET DF TO VALUE
OF FILENUM OF ASSOCIATED FILE"
DFA ($ DEVICEW ($ 'FILENUM $) $) = 1 $
DF ($ DEVICEW ($ 'FILENUM $) $) = 'FILENUM $
"NOW FIGURE OUT HOW MUCH BUFFER SPACE TO GET"
72
TEMP 1 =
FUNCRECLENGTH W ($ 'FILENUM $) *
FUNCS'PER'REPW ($ 'FILENUM $) + 1 $
"GET INDEX IN SYSBUF OF FIRST WORD OF BUFFER COMPLEX FOR THIS FILE"
TEMPI = RESERVE'SYSBUF (TEMPI) $
"NOTE RESERVE'SYSBUF IS A SYSTEM FUNCTION DESIGNED TO ALLOCATE
SPACE, AS SPECIFIED BY AN INPUT PARAM, IN SYSBUF. THE VALUE OF THIS
FUNCTION AFTER EXECUTION IS THE SYSBUF FIRST WORD INDEX"
"SET THIS INDEX UP IN BFT"
BFC($ 'FILENUM $) = TEMPI $
"NOW DO DEVICE POSITIONING. IF TAPE, REWIND, IF DISK, DO NOTHING.
FIRST, WAIT FOR UNIT TO COME READY"
WAIT'O.
'EXECUTE STAT'CHECK ( = TEMPI)
($ DEVICEW ($ FILENUM $) $) $
"WAIT LOOP"
IF TEMPI EQ 0$
GOTO WAIT'O $
IF DEVICEW ($ ' FILENUM $) LS 8 $ "TAPE OR DISK"
BEGIN "TAPE, INITIATE REWIND"
'EXECUTE REWIND ( ) ($ DEVICEW ($ ' FILENUM $) $) $
"BEGIN WAIT LOOP"
WAIT'l. "STAT'CHECK IS INSTANTANEOUS"
'EXECUTE STAT'CHECK ( = TEMPI)
($ DEVICEW ($ ' FILENUM $) $) $
IF TEMPI EQ 0 $ GOTO WAIT'l $
"END REWIND WHEN TEMPI EQ 0"
"NOW INITIATE TAPE POSITIONING"
'EXECUTE
SKIP'FILES'FORWARD (BASE'NUM ($ 'FILENUM $))
($ DEVICEW ($ 'FILENUM $) $) $
WAIT'2. "WAIT TILL DONE --NOOP IF BASENUM = 0"
'EXECUTE STAT'CHECK ( = TEMPI)
($ DEVICEW ($ ' FILENUM $) $) $
IF TEMPI EQ 0 $ GOTO WAIT'2 $
RETURN $ "END OF SKIP'FILE'FORWARD"
END
"NOW START INPUT INTO BUFFER"
IOBS READ ('FILENUM, BASE'NUMW ($ ' FILENUM $) ) $
"NOTE BASE'NUMW ABOVE WILL NOT BE USED BY IOBSREAD IF DEVICE IS TAPE"
RETURN $ "END IOBSOPEN' INP"
IOBSINP. "ENTRANCE TO IOBS FOR 'INPUT' SERVICE CALL"
TEMP2 = REM (POS, FUNCS'PER'REPW ($ 'FILENUM $) ) $
"TEMP 2 NOW CONTAINS THE ORDINAL OF THE FUNCTIONAL RECORD IN
THE BUFFER"
73
IF TEMP2 NQ 1$
BEGIN "A READ WAS INITIATED PREVIOUSLY"
WAIT'INP.
IF SYSBUF ($ BFC ($ 'FILENUM $) $) EQ 0$
GOTO WAIT'INP $ "BUFFER IS STILL FILLING"
"WHEN DONE, TEST FOR EOF"
IF SYSBUF ($ BFC ($ ' FILENUM $) $) EQ 3 $
BEGIN
"CODE TO PROCESS END OF FILE"
END
"NOW TEST FOR TRANSMISSION ERROR "
IF SYSBUF ($ BFC ($ ' FILENUM $) $) EQ 2 $
BEGIN
"CODE TO PROCESS ERROR"
END
END "BUFFER IS FILLED"
"NOW COMPUTE BUFFER ADR"
SYSBUF'INDEX = BCF ($ 'FILENUM $) + FUNC'REC'LENGTHW ($ 'FILENUM $) *
TEMP2 + 1 $
"INCREMENT POS"
POS = POS + 1
$
"NOW TEST TO SEE IF BUFFER NEEDS FILLING"
TEMP 2 = REM (POS, FUNCS'PER'REPW ( $ 'FILENUM $)) $
IF REMEQ 0$
BEGIN
"IF DISK, COMPUTE NEW DISK ADDRESS AND STORE IN TEMP 2"
IOBS READ ('FILENUM, TEMP2 ) $
END
"RETURN —ALL DONE"
END "IOBSINP"
"READ COMPLETION ROUTINE"
PROC ENDREAD () $
ITEM TEMP I 32 S $
BEGIN
"FIND OUT WHICH DEVICE CAUSED INTERRUPT"
'EXECUTE WHICH ( = TEMP) ($ 0 $)
"DEVICE PROCEDURE 'WHICH' IS INSTANTANEOUS. IT ASKS THE
CPU 'DEVICE' WHICH OTHER DEVICE CAUSED THE LAST INTERRUPT.
THE ANSWER IS PLACED IN TEMP"
"NOW DO STATUS CHECK — PLACE STATUS IN BUFFER CONTROL WORD"
'EXECUTE STAT'CHECK
( = SYSBUF ($ BCF ($ DF ($ TEMP $) $) $) )
($ TEMP $)
"RETURN"
END
74
PROC IOBSREAD (NFILE, DISKADR)
ITEM NFILE I 32 S $
ITEM DISKADR I 32 U $
BEGIN
ITEM TEMPI I 32 S $
"FIRST SET BUFFER CONTROL WORD TO 0 -- BUFFER WILL BE FILLING WHEN WE
EXIT THIS PROC"
SYSBUF ($ BFC ($ NFILE $) $) = 0 $
"IS DEVICE DISK OR TAPE"
IF DEVICEW ($ NFILE $) LS 8 $ "TAPE"
GOTO TAPE'READ.
DISK'READ. "WAIT FOR DISK READY"
'EXECUTE STAT'CHECK ( - TEMPI)
($ DEVICEW ($ NFILE$)$)$
IF TEMPI EQ 0 $ GOTO DISK'READ $
"NOW INITIATE DISK READ -- NOTE THAT THE DEVICE PROCEDURE
READ DISK IS NON-INSTANTANEOUS"
'EXECUTE READDISK ( DISKADR, "DISK ADDRESS"
"NUM WORDS TO READ" FUNC'REC'LENGTHW ($NFILE$)*
FUNCS'PER'REPW ($NFILE$),
"CORE LOCATION OF BUFFER" *LOC ( SYSBUF) + BFC ($ NFILE $) + 1 ) $
"DEVICE" ($ DEVICEW ($ NFILES) $)
"COMPLETION ROUTINE" ENDREAD () $
RETURN $
TAPE'READ. "WAIT FOR TAPE READY"
'EXECUTE STAT'CHECK ( = TEMPI)
($ DEVICEW ($ NFILE$) $) $
IF TEMPI EQ 0 $ GOTO TAPE'READ $
"NOW INITIATE TAPE READ — DEVICE PROCEDURE IS NON-INSTANTANEOUS"
'EXECUTE READTAPE ( FUNC'REC'LENGTHW ($NFILE$)*
"NUM WORDS TO READ" FUNCS'PER'REP ($ NFILE$),
"CORE BUFFER ADDRESS" 'LOC (SYSBUF) + BFC ($NFILE$) + 1 ) $
"DEVICE"
($ DEVICEW ($ NFILE$) $)
"COMPLETION ROUTINE" ENDREAD ( ) $
"RETURN"
END "IOBSREAD"
75
3.2.2.12 The Stop:statement
The stop:statement has the form:
STOP 6 $
A stop:statement has the effect of terminating the sequence of executions initiated
when the main:program began executing. This is true whether or not the stop:statement
is executed in the main:program or in a closed subroutine subordinate to the ma in: program.
The stop:statement in a closed subroutine does not cause control to pass to the calling
program.
3.2.2.13 The Pause:statement
A pause:statement is:
PAUSE 8 statement:name 8
optional:service:call 8 $
When a pause:statement is executed/ the serv?ce:call, if included, is operated. Upon
completion of the service:call execution, the sequence of executions initiated when the
main:program began executing is suspended. This is true whether or not the pause:statement
was executed in the main:program or in one of the closed subroutines subordinate to it.
When execution is restarted by some external means, the first statement executed is the
one labelled by statement: name. Note that the execution of a pause statement which
has no serv?ce:call takes place in the same manner as above except, of course, that
there is no service:call operation. It is anticipated that a common use of the service:call
will be to output some sort of identification information (e.g. to the printer).
3.2.2.14 Rounded:assignment:statements
A rounded:ass?gnment:statement has the form:
numeric:variable 8 = 6
numer?c:formula 8 'ROUNDED 8 $
The rounded:assignment:statement produces exactly the same result when the evaluated
numeric:formula is assigned to the numeric:varioble as would be obtained if the numeric:
variable were declared in an item:declaration with the abbreviation R. (ROUNDED has
no effect if indeed numeric:variable was declared in an ?tem:declaration with the
abbreviation R.)
76
3.2.2.15 Extension to Program
Program means:
START 9 optionahorigin 9$
0 statement:list 9
TERM 9 optional:statement:name 0 $
or:
CLOSE 0 name 9
START 9 optionahorigin 9 $
statement:list 9 TERM 9 $
or:
START optionahorigin 9 procedure:declaration 0
TERM 0 $
The meaning of the first two forms is given in CED 2487.1 . The third form provides the
facility for compiling "stand-alone" procedures. The effect of optionahorigin is the
same as for the first two forms. The program defined by the third form has the same name
as the procedure:name in the procedure:declaration. The program may also be referenced
by the alternate:entrance:name which appears in any alternate:procedure:entrance:
declaration. A program defined by the third form is invoked precisely as any procedure.
Also, the procedure:name and any alternate:entrance:names are category 3 names.
3.2.3
Nucleus Features
Based on the criteria as described in Section 1 (1.3) and the users responses to the
JOVIAL Application Questionnaire and Interview questions (contained in Appendix 3)
as summarized in Appendix 2 and 4, respectively, the following features are recommended
for inclusion in the nucleus. The references are to the appropriate sub-sections of the
JOVIAL Application Questionnaire (JAQ), Section 3 of this report (Section 3), Interview
Response Analysis in Appendix 4(1), and the Approach for Change (AFC) . Specification of each feature is contained in the JOVIAL Application Questionnaire for the current
JOVIAL features considered and in Section 3 for recommended extentions. Justification
for inclusion of features as a nucleus is contained in Appendix 2 (which is organized
by AFC numbers) and Appendix 4 (which is organized by I numbers).
11
Feature
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
Item Type Hollerith
Hollerith Formula
Character Data Size Attribute
Operations on Literal Data
Explicit Size Attribute
Structure Table
Rigid
Table Variability Attribute
Table Variability Attribute
Variable
NENT
BYTE
Subscripting - Expressed as Complex
omplex
Numeric Formula
Subscripting - Nested
Table Entry Referencing
(ENTRY only may be used)
Computer Representation of Data
ata
Computer Representation of Numeric
Items and Constants
Octal Constants, Hexadecimal Constant
(Must implement one or the other,
may implement both)
Basic Table Structure Attribute-Parallel
Basic Table Structure Attribute - Serial
Defined (Table) Packing
Independent Overlay Declaration
'LOC
Parenthesized Numeric Formulas
Mixed Item Types in Numeric Formulas
Item Type Integer
Item Type Fixed Point
Item Type Fixed Point - Scale in
Declaration Blank or Zero
Item Type Floating Point
Sign Attribute
Prefix + and Precedence of Unary Operators
(Alteration of precedence of +, -)
Exponentiation Operator (Noration**only)
Relational Formulas (excluding chained)
Boolean Formulas - with AND, OR, NOT
Item Type Boolean
Numeric Item Type Conversion in the
Assignment Statement
1
78
JAQ/Sec. 3
AFC/I
J3.5.1.1.11.1
J3.5.2.5
J3.5.1.1.14
3.2.2.4
J3.5.1.1.14
J3.5.1.3.1
J3.5.1.3.4
J3.5.1.3.4
J3.5.2.2.2.6
J3.5.2.2.2.2
Al.1.1.1
Al.1.1.1
Al.1.1.3
1 3,17
Al.1.3
Al.2.2
Al.2.3
Al.2.3
Al.2.3
A2.2
J3.5.2.2.1
J3.5.2.2.1
A2.4
A2.4
J3.5.2.6
J3.5.1.1.15
A2.5
A3
3.2.2.5
111
J3.5.1.1.1
3.2.2.1
J3.5.1.3.5
J3.5.1.3.5
J3.5.1.3.6.2
J3.5.1.7.1
J3.5.2.1.1
J3.5.2.3.1
J3.5.2.3.5
J3.5.1.1.4
J3.5.1.1.5
A3.1,1 12
A3.3
A3.3
A3.5
A3.6
A3.8
A4
A4
A4
A4
J3.5.1.1.5
J3.5.1.1.9
J3.5.1.1.6
J3.5.2.3.2
A4
A4
A4.4
A4.5
3.2.26
J3.5.2.3.3
J3.5.2.7
J3.5.2.8
J3.5.1.1.12
1 17
A4.5
A6.1
A7.1
A7.2
J3.5.3.1
A8
Feature
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
3.2.4
Boolean Assignment Statement
Item Preset
Table Preset
Compound Statement
GOTO Statement
STOP Statement
IF Statement
FOR-loop-One Factor
FOR-loop-Two Factor
FOR-loop-Three Factor
FOR-loop-Decrementing
Test Statement
Program
Procedure (Excluding Function)
Function
Alternate Entrances to Procedures
and Functions
Close
Return Statement
Direct Code
Data Editing and Conversion
Multiple Statement Labels
ALL
COMPOOL
JAQ/Sec. 3
AFC/I
J3.5.3.1
J3.5.1.6.1
J3.5.1.6.2
J3.5.4.2
J3.5.5
3.2.2.12
J3.5.5.3
J3.5.5.5
J3.5.5.5
J3.5.5.5
J3.5.5.5
J3.5.5.5.6
J3.5.4.10
J3.5.4.6
J3.5.4.8
A8
A8.1
A8.1
A9.1
A9.2
A9.3J 24
A9.4.1
A9.5
A9.5
A9.5
A9.5
A9.5.4
A9.6,A9.
A9.6.1
A9.6.1
3.2.2.9
J3.5.4.5
J3.5.5.6
J3.5.4.4
3.2.2.11.3
J3.5.4.3
J3.5.5.5.5
J3.5.6.1
1 28
A9.6.2
A9.6.3
A9.8
1 31
All.2
A12.5
A12.6
Optional Features
Based on the same criteria and data as indicated in Section 3.2.3 above, the following
features are recommended for the optional category.
Feature
1)
2)
3)
4)
5)
6)
7)
8)
9)
Hexidecimal Constants
Simplified Hollerith Constant Form
User Definable Character Encoding
Scheme ('CHARCODE)
Item Type Status
Status Formulas (Must be implemented
together)
Explicit Status Size Attribute
Structure Array
NWDSEN
BIT
79
JAQ/Sec. 3
AFC/I
3.2.2.1
3.2.2.2
1 12
-
3.2.2.3
J3.5.1.1.13
1 2
Al.1.2
J3.5.2.5
J3.5.1.1.14
J3.5.1.2
J3.5.2.1.2
J3.5.2.2.2.1
Al.1.2
Al .1.3
Al .2.1
Al.2.4
A2.1
Feature
JAQ/Sec. 3
AFC/I
J3.5.1.3.6.1
A3.4
J3.5.2.3.4
A4.7
3.2.2.10
J3.5.2.7
J3.5.1.6.3
J3.5.3.2
J3.5.5.4
J3.5.5.2
J3.5.5.1
J3.5.4.6
1 16
A6.2
A8.1
A8.3
A9.4.2
A9.4.3
A9.4.4
A9.6.1
J3.5.4.6
J3.5.4.11
J3.5.1.1.2.2
J3.5.6.2
3.2.2.7
J3.5.1.1.3
3.2.2.8
J3.5.1.3.2
3.2.2.11.1
3.2.2.11.2
3.2.2.13
A9.6.1
A9.7
All .1
A12.1
1 35
A12.2
A12.2J 36
A12.4
1 33
1 32
125
21)
22)
23)
24)
25)
26)
27)
28)
29)
30)
Ordinary Packing (Dense only is allowed)
Absolute Value Operator
(ABS only is allowed)
Extended Precision Numeric Items
and Constants
Chained Relational Formulas
Array Preset
Exchange Statement
IFEITH/ORIF Statements
Index Switch
Item Switch
Close in Parameter List (of Procedure)
Statement Label in Parameter List
(of Procedure)
'PROGRAM Declaration
Item Declaration
Define Directive
Extended Define Directive
MODE Directive
Extended Mode Directive
Like Table Declaration
Device oriented Input/Output Module
Functional File Input/Output Module
Pause Statement
31)
Extension to Program ("Stand-alone" Procedure)3.2.2.15
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
80
SECTION IV
ADDITIONAL RECOMMENDATIONS
4.1
Specific Study Topics
During the course of the interviews several unplanned for auxiliary topics of unusual
interest were discussed. Some of these subjects were concerned with general language
aspects, others with specific required features, and still others with implementation
constraints. Following is a list of the more important concepts raised in the discussions,
the details of which are included in Appendix 1 . DDI strongly recommends in-depth
studies of all of the concepts for possible inclusion in future JOVIAL language extensions.
4.2
General Concepts
1.
2.
3.
4.
5.
4.3
JOVIAL Input/Output - Many comments were made indicating that some
JOVIAL input/output specification should be included in the language.
DDI has included a set input/output specifications in the Extension Specifications, however, further effort is required to increase the comprehensiveness
of these specifications.
JOVIAL Library - It was recommended that a standard JOVIAL Source
Language Library should be generated and available to all users.
JOVIAL COMPOOL - It was proposed that the COMPOOL be rigidly
specified in the language rather than permitting individual interpretations
of the concept by the implementors of the JOVIAL language.
Real Time Concepts - It was suggested that statements facilitating real
time applications should be included in the language.
List Processing - It was proposed that some of the notions associated with
the concepts of list processing should be included in this language.
Specific Concepts
The following specific functions were recommended for inclusion in the JOVIAL language:
1 .
2.
3.
4.
5.
6.
7.
Bit string items with associated bit string operations.
Expanded data structuring and associated data referencing concepts.
Loader and Compiler Directives.
Implied subjects and objects in IF statements.
Expanded character set.
Multiple assignment statement.
Non-linear loop incrementing.
81
4.4
Language/Compiler Design Goals
During discussions the following general language and compiler design goals were
considered worthy of further investigation:
1.
2.
3.
4.
5.
Attainment of absolute machine independence.
Improved readability of JOVIAL computer programs.
Less verbose.
Separate function from functional software.
Compatibility with manufacturer software.
82
APPENDIX I
INTERVIEW MATERIAL
This appendix contains a list of the agencies and firms who participated in the study
together with information regarding their JOVIAL Application Questionnaire and
interview responses. DDI interviewed ten military agencies, two industrial firms,
and one non-military governmental agency in this study. Following is a list of those
organizations interviewed together with associated abbreviations that are used to
identify them throughout this and associated documents.
1 .
2.
3.
4.
5.
6.
7.
8.
ADC Computer Programming and Analysis Center
Ent Air Force Base
Colorado Springs, Colorado
-ADPAC
Computer Sciences Corporation
650 N. Sepulveda Boulevard
El Segundo, California
-CSC
Federal Aviation Agency
800 Independence Avenue, S.W.
Washington, D.C.
-FAA
FOCCPAC
U.S. Navy
Honolulu, Hawaii
-FOCC
Operational Program Maintenance Branch
4th Air Force Combat Center
Hamilton Air Force Base
San Francisco, California
-HAM
NAVCOSSACT
Washington Naval Yard Annex
Washington, D.C.
-NAVC
National Civilian Defense Computer Facility
Olney, Maryland
-NCDCF
Naval Electronics Laboratory
Command and Control Facility
San Diego, California
-NEL
83
9.
10.
11 .
12.
13
Defense Communication Agency
Naval Military Command System Support Center
Pentagon
Washington, D. C.
-NMCSSC
Headquarters NORAD
NHCP
Ent Air Force Base
Colorado Springs, Colorado
-NHCP
Rome Air Development Center
Griffiss Air Force Base
Rome, New York
-RADC
Headquarters SAC
Offutt Air Force Base
Nebraska
-SAC
Trans World Airways Data Processing Center
King Road
Rockleigh, New Jersey
-TWA
The selected organizations responded to the JOVIAL Application Questionnaire
(JAQ) in varying degrees of detail. Some responded qualitatively, some quantatively, and some not at all. Following is a summary of the responses to the JAQ
by the selected respondents:
1 .
2.
ADPACCSCFAA-
4.
5.
6.
7.
8.
9.
10.
FOCCHAMNAVCNCDCFNELNMCSSC
NHCP-
11.
RADC-
12.
SAC-
13.
TWA-
Complete quantitative response to three JAQ's.
No JAQ usage rates because of CSC's role as a
JOVIAL compiler writer rather than a JOVIAL user.
No JAQ usage rates were given; only qualitative
results were provided.
Complete quantitative responses to three JAQ's.
Complete quantitative responses to one JAQ.
Complete quantitative responses to three JAQ's.
Complete quantitative responses to one JAQ.
Complete quantitative responses to one JAQ.
Complete quantitative responses to one JAQ.
Responses received too late to be considered for
analysis.
Complete quantitative information was returned on
three of the four JAQ's.
Complete quantitative information was provided on
four JAQ's.
Because of a tight schedule, TWA did not complete
their JAQ.
84
Each of the numbered sections that follow contain information summarizing the results
obtained from each respondent. A complete description of the respondent is given,
his response to the JAQ is noted, any written interview material is included and notes
are provided that reflect general impressions gathered from the questionnaire and interview. The respondents are listed in each section according to the sequence indicated
above. Each of the sections containing data from the respondent is organized according
to the following outline:
1.
2.
3.
4.
5.
6.
7.
Organization ContactOrganization IdentifierNumber of JAQ's returned Date of Interview JAQ Response Notes Application -
8.
Interview Notes -
Particular application for specific agency.
Organization representative.
Organization abbreviation.
Self Explanatory.
Self Explanatory.
Comments about the response to the JAQ.
Information about each application
responded to in a JAQ.
Statements of actual interview responses or
interpretations of interview responses if
required.
1.0
ADPAC
1.1
Organization:
ADC Computer Programming and Analysis Center
ADPAC
Ent Air Force Base
Colorado Springs, Colorado
1.2
Contact:
Lt. Jan Feller
1 .3
Organization Identifier:
ADPAC
1.4
Number of JAQ's Returned:
4
1 .5
Date of Interview:
14 May 1968
1 .6
JAQ Response Notes:
Three of the JAQ's returned contain response data for three distinct subapplications. These are identified by ADPAC-1, ADPAC-2, ADPAC-3. There
is one compiler for all sub-applications. Compliance information was taken
from the JAQ for ADPAC-3.
1 .7
Application:
(1) Sub-application ADPAC-1
85
Sub-application Name:
Special Programs Section
Sub-application Description:
Data reduction and analysis for radar evaluation and SNOWTIME. The sub-application
includes editing, statistical calculation and data extraction. Sub-application currently
consists of 7 computer programs with more expected to be started in the near future.
Some computer programs were converted from COBOL.
Total Number of JOVIAL Statements:
5462
Sub-application Hardware Configuration:
Operating System:
See under ADPAC-2.
No information given.
Background:
JOVIAL was used because it was the language best suited for the project.
Average years experience of programmers: 3
Average years JOVIAL experience: 1
Dialect used: JOVIAL J3
Compilation speed: Not given.
Compiled code: Not relocatable.
(2)
Sub-application ADPAC-2
Sub-application Name:
SPACE TRACK
Sub-application description:
The objective of the sub-application is to maintain surveillance of all earth orbiting
objects.
Total Number of JOVIAL Statements:
Computer manufacturer and model
1400 (Approx.)
Philco 2000/212
High speed memory storage
Size
Word size if applicable
32K words
256K six bit bytes
48 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
Bryant
10,000,0008 six bit bytes
2
86
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
0
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
Ampex
14
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
0
IBM
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
Philco
1,000 lines/min
1
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
0
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
0
Operating system:
Name:
DELTA
Developer: SDC
Mode of operating system:
Batch Processing and Real Time
Background:
•
•
•
JOVIAL was used because it was the official Air Force language.
Average years experience of programmers: SDC - 5, Military - 3
Average years JOVIAL experience: SDC - 5, Military - 1
87
Dialect used:
JOVIAL J3
Compilation speed:
Compiled Code:
(3)
Not given.
"Applications are all RPL".
Sub-application ADPAC-3
Sub-application Name:
Satellite Archives - Storage and Retrieval
Sub-application Description:
The purpose of the sub-application is to store and retrieve satellite observations and
element sets. The current Archives system programs are for the most part written in
TAC. Only one short program has been written in JOVIAL but plans for the future
involve rewriting of all programs in JOVIAL.
Total Number of JOVIAL Statements:
278
Sub-application Hardware Configuration:
See under ADPAC-2
Operating System:
Name: COSMOS
Developer: SDC
Mode of operation:
Batch processing
Background:
•
JOVIAL was used to stay compatible with other projects and because it was the
official Air Force language.
Average years experience of programmers: 6
Average years JOVIAL experience: Not given
Dialect used:
J3
Compilation speed:
Not given
Compiled code: Not given
1.8
Interview Notes:
The following written information was received at the time of the interview.
General:
•
We have three areas of application. The largest, 80% of our JOVIAL programs
is SPADATS(496L). The Special Projects Section has 15%. The smallest is
Archives with 5%.
88
•
Technical data on the status of our compiler is contained in the Archives booklet.
A description of JOVIAL library routines and diagnostic messages is included.
Also included is a sample output and user instructions for the utility routine
REFORM.
•
Conclusions: Judging from our usage of JOVIAL two subsets would seem to be
needed. One an extension of AFM 100-24 JOVIAL to facilitate scientific data
analysis; the second a limited version without many of the features of AFM 100-24
for use in specific applications within real time systems which require extremely
efficient code and minimum core utilization. It would also seem desirable to
include specifications and minimum number of routines for the JOVIAL library.
HQ ADC, ADPAC, Special Programs Section
•
JOVIAL programming in the Special Programs Section started in August 1967.
The first implementation was the Radar Evaluation System. A limited version had
been implemented in COBOL. It was desired to include more extensive calculations, which could not be done in COBOL. Both FORTRAN and JOVIAL were
considered. Because of the greater power and flexibility of JOVIAL it was
selected.
•
The JOVIAL features which were significant in this decision were:
The ability to move and use data by BYTE modification.
The ability to pack data in core tables and in tape records.
The ability to imbed arithmetic operations in subscripting and in operations,
such as, BYTE($10 + A*3$) where A is a loop variable.
The ability to overlay data.
The define statement.
The ability to do manual conversion of input data enabling the same data fields
to be used for both numeric and alphabetic data.
•
Further JOVIAL programs are being written for the SNOWTIME data analysis
series. Plans call for placing the ADPAC status report in JOVIAL.
•
The following changes were proposed for JOVIAL:
Add carraige control option for printed output.
Expand features for conversion of numeric input/output to include signs and
decimal points.
89
Greater detail in diagnostics. Too many merely state that there is an error
without specifying the exact problems.
HQ ADC, ADPAC SPACE TRACK 496L
Computer programs are mostly in TAC (Philco 2000 assembly language) at the present.
As major changes are made to the computer programs they are being written in JOVIAL.
The following changes to JOVIAL were indicated to be highly desirable:
The capability to overlay COMPOOL defined items and tables with program defined
items and tables.
For integer by integer division the fractional bits should be preserved according
to the resulting defined integer.
JOVIAL I/O should include the option of having automatic conversion of numeric
items, like that in FORTRAN.
AFM 100-24 should include specifications for a standard JOVIAL library.
There should be a JOVIAL subset which is more limited than that of AFM 100-24.
The purpose being to produce extremely efficicient code, both core size and
execution time. This is needed for real time systems.
A traceback routine should be included for program error halts to aid in determining
the cause.
GEN2 diagnostics should give the line number.
When possible diagnostics should indicate the specific column which contains the
error.
Other Comments:
In addition to the written information, ADPAC personnel made the following statements:
•
It would be desirable to have the facility to apply the BYTE functional modifier
to an operand designated by the ENTRY functional modifier:
BYTE ($3,5$) (ENTRY(TABLE'NAME,3))
•
The NENT word should be located in some place other than word 0 of the table.
•
One ought to be able to use parentheses instead of the subscript brackets ($ and $).
90
•
It is felt that more should be said in AFM 100-24 about COMPOOL and Libraries.
•
A Hollerith constant form. - H(characters) ought to be provided.
•
A facility for specifying assignment without automatic conversion should be
supplied.
•
The FOR loop feature should be set up in such a way as to provide for testing prior
to the first iteration .
•
"Stringed" item declarations are desired:
ITEM AA, BB, CC
I
48 S $
•
Arrays with rows and column lengths and dimensions variable at run time would be
helpful.
2.0
CSC
2.1
Organization:
Computer Sciences Corporation
650 N. Sepulveda
El Segundo, California
2.2
Contact:
Mr. Terry Dunbar
2.3
Organization Identifier:
CSC
2.4
Number of JAQ's Returned:
1
2.5
Date of Interview:
11 July 1968
2.6
JAQ Response Notes:
The JAQ returned contained no usage rates. This is because, for the purposes of
this study, CSC was considered only in its role of compiler writer; the implementation information in the returned JAQ pertains to a compiler produced by means of
CSC's GENESIS system for the IBM System 360.
Compiler Hardware Configuration:
IBM System 360
Storage (Memory) 256K 8 bit bytes
Operating System:
Name: OS
Developer:
IBM
Mode of Operating System:
Batch Processing
91
2.7
Application:
Not applicable
2.8
Interview Notes:
Because CSC was being interviewed in the role of compiler implementor, the
usual interview format was suspended. Instead, an informal discussion regarding
the implementation of features took place. Acknowledgement is made to
Mr. Dunbar for his excellent remarks in this area.
•
The standard as described in AFM 100-24 implies an "all or nothing" implementation effort. Implementation "levels" or a feature or function module approach
would be preferable.
•
To achieve full compliance with AFM 100-24's "signed magnitude" fixed point
number convention is an extremely expensive proposition.
•
Full implementation of fixed point representation is very expensive.
•
Implementation of rounding is expensive.
•
Extended capabilities should be provided for "modelling" the computer memory,
other than simply the notion of "words". System 360 has, in effect, four addressable units (bytes, half-, full-, and double-word) and also the notion of word
boundaries, for example. An extended memory modelling capability would probably result in the generation of more efficient object code.
•
Standard JOVIAL J3 array presetting is inefficient in that array elements are
input in an order differing from the allocation order; and that there is no way for
the programmer to "skip" overelements he does not desire to preset.
•
AFM 100-24 should be rewritten. It is overly cumbersome for the compiler
implementor; also certain "holes" exist in the presentation.
•
In general, there are too many specific representation requirements to which the
implementor must adhere. Frequently, a property of a given machine will lend
itself to a more economic representation than that required in AFM 100-24.
In addition to the above remarks, Mr. Dunbar has provided a list of loop-holes and
ambiguities which CSC has encountered in implementing JOVIAL compilers based on
AFM 100-24. This list shows interpretations which CSC has made in order to implement
compilers. Also shown are certain comments regarding the JOVIAL J3 compiler specifications, not included in this study. DDI feels that this list is very important in that
it sheds light on problem areas which only an implementor might be expected to discover.
For this reason, we incorporate the following comments from CSC into this report.
92
CED-2400 as a contractual document leaves much to be desired as there are many areas
which are not covered at all or are ambiguous. The following is a list of these areas
and the interpretation we (CSC) are taking. Also included are exceptions that must be
taken because of incompatibilities with the hardware. Each item on the list references
CED-2400 by section and page.
1)
The floating point description has an error in it; part of a sentence is missing,
leaving both the signicand and the exrad undefined. We use the hardware representation. (2416.7; p. 10)
2)
Null literal constants, i.e., 0 H(), 0 T(), 0(), are not defined.
all to be illegal. (2418.5, .8, .9; p. 11).
3)
The sign-magnitude effect is incompatible with most hardware. As filler bits
arose as a complement to sign-magnitude, the compiler will ignore them and
treat the bit to the left of BIT($ 1 S) as BIT (S 0 $) for reasons of efficient object
programs. (2419.1, .2,2426.6; p. 12,16).
4)
The precision and range of index variables are not defined. It should be stated
that each implementation specify precisely these attributes in the form of an
implied item declaration:
ITEM letter I n S $. (2426.5; p. 16).
5)
ODD (variable) shall be interpreted as the rightmost bit of the variable (2429;
p. 17-8).
6)
Index computation should not follow rules which differ from normal arithmetic
computation. It is unreasonable to compute a floating constant + fixed variable
as fixed. (2434.6; p. 20).
7)
Floating point rounding is not consistent with fixed-point rounding.
8)
LOC of a TABLE is not described clearly since it is defined in terms of a 'control
register1 which is undefined. We are defining LOC (TABLE) to be the address of
the first word in ENTRY (TABLE ($ 0 $)). (2434.10, .11; p. 20).
9)
Scaling
division
formula
clause.
We define them
(2434.6; p.20),
formulas are not complete nor well defined. In particular scaling for
has a missing formula, i.e., IR for A/I. Our interpretation changes
2435.11 (11) to read IR=IN+AD+1-MD., thus deleting the qualifying
(2435; p. 21-2).
10)
As a point of interest, it should be noted that mixing of literal formula types in
relational expressions, assignments, I/O, and presets involve no conversions.
(2437.2, 2442.4, 2443, 2447-9, 2470; p. 23,26-7, 29-31, 45).
1 1)
Although ENTRY variables are not excepted, they are meaningless as actual parameters. (2446.1a., .4a.; p. 28).
93
12)
Since "type" is referred to in several contexts without a definition, it is not
apparent whether it is up to the programmer or the compiler to ensure parameter
compatibility. A technical interpretation of CED-2400 would indicate that
actual and formal parameters must agree, thus requiring no conversions. However,
based upon historical JOVIAL and what we feel to be the intent of the author,
the compiler will generate code to ensure type compatibility for value parameters.
CED-2400 does not define the distinction between the data parameters passed by
name (tables and arrays) used as input parameters and those used as output parameters. We choose to make no distinction. (2446.7. .8; p. 28-9).
13)
Since the
mentation
for:clause
(2455; p.
14)
Array presets should be specified in allocation order and expanded. (2467; p.43).
15)
Type matching for literal item presetting seems overly restrictive. We intend to
permit complete mixing of literal values with literal items. (2470; p. 45).
16)
For defined entry table items, we will ignore the packing specifier. This interpretation was chosen to alleviate the problem arising when the specified allocation conflicts with the packing specifier. (2474-5; p. 50-2).
17)
CED-2400 does not define COMPOOL resolutions of like table items. Given an
explicit COMPOOL declaration and an implicit item declaration via a like table
declaration within the source program, resolution will be as follows:
a) If a reference to the name occurs before the declaration, the COMPOOL
declaration is used and a duplicate declaration exists.
b) If the like table declaration occurs before the reference, the implied
declaration holds. (2476; p. 53).
18)
Our interpretation of CED-2400 is that the manual precludes the use of optional
origins. (2479, 2487; p. 55,60).
19)
The index switch list syntax permits at most 2 consecutive null switch points. We
feel this is an error and not the intent of the author. The compiler will not restrict
the number consecutive null switch points except to the maximum switch points.
(2481.1; p. 56).
20)
Since the constants of an item switch list must be possible values of the switch
item, we interpret CED-2400 to mean that no conversions will be necessary.
(2482.1,.4; p. 56).
21)
Although it is not excepted by the manual, we will not permit presetting formal
parameters or a function result item. (2484-5; p. 57-9).
94
manual is not clear as to whether iteration means looprvariable increor iterative execution of the loop body, the definition of a onerfactor:
is ambiguous. In our compiler no iteration or looping will occur.
33-4).
22)
An "is" is interpreted as an "it".
(2484.9; p. 58).
23)
CED-2400 refers to a name before START; we interpret this to mean only the case
of a compile above CLOSE. (2487.16., 2489.3)
in addition the following exceptions are taken to Part 1 of CED-2400 on compiler
specifications.
1)
All mention of library, procedure library and library maintenance programs should
be taken in light of the fact that the standard computer manufacturer's operating
system, library and library maintenance will be used.
2)
Sequence numbers will not be assigned to statements as described; instead card
numbers will be used for error reporting. (3.2.1.8; p. 69)
3)
The compiler will not produce stand-alone programs.
4)
Control input will obey computer operating system, not JOVIAL, conventions.
(3.2.5; p. 70).
5)
Error detection, reporting, and correction will not be as described in CED-2400.
Error messages referencing card numbers will be output rather than error numbers.
Not reporting errors caused by a previous error is not always possible. Calls to
an error monitor procedure will not be generated. (3.2.6; p. 70-1).
6)
Equipment, operator, and monitor - error checking will be performed by and obey
computer operating system conventions.
7)
Compiler capacities and efficiency will be as described in the contract (3.2.9,
3.2.10; p. 71-2).
8)
Debug aids (listings) will not necessarily be as described in CED-2400. Alter update
will be performed by standard computer operating system routines. (3.2.11; p.72-4).
9)
COMPOOL will not conform exactly to the specifications in CED-2400. Arrays will
be permitted in the COMPOOL. COMPOOL addresses will be determined by the standard compiler algorithms and will be relocatable. There will be no COMPOOL
disassembly program as such. A storage map will be produced, optionally, as
part of the assembly process.
10)
3.0
(3.2.4; p. 70).
Documentation and quality assurance will be as specified in the contract (3.5,4.;p.75-79).
FAA
95
3.1
Organization:
FAA
800 Independence Avenue, S.W.
Washington, D.C.
3.2
Contact:
Mr. Donald Scheffler
3.3
Organization Identifier:
FAA
3.4
Number of JAQ's Returned:
1
3.5
Date of Interview:
9 May 1968
3.6
JAQ Response Notes:
•
Application name: Not given
•
Application description: Not given
NOTE:
It was learned at interview that the chief use of JOVIAL in the FAA is in
the National Air Space Program.
3.7
Application:
Hardware Configuration:
Computer manufacturer and model
IBM 7090
High speed memory storage
Size
Word size if applicable
32K words
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
None
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
None
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
96
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
Operating System:
Name: FORTRAN Monitor System
Developer:
IBM
Mode of Operation: Batch processing
Background:
JOVIAL was used because it was regarded as the language best suited for the project.
Average years experience of programmers: 5
Average years JOVIAL experience: 2
Dialect used: JOVIAL J2
Compilation speed: Unknown
Compiled code: Not relocatable .
Total Number of JOVIAL Statements:
NOTE:
Not given.
No counts or estimates of usages were given in the JAQ returned. Qualitative
phrases were used instead. We have quantified these phrases, as shown below:
97
Occasionally
Frequently
Almost Always
Never
Generally
Constantly
Always
None
Not Available
Rarely
Infrequently
Continually
3.8
.2
.8
.9
0
.5
.9
.9
0
0
.1
.2
.9
Interview Notes:
FAA feels it would be desirable to allow:
IF AA EQ BB,CC,DD
for IF AA EQ BB OR AA EQ CC OR AA EQ DD
4.0
FOCCPAC
4.1
Organization:
FOCCPAC
U.S. Navy
Honolulu, Hawaii
4.2
Contact:
Capt. Bishop
4.3
Organization Identifier:
FOCC
4.4
Number of JAQ's Returned:
4.5
Date of Interview:
4.6
JAQ Response Notes:
22 May 1968
Each of the two JAQ's returned contains responses for two distinct sub-applications.
These are identified by FOCC-1 and FOCC-2. Both run on the same computer and
use the same compiler. Compliance information was taken from the JAQ for FOCC-1
4.7
Application:
(1) Sub-application FOCC-1
Sub-application Name:
Patrol Report — NAVCOSSACT
Report 0193 11P027
98
Sub-application Description:
The purpose of the sub-application is to maintain a history of data pertaining to the
operations of Polaris Submarines and upon request to evaluate this data.
Total Number of JOVIAL Statements:
13,388
Sub-application Hardware Configuration:
Computer manufacturer and model
Control Data Corporation 1604A & 160A
160A
High speed memory storage
Size
Word size if applicable
1604A
16K(4 banks)
82K words
2/word(2 banks8/word six bit bytes
160A; 2 banks-169
core storage only)
12 bits
48 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
None
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
1301 IBM
28X10° six bit bytes
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
729 IV IBM
556 bits/in
800
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
1402 IBM
250 cards/min
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
1402 IBM
600 cards/min
9V
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
Control Data 350
350 frames/sec
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
Teletype BRPE 11
110 frames/sec
Operating System:
Name: MESIM
Developer: NAVCOSSACT
Mode of operation:
"UNIT"
NOTE: With the exception of compilations, al! programs are run individually,
each being manually loaded.
Background:
JOVIAL was used because it was considered the language best suited for the project.
Average years experience of programmers: 4
Average years JOVIAL experience:
1
Compilation speed: 210 statements per minute
Compiled code: Optionally relocatable
(2)
Sub-application FOCC-2
Sub-application Name: Afloat Cost, Consumption, Effectiveness Surveillance System
Sub-application Description:
The purpose of the sub-application is to collect and summarize basic financial consumption
data generated in the normal course of supply operations afloat.
Total Number of JOVIAL Statements:
450
Sub-application Hardware Configuration:
See under FOCC-1 .
100
Operating System:
Name: Subsystem Executive
Developer: Not given
Mode of operation: Batch processing.
Background:
•
•
o
c
•
•
JOVIAL was used because it was the only high-level language available
Average years experience of programmers: 2
Average years JOVIAL experience: 2
Dialect used:
JOVIAL J3
Compilation speed: Not given
Compiled code: Relocatable.
4.8
Interview Notes:
The job of the FOCCPAC personnel is to maintain programs written by NAVCOSSACT
and NAVCOSSACT contractors. The desire was expressed for more compiler
directives or other mechanisms which would allow the programmer to effect a more
efficient code generation.
5.0
HAM
5.1
Organization:
Operational Program Maintenance Branch
4th Air Force Combat Center
Hamilton A.F.B.
San Francisco, California
5.2
Contact:
Lt. Ruck
5.3
Organization Identifier:
HAM
5.4
Number of JAQ's Returned:
1
5.5
Date of Interview:
23 May 1968
5.6
JAO Response Notes:
5.7
Application:
Application Description:
The application, WNR-CC, functions to monitor coordinate and direct air defense
operations for WNR and coordinate air defense with adjacent regions.
101
Total Number JOVIAL Statements:
8850
Application Hardware Configuration:
Computer manufacturer and model
Burroughs AN/GSA51
High speed memory storage
Size
Word size if applicable
60,000s words
10,000 six bit bytes
48 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
Burroughs MU-469/GYK-4
65,536]o 48 bit words each
2 each
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
None
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
Burroughs AN/GSH-12
800 bits/in
3 each
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration on this type
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
IBM 026
1 each
Burroughs AN/GSQ72
200 cards/min
1 each
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
102
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
Flexowriter - AN/GYQ-2
Controller Comparator - 2 I/O Modules
C4634/GYK-4
Controller Comparator/Message Progresser
1 I/O Module 1 msg. Processor C4635/GYK-4
Operating System:
Name: Western NORAD Region CC
Daveloper: USAF/SDC
Mode of Operation: Real Time
Background:
No background information supplied
SDC is primarily responsible for the design of the HAM syste m
5.8
Interview Notes:
6.0
NAVCOSSACT
6.1
Organization:
NAVCOSSACT
Washington Naval Yard Annex
Washington, D.C.
6.2
Contact:
Mr. Dan Foster
6.3
Organization Identifier:
NAVC
6.4
Number of JAQ's Returned:
3
6.5
Date of Interview:
8 May 1968
6.6
JAQ Response Notes:
•
Each of the three JAQ's returned contains response data for distinct sub-applications,
These are identified by NAVC-1, NAVC-2, and NAVC-3.
•
It is our understanding that each runs on the CDC 1604 and that the same compiler
is used for each. Compliance information was obtained from the JAQ for NAVC-1.
6.7
Application:
(1) Sub-application NAVC-1:
1J3
Sub-application Name:
JOVIAL Compiler
Sub-application Description:
The purpose of this sub-application is to compile programs written in JOVIAL for
use on the CDC 160/1604 computer complex.
Total Number of JOVIAL Statements:
NOTE:
Not given
No counts or estimates of features were provided in the JAQ.
Sub-application Hardware Configuration:
Computer manufacturer and model CDC-1604
High speed memory storage
Size
Word size if applicable
32,768 words
8 six bit bytes
48 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
IBM 1301
28,000,000o six bit bytes
4
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
IBM 729
556 bits/in
22
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
IBM 1402
250 cards/min
2
IBM 1402
800 cards/min
2
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
Burroughs B-122
250 cards/min
1
104
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
Holley
150 lines/min
1
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
CDC
1000 lines/min
2
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
CDC
350 frames/sec
3
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
CDC
350 frames/sec
2
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
Teletype BRPE 11
110 frames/sec
5
Operating System:
Name: AN FYK-l(V) 1604A OPCON
Developer: Auerbach Corporation
Mode of Operation: Batch processing
Background:
•
•
o
o
•
e
JOVIAL was used because it was the official NAVY language
Average years experience of programmers: 3
Average years JOVIAL experience: 3
Dialect used: JOVIAL J3
Compilation speed:
Not given,
Compiled code: Relocatable.
(2) Sub-application NAVC-2:
Sub-application Name:
None given
Sub-application Description:
Compiler Maintenance Activity
105
Total Number of JOVIAL Statements:
Not given
Sub-application Hardware Configuration:
Operating System:
See under NAVC-1
No information given.
Background:
•
JOVIAL was used in order to remain compatible with related projects and
because it was the best suited language for the project.
•
No further background information was given.
(3) Sub-application NAVC-3
Sub-application Name:
Route generation/Map generation (RGMG)
Sub-application Description:
Given a latitude and longitude, the sub-application RGMG generates a binary map of
the world or a sea route (land-mass avoidance) according to input specifications. The
binary map must reside in core before a route of turning points can be generated.
RGMG is compiled as a closed subroutine and is operational as a part of a larger sea
surveillance system. In addition it can be run independently and has been run using
the PPS Test function to take advantage of the recording capability (RGMG does not
write out the results).
Total Number of JOVIAL Statements:
2903
Sub-application Hardware Configuration:
Operating System:
See under NAVC-1
See under NAVC-1
Background:
JOVIAL was used to remain compatible with other related projects.
Average years experience of programmers: 0
Average years JOVIAL Experience: 0
Dialect used: JOVIAL J3
Compiler speed: Not given
Compiled Code: Not relocatable
6.8
Interview Notes:
•
It was stressed that the major consideration in the use of JOVIAL is the ease of
programming it provides.
106
•
NAVCOSSACT feels that the readibility of JOVIAL code in certain areas
(e.g., item declarations) could stand some improvement.
7.0
NCDCF
7.1
Organization:
National Civilian Defense Computer Facility
Olney, Maryland
7.2
Contact:
Mr. Marvie Lee
7.3
Organization Identifier:
NCDCF
7.4
Number of JAQ's Returned:
1
7.5
Date of Interview:
7 May 1968
7.6
JAQ Response Notes:
7.7
Application:
Application Description:
The Dash Executive control system assists in using and monitoring the execution of
a system of JOVIAL programs.
Total Number of JOVIAL Statements:
1600
Application Hardware Configuration:
Computer manufacturer and model
High speed memory storage
Size
Word size if applicable
CDC 3600
65536 words
48 bits
Operating System:
Name: SCOPE
Developer: CDC
Mode of Operation:
Batch Processing.
Background:
•
•
•
JOVIAL was used to maintain source language compatibility with related projects.
Average years experience of programmers: 4
Average years JOVIAL experience:
1
107
•
•
•
Dialect used: JOVIAL J3
Compilation speed: Not given
Compiled code: Not given
7.8
Interview Notes:
•
NCDCF personnel interviewed are primarily responsible for maintaining a
JOVIAL compiler.
An opinion was expressed that list processing facilities might find some use in
NCDCF's application.
•
8.0
NEL
8.1
Organization:
Naval Electronics Laboratory
Command and Control Facility
San Diego, California
8.2
Contact:
Mr. Barksdale
8.3
Organization Identifier:
NEL
8.4
Number of JAQ's Returned:
1
8.5
Date of Interview:
24 April 1968
8.6
JAQ Response Notes:
8.7
Application:
Application Description:
The purpose of the Navy Command and Control application is to maintain and test
compilers.
Total Number of JOVIAL Statements:
20K
Application Hardware Configuration:
Computer manufacturer and model
UNIVAC CP 667
High speed memory storage
Size
Word size if applicable
131 K words
6 six bit bytes
36 bits
Input/Output devices
Drum
108
Manufacturer and model
Storage capacity
Univac Fastran
132XlC6six bit bytes
702X106 bits
1
Guantity on this configuration
Magnetic tapes
Manufacturer and model
Recording densities permitted
CDC 603's &606's
200 bits/in
556 bits/in
8
Quantity on this configuration
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
Univac 1449
100 cards/min
1
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
Univac 1232
350 frames/sec
1
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
Univac 1232
150 frames/sec
1
Operating System:
Name: JOVIAL
Developer: PRC and NELC
Mode of operation: Batch processing
Background:
JOVIAL was used because it was regarded as the best suited language for the project.
Average years experience of programmers: 5
Average years JOVIAL experience:
1
Dialect used: JOVIAL J3
Compilation speed: 300-500 statements/minute
Compiled code: Relocatable
8.8
Interview Notes:
It is the intent of the Navy that the following philosophy be employed in the
design and implementation of Command & Control systems: A clear separation of
109
functional software from (machine) system support software is to be maintained.
This means that NEL would prefer a language as machine independent as possible.
The discussion also produced the counter idea - the essential strong point of
JOVIAL, as far as NEL is concerned, is the set of machine dependent features
it contains. It was suggested that a possible resolution of these two conflicting
notions would lie in a kind of (COBOL-like) "Environment Division". The Navy
wants to be able to transfer programs between computers; in other words the
functions performed by a given application may have to be executed on a variety
of different machines.
JOVIAL is too verbose. It would be desirable to have "compound" item declarations, for example (ITEM AA I 48 S BB I 48 S, etc.)
NEL would (and does) like to make use of an expanded character set. They use
braces
for BEGIN END. This helps attack the verbosity problems.
It was suggested that a "TYPE OTHER" (CDC FORTRAN 63) facility be considered,
9.0
NMCSSC
9.1
Organization:
DCA
National Military Command
System Support Center
Pentagon
Washington, D.C.
9.2
Contact:
Colonel Gallentine
9.3
Organization Identifier:
NMCSSC
9.4
Number of JAQ 's Returned:
9.5
Date of Interview:
9.6
JAQ Response Notes:
9.7
Application:
20 June 1968
Application Description:
The Damage and Contamination Model associates military nuclear weapons against all
kinds of targets and predicts damage. The pertinent parameters are coordinates, wind
data, height of weapon burst, weapon yield, vulnerability, number of targets, and
target capacity.
Total Number of JOVIAL Statements:
5000
110
Application Hardware Configuration:
High speed memory storage
Size
Word size if applicable
32K words
8 six bit bytes
48 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
None
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
None
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
CDC 606
500 bits/in
12
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
•
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
CPC 405
1200 cards/min
1
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
CDC 501
1000 lines/min
1
Paper tape reader
Manufacturer and model
Tape read speed
Quantity on this configuration
IBM
50 cards/min
1
CDC
1
Paper tape punch
Manufacturer and model
Tape punch speed
Quantity on this configuration
CDC
1
111
Operating System:
Name: COOP
Developer: CDC
Mode of Operation:
Batch Processing
Background:
•
•
•
•
•
•
JOVIAL was used in order to stay compatible with other projects and because it
was the language best suited for the project.
Average years experience of programmers: 2
Average years JOVIAL experience:
1
Dialect used: JOVIAL J3
Compilation speed: 44 statements per minute
Compiled Code: CODAP symbolic which is then assembled in a relocatable fashion,
9.8
Interview Notes:
•
A desire was expressed to have the compiler produce code in the form of the
assembly languages supplied by the computer manufacturer; also, the subroutine
linkages of the language should be in such a form as to be compatible with the
computer manufacturer's system.
•
NMCSSC also requires the ability to process machine interrupts.
10.0 NHCP
10.1
Organization:
Headquarters NORAD
NHCP
Ent Air Force Base
Colorado Springs, Colorado
10.2 Contact:
Mr. N. R. Gerhart
10.3 Organization Identifier:
NHCP
10.4 Number of JAQ's returned:
2*
10.5 Date of Interview:
10.6 JAQ Response Notes:
The JAQ's returned were not received in sufficient time for their contents to be processed,
10.7 Application:
10.8 Interview Notes:
112
•
NHCP desires facilities for tables containing variable length entries.
•
Multiple assignment statements of the form
AA = BB = CC = 0$
would be found useful. The effect of the above statement is produced by
AA = 0$
BB = 0$
CC = 0$
•
A need for a 'pro-word" such as "SELF" or "*" was voiced.
VARIABLE = {SELF} +3$
or VARIABLE =
* + 3 $
produces the effect
VARIABLE - VARIABLE + 3 S
•
Extended use of ranged subscripts would be helpful:
TABLE'NAME ( $3 . . . 12 $ )
has the effect of naming a table structure made up of entries 3 through 12.
•
NHCP would like the ability to show a set of loop variable increment values to
be taken in FOR loop processing:
FOR I = 1, (5, 3, 6, 19 ), NN
Each lime through the increment handling part of the loop, the next increment
"to the right" in the list is used.
•
NHCP would prefer the use of parentheses instead of the JOVIAL index brackets
($ and $) when writing subscripts.
•
A desire to include $ in comments was mentioned.
•
NHCP feels that non-named variables should be allowed as operands of the BIT
and BYTE functional modifier, e.g.,
BIT($3, 6 S)(BYTE ($5, 2$) (AA))
11.0
RADC
11.1
Organization:
Rome Air Development Center, EMI IF
Griffis Air Force Base
Rome, New York
1.2
Contact:
Mr. Dick Motto
1.3
Organization Identifier:
RADC
1 .4
Number of JAQ's Returned:
4
1.5
Date of Interview:
1 May 1968
1.6
JAQ Response Notes:
113
Each of the three JAQ's returned contains response data for three distinct sub-applications.
These are identified as RADC-2, RADC-3, and RADC-4.
The JAQ returned by RADC-1 did not give usage counts.
RADC-1 is run on the CDC 1604B.
RADC-2 is run on the Univac M555.
RADC-3 is run on the GE 635.
RADC-4 is run on the GE 635.
It is our understanding that RADC-3 and RADC-4 use the same compiler.
11.7
Application:
(1) Sub-application RADC-1
Sub-application Name:
None given.
Sub-application Description:
•
•
•
•
MADAPS - a data management system
TINT - an on-line JOVIAL (subset) compiler
JOVIAL COMPILER
AUERBACH PROGRAM
Total Number JOVIAL Statements:
NOTE:
Not given.
No counts or estimates of usage were entered in this JAQ.
Sub-application Hardware Configuration:
Operating System:
Background:
Not given.
No information given.
No information given.
(2) Sub-application RADC-2
Sub-application Name:
Data Management I
Sub-application Description:
Data Management I is a data management system.
Total Number of JOVIAL Statements:
Not given.
NOTE: It was stated in the JAQ for RADC-2 that because the compiler is in a continuous
state of flux and improvement, and since no major programs have yet been written, usage
counts have not been entered. Rather, qualitative statements have been made regarding
114
usage rates (e.g., very frequently, seldom, etc.) We have quantified these statements.
The following is a list of the qualitative statements used with their associated quantifiers:
.7
.9
.3
.2
.2
.9
0
.1
.9
.7
OFTEN
VERY FREQUENTLY
SOME
SELDOM
SOMETIMES
ALWAYS
NEVER
VERY SELDOM
VERY OFTEN
FREQUENTLY
Sub--application Hardware Conf iguratiion:
Computer manufacturer and model:
High speed memory storage
Word size:
Univac M555
64K words
18 bits
Operating System:
Name of operating system:
Developer:
Mode of operation:
ECP IT
Not given
Not given
Background:
•
JOVIAL was used in this project both because it was the official Air Force
language and because it was the language best suited for the project.
•
No other background information was entered.
(3) Sub-application RADC-3
Sub-application Name:
TINT
Sub-application Description:
"On-line compiler"
Total Number of JOVIAL Statements:
9142
Sub-Application Hardware Configuration:
Computer manufacturer and model
GE 635
115
High speed memory storage
Size
Word size if applicable
36 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
GS MDS 200
30M bits
1
128K words
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
GS DSU 200
138Mbits
2
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
GS MT #67
200/566/800 bits/in
8
Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
GE4WCPZ201A1
300 cards/min
1
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
GS4WCRZ201A1
800-1000 cards/min
GE PRT 200
1200 lines/min
2
Operating System:
Name: GECOS
Developer: General Electric Co.
Mode of Operating System: Batch processing
Background:
•
JOVIAL was used because it was the official Air Force language, because it was
desired to maintain source language compatibility with other projects, and
because it was the best suited language for the project.
116
Average years experience of programmers: 3-5
Average years JOVIAL experience: 3-5
Dialect used:
JOVIAL J3
Compilation speed: 50 statements per minute
Compiled code: Relocatable
(4) Sub-application RADC-4
Sub-application Name:
Auxiliary Control Executive Processor
Sub-application Description:
"Preprocessor for an Executive Control Program."
Total Number of JOVIAL Statements:
3951
Sub-application Hardware Configuration: No details given.
however, that the computer is the GE 635.
Operating System:
It is our understanding,
No information given.
Background:
•
JOVIAL was used to maintain compatibility with other related projects, because
it is the official Air Force language and because it is the language best suited
for the project.
Average years experience of programmers: 4
Average years JOVIAL experience:
1
Dialect used: JOVIAL J3
Compilation speed: None given.
Compiled code: Relocatable.
11.8
Interview Notes:
RADC would like the ability to specify (at compile or load time) the allocation sequencing of both programs and data; this is felt a more important facility than dynamic allocation,
12.0
SAC
12.1
Organization:
Headquarters SAC
Offut Air Force Base, Nebraska
12.2
Contacts:
Lt Col F. L. Maloy, DOCODS
Major Samuel P. Herod
12.3
Organization Identifier:
SAC
117
12.4
Number of JAQ 's Returned:
4
12.5
Date of Interview:
13 May 1968
12.6
JAQ Response Notes:
•
Each of the four JAQ's returned contains response data for four distinct subapplications. These sub-applications are identified as SAC-1, SAC-2, SAC-3,
and SAC-4.
•
Sub-applications SAC-1, SAC-2, and SAC-3 each run on the AN/FSQ-31 and
each uses the same compiler. Implementation responses for SAC-1, SAC-2, and
SAC-3 were taken from the JAQ for SAC-1.
•
Sub-application SAC-4 is run on the IBM 7090; implementation responses are
taken from the JAQ for SAC-4.
12.7
Application:
(1) Sub-application SAC-1
Sub-application Name:
Utility Subsystem
Sub-application Description:
The Utility subsystem includes the following capabilities:
•
•
•
•
•
•
a
•
o
•
•
executive
compiler
tape update
COMPOOL
data generator
data reduction
dump
CHECKER
task parameter assembler
tape maintenance
loader maintenance
Total Number JOVIAL Statements:
116,137
Sub-application Hardware Configuration:
Computer manufacturer and model
IBM AN/FSQ-31 Data Processing Central
High speed memory storage
Size
Word size if applicable
65,536 words
524,288 six bit bytes
48 bits
118
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
19
IBM (no model)
1, 114, 112 six bit bytes
6,684,672 bits
2
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
Bryant Model L
103,809,024 six bit bytes
622,854,144 bits
1
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
IBM 729 II, IBM 729 IV
200/556 bits/in
12
*Card punches
Manufacturer and model
Card punch speed
Quantity on this configuration of this type
IBM 729 II, IBM 729 IV
250 cards/min
1
*Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
IBM 1402
800 cards/min
1
*Printer
Manufacturer and model
Printer speed
Quantity on this configuration
IBM 1403
600lines/min
1
*Available as part of IBM 1401 systems which can be used on-line.
and punching is normally accomplished off-line.
However, printing
NOTE: There are two IBM AN/FSQ-31 computers. Each with an I/O typewriter, fix
typewriter, Disc, 2 drums, 15 tape drives and 1401 system.
Operating System:
Name: EXECUTIVE
Developer: SDC/USAF
Mode of operation: Batch processing
Real Time
NOTE: "The utility subsystem operates only in the batch processing mode.
it can operate 'interleaved' with the real time programs."
119
However,
Background:
•
JOVIAL was used both to maintain source language compatibility with other
related projects and because it was the language best suited for the project.
Also stated: "JOVIAL was devised for SACCS system by SDC - who wrote the
utility subsystem."
Average years experience of programmers: "Unknown"
Average years JOVIAL experience: "Unknown - perhaps about 2"
Dialect used:
JOVIAL J2
Compilation speed: 200 statements per minute
Compiled code: Relocatable
(2) Sub-application SAC-2
Sub-application Name:
Planning
Sub-application Description:
The Planning Branch furnishes the automated support for development and maintenance
of the Single Integrated Operations Plan and other SAC planning functions. This includes
missile and aircraft application against target systems with all the associated ramifications:
bomber/tanker mating, fuel consumption, performance characteristics, optimum routine
resolution of timing conflicts, etc. Also included is the production of planned and
emergency execution documents and statistical documents.
Total Number of JOVIAL Statements:
300,000 (est)
Sub-application Hardware Configuration:
See under SAC-1
Operating System:
Name: EXECUTIVE
Developer: SDC/USAF
Mode of operation: Batch Processing Real Time
NOTE: "The planning subsystem operates only in the batch processing mode.
it can operate 'interleaved' with the real time programs."
However,
Background:
JOVIAL was used both to maintain source language compatibility with other
related projects and because it was the best language suited for the project.
Average years experience of programmers: 3
Average years JOVIAL experience: 3
Dialect used: See under SAC-1
Compilation speed: See under SAC-1
Compiled code: See under SAC-1
120
(3) Sub-application SAC-3
Sub-application Name:
Force Control
Sub-application Description:
The Force Control sub-application modifies a static data base by processing message and
card inputs to provide a present status of SAC SIOP Forces through various prints, wall
displays and BOJO displays. DATA PREP modifies and error checks messages from units
for use by V-l. V-l updates tables and displays; 200 PACKAGES uses updated data to
create displays and prints. DATA PRES creates the displays that are projected to wall
screens.
Total Number of JOVIAL Statements:
153,789
Sub-application Hardware Configuration:
See under SAC-1
Operating System:
Name: EXECUTIVE
Developer: SDC/USAF
Mode of operating system:
Batch processing real time
Background:
•
JOVIAL was used both to maintain source language compatibility with other
related projects and because it was the language best suited for the project.
Average years experience of programmers: 2
Average years JOVIAL experience: 2
Dialect used: See under SAC-1
Compilation speed: See under SAC-1
Compiled code: See under SAC-1
(4) Sub-application SAC-4
Sub-application Name:
SIOP Gaming Simulation Analysis/ADA
Sub-application Description:
The SIOP Gaming Simulation extracts data from RISOP/SIOP tapes furnished by JWGA
and prepares data for War Gaming Simulation and Analysis. The model includes trajectory computations and damage assessments.
The purpose of the ADA is to provide an AUSTERE DEMONSTRATION SYSTEM (Hardware
and Software) in a PACCS aircraft to develop and demonstrate operational techniques in
the actual environment using available automation hardware and a minimum of development effort.
121
Total Number of JOVIAL Statements:
Gaming - 132,000
ADA 90,000
Application Hardware Configuration:
Computer manufacturer and model
IBM 7090
High speed memory storage
Size
Word size if applicable
65,536 words
393,216 six bit bytes
36 bits
Input/Output devices
Drum
Manufacturer and model
Storage capacity
Quantity on this configuration
17
0
Disc
Manufacturer and model
Storage capacity
Quantity on this configuration
IBM 1301-1
27,960,000 six bit bytes
167,760,000 bits
1
Magnetic tapes
Manufacturer and model
Recording densities permitted
Quantity on this configuration
IBM 729 IV
200/556 bits/in
12
Card reader
Manufacturer and model
Card read speed
Quantity on this configuration
IBM 711
250 cards/min
1
Printer
Manufacturer and model
Printer speed
Quantity on this configuration
IBM 716
150 lines/min
1
NOTE: One I/O typewriter and one Hendrix 5101 crt are attached to the IBM 7090.
NOTE: 2 IBM 1460 computers (with MOD III printers, MOD III card reader-punches)
plus a 5 track paper tape reader-punch are used off-line to print and punch 7090 outputs.
Operating System:
Name: (Gaming) None used
(ADA) ADA EXECUTIVE
122
Developer:
(Gaming) N/A
(ADA) SAC
Mode of operating system: (Gaming) N/A
(ADA) Real Time
(Ncte: ADA does utility work under IBSYS)
Background:
•
•
•
•
Both ADA and Gaming used JOVIAL to remain source language compatible with
other projects and because it was the best suited language for the project.
Average years experience programmers:
Gaming, 2.5
ADA, 2.7
Average years JOVIAL experience: Gaming, 2.2
ADA, 2.0
Dialect used: JOVIAL J2 (Gaming and ADA)
Compilation speed: 200 statements per minute (Gaming and ADA)
Compiled code: Not relocatable (Gaming and ADA)
12.8
Interview Notes:
•
•
General:
SAC may be going over to third generation equipment within the next two years; it is
expected that the corresponding software systems will operate in a time shared mode. SAC
would like to transfer programs already written to the new equipment with as little
reprogramming as possible, but admits that a lot of reprogramming may be required.
Specific:
•
•
SAC feels that the notion of COMPOOL has outlived its usefulness, though it is
admitted that this feeling is influenced by the fact that the COMPOOL implementation used is overly complex and very slow— both in terms of machine time and
personnel interface required. It is our impression that SAC would like facilities
for operationally imposing any conceivable kind of structuring over a relatively
unstructured "free standing" data base in a short order. Toward this end SAC is
currently examining TDMS (ADEPT).
SAC requires the ability to manipulate disc and drum addresses as well as main
memory addresses when doing I/O; further, they would like the capability of
incrementing buffer addresses as required.
13.0
TWA
13.1
Organization:
TWA Data Processing Center
King Road, Rockleigh, N. J,
13.2
Contact:
Mr. Duane Witlow
123
13.3
Organization Identifier:
TWA
13.4
Number of JAQ's Returned:
0
13.5
Date of Interview:
3 May 1968
13.6
JAQ Response Notes:
Owing to an extemely tight schedule, TWA was unable to complete a JAQ. From our
conversation at the interview and from a perusual of their JOVIAL Reference Manual, it
appears that the TWA JOVIAL complies fairly closely to the standard of AFM 100-24.
Particularly interesting are the several special features provided:
•
•
The Burroughs computer on which the application is run is a multiprocessing
machine. A BRANCH statement is provided to allow programmers to assign program
segments to processors for execution (several segments may run in parallel). An
ENDBRANCH Statement causes execution on a processor to cease.
The AWAIT Statement permits the suspension of a parallel path of execution until
the occurance of some condition.
READY, RELEASE, and SETUP statements provide the capabilities for dynamic
allocation of data.
ECI (Entry Control Item) and KEY allow for the manipulation of tables with both
variable length entries and variable structure entries at execution time.
The JOVIAL compiler was written by Burroughs.
13.7
Application:
13.8
Interview Notes:
•
•
•
No data
General:
TWA feels that the language (except as noted in the specific interview responses)
is essentially sufficient for its application. TWA believes its big problem lies
in the area of imposing control over all the diverse elements of the system at
large. That is, TWA would like the ability to link COMPOOL, program libraries,
and compiler, etc., together in such a way that any change to programs or data
structures would result automatically in the output of messages stating what other
parts of the system would be effected.
TWA desires to keep the machine separated from the functions as much as possible.
Toward this end, they have eliminated Direct Code from their system.
Specific:
A need exists for "formal" bit string items and operators AND, OR, NOT,
EITHER/OR.
124
TWA would like to have PROC's in COMPOOL as well as data with both
the definitional and external attributes.
A desire was expressed for a kind of "DEFINE" facility:
ALPHA ('BETA)
where 'BETA (COMPOOL name) would be inserted in the text along with the
ALPHA in subsequent references.
A need for a "MAKE CURRENT" facility was voiced. Sometimes, programs
will have many occurrences of the same table. It is desirable to write one
segment of code which references items in one table, but then switch physical
tables at execution time. (Only one physical table is being handled at a time.)
125
APPENDIX II
JOVIAL FEATURE RESOLUTION ANALYSIS
The folowing pages contain the resolution analyses for all of the features investigated
in the JOVIAL Evaluation Study. The JOVIAL Evaluation Questionnaire (JAQ) and
the approach for change reference numbers are provided for each feature for crossreferencing purposes. The resolution inequality, resolution equations and roles
leading to each particular resolution are in accordance with the discussion in Section 1 .
The application is described in Appendix 1. In the compliance column, if the feature
was implemented in accordance with AFM 100-24, it is noted as CFI; if not implemented,
CFNI; or if implemented differently, CFID. The usage is calculated according to the
resolution equation.
Resolution equations and usage rates are given frequently in this appendix for features
which are "accepted as nucleus." This is done only to provide the reader with a means
of comparing the use of such features with respect to other related features.
The resolution analysis of the features are organized according to the organization of the
Approach for Change (AFC) reference numbers.
127
RESOLUTION ANALYSIS
AFC Reference:
JAQ Reference:
J 3 .5.1.1 .11.1
Feature Name:
ITEM TYPE HOLLERITH
Resolution Inequal ity:
N/A
Resolution Equation:
U = Q46/(Q46 + Q50)
Number of users with usage rates:
Resolution:
Data:
A 1.1.1.1
GQ Tl > = N/A
Accepted as nucleus (Note optional simpl fied constant form,
3.2 .2.8)
Application
Compliance
Usage
.1333
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFI
RADC-1
CFI
(N/C)
RADC-2
CFID
.9
RADC-3
CFI
.9524
RADC-4
CFI
SAC-1
CFI
SAC-2
CFI
SAC-3
CFI
.7214
SAC-4
CFI
1
N(CFI)=
(N/C)
.9803
N(CFID) =
21
128
1
N(CFNI) =
°
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.5
Feature Name:
HOLLERITH FORMULA
Resolution Inequality:
N/A
Resolution Equation:
N/A
Number of users with usage rates:
Resolution:
Data:
AFC Reference: A 1.1.1.1
GQ Tl = N/A
Retain as nucleus (Note modification to Hollerith assignment
and comparisons, 3.2.2.4)
Compliance
Application
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFI
RADC-1
CFI
RADC-2
CFNI
RADC-3
CFI
RADC-4
CFI
SAC-1
CFI
SAC-2
CFI
SAC-3
CFI
SAC-4
CFI
N(CFI) =
21
N(CFID) =
129
Usage
N(CFNI) =
1
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.11.2
Feature Name:
ITEM TYPE STANDARD TRANSMISSION CODE
Resolution Inequality:
U GQ Tl = .10
Resolution Equation:
U = Q50/(Q46 + Q50)
Number of users with usage rates:
Resolution:
AFC Reference: A 1.1.1.2
GQ Tl = 2
Delete (Note also CHARCODE directive, 3.2.2.3)
Data:
Application
Compli a nee
Usage
ADPAC-1
CFI
.8666
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFID
.0196
NMCSSC
CFI
0
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
.0476
RADC-4
CFI
0
SAC-1
CFI
0
SAC-2
CFI
0
SAC-3
CFI
.2785
SAC-4
CFI
0
N(CFI)=
N(CFID) =
18
130
1
N(CFNI) =
2
RESOLUTION ANALYSIS
JAQ Reference:
j 3.5.2.5
Feature Name:
STANDARD TRANSMISSION CODE FORMULA
Resolution Inequality:
N/A
Resolution Equation:
N/A
Number of users with usage rates:
Resolution:
AFC Reference: A 1.1.1.2
QQ j\ = N/A
Delete (Because of deletion of Item Type STC)
Data:
Come liance
Application
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFI
RADC-1
CFI
RADC-2
CFNI
RADC-3
CFI
RADC-4
CFI
SAC-1
CFI
SAC-2
CFI
SAC-3
CFI
SAC-4
CFI
N(CFI) =
21
N(CFID)=
131
Usage
0
N(CFNI) =
1
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.14
Feature Name:
CHARACTER DATA SIZE ATTRIBUTE
Resolution Inequality:
N/A
Resolution Equation:
N/A
Number of users with usage rates:
Resolution:
AFC Reference:
A4, Al.1.1.3
GQ Tl • N/A
Accept as nucleus
Data:
Application
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFI
RADC-1
CFI
RADC-2
CFI
RADC-3
CFI
RADC-4
CFI
SAC-1
CFI
SAC-2
CFI
SAC-3
CFI
SAC-4
CFI
N(CFI)=
22
N(CFID)=
132
Usage
0
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.13
Feature Name:
ITEM TYPE STATUS
Resolution Inequality:
UGQ =T1 = 05
Resolution Equation:
U = Q58/Q14
Number of users with usage rates:
Resolution:
AFC Reference:
A 1.1.2
GQ Tl = 7
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.0416
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
.0040
FOCC-2
CFI
.4000
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0500
NAVC-3
CFI
.0100
NCDCF
CFI
.0200
NEL
CFI
.0080
NMCSSC
CFI
.1666
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
.0100
RADC-4
CFI
.0303
SAC-1
CFI
.1812
SAC-2
CFI
.0673
SAC-3
CFI
.1924
SAC-4
CFI
.0532
N(CFI) =
22
fs
N(CFID)
=
33
N(CFNI)= °
RESOLUTION ANALYSIS
JAQ Reference:
J o.3
Feature Name:
STATUS FORMULA
Resolution Inequal ity:
N/A
Resolution Equation:
N/A
#
Number of users with usage rates:
Resolution:
AFC Reference: A 1.1.2
£. . _
GQ T1 = N/A
Retain as optional (Required if St<
Data:
Application
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFI
RADC-1
CFI
RADC-2
CFNI
RADC-3
CFI
RADC-4
CFI
SAC-1
CFI
SAC-2
CFI
SAC-3
CFI
SAC-4
CFI
N(CFI) =
N(CFID) = 0
21
134
Usage
N(CFNI) =_
1
RESOLUTION ANALYSIS
JAQ Reference:
J 3. 5.1. 1.14
Feature Name:
EXPLICIT STATUS SIZE ATTRIBU"
Resolution Inequal ity:
UGQ Tl = .01
Resolution Equation:
U = Q70/Q58
Number of users with usage rates:
Resolution:
Data:
AFC Reference:
A 1.1.3
GQ Tl =12
Retc lin as nucleus (Meaningful on
imp lemen ted)
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.6000
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
0
FOCC-2
CFI
.0100
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.2000
NAVC-3
CFI
0
NCDCF
CFI
0
NEL
CFI
.0500
NMCSSC
CFI
.2000
RADC-1
CFID
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
1
RADC-4
CFI
0
SAC-1
CFI
.0500
SAC-2
CFI
.1484
SAC-3
CFI
.0543
SAC-4
CFI
.0487
N(CFI) =
N(CFID) _
21
135
1
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.2
Feature Name:
STRUCTURE ARRAY
AFC Reference: A 1 .2.1
Resolution Inequality:
N/A
Resolution Equation:
Q74(Q74 + Q78)
Number of users with usage rates:
Resolution:
Data:
GQ Tl = N/A
Retain as optional (Note: In the AFC, we accepted ARRAY as a nucleus
data structure. Since the number of users implementing ARRAY is relatively
small, and because the usage where implemented is low, we are altering the
status of this feature to "optional").
Compliance
Application
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFID
(N/A)
FAA
CFID
.2
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFID
.2500
NMCSSC
CFNI
0
RADC-1
CFID
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
.0322
RADC-4
CFI
0
SAC-1
CFID
0
SAC-2
CFID
.0181
SAC-3
CFID
.0417
SAC-4
CFID
.0676
N(CFI)= 5
N(CFID) = 8
136
N(CFNI)= 9
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.1
Feature Name:
STRUCTURE TABLE
Resolution Inequality:
UGQ Tl = .10
Resolution Equation:
U = Q78/(Q78 + Q74)
Number of users with usage rates:
Resolution:
AFC Reference: A 1.2.2
OQ Tl = 18
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
N/A)
FAA
CFI
9
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFI
RADC-1
CFI
N/C)
RADC-2
CFI
9
RADC-3
CFI
9677
RADC-4
CFI
SAC-1
CFI
SAC-2
CFI
.9818
SAC-3
CFI
.9582
SAC-4
CFI
.9323
N(CFI)=
(N/C)
7500
N(CFID) =
22
137
0
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.4
Feature Name:
TABLE VARIABILITY ATTRIBUTE
Resolution Inequality:
U GQ Tl = .10
Resolution Equation:
U = Q86/Q78
Number of users with usage rates:
Resolution:
AFC Reference:
A 1.2.3
RIGID
GQ Tl = 18
Retain as nucleus
Data:
Compliance
Application
Usage
ADPAC-1
CFI
.4736
ADPAC-2
CFI
.8750
ADPAC-3
CFI
1
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFID
.2608
FOCC-2
CFID
.7500
HAM
CFI
.0625
NAVC-1
CFI
(N/C)
NAVC-2
CFI
1
NAVC-3
CFI
.9534
NCDCF
CFI
.4000
NEL
CFI
.666
NMCSSC
CFI
0
RADC-1
CFID
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
.1666
RADC-4
CFI
.5555
SAC-1
CFI
.5952
SAC-2
CFI
.4615
SAC-3
CFI
.9556
SAC-4
CFI
.6113
N(CFI) =
19
N(CFID) =
138
N(CFNl) _
=
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.4
Feature Name:
TABLE VARIABILITY ATTRIBUTE - VARIABLE
Resolution Inequality:
U GQ Tl = .10
Resolution Equation:
1 - (Q86/Q87)
Number of users with usage rates:
Resolution:
AFC Reference:
GQ Tl = 18
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.5264
ADPAC-2
CFI
.1250
ADPAC-3
CFI
0
CSC
CFI
N/A
FAA
CFI
.2
FOCC-1
CFID
.7392
FOCC-2
CFID
.2500
HAM
CFI
.9375
NAVC-1
CFI
N/C
NAVC-2
CFI
0
NAVC-3
CFI
.0466
NCDCF
CFI
.6000
NEL
CFI
.334
NMCSSC
CFI
1
RADC-1
CFID
N/C
RADC-2
CFI
.1
RADC-3
CFI
.8334
RADC-4
CFI
.4445
SAC-1
CFI
.4048
SAC-2
CFI
.5385
SAC-3
CFI
.0444
SAC-4
CFI
.3887
N(CFI)=
19
N(CFID)=
139
3
N(C
A 1.2.3
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.2.2.6
Feature Name:
NENT
Resolution Inequal ity:
UGQT1 =.10
Resolution Equation:
U = Q169/Q78
Number of users with usage rates:
Resolution:
AFC Reference:
A 1.2.3
GQ T1 = 15
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.6315
ADPAC-2
CFI
.1250
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
1.304
FOCC-2
CFI
.2500
HAM
CFI
.9375
NAVC-1
CFI
(N/C)
NAVC-2
CFI
1
NAVC-3
CFI
.8139
NCDCF
CFI
1
NEL
CFI
.0166
NMCSSC
CFI
.6666
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
0
RADC-4
CFI
.0555
SAC-1
CFI
1.976
SAC-2
CFI
.3230
SAC-3
CFI
.8076
SAC-4
CFI
1.279
N(CFI)=
22
N(CFID) =
140
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.1.2
Feature Name:
NWDSEN
Resolution Inequality:
U GQ Tl = .02
Resolution Equation:
U = Q140/Q78
Number of users with usage rates:
Resolution:
AFC Reference:
A
1.2.4
GQ Tl = 0
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFID
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.0173
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFI
.0166
NMCSSC
CFNI
0
RADC-1
CFI
(N/C)
RADC-2
CFI
.1
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFI
.0119
SAC-2
CFI
.0115
SAC-3
CFI
.0087
SAC-4
CFI
.0010
N(CFI)=
19
N(CFID) =
141
N(CFNI)=2
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.4
Feature Name:
STRUCTURE STRING
Resolution Inequal ity:
UGQ Tl = .10
Resolution Equation:
U = Q103/Q78
Number of users with usage rates:
Resolution:
AFC Reference:
A 1.2.5
GQ Tl =2
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFI
0
SAC-2
CFI
.0307
SAC-3
CFI
.2697
SAC-4
CFI
.0357
N(CFI)=
6
N(CFID) =
142
0
N(CFNI)=
16
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.2.2.1
Feature Name:
BIT
Resolution Inequality:
UGQ Tl = .03
Resolution Equation:
U = Q149/Q14
Number of users with usage rates:
Resolution:
AFC Reference: A 2.1
GQ Tl = 10
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.0416
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.0200
FOCC-2
CFI
.0200
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.1000
NAVC-3
CFI
0
NCDCF
CFI
.0800
NEL
CFI
.0020
NMCSSC
CFI
.6666
RADC-1
CFI
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
.0100
RADC-4
CFI
.1635
SAC-1
CFID
.0966
SAC-2
CFID
.0210
SAC-3
CFID
.0689
SAC-4
CFID
.0649
N(CFI) =
18
N(CFID) =
143
_
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.2.2.2
Feature Name:
BYTE
Resolution Inequality:
UGQ Tl = .03
Resolution Equation:
U = Q153/(Q46+Q50)
Number of users with usage rates:
Resolution:
AFC Reference: A 2.2
GQ Tl = 15
Retain as nucleus
Data:
Application
.ompl i a nee
Usage
ADPAC-1
CFI
2.883
ADPAC-2
CFI
2.428
ADPAC-3
CFI
1.291
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.3076
FOCC-2
CFI
.0150
HAM
CFI
4.000
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.1500
NAVC-3
CFI
0
NCDCF
CFI
.8571
NEL
CFI
.0294
NMCSSC
CFI
.6666
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
.7500
RADC-4
CFI
.6666
SAC-1
CFID
4.235
SAC-2
CFID
2.058
SAC-3
CFID
.9856
SAC-4
CFI
.9605
N(CFI) =
N(CFID) _
= 4
17
144
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3 .5.2.2.2 .3-4
Feature Name:
CHAR/MAN T
Resolution Inequal ity:
U GQ Tl = , .03
Resolution Equation:
U = = (Q157 + Q161)/Q38
Number of users with usage i •ates:
Resolution:
AFC Reference:
A 2.3
GQ Tl =1
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.2000
ADPAC-3
CFI
0
CSC
CFNI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFI
.0200
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFI
0
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI) =
N(CFID) =
145
N(CFNI) _
=
15
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.2.1
Feature Name:
SUBSCRIPTING - Expressed as Complex Numeric Formula
Resolution Inequality:
N/A
Resolution Equation:
U = Q144/(Q74 + Q78 + Ql03)
Number of users with usage rates:
Resolution:
AFC Reference:
A 2.4
GQ Tl = N/A
Accepted as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.3684
ADPAC-2
CFI
.1250
ADPAC-3
CFI
1
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.1304
FOCC-2
CFI
.6250
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.2000
NAVC-3
CFI
.5813
NCDCF
CFI
.4000
NEL
CFI
.0750
NMCSSC
CFI
6.666
RADC-1
CFI
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
32.25
RADC-4
CFI
4.444
SAC-1
CFID
1.500
SAC-2
CFID
.5425
SAC-3
CFID
1.229
SAC-4
CFID
.8433
N(CFI) =
18
N(CFID) =
146
4
_
N(CFNl) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.2.1
Feature Name:
SUBSCRIPTING - Nested
Resolution Inequality:
N/A
Resolution Equation:
U = Q145/(Q74 + Q78 + Q103)
Number of users with usage rates:
Resolution:
AFC Reference: A 2.4
GQ Tl = N/A
Accepted as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
.8000
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.0869
FOCC-2
CFI
1.250
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0666
NAVC-3
CFI
.2325
NCDCF
CFI
1
NEL
CFI
.0050
NMCSSC
CFI
1.333
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
16.12
RADC-4
CFI
.1111
SAC-1
CFID
.3095
SAC-2
CFID
.2932
SAC-3
CFID
2.030
SAC-4
CFID
.5927
_
N(CFI) =
18
N(CFID) =
147
4
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.6
Feature Name:
TABLE ENTRY REFERENCING (ENTRY/ENT)
Resolution Inequality:
U GQ Tl =.02
Resolution Equation:
(J = Q200/Q78
Number of users with usage rates:
Resolution:
AFC Reference: A 2.5
GQ Tl - 13
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFID
.6315
ADPAC-2
CFID
.2500
ADPAC-3
CFID
0
CSC
CFI
(N/A)
FAA
CFID
.8
FOCC-1
CFI
.0652
FOCC-2
CFI
2.500
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.3333
NAVC-3
CFI
0
NCDCF
CFI
.0400
NEL
CFI
.0200
NMCSSC
CFID
.6666
RADC-1
CFID
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFID
.6904
SAC-2
CFID
.2307
SAC-3
CFID
.4125
SAC-4
CFID
.2202
N(CFI) =
9
N(CFID)= 9
148
N(CFNI)= 3
RESOLUTION ANALYSIS
JAQ Reference:
AFC Reference:
J 3.5.2.2.1
A
2 6
Feature Name:
Resolution Inequality:
N/A
Resolution Equation:
ENT:
U = Q201/Q200; ENTRY:
Number of users with usage rates:
Resolution:
Data-
U = 1 - Q201/Q200
GQ Tl = N/A
Retain ENTRY as nucleus; delete ENT (Basis of resolution: As shown below, the
majority of applications implementing both ENT and ENTRY and which use
table entry referencing at all, use ENTRY either exclusively or in most cases.)
Usage
Compl iance
Application
ENTRY
ADPAC-1
ENT
CFR1
ENTRY
CFl
ENT
U
ADPAC-2
CFNI
CFl
0
ADPAC-3
CFNI
CFl
0
CSC
CFl
CFl
(N/A)
(N/A)
FAA
CFl
CFNI
1
0
FOCC-1
CFl
CFl
0
FOCC-2
CFl
CFl
0
HAM
CFl
CFl
0
0
NAVC-1
CFl
CFl
(N/C)
(N/C)
NAVC-2
CFl
CFl
0
NAVC-3
CFl
CFl
0
NCDCF
CFl
CFl
0
NEL
CFl
CFl
.8333
NMCSSC
CFNI
CFl
0
RADC-1
CFl
CFl
(N/C)
(N/C)
RADC-2
CFNI
CFNI
(N/C)
(N/C)
RADC-3
CFl
CFl
0
0
RADC-4
CFl
CFl
0
0
SAC-1
CFl
CFNI
1
0
SAC-2
CFl
CFNI
1
0
SAC-3
CFl
CFNI
1
0
SAC-4
CFl
CFNI
1
0
ENT:
ENTRY:
N(CFI) =
N(CFI) =
17
N(CFID) =
N(CFID) =
16
149
0
0
0
.1667
N(CFNi)= 5
N(CFNI) = 6
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.15
Feature Name:
COMPUTER REPRESENTATION OF DATA
Resolution Inequality:
N/A
Resolution Equation:
N/A
Number of users with usage rates:
Resolution:
r> .
Application
AFC Reference: A3
GQ Tl = N/A
Modified as specified in 3.2.2.1 (hexadecimal constant), 3.2.2.3
(CHARCODE), 3.2.2.5 (computer representation of numeric variables
and constants, and 3.2.2.10 (extended precision)
Usage
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFID
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFID
NMCSSC
CFID
RADC-1
CFID
RADC-2
CFI
RADC-3
CFI
RADC-4
CFID
SAC-1
CFID
SAC-2
CFID
SAC-3
CFID
SAC-4
CFI
N(CFI) = 14
|v
N(CFID)=
150
8
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.1
Feature Name:
OCTAL CONSTANT
Resolution Inequality:
UGET1 =1
Resolution Equation:
U = Q4
Number of users with usage rates:
Resolution:
Data:
AFC Reference: A 3.1
GQ Tl - 18
The "Bit String Constant" Facility provided by Octal Constant is
retained as nucleus; however, octal is optional if hexadecimal
(3.2.2.1) is chosen for implementation.
Application
Compliance
Usage
ADPAC-1
CFI
48
ADPAC-2
CFI
60
ADPAC-3
CFI
1
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
70
FOCC-2
CFI
70
HAM
CFI
130
NAVC-1
CFI
(N/C)
NAVC-2
CFI
12
NAVC-3
CFI
1
NCDCF
CFI
30
NEL
CFI
1,000
NMCSSC
CFI
50
RADC-1
CFI
(N/C)
RADC-2
CFI
.7
RADC-3
CFI
30
RADC-4
CFI
25
SAC-1
CFID
520
SAC-2
CFID
5000
SAC-3
CFID
453
SAC-4
CFID
860
N(CFI)=
181
N(CFID) = = 4
151
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.5
Feature Name:
BASIC TABLE STRUCTURE ATTRIBUTE - PARALLEL
Resolution Inequality:
UGQT1 =.10
Resolution Equation:
U = Q89/(Q89A + Q89)
Number of users with usage rates:
Resolution:
AFC Reference:
A 3.3
GQT1 = 10
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.8157
ADPAC-2
CFI
.0625
ADPAC-3
CFI
1
CSC
CFI
(N/A)
FAA
CFID
0
FOCC-1
CFI
0
FOCC-2
CFI
.1428
HAM
CFI
1
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
.9767
NCDCF
CFI
0
NEL
CFI
.8000
NMCSSC
CFI
.3333
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
.5000
RADC-4
CFI
.9090
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFID
0
N(CFI) =
17
N(CFID) =
152
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.5
Feature Name:
BASIC TABLE STRUCTURE ATTRIBUTE - SERIAL
Resolution Inequality
UGQ = .10
Resolution Equation:
U = Q89A/(Q89A + Q89)
Number of users with usage rates:
Resolution:
AFC Reference:
A
33
GQ Tl = 16
Retain as nucleus
Data:
Application
Usage
Compliance
ADPAC-1
CFI
.1842
ADPAC-2
CFI
.9375
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFID
.9
FOCC-1
CFI
1
FOCC-2
CFI
.8572
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
2000
NMCSSC
CFI
6666
RADC-1
CFI
(N/C)
RADC-2
CFI
9
RADC-3
CFI
5000
RADC-4
CFI
9090
SAC-1
CFI
SAC-2
CFI
SAC-3
CFI
SAC-4
CFID
N(CFI) =
0232
N(CFID) =
20
153
2
N(CFM) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.6.1
Feature Name:
ORDINARY PACKING - Medium and/or Dense
Resolution Inequality:
(J GQ Tl = .02
Resolution Equation:
U = (Q95 + Q95A) +/Q7B
Number of users with usage rates:
Resolution:
AFC Reference:
A 3.4
GQ Tl = 14
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.0625
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFID
0
FOCC-2
CFID
0
HAM
CFI
0
NAVC-1
CFID
(N/C)
NAVC-2
CFID
0
NAVC-3
CFID
0
NCDCF
CFID
0
NEL
CFID
.3333
NMCSSC
CFID
0
RADC-1
CFI
(N/C)
RADC-2
CFID
.2222
RADC-3
CFI
.1666
RADC-4
CFID
.0222
SAC-1
CFID
(N/C)
SAC-2
CFID
(N/C)
SAC-3
CFID
(N/C)
SAC-4
CFID
0
N(CFI)=
8
N(CFID)=
154
M
N(CFNI)=
°
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.: 3.6.1
Feature Name:
ORDINARY PACKING - Medium
Resolution Inequal ity .
U GQ Tl = .05
Resolution Equation:
U = Q95/(Q95 + Q95A)
Number of users with usage rates:
Resolution:
AFC Reference:
A 3.4
GQT1 =0
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFID
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
0
RADC-4
CFNI
0
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI)=
N(CFID)=14
8
155
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
Feature Name:
ORDINARY PACKING - Dense
Resolution Inequality:
Resolution Equation:
UGQT1 =.05
U = Q95A/(Q95 + Q95A)
Number of users with usage rates:
Resolution:
Data:
AFC Reference: ^34
J 3.5.1. 3.6.1
GQT1 =5
Retain as optional (must be imple
is implemented)
Compliance
Application
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
1
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFI
1
NMCSSC
CFI
0
RADC-1
CFI
(N/C)
RADC-2
CFI
1
RADC-3
CFI
1
RADC-4
CFI
1
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI) = 8
N(CFID)=14
156
N(CFNI)= °
RESOLUTION ANALYSIS
JAQ Reference:
J 3. 0 •
Feature Name:
NO " PACKING NOTATION - "
Resolution Inequal ity:
UGQT1 = .05
Resolution Equation:
U = Q94/(Q93 + Q94)
1 •« 3.6.1
Number of users with usage rates:
Resolution:
AFC Reference:
A 3.4
GQ Tl = 1
Delete
Data:
Application
Compliancee
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFID
0
FOCC-2
CFID
0
HAM
CFI
0
NAVC-1
CFID
(N/C)
NAVC-2
CFID
0
NAVC-3
CFID
0
NCDCF
CFID
0
NEL
CFID
0
NMCSSC
CFID
0
RADC-1
CFI
(N/C)
RADC-2
CFID
.818
RADC-3
CFI
1
RADC-4
CFID
.027
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI) =
8
N(CFID) = 14
157
N(CFNI) = 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.3.6.2
Feature Name:
DEFINED PACKING
Resolution Inequal ity:
UGQ Tl = .10
Resolution Equation:
U = Q99/Q78
Number of users with usage rates:
Resolution:
AFC Reference:
A 3 5
GQ Tl = 17
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.4473
ADPAC-2
CFI
.9375
ADPAC-3
CFI
1
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
1
FOCC-2
CFI
1
HAM
CFI
.0625
NAVC-1
CFI
(N/C)
NAVC-2
CFI
1
NAVC-3
CFI
.9534
NCDCF
CFI
.6000
NEL
CFI
.1666
NMCSSC
CFI
.4666
RADC-1
CFI
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
0
RADC-4
CFI
.222
SAC-1
CFID
.3095
SAC-2
CFID
.5384
SAC-3
CFID
.7423
SAC-4
CFID
.7875
N(CFI)=
18
N(CFID) = 4
158
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.7.1
Feature Name:
INDEPENDENT OVERLAY DECLARATION
Resolution Inequality:
U GQ Tl = 1
Resolution Equation:
U = Q129
Number of users with usage rates:
Resolution:
AFC Reference: A 3.6
GQ Tl = 15
Retain as nucleus
Data:
Usage
Compliance
Application
ADPAC-1
CFI
19
ADPAC-2
CFI
7
ADPAC-3
CFI
0
CSC
CFID
(N/A)
FAA
CFNI
0
FOCC-1
CFI
30
FOCC-2
CFI
10
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
2
NAVC-3
CFI
0
NCDCF
CFI
5
NEL
CFI
30
NMCSSC
CFI
25
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
3
RADC-4
CFI
25
SAC-1
CFID
10
SAC-2
CFID
250
SAC-3
CFID
77
SAC-4
CFID
1370
N(CFI)=
N(CFID) =
16
159
5
N(CFN1) =
1
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.7.2
Feature Name:
SUBORDINATE OVERLAY DECLARATION
Resolution Inequality:
U GQ T1 = 1
Resolution Equation:
U - Q133
Number of users with usage rates:
Resolution:
AFC Reference: A 3.6
GQT1 =0
Delete
Data:
Application
Usage
Compliance
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
4
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFID
10
SAC-2
CFID
20
SAC-3
CFID
10
SAC-4
CFID
10
N(CFI) =
N(CFID) =
160
4
N(CFNI) =
17
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.1.1
Feature Name:
'LOC
Resolution Inequality:
UGQT1 =1
Resolution Equation:
U = Q136
Number of users with usage rates:
Resolution:
AFC Reference: A 3.8
GQ Tl = 4
Retain as nucleus*
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFID
(N/A)
FAA
CFNI
0
FOCC-1
CFI
5
FOCC-2
CFI
3
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
3
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFI
73
NMCSSC
CFNI
0
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFID
0
N(CFI) =
9
N(CFID)= 2
N(CFNI)= 11
*These data indicate that 'LOC be retained as optional. Responses to Interview Question 1-15 (2)
indicate nucleus, however.
.,.
I 61
RESOLUTION ANALYSIS
AFC Reference: ^ 4
JAQ Reference:
j 3.5.2.3.1
Feature Name:
PARENTHESIZED NUMERIC FORMULAS
Resolution Inequality:
N/A
Resolution Equation:
U = Q173
Number of users with usage rates:
Resolution:
GQ Tl • N/A
Accept as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
14
ADPAC-2
CFI
15
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
30
FOCC-2
CFI
100
HAM
CFI
230
NAVC-1
CFI
(N/C)
NAVC-2
CFI
20
NAVC-3
CFI
50
NCDCF
CFI
20
NEL
CFI
10
NMCSSC
CFI
1000
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
500
RADC-4
CFI
20
SAC-1
CFI
240
SAC-2
CFI
2700
SAC-3
CFI
968
SAC-4
CFI
2290
N(CFI) =
22
N(CFID)= 0
162
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.3.5
Feature Name:
MIXED ITEM TYPES IN NUMERIC FORMULAS
Resolution Inequality:
N/A
Resolution Equation:
U = Q189
Number of users with usage rates:
Resolution:
AFC Reference:
A4
GQ Tl = N/A
Accept as nucleus
Data:
Application
Compli a nee
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
20
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
1 or more
FOCC-1
CFI
150
FOCC-2
CFI
50
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
5
NAVC-3
CFI
0
NCDCF
CFID
10
NEL
CFI
150
NMCSSC
CFI
100
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
20
RADC-4
CFI
10
SAC-1.
CFI
100
SAC-2
CFI
4500
SAC-3
CFI
0
SAC-4
CFI
80
_
N(CFI) =
21
N(CFID) _
163
1
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.4
Feature Name:
ITEM TYPE INTEGER
Resolution Inequality:
N/A
Resolution Equation:
U = Q18/(Q18 + Q22 + Q38)
Number of users with usage rates:
Resolution:
AFC Reference:
A4
GQ Tl = 15
Accept as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFID
.7525
ADPAC-2
CFID
.1428
ADPAC-3
CFID
.4772
CSC
CFI
(N/A)
FAA
CFI
.9
FOCC-1
CFI
.0963
FOCC-2
CFI
.1428
HAM
CFI
.0303
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.2857
NAVC-3
CFI
.1000
NCDCF
CFI
.8000
NEL
CFI
.5000
NMCSSC
CFI
.0476
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
.9937
RADC-4
CFI
.7142
SAC-1
CFID
.9539
SAC-2
CFID
.8791
SAC-3
CFID
.9649
SAC-4
CFID
.9570
N(CFI) =
14
N(CFID) =
164
7
N(CFNI)
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.5
Feature Name:
ITEM TYPE FIXED POINT
Resolution Inequality:
N/A
Resolution Equation:
u = Q22/(Q18 + Q22 + Q38)
Number of users with usage rates:
Resolution:
AFC Reference:
A4
GQ = N/A
Accept as nucleus
Data:
Application
.omp liance
Usage
ADPAC-1
CFI
.2474
ADPAC-2
CFI
.6190
ADPAC-3
CFI
.5227
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.7831
FOCC-2
CFI
0
HAM
CFI
.9090
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.7142
NAVC-3
CFI
.6000
NCDCF
CFI
.1600
NEL
CFI
.3500
NMCSSC
CFI
.5714
RADC-1
CFID
(N/C)
RADC-2
CFI
9
RADC-3
CFI
.0062
RADC-4
CFID
.2857
SAC-1
CFID
.0184
SAC-2
CFID
.0293
SAC-3
CFID
.0155
SAC-4
CFID
.0184
N(CFI) =
16
N(CFID)=
165
6
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.5
Feature Name:
ITEM TYPE FIXED POINT - Scale in Declaration Blank or Zero
Resolution Inequality:
U GQ Tl = .02
Resolution Equation:
U = Q23/Q22
Number of users with usage rates:
Resolution:
AFC Reference:
A4
GQ Tl = 16
Retain as nucleus
Data:
Compliance
Application
Usage
ADPAC-1
CFI
(N/C)
ADPAC-2
CFI
.7692
ADPAC-3
CFI
.6521
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
1
FOCC-2
CFI
0
HAM
CFI
1.166
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
1
NCDCF
CFI
0
NEL
CFI
.0285
NMCSSC
CFI
.6666
RADC-1
CFI
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
1
RADC-4
CFI
.4166
SAC-1
CFI
0
SAC-2
CFI
1.156
SAC-3
CFI
.1666
SAC-4
CFI
0
N(CFI) =
16
N(CFID)=
166
0
N(CFNI) = 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.8
Feature Name:
RANGE ATTRIBUTE
Resolution Inequality:
UGQ Tl = .10
Resolution Equation:
U = Q34/(Q18 + Q22)
Number of users with usage rates:
Resolution:
AFC Reference:
A4 3
GQ Tl = 0
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFID
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI) =
2
N(CFID) =
167
N(CFNI) =
19
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.9
Feature Name:
ITEM TYPE FLOATING POINT
Resolution Inequality:
N/A
Resolution Equation:
U = Q38/(Q18 + Q22 + Q38)
Number of users with usage rates:
Resolution:
AFC Reference:
A 4.4
GQ Tl = N/A
Accept as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.2380
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.9
FOCC-1
CFI
.1204
FOCC-2
CFI
0
HAM
CFI
.0606
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
.3000
NCDCF
CFI
.0400
NEL
CFI
.1500
NMCSSC
CFI
.3809
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFI
.0276
SAC-2
CFI
.0915
SAC-3
CFI
.0194
SAC-4
CFI
.0245
N(CFI) = 22
N(CFID)=
168
°
N(CFNI) = 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.6
Feature Name:
SIGN ATTRIBUTE
Resolution Inequality:
U GET1 - .01
Resolution Equation:
U = Q26/(Q18 + Q22)
A 4.4
GQ Tl =14
Number of users with usage rates:
Resolution:
AFC Reference:
Retain as nucleus (Note:
Usage data refers to "signed" items)
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.04
ADPAC-2
CFI
.03
ADPAC-3
CFI
.05
CSC
CFI
(N/A)
FAA
CFI
.02
FOCC-1
CFI
1.095
FOCC-2
CFI
.04
HAM
CFI
.004
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
1
NCDCF
CFI
.008
NEL
CFI
.03
NMCSSC
CFI
.01
RADC-1
CFI
(N/C)
RADC-2
CFI
.03
RADC-3
CFI
.09
RADC-4
CFI
.01
SAC-1
CFI
.02
SAC-2
CFI
.008
SAC-3
CFI
.003
SAC-4
CFI
.02
N(CFI) =
22
N(CFID) = 0
169
N(CFNI)=
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.3.2
Feature Name:
PREFIX + AND-
Resolution Inequal 'ty:
U GQ Tl = 1
Resolution Equation:
|j = Q177
Number of users with usage rates:
Resolution:
AFC Reference:
QQ
^4 <
j] = 13
Retain as nucleus (Note modificati on of precedence (3.2.2.
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
2
CSC
(N/A)
FAA
CFI
*
FOCC-1
CFI
(N/C)
30
-
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
(N/C)
NAVC-2
CFI
20
NAVC-3
CFI
15
NCDCF
CFI
5
NEL
CFI
3
NMCSSC
CFID
10
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
0
RADC-4
CFI
20
SAC-1
CFID
140
SAC-2
CFID
9000
SAC-3
CFID
64
SAC-4
CFID
1300
N(CFI)= 15
0
•
N(CFID) =
55
5
''Misprinted page in JAQ made it impossible for FAA to respond.
170
N(CFNI)= 1
RESOLUTION ANALYSIS
JAQ Reference:
Feature Name:
J 3.5.2.3.3
AFC Reference:
EXPONENTIATION
Resolution Inequality:
N/A
Resolution Equation:
N/A
Number of users with usage rates:
Resolution:
Accept as
A 4.5
OPERATOR
GQ Tl = N/A
Nucleus
Data:
Application
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFID
FOCC-1
CFI
FOCC-2
CFI
HAM
CFID
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFID
RADC-1
CFI
RADC-2
CFID
RADC-3
CFI
RADC-4
CFI
SAC-1
CFID
SAC-2
CFID
SAC-3
CFID
SAC-4
CFID
N(CFI) =
14
h
N(CFID)=
171
Usage
8
N(CFNI) =
0
RESOLUTION ANALYSIS
AFC Reference: A 4.6
JAQ Reference:
J3.5.2.3.3
Feature Name:
EXPONENTIATION NOTATION - (* *)
Resolution Inequality:
U G Q Tl = 1
Resolution Equaltion:
U - Q181
Number of users with usage rates:
G Q Tl =10
Resolution: Delete
Data:
Note: Because of an oversight in the
preparation of the JAQ, insufficient
information regarding the use of exponentiation operators was obtained. We are
recommending that (* *) be dropped,
since ** is widely used in other high
level languages, and since only one
operator is required.
Compliance
Application
Usage
ADPAC-1
CFI
3
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
1 or more
FOCC-1
CFI
5
FOCC-2
CFI
0
HAM
CFNI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
5
NAVC-3
CFI
0
NCDCF
CFI
2
NEL
CFI
20
NMCSSC
CFNI
0
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
5
RADC-4
CFI
0
SAC-1
CFI
20
SAC-2
CFI
225
SAC-3
CFI
15
SAC-4
CFI
20
N(CFI) = 19
N(CFID)= 0
172
N(CFNI) = 3
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.3.4
Feature Name:
Absolute Value Operator
Resolution Inequality:
N/A
Resolution Equation:
N/A
AFC Reference:
Number of users with usage rates:
Resolution:
A 4.7
GQ Tl = N/A
Retain as optional
Data:
Compl i a nee
Application
ADPAC-1
CFID
ADPAC-2
CFID
ADPAC-3
CFID
CSC
CFI
FAA
CFID
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFID
RADC-1
CFI
RADC-2
CFID
RADC-3
CFI
RADC-4
CFI
SAC-1
CFID
SAC-2
CFID
SAC-3
CFID
SAC-4
CFID
N(CFI) =
Usage
Note:
Owing to an oversight in the
preparation of the JAQ, insufficient
data regarding use of absolute value
operator were solicited.
In the
interests of being fair, we have
declared this feature as optional.
12
h
N(CFID)=
173
10
N(CFNI)= 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.3.4
Feature Name:
ABSOLUTE VALUE NOTATION - (/ /)
Resolution Inequality:
N/A
Resolution Equation:
Q185
Number of users with usage rates:
Resolution:
Delete
Data:
Application
AFC Reference: A 4.8
GE Tl = N/A
Basis of Resolution: Only one notation for absolute
value is required. The number of application which do not
implement (/ /) or which have 0 usage is 15. Therefore (/ /)
is dropped in favor of ABS.
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
5
NAVC-3
CFI
2
NCDCF
CFI
0
NEL
CFI
0
NMCSSC
CFI
20
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI) = 14
N(CFID) = 0
174
N(CFNI) =8
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.9
Feature Name:
REM
AFC Reference:
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q265/Q18
Number of users with usage rates:
Resolution:
A 4.9
GQ Tl =0
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
1
N(CFID)=
175
0
N(CFNI) =
21
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.7
Feature Name:
REMQUO
AFC Reference: A 4.9
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q257/Q18
Number of users with usage rates:
Resolution:
GQ Tl = 7
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.001
ADPAC-2
CFI
0
ADPAC-3
CFI
.009
CSC
CFI
(N/A)
FAA
CFI
.08
FOCC-1
CFID
0
FOCC-2
CFID
0
HAM
CFI
.05
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
.01
RADC-4
CFNI
0
SAC-1
CFID
.001
SAC-2
CFID
.003
SAC-3
CFID
.001
SAC-4
CFID
.001
N(CFI)=
9
N(CFID)=
176
6
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.7
Feature Name:
ITEM TYPE DUAL
AFC Reference:
Resolution Inequality:
U GQ Tl = .10
Resolution Equation:
U = Q30/Q14
Number of users with usage rates:
Resolution:
A5
GQ Tl =0
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFNI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFI
0
NAVC-1
CFNI
(N/C)
NAyC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI) =
1
N(CFID) =
177
N(CFNI)=
21
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.4
Feature Name:
DUAL FORMULAS
AFC Reference:
Resolution Inequality:
U GQ Tl = 0
Resolution Equation:
U = Q193/Q14
Number of users with usage rates:
Resolution:
A5
GQ Tl - T2 = 0
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFNI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)= C
N(CFID)=
178
0
N(CFNI) =
22
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.7
Feature Name:
RELATIONAL FORMULAS (excluding "Chained")
Resolution Inequality:
N/A
Resolution Equation:
N/A
AFC Reference:
Number of users with usage rates:
Resolution:
A6.1
GQ Tl = N/A
Accept as nucleus
Data:
Application
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFID
NMCSSC
CFID
RADC-1
CFI
RADC-2
CFID
RADC-3
CFI
RADC-4
CFI
SAC-1
CFID
SAC-2
CFID
SAC-3
CFID
SAC-4
CFID
N(CFI)=
15
N(CFID)=7
179
Usage
N(CFNI) = 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.7
AFC Reference:
Feature Name:
"CHAINED" RELATIONAL FORMULAS
Resolution Inequality:
U GQ 77 = 1
Resolution Equation:
u = Q205
Number of users with usage rates:
Resolution:
A 6.2
GQ Tl = 9
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
37
ADPAC-2
CFI
15
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
1 or more
FOCC-1
CFI
10
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
5
NAVC-3
CFI
0
NCDCF
CFI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
10
RADC-4
CFI
0
SAC-1
CFI
100
SAC-2
CFI
700
SAC-3
CFI
540
SAC-4
CFI
600
N(CFI) =
19
N(CFID)=
80
0
N(CFNI)= 3
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.2.8
AFC Reference:
Feature Name:
BOOLEAN FORMULAS ~ with AND, OR, NOT
Resolution Inequality:
(j GQ Tl = 1
Resolution Equation:
(j = Q209
Number of users with usage rates:
Resolution:
A7.1
GQ Tl = 15
Retain as nucleus
Data:
Compliance
Application
Usage
ADPAC-1
CFI
18
ADPAC-2
CFI
15
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
500
FOCC-2
CFI
15
HAM
CFI
300
NAVC-1
CFI
(N/C)
NAVC-2
CFI
10
NAVC-3
CFI
20
NCDCF
CFI
20
NEL
CFI
30
NMCSSC
CFI
700
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
400
RADC-4
CFI
0
SAC-1
CFI
1480
SAC-2
CFI
7000
SAC-3
CFI
1700
SAC-4
CFI
8050
N(CFI) =
21
N(CFID)= 0
181
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.12
Feature Name:
ITEM TYPE BOOLEAN
AFC Reference:
Resolution Inequality:
U GQ Tl = .02
Resolution Equation:
U = Q54/Q14
Number of users with usage rates:
Resolution:
A 7.2
GQ Tl = 8
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.0500
ADPAC-2
CFI
.1083
ADPAC-3
CFI
.2380
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
.0480
FOCC-2
CFI
0
HAM
CFNI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0500
NAVC-3
CFI
.0050
NCDCF
CFI
.2000
NEL
CFID
.0100
NMCSSC
CFI
.3333
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI) =
15
N(CFID)
N
=
182
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.3.1
AFC Reference:
Feature Name:
NUMERIC ITEM TYPE CONVERSION IN THE ASSIGNMENT STATEMENT
Resolution Inequality:
U GQ Tl = .01
Resolution Equation:
U = Q213/Q217A
Number of users with usage rates:
Resolution:
A 8
GQ Tl = 12
Accept as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
(N/C)
ADPAC-2
CFI
.0428
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFID
.2
FOCC-1
CFI
.0125
FOCC-2
CFI
.0500
HAM
CFID
.0600
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.6000
NAVC-3
CFI
0
NCDCF
CFI
.0500
NEL
CFI
.0350
NMCSSC
CFI
.2000
RADC-1
CFI
(N/C)
RADC-2
CFID
.2
RADC-3
CFI
.0083
RADC-4
CFI
.0250
SAC-1
CFID
.0018
SAC-2
CFID
.0700
SAC-3
CFID
.0014
SAC-4
CFID
.0023
N(CFI) =
15
N(CFID)=
183
7
N(CFNI) =
°
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.3.1
Feature Name:
BOOLEAN ASSIGNMENT STATEMENT
AFC Reference: A 8
Resolution Inequality:
N/A
Resolution Equation:
U = Q217/Q217A
Number of users with usage rates:
Resolution:
GQ Tl = N/A
Retain as nucleus
Data:
Application
Compli a nee
Usage
ADPAC-1
CFI
(N/C)
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFID
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFID
0
NAVC-1
CFI
(N/C
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFI
0125
NEL
CFI
.0025
NMCSSC
CFI
.2000
RADC-1
CFI
(N/C)
RADC-2
CFID
0
RADC-3
CFID
c
RADC-4
CFID
0
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI) =
14
h
N(CFID)
=
184
N(CFNI) = 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.6.1
Feature Name:
ITEM PRESET
AFC Reference:
Resolution Inequality:
U GQ Tl = .02
Resolution Equation:
U = Ql 13/Q14
Number of users with usage rates:
Resolution:
A 8.1
GQ Tl = 13
Retain as nucleus
Data:
Compliance
Application
Usage
ADPAC-1
CFI
.1714
ADPAC-2
CFI
.0416
ADPAC-3
CFI
.3809
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
.0720
FOCC-2
CFI
.6000
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.1000
NAVC-3
CFI
.0650
NCDCF
CFI
.0400
NEL
CFI
.0400
NMCSSC
CFI
1.333
RADC-1
CFI
(N/C)
RADC-2
CFI
2
RADC-3
CFI
.1500
RADC-4
CFI
.3738
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
17
h
N(CFID)=
0
185
N(CFNI) = 5
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.6.2
Feature Name:
TABLE PRESET
AFC Reference:
Resolution Inequality:
U GQ T = .02
Resolution Equation:
U = Q116/Q78
Number of users with usage rates:
Resolution:
A 8.1
GQ Tl = 16
Retain as nucleus
Data:
Complia nee
Application
Usage
ADPAC-1
CFI
.1315
ADPAC-2
CFI
.1875
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
.4347
FOCC-2
CFI
.5000
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.3333
NAVC-3
CFI
0
NCDCF
CFI
.1000
NEL
CFI
.3333
NMCSSC
CFI
.2000
RADC-1
CFI
(N/C)
RADC-2
CFID
.2
RADC-3
CFI
2.000
RADC-4
CFI
.0777
SAC-1
CFID
.3333
SAC-2
CFID
1
SAC-3
CFID
.1061
SAC-4
CFI
.1088
N(CFI)= 18
N(CFID)=
186
4
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.6.3
AFC Reference:
Feature Name:
ARRAY PRESET
Resolution Inequality:
U GQ Tl = .02
Resolution Equation:
U = Q120/Q74
Number of users with usage rates:
Resolution:
A8.1
GQ Tl = 2
Retain as option — Must be implemented if ARRAY is implemented
Data:
Application
Comp lance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
(N/C)
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFI
.3000
NMCSSC
CFNI
0
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
1.000
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
N(CFID) = =
7
187
0
N(CFNI) =
14
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.6.4
Feature Name:
STRING PRESET
Resolution Inequality:
Resolution Equation:
AFC Reference:
A 8.1
U GQ Tl = .02
U = Q124/Q103
Number of users with usage rates:
GQ Tl = 0
Resolution: Delete
Data:
Note: STRING is deleted.
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
(N/C)
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)= 1
N(CFID)=
188
0
N(CFNl) =
21
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.10
AFC Reference:
Feature Name:
ROUNDED NUMERIC ASSIGNMENT —
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q42/(Q18 + Q22 + Q38)
Number of users with usage rates:
Resolution:
Delete
A8.2
Round Attribute
GQ Tl =0
Note: Extended Numeric Round (3.2.2.14) is made optional.
Data:
Application
Compliance
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFNI
0
NEL
CFNI
0
NMCSSC
CFNI
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
:2
N(CFID)=
189
0
N(CFNI) =
20
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.3.2
Feature Name:
EXCHANGE STATEMENT
Resolution Inequality:
Resolution Equation:
AFC Reference:
U GQ Tl = .01
U = Q221/Q217A
Number of users with usage rates:
Resolution:
A8.3
GQ Tl = 3
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
(N/C)
ADPAC-2
CFI
.0142
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
.0012
FOCC-2
CFI
.0100
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
(N/C)
NCDCF
CFI
.0025
NEL
CFI
.0035
NMCSSC
CFI
.1000
RADC-1
CFI
(N/C)
RADC-2
CFI
.1
RADC-3
CFI
0
RADC-4
CFI
.0150
SAC-1
CFI
.0030
SAC-2
CFI
.0240
SAC-3
CFI
.0158
SAC-4
CFI
.0103
N(CFI)=
22
N(CFID)=
190
0
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.2
Feature Name:
COMPUND STATEMENT
Resolution Inequality:
N/A
Resolution Equation:
U = Q234
AFC Reference:
Number of users with usage rates:
Resolution:
A9.1
GQ Tl = N/A
Accept as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
100
ADPAC-2
CFI
55
ADPAC-3
CFI
30
CSC
CFI
(N/A)
FAA
CFI
1 or more
FOCC-1
CFI
2000
FOCC-2
CFI
200
HAM
CFI
750
NAVC-1
CFI
(N/C)
NAVC-2
CFI
30
NAVC-3
CFI
0
NCDCF
CFI
40
NEL
CFI
200
NMCSSC
CFI
700
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
500
RADC-4
CFI
100
SAC-1
CFI
9360
SAC-2
CFI
11,000
SAC-3
CFI
4140
SAC-4
CFI
17,500
N(CFI) =
2
N(CFID)=
191
0
N(CFNI) = 0
RESOLUTION ANALYSIS
JAQ Reference:
Feature Name:
J 3.5.5
AFC Reference:
GOTO STATEMENT
Resolution Inequality:
Resolution Equation:
N/A
U = Q276
Number of users with usage rates:
Resolution:
A 9.2
Accept as nucleus
Data:
Application
GQ T1 = N/A
Note: The form containing a subscript is implemented
only if Index Switch is implemented.
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
420
ADPAC-3
CFI
33
CSC
CFI
(N/A)
FAA
CFI
1 or more
FOCC-1
CFI
0
FOCC-2
CFI
100
HAM
CFI
250
NAVC-1
CFI
(N/C)
NAVC-2
CFI
100
NAVC-3
CFI
250
NCDCF
CFI
60
NEL
CFI
400
NMCSSC
CFI
200
RADC-1
CFI
(N/C)
RADC-2
CFI
1 or more
RADC-3
CFI
1000
RADC-4
CFI
40
SAC-1
CFI
10080
SAC-2
CFI
28,000
SAC-3
CFI
5708
SAC-4
CFI
7120
N(CFI) =
22
N(CFID)=
192
0
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.7
Feature Name:
STOP
AFC Reference:
Resolution Inequality:
U GQ Tl = 1
Resolution Equation:
U = Q319
Number of users with usage rates:
A 9.3
GQ Tl =9
Resolution:
Retain as nucleus
Note: Modification in 3.2.2.12
Data:
Application
Complia nee
Usage
ADPAC-1
CFI
11
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFID
(N/A)
FAA
CFID
1 or more
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
7
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFID
15
NMCSSC
CFI
10
RADC-1
CFID
(N/C)
RADC-2
CFNI
0
RADC-3
CFID
1
RADC-4
CFID
0
SAC-1
CFID
220
SAC-2
CFID
10
SAC-3
CFID
160
SAC-4
CFI
80
N(CFI)=
11
N(CFID)=
193
9
N(CFNI) =
2
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.7
AFC Reference:
Feature Name:
STOP Statement Label (Pausing)
Resolution Inequality:
U GQ Tl = 1
Resolution Equation:
U = Q318
Number of users with usage rates:
A
?.3
GQ Tl = 1
Resolution: Delete
Note: Pause statement in 3.2.2.13
Application
Compliance
Uiv-ge
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFID
(N/A)
FAA
CFID
1 or more
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFID
5
NMCSSC
CFI
0
RADC-1
CFID
(N/C)
RADC-2
CFNI
0
RADC-3
CFID
0
RADC-4
CFID
0
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFI
0
N(CFI)=
11
N(CFID)= 9
194
N(CFNI) =
2
RESOLUTION ANALYSIS
JAQ Reference:
j 3.5.5.3
Feature Name:
)F
AFC Reference:
STATEMENT
Resolution Inequality:
N/A
Resolution Equation:
(j = Q291/(Q291 + Q295 + Q284 + Q280)
Number of users with usage rates:
Resolution:
A 9.4.1
QQ
j] - |\|/A
Accept as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.9742
ADPAC-2
CFI
.9090
ADPAC-3
CFI
.9756
CSC
CFI
(N/A)
FAA
CFI
.9
FOCC-1
CFI
.9615
FOCC-2
CFI
.8196
HAM
CFI
.9615
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.9708
NAVC-3
CFI
.9708
NCDCF
CFI
.6250
NEL
CFI
.9523
NMCSSC
CFI
.7407
RADC-1
CFI
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
.9685
RADC-4
CFI
1
SAC-1
CFI
.9361
SAC-2
CFI
.9529
SAC-3
CFI
.9492
SAC-4
CFI
.9906
N(CFI) =
22
N(CFID)=
195
0
N(CFNI) = 0
RESOLUTION ANALYSIS
AFC Reference:
JAQ Reference:
J 3.5.5.4
Feature Name:
IFEITH/ORIF STATEMENT
Resolution Inequality:
U GQ Tl =.02
Resolution Equation:
U = Q295/(Q291 + Q295 + Q284 + Q280)
Number of users with usage rates:
Resolution:
A 9.4.2
GQ Tl =7
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.0103
ADPAC-2
CFI
.0363
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
.0384
FOCC-2
CFI
.8196
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0097
NAVC-3
CFI
.0291
NCDCF
CFI
.1250
NEL
CFI
.0068
NMCSSC
CFI
.1111
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
.0169
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)= 17
N(CFID)= 0
196
N(CFNI)= 5
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.2
Feature Name:
INDEX SWITCHES
AFC Reference:
Resolution Inequality:
U GQ Tl = .02
Resolution Equation:
U = Q284/(Q291 + Q295 + Q284 + Q280)
Number of users with usage rates:
Resolution:
A9.4.3
GQ Tl =6
Retain as optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.0181
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
0
FOCC-2
CFI
.1639
HAM
CFI
.0192
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0097
NAVC-3
CFI
0
NCDCF
CFI
.1250
NEL
CFI
.0272
NMCSSC
CFI
.0740
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
.0096
RADC-4
CFI
0
SAC-1
CFID
.0036
SAC-2
CFID
.0071
SAC-3
CFID
.0187
SAC-4
CFID
.0025
N(CFI) =
18
N(CFID)= 4
197
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.2
AFC Reference:
Feature Name:
SWITCH NAMES within SWITCH DECLARATIONS
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q285/Q284
Number of users with usage rates:
Resolution:
A 9.4.3
GQ Tl = 1
Delete
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFI
0
NEL
CFI
0
NMCSSC
CFI
0
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI)=
18
N(CFID)=
198
4
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.2
Feature Name:
CLOSE NAMES within Switch Declarations
Resolution Inequality:
Resolution Equation:
AFC Refe renee:
U GQ Tl = .05
U = Q286/Q284
Number of users with usage rates:
Resolution:
A9.4.3
GQ Tl = 0
Delete
Data:
Application
Compl i a nee
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFI
0
NEL
CFI
0
NMCSSC
CFI
0
RADC-1
CFI
(N/C)
RADC-2
CFI
0
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI) =
18
N(CFID) =
199
N(CFNI)= 0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.1
Feature Name:
ITEM SWITCH
AFC Reference:
Resolution Inequality
UGQ Tl = .01
Resolution Equation:
U = Q280/(Q291 _ Q295 + Q284 + Q280)
Number of users with usage rates:
Resolution:
A 9.4.4
GQ Tl =7
Retain as optional
Data:
Application
omp lance
ADPAC-1
CFI
.5309
ADPAC-2
CFI
.0363
ADPAC-3
CFI
.0243
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
0
FOCC-2
CFI
.8196
HAM
CFI
.0192
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0097
NAVC-3
CFI
0
NCDCF
CFI
.1250
NEL
CFI
.0136
NMCSSC
CFI
.0740
RADC-1
CFI
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
,0048
RADC-4
CFI
0
SAC-1
CFID
.0602
SAC-2
CFID
.0399
SAC-3
CFI
.0319
SAC-4
CFI
.0067
N(CFI) =
N(CFID)
=
Is
18
200
Usage
N(CFNi) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.5
Feature Name:
FOR LOOP - One Factor
AFC Reference:
Resolution Inequality: U GO T1 = .05
Resolution Equation:
U = Q299/(Q74 + Q78 + Q103)
Number of users with usage rates:
Resolution:
GQ T1 = 15
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
2.289
ADPAC-2
CFI
.0625
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
.1739
FOCC-2
CFI
.2500
HAM
CFI
.0625
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.1333
NAVC-3
CFI
0
NCDCF
CFI
0
NEL
CFI
.0750
NMCSSC
CFI
.4000
RADC-1
CFID
(N/C)
RADC-2
CFI
.2
RADC-3
CFI
12.90
RADC-4
CFI
.0222
SAC-1
CFI
2.976
SAC-2
CFI
.2492
SAC-3
CFI
.4751
SAC-4
CFI
.4578
N(CFI)=
21
N(CFID)=
201
1
N(CI
A 9.5
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.5
Feature Name:
FOR LOOP - Two Factor
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q300/(Q74 + Q78 + Q103)
Number of users with usage rates:
Resolution:
AFC Reference:
A9.5
GQ Tl = 17
Retain as nucleus
Data:
Application
.ompl i a nee
ADPAC-1
CFI
.0789
ADPAC-2
CFI
.1875
ADPAC-3
CFI
.6000
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
.6521
FOCC-2
CFI
.5000
HAM
CFI
.3125
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0666
NAVC-3
CFI
0
NCDCF
CFI
.0400
NEL
CFI
.1000
NMCSSC
CFI
.2000
RADC-1
CFID
(N/C)
RADC-2
CFI
.7
RADC-3
CFI
1.129
RADC-4
CFI
.1666
SAC-1
CFI
.1904
SAC-2
CFI
.2419
SAC-3
CFI
.7408
SAC-4
CFI
.3421
N(CFI) =
N(CFID) =
21
202
Usage
N(CFNI)=
0
RESOLUTION ANALYSIS
JAQ Reference:
J3, .5.5.5
Feature Name:
FOR LOOP - Three Factor
Resolution Inequa lity:
UGQ Tl = .05
Resolution Equation:
U = : Q301/(Q74 + Q78 + Q103 )
Number of users with usage rates:
Resolution:
AFC Reference:
A 9.5
GQ Tl = 17
Reta in as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.6250
ADPAC-3
CFI
1.600
CSC
CFI
(N/A)
FAA
CFI
.9
FOCC-1
CFI
3.478
FOCC-2
CFI
1.250
HAM
CFI
3.125
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.6666
NAVC-3
CFI
0
NCDCF
CFI
.4000
NEL
CFI
.1750
NMCSSC
CFI
2.666
RADC-]
CFID
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
6.451
RADC-4
CFI
1.222
SAC-1
CFI
2.761
SAC-2
CFI
.8211
SAC-3
CFI
1.754
SAC-4
CFI
3.026
N(CFI) = 21
N(CFID)=
203
1
N(CFNi) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.5
Feature Name:
AFC Reference:
A 9.5
FOR LOOP - Decrementing
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q302/Q301
Number of users with usage rates:
GQ Tl = 15
Resolution: Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
(N/C)
ADPAC-2
CFI
.1000
ADPAC-3
CFI
.2500
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
.0625
FOCC-2
CFI
.6250
HAM
CFI
.0200
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.2000
NAVC-3
CFI
0
NCDCF
CFI
.2500
NEL
CFI
.1428
NMCSSC
CFI
.5000
RADC-1
CFID
(N/C)
RADC-2
CFI
.7
RADC-3
CFI
.0500
RADC-4
CFI
0
SAC-1
CFI
.3809
SAC-2
CFI
.0892
SAC-3
CFI
.2405
SAC-4
CFI
.1528
N(CFI)=
21
N(CFID)= 1
204
N(CFNI)=
°
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.5.6
Feature Name:
TEST STATEMENT
Resolution Inequality:
Resolution Equation:
U GQ Tl = .05
U = Q310/(Q299 + Q300 + Q301)
Number of users withjusage rates:
Resolution:
AFC Reference:
GQ Tl - 14
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
.1555
ADPAC-2
CFI
.1428
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.0404
FOCC-2
CFI
.3125
HAM
CFI
.3571
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.2307
NAVC-3
CFI
0
NCDCF
CFI
.9090
NEL
CFI
.0214
NMCSSC
CFI
.2857
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
.1181
RADC-4
CFI
.0787
SAC-]
CFI
.2610
SAC-2
CFI
.5251
SAC-3
CFI
.7140
SAC-4
CFI
1.011
N(CFI) =
21
N(CFID)=
205
0
N(CF
A 9.5.4
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.10
Feature Name:
PROGRAM
Resolution Inequality:
Resolution Equation:
AFC Reference:
A9.6,A9.7
N/A
N/A
Number of users with usage rates:
GQ Tl = N/A
Resolution:
Retain as nucleus
Note: Extension proposed in 3.2.2.15.
Data:
Application
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFID
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFID
NMCSSC
CFID
RADC-1
CFI
RADC-2
CFID
RADC-3
CFID
RADC-4
CFID
SAC-1
CFID
SAC-2
CFID
SAC-3
CFID
SAC-4
CFID
N(CFI)=
12
N(CFID)=
206
Usage
10
N(CFNI) =
0
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.6
Feature Name:
AFC Reference:
PROCEDURE (Excluding Function)
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q251/(Q251 + Q257 + Q261)
Number of users with usage rates:
Resolution:
A 9.6.1
GQ Tl = 17
Retain as nuc eus
Data:
Application
Compliance
Usage
ADPAC-1
CFI
1
ADPAC-2
CFI
.2916
ADPAC-3
CFI
.2857
CSC
CFI
( N/A)
FAA
CFID
.9
FOCC-1
CFI
.8823
FOCC-2
CFI
.8196
HAM
CFI
1
NAVC-1
CFID
(N/C)
NAVC-2
CFID
(N/C)
NAVC-3
CFID
(N/C)
NCDCF
CFI
.7500
NEL
CFID
.8571
NMCSSC
CFI
.6250
RADC-1
CFI
(N/C)
RADC-2
CFI
.9
RADC-3
CFI
.1250
RADC-4
CFI
1
SAC-1
CFID
.5714
SAC-2
CFID
.6060
SAC-3
CFID
.8153
SAC-4
CFID
.7128
N(CFI) =
13
N(CFID) =
207
9
N(CFNI) =
°
RESOLUTION ANALYSIS
JAQ Reference:
Feature Name:
J 3.5.4.6
AFC Reference: A 9.6.1
Close in Parameter List
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q252/Q251
Number of users with usage rates:
Resolution:
GQ Tl = 1
Retain as Optional
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
(N/C)
NCDCF
CFI
0
NEL
CFI
.0833
NMCSSC
CFI
0
RADC-1
CFI
(N/C)
RADC-2
CFI
0
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
17
N(CFID)=
208
0
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.6
Feature Name:
Statement label in Parameter List
AFC Reference:
Resolution Inequality:
U GQ T1 = .05
Resolution Equation:
U = Q253/Q251
Number of users with usage rates:
Resolution:
A.9.6.1
GE Tl = T2 =5
Retain as optional
Data:
Application
Usage
Compliance
ADPAC-1
CFI
.0270
ADPAC-2
CFI
.1428
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
NCDCF
CFI
.0666
NEL
CFID
.1666
NMCSSC
CFI
.4000
RADC-1
CFI
(N/C)
RADC-2
CFf
.2
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI) =
-
(N/C)'
N(CFID)=
r
17
209
0
N(CFNI) =
5
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.4.8
Feature Name:
FUNCTION
AFC Reference:
Resolution Inequality:
U GQ Tl = .05
Resolution Equation:
U = Q261/(Q251 + Q247 + Q261)
Number of users with usage rates:
Reso'ution:
A9.6.1
GQ Tl = 12
Retain as nucleus
Data:
Application
Compliance
Usage
ADPAC-i
CFI
0
ADPAC-2
CFI
.04*16
ADPAC-3
CFI
.7142
CSC
CFI
(N/A)
FAA
CFID
.2
FOCC-i
CFI
.1176
FOCC-2
CFI. 1639
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.3125
NAVC-3
CFI
NCDCF
CFI
.2500
NEL
CFI
0
NMCSSC
CFI
.1875
RADC-1
CFI
(N/C)
RADC-2
CFF
.2
RADC-3
CFI
.7500
RADC-4
CFI
0
SAC-1
CFID
.2571
SAC-2
CFID
.2121
SAC-3
CFID
.0119
SAC-4
CFID
.2666
N(CF!)=
0
-
17
N(CFID)=
210
5
N(CFNI)=
0
RESOLUTION ANALYSIS
JAQ Reference:
j 3.5.4.5
Feature Name:
CLOSE
AFC Reference:
Resolution Inequality:
\j QQ J] = .05
Resolution Equation:
y = Q247/(Q251 + Q247 + Q261)
Number of users with usage rates:
Resolution:
Retain as nucleus
A9.6.2
GQ Tl = 11
*
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.6666
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-1
CFI
0
FOCC-2
CFI
.1639
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0625
NAVC-3
CFI
0
NCDCF
CFI
0
NEL
CFI
.1428
NMCSSC
CFI
.1875
RADC-1
CFI
(N/C)
RADC-2
CFf
.1
RADC-3
CFI
.1250
RADC-4
CFI
0
SAC-1
CFI
.1714
SAC-2
CFI
.1818
SAC-3
CFI
.1027
SAC-^
CFI
.0205
N(CFI) =
222
N(CFID) = 0
*
N(CFN!)=
0
*These data indicate retention as optional, Interview responses to question 1-27 require
retention as nucleus
211
RESOLUTION ANALYSIS
AFC Reference:
JAQ Reference:
j 3.5.5.6
Fecture Name:
RETURN STATEMENT
Resolution Inequality:
Resolution Equation:
N/A
Q134
Number of users with usage rates:
Resolution:
A9.6.3
QQ
yj = ^ //^
Accept as nucleus
Data:
Usage
Compliance
Application
ADDAC-1
CFI
48
ADPAC-2
CFI
60
ADPAC-3
CFI
3
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
300
FOCC-2
CFI
25
HAM
CFI
50
NAVC-1
CFI
(N/C)
NAVC-2
CFI
25
NAVC-3
CFI
40
NCDCF
CFI
30
NEL
CFID
100
NMCSSC
CFI
75
RADC-T
CFI
(N/C)
RADC-2
CFf
.9
RADC-3
CFI
50
RADC-'-
CFI
20
SAC-1
CFI
700
SAC-2
CFI
1200
SAC-3
CFI
686
SAC-4
CFI
1520
N(CFI) =
N(CF!D)=
21
212
1
N(CFN1) = 0
RESOLUTION ANALYSIS
AFC Reference:
JAG Reference:
J 3.5.4.11
Feature Nome:
PROGRAM DECLARATION
Resolution Inequality:
Resolution Equation:
N/A
U = Q275
Number of users with usage rates:
Resolution:
A9.7
GQ Tl = N/A
Retain as optional
Date:
Compliance
Application
Usage
ADPAC-1
CFNI
0
ADPAC-2
CFNI
0
ADPAC-3
CFNI
0
CSC
CFNI
0
FAA
CFI
1 or more
FOCC-1
CFI
1
FOCC-2
CFI
0
HAM
CFNI
0
NAVC-1
CFI
0
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFNI
0
NEL
CFID
1
NMCSSC
CFNI
0
RADC-1
CFI
0
RADC-2
CFNl
0
RADC-3
CFI
0
RADC-4
CFI
0
SAC-1
CFNI
1260
SAC-2
CFNI
16
SAC-3
CFNI
110
SAC-/
CFI
50
N(CFID)
r-
N(CFI) = 10
213
N(CFNI)
11
RESOLUTION ANALYSIS
JAQ Reference:
AFC Reference:
J 3.5.4.4
Feature Nc me:
DIRECT CODE
Resolution Inequality:
UGQ Tl • • 1
Resolution Equation:
U = Q242
Number of users with usage rates:
Resolution:
A9.8
GQ Tl = 16
Retain as nucelus
Dcta:
Application
Usage
C ompliance
ADPAC-1
CFI
5
ADPAC-2
CFI
130*
ADPAC-3
CFI
12
CSC
CFI
(N/A)
FAA
CFI
1 or more
FOCC-T
CFI
60
FOCC-2
CFI
50
HAM
CFI
15
NAVC-1
CFI
(N/C)
NAVC-2
CFI
10
NAVC-3
CFI
NCDCF
CFI
15
NEL
CFI
50
NMCSSC
CFI
50
RADC-1
CFI
(N/C)
RADC-2
CFID
1 or more
RADC-3
CFI
150
RADC-4
CFI
0
SAC-1
CFID
880
SAC-2
CFID
2000
SAC-3
CFID
620
SAC-4
CFID
620
N(CFI)=
5
-
17
N(CFID)=
214
5
N(CFN1)= 0
RESOLUTION ANALYSIS
JAQ Reference:
AFC Reference:
J 3.5.1.5
Feature Name:
STRUCTURE FILE
Resolution Inequality:
N/A
Resolution Equation:
U = Q107
Number of users with usage rates:
Resolution:
GQ Tl
N/A
Delete in favor of features specificed in 3.2.2.11
Data:
Application
Compliance
Usage
ADPAC-1
CFI
34
ADPAC-2
CFI
0
ADPAC-3
CFI
2
CSC
CFID
(N/A)
FAA
CFNI
0
FOCC-1
CFID
80
FOCC-2
CFID
HAM
CFNI
0
NAVC-1
CFID
(N/C)
NAVC-2
CFID
6
NAVC-3
CFID
NCDCF
CFID
38
NEL
CFID
300
NMCSSC
CFI
20
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFID
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CF!)=
,
20
*
4
2
N(CFID)=
215
9
N(CFNI) = 9
A 10
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.5
Feature Name:
STRUCTURE FILE - Hollerith or Binary
Resolution Inequality:
Resolution Equation:
AFC Reference:
N/A
y = Q108/Q107
Number of users with usage rates:
Resolution:
A 10
GQ Tl = N/A
Delete in favor of features specified in 3.2.2.11
Data:
Application
Compliance
Usage
ADPAC-1
CFI
1
ADPAC-2
CFI
0
ADPAC-3
CFI
1
CSC
CFID
(N/A)
FAA
CFNI
0
FOCC-1
CFID
.0500
FOCC-2
CFID
HAM
CFNI
0
NAVC-1
CFID
(N/C)
NAVC-2
CFID
0
NAVC-3
CFID
NCDCF
CFID
.4736
NEL
CFID
0
NMCSSC
CFI
.5000
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
,
0
*
N(CFID) = 9
4
216
0
N(CFNI) =
9
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.5
AFC Reference:
Feature Name:
STRUCTURE FILE - Record Length Variability
Resolution Inequality:
N/A
Resolution Equation:
\j = Q109/Q107
Number of users with usage rates:
Resolution:
GQ Tl
=
^ ]Q
N/A
Delete in favor of features specified in 3.2.2.11
Data:
Compliance
Application
Usage
ADPAC-1
CFI
.3235
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFID
(N/A)
FAA
CFNI
0
FOCC-1
CFID
.0500
FOCC-2
CFID
0
HAM
CFNI
0
NAVC-1
CFID
(N/C)
NAVC-2
CFID
0
NAVC-3
CFID
NCDCF
CFID
.5263
NEL
CFID
0
NMCSSC
CFI
.7500
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFID
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
0
•
N(CFID)=
N(CFI) = 4
217
9
N(CFN!) =
9
RESOLUTION ANALYSIS
AFC Reference:
JAQ Reference:
J 3.5.2.2.2.5
Feature Name:
INPUT/OUTPUT --POS
Resolution Inequality:
N/A
Resolution Equation:
U = Q165
Number of users with usage rates:
Reso'ution:
A 10
GQ Tl = N/A
Modify as specified in 3.2.2.11
Data:
Application
Compliance
Usage
ADPAC-1
CFID
7
ADPAC-2
CFID
0
ADPAC-3
CFID
0
CSC
CFI
(N/A)
FAA
CFNI
1 or more
FOCC-1
CFNI
0
FOCC-2
CFNI
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
NCDCF
CFID
10
NEL
CFNI
0
NMCSSC
CFI
100
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-T
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
0
/
0
*
N(CFID)=
N(CFI) = 2
218
4
N(CFNI) =
16
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.3.3
AFC Reference:
Feature Name:
INPUT/OUTPUT - OPEN Statement with Operand
Resolution Inequality:
N/A
Resolution Equation:
U = Q225
Number of users with usage rates:
Resolution:
A 10
GQ Tl = N/A
Delete in favor of features specified in 3.2.2.11
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
2
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFID
0
NEL
CFNI
0
NMCSSC
CFID
0
RADC-I
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
4
,
N(CFID)=
219
0
2
N(CFNI) =
J6
RESOLUTION ANALYSIS
JAQ Reference:
j 3.5.3.3
Feature Name:
INPUT/OUTPUT - OPEN Statement without Operand
Resolution Inequality:
Resolution Equation:
AFC Reference:
N/A
y = Q226
Number of users with usage rates:
Resolution:
A 10
=
GQ Tl
N/A
Delete in favor of features specified in 3.2.2.11
Data:
Application
Compliance
Usage
ADPAC-1
CF,
18
ADPAC-2
CF|
0
ADPAC-3
Cp|
1
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
NCDCF
CFID
0
NEL
CFNI
0
NMCSSC
CFID
20
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-^
CFNI
0
SAC-^
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-'-
CFNI
0
N(CFI)=
-
0
*
4
0
N(CFID)=
220
2
N(CFNI) =
16
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.3.3
Feature Name:
INPUT/OUTPUT - SHUT Statement with Operand
Resolution Inequality:
AFC Reference:
A 10
N/A
l
Resolution Equation:
U = Q227
Number of users with usage rates:
Resolution:
GQ Tl = N/A
Delete in favor of features specified in 3.2.2.11
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
7
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
NCDCF
CFID
10
NEL
CFNI
0
NMCSSC
CFID
0
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CFI)=
4i
0
*
N(CFID)=
221
0
,
2i
N(CFN!) =
N(CFNI)
16
RESOLUTION ANALYSIS
JAG Reference:
j 3.5.3.3
Fec'ure Name:
INPUT/OUTPUT - SHUT Statement Without Operand
Resolution Inequality:
|\|/A
Resolution Equation:
(J = Q228
Number of users with usage rates:
Resolution:
AFC Reference:
A 10
GQ Tl = N/A
Delete in favor of Features specified in 3.2.2.11
Data:
Application
Usage
Compliance
ADPAC-1
CFI
18
ADPAC-2
CFI
0
ADPAC-3
CFI
2
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFID
0
NEL
CFNI
0
NMCSSC
CFID
20
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
~ADC-3
CFNI
0
RADC-'-
CFNI
0
SAC-i
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-^-
CFNI
0
N(CF!)= A \
N(CFID)
222
0
'
2
N(CFNI)= 16
RESOLUTION ANALYSIS
JAQ Reference:
Feature Name:
j 3.5.3.3
A 10
INPUT/OUTPUT - INPUT Statement
Resolution Inequality:
|s|/A
Resolution Equation:
\j = Q229
Number of users with usage rates:
Resolution:
AFC Reference:
GQ Tl = N/A
Delete in favor of features specified in 3.2.2.11
Data:
Application
Usage
Compliance
ADPAC-1
CFI
18
ADPAC-2
CFI
0
ADPAC-3
CFI '
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FOCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
0
NCDCF
CFID
20
NEL
CFNI
0
NMCSSC
CFID
50
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFI
0
N(CFI) = 4
N(CFID)=
r223
2
N(CFNI)= 16
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.3.3
AFC Reference:
Feature Name:
INPUT/OUTPUT - OUTPUT Statement
Resolution Inequality:
N/A
Resolution Equation:
U = Q230
Number of users with usage rates:
Resolution:
A
10
GQ Tl = N/A
Delete in favor of features specified in 3.2.2.11
Data:
Comoliance
Application
Usage
i
ADPAC-1
CFI
18
ADPAC-2
CFI
0
ADPAC-3
CFI
14
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFNI
0
FCCC-2
CFNI
0
HAM
CFNI
0
NAVC-1
CFNI
(N/C)
NAVC-2
CFNI
0
NAVC-3
CFNI
NCDCF
CFID
20
NEL
CFNI
0
NMCSSC
CFID
50
RADC-1
CFNI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
0
RADC-4
CFNI
0
SAC-1
CFNI
0
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-4
CFNI
0
N(CF!) =
4
"
0
N(CF!D)=
224
2
N(CFNI)=
16
RESOLUTION ANALYSIS
JAG Reference:
J 3.5.1.1.2.2
Feature Name:
ITEM Declaration by Preset Constant
Resolution Inequality:
Resolution Equation:
A 11.1
U GQ Tl = .05
U = Q8/Q14
Number of users with usage rates:
Resolution:
AFC Reference:
GQ Tl = N/A
Retain as optional
Data:
Application
Compliance
ADPAC-1
CFI
ADPAC-2
CFI
Usage
1
0
x
ADPAC-3
CFI
.0476
CSC
CFI
(N/A)
FAA
CFI
.8
FOCC-1
CFI
.0012
FOCC-2
CFI
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
•
0
.1250
•*
NAVC-3
CFI
NCDCF
CFI
.0200
NEL
CFI
.2000
NMCSSC
CFI
.1333
RADC-1
CFI
(N/C)
RADC-2
CFNl
0
RADC-3
CFI
0
RADC-4
CFNI
.2757
SAC-1
CFID
.0362
SAC-2
CFID
.1789
SAC-3
CFID
.0428
SAC-4
CFI
.0367
N(CF!)=
0
N(CF!D) = 3
17
225
N(CFNI) =
2
RESOLUTION ANALYSIS
AFC Reference: A 11.2
JAQ Reference:
J 3.5.4.3
Feature Name:
Multiple Statement Labels
Resolution Inequality:
U GQ T1 = .05
Resolution Equation: U = Q238/Total Number of Statements
Number of users with usage rates:
Resolution:
GQ Tl = N/A
Retain as nucleus
Data:
Compl? a nee
Application
Note: These data indicate
that the multiple statement
labels feature ought to be
deleted. Because of the high
degree of interplay between the
various kinds of Statements in
JOVIAL and the ease of syntactic
specification obtained by
allowing this feature (CED 2448),
we are recommending that this
feature be retained as nucleus.
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
0
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
.0597
FOCC-2
CFI
0
HAM
CFID
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
0
NCDCF
CFI
.0031
NEL
CFI
0
NMCSSC
CFI
0
RADC-1
CFI
(N/C)
RADC-2
CFID
0
RADC-3
CFID
.0010
RADC-4
CFI
0
SAC-1
CFID
0
SAC-2
CFID
.0001
SAC-3
CFID
0
SAC-4
CFID
0
N(CFI) = 14
N(CFID) = 7
226
N(CFNI) = 1
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.6.2
AFC Reference:
Feature Name:
DEFINE Directive
Resolution Inequality:
U GQ Tl = .001
Resolution Equation:
\j = Q236/Total Number of Statements
Number of users with usage rates:
Resolution:
QQ J]
A 12.1
= Q
Retain as optional
Data:
Compliance
Application
Usage
ADPAC-i
CFI
.0035
ADPAC-2
CFI
.0071
ADPAC-3
CFI
" (N/C)
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
.0037
FOCC-2
CFI
0
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
.0148
NCDCF
CFI
.0031
NEL
CFI
.0100
NMCSSC
CFI
.0010
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFI
.0010
RADC-4
CFI
0
SAC-1
CFNI
(
SAC-2
CFNI
0
SAC-3
CFNI
0
SAC-^
CFID
0
N(CFI)=
N(CFID)=
16
227
!
N(CFNI)=
5
RESOLUTION ANALYSIS
A?c
JAQ Reference:
J 3.5.1.1.3
Reference:
Feature Name:
MODE DIRECTIVE - Automatic and Explicit
A 12>2
Resolution Inequality: U GQ Tl = .02
Resolution Equation:
U = Q12/Q14
Number of users with usage rates:
Resolution:
GQ Tl = 5
Retain as optional (Note extension as specified in 3.2.2.8)
Data:
Application
Compliance
Usage
ADPAC-1
CFI
0
ADPAC-2
CFI
.0200
ADPAC-3
CFI
0
CSC
CFI
(N/A)
CFNI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFNI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
1
NCDCF
CFNI
0
NEL
CFI
.4000
NMCSSC
CFI
.0666
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
.0500
RADC-4
CFNI
0
SAC-i
CFID
0
SAC-2
CFID
0
SAC-3
CFID
0
SAC-4
CFID
0
FAA
"
N(CFI)=
12
N(CF1D)=
228
4
N(CFNI) =
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.1.1.3
Feature Name:
MODE DIRECTIVE -Explicit
Resolution Inequality:
UGQT1 = 1
Resolution Equation:
U-Q13
Number of users with usage rates:
Resolution:
AFC Reference: A 12.2
^Q Tl =4
Retain as optional (Note extension as specified in 3.2.2.8)
Data:
Application
Usage
Compliance
ADPAC-1
CFI
0
ADPAC-2
CFI
10
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFNI
0
FOCC-1
CFI
0
FOCC-2
CFI
0
HAM
CFNI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
0
NAVC-3
CFI
200
NCDCF
CFNI
0
NEL
CFI
40
NMCSSC
CFI
5
RADC-1
CFI
(N/C)
RADC-2
CFNI
0
RADC-3
CFNI
1
RADC-4
CFNI
0
CFID
0
CFID
0
CFID
0
CFID
0
SAC-l"
SAC-2
SAC-3
SAC-4
N(CFI) =
12
N(CF1D)
22?
_ 4
_
N(CFN1) =
6
RESOLUTION ANALYSIS
AFC Reference:
JAQ Reference:
J 3.5.1.; 3.2
Feature Name:
LIKE TABLE DECLARATION
Resolution Inequal ity:
UGQT1 = .05
Resolution Equation:
U = Q82/Q78
GQ Tl =9
Number of users with usage rates:
Resolution:
12.4
Retain as optional
Data:
Usage
Comoliance
Application
ADPAC-1
CFI
.0789
ADPAC-2
CFI
.0625
ADPAC-3
CFI
0
CSC
CFI
(N/A)
FAA
CFI
.2
FOCC-]
CFI
.0130
FOCC-2
CFI
.1000
HAM
CFI
0
NAVC-1
CFI
(N/C)
NAVC-2
CFI
.0666
NAVC-3
CFI
0
NCDCF
CFNI
0
CFI
.2333
CFI
.1333
CFI
(N/C)
CFI
.2
CFI
0
CFI
0
CFI
.0476
CFI
.0346
CFI
.0078
CFI
.1088
NSL
NMCSSC
RADC-1
RADC-2
RADC-3
RADC-4
SAC-i
SAC-2
SAC-3
SAC-A
N(CFI) =
21
N(CF!D) =
230
0
N(CFN1) = 1
RESOLUTION ANALYSIS
JAQ Reference:
J 3.5.5.5.5
Feature Name:
ALL
Resolution Inequality:
U GQ T = .05
Resolution Equation:
U = Q306/Q78
Number of users with usage rates:
Resolution:
AFC Reference:
A 12.5
GQ Tl = 12
Retain as nucleus
Data:
Application
Compile nee
Usage
ADPAC-1
CFID
.3421
ADPAC-2
CFID
.0625
ADPAC-3
CFID
0
CSC
CFI
(N/A)
CFID
.8
FOCC-1 '
CFI
-W34
FOCC-2
CFI
0
HAM
CFI
°
NAVC-1
CFI
CFI
(N/C)
.06666
CFI
0
CFI
.1000
CFID
.1000
CFI
.2000
CFI
(N/C).
CFI
.2
CFI
0
CFI
0
CFID
.1726
CFID
.1230
CFID
.4038
CFID
.4455
FAA
•
NAVC-2
NAVC-3
NCDCF
NEL
NMCSSC
RADC-1
RADC-2
RADC-3
RADC-4
SAC-1
SAC-2
SAC-3
SAC-4
N(CF1)=
13
N(CF1D)=
231
9
N(CFNI) -
0
RESOLUTION ANALYSIS
JAQ Referc •nee:
J 3.5.6. 1
Feature Nc me:
COMPOOL
Resolution necuality:
N/A
Resolution Equation:
N/A
AFC Reference:
A 12.6
GQ Tl = N/A
Number of users with usage rates:
Resolution:
<
Retain as nucleus
Dota:
C omoliance
Application
ADPAC-1
CFI
ADPAC-2
CFI
ADPAC-3
CFI
CSC
CFI
FAA
CFI
FOCC-1
CFI
FOCC-2
CFI
HAM
CFI
NAVC-1
CFI
NAVC-2
CFI
NAVC-3
CFI
NCDCF
CFI
NEL
CFI
NMCSSC
CFID
RADC-1
CFI
RADC-2
CFNI
RADC-3
CFI
RADC-4
CFNI
SAC-!
CFI
SAC-2
CFI
SAC-3
CFI
SAC-4
CFI
N(CF!)=
19
N(CF!D) =
232
Usage
1
N(CFNI) =
2
J 3.5.7
OTHER FEATURES
Following is the collection of response to the other feature section of the JAQ that
included potential JOVIAL language additions not specifically mentioned in the
previous sections of the JAQ:
CSC
(1)
Hexadecimal constant feature provided
(as well as octal)
(2)
Double precision floating point constants
and variables
(3)
An ability to declare a PROC as a closed
routine using START PROC
. . is provided
to augment the standards
FAA
"EXIT" - Return to monitor instruction
FOCC-1
(1)
A formatting and editing capability is
included (FORMAT1, ENCODE', DECODE')
(2)
"LOAD"' is used to bring a program in
loader format into core
(3)
"MESSAGE"' enables a character string to
be output to the system console
(4)
"FAULT1 and NOFAULT"' are used to enable
and disable fault interrupts
233
APPENDIX III
INTERVIEW QUESTIONS
This Appendix contains the questions asked of participants at interview. The
symbols "Y", "N", "NSF", "CT", denote "Yes", "No", "No Strong Feeling",
and "Can't Tell" . "No Strong Feeling" was used by respondents when they
felt that the oroposed addition, extension, or modification would be only
marginally heloful . "Can't Tell" was used when resDondents felt they required
more SDecific information regarding implementation of a oroposed feature in order
to decide whether or not it would be worthwhile. The number in the parenthesis
is the related "Aoproach for Change" reference number.
The interview responses to these questions are included in sequential order in
Appendix 4, along with their recommended disposition or resolution.
1)
Expanded Character Sets (Al . 1 . 1)
Equipments which oermit the use of expanded character sets are currently
available. Using these equipments it is possible in writing JOVIAL Drograms
to use, for examole, the symbol " ", "<" " Comparisons?
Number of Users with Response Y:
10
Number of Users with Response N:
1
Number of Users with Response NSF:
1
Number of Users with Response CT:
0
Data:
Application
Resolution:
Resp onse
ADPAC
NSF
FAA
Y
FOCC
Y
HAM
N
NAVC
Y
NCDCF
Y
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
Y
SAC
Y
TWA
Y
Adopt literal comparison feature (3.2.2.4.2) (nucleus)
256
NTERVIEW ANALYSIS
Interview Question:
1-4
AFC Reference: A 1 .1
_
Question Content:
(1) Deal With Data Which are Simply BIT Strings?
^ ^^ Q{J ;$ ^^ |$ Referenced ^^ Ju$f B|T
Number of Users with Response Y:
(1)
8
(2)
9
Number of Users with Response N:
(1)
4
(2)
3
Number of Users with Response NSF:
(1)
0
(2)
0
Number of Users with Response CT:
(1)
0
(2)
0
Sfring?
Data:
Application
Response
(1) Y
(2) Y
FAA
Y
Y
FOCC
N
N
HAM
N
Y
NAVC
Y
Y
NCDCF
N
N
NEL
Y
Y
NHCP
Y
Y
NMCSSC
Y
Y
RADC
N
N
SAC
Y
Y
TWA
Y
Y
ADPAC
Note:
The purpose of Questions 1-4 (1), (2) was to ascertain whether or not
a formal item type "bit string" ought to be incorporated into JOVIAL.
Operations on bit strings might include assignment, concateration,
ana,
or,
not, etc.
Resolution:
No recommendation at this time.
257
INTERVIEW ANALYSIS
Interview Question:
1-5
AFC Reference: A 1 .2
Question Content:
In Favor of GROUP Data Structure?
Number of Users with Response Y:
7
Number of Users with Response N:
4
Number of Users with Response NSF:
1
Number of Users with Response CT:
0
Data:
Application
Resolution:
Response
ADPAC
NSF
FAA
Y
FOCC
Y
HAM
N
NAVC
N
NCDCF
N
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
Y
SAC
N
TWA
Y
No recommendation at this time.
258
NTERVIEW ANALYSIS
Interview Question:
1-6
Question Content:
In Favor of SET Data Structure?
AFC Reference: A 1 .2
Number of Users with Response Y:
8
Number of Users with Response N:
2
Number of Users with Response NSF:
2
Number of Users with Response CT:
0
Data:
Application
Resolution:
Response
ADPAC
NSF
FAA
Y
FOCC
NSF
HAM
N
NAVC
N
NCDCF
Y
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
Y
SAC
Y
TWA
Y
No recommendation at this time,
259
INTERVIEW ANALYSIS
Interview Question:
1-7
AFC Reference: A 1
Question Content:
In Favor of Dynamic Allocation Facilities?
Number of Users with Response Y:
4
Number of Users with Response N:
6
Number of Users with Response NSF:
0
Number of Users with Response CT:
2
Data:
Application
Resolution:
Resp onse
ADPAC
N
FAA
CT
FOCC
N
HAM
N
NAVC
N
NCDCF
Y
NEL
CT
NHCP
N
NMCSSC
Y
RADC
N
SAC
Y
TWA
Y
No recommendation at this time.
260
INTERVIEW ANALYSIS
Interview Question:
1-8
AFC Reference: A 3
Question Content:
Explicit Storage Allocation Facilities Important?
Number of Users with Response Y:
12
Number of Users with Response N:
0
Number of Users with Response NSF:
0
Number of Users with Response CT:
0
Data:
Application
Response
ADPAC
Y
FAA
Y
FOCC
Y
HAM
Y
NAVC
Y
NCDCF
Y
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
Y
SAC
Y
TWA
Y
Note:
This question was not intended to determine the need for any specific feature
or features, but rather to measure, in general terms, command and control
programming requirements. Users felt strongly that these explicit storage
allocation facilities are among the most powerful of the JOVIAL capabilities.
Resolution:
N/A
261
NTERVIEW ANALYSIS
Interview Question:
1-9
AFC Reference: A 3
Question Content:
Transfer Already, Or In Future, Programs Between Different
Computer Systems?
Number of Users with Response to Y:
10
Number of Users with Response to N:
2
Number of Users with Response to NSF:
0
Number of Users with Response to CT:
0
Data:
Application
Response
ADPAC
Y
FAA
Y
FOCC
Y
HAM
N
NAVC
Y
NCDCF
Y
NEL
Y
NHCP
N
NMCSSC
Y
RADC
Y
SAC
Y
TWA
Y
Note:
This question, like 1-9, was not intended to determine the need for any specific
feature or features, but rather to ascertain user requirements. The fact that the
great majority of users responded with "yes" implies that the command and
control language should be very machine independent. This conflicts with the
highly machine dependent explicit storage allocation facilities deemed so
important by users. It is important to note that most users commented that they
were willing to sacrifice machine independence for allocation facilities.
Resolution:
N/A
262
INTERVIEW ANALYSIS
Interview Question:
1-10
Question Content:
Is "Memory Model" Sufficient?
AFC Reference: A 3
Number of Users with Response Y:
12
Number of Users with Response N:
0
Number of Users with Response NSF:
0
Number of Users with Response CT:
0
Data:
Application
Resolution:
Response
ADPAC
Y
FAA
Y
FOCC
Y
HAM
Y
NAVC
Y
NCDCF
Y
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
N
SAC
Y
TWA
Y
Retain the memory model — words, bits, bytes — as is.
263
INTERVIEW ANALYSIS
Interview Question:
1-11
AFC Reference: A 3.2
^
_
A.
Question Content:
In Favor of Dropping Absolute Adherence to Signed Magnitude
_
Z
t.
Representation?
Number of Users with Response Y:
9
Number of Users with Response N:
1
Number of Users with Response NSF:
2
Number of Users with Response CT:
0
Data:
Application
Resolution:
Response
ADPAC
Y
FAA
Y
FOCC
Y
HAM
N
NAVC
Y
NCDCF
Y
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
Y
SAC
NSF
TWA
NSF
Adopt "relaxed" signed magnitude interpretation (3.2.2.5).
264
NTERVIEW ANALYSIS
Interview Question:
1-12
Question Content:
In Favor of Hexadecimal Constants?
AFC Reference: A 3.1
Number of Users with Response Y:
5
Number of Users with Response N:
7
Number of Users with Response NSF:
N/A
Number of Users with Response CT:
N/A
Data:
Application
Response
ADPAC
N
FAA
Y
FOCC
Y
HAM
N
NAVC
N
NCDCF
N
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
N
SAC
Y
TWA
N
Note:
It is recommended that compilers must implement either the octal constant
or the hexadecimal constant, but that they may implement both.
Resolution:
Adopt a hexadecimal constant capability (3.2.2.1) (optional)
265
INTERVIEW ANALYSIS
Interview Question:
1-13
AFC Reference: A 3
Question Content:
In Favor of Generalized Packing?
Number of Users with Response Y:
9
Number of Users with Response N:
3
Number of Users with Response NSF:
0
Number of Users with Response CT:
0
Data:
Application
Resolution:
Response
ADPAC
Y
FAA
Y
FOCC
Y
HAM
N
NAVC
N
NCDCF
N
NEL
Y
NHCP
Y
NMCSSC
Y
RADC
Y
SAC
Y
TWA
Y
No recommendation at this time.
266
INTERVIEW ANALYSIS
Interview Question:
1-14
Question Content:
Use of OVERLAY
AFC Reference: A 3.6
Number of Users with Response Y:
"(l)/(2) more"
Number of Users with Response N:
"(3)/(4) more"
Number of Users with Response NSF:
"Both the Same1
Number of Users with Response CT:
1
Data:
Application
Response
ADPAC
(3)/(4) more
FA A
Both the same
FOCC
Both the same
HAM
CT
NAVC
(1 )/(2) more
NCDCF
(3)/(4) more
NEL
(3)/(4) more
NHCP
Both the same
NMCSSC
Both the same
RADC
(3)/(4) more
SAC
(1 )/(2) more
TWA
Both the same
Note:
(See next page)
Resolution:
No recommendation at this time.
267
Note:
The purpose of this question was to determine whether OVERLAY
is used more for directing allocation — its immediately apparent
function — or for applying multiple interpretations to data and
data structures. DDI contended in the AFC that it would be
preferable to provide distinct features for the two fundamental functions
performed by OVERLAY because this would provide greater ease in
training novice programmers and because the ambiguity of the intent
of an OVERLAY (is the programmer directing allocation or is he
assigning more than one set of attributes to a given datum or data
structure?) would be avoided. The responses indicate that nine
of the 12 applications use OVERLAY at least as much for performing the "multiple interpretations" function as for the allocation
direction function. Based upon these responses, we should recommend
distinct features to replace OVERLAY; however, owing to the fact
that we are proposing no action be taken as yet in implementing new
data structures, we feel that it would be counter-productive to
propose features to replace OVERLAY at this time.
268
INTERVIEW ANALYSIS
Interview Question:
1-15
AFC Reference: A 3.7/A 3.8
_
.
_
Question Content:
(1) In Favor of Obtaining Absolute Address Specifications?
,ox . _
. . .
,r\r-n
(2)
In Favor of DRetaining y'LOC?
Number of Users with Response Y:
(1)
8
(2)
9
Number of Users with Response N:
(1)
4
(2)
3
Number of Users with Response NSF:
(1)
0
(2)
0
Number of Users with Response CT:
(1)
0
(2)
0
Data:
Application
0)
1
Y (2)
Y
FAA
Y
Y
FOCC
Y
Y
HAM
N
N
NAVC
Y
N
NCDCF
N
N
NEL
N
Y
NHCP
Y
Y
NMCSSC
N
Y
RADC
Y
Y
SAC
Y
Y
TWA
Y
Y
ADPAC
Resolution:
Re
Source Exif Data:
File Type : PDF
File Type Extension : pdf
MIME Type : application/pdf
PDF Version : 1.4
Linearized : Yes
Page Count : 296
Page Mode : UseNone
XMP Toolkit : XMP Core 4.1.1
Metadata Date : 2010:09:29 14:41:53-04:00
Creator Tool : LuraDocument PDF Compressor Server 5.5.50.41
Create Date : 2010:09:29 14:41:53-05:00
Modify Date : 2010:09:29 14:41:53-05:00
Producer : LuraDocument PDF v2.41
Part : 1
Conformance : B
Document ID : uuid:uuid:7b5f3585-8bf3-6a3c-bbd1-6c362753950c
Version ID : 1
Creator : LuraDocument PDF Compressor Server 5.5.50.41
EXIF Metadata provided by EXIF.tools