|
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: 121216 (0x1d980)
Types: TextFile
Names: »D74«
└─⟦a2495fc4f⟧ Bits:30005867/disk10.imd Dokumenter (RCSL m.m.)
└─⟦this⟧ »D74«
5_._9_._7_ _ _C_o_n_n_e_c_t_ _A_c_c_o_u_n_t_ _E_n_t_r_i_e_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 6
Designation : Erase account entry
Reading :
Writing :
Conditions for
activation : If erase _scan = 1. The adaption point
is activated for each account entry read
during the scan.
Comm. variables:ae_erased (account entry erased)
call: 0,1 (0 = not erased)
answer: 0,1
cont_scanning (continue the scanning)
call: 1 (wanted)
answer: 0,1
Use : A possible erasing may be done by means of
the communication variable ae _erased
Block reference: B (adp _block _18,29)
Next adaption
point : Adp 7 or exit \f
5_._9_._7_ _ _C_o_n_n_e_c_t_ _A_c_c_o_u_n_t_ _E_n_t_r_i_e_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 7
Designation : Update balance
Reading :
Writing :
Conditions for
activation : If new _record _wanted = 0 (not wanted).
An account entry record selected in adp 4
by means of recordpos will be available.
Comm. variables:ae_erased (account entry erased)
call: 0,1 (0 = not erased)
answer: 0,1
copy_wanted _in _ta
call: 0 (not wanted)
answer: 0,1
erase_scan (scan for erasing of account entries)
call: 0 (not wanted)
answer: 0,1
Use : Updating of balance in the selected account
entry record. The record can be erased after-
words, at once or during an erase scan.
Block reference: B (adp _block _18,30)
Next adaption
point : Adp 3 \f
5.9.8 A_c_c_o_u_n_t_ _E_n_t_r_y_ _l_i_n_e_ _f_o_r_ _B_a_t_c_h_ _P_u_r_p_o_s_e_s_
(tegning 96t)\f
5_._9_._8_ _ _A_c_c_o_u_n_t_ _E_n_t_r_y_ _L_i_n_e_ _f_o_r_ _B_a_t_c_h_ _P_u_r_p_o_s_e_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read the information
Reading :From the input buffer
Writing :
Conditions for
activation : After interpretation of the line code
(adp 0)
Comm. variables:posting _wanted (voucherline in the terminal
area
call: 1 (wanted)
answer: 0,1
Use : Reading of information
Block reference: B (adp _block _18,3)
Next adaption
point : Exit \f
5.10 P_r_i_n_t_ _O_u_t_ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_
L_i_s_t_ _o_f_ _c_o_n_t_e_n_t_s_P_a_g_e_
Introduction 119
Outline 122
5.10.1 Print Out Command (UOR) 123
5.10.2 Print Out Acceptance (UAC) 128
\f
5_._1_0_ _ _P_r_i_n_t_ _O_u_t_ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_
I_n_t_r_o_d_u_c_t_i_o_n_
These transactions cover the administration of those text
areas that are filled in with the function "print output"
(e.g. invoices - cf. 5.11).
Primitive The functions are primitive and easy to handle. Apart from
Flexible that, they are flexible, as a more developed control can be
implemented in the adaption.
Text areas The administration in the Skeleton Program is confined to
control those text areas that are to be printed on the prin-
ters and the necessary communication with DUETCOM (by
TELEOP).
Not printers There is thus no administration of the printers as such, and
neither of the paper type they have mounted.
From among the 2 kinds of printers which DUETCOM administers
(see the TELEOP documentation), the Skeleton Program is pri-
marily based on "selective" (and seperate) printers. See also
section 3.2 (output).
2 transactions The Skeleton Program has 2 transactions:
UOR, print out command : Print a text area mentioned by
name or output type at a printer.
UAC, print out acceptance: Accept an UOR for a certain output
type. \f
5_._1_0_ _ _P_r_i_n_t_ _O_u_t_ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_
P_r_i_n_t_ _O_u_t_ _C_o_m_m_a_n_d_ _(_U_O_R_)_
The transaction effects the print out of a text area.
Text area In case that the text area is identified by output type, the
identifiedSKP fetches the output form administration record by means
by output of the key determined in adp 1. The simplest way is to read
type in the key from the transaction, but it may also be fixed
(programmed) or parameter selected (terminal dependent) or a
combination of both.
In adp 1 it can be decided whether the print out is to be
produced centrally or not (comm. variable centralconv). In
the first case the algol8 operation is executed, i.e. the
print area is renamed and a request for central convert is
displayed on the console. It is then the task of operator to
start the convert process (e.g. by means of a UOR command
including the area name). If the central convert is not
wanted, the algol7 operation is executed, i.e. the print out
area is converted by DUETCOM. The parameter printer inf (cf.
algol7 in the TELEOP manual) must be assigned with a legal
value in adp 2, thereby addressing the printer on which the
print out is demanded.
The only function that the SKP always executes is the fol-
lowing:
2 text areas 2 text areas have been described in the output form admini-
stration record: the first is filled in from "print output",
the second is being printed (or the print out has already
been accepted).\f
5_._1_0_ _ _P_r_i_n_t_ _O_u_t_ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_
Exchange of If the latest print out h_a_s_ _b_e_e_n_ accepted (by the UAC trans-
text areas action), this area is marked "after acceptance" and thus
terminated, and following print outs are printed from the
beginning of the other area. If the latest print out h_a_s_ _n_o_t_
b_e_e_n_ accepted, the UOR must be a repeat or resume transaction.
Text area Also a text area with a definite name can be printed out
identified without being attached to an output form administration re-
by name cord. In adp 1 parameters for the print out action are de-
termined, such as the name of the area, which e.g. can be read in
Central con- from the transaction. Thus the UOR transaction can be used for
vert print out at the system printer after a message about central
Test print convert, or for test print outs.
P_r_i_n_t_ _O_u_t_ _A_c_c_e_p_t_a_n_c_e_ _(_U_A_C_)_
Release of The purpose of the transaction is to release a text area
text area that has been printed. This is done by changing the state of
the second text area in the output form administration re-
cord. The transaction is to be used for text areas identi-
fied by output type in the UOR command.\f
5_._1_0_ _ _P_r_i_n_t_ _O_u_t_ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_
O_u_t_l_i_n_e_
(tegning 101)\f
5.10.1 P_r_i_n_t_ _O_u_t_ _C_o_m_m_a_n_d_
(Tegning 102)
\f
5_._1_0_._1_ _ _P_r_i_n_t_ _O_u_t_ _C_o_m_m_a_n_d_
(Tegning 103)
\f
5_._1_0_._1_ _ _P_r_i_n_t_ _O_u_t_ _C_o_m_m_a_n_d_
(Tegning 104)
\f
5_._1_0_._1_ _ _P_r_i_n_t_ _O_u_t_ _C_o_m_m_a_n_d_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Reading of an input line
Reading :From the input buffer
Writing :
Conditions for
activation : After interpretation of the line code
(adp 0)
Comm. variables: get _outp, get _print, and centr _conv
call: 0 (not wanted)
return: 0,1
Use : Reading of information and alteration of
the communication variables
Block reference: B (adp _block _15,1)
Next adaption
point : Adp 2 or exit \f
5_._1_0_._1_ _ _P_r_i_n_t_ _O_u_t_ _C_o_m_m_a_n_d_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Assign printer name
Reading :
Writing :
Conditions for
activation : The value of the communication variable is
one.
Comm. variables: printer _inf
call: l6
return: printer name
Use : Assignment of printer name by means of
printer index
Block reference: B (adp _block _15,2)
Next adaption
point : Exit \f
5.10.2 P_r_i_n_t_ _O_u_t_ _A_c_c_e_p_t_a_n_c_e_
(tegning 107)\f
5_._1_0_._2_ _ _P_r_i_n_t_ _O_u_t_ _A_c_c_e_p_t_a_n_c_e_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Reading of an input line
Reading :From the input buffer
Writing :
Conditions for
activation : After interpretation of the line code
(adp 0)
Comm. variables:
Use : Reading of information
Block reference: B (adp _block _15,3)
Next adaption
point : Exit \f
5.11 P_r_i_n_t_ _O_u_t_p_u_t_
L_i_s_t_ _o_f_ _c_o_n_t_e_n_t_s_P_a_g_e_
Print Output (introduction)131
Flow Diagram133
Adaption Point Description135 \f
5_._1_1_ _ _P_r_i_n_t_ _O_u_t_p_u_t_
Form print The function "print output" is the Skeleton Program routine
outswhich activates the form print outs from TELEDATA (invoices,
delivery notes, order confirmations, etc.). These (print
outs) are written in text areas where they are accumulated
until they are to be printed (cf. Print Out Administration).
Print channel The printing is done in the adaption at print channel 1.
1
(At print channel 2 the other type of print outs occur - that
is, those that are written on the terminal - answer to inqui-
ries, errors, etc. They have been described elsewhere (see
section 5.4 and section 6). Print outs from TELEOP, DUETCOM,
etc. are not described in this manual).
Activated from Print output is activated in the Skeleton Program under 4
other other functions:
transactions
- last in the order voucher end (section 5.5)
- last in the erase order (section 5.5)
- last in the invoice voucher end (section 5.6)
- last in the account entry voucher end and in the
deb/cred entry scan (section 5.9)
The terminal The printing is done from records in the terminal area. These
area is records are sorted and then scanned. The set used for the
scanned scan is set 23 but another (new) one can be selected in the
adaption, if wanted.
The actual scan is placed in adaption point 4 because of
flexibility and economy in block calls. The printing may fill
up to 2 blocks, adaption block 13 and adaption block 14, but
all the adaption points are in adaption block 13.\f
5_._1_1_ _ _P_r_i_n_t_ _O_u_t_p_u_t_
A scan in An outline of the scan (adaption point 4):
the adaption
next scanning_set
while sodaspec = 0 do.
"print output from the record"
next scanning_set
The area, on which is printed, has been determined from the
output type which is selected in adaption point 2. Then the
Output form Skeleton Program fetches the corresponding output form admi-
administration nistration record where the text area has been described
with the name and position, from which it is to be written.
The algol operation 5 "opens" and positions in the area and
after the printing, algol operation 6 "closes" (and saves
the position).
Text area To each output type corresponds a text area in which prin-
per output ting is conducted (furthermore there is a text area which is
typebeing printed). The output types are specific for each user
User specific and all the user>s terminals can thus make use of them.
All of the above algorithm (define output type and sorting
parameters, sort terminal area, scan terminal area and
print) can be repeated a couple of times so that by one
execution of "print output" (and one transaction) several
different print outs can be made.\f
5_._1_1_ _ _F_u_n_c_t_i_o_n_:_ _P_r_i_n_t_ _O_u_t_p_u_t_
(tegning 114)\f
5_._1_1_ _ _F_u_n_c_t_i_o_n_:_ _P_r_i_n_t_ _O_u_t_p_u_t_
(tegning 115)\f
5_._1_1_ _ _P_r_i_n_t_ _O_u_t_p_u_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Assign the control parameters
Reading :
Writing :
Conditions for
activation :
Comm. variables: no _of _scans
call: 1
answer: '=0
Use : Assignment of the comm. variable.
Assign possible scanning sets or set
restrictions.
Block reference: B (adp _block _13,1)
Next adaption
point : Adp 2 or exit \f
5_._1_1_ _ _P_r_i_n_t_ _O_u_t_p_u_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Determine the output type
Reading :
Writing :
Conditions for
activation : By each scan
Comm. variables:
Use : Assignment of the output type before the
current scan
Block reference: B (adp _block _13,2)
Next adaption
point : Adp 3 \f
5_._1_1_ _ _P_r_i_n_t_ _O_u_t_p_u_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3
Designation : Assign the sorting parameters
Reading :
Writing :
Conditions for
activation : After fetching the output form administra-
tion record
Comm. variables: sort_wanted
call: 0 (not wanted)
answer: 0,1
Use : Assignment of parameters for the sorting
procedure (algol 1)
Block reference: B (adp _block _13,3)
Next adaption
point : Adp 4 \f
5_._1_1_ _ _P_r_i_n_t_ _O_u_t_p_u_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 4
Designation : Scan the terminal area
Reading :
Writing :
Conditions for
activation : After a possible sorting, after opening
the text area, and after selection of print
channel 1.
After initialization of the scanning set.
Comm. variables:
Use : Scan of the terminal area.
Printing of the output.
Block reference: B (adp _block _13,4)
Next adaption
point : Adp 2 or exit \f
6. E_r_r_o_r_ _P_r_o_c_e_s_s_i_n_g_
L_i_s_t_ _o_f_ _C_o_n_t_e_n_t_s_P_a_g_e_
Introduction 140
6.1 Error Reactions from the DUET system 141
6.2 Error Reactions from the DUET program 142
6.3 Error list - Skeleton Program Data Errors 143
\f
6_._ _ _E_r_r_o_r_ _P_r_o_c_e_s_s_i_n_g_
I_n_t_r_o_d_u_c_t_i_o_n_
In this section the error reactions in the running TELEDATA
system are described.
Five types of errors may arise in the running situation:
1. DUET system errors.
Described in the DUET manual, cf. the reference list
in section 1.
2. DUET programming errors.
Described in the DUET manual, cf. the reference list
in section 1.
3. DUET data errors.
Described in the DUET manual, cf. the reference list
in section 1. These error messages can be redefined,
e.g. if they are required in a different language.
4. Skeleton Program data errors, cf. section 6.3.
5. Adaption data errors, cf. the User>s Handbook.
The error processing has been worked out considering the
fact that the running TELEDATA system is an on-line system
where the user receives a prompt reply about a transaction
and so may correct any possible erroneous transaction at
once. No special processing for batch runs, if any, has been
implemented.\f
6.1 E_r_r_o_r_s_ _f_r_o_m_ _t_h_e_ _D_U_E_T_ _S_y_s_t_e_m_
P_r_i_n_t_ _o_u_t_ _o_f_ _e_r_r_o_r_ _m_e_s_s_a_g_e_s_ _f_r_o_m_ _t_h_e_ _D_U_E_T_ _s_y_s_t_e_m_
The DUET interpreter itself makes certain that the DUET sys-
tem errors (error type 1) and the DUET programming errors
(error type 2) are printed on the primary output and that
the message about the occurrence of an error is given to the
DUET data error procedure.
DUET data errors (error type 3) will be printed at channel
2, which has been selected in the Skeleton Program and the
DUET data error procedure will also, when it receives a mes-
sage about a system - or a programming error, print an error
message at channel number 2.
The DUET data error procedure is adaptable as for the writ-
ten text so that error messages can be printed in the local
language. The text is inserted by a re-interpretation of
TELEOP.
About the processing of the primary output and channel num-
ber 2: see the TELEOP MANUAL.\f
6.2 E_r_r_o_r_s_ _f_r_o_m_ _t_h_e_ _D_U_E_T_ _P_r_o_g_r_a_m_
S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _E_r_r_o_r_s_ _(_E_r_r_o_r_ _T_y_p_e_ _4_)
The Skeleton Program data errors include all errors registe-
red by the Skeleton Program.
A print out of error messages is performed at the user ter-
minal from block 22 (installation adaption) where the text
can be adapted to the current language.
The reaction to different Skeleton Program data errors ap-
pears from the error list in section 6.3.
A_d_a_p_t_i_o_n_ _D_a_t_a_ _E_r_r_o_r_s_ _(_E_r_r_o_r_ _T_y_p_e_ _5_)
Adaption data errors include all errors registered in the
adaption.
The print out of error messages is performed at the user
terminal and should be programmed in the block where the
error has been registered.\f
6.3 E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _E_r_r_o_r_s_
The error list of the Skeleton Program data errors contains,
for each error that is registered by the Skeleton Program,
the following information:
1. An error number which refers to the entry point in
block 22 from where the error text is printed out.
2. The error text which is printed out at the user>s
terminal, including the error number mentioned under
1 and perhaps a line code.
3. One or more block numbers and one or more DUET ope-
ration numbers for identifying where in the Skeleton
Program the error has arisen. If the line code is
indicated, this will be decisive of which block and
DUET operation the error has been called from.
4. The Skeleton Program>s reaction to the current er-
ror. In this case the line code will also decide
which reaction will be selected out of several pos-
sible reactions.
5. Messages, if any.\f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _E_r_r_o_r_s_
21 ILLEGAL CODE code'line_code'
O--: 4, D183 (D166)
: SKP returns to P1 (D160) and continues normally from
there.
R--: 4, D245 (D207, D235)
: SKP returns to P1 (D200) and continues normally from
there.
N--: 4, D345 or 4, D245 (D307 or D235)
: SKP returns to P1 (D300) and continues normally from
there.
?--: 5, D25
: SKP returns to P0 and the control is given to TELEOP.
Comments:
O-- : = Create structure list
R-- : = Update structure list
N-- : = Delete structure list
?-- : = Structure list inquiries
22 PART ident'RECORD DOES NOT EXIST line _code'
0--: 4, D185 (170)
: Normal continuation of the operating sequence
23 ident'MASTER MUST NOT BE DELETED line _code'
N--: 4, D140, D141, D142, D143
: SKP returns to P0 and the control is given to
TELEOP.\f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _E_r_r_o_r_s_
24 LIST RECORD DOES NOT EXIST
R--: 4, D255 (D213)
: like R--
?--: 5, D118, (D117)
: The key is printed, SKP returns to P1 (D133) and
is terminated normally.
25 TERMINAL IN ILLEGAL STATE
: 1, D115
: SKP returns to P0 and the control is given to TELEOP.
26 TERMINAL BLOCKED
: 1, D130
: Like error no 25
: Only >logout> will be accepted.
27 TERMINAL IN ILLEGAL STATE state'
: 1, D155
: SKP returns to P2 (D10) and continues normally with
the "terminate transaction" (D300).
28 UNKNOWN LINE CODE line code'
: 1, D260
: SKP continues normally with the "terminate
transaction" (D300).
29 ILLEGAL PASSWORD password'
: 2, D31
: SKP returns to P0 and the control is given to TELEOP.\f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _e_r_r_o_r_s_
30 UNKNOWN TESTMODE testmode'
: 1, D412
: SKP returns to P0 and the control is given to TELEOP.
31 ILLEGAL VARIABLE NAME testvarcode'
: 1, D423
: SKP returns to P0 and the control is given to TELEOP.
32 INPUT LINE INCOMPLETE
: 1, D413
: SKP returns to P0 and the control is given to TELEOP.
33 UNKNOWN TRANSACTION linecode'skplinecode'
: 2, D5
: The block is terminated normally.
34 UNKNOWN INFORMATION CODE informationcode'
: 1, D415
: SKP returns to P0 and the control is given to TELEOP.
35 PRINTOUT NOT OK
: 6, D900 (D258, D540)
: SKP returns to P1.
36 PRINTOUT ILLEGAL STATE: state'further explanation'
: 6, D900 (D258)
: SKP returns to P1. \f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _e_r_r_o_r_s_
37 NO ACCOUNT-ENTRY LINES CONNECTED
: 8, D263 (D262), 8, D623 (D621)
: 9, D392 (D390)
: SKP continues normally in the operating sequence.
38 PRINTOUT REJECTED
: 6, D900 (D380)
: SKP returns to P1.
40 DEB/CRED RECORD PROTECTED line_code'
A : 8, D130 (D102, D150, D250)
: SKP returns to P1 and the block is terminated
normally.
FA-FI: 9, D120 (D110)
: SKP returns to P1 and the block is terminated
normally.
FV : 9, D620 (D603)
: SKP returns to P1 and the block is terminated
normally.
FL-FO: 8, D130 (D102)
: SKP returns to P1 and the block is terminated
normally.
Comments:
The error may also arise in the deb/cred - and order
invoicing with the corresponding line codes (F--).\f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _e_r_r_o_r_s_
41 ORDER RECORD PROTECTED line_code'
AD-AF: 8, D132 (D150)
: SKP returns to P1 and the block is terminated
normally.
AK-AM: 8, D132 (D250)
: Like AD-AF.
FP-FV: 9, D130 (D284)
: SKP returns to P1 and the block is terminated
normally.
Comments:
See comments to error 40.
42 INDICATED ORDER LINE NOT PARENT serial_no'
AN-AQ: 8, D412 (D415)
: SKP returns to P1 and the block is terminated
normally.
FL-FO: 8, D412 (D415)
: SKP returns to P1 in block 9 and the block is termi-
nated normally.
DBB : 8, D412 (D415)
: SKP returns to P1 in block 7 and the block is termi-
nated normally.
FP,FV: 9, D299 (D298)
: SKP continues normally in the operating sequence.
Comments:
See comments to error 40.\f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _e_r_r_o_r_s_
44 PART ORDER LINES MISSING line_code'
AR-AU: 8, D780 (D730 and D760)
: SKP continues normally in the operating sequence.
FP-FV: 9, D362 (D355 and D361)
: SKP continues normally in the operating sequence.
Comments:
See comments to error 40.
45 ORDER LINE MISSING odl serial no'
: 8, D770 (D415, D700)
: SKP continues normally in the operating sequence.
Comments:
Called from cancellation or order line correction.
26 NO VOUCHER LINES IN THE DEMANDED INTERVAL
first_line'last _line'
: SKP returns to P1 in block 7 or the block from where
block 7 has been called.
Comments:
Called from "display voucher", which can be called
from several places.\f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _e_r_r_o_r_s_
47 VOUCHER START DOES NOT EXIST line_code'
: 8, D220 (D200), 8, D612 (D608), 9, D385 (D384)
: 9, D418 (D417), 9, D478, 7, D160
: SKP returns to P1.
Comments:
One line code may cause a call of the error from
several blocks.
48 ORDER NOT FOUND
AD-AE: 8, D153 (D150)
: SKP returns to P1 and the block is terminated
normally.
FA-FF: 9, D281 (D280)
: SKP returns to P1 and the block is terminated
normally.
49 REPEAT NOT ALLOWED
: 6, D900 (D330)
: SKP returns to P1
50 RESUME NOT ALLOWED
: 6, D900 (D340)
: SKP returns to P1
51 NO OUTP.FORM PRESENT AT REP/RES
: 6, D900 (D350)
: SKP returns to P1 \f
6_._3_ _ _E_r_r_o_r_ _L_i_s_t_:_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_a_t_a_ _e_r_r_o_r_s_
52 SPECIFIED PRINTER DOES NOT EXIST
: 6, D900 (D300, D350)
: SKP returns to P1
53 ILLEGAL PRINT FUNCTION
: 6, D900 (D320, D370)
: SKP returns to P1
54 TEXTFILE NOT FOUND
: 6, D900 (D370)
: SKP returns to P1
55 NO RESOURCES FOR RENAME
: 6, D900 (D370)
: SKP returns to P1
56 CENTRAL CONVERT NOT SUCCESFUL
: 6, D900 (D370)
: SKP returns to P1
57 PRINTER BUSY
: 6, D900 (D300, D390)
: SKP returns to P1
58 PRINT NOT OK - ACCEPT REJECTED
: 6, D900 (D540)
: SKP returns to P1
59 PRINTOUT NOT TERMINATED
: 6, D900 (D540)
: SKP returns to P1\f
7. O_p_e_r_a_t_i_n_g_ _g_u_i_d_e_
L_i_s_t_ _o_f_ _C_o_n_t_e_n_t_s_P_a_g_e_
Introduction 153
Outline of Compilations 154
7.1 Translation of the DB Description 156
7.2 Translation of the SODA-LD Description 158
7.3 Translation of the DUET Program 160
7.4 Translation of TELEOP 162
7.5 Test Runs 164
\f
7_._ _ _O_p_e_r_a_t_i_n_g_ _G_u_i_d_e_
I_n_t_r_o_d_u_c_t_i_o_n_
In this section is described the execution of the various
compilations in connection with the establishing of a new
TELEDATA system - e.g. by inserting a new adaption. The sec-
tion contains both an outline of the compilation sequence
and a description of each compilation job, illustrated by
examples. For further details concerning the systems invol-
ved - including possible error reactions - see the respecti-
ve manuals - cf. the reference list, section 1.
Finally, 2 examples of test jobs for off-line execution are
given.\f
7_._ _ _O_p_e_r_a_t_i_n_g_ _g_u_i_d_e_
O_u_t_l_i_n_e_ _o_f_ _C_o_m_p_i_l_a_t_i_o_n_s_
(tegning 145)\f
7_._ _ _O_p_e_r_a_t_i_n_g_ _g_u_i_d_e_
O_u_t_l_i_n_e_ _o_f_ _C_o_m_p_i_l_a_t_i_o_n_s_
T_E_L_E_O_P_
(tegning 146) \f
7.1 T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _D_B_ _D_e_s_c_r_i_p_t_i_o_n_
E_x_a_m_p_l_e_:_
job teledata 1 28xxxx time 15 0 size 100000,
temp disc 1500 25 perm dkxxxxxx 200 1
dblist = set 1
database80 section.102,
descrip.descripfile,
sysdok.sysdokfile,
list.yes,
listout.dblist,
run.init
convert dblist
finis
Comments:
The files descripfile and sysdokfile exist permanently
on the disc in this job. A description of all the para-
meters to the call of the db translator and possible
error print outs from the latter exists in the DATABA-
SE80 manual (cf. the reference list).
Overleaf the parameters of the standard job are
described briefly.\f
7_._1_ _ _T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _D_B_ _D_e_s_c_r_i_p_t_i_o_n_
section.102
Have to be included. 102 indicates the number of the
section in the sysdok file where the db-description has
been stored.
descrip.descripfile
May be omitted as the standard name is used. Descripfile
is the name of the file where the translated db-descrip-
tion is to be stored.
sysdok.sysdokfile
May be omitted as the standard name is used. Sysdokfile
is the name of the file where the db-description has
been stored by means of the SYSDOK system (cf. referen-
ce list).
list.yes
May be omitted. Includes listing of the translated
sysdok section.
listout.dblist
May be omitted. Dblist is the name of the file in which
the listing is to be placed.
run.init
Indicates that a new db-file initialization is wanted.
The catalogue entry for the db-file (in this case the
descripfile) must exist. This parameter has to be in-
cluded in the first translation of a db-description.\f
7.2 T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _S_O_D_A_-_L_D_ _D_e_s_c_r_i_p_t_i_o_n_
E_x_a_m_p_l_e_:
job teledata 2 28xxxx time 14 0 size 125000,
buf 10 area 1 perm 1 perm dkxxxxxx 300 2
sodalist = set 200 dkxxxxxx
sodald ldtext.ldtext,
descrip.descripfile,
section.103.1,
list.yes,
listout.sodalist,
vardecl.vardecl
scope user sodalist
finis
Comments:
In this job the files: descripfile, ldtext and vardecl
exist permanently on disc.
All parameters for the call of the SODA-LD translator
and error print outs from this, are described in the
SODA manual (cf. the reference list).
Overleaf a short explanation of the parameters used in
the example is given.\f
7_._2_ _ _T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _S_O_D_A_-_L_D_ _D_e_s_c_r_i_p_t_i_o_n_
ldtext.
indicates the name of the area from which the source
text is to be read.
If the source text is placed in a sysdok file, this is to
be specified with a "sysdok" parameter and "ldtext" must
not occur.
descrip.descripfile
Indicates the name of the file in which a correctly trans-
lated database description has been stored and in which
the new translated ld-description is to be stored. The
parameter may be omitted in this case as descripfile is
the standard name.
section.103.1
Indicates the section in the description file in which
the interpreted ld-description is to be inserted.
list.yes
Causes the creation of an edited listing on a discarea.
listout.sodalist
Indicates the name of the area on which the edited lis-
ting is to be placed. If the area does not exist, it
will be created as a temporary file, which is printed
automatically on the local printer.
varedecl.vardecl
Indicates that an automatically generated declaration
of the field variables with their respective initializ-
ation is wanted for TELEOP. "Vardecl" is the name of
the area in which the result is stored. If the area
does not exist, it is created temporarily. This para-
meter is necessary if the variable section has been
changed (after this, both TELEOP and the DUET program
are to be re-translated).\f
7.3 T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _D_U_E_T_ _P_r_o_g_r_a_m_
E_x_a_m_p_l_e_:
job teledata 3 28xxxx time 10 0 size 125000,
perm dkxxxxxx 300 1
clear user teleprg
teleprg = set 100 dkxxxxxx
scope user teleprg
duetabler duettext.teletrim,
init.user,
descrip.descripfile,
oldduet.oldteleprg,
newduet.teleprg,
change.55.57
finis
Comments:
All parameters for the call of the DUET translator and error
print outs from this, have been described in the DUET manual
(cf. the reference list).
The parameters for the standard job are described below.
duettext.teletrim
Indicates the name of the text area from which the DUET
program is to be read. If the DUET program is placed in
a sysdok file, this is indicated by a sysdok parameter
(see the DUET manual).
init.user
Indicates the initials of the person who has activated
the DUET translation.\f
7_._3_ _ _T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _D_U_E_T_ _P_r_o_g_r_a_m_
descrip.descripfile
Indicates the name of the description file in which the
interpreted ld-description is stored. The parameter may
be omitted in this case as descripfile is standard.
oldduet.oldteleprg
Indicates the name of the "old" duet file. Necessary if
the newduet parameter is indicated.
newduet.teleprg
Indicates the name of the "new" duet file. If this
parameter is omitted, the oldduet parameter is not to
be indicated either and no new duet file will be crea-
ted. The translation run is thus reduced to be a
syntactic check of the indicated DUET blocks.
change.55.57
Indicates the duet blocks (block 55 and 57) that are to
be translated.
This parameter is only allowed if both oldduet and
newduet are indicated
Instead of change, you may indicate one of the parame-
ters: insert, delete or translate. The insert parameter
causes the indicated blocks to be inserted in the duet
file. Newduet must be indicated. The delete parameter
causes the indicated blocks to be removed from the duet
file. Oldduet - newduet must be indicated. The transla-
te parameter causes the indicated blocks to be checked
syntactically but not inserted in the duet file.\f
7.4 T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _T_E_L_E_O_P_
E_x_a_m_p_l_e_:_
job teledata 4 28xxxx time 8 0 size 60000,
area 12 buf 12 perm dkxxxxxx 500 1,
temp disc 2400 24
i prim; translate the print system primula
i sdtrans; translate the soda transfer procedure
i tduetcode; translate the duetinterpreter
teleop = set 480 dkxxxxxx
teleop = algol teleoptext message.yes
scope user teleop
finis
Comment:
In this job, the presence of quite a few algol text areas
are presupposed. They are all delivered together with the
system, but some can be changed or replaced as a matter of
course.
The following texts are never to be changed:
prim : contains the slangcoded primula system
procedures
duettext 1 : the DUET interpreter procedures
duettext 2 : the DUET interpreter
sodatext 1 : the SODA interpreter
sodatext 2 : the SODA interpreter
sodatext 3 : the SODA interpreter
sodafields : initialization in the descripfile
statustext : status initialization
paramtext : reading in of fp-parameters
sdtrans : contains the slangcoded soda transfer
procedure
tduetcode : contains a part of the duetinterpreter,
slangcoded \f
7_._4_ _ _T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _T_E_L_E_O_P_
teleoptext : the algol "frame"
The following texts are changed currently:
newaktt : algol operations, DUET-ALGOL; here it is
possible to add new operations in ALGOL.
userrortext : errortexts concerning the algol operati-
ons.
vardecl : is created by the SODA-LD translator
and is changed each time the variable
declarations have been altered.\f
7.5 T_e_s_t_ _R_u_n_s_
; job for initialization of TELEDATA>s database
job teleinit 28xxxx size 120000 time 8 0,
perm dkxxxxxx 2500 30 temp disc 2500 25 outp 100000
mode list.yes
; create files to be used by reorg80
reotab = set 1 disc
newformat = set 1 disc 0 0 0 20.4
; any old files are removed
clear user debcred items orders tdadmin userinf,
dcstructure partslist orderlines accentry orderref,
termarea
; create and scope new files
tdadmin = set 1 dkxxxxxx
debcred = set 1 dkxxxxxx
items = set 1 dkxxxxxx
userinf = set 1 dkxxxxxx
orderlines = set 1 dkxxxxxx
orders = set 1 dkxxxxxx
accentry = set 1 dkxxxxxx
partslist = set 1 dkxxxxxx
dcstructure = set 1 dkxxxxxx
orderref = set 1 dkxxxxxx
termarea = set 1 dkxxxxxx \f
7_._5_ _ _T_e_s_t_ _R_u_n_s_
scope user debcred items orders tdadmin userinf dcstructure
partslist orderlines accentry orderref
; initialization of the file heads
reanalyse init.yes
descripfile = reinsert
; create the necessary areas for the logical file
; maintenance
rpl00 = copy 0
rpl01 = copy 0
rpl02 = copy 0
prinz1 = copy 0
prinz2 = copy 0
; create and initialize the telestatus
telestatus = set 1 dkxxxxxx
telestatus clear.all logmode.0 safemode.1 disclog.logfile
func1
; the logical file maintenance is executed and
; customers, items and terminal
; administration records are created
; so that the files are
; ready for the real test run
teleop input.dbtransact status. statusfile duetfile.duetfile,
descrip.descripfile ldsection 103.1 stacco.no log.no\f
7_._5_ _ _T_e_s_t_ _R_u_n_s_
; from now on the newly initialized files
; are saved on user level, ready to be used
; by the following test runs
t1 = set 1 dkxxxxxx
t2 =set1dkxxxxxx
t3 =set1dkxxxxxx
t4 = set 1 dkxxxxxx
t5 = set 1 dkxxxxxx
t6 = set 1 dkxxxxxx
t7 = set 1 dkxxxxxx
t8 = set 1 dkxxxxxx
t9 = set 1 dkxxxxxx
t10 = set 1 dkxxxxxx
t11 = set 1 dkxxxxxx
; move the contents of the initialized files to the
; safety files
t1 = move debcred
t2 = move items
t3 = move orders
t4 = move tdadmin
t5 = move userinf
t6 = move dcstructure
t7 = move partslist
t8 = move orderlines
t9 = move accentry
t10 = move orderref
t11 = move termarea
scope user t1 t2 t3 t4 t5 t6 t7 t8 t10 t11
; now the newly initialized files have been generated
; they can, in future, be moved from the test files
; if one wants to start all over again.
finis\f
7_._5_ _ _T_e_s_t_ _R_u_n_s_
; example of an off-line test job with max 2 terminals
job teletest 1 28xxxx size 120000 time 10 0,
area 36 buf 24 perm dkxxxxxx 400 4 temp disc 3600 24,
outp 200000
mode list.yes
; reply and print areas are zerofilled
rpl00 = copy 0
rpl01 = copy 0
rpl02 = copy 0
prinz1 = copy 0
prinz2 = copy 0
; create new terminal areas and output areas
; for invoicing and scope
clear user wrkfil01 wrkfil02 inv01a inv01b inv02a inv02b
wrkfil01 = set 1 dkxxxxxx 0 0 0 20.4
wrkfil02 = set 1 dkxxxxxx 0 0 0 20.4
inv01a = set 1 dkxxxxxx
inv01b = set 1 dkxxxxxx
inv02a = set 1 dkxxxxxx
inv02b = set 1 dkxxxxxx
scope user wrkfil01 wrkfil02 inv01a inv01b inv02a inv02b
; the safety copy of the data is moved to the test files
debcred = move t1
items = move t2
orders = move t3
tdadmin = move t4
userinf = move t5
dcstructure = move t6 \f
7_._5_ _ _T_e_s_t_ _R_u_n_s_
partslist = move t7
orderlines = move t8
accentry = move t9
orderref = move t10
termarea = move t11
; create and initialize telestatus
statusfile = set 10 disc
telestatus clear.all logmode.0 safemode.3 func.1
; introductory moves terminated
; the test is started
teleop input.testinput status.statusfile ldsection.103.1,
duetfile.duetfile descripfile.descripfile log.no
; test the achieved results
list rpl01; print out reply area for terminal no 1
list rpl01; print out reply area for terminal no 2
list testinput; print out the processed transactions
; now the testrun
; has been terminated, please
; study your output
; before the next run
finis
Note: Another description of how to run a TELEDATA system in
batch mode is given in the SYSTEM80 - TELEDATA TOOL
COURSE manual (RCSL 21-T005).\f
8. R_e_l_a_t_i_o_n_s_ _t_o_ _O_t_h_e_r_ _S_y_s_t_e_m_s_
L_i_s_t_ _o_f_ _C_o_n_t_e_n_t_s_:P_a_g_e_
Introduction 170
8.1 TELEOP 171
8.2 DUET Interpreter 176
8.3 TD Utility 178
8.4 SYSTEM80 Batch Programs 180
8.5 Other Systems 184
\f
8_._ _ _R_e_l_a_t_i_o_n_s_ _t_o_ _O_t_h_e_r_ _S_y_s_t_e_m_s_
I_n_t_r_o_d_u_c_t_i_o_n_
The Skeleton Program is closely related to the operative
system TELEOP and the virtual interpreter that executes the
DUET program, the DUET interpreter. Even though these sys-
tems are placed in the same algol program they can be pro-
cessed seperately.
The use of the SYSTEM80 batch programs in connection with TD
is mentioned, as a brief outline of known possibilities and
problems is given.
Finally "other" systems are mentioned. \f
8.1 T_E_L_E_O_P_
In this section is given an outline of those variables that
are used for the TELEOP-SKP communication, and an abstract
of the TELEOP actions respectively before, during, and after
the processing of each transaction. For further information
see the TELEOP manual.
C_o_m_m_u_n_i_c_a_t_i_o_n_ _V_a_r_i_a_b_l_e_s_:_ _T_E_L_E_O_P_ _-_ _S_K_P_
The variables are declared in the SODA-LD, where they are
all marked with an *.
Apart from the mentioned variables, certain variables are
used as parameters, calling the algol operations.
Variables which are not moved in any set:
V70 no_of_ports and
V71 current_port:
determines the number of the port for the
current terminal
V74 printer_no
by "printer transactions" (see section 3).
V180 error number
contains the error number, if any, which is
logged by Teleop in the LOGFILE.
Variables which are moved in set 11:
They are used by TELEOP in the creation of the very first
terminal administration record, which is created from the
"operator terminal".\f
8_._1_ _ _T_E_L_E_O_P_
V190 startposition : contains the startposition in a
text file after an erronous print
out.
V327 adm_ident1
V328 adm_type and
V329 adm_ident2 : are all key variables for set 11.
V610 user_no : is user number at this terminal.
V663 terminal-type : indicates whether it is an admi-
nistrative terminal.
Variables which are moved in set 14:
They are all (except the keys and the user number) moved
back and are thus updated by TELEOP.
V302 adm_user_no
V577 adm14_key_1,
V578 adm14_key_2, and
V579 adm14_key_3: key variables inserted in the
head of log records
V644 adm_term_blocking:
blocking, is assigned in case of
errors in the sorting.
Description of the terminal area:
V582 adm_ta_area_name:
name
V584 adm_ta_segmpos
Description of the reply area (print channel 2).
V586 adm_rp_area_name:
name
V588 adm_rpa_segmpos
V589 adm_rpa_bytepos:
eof - marking \f
8_._1_ _ _T_E_L_E_O_P_
T_E_L_E_O_P_ _A_c_t_i_o_n_s_ _B_e_f_o_r_e_ _t_h_e_ _S_K_P_ _i_s_ _A_c_t_i_v_a_t_e_d_
The following actions are executed each time a transaction
is read and before the control is handed over to the DUET
interpreter which executes the SKP.
The sequence of these points does not correspond with the
real execution.
- The terminal administration record is fetched (get
S14)
- Print channel 2 (reply-zone) is "opened" and positio-
ned. When running in the on-line mode, the positio-
ning starts from the beginning; when running in the
off line mode the positioning starts at the eof-mark
(continued writing).
- Print channel1 (output zones) are n_o_t_ opened (cf.
section 5.11, print output).
- DUET>s variables are n_o_t_ zerofilled (only by starting
TELEOP, that is, before the first transaction).
- DUET>s print channel = 1 (changed in the SKP).
- DUET>s error print out channel = 0 (current out, is
changed in SKP to 2 for data errors).
- DUET>s test variables are n_o_t_ changed.
- DUET>s test print out channel = 0 (current out).
- The current terminal area is "opened" and positioned,
ready to use DUET>s record operations.\f
8_._1_ _ _T_E_L_E_O_P_
T_E_L_E_O_P_ _A_c_t_i_o_n_s_ _D_u_r_i_n_g_ _t_h_e_ _E_x_e_c_u_t_i_o_n_ _o_f_ _t_h_e_ _S_K_P_
- Logging of record images: each time the DUET operati-
ons >put> and >delete> are executed, the current re-
cord may be logged on the LOGFILE.
- The first time the records are logged in a transacti-
on, the information in the status area about the
"current transaction number" is changed, and regis-
ters that the database is now being updated.
- Algol operations (DUET - ALGOL). These are originally
independent but some of the operations use TELEOP>s
procedures, e.g. message to DUETCOM about the print
out of a text area (convert).
T_E_L_E_O_P_ _A_c_t_i_o_n_s_ _a_f_t_e_r_ _T_e_r_m_i_n_a_t_i_n_g_ _t_h_e_ _S_K_P_
It should be pointed out that these actions are executed
without any regard to how the execution of the SKP (actual-
ly, the DUET program) has proceeded. The state is thus only
characterized by the fact that the DUET interpreter has
terminated the execution of the DUET-program.
- Replies in the reply zone are only processed if some-
thing has been written. When running the program in
on-line mode the text is printed on the terminal by
DUETCOM (short text: interrupt message, long text:
convert message). By running the program in off-line
mode the end position is saved in the terminal admi-
nistration variables.
- The terminal is terminated, i.e. the new eof position
is saved in the terminal administration variables. \f
8_._1_ _ _T_E_L_E_O_P_
- The terminal administration record is moved back with
put S14.
- All record transfers to the database are terminated
(i.e. the buffers are emptied so that the records, if
any, are forced out on the disc).
- The information in the status area about the "termi-
nated transaction number" is updated and registers
that the database is no longer being updated.\f
8.2 D_U_E_T_ _I_n_t_e_r_p_r_e_t_e_r_
This interpreter executes the DUET program and the close re-
lations between them should be obvious. Here, however, 2
points should be mentioned where the relations are not
obvious.
E_r_r_o_r_ _P_r_i_n_t_ _O_u_t_s_ _i_n_ _t_h_e_ _D_U_E_T_ _I_n_t_e_r_p_r_e_t_e_r_
As it has been described in section 6 there are 3 types of
errors: data errors (from read and get), programming errors
and system errors.
As it has been mentioned above (8.1), a print channel is
initialized to all 3 types of errors before the SKP is acti-
vated.
SKP selects in the start print channel 2 for data errors, so
that error print outs from the DUET interpreter ends up in:
data errors :channel 2
programming errors:current out + channel 2
system errors :current out +channel 2
For programming - and system errors the print out (the actu-
al text) is standardized, but for data errors it can be
changed (for example to a different language) by means of
corrections made in the Algol text that is used for the
Algol translation of TELEOP. This contains the texts for the
DUET data error print outs (cf. section 7.4).
T_e_s_t_ _P_r_i_n_t_ _O_u_t_s_ _f_r_o_m_ _t_h_e_ _D_U_E_T_ _I_n_t_e_r_p_r_e_t_e_r_
Test print can be activated by:
- parameters used in the call of the TELEOP program\f
8_._2_ _ _D_U_E_T_ _I_n_t_e_r_p_r_e_t_e_r_
- in transactions from the operator>s terminal (see the
TELEOP manual)
- by assignment of the test variables in the adaption
(SKP does not execute these assignments)
For the meaning of the test variables, see the respective
manuals (DUET and TELEOP).
Note, that these test variables survive the transactions
until they are re-assigned or until TELEOP terminates the
execution.
In the SKP there has been implemented the possibility of
activating the test print outs selectively per terminal (and
route them out on the terminal) which is a powerful facility
during the testing of the adaption and the localization of
errors.
An exception is the vartrace test print out (cf. the DUET
manual) which cannot be selected seperately per terminal,
but will appear on all terminals when used.
Test print outs from the DUET interpreter are routed to
current out (contrary to primary out, cf. Algol and Boss
manuals), and this is not changed in the SKP. It may be
changed with "select" in the adaption.
Test print outs are always written on current out.
Finally we shall mention the fact that the SKP itself does
not possess built-in test print out facilities. \f
8_._3_ _ _T_D_ _U_t_i_l_i_t_y_
The TD utility programs are used for routine administration
of a TD system. They cover the functions: control of runs
including automatic recovery, tape administration and safety
dumping, safety checking of disc files, fast copying of disc
files, extraction of log information, extraction of database
information, statistical analysis of the processing of a
transaction, and restablishing.
The following TD utilities are available:
T_e_l_e_a_d_m_ (cf. ref. 12)
Controls the execution of a run by means of some user speci-
fied command files.
T_e_l_e_s_t_a_t_u_s_ (cf. ref. 12)
For handling of a status catalogue in the TD system.
T_e_l_e_t_a_p_e_ (cf. ref 12)
Maintains the tape catalogue of the TD system.
T_e_l_e_m_o_v_e_ (cf. ref. 12)
Performs a fast moving of any kind of file on disc.
T_e_l_e_c_l_o_c_k_ (cf. ref. 12)
Calculates the shortclock value or loads it from a file en-
try, stores the shortclock value in a file entry, or makes
comparisons with other file entries.
T_e_l_e_r_e_a_d_c_f_ (cf. ref 12)
Checks selected parts of a TD database. The program is not
dependent on a particular database configuration, but cer-
tain application dependent record counters are required.\f
8.3 T_D_ _U_t_i_l_i_t_y_
T_e_l_e_c_l_e_a_n_c_f_ (cf. ref 12)
Deletes erase-marked records in selected parts of the data-
base and adjusts certain counter fields, which must be
present.
T_e_l_e_l_o_g_e_x_ (cf. ref 12)
Extracts records from the LOGFILE generated by Teleop. The
relevant records are transformed into records readable by
the GENIUS system (cf. ref. 16)
T_e_l_e_d_b_e_x_ (cf. ref. 15)
Extracts information from the TD database and generates re-
cords readable by the GENIUS system (cf. ref. 16)
T_e_l_e_s_t_a_t_a_c_ (cf. ref 14)
Makes statistical analysis of the times and segment trans-
ports for the processing of transactions in a real-time
system.
T_e_l_e_r_e_e_s_ (cf. ref 13)
Reestablishes a TD database by means of the LOGFILE and a
safety copy of the database.\f
8.4 S_Y_S_T_E_M_8_0_ _B_a_t_c_h_ _P_r_o_g_r_a_m_s_
As there is only limited experience in integrating the
SYSTEM80 and TD, only the existing possibilities and known
problems are mentioned in this section.
D_a_t_a_b_a_s_e_
It should not provide any problems that the access system is
SODA and the programming language DUET, because the TD data-
base has been described in the DATABASE80 language just as
any S80 database.
The TD database resembles the S80 reference database at file
- and logical file level. The SKP makes certain demands on
the contents and the numbers of the record types (see secti-
on 2.1). The TD use of repeating field groups makes it appa-
rently impossible to share the database, but partly they can
be described as simple field groups (and the SKP can still
be used), and partly, the TD will, according to conventions
for a definite user, have a fixed amount of repetitions per
field group (repeatedly, no SKP demand).
The fact that TD is a multi-user system and SYSTEM80 a sing-
le user system, could cause problems but these are solved in
principle, if a whole TD system is used by a single user. It
remains to divide the responsibility for the maintenance of
the fields between TD and the SYSTEM80 modules. Besides, it
will be necessary to build up a common database which must
satisfy all the demands of the programs. \f
8_._4_ _ _S_Y_S_T_E_M_8_0_ _B_a_t_c_h_ _P_r_o_g_r_a_m_s_
O_p_e_r_a_t_i_n_g_ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_
Finally, the practical problem consisting of administrating
the daily operations (also by single-user systems) are to be
solved. Included in this is security and logging. TD uses
its own administration system, Teleadm, SYSTEM80 uses KAOS.
Teleadm is very closely related to TELEOP, it runs under S
and is administered by generating some previously programmed
rows of fp-commands. KAOS is a general operating ad-
ministration system; it runs under BOSS and is administered
by generating BOSS jobs from earlier adaptions that are sa-
ved in KAOS logical files. This is just to mention a few
practical differences. In short; the differences are large
and the problems have not been clarified.
C_o_m_m_u_n_i_c_a_t_i_o_n_
This covers the dispatching/receiving of information from
other systems, including the SYSTEM80 batch systems.
No special functions for this communication have been imple-
mented in the SKP. This must then be done in the adaption.
The communication from the TD can take place in 2 different
ways:
- by reading the LOGFILE
- by TD creating the information selectively
The reading of the LOGFILE is a historically wellknown and
safe method to register exactly what TD has executed. It is
safe because the TD database is never to be "touched" at
all. But it demands a development of the software for rea-
ding the log (the TD utility program TELELOGEX), a prepara-
tion of lists about what is logged (if anything) by which
transactions, change of format and creation of new records. \f
8_._4_ _ _S_Y_S_T_E_M_8_0_ _B_a_t_c_h_ _P_r_o_g_r_a_m_s_
Furthermore, the method is rather slow as the records in the
LOGFILE are intermingled independently of users and termi-
nals.
A selective creation of the information in TD can take place
by generating either the records or the text for this one
purpose.
The record generation demands a description (DATABASE80 and
SODA-LD) of the records and an implementation in the current
adaption points of: opening and positioning for the current
file (algol operation), creation of records (create, put),
and closing the file (algol operation); furthermore a de-
scription of the file in an administration record (eof-posi-
tion) is demanded by the same method in which the terminal
area is described in the terminal administration record. The
record generation could take place simultaneously with the
function print output (section 5.11).
The text generation would be more simple if it could be li-
mited to the times when the print output is being activated.
It may then be a print out (like any other print out).
All in all, the implementation will demand quite a lot of
adaption and furthermore it will strain the on-line functi-
ons. But it will not demand any implementation of a larger,
new module and the created information will be selective,
limited, and user individual.
The communication to TD may, in principle, take place either
at record - or text level. The record reception makes the
same demands as the record generation with regards to de-
scription, reading and administration records; furthermore
transactions, which activate the reading, must be implemen-
ted. \f
8_._4_ _ _S_Y_S_T_E_M_8_0_ _B_a_t_c_h_ _P_r_o_g_r_a_m_s_
Texts can be received like normal transactions. These can
either be processed by activating TELEOP in the off-line
mode or TELEOP can, in the on-line mode, read and process
the transactions in between the on-line transactions (not
implemented at present).
It must be said generally about communication that the tech-
nique exists but some implemantation is needed. There is,
however, no administration of the communication (e.g. of er-
roneously running the same input twice or any other error in
the administration, security at break-down, reestablishment,
restart at the right point etc).
The above remarks apply to communication with all the S80
function modules but especially those of GENIUS and GVINDS.\f
8.5 O_t_h_e_r_ _S_y_s_t_e_m_s_
Communication should take place without any merging in the
database.
Moreover the above-mentioned remarks concerning communicati-
on with SYSTEM80 can be repeated.\f
9 I_n_d_e_x_
The index includes keywords, definitions, etc. for the text
sections of the manual, and also references to sections with
flow diagrams and adaption point descriptions. References are
given the form
volume no.' section no', page no'
Variable designation, line codes and the like are not - with a
few exceptions - included in the index.\f
9_._ _ _I_n_d_e_x_
account entry II 5.6, 107
III 5.9, 63
account entry record III 5.9, 64
adaption, data errors III 6, 140
III 6.2, 142
reading of input I 4.2,40
adaption point description,
conventions for I 5.0,44
adaption point graph I 5.0,44
adaption point, next I 5.0,44
addition line II 5.5,4
II 5.6,107
admin_error_state I 5.1.1,49
administrative transactions I 5.3,116
adp 0 I 5.1.1,49
back order lines II 5.6,107
basic data, the user>s I 5.2,69
I 5.4,137
block reference in flow diagram I 5.0, 44
in adaption point description I 5.0, 44
BOSS III 8.4, 181
cancellation II 5.5,4
II 5.5.9,73
II 5.6,107
central convert III 5.10, 121
comment line II 5.5, 4
II 5.6,107 \f
9_._ _ _I_n_d_e_x_
communication variable
(Skeleton Program I 5.0,44
II 5.5, 4
II 5.6,107
(TELEOP) I 5.1.1,49
communication with other systems III 8.4, 181
compound deb/cred II 5.6,107
invoicing II 5.6.9,174
conditions for activation I 5.0,44
convert text area III 5.10, 119
III 5.10.1, 119
III 8.1, 174
create line (invoice) II 5.6,107
II 5.6.3,134
(account entry) III 5.9, 64
III 5.9.3, 72
(order) II 5.5, 4
II 5.5.6, 43
create master I 5.2.3,89
order II 5.5, 4
II 5.5.1, 18
structure list I 5.2.4,94
crediting II 5.6,107
database - I 2,13
III 8.4, 180
database 80 III 8.4, 180
description I 2.1,14
III 7.1, 156
structure I 2.1,14
data error - DUET cf. DUET
- Skeleton Program cf. Skeleton Program
- adaption cf. adaption\f
9_._ _ _I_n_d_e_x_
deb/cred entry scan III 5.9, 65
III 5.9.5, 86
deb/cred order scan III 5.7, 6
III 5.7.5, 36
debiting II 5.6,107
debitor/creditor invoicing II 5.6,107
II 5.6.5,164
delete master I 5.2.5,103
delete structure list I 5.2.6,108
designation (for adaption point) I 5.0, 44
discount record II 5.5, 4
II 5.6,107
display voucher III 5.7, 5
III 5.7.2, 20
DUET -
data errors III 6, 140
III 6.1, 141
III 8.2, 176
errors from the DUET system III 6, 140
III 6.1, 141
instruction number I 5.0, 44
interpreter I 3.1, 30
III 6.1, 141
III 8, 170
III 8.2, 176
program III 7.3, 160
program errors III 6, 140
III 6.1, 141
III 8.2, 176
system errors III 6, 140
III 6.1, 141
III 8.2, 176
\f
9_._ _ _I_n_d_e_x_
DUETCOM I 3.1,30
III 5.10, 119
III 8.1, 174
entry record II 5.6,107
erase line (invoice) II 5.6,107
II 5.6.6,168
(account entry) III 5.9, 64
III 5.9.4, 84
(order) II 5.5, 4
II 5.5.8,71
order II 5.5.5, 33
errors -
and warnings, input I 4.0,38
output I 3.1, 30
processing III 6, 139
number III 6.3, 143
text III 6.3, 143
print-outs III 6, 139
III 8.2, 176
errors -
from the DUET program III 6, 140
III 6.2, 142
field groups, repeating III 8.4, 180
flow diagrams, conventions for I 5.0,44
form of transaction I 4.0, 38
form print-outs III 5.11, 130
fp-commsnds III 8.4, 180
GENIUS III 8.4, 180
GVINDS III 8.4, 180
\f
9_._ _ _I_n_d_e_x_
identification (of the transaction) I 4.1,39
initialization (in the Skeleton Program I 5.1, 48
information code I 4.2, 40
input - I 4, 37
structure I 4.1, 39
input - zone I 5.1, 48
installation adaption III 6.2, 142
inquiry transactions I 5.4,137
item line II 5.5, 4
II 5.6,107
item movement, entering of II 5.6,107
item order scan III 5.7, 4
III 5.7.3, 24
invoice head amendment II 5.6,107
II 5.6.7,170
invoicing II 5.6,107
killing II 5.5, 4
II 5.5, 4
II 5.6,107
III 8.3, 178
KAOS III 8.4, 180
line code I 4.1, 39
I 4.2, 40
reading of I 5.1.2, 54
line number II 5.5, 4
II 5.6,107
III 5.7, 4
III 5.9, 63
logging III 8.1, 171
III 8.4, 180
\f
9_._ _ _I_n_d_e_x_
logical file maintenance I 4.2,40
I 5.2, 69
login III 5.8, 55
logout I 5.1, 48
III 5.8, 55
miscellaneous transactions III 5.7, 4
mode of operations I 5.1.1, 49
multi-user(-system) III 8.4, 180
neutral line II 5.5,4
number (for the adaption point) I 5.0, 44
off-line run I 5.1,48
operating administration III 8.4, 180
operating guide III 7,152
order -
entry II 5.5, 4
invoicing II 5.6,107
II 5.6.4,148
head amendment II 5.5, 4
II 5.5.3, 28
invoicing, compound II 5.6,107
II 5.6.8,172
line scan III 5.7, 4
III 5.7.6, 46
number II 5.5,4
other systems III 8, 170
III 8.5, 184
output I 3, 28
\f
9_._ _ _I_n_d_e_x_
output form administration record III 5.10, 118
III 5.11, 130
output-type I 3.2,31
III 5.10, 118
III 5.11, 130
paper type III 5.10, 118
parent deb/cred record II 5.6,107
line II 5.5, 4
part line II 5.5, 4
parts-list II 5.5, 4
II 5.6,107
password III 5.8, 55
physical stock count III 5.7, 4
III 5.7.4, 34
pooling administration I 3.4,
primary output III 6.1, 141
print channel 1 I 3.2,31
III 5.11, 130
III 8.1, 171
channel 2 I 3.1, 30
III 5.11, 130
III.6.1, 141
III 8.1, 171
printer
administration I 3.4, 35
printer,
central = common
common I 3.2, 31
III 5.10, 118
printer -
ident. I 3.2,31
number III 5.10, 118
\f
9_._ _ _I_n_d_e_x_
printer,
selective I 3.2,31
III 5.10, 118
separate = selective
control of I 3.2,31
print-out (from terminal area) cf. print output
print-out acceptance III 5.10, 118
III 5.10.2, 128
print-out administration III 5.10, 118
print-out command III 5.10, 118
print-out order I 3.2,31
print output III 5.11, 130
III 8.4, 180
priority I 5.1.1,49
production order II 5.5,4
program errors - DUET cf. DUET
protection - by order creation II 5.5 4
II 5.5, 4
- by invoicing II 5.6,107
purchase order II 5.5,107
reading (in the adaption point) I 5.0,44
references (to manuals) I 1.3, 12
relations (to other systems) III 8, 169
relocate stock transaction III 5.7, 4
III 5.7.4, 34
reply area I 3.1,30
III 8.1, 171
reply zone III 8.1, 171
re-run I 5.0,44
restrictions (of sets) II 5.5, 4
III 5.7, 4
\f
9_._ _ _I_n_d_e_x_
s no' cf. set description
sales order II 5.5, 4
select III 6.1, 141
serial number II 5.5, 4
II 5.6,107
III 5.7, 4
set I 2.2,21
, descriptions I 2.2, 21
single user (system) III 8.4, 180
Skeleton Program -
data errors III 6.2, 142
error list III 6.3, 143
skp_first_char I 5.1.8,61
skp_line_code I 2.2, 21
I 5.1.3, 55
SODA-LD I 2.2, 21
III 7.2, 158
III 8.1, 171
III 8.4, 180
sorting (of terminal area) II 5.5, 4
III 5.7, 4
III 5.9, 63
state check I 4.0,38
status area III 8.1, 171
syntax (input) I 4.2,40
system errors - DUET cf. DUET
system printer = printer, common
SYSTEM S III 8.4, 180
systems, >other> III 8, 169
III 8.5, 184
SYSTEM80 III 8, 169
III 8.4, 180
\f
9_._ _ _I_n_d_e_x_
TD utility III 8, 169
III 8.3, 178
Teleadm III 8.4, 180
TELELOG III 8.1, 171
III 8.4, 180
TELEOP I 3.1,30
III 5.10, 118
III 6.1, 141
III 7.4, 162
III 8, 169
III 8.1, 171
III 8.2, 176
terminal administration record I 5.1.1,49
I 5.3,116
II 5.5,4
III 5.8, 55
III 8.1, 171
terminal, administrative I 5.3,116
terminal area I 2.1, 14
II 5.5,4
II 5.6,107
III 5.9, 63
III 5.11, 130
III 8.1, 171
terminal controlling transaction III 5.8, 55
terminal ident. I 3.2, 31
test print-outs (from the DUET
interpreter III 8.2, 176
test runs III 7.5, 164
transaction I 1.1, 10
, from DUETCOM I 3.3, 32
, summary I 4.3, 42
transaction information I 4.2, 42
\f
9_._ _ _I_n_d_e_x_
text area III 5.10, 118
III 5.11, 130
III 8.1, 171
text crucher III 5.8, 55
update line (order) II 5.5, 4
II 5.5.7, 66
master I 5.2.1,78
order II 5.5, 4
II 5.5.2, 24
structure list I 5.2.2, 82
use (of adaption point) I 5.0, 44
utility = TD utility
voucher -
calculation III 5.7, 4
III 5.7.1, 9
line (record) II 5.5, 4
end - invoice II 5.6,107
II 5.6.2,125
III 5.7, 4
- account entry III 5.9, 63
III 5.9.2, 70
- order II 5.5, 4
II 5.5.4, 30
II 5.6,107
start - invoice II 5.6,107
II 5.6.1,120
- account entry III 5.9, 63
III 5.9.1, 68
- order II 5.5, 4
\f
9_._ _ _I_n_d_e_x_
writing (in the adaption point) I 5.0,44
\f
A_p_p_e_n_d_i_x_ _A_:
A_p_p_l_i_c_a_t_i_o_n_ _o_f_ _D_U_E_T_ _B_l_o_c_k_s_
By coding of the Skeleton Program and assignment of block
number and entry point for the adaption, the following
conventions have been applied.
Skeleton Program: block 1-19
Installation Adaption: block 20-29
User Adaption: block 50-'
S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_
block no. Application
1 Initialization and termination
of the transaction processing.
2 Terminal controlling transactions.
3 System transactions
(Z-transactions).
4 Logical file maintenance.
5 Inquiry transactions.
6 Print-out transactions.
7 Voucher calculation, display
transaction and print output.
8 Order entry.
9 Invoicing.\f
block no. Application
10 Account entry.
11 Miscellaneous transactions.
12 Cancellation (general)
13-19 Free.
I_n_s_t_a_l_l_a_t_i_o_n_ _A_d_a_p_t_i_o_n_
Includes adaption, which is common to all users of the
TELEDATA installation in question.
block no. Application
20 Terminal controlling transactions.
21 System transactions.
22 Error print-outs, Skeleton Program.
23 Print-out, convert-messages.
24-29 Free.
U_s_e_r_ _A_d_a_p_t_i_o_n_
Includes adaption, which is individual for a user (or a group
of users). For this purpose 20 blocks per user (-group) are
applied. By all calls of the user adaption in the Skeleton Pro-
gram the block number is stated as a variable which is assigned
from a corresponding field in the terminal record - i.e. the
terminal administration record contains 20 fields (adp. block
1, ---, a block 20) in which the block numbers for the user>s
adaption are saved.\f
The adaption is distributed in the blocks in the following
way:
Adp. block 1 Conversion of line code.
- - 2 Reading of keys, logical file
maintenance of master records.
- - 3 The rest of the logical file
maintenance.
- - 4 Inquiry transactions.
- - 5 Miscellaneous transactions.
- - 6 Order entry I
(Create Order, Update Order,
Erase Order, Order Head Amendment).
- - 7 Order entry II
(Create Order Line, Update
Order Line).
- - 8 Order entry III (Empty)
- - 9 Invoicing I (Voucher Start,
Invoice Head Amendment).
- - 10 Invoice II (Create Invoice Line).
- - 11 Invoice III (Create Invoice Line)
- - 12 Invoice IV (Order Invoice,
Deb/Cred Invoicing).
- - 13 Print-outs I (Print Output)\f
Adp. block 14 Print-outs II (Empty)
- - 15 Print-out administration.
- - 16 Cancellation (Erase Order Line,
Erase Invoice Line, Cancellation).
- - 17 Voucher calculation, etc.
(Display Voucher, Order Voucher End,
Invoice Voucher End, Voucher Calculation).
- - 18 Account entry (Voucher Start,
Entry Line, Erase Entry Line,
Customer Entry Scan).
- - 19 Other transactions (Empty).
- - 20 Free.\f
\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. LOADING THE SYSTEM ..................................... 2
3. RECONFIGURING THE PASCAL INTERPRETER ................... 4
4. PASCAL SYSTEM UTILITIES ................................ 5
4.1 BACKUP Utility .................................... 5
4.2 BOOTER Utility .................................... 5
4.3 CONVERT Utility ................................... 6
4.4 DISKSIZE Utility .................................. 6
5. LOADER DISKETTE UTILITIES .............................. 7
5.1 The SYSTEM Utility ................................ 7
5.2 The CONFIGURATION Utility ......................... 8
5.3 The FORMAT Utility ................................ 9
6. CONTENTS OF DISKETTES .................................. 10
7. PERIPHERAL SUPPORT ..................................... 12
7.1 Diskette Formats .................................. 12
7.1.1 Loader Diskettes ........................... 12
7.1.2 System Diskettes ........................... 12
7.2 Printer Port ...................................... 13
7.3 Terminal Port ..................................... 13
7.4 Display Handling .................................. 14
7.4.1 Cursor Addressing .......................... 14
7.4.2 Cursor Control ............................. 15
7.4.3 Attributes ................................. 15
7.4.4 Semigraphics ............................... 16
7.5 Keyboard .......................................... 18
A_P_P_E_N_D_I_C_E_S_:
A. REFERENCES ............................................. 21
B. ADDENDUM TO UCSD PASCAL USER'S MANUAL ................... 22
\f
ii
\f
F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
This document is intended as an introduction to the UCSD Pascal
system running on the RC700 microcomputer.
Only details specific to the RC700 implementation of UCSD Pascal
is covered.
For detailed information about the UCSD Pascal system and the
PASCAL language please refer to the references in appendix A.
The system delivered from A/S REGNECENTRALEN af 1979, is a CP/M
adaptable UCSD Pascal system from SofTech Microsystems configured
to run on the RC700 microcomputer.
The UCSD Pascal system is delivered on 2 or 3 diskettes. The UCSD
Pascal loader diskette contains drivers for the RC700 microcom-
puter hardware and various system utilities (refer to chapter 5).
The UCSD Pascal system diskette(s) contains the operating system,
files, editor and other utilities (refer to chapter 6).
The system will support one or two diskette drives of the 8" type
(recommended capacity: 915 k bytes per drive) or the 5 1/4" (re-
commended capacity: 279 k bytes per drive). The UCSD Pascal sys-
tem units #4 and #5 are supported as the RC700 diskette units 1
and 2 respectively. The RC700 Printer Port is supported as the
UCSD Pascal system unit #6 (printer:). The RC700 Terminal Port is
supported as the UCSD Pascal system units #7 and #8 (remin: and
remout:).
The RC700 Parallel Input/Output Port is not supported. Chapter 7
contains more detailed information on the peripheral support.
In chapter 2 you will find instruction on how to load the system
and get started.
The distribution system is configurated for one drive and has no
floating point facilities. The configuration may be changed by
the user in choosing a suitable interpreter module, see chapter
3.
CP/M is a registred trademark of Digital Research.
\f
The distribution system is configurated for use with a Danish
keyboard. However this configuration can easily be changed by
following the procedure outlined in chapter 5 before the system
is loaded or before the distribution system is copied.
Do not start using the distribution system before you have famil-
iarized yourself with this manual and examined the UCSD Pascal
User's Manual.
Never write on the original distribution diskettes. These will be
master copies and will function as last resert backups in the
event of errors. Start by producing backup copies as explained in
chapters 4 and 5. You may find it valuable to keep an additional
backup of the system at a secure place.
Your copy of the UCSD Pascal system for the RC700 has a serial
number and is licensed for your use only on a single RC700 micro-
computer system.
\f
F_ 2_._ _ _ _ _ _ _ _ _L_O_A_D_I_N_G_ _T_H_E_ _S_Y_S_T_E_M_ 2.
The UCSD Pascal system is loaded in the following way:
1) Insert the diskette marked 'PASCAL LOADER' into drive 1 and
press the 'RESET'-button.
The following text (loader diskette promptline) will be dis-
played:
RC700 PASCAL LOADER vers. dd.mm.yy
INSERT PASCAL DISK - TYPE <RETURN>
2) Insert the Pascal system disk (SYS:) into drive 1, and type
<return>. After several disk accesses, the Pascal prompt line
will appear, and the system is ready for use.
The Pascal system disk (SYS:) must contain the following files:
SYSTEM.PASCAL (the operating system)
SYSTEM.INTERP (the Pascal interpreter)
SYSTEM.MISCINFO (information about terminal handling)
The available Pascal programs - for example the compiler - may
require some additional files to exist on SYS:, see chapter 6.
The system will be loaded in a configuration corresponding to the
contents of the loader diskette. When the loader diskette prompt-
line appears, the possibility to change the configuration is
available. This is done before the system diskette is loaded and
is described in further detail in chapter 5.
\f
F_ 3_._ _ _ _ _ _ _ _ _R_E_C_O_N_F_I_G_U_R_I_N_G_ _T_H_E_ _P_A_S_C_A_L_ _I_N_T_E_R_P_R_E_T_E_R_ 3.
The initial configuration of the Pascal interpreter (the file
SYSTEM.INTERP) is able to handle one floppy disk drive and has no
floating point capabilities.
Three more interpreter module files exist:
CPM2.INTERP
2 drives supported -
no floating point capabilities.
CPM1.FP.INTERP
1 drive supported
floating point included
CPM2.FP.INTERP
2 drives supported
floating point included
The INTERP modules occupies much less memory space than the
FP.INTERP modules.
To install a new interpreter, enter the F)iler by typing F, and
R)emove the file SYSTEM.INTERP. Then T)ransfer the appropriate
interpreter file to the system disk (in case it is not present on
the system disk), naming it SYSTEM.INTERP. The system may now be
re-booted, thus including the new interpreter module.
NOTE: With a two drive configuration (CPM2....) a system load
requires diskettes in both drives in order to prevent the
system from hanging on a read to the second drive.
\f
F_ 4_._ _ _ _ _ _ _ _ _P_A_S_C_A_L_ _S_Y_S_T_E_M_ _U_T_I_L_I_T_I_E_S_ 4.
Apart from the standard UCSD Pascal utilities (see ref. 1) the
RC700 Pascal is supplied with a number of system utilities. They
are described in the following sections.
4_._1_ _ _ _ _ _ _ _B_A_C_K_U_P_ _U_t_i_l_i_t_y_ 4.1
The backup program BACKUP.CODE will make a copy of an RC700 UCSD
Pascal system diskette (note that copies of the loader diskette
is made as described in section 5.1). The program asks for the
source- and destination unit numbers for the transfer, and will
work on both one and two drive systems. The diskette drives have
unit numbers 4 and 5, ref. 1 p.8. On a single drive system the
backup process is somewhat tedious as you have to interchange the
source and destination disks a number of times.
To execute the backup program, type X and BACKUP at the command
level.
4_._2_ _ _ _ _ _ _ _B_O_O_T_E_R_ _U_t_i_l_i_t_y_ 4.2
The bootstrap copies program BOOTER.CODE is described in ref.
1, p.293. It is used to copy the UCSD Pascal System Secondary
Bootstrap from one disk drive to another. This must be done
before a diskette initialized by means of the Z(ero) command (see
ref. 1, p.29) can be used as system load diskette. The RC700
BOOTER program asks for source- and destination unit numbers and
then proceeds to copy the secondary bootstrap (residing on
cylinder 0) from a system load diskette onto the destination
diskette.
To execute the booter program, type X and BOOTER at the command
level.
\f
4_._3_ _ _ _ _ _ _ _C_O_N_V_E_R_T_ _U_t_i_l_i_t_y_ 4.3
The convert program is supplied only with the RC700 UCSD Pascal
5 1/4" diskette systems. It is used to convert old single den-
sity, double sided system diskettes into the current dual den-
sity, double sided system diskette format, and requires a two
drive system for proper operation. The program will ask for the
number of blocks to convert (normally 280) and will then prompt
the user to insert the old single density diskette in unit #4 and
a dual density system diskette in unit #5 as destination drive.
On completion it is up to the user to change the directory size
on the dual density diskette in order to use the full capacity of
558 blocks.
To execute the convert program, type X and CONVERT at the command
level.
4_._4_ _ _ _ _ _ _ _D_I_S_K_S_I_Z_E_ _U_t_i_l_i_t_y_ 4.4
The disksize utility is described in ref. 1, p.I-11. The
standard disksizes for the RC700 UCSD Pascal systems are
558 blocks for 5 1/4" diskettes and
1830 blocks for 8" diskettes.
It is recommended not to change the disk capacity, as several
utilities will operate with the standard sizes.
\f
F_ 5_._ _ _ _ _ _ _ _ _L_O_A_D_E_R_ _D_I_S_K_E_T_T_E_ _U_T_I_L_I_T_I_E_S_ 5.
The loader diskette of the RC700 UCSD Pascal system contains a
bootstrap loader and the drivers for the RC700 microcomputer sys-
tem. It further contains utilities to generate copies of the
loader diskette itself, to reconfigure the RC700 driver system
and to format system diskettes.
The loader diskette utilities are activated by following the pro-
cedure for loading the system as outlined in chapter 2. When the
loader diskette promptline appears, press the ESC button instead
of typing return. This will bring up the U_t_i_l_i_t_y_-_p_r_o_m_p_t_l_i_n_e_:
RC700 UTILITY: F(ORMAT, S(YSTEM, C(ONFIGURATION?
Now type a single letter as indicated to select the required
utility. Whenever the Utility-promptline is re-displayed, type
RETURN to get the loader diskette promptline back.
5_._1_ _ _ _ _ _ _ _T_h_e_ _S_Y_S_T_E_M_ _U_t_i_l_i_t_y_ 5.1
The SYSTEM utility is used to generate a copy of the loader dis-
kette. The distribution loader diskette contains the drivers
configured according to normal RC700 standard. The user has the
option of reconfiguring the drivers before the copy is made (re-
fer to section 5.2). In this way the user may generate loader
diskettes to suit actual requirements, and may produce different
loader diskettes for different tasks to be run on the same sys-
tem.
The diskette types used for the loader diskettes are described in
section 7.1. Here it should be noted that the diskettes need n_o_t_
be pre-formatted as this is taken care of by the utility as re-
quired.
When the utility is selected by responding with an 'S' to the
Utility-promptline, the user will be asked to:
INSERT DISK - TYPE 'RETURN'
\f
Now insert an empty diskette in drive 1 and press the return key.
When the loader system has been written onto the diskette, return
will be made to the Utility-promptline and another copy can be
made, if required.
5_._2_ _ _ _ _ _ _ _T_h_e_ _C_O_N_F_I_G_U_R_A_T_I_O_N_ _U_t_i_l_i_t_y_ 5.2
The CONFIGURATION utility is used to make reconfigurations of the
RC700 drivers. It is possible to reconfigure the following:
1) Printer Port characteristics
2) Terminal Port characteristics
3) Conversion tables for keyboard alphabets
4) Cursor format on display unit.
The CONFIGURATION utility is activated by responding with a 'C'
to the Utility-promptline and is menu driven from there on. When
the various parameters have been set, return is made to the Util-
ity-promptline by pressing RETURN.
The actual reconfigurations take place only when the system is
loaded from the system diskette. Please note that a reconfigured
loader diskette may be generated by means of the SYSTEM utility
once the parameters have been set. When the new loader diskette
is subsequently used together with the system diskette for load-
ing, the UCSD Pascal system will appear in the reconfigurated
form.
The setting of the configuration parameters is achieved by se-
lecting options from the menues on display. The first menu to ap-
pear will offer a choice of the above mentioned reconfiguration
possibilities. When a selection has been made, another menu will
appear with a further choice of options, or with a list of poss-
ible values for the parameter in question. When a parameter has
been set by typing the number of its desired value, the previous
menu will be redisplayed for a new selection to be made. The cur-
rent value of a parameter is indicated by an asterisk to the left
of the selection number. If no changes are to be made or if a se-\f
lection is regretted, typing RETURN will cause the previous menu
to be redisplayed.
The loader system distributed by RC is configured for a Danish
keyboard and with a blinking reverse video cursor. The printer
and terminal part are configured as detailed in sections 7.2 and
7.3.
5_._3_ _ _ _ _ _ _ _T_h_e_ _F_O_R_M_A_T_ _U_t_i_l_i_t_y_ 5.3
The FORMAT utility is used to format diskettes to be used as sys-
tem diskettes. The diskettes must be of the 2D type, double si-
ded, dual density, soft sectored (refer to section 7.1).
It is advisable to format a batch of diskettes before they are
used as system diskettes for the RC700 UCSD Pascal system as one
cannot be certain that the diskettes are correctly formatted by
the manufacturer in all cases (5 1/4" never are).
Remove the loader diskette from diskette drive 1 before selecting
the utility by typing 'F'. Now the prompt will be to:
INSERT DISK - TYPE 'RETURN'
Put the diskette to be formatted into diskette drive 1, close the
door and press RETURN. When the formatting is over, the Utility-
promptline will be redisplayed and the system will be ready for
formatting of the next diskette.
\f
F_ 6_._ _ _ _ _ _ _ _ _C_O_N_T_E_N_T_S_ _O_F_ _D_I_S_K_E_T_T_E_S_ 6.
The RC700 UCSD Pascal system is distributed on two or three dis-
kettes. The MAXI diskette system consists of a loader diskette
and a Pascal system diskette (volume id SYS:). The MINI diskette
system consists of a loader diskette and two Pascal system dis-
kettes (volume id SYS: and SYS1:). (Note however that the RC700
UCSD Pascal Turnkey System on MINI diskette comprises only loader
diskette and system diskette, SYS:). The Pascal system load dis-
kette (see chapter 2) is the diskette with the volume id SYS:.
The following is a list of the files on the distribution disket-
te(s) with reference to the appropriate documentation:
SYSTEM.PASCAL ref. 1 p.5 3)
SYSTEM.INTERP this manual 3)
SYSTEM.MISCINFO ref. 1 p.259 3)
SYSTEM.FILER ref. 1 p.7
SYSTEM.EDITOR ref. 1 p.31
SYSTEM.COMPILER ref. 1 p.69
SYSTEM.SYNTAX ref. 1 p.70
DISKCHANGE.CODE ref. 1 p.I-9, I-15
DISKSIZE.CODE ref. 1 p.I-11 3)
YALOE.CODE ref. 1 p.57
SYSTEM.LINKER ref. 1 p.77
SYSTEM.LIBRARY ref. 1 p.78
SYSTEM.ASSEMBLER ref. 1 p.129
Z80.OPCODES ref. 1 p.129
Z80.ERRORS ref. 1 p.129
8080.ASSEMBLER ref. 1 p.129
8080.OPCODES ref. 1 p.129
8080.ERRORS ref. 1 p.129
LIBRARY.CODE ref. 1 p.249
LIBMAP.CODE ref. 1 p.309
PATCH.CODE see PATCH.DOC.TEXT
PATCH.DOC.TEXT replaces section 4.4 in ref. 1
\f
CPM1.INTERP this manual chapter 3 1), 3)
CPM2.INTERP this manual chapter 3 1), 3)
CPM1.FP.INTERP this manual chapter 3 1), 3)
CPM2.FP.INTERP this manual chapter 3 1), 3)
MARKDUPDIR.CODE ref. 1 p.301 1)
COPYDUPDIR.CODE ref. 1 p.301 1)
DISASM.II.CODE ref. 1 p.303 1)
OPCODES.II.0 ref. 1 p.303 1)
RELOC.CODE see RELOC.DOC.TEXT 1)
RELOC.DOC.TEXT 1)
FLIPCODE.CODE see FLIP.DOC.TEXT 1)
FLIPDIR.CODE see FLIP.DOC.TEXT 1)
FLIP.DOC.TEXT 1)
BOOTER.CODE this manual chapter 4 1)
BACKUP.CODE this manual chapter 4 1)
CONVERT.CODE this manual chapter 4 1), 2)
Notes: 1) For a MINI diskette system these files will be on the
(SYS1:) system diskette
2) MINI diskette system only
3) Files included in the RC700 UCSD Pascal Turnkey System
\f
F_ 7_._ _ _ _ _ _ _ _ _P_E_R_I_P_H_E_R_A_L_ _S_U_P_P_O_R_T_ 7.
The following sections contain information about the peripherals
supported by the RC700 UCSD Pascal system.
7_._1_ _ _ _ _ _ _ _D_i_s_k_e_t_t_e_ _F_o_r_m_a_t_s_ 7.1
7_._1_._1_ _ _ _ _ _L_o_a_d_e_r_ _D_i_s_k_e_t_t_e_s_ 7.1.1
The 5 1/4" MINI-diskette is a single density, double sided, 128
bytes per sector, 16 sectors per track floppy disk with 36 cylin-
ders.
Recommended type: Memorex 32013421.
The 8" MAXI-diskette is a single density, single sided, 128 bytes
per sector, 26 sectors per track floppy disk with 77 cylinders.
Recommended type: 3M 740/2-0.
7_._1_._2_ _ _ _ _ _S_y_s_t_e_m_ _D_i_s_k_e_t_t_e_s_ 7.1.2
The 5 1/4" MINI-diskette is a dual density, double sided, 512
bytes per sector, 9 sectors per track floppy disk with 32 cylin-
ders. Thus it can hold 558 Pascal blocks (279 k bytes).
Recommended type: Memorex 32013421.
The diskette is formatted with 2 to 1 interleaved sectors and
zero track to track skew. The first Pascal cylinder is cylinder
one.
The 8" MAXI-diskette is a dual density, double sided, 512 bytes
per sector, 15 sectors per track floppy disk with 62 cylinders.
Thus it can hold 1830 Pascal blocks (915 k bytes).
Recommended type: 3M 743-0-512.
The diskette is formatted with 2 to 1 interleaved sectors and
zero track to track skew. The first Pascal cylinder is cylinder
one.
\f
Diskettes originating from other UCSD Pascal systems not having
the proper interleaving ratio and track to track skew must be
reformatted using the DISCCHANGE program (see ref. 1) before
being used with the system.
7_._2_ _ _ _ _ _ _ _P_r_i_n_t_e_r_ _P_o_r_t_ 7.2
The RC700 Printer Port is supported as the UCSD Pascal unit #6
(printer:). The standard configuration is:
1 stopbit
even parity
1200 bps
7 data bits
The port can be used for attachment of most printers with a ser-
ial interface and busy control. The busy handshake mechanism uses
the V.24 signals RTS and CTS as follows:
Figure 1: Printer port V.24 signals.
7_._3_ _ _ _ _ _ _ _T_e_r_m_i_n_a_l_ _P_o_r_t_ 7.3
The RC700 Terminal Port is supported as the UCSD Pascal units #7\f
and #8 (REMIN: and REMOUT:) for asynchronous operation (V.24).
The standard configuration is:
1 stopbit
even parity
1200 bps
7 data bits for transmit and receive
The port characteristics can be adapted to fit almost any requi-
rements by means of the configuration utility on the loader disk
(see section 5.2).
The transmitter part of the terminal port functions exactly as
the printer port. The receiver port uses the V.24 signal DCD to
enable receiving. The parity bit is masked off when receiving.
7_._4_ _ _ _ _ _ _ _D_i_s_p_l_a_y_ _H_a_n_d_l_i_n_g_ 7.4
7_._4_._1_ _ _ _ _ _C_u_r_s_o_r_ _A_d_d_r_e_s_s_i_n_g_ 7.4.1
Cursor movements on the display can be controlled by absolute
cursor addressing, where horizontal before vertical addressing is
used. The cursor movement is made by outputting three characters,
a control character and two addressing characters:
Control character: 6
First address character: horizontal position + 32
Second address character: vertical position + 32
It is the programmer's responsibility to see that the values of
addresses are kept within the following limits:
0 + 32 <_ vertical position <_ 24 + 32
0 + 32 <_ horizontal position <_ 79 + 32
The upper left corner of the display has the address (0,0), the
lower right the address (24,79).
\f
7_._4_._2_ _ _ _ _ _C_u_r_s_o_r_ _C_o_n_t_r_o_l_ 7.4.2
The characters below will cause the cursor to move as specified:
5 or 8 - one position to the left (backspace)
9 - four positions forward (tabulation)
10 - one line down (newline)
12 - display cleared and cursor to position (0,0)(clear)
13 - return to position 0 on current line (carriage re-
turn)
24 - one position to the right (forward space)
26 - one line up
29 - return to position (0,0)(home)
30 - current line erased from cursor position to end of
line
31 - display erased from cursor position to end of dis-
play
7_._4_._3_ _ _ _ _ _A_t_t_r_i_b_u_t_e_s_ 7.4.3
A set of attributes is available to be used for characters on the
display:
- underline
- inverse video
- blinking
- semigraphic
The attributes are assigned each character following the "set
attribute" character until the "reset attribute" character occurs
or the "set attribute" character is scrolled out of the screen.
The "set attribute" character is defined as 128 plus the actual
attribute byte. The "reset attribute" character is defined as
128.
\f
The value of the attribute byte can be found by using the table
below:
Attribute Value
dec. hex. bin.
blinking 2 2 00000010
semigraphic 4 4 00000100
inverse video 16 10 00010000
underline 32 20 00100000
The attribute may be mixed in any order to enable e.g. inverted
semigraphic (128 + 4 + 16 = 148) or blinking semigraphic (128 + 2
+ 4 = 134).
7_._4_._4_ _ _ _ _ _S_e_m_i_g_r_a_p_h_i_c_s_ 7.4.4
The semigraphic attribute enables a semigraphic character set as
shown in fig. 2.
\f
F_
Figure 2: Semigraphic character set. \f
F_ 7_._5_ _ _ _ _ _ _ _K_e_y_b_o_a_r_d_ 7.5
The RC700 Microcomputer keyboard exists in two layouts, where
RC721 keyboards with production number before KBU723 S/N 51, and
RC722 keyboards before KBU722 S/N 384, follow the layout shown in
fig. 3. Later productions of RC721/RC722 keyboards follow fig. 4.
The values delivered by the keyboard are used as index into an
input conversion table in order to produce the character value
for the UCSD Pascal system. The input conversion table is located
at address 5A00 Hex in the loader diskette memory image.
\f
F_
\f
F_
\f
F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.
1 RCSL No 42-i1515:
UCSD Pascal, User's Manual
SofTech Microsystems/RC Computer, 1980
2 RCSL No 42-i1530:
Beginner's guide for the UCSD Pascal System
Kenneth L. Bowles
Byte Books (McGraw-Hill), 1979
3 RCSL No 42-i1609:
PASCAL, User's Manual and Report
Kathleen Jensen and Niklaus Wirth
Springer-Verlag, New York, 1975
\f
F_ B_._ _ _ _ _ _ _ _ _A_D_D_E_N_D_U_M_ _T_O_ _U_C_S_D_ _P_A_S_C_A_L_ _U_S_E_R_'_S_ _M_A_N_U_A_L_ B.
This appendix contains a number of amendments to the UCSD Pascal
User's Manual, ref. 1.
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
F_
\f
«eof»