|
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: 133504 (0x20980)
Types: TextFile
Names: »D155«
└─⟦ae2411776⟧ Bits:30008864 Diskette med tekster der formodes at være 31-D-152…161
└─⟦this⟧ »D155«
\f
F_ I_n_d_i_v_i_d_i_n_f_ _f_o_r_ _i_n_d_i_v_i_d_t_y_p_e_ _i_1_0_1_
maxfelter = 17
index i _feltnr i _feltadr elem- db-ref ant.elem typelgd adm- type
status status
1: 1 sa _reclength 0 0 0 0 2 3 2
2: 2 sa _serialno 2 0 0 0 2 8 2
3: 3 sa _rectype 4 0 0 0 2 4 2 word
4: 4 sa _adate 6 0 0 0 2 7 2
5: 5 sa _recstate 8 0 0 0 2 8 2
6: 6 sa _fstate 10 0 0 1 array 1 8 1 half
7: 10 sa _key 12 0 0 0 4 1 7 aggr
8: 11 sa _caseno 12 3 i 7 0 2 1 ident 2
9: 12 sa _type 14 3 aggr 7 0 2 1 2 word
10: 13 sa _expl 16 0 0 4 array 2 8 2
11: 90 sa _cons 0 0 0 1 liste- 0 0 10
12: 91 sa _rel1 0 0 0 3 nr. 0 0 10 dref
13: 92 sa _rel2 0 0 0 4 0 0 10
14: 1001 sa _casetext 24 0 0 0 40 0 5
15: 1002 sa _custname 52 0 0 0 40 0 5 text
16: 1003 sa _custadr1 80 0 0 0 40 0 5
17: 1004 sa _custadr2 108 0 0 0 40 0 5
18: 101 caserecord 0 0 0 0 0 0 0
19: 1 caself 0 0 0 0 0 0 0
register
individtype
\f
F_ I_n_d_i_v_i_d_i_n_f_ _f_o_r_ _i_n_d_i_v_i_d_t_y_p_e_ _i_4_0_2_
maxfelter = 24
index i _feltnr i _feltnavn i _feltadr elem- db-ref ant.elem typelgd adm. type
status status
1: 1 fb _reclength 0 0 0 0 2 3 2
2: 2 fb _rec _no _cf 2 0 0 0 2 2 2
3: 3 fb _rectype 4 0 0 0 2 4 2 word
4: 4 fb _adate 6 0 0 0 2 7 2
5: 5 fb _recstate 8 0 0 0 2 8 2
6: 6 fb _fstate 10 0 0 4 array 1 8 1 half
7: 90 fb _caseref -10 0 0 1 listenr 4 1 ident 11 mref
8: 1 10 sa _key 12 1 i mref 7 0 4 0 7 aggr
9: 1 11 sa _caseno 12 3 i 8 0 2 0 2
10: 1 12 sa _type 14 3 aggr 8 0 2 0 2 word
11: 91 fb _ident 14 0 0 0 2 1 ident 2
12: 2001 fb _km _amt 16 0 0 0 4 0 3
13: 2002 fb _subst _amt 20 0 0 0 4 0 3 long
14: 2003 fb _other _amt 24 0 0 0 4 0 3
15: 2004 fb _machinetime 28 0 0 4 array 2 0 2
16: 2005 fb _rc4000 28 5 equiv 15 0 2 0 2 word
17: 2006 fb _rc8000 32 5 15 0 2 0 2
18: -402 voucherinf 36 0 38 rpadr 3 repant 4 0 9 rpg
19: 201 fb _voucherno 0 4 i 18 0 2 0 2 word
20: 202 fb _voucherdate 2 4 rpg 18 0 2 0 6 date
21: -401 employeeref 38 0 0 0 0 0 8 fgr
22: 101 fb _employeeref -4 2 i fgr 21 2 listenr 4 0 11 mref
23: 2 10 ma _key 12 1 i mref 22 0 4 0 7 aggr
24: 2 11 ma _employeeno 12 3 i aggr 23 0 4 0 3 long
25: 402 travelexpenses 0 0 0 0 0 0 0
26: 4 consumptlf 0 0 0 0 0 0 0
\f
F_ I_n_d_i_v_i_d_i_n_f_ _f_o_r_ _i_n_d_i_v_i_d_t_y_p_e_ _i_1_2_0_2_
maxfelter = 31
index i _feltnr i _feltnavni _feltadr elem- db-ref ant.elem typelgd adm. type
status status
1: 1 i12 _reclength 0 0 0 0 2 3 2
2: 2 i12 _checksum 2 0 0 0 2 8 2 word
3: 3 i12 _rectype 4 0 0 0 2 4 2
4: 4 i12 _adate 6 0 0 0 2 7 2
5: 10 i12 _sa _key 8 0 0 0 4 1 7 aggr
6: 11 i12 _caseno 8 3 i 5 0 2 1 ident 2 word
7: 12 i12 _casetype 10 3 aggr 5 0 2 1 2
8: 1 fb _reclength 24 0 0 0 2 0 2
9: 2 fb _rec _no _cf 26 0 0 0 2 0 2
10: 3 fb _rectype 28 0 0 0 2 0 2 word
11: 4 fb _adate 30 0 0 0 2 0 2
12: 5 fb _recstate 32 0 0 0 2 0 2
13: 6 fb _fstate 34 0 0 4 array 1 0 1 half
14: 90 fb _caseref -10 0 0 1 listenr 4 0 11 mref
15: 1 10 sa _key 14 1 i mref 14 0 4 0 7 aggr
16: 1 11 sa _caseno 14 3 i 15 0 2 0 c 2
17: 1 12 sa _type 16 3 aggr 15 0 2 0 o 2 word
18: 91 fb _ident 38 0 0 0 2 0 p 2
19: 2001 fb _km _amt 40 0 0 0 4 0 y 3
20: 2002 fb _subst _amt 44 0 0 0 4 0 r 3 long
21: 2003 fb _other _amt 48 0 0 0 4 0 e 3
22: 2004 fb _machinetime 52 0 0 4 array 2 0 c 2
23: 2005 fb _rc4000 52 5 equiv 22 0 2 0 o 2 word
24: 2006 fb _rc8000 56 5 22 0 2 0 r 2
25: -402 voucherinf 60 0 62 rpgadr 3 rpgant 4 0 d 9 rpg
26: 201 fb _voucherno 0 4 i 25 0 2 0 2 word
27: 202 fb _voucherdate 2 4 rpg 25 0 2 0 6 date
28: -401 employeeref 62 0 0 0 0 0 8 fgr
29: 101 fb _employeeref -4 2 i fgr 28 2 listenr 4 0 11 mref
30: 2 10 ma _key 20 1 i mref 29 0 4 0 7 aggr
31: 2 11 ma _employeeno 20 3 i aggr 30 0 4 0 3 long
32: 1202 i12 _travelexp 0 0 0 0 0 0 0
33: 12 i12 _trans 0 0 0 0 0 0 0
\f
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. INDLEDNING ............................................ 1
2. DB-infprocedurerne .................................... 2
2.1 initdbinf ........................................ 2
2.2 filinf ........................................... 3
2.3 listeinf ......................................... 4
2.4 registerinf ...................................... 5
2.5 feltinf .......................................... 8
2.6 individinf ....................................... 11
2.7 værdiinf ......................................... 22
\f
ii
\f
F_ 1_._ _ _ _ _ _ _ _ _I_N_D_L_E_D_N_I_N_G_ 1.
DB-beskrivelsens dokumentation af databasen indgår i mange værk-
tøjsprogrammer og hjælpeprogrammer. Da disse programmer bør være
uafhængige af eventuelle ændringer i det interne format af DB-re-
gistret, er der udarbejdet et sæt procedurer - de såkaldte DB-
inf-procedurer - som kan fortolke informationen i DB-registret og
levere den på en mere brugervenlig form.
\f
F_ 2_._ _ _ _ _ _ _ _ _D_B_-_i_n_f_p_r_o_c_e_d_u_r_e_r_n_e_ 2.
Nedenfor beskrives de enkelte DB-inf-procedurer. De læser alle
fra DB-registret via en global zone, der skal erklæres som vist i
figur 1.
zone dbz (buflengthcf (string db-regnavn (increase(i)), 2),
3, stderror);
Figur 1: Erklæring af zone for DB-inf
Zonen skal åbnes ved et kald af procedure init _db _inf (jf. afsnit
2.1), hvorefter de øvrige procedurer kan kaldes i vilkårlig
rækkefølge.
2_._1_ _ _ _ _ _ _ _i_n_i_t_d_b_i_n_f_ 2.1
Initialiseringsproceduren >init _db _inf> er erklæret som vist i
figur 2.
integer procedure init _db _inf (dbz, dbreg _navn, dbreg _version,
sprogkode);
zone dbz;
real array dbreg _navn; <*(1:2)*'
integer dbreg _version;
integer sprogkode;
Figur 2: init _db _inf
Proceduren åbner zonen >dbz> til DB-registret identificeret ved
>dbreg _navn>. Parametrene >dbreg _version> og >sprogkode> er p.t.
dummy. (De er beregnet til fremtidig udvidelse af DB-registret
med versionskontrol og alternative feltnavne).
Værdien af procedurekaldet:
'= 0: ok
= -1: ikke dbregister i >dbreg _navn>
= -2: forkert dbregister version
= -3: ukendt sprogkode
<= -4: inkonsistens i db-register
\f
2_._2_ _ _ _ _ _ _ _f_i_l_i_n_f_ 2.2
Proceduren >filinf> er erklæret som vist i figur 3.
integer procedure filinf (dbz, filnr, filnavn, f _inf);
zone dbz; <*åbnet ved init _db _inf*'
integer filnr;
long array filnavn; <*(1:2)*'
integer array f _inf; <*(1:22 + max _antal _registre*'
Figur 3: filinf
Proceduren henter oplysning fra DB-registret om en fil bestemt
ved værdien af kaldparametern >filnr>:
f_i_l_n_r_ _=_ _0_: Filen identificeres ved navnet lagret i >filnavn>,
mens >filnr> som returparameter indeholder filens nummer.
f_i_l_n_r_ _'_ _0_: Filen identificeres ved nummeret i >filnr>, mens
>filnavn> som returparameter indeholder filens navn.
Øvrige returværdier:
f_i_l_i_n_f_: Værdien af procedurekaldet:
< 0: inkonsistens i DB-register eller fejl ved >init _db _inf>
= 0: ukendt fil
' 0: ok
f_i_n_f_: integer array f _inf (1:22+max _antal _registre) indeholder
som returværdi filbeskrivelsen, som vist nedenfor:
index indhold
1 filtype: 1 = text
2 = outvar
3 = cfmaster
4 = cflist
5 = special
2 minsegs (antal segmenter)
3 normsegs (antal segmenter)
4 maxsegs (antal segmenter) \f
index indhold
5 bloklængde (antal halvord)
6 ubenyttet
7 min. individlængde (antal halvord)
8 norm. individlængde (antal halvord)
9 max. individlængde (antal halvord)
10 ubenyttet
11 nøglekode: 1 = ingen nøgle
2 = kompakt nøgle
3 = long nøgle
4 = abs nøgle
12 nøglebase (dvs. basisadresse for nøglen som en
lige halvordsadresse)
13 nøglelængde (antal halvord)
14-17 nøglemaske (2 longs, kun relevant for nøglekode 2,
beskriver en kompakt nøgle som et antal words og
longs, hvor en long er angivet med en 1-bit)
18 antal registre i filen
19 ubenyttet
20 filparam1: indhold bestemt af filtypen:
cfmaster: bucketstørrelse i antal segm.
cf list: bruges ikke
andet: bruges ikke
21 filparam2: bruges ikke
22 filparam3: bruges ikke
23- registernumre for alle registre, der tilhører filen
2_._3_ _ _ _ _ _ _ _l_i_s_t_e_i_n_f_
2.3
Proceduren >listeinf> er erklæret som vist i figur 4.
integer procedure liste _inf (dbz, listenr, listenavn, l _inf);
zone dbz; <*åbnet ved init _db _inf*'
integer listenr;
long array listenavn; <*(1:3)*'
integer array l _inf; <*(1:5)*'
Figur 4: listeinf
\f
Proceduren henter oplysning fra DB-registret om en cf-kæde
bestemt ved kaldparameteren >listenr>.
Returværdier:
l_i_s_t_e_i_n_f_: Værdien af procedurekaldet:
< 0: inkonsistens i DB-registret eller fejl ved >init _db _inf>
= 0: ukendt listenr
' 0: ok
l_i_s_t_e_n_a_v_n_: long array listenavn (1:3)
indeholder som returværdi listens navn
l_i_n_f_: integer array l _inf (1:5) indeholder som returværdi
nedenstående oplysninger om listen:
index indhold
1 filnummer for listens moderfil
2 filnummer for listens datterfil
3 registernummer for listens moderregister
4 registernummer for listens datterregister
5 listetype: 1 = enkel
2 = forbind
3 = netværk
2_._4_ _ _ _ _ _ _ _r_e_g_i_s_t_e_r_i_n_f_ 2.4
Proceduren >register _inf> er erklæret som vist i figur 5.
integer procedure register _inf (dbz, regnr, regnavn, reginf,
ityper, itypenavne, ilængder);
zone dbz; <*(1:3)*'
integer regnr;
long array regnavn; <*(1:3)*'
integer array reginf; <*(1:27+max _antal _filer)*'
integer array ityper; <*(1:max _antal _ityper)*'
long array itypenavne; <*(1:3*max _antal _ityper)*'
integer array ilænger; <*(1:max _antal _ityper)*'
Figur 5: register _inf.
\f
Proceduren henter oplysning fra DB-registret om et register be-
stemt ved værdien af kaldparameteren >regnr>:
r_e_g_n_r_ _=_ _0_: Registret identificeres ved navnet lagret i >regnavn>,
mens >regnr> som returparameter indeholder registrets nummer.
r_e_g_n_r_ _'_ _0_: Registret identificeres ved registernummeret i
>regnr>, mens >regnavn> som returparameter indeholder registrets
navn.
Øvrige returværdier:
r_e_g_i_s_t_e_r_i_n_f_: værdien af procedurekaldet:
< 0: inkonsistens i DB-registret eller fejl ved >init _db _inf>
= 0: ukendt register
' 0: antal individtyper i registret
i_t_y_p_e_r_: integer array ityper (1: max _antal _ityper)
indeholder som returværdi individtypenumrene for alle de indi-
vidtyper, der indgår i registret.
i_t_y_p_e_n_a_v_n_e_: long array itypenavne (1:3*max _antal _ityper)
indeholder som returværdi individtypenavnene for alle registrets
individtyper, lagret med 3 longs pr. navn (max. 17 tegn).
i_l_æ_n_g_d_e_r_: integer array ilængder (1: max _antal _ityper)
indeholder som returværdi den maximale og minimale individlængde
(antal halvord) for hver individtype, der indgår i registret.
Individlængderne er pakket således:
max _ilængde shift 12 + min _ilængde
r_e_g_i_n_f_: integer array reginf (1:27+max _antal _filer)
indeholder som returværdi registerbeskrivelsen som vist nedenfor:
\f
Index Indhold:
1 registertype 2 = sekventiel
3 = indekssekventiel
4 = primærliste
1 = udefineret
2 antal filer hvori registret kan indgå
3 anvendelseskode: 1 = speciel
2 = standard
3 = gvs
4 = gvs-speciel
4 listenummer for primærliste
5 ubenyttet
6 mindste individlængde (antal halvord) *)
7 største individlængde (antal halvord) *)
8 nøglekode
9 nøglebase som filinf, f _inf (11:17)
10 nøglelængde
11-14 nøglemaske
15 ubenyttet
16 ubenyttet
17 antal individtyper i registret (=registerinf)
18 antal feltgrupper i registret
19 antal registerspecifikke felter
20 feltnr for første registerspecifikke felt
21 feltnr for sidste registerspecifikke felt
22 samlet længde (antal halvord) af register speci-
fikke felter
23 antal nøglefelter
24 antal felter med fremdaterede ændringer
25 antal moderkædefelter
26 antal datterkædefelter
27 længde (antal halvord) af kædedel
28- filnumre for alle de filer, registret kan tilhøre
*) oplysningen er i_k_k_e_ rigtig, hvis individet indeholder en
copyrecord.
\f
2_._5_ _ _ _ _ _ _ _f_e_l_t_i_n_f_ 2.5
Proceduren feltinf er erklæret som vist i figur 6:
integer procedure feltinf (dbz, regnr, feltnr, feltnavn,
feltspec, feltadr, fvref);
zone dbz; <*åbnet ved init _db _inf *'
integer regnr;
integer feltnr;
long array feltnavn; <*(1:3)*'
long feltspec;
integer feltadr;
integer fvref;
Figur 6: feltinf
Proceduren henter oplysning fra DB-registeret om et felt eller en
feltgruppe bestemt ved feltnr eller feltnavn:
f_e_l_t_n_r_ _=_ _0_: feltet identificeres ved navnet lagret i >feltnavn>,
mens >regnr> og >feltnr> som returparametre indeholder
registernummer og feltnummer for feltet.
f_e_l_t_n_r_ _'_ _0_: feltet identificeres ved feltnummer og registernummer
i >feltnr> og >regnr>, mens >feltnavn> som returværdi indeholder
feltets navn.
Returværdier:
f_e_l_t_i_n_f_: værdien af procedurekaldet:
< 0: inkonsistens i DB-register eller fejl ved >init _db _inf>
= 0: ukendt felt
= 1: feltet er registerspecifiket
= 2: feltet er feltgruppespecifikt
= 3: feltet er individtypespecifikt
\f
f_e_l_t_n_a_v_n_: integer feltnavn
indeholder som returværdi feltets navn (uanset kaldmåden). Hvis
feltet er af type mref eller dref er det dog listenavnet der re-
turneres.
f_e_l_t_s_p_e_c_: long feltspec
indeholder som returværdi oplysninger om feltet pakket som vist i
Figur 7.
3 3 16 10 8 4 4
dec.ant. elem-status db-ref ant.elem. typelgd adm-status type
47 45 42 26 16 8 4 0
figur 7: indhold af feltspec.
De enkelte bitgrupper i feltspec beskrives nedenfor:
d_e_c_._a_n_t_
numerisk felt: antal decimaler specificeret i feltets repræsen-
tationsangivelse.
andre felter : 0
e_l_e_m_-_s_t_a_t_u_s_
angiver feltets sammenhæng med andre felter:
0 = selvstændigt felt
1 = element i mref
2 = element i feltgruppe
3 = element i aggregat
4 = element i repeterende feltgruppe
5 = redefinition af arrayfelt
d_b_-_r_e_f_ indeholder:
hvis feltet er en repeterende feltgruppe:
basisadressen (= lige halvordsadresse) for den første
repeterende feltgruppe i individet,
hvis elem-status <' 0: f_e_l_t_n_r_ for det overordnede felt, som det
givne felt er element i,
ellers: 0.
\f
a_n_t_._e_l_e_m_ Betydningen afhænger af feltets art:
arrayfelt: antal arrayelementer
rep.feltgruppe: max.antal repetitioner
mref.felt: listenr
dref.felt: listenr
ellers: 0
t_y_p_e_l_g_d_ angiver længden af feltet afhængig af felttypen:
textfelt: antal karakterer excl. afsluttende null
mref.felt: samlet længde (antal halvord) af modernøglen
dref.felt: 0
aggr. felt: samlet længde (antal halvord)
feltgruppe: - - - -
numerisk felt: antal halvord (1, 2 el. 4)
Hvis feltet er et array eller en repeterende feltgruppe, er det
længden af en enkelt forekomst.
a_d_m_-_s_t_a_t_u_s_ angiver administrativ feltstatus:
0 = normalt felt
1 = ident (nøglefelt)
2 = recnocf
3 = reclength (ilang)
4 = rectype (itype)
5 = genitype
6 = geniuser
7 = adate (ændringsdato)
' 8 checksum og øvr. adm. status.
t_y_p_e_ angiver feltets type:
1 = half (byte)
2 = word
3 = long
4 = real
5 = text
6 = date
7 = aggr
8 = feltgruppe
9 = repeterende feltgruppe
10 = dref
11 = mref
\f
f_e_l_t_a_d_r_: integer feltadr
indeholder som returværdi feltets basisadresse, dvs. en halvords-
adresse der peger umiddelbart foran feltes start. Felter af ty-
perne mref, dref, feltgruppe og rep.feltgruppe har dog feltadr
=0. For felter der indgår i en feltgruppe eller en rep. feltgrup-
pe angives adressen relativt til feltgruppens start. For alle
andre felter er adressen absolut inden for individet.
f_v_r_e_f_: integer fvref
indeholder som returværdi feltets værdinummer, der kan bruges som
kaldparameter til procedure værdi _inf (jf. afsnit 2.7).
2_._6_ _ _ _ _ _ _ _i_n_d_i_v_i_d_i_n_f_ 2.6
Proceduren individinf er erklæret som vist i figur 8.
integer procedure individ _inf (dbz, itypenr, i _feltnr,
i _feltnavn, i _feltspec, i _feltadr, i _fvref);
zone dbz; <*åbnet ved init _db _inf*'
integer itypenr;
integer array i _feltnr; <*(1: maxfelter +2)*'
long array i _feltnavn; <*(1:3*(maxfelter +2)*'
long array i _feltspec; <*(1:maxfelter +2)*'
integer array i _feltadr; <*(1:maxfelter +2)*'
integer array i _fvref; <*(1:maxfelter +2)*'
Figur 8: individ _inf.
Proceduren henter oplysning fra DB-registret om alle felter i en
individtype bestemt ved værdien af kaldparameteren >itypenr>.
i_t_y_p_e_n_r_ _=_ _0_: individtypen identificeres ved individtypenavnet
lagret i i _feltnavn som kaldparameter. >itypenr> indeholder som
returværdi individtypenummeret.
i_t_y_p_e_n_r_ _'_ _0_: individtypen identificeres ved individtypenummeret i
>itypenr>.
\f
Returværdier:
i_n_d_i_v_i_d_i_n_f_: Værdien af procedurekaldet:
= -4: copyrecord i copyrecord
= -3: copyrecord af ukendt individtype
= -2: inkonsistens i DB-register eller
= -1: fejl ved >init _db _inf>.
= 0: ukendt individtype
' 0: maxfelter (=antallet af feltbeskrivelser hørende til
individtypen).
Alle øvrige returværdier er p_a_r_a_l_l_e_l_l_e_ _a_r_r_a_y_s_, der beskriver
individtypens felter i den rækkefølge hvori de findes i
individet.
I arrayelementerne umiddelbart efter et felt af typen aggregat,
feltgruppe eller rep. feltgruppe findes beskrivelsen af de en-
keltfelter, der indgår i aggregatet/feltgruppen.
Hvis et arrayfelt er ækvivaleret med simple felter, findes
beskrivelsen af disse umidelbart efter arrayfeltets beskrivelse.
I arrayelementerne efter et felt af typen mref findes beskri-
velsen af moderregistrets nøglefelter. Hvis modernøglen er et
aggregat findes først aggregatfeltet og derefter de felter der
indgår i aggregatet.
De sidste to benyttede elementer af disse arrays (med index hhv.
maxfelter+1 og maxfelter+2) beskriver ikke felter men individ-
typen og registret.
I det følgende defineres indholdet af de enkelte arrays. Iøvrigt
henvises til eksemplerne i slutningen af dette afsnit.
i_f_e_l_t_n_r_: integer array i _feltnr (1: maxfelter +2)
indeholder feltnumrene for alle individtypens felter. Visse
felter optræder her med specielle feltnumre:
\f
feltgruppe/rep.feltgruppe:
nr:= -feltgruppenr
modernøgle i mref:
nr:= moder _regnr shift 16 + moder _feltnr
individtype:
i _feltnr (maxfelter +1):= itypenr
register:
i _feltnr (maxfelter +2):= registernr
i_f_e_l_t_n_a_v_n_: long array i _feltnavn (1:3*(maxfelter+2))
indeholder feltnavnene for alle individtypens felter, samt indi-
vidtypenavn og registernavn. Hvert navn optager 3 longs (max. 17
tegn).
De sidste to navne i i _feltnavn er hhv. individtypenavn og re-
gisternavn.
i_f_e_l_t_s_p_e_c_: long array i _feltspec (1:maxfelter+2)
indeholder som returværdi feltbeskrivelser for alle individtypens
felter. Hvert element af >i _feltspec> indeholder pakket felt-
information som defineret ved >feltspec> i afsnit 2.5 med und-
tagelse af bitgruppen db-ref.
d_b_-_r_e_f_ indeholder:
hvis feltet er en repeterende feltgruppe: basisadressen (= lige
halvordsadresse) for den første repeterende feltgruppe i
individet,
hvis elemstatus <' 0: i_n_d_e_x_ i feltarrays for beskrivelsen af det
overordnede felt som det aktuelle felt tilhører
ellers: 0.
i_f_e_l_t_a_d_r_: integer array i _feltadr (1:maxfelter+2)
indeholder feltadressen for alle individtypens felter, som
beskrevet ved >feltadr> i afsnit 2.5 med følgende undtagelser:
\f
Felt i feltgruppe: adressen angives absolut inden for individet.
Felt i repeterende feltgruppe: adressen angives relativt til
feltgruppens start.
Felt af typen mref: i _feltadr indeholder et tal, der angiver
forskydningen mellem de efterfølgende moder-nøglefelters adresse
i moderindividet og deres faktiske placering i datterindividets
kædedel. Denne forskydning bruges ved adressering i kædedelen,
f.eks. ved individudskrifter, som vist i eksempelt figur 9.
Felt der indgår i mref: dvs. et felt i moderregistrets nøgle.
i _feltadr indeholder moder-nøglefeltets adresse i moderindividet,
jf. figur 9.
Udskrift af long modernøgle i liste individ:
begin integer kædedels _lgd, kædebasis;
long field lf;
integer array ia(1:20);
zone zlist (...); <*cf-listefil*'
...
kædedels _lgd := reginf(27);
getzone6 (zlist, ia);
kædebasis := ia(16);
ia(16) := ia(16) + kædedels _lgd;
setzone6 (zlist, ia);
lf := kædebasis
+ fadr (mrefindex) <*forskydning*'
+ fadr (feltindex) <*modernøgle basis *'
+ 4;
write (out, <<dddd', zlist.lf);
end;
Figur 9: Eksempel på addressering af kædedel.
\f
i_f_v_r_e_f_: integer array i _fvref (1: maxfelter+2)
indeholder værdinumrene for hvert af individets felter.
Hvis en individtype indeholder en >c_o_p_y_r_e_c_o_r_d_> i DB-beskrivelsen,
vil procedure individinf efter beskrivelsen af individtypens egne
felter levere beskrivelsen af alle den kopierede individtypes
felter. Disse vil fremtræde med feltnumre og andre oplysninger
som i det oprindelige individ, dog med følgende to undtagelser:
a_d_m_-_s_t_a_t_u_s_ i i _feltspec er 0 for alle felter, uanset deres adm-
status i det oprindelige individ.
i_f_e_l_t_a_d_r_ indeholder adressen på feltets placering i det nye indi-
vid. Bemærk her, at en eventuel kædedel i individet kopieres
f_o_r_a_n_ selve individet (mens kædedelen ligger sidst i det oprinde-
lige individ).
I hvert af de efterfølgende tre eksempler vises definitionen af
et register og en individtype i database beskrivelsen, sammen med
indholdet af individinf-arrayene for den pågældende individtype.
\f
F_ Eksempel 1: M_o_d_e_r_i_n_d_i_v_i_d_ _i_ _c_f_-_m_a_s_t_e_r_f_i_l_
10
20 logical _file _section:
30
40 r1 caselfindexed _sequential gvs
50 **
60 ** logical _file _specific fields
70 **
80 f1 sa _reclength word reclength
90 f2 sa _serialno word serialno
100 f3 sa _rectype word rectype
110 f4 sa _adate word adate
120 f5 sa _recstate word recstate
130 f6 sa _fstate half (1) fbits
140**
150 f10 sa _key aggr ident (1)
160 f11 sa _caseno word v1
170 f12 sa _type word v2
180 aggr
190**
200 f13 sa _expl word (4) plosion
210 f90 sa _cons dref sa _consumpt
220 f91 sa _rel1 dref sa _netw1
230 f92 sa _rel2 dref sa _netw2
240 **
250 ** record _types
260 **
270 i101 caserecord
280 f1001 sa _casetext text t40 gu
290 f1002 sa _custname test t40 gu
300 f1003 sa _custadr1 text t40 gu
310 f1004 sa _custadr2 text t40 gu
\f
F_ (skema)
\f
F_ Eksempel 2: D_a_t_t_e_r_i_n_d_i_v_i_d_ _i_ _c_f_-_l_i_s_t_e_f_i_l_e_
10
20 r4 consumptlf primary _list: sa _consumpt gvs
30 ** logical _file _specific fields
40 f1 fb _reclength word reclength
50 f2 fb _rec _no _cf word recnocf
60 f3 fb _rectype word rectype
70 f4 fb _adate word adate
80 f5 fb _recstate word recstate
90 f6 fb _fstate half (4) fbits
100 f90 fb _caseref mref sa _consumpt ident (0)
110 f91 fb _ident word ident (1)
120 **
130 g401 employeeref
140 f101 fb _employeeref mref ma _consumpt
150 **
160 g402 voucherinf rpg
170 f201 fb _voucherno word v5
180 f202 fb _voucherdate word d1
190 **
200
210
220 ** recordtypes and record _specific fields
280 i402 travelexpenses
290 f2001 fb _km _amt long n6.2 v8
300 f2002 fb _subst _amt long n6.2 v8
310 f2003 fb _other _amt long n6.2 v8
320 f2004 fb _machinetime word (4)
330 f2005 fb _rc4r000 = fb _machinetime (1)
340 f2006 fb _rc8000 = fb _machinetime (3)
350 voucherinf (3)
360 employeeref
370 **
\f
F_ (skema)
\f
F_ Eksempel 3: C_o_p_y_r_e_c_o_r_d_ _a_f_ _d_a_t_t_e_r_i_n_d_i_v_i_d_
30
40 r 12 i12 _trans sequential
50
60 ** logical _file _specific fields
70
80 f1 i12 _reclength word reclength
90 f2 i12 _checksum word checksum
100 f3 i12 _rectype word rectype
110 f4 i12 _adate word adate
120
130 f10 i12 _sa _key copyaggr sa _key ident(1)
140 f11 i12 _caseno
150 f12 i12 _casetype
160 aggr
170
220
230 ** record type 2 travel expenses transaction
240
250 i1202 i12 _travelexp
260 copyrecord: i402
270
\f
F_ (skema)\f
F_ 2_._7_ _ _ _ _ _ _ _v_æ_r_d_i_i_n_f_ 2.7
Proceduren værdiinf er erklæret som vist i figur 10.
integer procedure værdi _inf (dbz, vref, værdier);
zone dbz; <*åbnet ved init _db _inf*'
integer vref;
long array værdier; <*(1:2+maxværdier)*'
Figur 10: værdi _inf
Proceduren henter oplysning fra DB-registret om en værdispecifi-
cation bestemt ved værdinummeret i kaldparameteren >v_r_e_f_&.
Returværdier:
v_æ_r_d_i_i_n_f_: Værdien af procedurekaldet:
< 0: inkonsistens i DB-registret eller fejl ved >init _db _inf>
= 0: ukendt værdinr
' 0: maxværdier (= antallet af relevante værdier).
v_æ_r_d_i_e_r_: Indeholder værdierne hørende til vref på følgende måde:
v_æ_r_d_i_e_r_(_1_)_ er en værdispecifikation pakket på samme måde som
>feltspec> i procedure feltinf (jf. afsnit 2.5), idet dog
bitgrupperne elem-status, db-ref og adm-status altid er nul.
3 19 10 8 4 4
dec.ant. 0 ant.elem. typelgd 0 type
47 45 26 16 8 4 0
Figur 11: indhold af værdier(1)
v_æ_r_d_i_e_r_(_2_)_ indeholder en bitmaske, som angiver hvilke af de ef-
terfølgende elementer af >værdier>, der er relevante. Bittene fra
og med
værdier(2) shift (-1) extract 1
til og med
værdier(2) shift (-værdiinf) extract 1
er betydende; de øvrige er nulstillede.
\f
Den første bit (dvs. shift(-1)) har værdien 1 hvis der findes en
standardværdi, 0 ellers.
De efterfølgende bits svarer til par af min-max grænser, dvs.
bitten >shift(-2)> angiver om første interval har en nedre
grænse.
v_æ_r_d_i_e_r_(_3_:_._._._)_ indeholder de aktuelle værdier (standardværdi
og/eller værdigrænser), idet værdispecifikationen i værdier(1)
bestemmer formatet af disse værdier.
B_e_g_r_æ_n_s_n_i_n_g_e_r_:
I den nuværende udgave af værdiinf er der følgende begrænsninger
i forhold til ovenstående generelle beskrivelse:
værdiinf <= 3
værdier(1) = 4 shift 8 + 3
værdier(3) = evt. standardværdi
værdier(4) = evt. minimumsværdi
værdier(5) = evt. maksimumsværdi.
\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. SYSTEM OVERVIEW ........................................ 2
3. ACCESS TO FTU VIA RC8000 MESSAGES ...................... 3
3.1 Messages .......................................... 3
3.1.1 Sense ...................................... 3
3.1.2 Get Status ................................. 3
3.1.3 Start FTU .................................. 4
3.1.4 Stop FTU ................................... 4
3.1.5 Abort Transfer ............................. 4
3.1.6 Request Transfer (REQ) ..................... 5
3.2 Answers ........................................... 5
4. ACCESS TO FTU VIA SC CONNECT ........................... 6
4.1 Connecting ........................................ 6
4.2 Session ........................................... 6
4.3 Disconnecting ..................................... 6
5. FTU ACCESS TO SC ....................................... 7
5.1 Port Open ......................................... 7
5.2 Connecting ........................................ 7
5.3 Session ........................................... 8
5.4 Disconnecting ..................................... 8
6. IMPLEMENTATION OF FTP .................................. 9
6.1 Level 0 Implementation ............................ 9
6.2 Level 1 Implementation ............................ 13
7. INSTALLATION GUIDE ..................................... 14
7.1 Resource Requirements ............................. 14
7.2 Prerequisites ..................................... 14
7.3 System Tape ....................................... 14
7.4 Installation ...................................... 15
7.5 Validation ........................................ 16 \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_
8. OPERATING GUIDE ........................................ 17
8.1 Process Start ..................................... 17
8.2 Call of FTU Program (bftu) ........................ 18
8.3 Operator Interaction During Operation ............. 20
8.3.1 Printouts on Current Output ................ 20
8.3.2 Printouts from s on Print Messages ......... 20
8.4 Operator Termination of FTU ....................... 21
9. FTU ACCESS TO DISC FILES ............................... 23
10. MAINTENANCE INFORMATION ................................ 24
10.1 FTU Program ...................................... 24
10.1.1 Block Structure and Procedures ........... 24
10.1.2 Protocol Procedures ...................... 26
10.1.3 Event Handling ........................... 28
10.1.4 Alarm Handling ........................... 30
10.1.5 Net Access ............................... 30
10.1.6 Level 0 Parameter Mapping ................ 31
10.2 Genjob ........................................... 31
10.3 Test of FTU under BOSS2 .......................... 32
A_P_P_E_N_D_I_C_E_S_:
A. REFERENCES ............................................. 33
B. FORMAT OF THE FILE TRANSPORT DESCRIPTION (FTD) ......... 34
C. FORMAT OF ANSWERS TO FTU MESS .......................... 38
D. OPRES VALUES ........................................... 39
E. LEVEL 0 STATE SETTINGS ................................. 40
F. LEVEL 1 STATE SETTINGS ................................. 42
\f
iii
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_
G. SET-FILE RESULT VALUES ................................. 44
H. DISCONNECT CAUSE VALUES ................................ 46
I. SYSTEM PARAMETERS ...................................... 47
J. SURVEY OF LEVEL 0 COMMANDS ............................. 48
K. SURVEY OF LEVEL 1 COMMANDS ............................. 49
L. LEVEL 1 STATE/EVENT TABLES ............................. 50
M. DETAILS ON LEVEL 0 PARAMETERS .......................... 52
N. LOG FILE EVENTS AND RECORDS ............................ 56
O. DIVISION OF DATA BLOCKS IN SUBRECORDS .................. 57
P. FTU STATE SETTINGS ..................................... 58
\f
iv
\f
1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
This manual describes the RC8000 File Transfer Utility (FTU),
developed at REGNECENTRALEN af 1979 for CENTERNET in 1980-81.
The FTU serves as a RC8000 host utility, and performs the task of
trasferring files across the network.
The protocol used in the transfer is described in ref. 5.
The FTU is implemented in ALGOL and is executed in an RC8000
process using the basic operating system - s.
The FTU is accessed either local: from another RC8000 process,
using RC8000 messages - or remote: from another host in the
network.
In any case, FTU performs one out of two parties involved in a
file transfer.
This manual contains the reference information about FTU. If you
are not familiar with file transfers, you should first read the
user's guide (ref. 6).
The following abbreviations are used throughout this manual:
FTP - File transfer protocol (ref. 5),
FTU - RC8000 File Transfer Utility (covered by this manual),
NPM - Network Port Module (ref. 3),
SC - CENTERNET Session Control (ref. 4),
P - Denotes FTP level 0 initiator,
Q - Denotes FTP level 0 responder,
FTD - Filetransport description. See appendix B,
REQ - Transport request message (see subsection 3.1.6).
\f
F_ 2_._ _ _ _ _ _ _ _ _S_Y_S_T_E_M_ _O_V_E_R_V_I_E_W_ 2.
The FTU and its environments are outlined in the following fig.
REQUESTER
FTU NPM CNET
ANY
LOG FILE S
The arrows shows the message flow (not the data flow).
NPM - Serves as interface to the net.
S - Is parent process of FTU, and may receive print
messages from FTU (see 6.1, opmess).
FILE - Denotes some disk file to be transferred.
LOG - The FTU log file, recording the history of FTU.
ANY - Some other process, which may receive a message (see
6.1, monmess).
REQUESTER - Some other process, requesting FTU functions (by
means of messages).
A file transport is initiated in two ways:
- Local request: FTU connects to the remote end, and performs the
file transfer as initator (P). All transfer parameters are
given in the request.
- Remote request: FTU receives a connect from a remote host and
performs the file transfer as responder (Q). All transfer
parameters are given in the level 0 SFT command by the
initiator.
FTU performs one file transfer at a time. Local transfer requests
recieved during a transfer are immediately returned (not
accepted).
\f
F_ 3_._ _ _ _ _ _ _ _ _A_C_C_E_S_S_ _T_O_ _F_T_U_ _V_I_A_ _R_C_8_0_0_0_ _M_E_S_S_A_G_E_S_ 3.
The functions of FTU are requested local in RC8000 by sending
messages to FTU. Any RC8000 process may send messages to FTU. The
messages are outlined in 3.1. The answers have all the same
format, and are described in 3.2.
3_._1_ _ _ _ _ _ _ _M_e_s_s_a_g_e_s_ 3.1
The messages consist of 8 words, and in the description the words
are numbered 1 to 8. Irrelevant words are omitted.
3_._1_._1_ _ _ _ _ _S_e_n_s_e_ 3.1.1
Message: 1. 0<12 + mode.
No function is performed. The answer is delayed, as requested by
mode, thus:
mode = 0: no delay
mode = 2: delay until a transport stop occurs
mode = 4: delayed until a transport start occurs
mode = 6: delayed until either transport stop or start
occurs
mode =10: as mode = 2, but if no transport is active, it is
answered immediately
mode =12: as mode = 4, but if a transport is active, it is
answered immediately
Transport start: When level 0 GO is sent (P) or received (Q)
Transport stop: When level 0 STOP (or disconnect) is sent (P) or
received (Q).
3_._1_._2_ _ _ _ _ _G_e_t_ _S_t_a_t_u_s_ 3.1.2
Message: 1. 3<12 + mode (meaning input)
2. first addr.
3. last addr.
\f
No function is performed. The answer is delayed, as requested by 3.1.3
mode, as described in sense message. The data block contains the
FTD at answer time (the first part, if not room for it all).
3_._1_._3_ _ _ _ _ _S_t_a_r_t_ _F_T_U_
Message: 1. 202<12 + reserve
FTU is started (if not already started):
A port is opened at NPM, and answer sent.
If reserve = 1, FTU is reserved by the requester, i.e. messages
from other processes are rejected (except sense and get status).
3_._1_._4_ _ _ _ _ _S_t_o_p_ _F_T_U_ 3.1.4
Message: 1. 204<12 + 0
The FTU is stopped: If a transport is active, it is aborted, and
port at NPM is closed. Then the answer is sent.
3_._1_._5_ _ _ _ _ _A_b_o_r_t_ _T_r_a_n_s_f_e_r_ 3.1.5
Message: 1. 5<12 + 1 (meaning output)
2. first addr.
3. last addr.
If the data block has exactly same contents as the FTD when the
message is sent, describing an active transfer (fields No 1 to 7,
see appendix B), the transfer is aborted, and the answer is sent
at transport stop (see sense).
Otherwise the answer is sent immediately (abort not accepted).
\f
3_._1_._6_ _ _ _ _ _R_e_q_u_e_s_t_ _T_r_a_n_s_f_e_r_ _(_R_E_Q_)_ 3.1.6
Message: 1. 5<12 + 2 (meaning output)
2. first addr.
3. last addr.
The data block contains a transport description in the format as
in FTD (see appendix B). Fields 1 to 7 are demanded, 8 to 14 are
optional.
The local file is checked, connection established and a transfer
initiated. The request is considered processed when transport
start occurs, or if any earlier operation does not succeed.
The answer is sent when the request is processed, or immediately
(if transport already in progress).
3_._2_ _ _ _ _ _ _ _A_n_s_w_e_r_s_ 3.2
The answer consists of 8 words and a result. All answers from FTU
have the same format, and the contents reflect the success of the
operation and the state of the FTU at answer time.
The format is given in appendix C.
\f
F_ 4_._ _ _ _ _ _ _ _ _A_C_C_E_S_S_ _T_O_ _F_T_U_ _V_I_A_ _S_C_ _C_O_N_N_E_C_T_ 4.
When the FTU has been started, a file transfer may be initiated
from another host by connecting via SC.
4_._1_ _ _ _ _ _ _ _C_o_n_n_e_c_t_i_n_g_ 4.1
The SC connect operation is used. The FTU gives no restrictions
on the connect, and will always return connect accept.
4_._2_ _ _ _ _ _ _ _S_e_s_s_i_o_n_ 4.2
In the session, letters may be sent of a size up to 1998 bytes
(-18 bytes header). The initiator must be able to receive letters
of same size. The data must follow the FTP (see ref. 5 and
chapter 6).
4_._3_ _ _ _ _ _ _ _D_i_s_c_o_n_n_e_c_t_i_n_g_ 4.3
After a successful filetransfer, FTU will (as Q) disconnect the
session. If this is rejected, the session is aborted.
The initiator may at any time request disconnect or abort the
session. A disconnect is accepted by FTU. FTU may abort session -
see section 5.4.
The values of cause (in disconnect request and abort session) are
stated in appendix H.
\f
F_ 5_._ _ _ _ _ _ _ _ _F_T_U_ _A_C_C_E_S_S_ _T_O_ _S_C_ 5.
The SC is accessed via NPM (ref. 3).
The data formats followed are stated in ref. 2.
5_._1_ _ _ _ _ _ _ _P_o_r_t_ _O_p_e_n_ 5.1
A port is opened when receiving an FTU start message (if not
already opened). The port is opened with the following port
parameters (system parameters are described in appendix I, port
parameters in ref. 2 and ref. 3):
receiver mask: rmask (system parameter)
bufno for receiving: bufno +1 (bufno is system parameter)
buflength for receiving: 1998
bufno for sending: bufno (bufno is system parameter)
buflength for sending: 1998
r-bit for sending: 0
After port open, an event-control operation is set up.
5_._2_ _ _ _ _ _ _ _C_o_n_n_e_c_t_i_n_g_ 5.2
When FTU is connecting, the parameters are set as follows:
xmit mask: from request transfer (F7)
class: 0 (low prio)
nui: from request transfer (F6)
F6 and F7: see appendix B.
After connect, "bufno" receive letter operations are set up.
\f
5_._3_ _ _ _ _ _ _ _S_e_s_s_i_o_n_ 5.3
FTU sends letters of a size up to 1998 bytes (-18 bytes header),
and is prepared to receive letters of same size. Data follows FTP
(see ref. 5 and chapter 6).
5_._4_ _ _ _ _ _ _ _D_i_s_c_o_n_n_e_c_t_i_n_g_ 5.4
After a terminated file transfer (successful or not), FTU will
(as P) await disconnect request from Q (if it does not happen
before timeout - see appendix I - an abort session is sent). The
disconnect request is accepted.
In giveup situations, FTU will abort the session:
- result not ok on SC operations
- timeout awaiting disconnect
- after a parent break (see section 8.4).
- after recieving a stop FTU message (see subsection 3.1.4)
\f
F_ 6_._ _ _ _ _ _ _ _ _I_M_P_L_E_M_E_N_T_A_T_I_O_N_ _O_F_ _F_T_P_ 6.
This chapter describes the interpretation of the elements of FTP
done by FTU in order to map the protocol into RC8000 file system.
Data records sent by FTU are subdivided as described in appendix
O. The parameter numbers refer to the field descriptions in
appendix B. (e.g. F4).
6_._1_ _ _ _ _ _ _ _L_e_v_e_l_ _0_ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_ 6.1
A survey of level 0 commands is given in appendix J, and details
on parameters are given in appendix M. The following is a survey
of the implementation. First the commands are mentioned, then the
attributes. These are described by first stating which value is
sent, so "sent value (RNEG, STOP)" means that the attribute will
only be sent in RNEG and STOP commands. Second, recieved values
are stated. Here, "Accepted (SFT)" means that, the attribute must
only be recieved in SFT command, otherwise protocol error is
detected. The level 0 attributes are ordered as in ref. 5.
S_F_T_ _c_o_m_m_a_n_d_
The parameters F1, F4-F5, F11, F15 and F19 are converted and
sent. The parameters F10, F12, F13 and F14 are sent, if assigned
in request transport (one of first 6 bytes <> 0). F16 is sent and
if level 1 role is receiver, the "monitor bit" is set. F17 and
F18 is always sent with monitorbit.
When receiving SFT, no parameters are demanded, but if not
assigned, the default value is used. This will not do in case of
F1, F4-F5 and F16.
R_P_O_S_ _c_o_m_m_a_n_d_
All parameters sent with monitor bit are returned. If level 1
role is sender, F16 is returned. When receiving RPOS, F10
assigned will cause an opmess to be sent.
R_N_E_G_ _c_o_m_m_a_n_d_
All parameters sent with monitor bit are returned, together with
F20. When receiving RNEG, F10 assigned will cause an opmess to be
sent.
\f
G_O_ _c_o_m_m_a_n_d_
No parameters sent, no received.
S_T_O_P_ _c_o_m_m_a_n_d_
F20 always sent. F8-F9 sent, if assigned in transport request (F8
<> null name). When receiving STOP, F20, F8-F9 and F10 are
expected. F8-F9 will cause a monitor message to be sent, F10 will
cause an opmess to be sent.
P_r_o_t_o_c_o_l_ _i_d_e_n_t_i_f_i_c_a_t_i_o_n_ _(_F_1_9_)_
Sent value (SFT): 0
Accepted (SFT): 0
M_o_d_e_ _o_f_ _a_c_c_e_s_s_ _(_F_1_)_
Sent value (SFT): as assigned in REQ.
Accepted (SFT): = 2 (receiver), = 130 (sender)
C_o_d_e_s_ _(_F_1_8_)_
Sent value (SFT): 2 (binary)
Accepted (SFT): Anything, if just the "binary" bit is set. If
other bits are set, F18 is sent in RPOS/RNEG.
F_a_c_i_l_i_t_i_e_s_ _(_F_1_7_)_
Sent value (SFT): 1+4+8
Accepted (SFT): Anything, but it is only possible to clear one
or more of the bits. If so, the new value is
returned on RPOS/RNEG.
S_t_a_t_e_ _o_f_ _t_r_a_n_s_f_e_r_ _(_F_2_0_)_
Sent (RNEG, STOP): Values in appendix E.
Accepted (RNEG, STOP): Any.
F_i_l_e_ _n_a_m_e_ _(_F_2_-_F_3_ _o_r_ _F_4_-_F_5_)_
A proper file name consists of the following IA5 string:
<entry name><sp><lower base><sp><upper base><sp>
\f
The elements uniqely identifies an entry in the RC8000 catalog
(see ref. 10). When processing an REQ, F2-F3 is checked (area
process created and reserved see ref. 10). If this fails, REQ
is answered not ok.
Sent (SFT: F4-F5): as assigned in REQ
Accepted (SFT: F2-F3): same check as mentioned above.
U_s_e_r_ _n_a_m_e_ _(_F_1_2_)_
Sent (SFT): if as assigned in REQ
Accepted (SFT, RPOS, RNEG): Any
F12 is not used by FTU.
K_i_n_s_h_i_p_ _(_F_1_6_)_
A proper kinship is an IA5 string consisting of 10 numbers
separated by delimiters. These 10 numbers are the contents of a
catalog entry tail (see ref. 11). The first of these integers
is the number of segments of the file.
When FTU is level 1 receiver, it must receive kinship (in SFT or
RPOS), whereupon the tail of the local file is attempted changed
to the received values (by performing changeentry). Note, that
the resources of the FTU process hereby may be changed because
the segment size of the file may be changed. Note that the
document name (tail2-tail5) cannot be changed. Finally, the FTU
level 1 receiver inserts an update mark (system parameter,
appendix I) in tail7 before entering level 1. This mark is
removed if the level 1 transfer terminates successfully.
sent (SFT): Entry tail of local file
sent (RPOS): Entry tail of local file (if level 1 role is sender)
Accepted (SFT/RPOS): Any 10 numbers, if changeentry succeeds.
A_c_c_o_u_n_t_ _(_F_1_3_)_
Sent (SFT): If assigned in REQ
Accepted (SFT, RPOS, RNEG): Any
F13 is not used by FTU.
\f
F_i_l_e_ _S_i_z_e_ _(_F_1_5_)_
Sent (SFT): (<bytes of local file> -1)//1024+1
Accepted (SFT, RPOS, RNEG): Any
F15 is not used by FTU.
O_p_e_r_a_t_o_r_ _M_e_s_s_a_g_e_ _(_F_1_0_)_
The text string in this parameter is, if received, sent to the
parent (s) in a print message (first 21 bytes) (opmess).
Sent (SFT): if assigned in REQ
Accepted (SFT, RPOS, RNEG, STOP): if received, an opmess is
sent.
M_o_n_i_t_o_r_ _M_e_s_s_a_g_e_ _(_F_8_-_F_9_)_
The text string of this parameter is supposed to contain
M_m_m_ 8
<process name><sp><mess>
P_p_p_ 8
<mess> is 8 integers which are stored in a message buffer. When
received, the message is sent to the process called <process
name> (monitormess). In mess1 the bits 1 shift 12 and 1 shift 0
are removed.
The answer to the message is not reported.
Sent (STOP): if <process name> (=F8) is assigned in REQ
Accepted (STOP): if received, monitormess is sent.
S_p_e_c_i_a_l_ _o_p_t_i_o_n_s_ _(_F_1_4_)_
Sent (SFT): if one of 6 first bytes is assigned (not 0) in REG.
Accepted (SFT): any
F14 is not used by SFT.
A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_ _w_i_n_d_o_w_ _(_F_1_1_)_
Sent (SFT): Current value. Initial setting is system parameter
(appendix I), but may be assigned in REQ
Accepted (SFT, RPOS, RNEG): Any.
\f
6_._2_ _ _ _ _ _ _ _L_e_v_e_l_ _1_ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_ 6.2
The implementation follows ref. 3, and only a few remarks will
be added.
Some implementation details (state/event tables for sender and
reciever) can be found in appendix L.
Level 1 states are listed in appendix F.
S_e_n_d_e_r_
The level 1 data blocks contain (before diversion in subrecords -
see appendix O)
<zero><MS><mark><768 bytes><768 bytes>
In the last data block of a transfer, the last 768 bytes may be
omitted. Note, that level 1 compression is not done.
R_e_c_e_i_v_e_r_
The receiver accepts any format of the data blocks. One level 1
command may be inserted in a data block, and it must be an MS.
The mark is then understood to be a mark after all data of the
block.
The RR command is only issued after a TS reset.
If status error occurs on the disk file, which is written by the
receiver, QR is sent with proper status.
QR (ok) is never sent. If the sender sends more data than
expected, it is treated as a disk error. The sender may send less
data than expected, and the receiver accepts this and outputs
binary zero bytes in the rest of the file. Note that the file
size is negotiated in level 0 (kinship, first number = segments
of 768 bytes each).
\f
F_ 7_._ _ _ _ _ _ _ _ _I_N_S_T_A_L_L_A_T_I_O_N_ _G_U_I_D_E_ 7.
7_._1_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _R_e_q_u_i_r_e_m_e_n_t_s_ 7.2
The system is contained in 3 disc files, that are loaded on disc.
They require:
3 entries, permanent on disc
- bftu of 143 segments
- ftufunc of 123 segments
- startftu of 2 segments.
7_._2_ _ _ _ _ _ _ _P_r_e_r_e_q_u_i_s_i_t_e_s_
- Basis system release 2.0 or later.
(i.e. monitor release 6.0 or later).
Including MT Station, linked with blocklength of at least 4
segments.
- Algol release 11.0 or later
(only in case of maintenance of FTU)
- Network Port Module (NPM) - see ref 3.
7_._3_ _ _ _ _ _ _ _S_y_s_t_e_m_ _T_a_p_e_ 7.3
The system tape is generated with the utility program SAVE, and
has the following format (version 1.1):
\f
7_._4_ _ _ _ _ _ _ _I_n_s_t_a_l_l_a_t_i_o_n_ 7.4
File 1 of the systemtape should be loaded at system scope. The
following commands, performed at a console, will do (supposing
the systemtape is labelled mt80001):
ESC
att s
new chd size 40000 base -8388607 8388605 perm disc 1000 10 run
to chd
load mt80001.1
from s
pause chd mount mt80001
\f
ESC
att s
call 10 mt80001 start
---
---
Note, that no system parameters are assigned during installation.
Cfr. chapter 8.
7_._5_ _ _ _ _ _ _ _V_a_l_i_d_a_t_i_o_n_ 7.5
After load of the system tape, the 3 entries should be visible at
system scope, performing lookup:
lookup bftu ftufunc startftu
The entry tails (and shortclocks) are version dependant. In
version 1.0 the shortclocks will be:
bftu d.810721.2158
ftufunc d.810721.2140
startftu d.810721.1545
Further validation can be done at start up of FTU, see chapter 8.
\f
F_ 8_._ _ _ _ _ _ _ _ _O_P_E_R_A_T_I_N_G_ _G_U_I_D_E_ 8.
Before starting the FTU, consult chapter 9.
8_._1_ _ _ _ _ _ _ _P_r_o_c_e_s_s_ _S_t_a_r_t_ 8.1
From a console the following process is created. The process
parameters give the resource requirements (cf. ref. 7).
ESC
att s
new ftu the following commands
may be typed in one line
some may be skipped if set by "new".
size 25000 if bufno>1: + 3000*(bufno-1)
buf 15 if bufno>1: +2*(bufno-1)
area 7
temp disc 0 4 for c, v and FP
perm disc2 100 10 for log file, current output.
cf. chapter 9 about disc resources.
base 81 81 cf. chapter 9 about bases
project 80 89 and access rights.
run
ready
to ftu
\f
8_._2_ _ _ _ _ _ _ _C_a_l_l_ _o_f_ _F_T_U_ _P_r_o_g_r_a_m_ _(_b_f_t_u_)_
A program call is found in the system file Startftu. It may be
changed by editing the file. All possible call parameters are
stated in startftu, and a description is found in appendix I.
Current output (which is diminutive if not testoutput is wanted)
may be directed to a discfile by the FP command:
mode 1.yes
If the FTU is intended to run for more than a day, this should
not be done, as resource problems may happen on current output.
Now the program bftu is called by the FP command:
i startftu
(If you have edited startftu to another file, say "startx", you
should type "i startx"). The FTU does not require the NPM module
to be running before the program is called.
\f
The file startftu has the following content (version 1.1):
; centernet rc8000 file transfer utility
; start up instruction for ftu
; att s
; new ftu size 25000 (+3000 for bufno=2)
; buf 15 (+2 for bufno=2)
; perm disc2 100 10
; base 81 81 project 80 89 run
;
; maybe:mode 1.yes = current output to udftu
; i startftu
;
mode list.yes
logftu = set 30 disc2
udftu = set 30 disc2
scope user logftu udftu
rubout user logftu udftu
if 1.yes
o udftu
bftu,
npm. npm1 , name of npm process
nsubscr. him , host interface module
rmask. 255.255.255.255, reciever mask for ftu
bufno.2 , double-buffered traffic
log.logftu , name of log file
timeout.100 , when waiting, after 100-200 seconds
ackw.4 , acknowledge window, level 1
updmark.1001 , set in tail when writing file
, test1 , dump at all events in level 1
, test2 , dump in level0, algol alarm outp.(trapmode)
, test3 , progr. end at stopmess, printout at dump
, test4 , printout at all NPM mess-answ
;
mode all.no
o c
\f
8_._3_ _ _ _ _ _ _ _O_p_e_r_a_t_o_r_ _I_n_t_e_r_a_c_t_i_o_n_ _D_u_r_i_n_g_ _O_p_e_r_a_t_i_o_n_ 8.3
The operator should t_a_k_e_ _n_o_ _a_c_t_i_o_n_s_ during operation.
8_._3_._1_ _ _ _ _ _P_r_i_n_t_o_u_t_s_ _o_n_ _C_u_r_r_e_n_t_ _O_u_t_p_u_t_ 8.3.1
During normal operation, algol alarms may be printed. This will
normally indicate a program error. On a new alarm, the following
is printed
hh mm ss: alarm: <-time
<alarm text> <param> <-from algol system
If the alarm is on a document (including the NPM module), the
following is added:
devicestatus on <doc>: status=<status> = <bits>
An alarm includes parent break.
8_._3_._2_ _ _ _ _ _P_r_i_n_t_o_u_t_s_ _f_r_o_m_ _s_ _o_n_ _P_r_i_n_t_ _M_e_s_s_a_g_e_s_ 8.3.2
A print message will be printed by s on the console where the FTU
process is started.
FTU sends a parent message (print) (cf. ref 8) in the following
situations:
1. If the level0 parameter operator message (F10) is recieved and
accepted, the following 2 lines are output:
message <ftu> hhmmss<nui>
message <ftu> <operator message>
\f
where hhmmss is the time in 6 digits (printed as one integer)
and <nui> is the first 18 bytes of the network user id
recieved in connect request (or assigned in REQ).
2. When FTU is stopped, one of the following messages is sent:
message <ftu> hhmmss stopped by mess
message <ftu> hhmmss stop by npmerr
message <ftu> hhmmss stopped by error
3. When the FTU program ends, one of the following messages is
sent:
message <ftu> hhmmss breaked by parent
message <ftu> hhmmss end on error
8_._4_ _ _ _ _ _ _ _O_p_e_r_a_t_o_r_ _T_e_r_m_i_n_a_t_i_o_n_ _o_f_ _F_T_U_ 8.4
Before the operator terminates the operation of FTU, he might
check that no transport is active. Consult ref. 6.
Anyway, the FTU may terminate at any time.
The operator terminates the FTU by the command:
ESC
att s
proc <ftu> break
It is vital to break the FTU in order to perform the "closeport"
operation before program end.
\f
Now the operator may clean up, for example:
to ftu
lp = copy udftu
udftu segm 7 -----
lp segm 7 -----
finis
from s
pause ftu finis
esc
att s
proc ftu remove
ready
\f
F_ 9_._ _ _ _ _ _ _ _ _F_T_U_ _A_C_C_E_S_S_ _T_O_ _D_I_S_C_ _F_I_L_E_S_ 9.
A disc file involved in a transfer must be accessible for FTU.
This is checked before the transfer is started, and if any of the
operations does not succeed, the transfer is not started.
The operations involved in the checking are (in the order men-
tioned):
- set catalog base (to entry base of file)
- lookup entry
- create area process
- reserve area process
- if level 1 reciever:
change entry (file size and tail same as sender file).
The results of the operations is listed in appendix G.
The general restriction in which files the FTU may access is
expressed in the process parameters maxbase and standard base set
at process start. The file protection rules are described in ref.
9 and 10.
The disc resources of the FTU process (bs claims: segments on a
logical disc) may be changed in the changeentry operation. The
claims may either be augmented or decreased with a number of
slices on the logical disc in question.
The permanent key of the file is not relevant to the FTU. But if
the operating system BOSS2 is performing a job finish on a job
with user base containing the base of a temporary file involved
in a transfer, this will lead to a "bossfault".
The situation occurs if a BOSS job creates a temporary file and
sends a transport request to FTU, and does not await the termi-
nation of transport.
\f
F_ 1_0_._ _ _ _ _ _ _ _M_A_I_N_T_E_N_A_N_C_E_ _I_N_F_O_R_M_A_T_I_O_N_ 10.
File 2 on the system tape (chapter 7.3) contains the files needed
for maintenance. The source texts and their comments should be
studied to get the details. This chapter contains some overviews
and the basic mechanisms used.
1_0_._1_ _ _ _ _ _ _F_T_U_ _P_r_o_g_r_a_m_ 10.1
The file "tftu" contains the source text. During algol
compilation, the source "field2" is included. The algol compiler
is called like this:
bftu = algol tftu list.no
1_0_._1_._1_ _ _ _ _B_l_o_c_k_ _S_t_r_u_c_t_u_r_e_ _a_n_d_ _P_r_o_c_e_d_u_r_e_s_ 10.1.1
begin outer block
declare system parameters
begin block for reading FP parameters
procedure fpkey (key)
procedure fpname (no, val)
procedure fpno (no, val)
procedure fperr
. . . . read FP parameters
end
begin main block
declare main block variables
M_m_m_ declare fields for FTD
algol copy.field2
P_p_p_ procedure init fields
procedure dump (lab)
procedure dump-b (z,s,b)
procedure dump-data (lab, zix, hw) \f
procedure checknpm (z, strict)
procedure emptyout
procedure checkalarm
procedure maybetrap
procedure opmess (m)
procedure ftuopmess (text)
procedure answer-it (mb, code, res)
procedure recieve (x, func)
procedure send (z, hw, x)
procedure get-ready-outzone (x)
procedure set-file (z, area, mess, ta)
procedure next-event (evt, dex)
procedure init-ftd (pq)
procedure check-ftd
procedure answer-all (opres)
procedure set-skip (i1, i2, i3, i4, i5, i6, i7)
procedure closeport
procedure openport (res)
procedure ftu-ready
procedure send-sc (func, res, val)
procedure call-level0 (pq)
procedure read-level0 (z, by, err)
procedure write-level0 (cmd)
procedure pack-subrecords (zo, outhw, z1, inby)
procedure reset (z)
procedure set-read (z)
procedure correct (z, byno, val)
procedure p (result)
procedure exit-p (res, st)
procedure q (result)
procedure q-next event (got, exp)
procedure exit-q (res, st)
procedure sender (result)
procedure s-block (z, s, b)
procedure sendlevel1-s (com, arg)
procedure set-event-s (ev)
\f
procedure reciever (result)
procedure set-event-r (evt)
procedure send-level1-r (com, arg)
procedure r-block (z, s, b)
procedure read-level1 (z, by, c)
.... initializations
.... body of main block (label: waiting-for-start)
.... end of FTU program
end
end
1_0_._1_._2_ _ _ _ _P_r_o_t_o_c_o_l_ _P_r_o_c_e_d_u_r_e_s_ 10.1.2
The protocol levels are all handled by dedicated procedures, and
the figure below gives the overview of the levels (who is calling
who).
\f
FTU not started body of main block
waiting for start:
- wait for start message
- open port
Started, ftu _ready
no transport wait for:
- trsp req or connect req
(check file) (connect accept)
(connect req)
(P) (Q)
call _level0
call p call q
- disconnect
session
P Q
- Perform level0 as P - Perform level0 as Q
- call level 1 - call level 1
- send level0 stop - await level0 stop
sender reciever
- Perform level1 - Perform level1
as sender as reciever
\f
The following procedures "assist" in performing the proper
protocols:
- Procedure send _sc
Used by ftu _ready and call _level0 for sending sc operations
concerning connect/disconnect.
- procedure readlevel0
- procedure writelevel0
- procedure pack _subrecords
Used by p and q (and sender: pack _subrecords) for reading and
writing level0 commands, and packing a datablock in subrecords.
- procedure reset
- procedure set _read
- procedure correct
Used by readlevel0 and writelevel0 for zone manipulations.
1_0_._1_._3_ _ _ _ _E_v_e_n_t_ _H_a_n_d_l_i_n_g_ 10.1.3
The central event handling is done by p_r_o_c_e_d_u_r_e_ _n_e_x_t_ _e_v_e_n_t_. The
procedure delivers the next event that happens. Next _event does
not return in case of generated or provoked alarms (see 10.1.4).
The event delivered is controlled by the g_l_o_b_a_l_ _a_r_r_a_y_ _s_k_i_p_. By
assigning to the skip array, next _event is told which events
should be delivered etc.
Array skip is interpreted as follows:
\f
I_n_d_e_x_ _ _ _C_o_n_t_r_o_l_s_ _ _ _ _ _ _ _ _ _ _ _ _V_a_l_u_e_s_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
1 Answer on 100 Special function: only
zi zones answer sense/status mess.
(input from net) 1 do not deliver event, take home
answer
0 deliver event
-2 do not deliver, no check
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
2 Answer on 1 do not deliver event, take home
answer
zo zones 0 deliver event
(output letter -2 do not deliver event, no check
to net) -3 do not deliver, only status check,
but control operations are
delivered (see send _sc)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
3 Start mess >0 Answer immediately,
if val > 10 then opres:=val -10
if val < 10 then result:=val
=0 deliver event
-1 skip mess
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
4 Stop mess as 3, adding:
-2 provoke alarm.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
5 Transport as 3.
mess
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
6 Abort mess as 3.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
7 Timeout 1 skip event
0 deliver event
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
1_0_._1_._4_ _ _ _ _A_l_a_r_m_ _H_a_n_d_l_i_n_g_ 10.1.4
All the protocol procedures are equipped with trap labels, catch-
ing algol alarms. Note that trapmode is assigned, omitting the
most frequent algol alarm printouts.
In all traplabels, the p_r_o_c_e_d_u_r_e_ _c_h_e_c_k_a_l_a_r_m_ is called, which
maybe prints an alarm printout, and assigns a value, so that the
calling procedure can detect the cause of the alarm, even if the
alarm had already occured at a "higher" level.
P_r_o_c_e_d_u_r_e_ _m_a_y_b_e_t_r_a_p_ takes care of provoking an alarm, hereby
reporting the alarm to the "lower" level.
The alarms thus reported include:
- parent break (trap value 9);
- NPM status error (trap value 11);
- stop message (trap value 13);
1_0_._1_._5_ _ _ _ _N_e_t_ _A_c_c_e_s_s_ 10.1.5
The net is accessed via the NPM module. The following zones are
opened to npm:
z_o_n_e_ _a_r_r_a_y_ _z_i_:
The number of zones is bufno+1. One zone is always pending,
because an event-control operation is pending at SC. The others
are used for recieve-letter.
P_r_o_c_e_d_u_r_e_ _r_e_c_i_e_v_e_ sets up an input mess.
P_r_o_c_e_d_u_r_e_ _c_h_e_c_k_n_p_m_ is used for checking the answer.
I_n_t_e_g_e_r_ _a_r_r_a_y_ _b_u_f_z_i_ contains the message buffer addresses.
z_o_n_e_ _a_r_r_a_y_ _z_o_:
The number of zones is bufno. All are used for sending letters.
P_r_o_c_e_d_u_r_e_ _s_e_n_d_ sets up output mess.
P_r_o_c_e_d_u_r_e_ _c_h_e_c_k_N_P_M_ is used for checking the answer.
P_r_o_c_e_d_u_r_e_ _g_e_t_ _r_e_a_d_y_ _o_u_t_z_o_n_e_ is used for finding a free (not
pending) zone.
I_n_t_e_g_e_r_ _a_r_r_a_y_ _b_u_f_z_o_ contains the message buffer addresses.
\f
z_o_n_e_ _z_c_o_n_t_r_:
Used for sending control operations to SC (all but letters).
P_r_o_c_e_d_u_r_e_ _s_e_n_d_ _s_c_ is used for sending and recieving the output
message.
The recieving is done by next _event, which in turn calls
checknpm.
I_n_t_e_g_e_r_ _b_u_f_c_o_n_t_r_ contains the message buffer address.
P_r_o_c_e_d_u_r_e_ _o_p_e_n_p_o_r_t_ _a_n_d_ _c_l_o_s_e_p_o_r_t_.
Use local zones for the messages.
Openport also prepares the zones zo and zi.
1_0_._1_._6_ _ _ _ _L_e_v_e_l_0_ _P_a_r_a_m_e_t_e_r_ _M_a_p_p_i_n_g_ 10.1.6
When reading/writing level0 commands, the parameters are mapped
between FTD and the recieved/sent data blocks. The mapping is
described in appendix M. The mapping is controlled by 6 parallel
arrays of 17 elements:
e _qualif: expected qualifiers when reading
r _qualif: qualifiers actually read
w _qualif: qualifiers to write (if <> 0)
attr : attribute numbers in FTP
format : coding for the mapping, as in appendix M.
faddr : field address in FTD, always "array field"
value.
1_0_._2_ _ _ _ _ _ _G_e_n_j_o_b_ 10.2
The file genjob on system tape contains a BOSS2 job for
generating the fields, that are used for adressing FTD.
The field descriptions are coded, and an ad hoc program is used
for writing the contents of the files
field1 (for program FTUFUNC)
field2 (for program BFTU)
\f
This mechanism ensures, that the two programs work on the same
field addresses, and is easy maintainable. New fields can easily
be added (note that the first fields are used extensively by FTU,
(see 10.1.6).
1_0_._3_ _ _ _ _ _ _T_e_s_t_ _o_f_ _F_T_U_ _u_n_d_e_r_ _B_O_S_S_2_ 10.3
The files tprog
ftujob
on the system tape can be used for testing the functions of FTU
under BOSS2.
tprog:
contains program text of a program simulating the net (i.e. npm
process) by generating 3 child processes:
- an FTU as p.
- an FTU as q.
- a requester.
ftujob:
The BOSS2 job running the test.
\f
F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.
1 RCSL No 43-GL10190:
CN System Specifications section 9.2
2 RCSL No 43-GL11341:
CN RC8000 Network Access
Programming Guide
3 RCSL No 43-GL11417:
CN RC8000 Network Port Module - NPM
Reference Manual
4 CENTERNET
CN Session Control
Programming Guide
5 RCSL No 43-GL11401:
CN File Transfer Protocol - FTP
Report
6 RCSL No 43-GL11294:
CN RC8000 File Transport Utility - FTU
User's Guide
7 RCSL No 31-D595:
RC8000 Operating System S
Reference Manual
8 RCSL No 31-D610:
Parent Messages in RC8000
9 RCSL No 31-D476:
RC8000 Monitor, Part 1
10 RCSL No 31-D477:
RC8000 Monitor, Part 2
11 RCSL No 31-D106:
RC8000 System 3 Utility Programs, Part 1
\f
F_ B_._ _ _ _ _ _ _ _ _F_O_R_M_A_T_ _O_F_ _T_H_E_ _F_I_L_E_ _T_R_A_N_S_P_O_R_T_ _D_E_S_C_R_I_P_T_I_O_N_ _(_F_T_D_)_ B.
The following pages show the layout of the FTD. The same layout
is used in 3 situations:
1. as data blocks in REQ, abort and get status messages.
2. when creating and interpreting level 0 commands (see section
6.1 and appendix M)
3. The dump records on the log file.
Legend:
NO: Field number, referred to in chapter 6.
TYPE: Type of field, controlling the ALGOL variable used
to reference the field, and used when printing the
logfile (see ref. 6).
FIELD VALUE: The value assigned to the ALGOL field variable.
BASE ADR: Halfword index of the halfword just before the
field.
HW: Number of halfwords occupied by the field.
CHARS: Number of characters or 8 bit bytes occupied by the
field.
Fields F1-F20 are described in chapter 6 and section 5.2.
Among the rest, the most interesting fields are delivered in
answers to FTU messages (see appendix C).
Remaining fields of external interest are:
F61 R _FILESTATUS: The logical statusword received on an output to
disk file
F62 PROGLAB: A text telling the state at the last update of
the FTD (and log file).
F65 T _DATE: Date of last update.
F66 T _TIME: Time of last update.
F67 T _CPUTOT: CPU time used by FTU since process start.
F68 T _CPU _TRSP: CPU time used in current/last transport.
F69 T _REAL _TOT: Real time spent since FTU process start.
F70 T _REAL _TRSP: Real time spent in current/last transport.
F71 BLOCKSTOT: ALGOL program segments read since FTU program
start. \f
F72 BLOCKSTRSP: ALGOL program segments read in current/last
transport. \f
F_
\f
F_
\f
F_ C_._ _ _ _ _ _ _ _ _F_O_R_M_A_T_ _O_F_ _A_N_S_W_E_R_S_ _T_O_ _F_T_U_ _M_E_S_S_ C.
R_E_S_U_L_T_: 1 = OK
2 = Reject: FTU reserved by another process
3 = Unintelligible: Unknown operation
4 = (not used)
5 = FTU process does not exist (set by the monitor)
A_N_S_W_E_R_ _F_O_R_M_A_T_:
(1) + 0 OPRES (0 = OK) (appendix D)
(2) + 2 hw transferred = 0 in answers to
(3) + 4 bytes transferred start/stop mess
(4) + 6 bytes moved in transport
(5) + 8 FTU state (appendix P)
(6) +10 <level 1 state> shift 16 + <level 0 state> (appendices E+F)
(7) +12 set file result (appendix G)
or(- in case 0PRES = 0 and no transport is active):
1 shift 23
add (<cpu secs used in last transp.> shift 12)
add (<realtime secs used in last transp.>)
(8) +14 NPM status
- Bytes moved in transport: If no transport is active, the
resulting bytes of last transport.
- NPM status: logical statusword of a not-ok answer to a message
to NPM, calculated thus:
if <monitor-result> <>1 then (1 shift <monitor-result>)
else 2 + answ(1).
\f
F_ D_._ _ _ _ _ _ _ _ _O_P_R_E_S_ _V_A_L_U_E_S_ D.
V_A_L_U_E_S_ _O_F_ _O_P_R_E_S_ _P_A_R_A_M_E_T_E_R_ _I_N_ _A_N_S_W_E_R_S_ _T_O_ _F_T_U_ _M_E_S_S_
Relevant in FTU mess:
OPRES Meaning trp. Abort Start Stop
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _m_e_s_s_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
0 OK + + + +
1 Connect not OK +
2 NPM status error + + + +
3 FTU in state stopped + +
4 FTU busy in transport +
5 Local file not OK +
6 RNEG received +
7 Not current transport +
8 No transport +
9 Terminated (in level 0) +
10 Aborted (in level 0) +
11 FTU process breaked by parent + + + +
12 Block length (block too small) + +
13 Sending process stopped + +
14 SC error +
15 FTU program error +
16 Result not OK
17 FTU stopped by mess + +
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
F_ E_._ _ _ _ _ _ _ _ _L_E_V_E_L_ _0_ _S_T_A_T_E_ _S_E_T_T_I_N_G_S_E.
L_E_V_E_L_ _0_ _S_T_A_T_E_ _O_F_ _T_R_A_N_S_F_E_R_ _-_ _A_R_G_U_M_E_N_T_ _T_O_ _R_N_E_G_ _A_N_D_ _S_T_O_P_ _C_O_M_M_A_N_D_S_
G_R_O_U_P_:_ _ _ _ _ _ _ _ _H_E_X_:_ _ _ _ _ _ _D_E_C_:_ _ _ _ _ _ _E_X_P_L_:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
V_I_A_B_L_E_ 0000 0 OK
R_E_J_E_C_T_E_D_ 1000 4096 Unexpected qualifier
1001 4097 See textmessage
1002 4098 Code binary not set
1003 4099 Mode of access not ok
1004 4100 Protocol ident not ok
1011 4113 File not found (maybe not exist)
1012 4114 No access to file quoted (reserved)
101A 4122 Size too big (no resources for extend)
101C 4124 Kinship missing (file tail)
T_E_R_M_I_N_A_T_E_D_ 2000 8192 OK
2001 8193 Problem - see text message
2002 8194 RNEG without state received (P only)
A_B_O_R_T_E_D_ 3000 12288 Satisfactory and incomplete -
only level 1 no retry required
3002 12300 Receiver problems
3004 12302 Sender problems
3005 12303 Time out (level 1)
A_B_O_R_T_E_D_
STATE:
3xxx 12288 in level 1
4xxx 16384 sending SFT
5xxx 20480 awaiting RPOS/RNEG
6xxx 24576 Sending STOP
7xxx 28672 awaiting SFT (and processing it)
8xxx 32768 awaiting GO
9xxx 36864 awaiting STOP
\f
G_R_O_U_P_:_ _ _ _ _ _ _ _ _H_E_X_:_ _ _ _ _ _ _D_E_C_:_ _ _ _ _ _ _E_X_P_L_:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
ABORTED (cont.)
CAUSE:
xxx7 +7 Abort mess
xxx8 +8 Stop mess
xxx9 +9 Parent break of FTU process
xxxA +10 Protocol error (level 0 command)
xxxB +11 Program error (level 0)
xxxC +12 Timeout (level 0)
xxxD +13 Disconnect
xxxE +14 NPM Status error (not sent)
xxxF +15 SC result not ok (not sent)
\f
F_ F_._ _ _ _ _ _ _ _ _L_E_V_E_L_ _1_ _S_T_A_T_E_ _S_E_T_T_I_N_G_S_ F.
L_E_V_E_L_ _1_ _S_T_A_T_U_S_ _-_ _A_R_G_U_M_E_N_T_ _T_O_ _C_O_M_M_A_N_D_S_ _E_S_-_Q_R_-_E_R_-_
GROUP: HEX: DEC: EXPL: USED BY:
O_K_ 00 0 OK ESok -> ERok
QRok -> ESok -> ERok
E_R_R_O_R_ -Detected by receiver: QRe ->ESe -> ERe
20 32 Receiver error -
retry possible (progr error)
21 33 Receiver error -
no retry possible (parent break)
22 34 Protocol error detected by receiver
23 35 STOP mess to receiver
24 36 ABORT MESS to receiver
25 37 Hard error on disk
26 38 End of file - too much data sent
- Detected by sender: ESe -> ERe
28 40 Sender error -
retry possible (progr error)
29 41 Sender error -
no retry possible (parent break)
2A 42 Protocol error detected by sender
2B 43 STOP mess to sender
2C 44 ABORT MESS to sender
2D 45 Hard error on disk
A_B_O_R_T_ - Done by receiver: TIMEOUT QRa -> -
30 48 -awaiting data
31 49 -after sending RR, awaiting SS
32 50 -after sending QRok, awaiting ESok
33 51 -not used
34 52 -after sending QRe, awaiting ESe
35 53 -after GO, awaiting first SS
36 54 -NPM status error occured (not sent)
\f
GROUP: HEX: DEC: EXPL: USED BY:
- Done by sender: TIMEOUT ESa -> -
40 64 -awaiting MR
41 65 -after TS reset, awaiting RR
42 66 -after sending ESok, awaiting ERok
43 67 -after sending ESe, awaiting ERe
k)
46 70 NPM status error occurred (not sent) \f
F_ G_._ _ _ _ _ _ _ _ _S_E_T_-_F_I_L_E_ _R_E_S_U_L_T_ _V_A_L_U_E_S_ G.
Set-file result reflects the success of the initial attemps to
access a file involved in a transfer.
Result = 0 is OK.
Not ok is:
1*SETCATBASE
+ 10*LOOKUPENTRY
+ 100*CREATEAREA
+ 1000*RESERVEPROCESS
+ 10000*(RESULT _OF _WAITANSWER -1)
+ 100000*CHANGEENTRY
Setcatbase: 0 Catalog base set
2 (-) State of child process does not permit
modification
3 (-) Process does not exist, not internal,
not child
4 New base illegal
5 (-) Name format illegal
lookupentry: 0 Entry look up
2 Catalog input/output error
3 Entry does not exist
6 Name format illegal
7 (-) Maincat not present
createarea: 0 Area process created
1 Area claims exceeded
2 Catalog i/o error, state of document
does not permit this call
3 Entry not found
4 Entry does not describe an area
6 (-) Name format illegal
\f
reserveprocess: 0 Process reserved
1 Reserved by another process
2 Process cannot be reserved
3 Process does not exist, calling process
not user
result _of _
waitanswer: 1 Normal
(on sense mess) 2 Rejected
3 Unintelligible
4 Disconnected
5 Receiver does not exist
changeentry: 0 Entry changed
2 Catalog i/o error, document not ready
3 Entry not found
4 Entry protected: entry base not con-
tained in max base of calling process
5 Area process reserved by another process
6 Name format or new size illegal, claims
exeeded
7 Maincat not present
\f
F_ H_._ _ _ _ _ _ _ _ _D_I_S_C_O_N_N_E_C_T_ _C_A_U_S_E_ _V_A_L_U_E_S_ H.
The CAUSE is one byte delivered in SC operations disconnect
request, disconnect accept, disconnect reject and abort session.
The following values are assigned to CAUSE by FTU:
- in disconnect request: cause = 0
- in disconnect accept: cause = 0
- (disconnect reject never sent by FTU)
- in abort session:
cause = 9: program error
(10) not used)
= 11: timeout awaiting disconnect
= 12: letter recieved was not ok from SC (SC result
<> 0)
= 13: disconnect request was not processed ok by SC
(SC result <> 0).
\f
F_ I_._ _ _ _ _ _ _ _ _S_Y_S_T_E_M_ _P_A_R_A_M_E_T_E_R_S_ I.
The system parameters are set at program call time as parameters
to the program call:
npm.<npm> name of NPM. Default: npm
log.<logfile> name of logfile. Default: ftulog
timeout.<secs> seconds in timeout. Used when awaiting
data/command from the remote end. If nothing
arrives, timeout will occur in the time interval
between <timeout> and 2*<timeout> seconds.
Default value: 3.
updmark.<val> value for updatemark (integer). Used when writing
(receiving) a file. During writing, <updmark> is
placed in the catalog entry, in tail (7) instead
of the proper value, which is placed if the
transport terminates successfully.
Default value: 1001.
ackw.<val> acknowledgement window used in level 1, if not set
in transport mess or changed by the remote end.
Default value: 3.
nsubscr.<him> name of HPM subscriber, used at open port.
Default: him.
rmask.<r1>.<r2>.<r3>.<r4>
receivermask used at open port. 4 numbers, stored
in 4 bytes.
Default: 0.1.0.1.
bufno.<val> the number of buffers of 1998 bytes each used for
recieve-letter and send-letter operations,
respectively. During a transport (session), all
recieve-buffers are attempted waiting for input,
and if FTU is in the role of sender, all
send-buffers are attempted sent. The FTU allocates
<val>+1 buffers for input, the extra is used for
event-control.
\f
F_ J_._ _ _ _ _ _ _ _ _S_U_R_V_E_Y_ _O_F_ _L_E_V_E_L_ _0_ _C_O_M_M_A_N_D_S_ J.
NAME CODE FORMAT USED BY
(HEX) (before dividing in subrecords)
CMD PAR
(DEC) CNT
SFT 04 4 <n> PARAMETERS P
RNEG 03 3 <n> PARAMETERS Q
RPOS 02 2 <n> PARAMETERS Q
GO 01 1 0 P
STOP 00 0 <n> PARAMETERS P
\f
F_ K_._ _ _ _ _ _ _ _ _S_U_R_V_E_Y_ _O_F_ _L_E_V_E_L_ _1_ _C_O_M_M_A_N_D_S_ K.
The FORMAT shown is before divinding in subrecords.
NAME CODE FORMAT USED
_ _ _ _ _ _(_H_E_X_)_ _(_D_E_C_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _B_Y_ _ _ _ _
HEAD CMD ARG S
SS 40 0 64 0
Start of data
MS 41 0 65 MARK S
Mark sender (placed in first
par of data blocks)
ES 43 0 67 State1 S
End sender
RR 44 0 68 MARK R
Restart request
MR 45 0 69 MARK R
Mark Ackn
QR 46 0 70 State1 R
Quit
ER 47 0 71 State1 R
End ackn
\f
F_ L_._ _ _ _ _ _ _ _ _L_E_V_E_L_ _1_ _S_T_A_T_E_/_E_V_E_N_T_ _T_A_B_L_E_S_ L.
\f
F_ \f
F_ M_._ _ _ _ _ _ _ _ _D_E_T_A_I_L_S_ _O_N_ _L_E_V_E_L_ _0_ _P_A_R_A_M_E_T_E_R_S_ M.
The table below shows all transport paramteters, as stored in
FTD, and shows the mapping into FTP parameters.
Field Field Used Form Format Qualifier Base
No Var Attr in FTD used in addr
_ _ _ _ _ _C_o_n_t_e_n_t_s_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_F_T_ _ _ _ _o_t_h_e_r_ _ _ _ _ _ _
F1 Mode of access moa 1 W -1 42 42 0
2=Replace P->Q
130=Read only Q->P
F2 Local file name lname -1/64 t11 8<12+2 0 50 2
F3 Local file scope
(low-up) lscope 2w 10
F4 Remote file name rname 64/-1 t11 8<12+2 50 50 14
F5 Remote file scope
(low-up) rscope 2w 22
F6 Remote HOST IDENT rhost -1 t23 16<12 0 0 26
F7 Remote XMIT MASK rxmask -1 t4 4<12 0 0 42
F8 Monitor message:
name mname 113 t11 8<12+8 0 58 46
F9 contents mmess 8w 54
F10 Operator message opm 112 t23 16<12 58/0 58 70
F11 Ackn. window ackw 10 w -1 42 42 86
F12 User name uname 66 t41 24<12 50/0 50 88
F13 Account acc 74 t23 16<12 50/0 50 112
F_1_4_ _ _ _ _S_p_e_c_i_a_l_ _o_p_t_i_o_n_s_ _ _ _s_p_e_c_i_a_l_ _ _ _1_2_8_ _ _ _ _t_4_1_ _ _ _ _2_4_<_1_2_ _ _ _5_8_/_0_ _ _ _5_0_ _ _ _ _1_2_8_
F15 File size fsize 96 w -1 42 42 152
F16 Kinship (filetail)tail 70 10w 0<12+10 178/50 50 154
F17 Facilities facil 14 w -1 171 42 174
F18 Codes codes 2 w -1 171 42 176
F19 Protocol ident protocol 0 w -1 42 42 178
F_2_0_ _ _ _ _S_t_a_t_e_ _o_f_ _t_r_a_s_f_e_r_ _ _s_t_a_t_e_s_ _ _ _ _1_5_ _ _ _ _ _w_ _ _ _ _ _ _-_1_ _ _ _ _ _ _0_ _ _ _ _ _ _4_2_ _ _ _ _1_8_0_
F21 Level 0
role (P or Q) role0 w 182
F22 Level 1
role (R or S) role1 w 184
\f
L_e_g_e_n_d_:
Field No: as in appendix B.
Contents: FTP name
Field var: FTD name
Used attr: Level 0 attribute number or -1 (no attribute)
Base adr: field address of the field in FTD. Always array
field, i.e. an integer parameter is referenced
ftd.<faddr-val>(1)
format: describes the format of the attribute:
-> -1: one integer (16 bits number in FTP)
-> thw <12:
an IA5 text string. thw halfwords, i.e. max
thw*3//2 characters.
-> thw <12 + nws:
1) an IA5 text string of max thw halfwords. When
read in FTP it is interpreted as a name, i.e.
the first sequence of number and letters,
terminated by a delimiter. When written in FTP,
all chars (until NULL) are output.
2) nws numbers follow, in FTP both read and
written as IA5 text separated by delimiters
(minus sign may occur). In FTD, the numbers are
stored in integers just after the thw halfwords
of text.
3) the total field is in FTP taken as one
parameter (attribute), i.e. one IA5 string.
qualifier used:qualifier value used (decimal)
form in FTD: type of field content.
\f
Q_U_A_L_I_F_I_E_R_ _D_E_C_O_D_I_N_G_
The following is mostly a repetition of FTP.
bit: 7 6 5 4 3 2 1 0
decimal values -> 128 64 32 16 8 4 2
HEX DEC
M_O_N_I_T_O_R_ (P only)
00 + 0 - not in reply
80 +128 - Include in reply
F_O_R_M_A_T_ _O_F_ _V_A_L_U_E_
80 or 00 + 0 - Attribute unknown
90 or 10 + 16 - Attr. value absent
A0 or 20 + 32 - Number (2 bytes)
B0 or 30 + 48 - Alpha (IA5 string)
T_Y_P_E_ _O_F_ _P_A_R_A_M_E_T_E_R_
08 + 8 - Modify: change current
value - constraints below not checked
00 + 0 - Select: value controls in reading
selection of an entry
O_P_E_R_A_T_O_R_
Make (take) a new attr. value. It is successful if
(new attr. value) <operator> (parameter val) is
true.
For strings:
0A or 02 + 2 - EQ Equal +
0B or 03 + 3 - LE Less than or equal
05 or 05 + 5 - NE Not equal +
0E or 06 + 6 - GE Greather than or equal
0F or 07 + 7 - ANY Any value acceptable +
\f
W_r_i_t_i_n_g_ _a_t_t_r_i_b_u_t_e_s_ _i_n_ _l_e_v_e_l_ _0_
text (both pure text and names):
all bytes of the field in FTD are output (all 8 bit)
regardless of their contents.
numbers: output by write (layout << d>) i.e. a space followed by
(maybe) minus sign and digits.
R_e_a_d_i_n_g_ _a_t_t_r_i_b_u_t_e_s_ _i_n_ _l_e_v_e_l_ _0_
Unknown attributes (i.e. the attribute value not mentioned in the
table introducing this app.) are skipped (even if monitor bit is
set).
Qualifier checked:
- no value: no value taken. If monitor bit set,the value
is returned.
- number: check to expected qualifier
- text: check to expected qualifier
- type: irr
- operator: checked to expected qualifier
- if not ok: State 1002 is returned (in RNEG)
Interpret text: (follows contents of format)
- pure text: all bytes moved as (byte extract 7) unused
bytes in FTD are zero set (NULL)
- name: read with procedure readstring, skipping
delimiters in front, reading until delimiter.
valid bytes: small letters and numbers. NULL
and DEL are blind.
- numbers: read with procedure read. Alphabeth allows
plus or minus in front, and digits. Delimiters
in front are skipped.
\f
F_ N_._ _ _ _ _ _ _ _ _L_O_G_ _F_I_L_E_ _E_V_E_N_T_S_ _A_N_D_ _R_E_C_O_R_D_S_ N.
The log file is used to log events of history from FTU. A log
record is one segment. The file is written segment by segment
cyclically.
A log record is written (contents of field p_r_o_g_l_a_b_ in paranthesis):
- at start of FTU program (start-ftu)
- when FTU is stopped (ftu-stopped)
- when transport stop occurs, as described in 3.1.1 (trsp-stop)
- when an alarm occurs (alarm).
This includes: - parent break
- status error recieved from NPM
- result <> 0 from SC on letters sent,
- stop message recieved
- program errors
- when a disc error occurs in level 1 reciever (filestatus)
The format of the log record is exactly all fields of FTD.
\f
F_ O_._ _ _ _ _ _ _ _ _D_I_V_I_S_I_O_N_ _O_F_ _D_A_T_A_ _B_L_O_C_K_S_ _I_N_ _S_U_B_R_E_C_O_R_D_S_ O.
Before sending a block (letter), it is divided in sub-records,
thus b denotes data bytes, h header bytes
h = 2 (or =0 in level 1 commands)
b1
b2
h = 1
b3
h = 2
b4
b5
h = 60
b6
b7
.
.
.
b65
h = 1
b66
h = 2
b67
b68
h = 60
b69
b79
.
.
.
etc. until no more data bytes.
The last header has the EOR bit set. After the last
subrecord, one or two dummy bytes may be transmitted in
order to stick to the word boundaries of RC8000.
\f
F_ P_._ _ _ _ _ _ _ _ _F_T_U_ _S_T_A_T_E_ _S_E_T_T_I_N_G_S_ P.
FTU STATE has the following format:
STATEPORT<8 + STATECON
S_T_A_T_E_P_O_R_T_ _v_a_l_u_e_s_ _(_d_e_c_i_m_a_l_)_:_ _ _ _ _ _ _ _ _ _ _ _
1: FTU not started
2: FTU stopped by stopmess
3: FTU stopped by parent break
4: stopped by npm error
5: stopped by program error
6: ready (port opened)
S_T_A_T_E_C_O_N_ _v_a_l_u_e_s_ _(_d_e_c_i_m_a_l_)_:_ _ _ _ _ _ _ _ _ _ _ _
1: not ready (no port)
2: waiting (port open, no connection)
3: called for connect
4: connected as q
5: calling for connect
6: connected as p
7: disconnecting
8: awaiting disconnect
9: aborting on program error
10: (not used)
11: aborting on timeout awaiting disconnect
12: aborting on letter recieved with SC result <> 0 (not ok)
13: aborting on disconnect request was not processed ok by SC
(SC result <> 0)
\f
«eof»