|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 106880 (0x1a180)
Types: TextFile
Names: »D171«
└─⟦4b76feb82⟧ Bits:30008865 Diskette med tekster der formodes at være 31-D-163…174
└─⟦this⟧ »D171«
\f
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. INTRODUCTION .......................................... 1
2. THE PREPARATION OF A GENIUS PROGRAM ................... 2
3. INPUT TO A GENIUS PROGRAM ............................. 3
3.1 Records from a Textfile .......................... 3
3.2 Records from a Database .......................... 6
4. THE STRUCTURE OF A GENIUS DESCRIPTION ................. 9
4.1 The First Part of the GENIUS Description ......... 10
4.1.1 Input Without a Database Description ...... 10
4.1.2 Input With a Database Description ......... 15
4.2 The Second Part of the GENIUS Description ........ 16
4.2.1 Printidentifier ........................... 17
4.2.2 Trigger ................................... 17
4.2.3 Event Reference ........................... 17
4.2.4 Format .................................... 18
4.2.5 Value Specification ....................... 19
4.3 The Third Part of the GENIUS Description ......... 20
4.3.1 Identifier ................................ 20
4.3.2 Trigger ................................... 20
4.3.3 Definition Symbol ......................... 20
4.3.4 Definition Body ........................... 21
5. THE GENIUS COMPILER FIKS .............................. 22
5.1 Genius Description File Name ..................... 23
5.2 Database Description File Name ................... 23
5.3 Initials ......................................... 23
5.4 Genius File Name ................................. 23
5.5 Genius Ident ..................................... 23
5.6 Genius Number .................................... 23
\f
ii
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
6. THE GENIUS PROCESSOR SMART ............................ 24
6.1 Genius File Name ................................. 24
6.2 Genius Ident ..................................... 24
6.3 Genius Version ................................... 25
6.4 Record File Name ................................. 25
6.5 Print File Number ................................ 25
6.6 Result File Name ................................. 25
6.7 User Number ...................................... 25
6.8 Genius Number .................................... 25
7. EXAMPLES .............................................. 27
7.1 Municipal Trim ................................... 27
7.1.1 Problem: Labels ........................... 27
7.1.2 Problem: Firmlist.......................... 41
7.2 Customer Balance Survey .......................... 48
7.2.1 Input From a Textfile ..................... 48
7.2.2 Input From a Database ..................... 69
A_P_P_E_N_D_I_C_E_S_:
A. REFERENCES ............................................ 77
B. NOTATION .............................................. 78
C. ISO-CHARACTERS ........................................ 79
D. ALPHABETICAL INDEX .................................... 80
\f
E_X_P_L_A_N_A_T_I_O_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_N_P_U_T_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _F_I_E_L_D_N_A_M_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _F_I_E_L_D_T_Y_P_E_
number of records 4
geniuser (u=11, g=5) W45061 geniuser word
long field: value = 0 (dummy) L0 debtornumber long
word field: value = 1 (type) W1 type word
W11 usernumber word
14 words text field T14 UK-BICYCLE-IMPORT username text.41
W30 time of respite word
W45061 geniuser word
L101 debtornumber long
W2 type word
2. record T6 TOP-SERVICECENTRE firmname text.17
L99999999999999 creditmax (in pence) long
W1 creditwordthy (if 1 yes else no) word
L527348 customerbalance (in pence) long
W45061 geniuser word
L101 debtornumber long
W3 type word
L299085 amount (in pence) long
3. record W791225 entrydate (yymmdd) word
W12 invoicenumber word
W25698 posttype (ISO-value for db(debit)) word
W800630 duedate (yymmdd) word
W45061
L101
W3
L202166
4. record W800127 as record 3
W14
W25458
W800731
Figure 3: Example showing 4 records from a textfile.
\f
E_x_p_l_a_n_a_t_i_o_n_:
number of records
geniuser (u=27, g=1)
tradecode (sortword, dummy)
type
municipal
geniuser (u=27, g=1)
tradecode (sortword)
type
firmnumber
staff
turnover (pound/year)
firmname
housenumber
street
postal district
postal code(1)
postal code(2) \f
F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
This is an introduction to the general event-oriented output
system, GENIUS. The reason for writing this introduction is, that
users not familiar with the system have some problems using it
only with the manual 1 as a tool.
Anyway it has appeared that this report generating system does
have a very broad flexibility, while there is no predefined
formatting; and we hope, that this introduction will make it easy
for you to use.
Furthermore the language is not algoritmic, and therefore it is
very easy to use, also for users not familiar with the ordinary
programming languages.
The first chapters, 2-6, contain a short entry to GENIUS; while
the last chapter, 7, deals with a number of examples illustrating
the pratical use.
In appendix A you will find a reference list. Appendix B shows
the notation used in this introduction. The ISO-characters are
listed in appendix C. Finally you will find an alphabetical index
in appendix D.
A graphic survey of the GENIUS system is shown in fig. 1.
DB TRANS-
DESCR. ACTION
FILE FILE
GENIUS
DESCRIP- FIKS GENIUS SMART RESULTS
TION FILE
LISTING LOG LOG
Figure 1: Survey of the GENIUS system.
\f
F_ 2_._ _ _ _ _ _ _ _ _T_H_E_ _P_R_E_P_A_R_A_T_I_O_N_ _O_F_ _A_ _G_E_N_I_U_S_ _P_R_O_G_R_A_M_ 2.
The first thing you have to do, after having made the decision to
use the GENIUS system, is to find yourself a problem to solve. If
it is the first time you are going to use GENIUS, then make it
simple.
When the problem has been chosen, the next step is to create a
layout for the report.
The final step of the preliminary phase is to collect, select and
sort the testdata for the report.
Now the problem is determinated, and the actual GENIUS treatment
can begin.
\f
F_ 3_._ _ _ _ _ _ _ _ _I_N_P_U_T_ _T_O_ _A_ _G_E_N_I_U_S_ _P_R_O_G_R_A_M_ 3.
It is possible to present your data to GENIUS in two ways, either
from an ordinary textfile or from a sequential file in a data-
base. It is advisable to use a textfile with a small amount of
testdata for the debugging of the GENIUS program, and then after
the program is in operation change to your database (if you have
one). This is done rather easily.
B A
DB TRANS-
DESCR. ACTION
FILE FILE
GENIUS
DESCRIP- FIKS GENIUS SMART RESULTS
TION FILE
LISTING LOG LOG
Figure 2: The GENIUS system.
3_._1_ _ _ _ _ _ _ _R_e_c_o_r_d_s_ _f_r_o_m_ _a_ _T_e_x_t_ _F_i_l_e_ 3.1
The transaction file (frame A in figure 2) contains a number of
sorted records. The first element in the first record must
specify the number of records in the transaction file. The
following elements in all the records have to start with a type
indication. There are three kinds allowed in the transaction:
w : word. Positive or negative integer.
l : long. Positive or negative integer
(if large numbers needed).
t followed by an integer: text. The integer denotes the length in
words (i.e. (c//3+1), where c: number
of characters) of the text field.
\f
A text can contain letters, digits and minus (-). Blanks are not
allowed. Empty texts are also forbidden.
Values must be specified for dummy fields too.
Dates are represented as words in the format yymmdd.
Arrays are represented as a successive number of elements of the
appropriate type.
The first element in every record (except in the first record,
where it is the second) has to be the so-called geniuser. The
type of the geniuser is word and the value is calculated as:
u * 4096 + g
where u: usernumber
g: geniusnumber.
The next elements in every record have to be the sortwords (i.e.
words which are picked out to direct the printout, e.g. the
debtornumber, if you want all data concerning one debtor to be
printed apart). One of the sortwords has to be the standardword,
TYPE. Normally the records in a transaction file can be divided
into various groups of different type (e.g. records containing
information about the user, the debtors or the invoices). The
value of type is an integer from 1 to the number of different
types in the transaction file.
Finally the rest of the variables are listed after importance in
contents.
It is requisite to see to that the order in the GENIUS descrip-
tion is in accordance with the order given in the transaction
file.
An example is shown in fig. 3.
\f
F_\f
F_ 3_._2_ _ _ _ _ _ _ _R_e_c_o_r_d_s_ _f_r_o_m_ _a_ _D_a_t_a_b_a_s_e_ 3.2
If the data to the GENIUS program are to be found in a database,
the procedure most common will be the following (while the
database is described by means of DATABASE80 4):
1. Extraction of selected records into a sequantial file.
2. Sorting of the formed transaction file by SORT80 2.
3. Treatment of the sorted file by GENIUS.
All the mentioned programs use the description register (frame B
in fig. 2) formed by DATABASE80. While the system is in the
debugging phase, it is possible to use PRINT80 3 for the
printout of the database contents, the unsorted and sorted
transaction file. An example showing a printout of a transaction
file by PRINT80 is given in fig. 4.
In fig. 5 the input to DATABASE80 is given for a simple database
description.
Finally GENIUS is also able to treat sorted transactions from a
sequential file, which is not described by DATABASE80.
\f
F_
Figure 4: Example showing 4 records from a database. \f
F_
Figure 5: Example showing a database description.
\f
F_ 4_._ _ _ _ _ _ _ _ _T_H_E_ _S_T_R_U_C_T_U_R_E_ _O_F_ _A_ _G_E_N_I_U_S_ _D_E_S_C_R_I_P_T_I_O_N_ 4.
After the preparation of the data to the report is finished, the
creation of the GENIUS description (the frame in fig. 6) can
start.
DB TRANS-
DESCR. ACTION
FILE FILE
GENIUS
DESCRIP- FIKS GENIUS SMART RESULTS
TION FILE
LISTING LOG LOG
Figure 6: The GENIUS system.
The following tree rules are general for the whole GENIUS
description:
1) Comment : Every line of the description may be terminated
by a comment enclosed in the short-comment
brackets <* *'.
2) Statements : All statements of the description must start on a
new line and must be terminated by a semicolon
character. In general, statements may occupy more
than one line. Any number of empty lines, or
lines with just a comment, may appear between
statements.
3) Letters : Only small letters are allowed.
The GENIUS description can be divided into three parts.
\f
In the first part there are some differences whether one has a
database description or not. These will be pointed out and
treated separately.
The rest of the GENIUS description is common for both ways of
presenting the input and will be treated in all.
4_._1_ _ _ _ _ _ _ _T_h_e_ _F_i_r_s_t_ _P_a_r_t_ _o_f_ _t_h_e_ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 4.1
In the first part of the GENIUS description the data to the pro-
gram are declared and described. As mentioned in chapter 3, there
are two ways of presenting the input to the program. The first is
to design a textfile with all the relevant data to the report.
The second and most common way is to select the actual data from
a database.
It is important to notice that GENIUS is an outputprogram and be-
cause of that does not have sorting facilities in the common
sense (e.g. alphabetic or numeric sorting); for this purpose
there is a special sortingprogram, SORT80 2. The sorted records
to GENIUS can be divided into different types and then treated in
separate ways.
4_._1_._1_ _ _ _ _ _I_n_p_u_t_ _W_i_t_h_o_u_t_ _a_ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_ 4.1.1
The structure of the first part of the description while using no
database description is shown in fig. 7. The notation is explai-
ned in appendix B. The variables used in the figure are explained
in the following subsections.
\f
F_
GENIUS geniusnumber :USER = usernumber;
F_I_E_L_D_S_:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
F1: fieldname _1: variabletype _1
F2: fieldname _2: variabletype _2
.
.
.
F_n_:_ _f_i_e_l_d_n_a_m_e_ _n_:_ _v_a_r_i_a_b_l_e_t_y_p_e_ _n_ _ _;_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTRANS: BASE = basenumber
SORTWORDS = _s_o_r_t_n_u_m_b_e_r_,_ _S_O_R_T_F_I_E_L_D_S_ _=_ _(_s_o_r_tname _1, sortname _2, ..., sortname m, TYPE)
TYPE 1 : field _reference _list _1
TYPE 2 : field _reference _list _2
.
.
TYPE l _:_ _f_i_e_l_d_ _r_e_f_e_r_e_n_c_e_ _l_i_s_t_ _l_ _ _ _ _ _ ;
RESULT result _name : PRINTFILE = printfilenumber;
where:
n: the number of fields.
m: the number of sortfields excl. TYPE.
l: the number of types.
Figure 7: The first part of the GENIUS description using no
database description.
\f
F_ 4_._1_._1_._1_ _ _ _G_e_n_i_u_s_ _n_u_m_b_e_r_ 4.1.1.1
The genius number is an arbitrary chosen number for the actual
GENIUS description.
4_._1_._1_._2_ _ _ _U_s_e_r_ _n_u_m_b_e_r_ 4.1.1.2
The user number(s) points out the user(s) for whom the descrip-
tion is intended. In case of more than one user the numbers
should be separated by commas. If the user identifications are
omitted, all users are allowed.
4_._1_._1_._3_ _ _ _F_i_e_l_d_ _n_a_m_e_ 4.1.1.3
The field name is the name of the particularly field in the
record of the transaction.
4_._1_._1_._4_ _ _ _V_a_r_i_a_b_l_e_ _t_y_p_e_ 4.1.1.4
The variable type is the type of the field. Following types are
allowed:
word : an integer -8 388 607, 8 388 607.
long : an integer of double length -140 737 488 355 327,
140 737 488 355 327.
text.c: a text with max c characters.
date : a date with the format yymmdd.
array : one of the above-mentioned types followed by an integer,
enclosed in parenthesis, denoting the upper bound (the
lower is always 1).
group : see the manual 1.
\f
4_._1_._1_._5_ _ _ _B_a_s_e_ _n_u_m_b_e_r_ 4.1.1.5
The base number is the number of words, which the administrative
fields before the geniuser field occupy (standard 2 words in
which case BASE = base number may be left out).
4_._1_._1_._6_ _ _ _S_o_r_t_ _n_u_m_b_e_r_ 4.1.1.6
The sort number is the number of sortwords, incl. TYPE, counted
in words
(word = 1 word
long = 2 words
text.c = (c//3+1)words).
4_._1_._1_._7_ _ _ _S_o_r_t_ _n_a_m_e_ 4.1.1.7
The sort name is the name of the field, which is used as a
criterion field for sorting.
4_._1_._1_._8_ _ _ _F_i_e_l_d_ _R_e_f_e_r_e_n_c_e_ _L_i_s_t_ 4.1.1.8
The field reference list for each type contains the field numbers
of the fields in the record of the appropriate type excl. the
sortfields. The fieldnumbers are seperated by commas.
Every field number except the field numbers of the sortwords
must be represented once and only once in field reference lists
all together. If one or more of the declared fields are not used,
then they can be referred to as dummy fields but instead of
writing the fieldnumber then write the X followed by the number
of dummy words.
\f
4_._1_._1_._9_ _ _ _R_e_s_u_l_t_ _N_a_m_e_ 4.1.1.9
The result name is an arbitrary chosen name of the result state-
ment.
4_._1_._1_._1_0_ _ _P_r_i_n_t_f_i_l_e_ _N_u_m_b_e_r_ 4.1.1.10
The printfile number is an integer between 1 and 999, which indi-
cates where the result is going to be stored.
\f
F_ 4_._1_._2_ _ _ _ _ _I_n_p_u_t_ _W_i_t_h_ _a_ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_ 4.1.2
The structure of the first part of the description, while using a
database description, is shown in fig. 8. The notation is explai-
ned in appendix B.
GENIUS geniusnumber :USER = usernumber;
F_I_E_L_D_S_:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
F1: fieldname _1 : variabletype _1
F2: fieldname _2 : variabletype _2
.
.
F_m_:_ _f_i_e_l_d_n_a_m_e_ _m_ _:_ _v_a_r_i_a_b_l_e_t_y_p_e_ _m_ _ _;_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
INTRANS : BASE = basenumber
SORTWORDS_ _=_ _s_o_r_t_n_u_m_b_e_r_,_ _S_O_R_T_F_I_E_L_D_S_ _=_ _(_s_o_r_t_n_a_m_e_ _1_,_ _s_o_r_t_name 2. ..., sortname m, TYPE)
M_m_m_ record _type _number _1
TYPE 1 = RECORD
P_p_p_ record _type _name _1
M_m_m_ record _type _number _2
TYPE 2 = RECORD
P_p_p_ record _type _name _2
.
.
M_m_m_ record _type _number _l
TYPE l = RECORD
P_p_p_ _ _ _ _ _ _ _ _ _ _ _r_e_c_o_r_d_ _t_y_p_e_ _n_a_m_e_ _l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ;
RESULT result _name : PRINTFILE = printfile _number;
where:
m: the number of sortfields excl. TYPE.
l: the number of types.
Figure 8: The first part of the GENIUS description using a
database description.
\f
F_ 4_._1_._2_._1_ _ _ _R_e_c_o_r_d_ _t_y_p_e_ _n_u_m_b_e_r_ 4.1.2.1
The record type number is the number of the corresponding record
type in the database description.
4_._1_._2_._2_ _ _ _R_e_c_o_r_d_ _t_y_p_e_ _n_a_m_e_ 4.1.2.2
The record type name is used if you want the record to be
identified by a name instead of a number.
4_._2_ _ _ _ _ _ _ _T_h_e_ _S_e_c_o_n_d_ _P_a_r_t_ _o_f_ _t_h_e_ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 4.2
This section deals with the statements for the printout. Once you
have made the layout specification for your problem, it is very
easy to construct this part; but remember that texts are always
left adjusted while numbers are always right adjusted.
Now make yourself clear when (the trigger), where (the format)
and what (the value specification) you will print out.
The structure is shown in fig. 9.
printidentifier _i trigger _j .= PRINT(
<format _1': valuespecification _1
<format _2': valuespecification _2
.
.
<format _k': valuespecification _l);
where:
i : the i>th printstatement.
j : the j>th trigger.
k : the number of formats in the i>th printstatement.
l : the number of valuespecifications in the i>th printstatement.
Figure 9: The second part of the GENIUS description.
\f
4_._2_._1_ _ _ _ _ _P_r_i_n_t_ _i_d_e_n_t_i_f_i_e_r_ 4.2.1
The print indentifier is the name of the print statement. It can
either be followed by a trigger or be referred to elsewhere in
the description.
4_._2_._2_ _ _ _ _ _T_r_i_g_g_e_r_ 4.2.2
The trigger activates the statement to be executed. It is defined
as the reserved word ON followed by an event reference.
4_._2_._3_ _ _ _ _ _E_v_e_n_t_ _r_e_f_e_r_e_n_c_e_ 4.2.3
The event reference can either be a reference to a basic event or
an identifier, defined elsewhere in the description by means of
an event definition symbol *= .
A basic event can either be a standard event or a criterion
event.
The following standard events exist:
TYPE typenumber
TRANS
NEW/END GENIUSER
NEW/END LINE
NEW/END PAGE
The criterion event is the word NEW or END followed by a sort
field (the sort field is defined in the first part of the
description).
Finally an event can be defined in a statement using the defini-
tion symbol *= .
\f
4_._2_._4_ _ _ _ _ _F_o_r_m_a_t_ 4.2.4
In fig. 10 the possible format elements (except horizontal
operation) are shown.
*
p (identifier) t integer
(identifier)
M_m_m_ integer
c
P_p_p_ (identifier)
w integer
M_m_m_ integer
d
P_p_p_ (identifier)
M_m_m_ integer (identifier)
l * n z
(identifier) - * b princ .dec-
P_p_p_ g
vertical operation position transformation parameter
transformation
operator
Figure 10: Survey of the possible format elements (except
horizontal operation).
The integer/identifier before l indicates the number of new lines. If l
is given alone, there will be one new line.
l: lineshift
p: pageshift
w: vertical tabulation
\f
The integer/identifier/asterisk before the transformation opera-
tor indicates the start position. If an asterisk is used the
printing procedure starts immediately after the previously written
character.
t: text
c: character
d: date
n: number
t is followed by an integer/identifier/asterisk, which indicates
the number of characters in the text. If an asterisk is used the
number of characters is equal to the length of the text. NOTE: It
is not possible to use an asterisk both as a startposition and as
a transformation parameter.
c is followed by an integer/identifier defining the number of
times the character should be repeated.
d is followed by an integer/identifier with the value 1-4.
1: dd.mm.yy
2: yy.mm.dd
3: dd. danish month name 19yy
4: 19yy english month name dd.
n is followed by a number _layout/indentifier telling how the
number will be generated.
Minus - can be placed either as a prefix or a postfix sign.
z, *, g, and b are explained in the manual 1.
princ is the number of principals.
dec is the number of decimals.
\f
Finally the horizontal operation h will be mentioned. The iden-
tifier/integer before or after the h defines the basic position
of the format, and will automatically be added to all start
positions in the format.
4_._2_._5_ _ _ _ _ _V_a_l_u_e_ _S_p_e_c_i_f_i_c_a_t_i_o_n_ 4.2.5
The value specification is the value/contents of what should be
printed. It can be identifiers, texts, expressions, etc. NOTE:
The value for the character, c, is the ISO-value (see appendix
C).
4_._3_ _ _ _ _ _ _ _T_h_e_ _T_h_i_r_d_ _P_a_r_t_ _o_f_ _t_h_e_ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 4.3
In the third and last part of the GENIUS description, which deals
with the operational declarative statement, it is not possible,
like in the two first parts, to show a general overall structure.
The reason for this is, that the structure depends on the actual
problems to be solved.
Anyway it is possible to show the structure of the individual
statements of this part (fig. 11).
identifier trigger definition _symbol definition _body;
Figure 11: General structure of the individual statements of part
three.
\f
4_._3_._1_ _ _ _ _ _I_d_e_n_t_i_f_i_e_r_ 4.3.1
The identifier is the name of the variable, which is declared by
this statement. It starts with a letter followed by any number of
letters, digits and underlines.
4_._3_._2_ _ _ _ _ _T_r_i_g_g_e_r_ 4.3.2
See subsection 4.2.2.
4_._3_._3_ _ _ _ _ _D_e_f_i_n_i_t_i_o_n_ _S_y_m_b_o_l_ 4.3.3
The definition symbol defines the k_i_n_d_ of the identifier. There
are four possibilities:
= : numeric quantity
,= : text
*= : event
.= : result element (print statement).
4_._3_._4_ _ _ _ _ _D_e_f_i_n_i_t_i_o_n_ _B_o_d_y_ 4.3.4
The definition body is the v_a_l_u_e_/_c_o_n_t_e_n_t_s_ of the identifier.
A going through of all the facilities in this part would be much
to far-reaching for the purpose of this introduction; so instead
of a theoretical going through, the facilities will be explained
in the following examples (chapter 7) as they appear.
If you need some additional facilities in solving your own prob-
lem, then look in the manual 1.
\f
F_ 5_._ _ _ _ _ _ _ _ _T_H_E_ _G_E_N_I_U_S_ _C_O_M_P_I_L_E_R_ _F_I_K_S_ 5.
When the input data and the GENIUS description are ready, it is
time for the compilation of the program. For this purpose we use
the compiler FIKS (the frame in fig. 12). In fig. 13 a selection
of FIKS commands is shown. You can look in the manual 1 for
further information.
DB TRANS-
DESCR. ACTION
FILE FILE
GENIUS
DESCRIP- FIKS GENIUS SMART RESULTS
TION FILE
LISTING LOG LOG
Figure 12: The GENIUS system.
FIKS,
GENIUSTEXT.genius _description _file _name,
DESCRIPFILE.database _description _file _name,
INIT.initials,
M_m_m_ yes
LIST. ,
P_p_p_ no
NEWGENIUS.genius _file _name. geniusident,
TAKE.geniusnumber _l,
.
.
TAKE.geniusnumber _m
Figure 13: Activation of FIKS.
\f
5_._1_ _ _ _ _ _ _ _G_e_n_i_u_s_ _D_e_s_c_r_i_p_t_i_o_n_ _F_i_l_e_ _N_a_m_e_ 5.1
The genius description file name is the name of the textfile in
which the actual genius description(s) is/are stored.
5_._2_ _ _ _ _ _ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_ _F_i_l_e_ _N_a_m_e_ 5.2
This command is used if there is a database description.
The database description file name indicates the file in which
the database description is stored.
5_._3_ _ _ _ _ _ _ _I_n_i_t_i_a_l_s_ 5.3
The initials are the initials of the programmer, and is a text
comprising at most four letters.
5_._4_ _ _ _ _ _ _ _G_e_n_i_u_s_ _F_i_l_e_ _N_a_m_e_ 5.4
The genius file name is the name of the file in which the compi-
led genius description will be stored.
5_._5_ _ _ _ _ _ _ _G_e_n_i_u_s_ _I_d_e_n_t_ 5.5
The genius ident is a text that serves as an identifier for the
compiled genius file.
5_._6_ _ _ _ _ _ _ _G_e_n_i_u_s_ _N_u_m_b_e_r_ 5.6
The genius number is the number of the genius description to be
compiled. If more than one is to be compiled, the TAKE commands
have to appear in increasing order of the genius numbers (l<m).
\f
F_ 6_._ _ _ _ _ _ _ _ _T_H_E_ _G_E_N_I_U_S_ _P_R_O_C_E_S_S_O_R_ _S_M_A_R_T_ 6.
Now it is finally time for the run of the genius program(s). For
this purpose we use the processor SMART (the frame in fig. 14).
In fig. 15 a selection of commands for the activation of each
SMART run is shown.
DB TRANS-
DESCR. ACTION
FILE FILE
GENIUS
DESCRIP- FIKS GENIUS SMART RESULTS
TION FILE
LISTING LOG LOG
Figure 14: The GENIUS system.
SMART,
GENIUS.geniusfilename.geniusident.geniusversion,
TRANSFILE.recordfilename.TEXT,
PRINTFILES.printfilenumber.resultfilename,
RUN.usernumber.geniusnumber _1.geniusnumber _2
Figure 15: The activation of SMART.
6_._1_ _ _ _ _ _ _ _G_e_n_i_u_s_ _F_i_l_e_ _N_a_m_e_ 6.1
See section 5.4.
\f
6_._2_ _ _ _ _ _ _ _G_e_n_i_u_s_ _I_d_e_n_t_ 6.2
See section 5.5.
6_._3_ _ _ _ _ _ _ _G_e_n_i_u_s_ _V_e_r_s_i_o_n_ 6.3
If the value of the genius version is zero the version check is
suppressed, else see the manual 1.
6_._4_ _ _ _ _ _ _ _R_e_c_o_r_d_ _F_i_l_e_ _N_a_m_e_ 6.4
The record file name is the name of the transaction file in which
the input records are stored.
If the records are stored in an ordinary textfile, the record
file name has to be followed by a point and the reserved word
TEXT.
6_._5_ _ _ _ _ _ _ _P_r_i_n_t_ _F_i_l_e_ _N_u_m_b_e_r_ 6.5
See subsection 4.1.1.10.
6_._6_ _ _ _ _ _ _ _R_e_s_u_l_t_ _F_i_l_e_ _N_a_m_e_ 6.6
The result file name is the name of the text file in which the
result is going to be stored.
6_._7_ _ _ _ _ _ _ _U_s_e_r_ _N_u_m_b_e_r_ 6.7
The user number is the one which is used in the corresponding
transaction file.
\f
6_._8_ _ _ _ _ _ _ _G_e_n_i_u_s_ _N_u_m_b_e_r_ 6.8
If you run one GENIUS program with the corresponding input,
whether it is from a textfile or a database, the GENIUS number is
just the number of your GENIUS description, and the following
bracket is omitted.
However, it is also possible to run several GENIUS programs with
input from the same transaction file. The value of the geniuser
in the input is calculated from a user number and a GENIUS
number, which means that the input refers only to one of the
GENIUS programs. This GENIUS number is given as the first one,
and the GENIUS number of the actual run as the second.
\f
F_ 7_._ _ _ _ _ _ _ _ _E_X_A_M_P_L_E_S_ 7.
In this last chapter the use of GENIUS is illustrated by examples.
They are given in order of increasing complexibility.
7_._1_ _ _ _ _ _ _ _M_u_n_i_c_i_p_a_l_ _T_r_i_m_ 7.1
The municipals have a register for local firms. For each firm
following data are available: Tradecode, firm number, number of
employees, turnover, firm name, and firm address.
7_._1_._1_ _ _ _ _ _P_r_o_b_l_e_m_:_ _L_a_b_e_l_s_ 7.1.1
Many times during the year the municipal, PENTOWN, sends letters
to all the local firms. Therefore the municipal decides to make a
program, printing out labels for all the firms.
7_._1_._1_._1_ _ _ _L_a_y_o_u_t_ 7.1.1.1.
The municipal prefers the labels listed in a long column. The
layout is shown in fig. 16.
\f
F_\f
F_ 7_._1_._1_._2_ _ _ _I_n_p_u_t_ 7.1.1.2
This is a very simple problem, and the creation of the textfile
containing the necessary input will also be easy. But the
municipal knows that it also has need for a survey of the firms
sorted according to trade and number of employees. So instead of
making an inputfile for each of the problems they decide to make
a general one, which can be used in both problems. The textfile,
which is called KOMTRANS, is shown in fig. 17.
\f
F_
Figure 17: Input to municipal trim. \f
F_ The commands outside the marks belong to BOSS, FP, and UTILITY.
Inside the marks the data to GENIUS are placed.
KOMTRANS contains 9 records. The first one, TYPE 1, rises from
the municpal and the eight others, TYPE 2, from the eight firms.
In the first record the following data are given: The number of
the user is 27, and the genius number is 1. Because we want to
sort according to the tradecode later on, we treat it as a
sortword. Of course the municipal does not have any tradecode,
but is given the dummy value, 0. The name of the municipal is
Pentown.
Now the data from the eight firms are given. We have sorted them
first on tradecode, if 7 then hotels if 8 then shops, second on
number of employees. For each firm the following data are given
in succession: The geniuser, the tradecode, the type, the
firmnumber, the staff, the turnover (pound/year), the firmname,
the housenumber (if none the dummy value, 0 is given), the
street, the postal district, and the postal code divided into two
(remember that spaces are not allowed).
7_._1_._1_._3_ _ _ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 7.1.1.3
Now the GENIUS description is made. It is stored in a textfile
called IAGENTRANS1, and the listing is shown in fig. 18.
\f
Figure 18: GENIUS description to labels.
m_ The genius number is 1, and there are no restrictions on the user
(no usernumber(s) given). In the fieldspecification the necessary
variables for the labels are given. Furthermore the variable,
tradecode, is given, because it is a sortword (used in the next
problem). Base has the standardvalue 2. The number of sortwords
is 2, viz tradecode and type, both with the variable type, word.
The data from type 1 concerning the municipal are not used in
this program. Therefore they are fixed as dummies. The value, 6,
is the declared length in words of the text, municipal. In type 2
we dont use the firmnumber, the staff and the turnover, why these
are fixed as dummies. The result is going to be stored on
printfile 11 under the name, labels. The printstatement is called
label and is activated each time a type 2 transaction is read,
i.e. each time another firm appears. It states: First it jumps 4
lines (to make some room between the labels), and then it writes\f
the firmname starting in the first position. On the next line is
p_
written the housenumber followed by a space, if there is any
housenumber (see the 2nd and 3rd last line in the GENIUS
description), and finally on this line the name of the street. If
there is no housenumber, the name of the street will be placed in
the first position. On the next line the postal district is
printed followed by a space, the first part of the postal code, a
space and the last part of the postal code. The description is
terminated by an end and the genius number.
7_._1_._1_._4_ _ _ _C_o_m_p_i_l_a_t_i_o_n_ 7.1.1.4
Now the program is going to be compiled. The compiler, FIKS, is
used. The activation commands are shown in fig. 19.
Figure 19: FIKS commands to labels.
m_ Line 1: FIKS is called.
Line 2: The GENIUS description is stored in the file called
IAGENTRANS1.
Line 3: The programmer has the initials IA.
Line 4: A listing of the GENIUS description is wanted.
Line 5: The compiled GENIUS description is to be stored in the
file GENIFILE identified by GEN.
Line 6: The geniusnumber to be compiled is 1.
\f
7_._1_._1_._5_ _ _ _P_r_o_c_e_s_s_ 7.1.1.5
The processing of the program is done by SMART. The activation of
SMART is shown in fig. 20.
p_
Figure 20: SMART commands to labels.
The statements outside the marks belong to BOSS/FP.
Line 1: SMART is called.
Line 2: The compiled description is to be found in GENIFILE.GEN.
There is no versioncheck.
Line 3: The input is to be found in the textfile, KOMTRANS.
Line 4: The result produced in printfile 11, is to be stored in
an output file called LABELS. Remember, consistence with
the printfile number in the GENIUS description. .
Line 5: Run the genius program 1 for user 27.
7_._1_._1_._6_ _ _ _R_e_s_u_l_t_ 7.1.1.6
During the editing of the transactions and the compilation of the
description the following is generated on the used printoutfile,
here PRIMOUT.
\f
Because of the command LIST KOMTRANS the contents of KOMTRANS are
listed.
After this the FIKS commands are listed twice, first by FP and
second by the FIKS compiler itself. Then the GENIUS description
is listed in an edited form, and the variables are listed below
the TYPE specifications. The 3 columns of integers in the frame
are irrelevant checknumbers. The GENIUS description is followed
by an identifier list, tables of max. limits together with the
ones actually used, and organisation of the variable-arrays. All
written by FIKS.
Finally the SMART commands are listed twice and the SMARTLOG is
printed.
The listing is shown in fig. 21.
\f
F_
Figure 21: Printout from labels (to be continued). \f
F_ (continued)
Figure 21: Printout from labels (to be continued). \f
F_ (continued)
Figure 21: Printout from labels (to be continued). \f
F_ (continued)
Figure 21: Printout from labels.
The final result is stored in the file, LABELS.
The printoutfile always starts with the GENIUS star telling the
genius- and usernumber. The next page(s) is/are the desired
output. A check with the layout shows complete consistence, and
our problem is solved.
The final result is shown in fig. 22.
\f
F_
Figure 22: Final result on labels. \f
7_._1_._2_ _ _ _ _ _P_r_o_b_l_e_m_:_ _F_i_r_m_l_i_s_t_ 7.1.2
As previously mentioned the municipal, Pentown, also wants a list
of firms sorted according to tradecode and number of employees.
7_._1_._2_._1_ _ _ _L_a_y_o_u_t_ 7.1.2.1
The layout for this problem is designed according to the follo-
wing ideas. The firms are divided into groups according to their
tradecode. Within each trade they are listed in decreasing order
of number of employees. Every page begins with a head and a trade
specification. For each firm the name, number, staff, and turn-
over are printed. Finally the total number of firms, employees,
and sum of the turnovers are accumulated both for each trade and
for the firms in all. The layout is shown in fig. 23.
\f
F_\f
F_ 7_._1_._2_._2_ _ _ _I_n_p_u_t_ 7.1.2.2
The same transaction file as in the problem, labels, is used.
7_._1_._2_._3_ _ _ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 7.1.2.3
The conditions deriving from the previous problem, are explained
here.
The head is printed every time a new tradecode appears, except
for TYPE 1 transaction records (tradecode = 0).
The tradeline is printed on the same conditions as the head.
Every time a TYPE 2 transaction is read, i.e. a new firm appears,
the firmline is printed.
Every time a trade is finished, the total of the tradecode is
printed.
Finally a grand total is printed.
\f
F_
Figure 24: GENIUS description to firmlist. \f
F_ 7_._1_._2_._4_ _ _ _C_o_m_p_i_l_a_t_i_o_n_ 7.1.2.4
The FIKS commands (fig. 25) are almost the same as in the problem,
labels. The deviations are underlined.
Figure 25: FIKS commands to firmlist.
7_._1_._2_._5_ _ _ _P_r_o_c_e_s_s_ 7.1.2.5
The SMART commands (fig. 26) differ in the following ways from
those in the previous problem.
The result produced in printfile 12 is to be stored in the file
FIRMLIST.
The run specification direct the running of GENIUS description 2,
but with genius number 1 used in the records of the transaction
file.
\f
Figure 26: SMART commands to firmlist.
7_._1_._2_._6_ _ _ _R_e_s_u_l_t_ 7.1.2.6
The result, which is stored in FIRMLIST, is shown without the
GENIUS star in fig. 27.
\f
F_
Figure 27: Final result on firmlist. \f
F_ 7_._2_ _ _ _ _ _ _ _C_u_s_t_o_m_e_r_ _B_a_l_a_n_c_e_ _S_u_r_v_e_y_ 7.2
In this section the use of GENIUS will be illustrated by a larger
common example. First it is shown by the use of an ordinary text-
file without any database description and afterwards with the use
of a database together with its corresponding database descrip-
tion. The differences will be pointed out.
A bicycle supplier, UK BICYCLE IMPORT, has a number of customers
to whom he delivers bicycles, ect. For each delivery and payment
the following information is given: invoice number, posttype
(i.e. whether it is a credit- or a debitpost), amount, entrydate,
duedate, ect. Now he wants to make a report telling him about the
posts for each customer, a balance which shows, when he can
expect the payments of his debtors to arrive, and a note showing
if reminders are needed. Finally he wants an overall balance for
all of his customers.
7_._2_._1_ _ _ _ _ _I_n_p_u_t_ _f_r_o_m_ _a_ _T_e_x_t_f_i_l_e_ 7.2.1
7.2.1.1
7_._2_._1_._1_ _ _ _L_a_y_o_u_t_
The first part of the layout (fig. 28) is printed for each
customer. The last part (fig. 29) after the last customer.
\f
F_
Figure 28: Customer balance survey.
\f
F_\f
F_ 7_._2_._1_._2_ _ _ _I_n_p_u_t_ 7.2.1.2
The input to the problem, debtorsurvey, using a textfile, is
shown in fig. 30. The variables are explained in fig. 3, only
here the number of records is 38 instead of 4. The genius number
is fixed as 5 and the user number as 11.
\f
F_
Figure 30: Input to debtorsurvey (to be continued). \f
F_ (continued)
Figure 30: Input to debtorsurvey (to be continued). \f
F_ (continued)
Figure 30: Input to debtorsurvey (to be continued). \f
F_ (continued)
Figure 30: Input to debtorsurvey. \f
F_ 7_._2_._1_._3_ _ _ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 7.2.1.3
The GENIUS description (fig. 31) is shown in the form edited by
FIKS.
The genius number is 5.
The variables and their type are specified in the fieldlist.
The base is equal to 2 (standard).
The number of sortwords is three (debtornumber: long = 2 words +
type: word = 1 word).
Type 1 is the userdata.
Type 2 is the debtordata.
Type 3 is the invoicedata.
The result is printed on printfile 1 identified by debtrsurvey.
Every time a type 2 is read from the transaction file, KOMTRANS,
(i.e. every time a new debtor is read), HEAD, INFORM and
CUSTOMERHEAD are printed.
Every time a type 3 (new invoice) is read, AEINF is printed.
DEBNO is defined as an event, which appears when the invoice
records belonging to one real debtor (i.e. not when the
debtornumber is zero) are finished. Every time this happens
BALINF is printed.
For each new customer we get a new page.
At last (ON END GENIUSER) we print HEAD, INFORM and
TOTAL _SURVEY.
\f
After the print statements, the not declared variables used in
these are defined.
The following general facilities are used:
IF THEN ELSE
CASE OF
DIGITS OF
ACCUM OVER
FOR WHICH
These should be commonly known, except ACCUM, which is an
accumulation. Further information is to be found in the manual
1.\f
F_
Figure 31: GENIUS description to debtorsurvey (to be continued). \f
F_ (continued)
Figure 31: GENIUS description to debtorsurvey (to be continued). \f
F_ (continued)
Figure 31: GENIUS description to debtorsurvey (to be continued). \f
F_ (continued)
Figure 31: GENIUS description to debtorsurvey. \f
F_m_ 7_._2_._1_._4_ _ _ _C_o_m_p_i_l_a_t_i_o_n_ 7.2.1.4
The FIKS commands (fig. 32) are analogous to those in the
p_ previous example.
m_ Figure 32: FIKS commands to debtorsurvey.
7_._2_._1_._5_ _ _ _P_r_o_c_e_s_s_ 7.2.1.5
The SMART commands (fig. 33) are analogous to those in the
p_ previous example.
Figure 33: SMART commands to debtorsurvey.
m_7_._2_._1_._6_ _ _ _R_e_s_u_l_t_ 7.2.1.6
The final result, excl. the GENIUS star, is shown in fig. 34.
p_ \f
F_
Figure 34: Final result on debtorsurvey (to be continued). \f
F_ (continued)
Figure 34: Final result on debtorsurvey (to be continued). \f
F_ (continued)
Figure 34: Final result on debtorsurvey (to be continued). \f
F_ (continued)
Figure 34: Final result on debtorsurvey (to be continued). \f
F_ (continued)
Figure 34: Final result on debtorsurvey (to be continued). \f
F_ (continued)
Figure 34: Final result on debtorsurvey. \f
F_ 7_._2_._2_ _ _ _ _ _I_n_p_u_t_ _f_r_o_m_ _a_ _D_a_t_a_b_a_s_e_ 7.2.2
7_._2_._2_._1_ _ _ _L_a_y_o_u_t_ 7.2.2.1
See subsection 7.2.1.1.
7_._2_._2_._2_ _ _ _I_n_p_u_t_ 7.2.2.2
Now we use input from a database instead of a textfile.
The file, which contains the database extraction, is called
GEN1111. Fig. 35 shows a printout of a part of this file.
The other file, which contains the logical description of the
database extraction, is called GENDESCRIP. This is shown in fig.
36.
\f
F_
Figure 35: A part of the database extraction to debtorsurvey. \f
F_
Figure 36: Description for the database extraction to debtor-
survey. \f
F_ 7_._2_._2_._3_ _ _ _G_E_N_I_U_S_ _D_e_s_c_r_i_p_t_i_o_n_ 7.2.2.3
The first part of the GENIUS description, in which there are some
differences to the one in fig. 31, is shown in fig. 37. The
differences are underlined.
The first one appears in the field list. It is only necessary to
declare the sortwords excl. TYPE, here debtorno, instead of all
the input variables.
The value of base has changed from the standardvalue 2 to 3. The
reason for this is to be found in the database description (fig.
36). To the two standardwords in the administrative field (record-
length and checksum) is added the word: recordtype.
The last difference is to be found in the type identification.
Here the field lists are changed with the record specifications.
The GENIUS description is stored in IAGENIUS5.
\f
F_
Figure 37: The first part of the GENIUS description to debtor-
survey. \f
F_ 7_._2_._2_._4_ _ _ _C_o_m_p_i_l_a_t_i_o_n_ 7.2.2.4
The FIKS commands are shown in fig. 38. The differences from fig.
32 are underlined.
The file containing the GENIUS description is called IAGENIUS5
instead of IAGENTRANS5.
The statement stating where to find the database description is
included here. It is to be found in GENDESCRIP.
Figure 38: FIKS commands to debtorsurvey using database.
\f
7_._2_._2_._5_ _ _ _P_r_o_c_e_s_s_ 7.2.2.5
The SMART commands (fig. 39) are almost equal to those used in
subsection 7.2.1.5, only the data are to be found in GEN1111
instead of in the textfile, KOMTRANS.
Figure 39: SMART commands to debtorsurvey using database.
7_._2_._2_._6_ _ _ _R_e_s_u_l_t_ 7.2.2.6
A part of the final result is shown in fig. 40. Except for the
spaces instead of the minus signs in the textvariables containing
more than one word, there are no differences. The reason for this
difference is, that spaces are not allowed when using input from
a textfile, while there is no such restriction when the input
comes from a database.
\f
F_
Figure 40: The first part of the final result on debtorsurvey
using database.
\f
F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.
1. RCSL No 21-V055:
GENIUS, 2nd English Edition, April 1978, Paul Lindgreen.
Abstract:
This manual describes GENIUS, a system for producing report
generating programs. It is based on specifications in a
declarative language of the characteristics of the reports
and a compilation of these descriptions into executable
programs.
2. RCSL No 21-V038:
SORT80 - SPLIT80, English Edition, February 1978, Jens V.
Thofte.
Abstract:
Description of 2 basic modules in SYSTEM80:
SORT80 for sorting a sequential file (transaction file), the
key description and other sort parameters are read
from a SYSTEM80 database description.
SPLIT80 for splitting one sequential file into more sequen-
tial files.
3. RCSL No 21-V064:
PRINT80, 2nd English Edition, March 1980, Carl Henrik Dreyer.
Abstract:
PRINT80 is a SYSTEM80 tool, which on the basis of a descript-
file and a data base, consisting of cf-files and bs-files,
can print record descriptions and record contents.
4. RCSL No 21-V067:
DATABASE80, 3rd English Edition, June 1980, Vibeke Nielsen.
Abstract:
The purpose of DATABASE80 is to check and translate a data-
base description. The description is read from a SYSDOK file
as a text and translated into a database description file to
be used by other database modules.
\f
F_ B_._ _ _ _ _ _ _ _ _N_O_T_A_T_I_O_N_ B.
The notation used in this introduction is described in the
following paragraphs:
1. All words printed in capital letters belong to the language.
They are referred to as "reserved names".
2. Variable entries which are to be supplied by the format pro-
grammer are printed in lower case letters.
3. When punctuation or other special characters are printed, they
are required.
4. Braces enclosing vertically listed items indicate that one
and only one of the items is required.
5. Brackets are used to enclose a portion which is optional.
6. Three following points placed vertical or horizontal ...
between entries indicate that they can occur the number of
times indicated by the index of the last entity.
\f
F_ C_._ _ _ _ _ _ _ _ _I_S_O_-_C_H_A_R_A_C_T_E_R_S_ C.
\f
F_ D_._ _ _ _ _ _ _ _ _A_L_P_H_A_B_E_T_I_C_A_L_ _I_N_D_E_X_ D.
administrative field ........... 13, 72
array .......................... 4, 12
basenumber ..................... 13
basic event .................... 17
comment ........................ 9
compiler ....................... 22, 33, 35
criteria event ................. 17
database description ........... 6, 10, 15, 74
database description file name . 23
database extraction ............ 6, 69
date ........................... 4, 12
decimal ........................ 19
definition body ................ 21
definition symbol .............. 17, 20
END ............................ 17
event reference ................ 17
fieldname ...................... 12
fieldnumber .................... 13
field reference list ........... 13
FIKS ........................... 22, 33, 35, 45, 62, 74
format ......................... 16, 18
GENIUS description ............. 9, 10, 20, 31, 33, 35, 43, 56, 72
genius description file name ... 23
GENIUSER ....................... 17
geniuser ....................... 4
genius file name ............... 23
geniusident .................... 23
geniusnumber ................... 4, 12, 23, 25, 31, 32, 33, 38, 56
geniusversion .................. 25
group .......................... 12
\f
horizontal operation ........... 19
identifier ..................... 20, 35
initials ....................... 23, 33
LINE ........................... 17
long ........................... 3, 12, 13
NEW ............................ 17
newline ........................ 18
number layout .................. 19
ON ............................. 17
PAGE ........................... 17, 56
principal ...................... 19
print file number .............. 14
print identifier ............... 17
processor ...................... 24
record file name ............... 25
result file name ............... 25
result name .................... 14
SMART .......................... 24, 33, 35, 45, 62, 75
sortname ....................... 13
sortnumber ..................... 13
sortword ....................... 4, 13, 17, 31, 32, 56, 72
standard event ................. 17
statement ...................... 9
tabulation ..................... 18
TEXT ........................... 25
text ........................... 3, 12, 13, 32
TRANS .......................... 17
trigger ........................ 16, 17
TYPE ........................... 4, 17, 31, 35, 43, 72
type ........................... 4, 32, 56
user identification ............ 12
usernumber ..................... 4, 12, 25, 32, 39
\f
value specification ............ 16, 19
variable type .................. 12
word ........................... 3, 12, 13, 32, 56
\f
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. DESCRIPTION ............................................ 1
2. FLOPPY DISK INTERFACE .................................. 4
2.1 General Description ............................... 4
2.2 Block Diagram ..................................... 4
2.3 Functional Description ............................ 4
2.3.1 Address Decoder ............................ 4
2.3.2 Floppy Disk Controller ..................... 4
2.3.3 Strapping FDI501 and FDI502 ................ 8
3. OPTIONAL PARALLEL INTERFACE ............................ 22
4. CIRCUIT DIAGRAM ........................................ 25
5. SIGNAL CABLE ........................................... 36
5.1 Signal Cable if PIO is Used ....................... 36
\f
ii
\f
F_ 1_._ _ _ _ _ _ _ _ _D_E_S_C_R_I_P_T_I_O_N_ 1.
The FDI501 and FDI502 Floppy Disk Interface are controller boards
to the RC850 system. The controller may be connected to the
microcomputer board housed in RC850. Connection to the floppy
disk drive is made using the cable CBL960 which makes a standard
connection for floppy disk drives used in the RC700 and RC850
systems.
This manual contains the following main parts:
Floppy Disk Interface
Optional Parallel Interface
Signal Cables
N_o_t_e_: FDI501 and FDI502 have the same format, fit and function.
FDI502 is a new print layout which removes the FCO20-005.
In FDI502 the switches are replaced with wrappings and
removable shorts.
\f
F_
\f
F_
\f
F_ 2_._ _ _ _ _ _ _ _ _F_L_O_P_P_Y_ _D_I_S_K_ _I_N_T_E_R_F_A_C_E_ 2.
2_._1_ _ _ _ _ _ _ _G_e_n_e_r_a_l_ _D_e_s_c_r_i_p_t_i_o_n_ 2.1
The FDI501 and FDI502 are built on single circuit boards. They
are connected to J1 on the microcomputer board housed in the
RC850. Through this connector the power to the board is supplied.
FDI501 needs the following power: +5 V. Typical power
consumption: 0.6 A.
The board layout is shown in fig. 1.
2_._2_ _ _ _ _ _ _ _B_l_o_c_k_ _D_i_a_g_r_a_m_ 2.2
Fig. 2 shows a block diagram for FDI501 and FDI502. In the dia-
gram is shown, where each block is found in the circuit diagrams.
2_._3_ _ _ _ _ _ _ _F_u_n_c_t_i_o_n_a_l_ _D_e_s_c_r_i_p_t_i_o_n_ 2.3
The functional description follows the block diagram. This paper
does not contain a full description of all the functions of the
VLSI circuits used. This kind of information may be supplied by
the manufacturers of the VLSI circuits.
2_._3_._1_ _ _ _ _ _A_d_d_r_e_s_s_ _D_e_c_o_d_e_r_ 2.3.1
The addressing of the devices is made very simple with the
circuits shown in diagram page FDI04. Each device uses 4
addresses as shown in fig. 3.
2_._3_._2_ _ _ _ _ _F_l_o_p_p_y_ _D_i_s_k_ _C_o_n_t_r_o_l_l_e_r_ 2.3.2
The floppy disk controller to FDI501 and FDI502 is based on the
FDC chip uPD765 from NEC or 8272 from Intel. The chip contains
the circuitry and control functions for interfacing the processor
to 4 floppy disk drives. It supports both IBM3740 single density\f
F_
\f
F_
\f
F_
\f
F_ format (FM) and IBM system 34 double density format including
double sided recording.
Fig. 4 shows a block diagram for the controller chip.
The uPD765 contains two registers which may be accessed by the
program. The 8-bit main status register contains the status
information of the FDC and may be accessed at any time. The 8-bit
data register (actually consists of several registers in stack
with only one register present to the bus at a time), stores
data, commands, parameters and floppy disk drive information.
Fig. 5 shows the information stored in the status register.
Fig. 6 shows the information to and from the data register during
a read or write instruction to the controller. The programming of
uPD765 is very complex and is described by the manufacturer. The
controller interfaced to both Maxi- and Mini disc drives. The
circuits on diagrams FDI02 and FDI03 show this.
Fig. 7 shows the data media floppy disk. The diskette contains a
number of tracks which again are divided into a number of sectors
as shown in fig. 8. The controller is able to format, read or
write the diskette. Information about the actual formats used is
available in the software manuals. Fig. 9 shows the two recording
methods used.
2_._3_._3_ _ _ _ _ _S_t_r_a_p_p_i_n_g_ _F_D_I_5_0_1_ _a_n_d_ _F_D_I_5_0_2_ 2.3.3
Besides the 8 switches selectable for the program using the
device code 14(Hex) (see subsection 2.3.2), FDI801 contains 4
other switches. The way to strap them is shown in fig. 10.
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_ 3_._ _ _ _ _ _ _ _ _O_P_T_I_O_N_A_L_ _P_A_R_A_L_L_E_L_ _I_N_T_E_R_F_A_C_E_ %:
The layout of FDI501 and FDI502 is prepared for connection of a
parallel interface. Although the IC's are not mounted, the fol-
lowing description of the circuit is contained in this paper. The
Z80A parallel I/O (PIO) interface controller is a programable,
two port device which provides interface between the CPU and the
connector J2 for parallel I/O. The diagram is shown on page
FDI04. The block diagram is shown in fig. 11. The internal struc-
ture of the Z80A-PIO consists of a bus interface, internal con-
trol logic, port A I/O logic, port B I/O logic and interrupt con-
trol logic.
Each of the two port I/O logic is composed of 6 registers. The
registers include: an 8-bit input register, an 8-bit output re-
gister, a 2-bit moderegister, an 8-bit mask register, an 8-bit
input/output select register and a 2-bit mask control register.
Before using the PIO it has to be programmed to the wanted Inter-
rupt Vector and operating mode. This is described in manuals from
Zilog.
The timing diagram in fig. 12 shows input from a keyboard. The
interrupt system is described in the manual for the microcom-
puter.
\f
F_
\f
F_
\f
F_ 4_._ _ _ _ _ _ _ _ _C_I_R_C_U_I_T_ _D_I_A_G_R_A_M_ 4.
The following 5 pages contain the circuit diagrams for FDI501 and
FDI502. They are made according to the RC standard for diagrams
to the RC700 and RC850 systems.
\f
F_ S_i_g_n_a_l_ _ _ _ _ _ _ _ _ _D_e_s_t_i_n_a_t_i_o_n_ _ _D_e_s_c_r_i_p_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
16 MHz Symmetric clock signal of 16 MHz
8 - - - - - 8 -
4 - - - - - 4 -
2 - - - - - 2 -
1 - - - - - 1 -
0.5 - - - - - 0.5 -
0.25 - - - - - 0.25 -
8 MHz/4 MHz 3 Clock to floppy controller
8 MHz for MAXI floppy and
4 MHz for MINI floppy drives
CLOCK1 2 Clock to read logic for floppy con-
troller
CLOCK2 Clock signal to generate WRITE CLOCK
MINI SELECT 3, 4 Selects MINI floppy as strapped or as
programmed. Strapping is described in
fig. 10.
WRITE CLOCK 3 Write clock input to floppy control-
ler. High for about 250 nS. Period
time is 4 S., 2 S. or 1 S.
\f
\f
F_ S_i_g_n_a_l_ _ _ _ _ _ _ _ _ _D_e_s_t_i_n_a_t_i_o_n_ _ _D_e_s_c_r_i_p_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
READ DATA 3 Read data from the floppy, synchron-
ized with the VCO signal to separate
phase bits and data bits
D WINDOW 3 Data window is used by the floppy
controller to separate data bits from
phase bits
STEP 5 Output pulse to make the floppy head
move from one cylinder to the next
DIRECTION SEL 5 Used together with the step pulse. A
low signal together with a step pulse
makes the floppy head move towards
the center
WP/TS 3 Write protect/two sided. Signal from
the floppy disk drive
FLT/TRO 3 Fault/Track 0. Signal from the floppy
disk drive
LOW CURRENT 5 Signal to the MAXI disk drive. Used
to decrease the write current when
the head is close to the center of
the disk
MOTOR EN 5 Signal to the MINI disk. Used to
start and stop the motor
RESET 3 Power Reset and Master Reset
DSEL 0 5 DRIVE SELECT 0
- 1 5 - - 1
- 2 5 - - 2
- 3 5 - - 3
\f
F_
\f
F_ S_i_g_n_a_l_ _ _ _ _ _ _ _ _ _D_e_s_t_i_n_a_t_i_o_n_ _ _D_e_s_c_r_i_p_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
WR DATA 5 WRITE Data to the floppy disk drive.
Valid when WRITE GATE is on
WRITE GATE 5 Control signal to the floppy disk
drive. Informs that now the WR DATA
is valid
MFM MODE 1 MFM MODE is dual density,
MF MODE is single density
VCO 2 Voltage Controlled Oscillator. The
signals is used to enable the read
control logic
SEEK MODE 2 Sets input and output selector in
seek mode
FR/STP 2 Control signal. Fault Reset/Step
LC/DIR 2 Control signal. Low Current/Direction
HEAD LOAD 5 Control signal. Head Load
SIDE SELECT 5 Control signal. Side Select
DRIVE SEL 0 2 Control signal. Drive Select 0
DRIVE SEL 1 2 Control signal. Drive Select 1
DRIVE SEL 2 2 Control signal. Drive Select 2
DRIVE SEL 3 2 Control signal. Drive Select 3
DREQ1 DMA Request from the floppy
controller
FD INTR Interrupt Request from the floppy
controller
RDY Floppy Disk Drive is Ready. When S5
is closed a Minifloppy without Ready
signal may be used
INDEX Index Mark from floppy disk drive
\f
F_
\f
F_ S_i_g_n_a_l_ _ _ _ _ _ _ _ _ _D_e_s_t_i_n_a_t_i_o_n_ _ _D_e_s_c_r_i_p_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I/O A (0:7) Input/Output signals from channel A
of the PIO
STROBE A Input Strobe signal for the channel A
of the PIO
REG READY A Register Ready A output signal for
the channel A of the PIO
I/O B (0:7) Input/output signals from channel B
of the PIO
STROBE B Input Strobe signal for the channel B
of the PIO
REG READY B Register Ready B output signal for
the channel B of the PIO
INT Interrupt request
EN FLOP Enable Floppy Controller
EN SWITCH 1, 2 Enable Switch
BUS (0:7) Data bus for the system
Test strobe The signal is used when the PIO is
tested
NOTE 1: POS51 and POS81 are not mounted in FDI501.
NOTE 2: S5 left open disables the switches (S1:S4) from being
sensed by the program.
\f
F_
\f
F_ S_i_g_n_a_l_ _ _ _ _ _ _ _ _ _D_e_s_t_i_n_a_t_i_o_n_ _ _D_e_s_c_r_i_p_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
PRECLOCK 3 Clock to precompensation register
RD DATA 2 Input signal from floppy disk
WRITE PROT 2 - - - - -
TRACKO 2 - - - - -
READY 3 - - - - -
INDEX 3 - - - - -
TWO SIDED 2 - - - - -
\f
F_
\f
F_ 5_._ _ _ _ _ _ _ _ _S_I_G_N_A_L_ _C_A_B_L_E_ 5.
The cable used is of the type CBL960. The signal cable is con-
nected from J3 on the FDI501 board to the socket of RC850. The
output plug placed in the socket of RC850 is a 37-pin D connector
female and makes an RC standard for connection to floppy disk
drives like RC762.
The pin numbers are shown in fig. 13.
5_._1_ _ _ _ _ _ _ _S_i_g_n_a_l_ _C_a_b_l_e_ _i_f_ _P_I_O_ _i_s_ _U_s_e_d_ 5.1
If the PIO is used, the pin numbers of the cable are the same as
shown in diagram FDI04, connector J2. The output connector is
also placed in the socket of RC850 and is a 25-pin D connector
female.
\f
F_
\f
F_
\f
«eof»