|
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: 128384 (0x1f580)
Types: TextFile
Names: »D78«
└─⟦a2495fc4f⟧ Bits:30005867/disk10.imd Dokumenter (RCSL m.m.)
└─⟦this⟧ »D78«
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. INTRODUCTION ........................................ 1
2. BASIC CONCEPTS ...................................... 2
2.1 Processes .................................... 4
2.2 Programs ..................................... 8
2.3 Messages - Answers ........................... 9
2.4 Initialization of the Descriptors ............ 11
3. MONITOR ............................................. 15
3.1 Monitor Descriptor ........................... 15
3.1.1 Running Queue ....................... 17
3.1.2 Process Chain ....................... 18
3.1.3 Device Table ........................ 19
3.1.4 Delay Queue ......................... 21
3.1.5 Program Chain ....................... 22
3.1.6 Free Core Area ...................... 22
3.1.7 The Dummy Process ................... 22
3.1.8 Area Process Chain .................. 23
3.1.9 Interrupt Mask ...................... 23
3.1.10 Real Time Clock ..................... 23
3.1.11 Power Failure ....................... 24
3.2 Monitor Functions ............................ 24
3.2.1 Function WAITINTERRUPT .............. 24
3.2.2 Function SENDMESSAGE ................ 26
3.2.3 Function WAITANSWER ................. 30
3.2.4 Function WAITEVENT .................. 32
3.2.5 Function WAIT ....................... 34
3.2.6 Function SENDANSWER ................. 35
3.2.7 Function SEARCHITEM ................. 37
3.2.8 Function BREAKPROCESS ............... 40
3.2.9 Function CLEANPROCESS ............... 42
3.2.10 Function STOPPROCESS ................ 43 \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_
3.2.11 Function STARTPROCESS ............... 44
3.2.12 Function RECHAIN .................... 44
3.3 Initialization of the Monitor ................ 47
3.4 Processor Expansion .......................... 48
4. DRIVER PROCESSES .................................... 49
4.1 Introduction ................................. 49
4.2 Device Handling .............................. 50
4.3 Driver Interface ............................. 54
4.3.1 Control Messages .................... 55
4.3.2 Transput Messages ................... 59
4.3.2.1 Input .................... 60
4.3.2.2 Output ................... 60
4.3.3 Answers ............................. 62
4.3.3.1 Answer ................... 62
4.4 System Utility Procedures .................... 66
4.4.1 Formats ............................. 66
4.4.2 Procedures .......................... 67
4.4.2.1 Procedure NEXTOPERATION .. 67
4.4.2.2 Procedure WAITOPERATION .. 71
4.4.2.3 Procedure RETURNANSWER ... 73
4.4.2.4 Procedure SETRESERVATION . 74
4.4.2.5 Procedure SETCONVERSION .. 75
4.4.2.6 Procedure CONBYTE ........ 75
4.4.2.7 Procedure GETBYTE ........ 76
4.4.2.8 Procedure PUTBYTE ........ 76
4.4.2.9 Procedure MULTIPLY ....... 78
4.4.2.10 Procedure DIVIDE ......... 79
4.4.2.11 Procedure SETINTERRUPT ... 79
4.5 Driver Requirements .......................... 81
4.5.1 Break Action ........................ 81
4.5.2 Device handling ..................... 82
4.6 Driver Incarnations .......................... 83 \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_
5. BASIC I/O HANDLING .................................. 86
5.1 General Description .......................... 86
5.2 Zone Format .................................. 90
5.3 Share Descriptor Format ...................... 93
5.4 Zone Setup ................................... 96
5.4.1 Zone Descriptor ..................... 96
5.4.2 Share Descriptor .................... 97
5.4.3 Message Buffer Pool Size ............ 97
5.5 Document Identification ...................... 99
5.6 Exception Handling ........................... 101
5.6.1 User Giveup ......................... 102
5.6.2 Giveup Procedure Example ............ 104
5.7 Repeat Actions ............................... 104
5.8 Basic I/O Procedures ......................... 107
5.8.1 Initialization Procedures ........... 109
5.8.1.1 Procedure OPEN ........... 109
5.8.1.2 Procedure SETPOSITION .... 110
5.8.1.3 Procedure WAITZONE ....... 111
5.8.1.4 Procedure CLOSE .......... 111
5.8.2 INPUT/OUTPUT Procedures ............. 114
5.8.2.1 Procedure TRANSFER ....... 114
5.8.2.2 Procedure WAITTRANSFER ... 115
5.8.2.3 Procedure INBLOCK ........ 116
5.8.2.4 Procedure OUTBLOCK ....... 118
6. RECORD I/O .......................................... 120
6.1 Physical/Logical Datablock ................... 120
6.2 Record-Formats ............................... 124
6.2.1 Undefined, Unblocked ................ 125
6.2.2 Undefined, Blocked .................. 126
6.2.3 Fixed, Unblocked .................... 126
6.2.4 Fixed, Blocked ...................... 127
6.2.5 Variable, Unblocked ................. 127 \f
iv
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_C_O_N_T_I_N_U_E_D_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
6.2.6 Variable, Blocked ................... 129
6.3 GETREC ....................................... 129
6.3.1 Procedure GETREC (Zone, Addr., Bytes) 129
6.3.2 Pseudo-Algol Description ............ 132
6.3.3 Programming Example ................. 137
6.4 PUTREC ....................................... 138
6.4.1 Procedure PUTREC (Zone, Addr., Bytes) 138
6.4.2 Pseudo-Algol Description ............ 141
6.4.3 Programming Example ................. 145
6.5 MOVE ......................................... 146
6.5.1 Programming Example ................. 148
7. CHARACTER I/O PROCEDURES ............................ 149
7.1 Single Character Procedures .................. 149
7.1.1 INCHAR .............................. 149
7.1.2 OUTCHAR ............................. 150
7.1.3 OUTSPACE ............................ 150
7.1.4 OUTEND .............................. 151
7.1.5 OUTNL ............................... 151
7.2 String Oriented Procedures ................... 152
7.2.1 OUTTEXT ............................. 152
7.2.2 OUTOCTAL ............................ 152
7.2.3 INNAME .............................. 153
7.3 Utility Procedures ........................... 153
7.3.1 DECBIN .............................. 153
7.3.2 BINDEC .............................. 154
7.4 Programming Examples ......................... 155
8. CATALOG SYSTEM ...................................... 156
8.1 Introduction ................................. 156
8.2 Catalog System Disc Structure ................ 157
8.3 Catalog System Procedures .................... 164
8.3.1 General ............................. 164 \f
v
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.3.1.1 Main Catalogs ............ 164
8.3.1.2 Sub Catalogs ............. 165
8.3.1.3 Procedure CREATEENTRY .... 165
8.3.1.4 Procedure REMOVEENTRY .... 167
8.3.1.5 Procedure LOOKUPENTRY .... 168
8.3.1.6 Procedure CHANGEENTRY .... 170
8.3.1.7 Procedure SETENTRY ....... 171
8.3.1.8 Procedure INITCAT ........ 174
8.3.1.9 Procedure NEWCAT ......... 175
8.3.1.10 Procedure FREECAT ........ 176
8.4 Catalog File INPUT/OUTPUT .................... 178
8.4.1 Procedure OPEN ...................... 178
8.4.2 Procedure SETPOSITION ............... 181
8.4.3 Procedure CLOSE ..................... 181
8.4.4 Catalog Input/Output ................ 181
APPENDIX
A. REFERENCES .......................................... 185
B. TERMINOLOGY ......................................... 187
C. DEVICE CODES ........................................ 191
D. FIRST AND SECOND PAPER TAPE PUNCH DRIVERS ........... 194
\f
vi
F_O_R_E_W_O_R_D_
This publication is to superseed the one currently in use:
44-RT 1306: MUS SYSTEM INTRODUCTION
(part one of two) and
MUS PROGRAMMERS GUIDE
(part two of two)
August 1976 \f
vii \f
6_._ _ _ _ _ _ _ _ _R_E_C_O_R_D_ _I_/_O_._ 6.
6_._1_ _ _ _ _ _ _ _P_h_y_s_i_c_a_l_/_l_o_g_i_c_a_l_ _D_a_t_a_b_l_o_c_k_._ 6.1
When dealing with a physical data transfer to/from a certain de-
vice mounted document as to example a magnetic tape roll, the da-
ta are gathered in groups of data, called physical datablocks.
From a MUS-system point of view, interchange of data between do-
cuments is handled as a transport of physical datablocks between
socalled zones (chapter 5). A zone contains information about the
document in use and about data to be processed. To establish a
link between the zone and physical datablock concept, the docu-
ment to use and the process-buffer concept of the MUS-MONITOR
system, the basic I/O-procedures are implemented (chapter 5).
From a programmers point of view, a physical datablock should not
always be looked upon as a logically indivisible whole of data.
Often, a logical datablock surrounded by some header or tail in-
formation, and after some documents/device dependant physical
features calls for unmatching moving information between diffe-
rent documents. To example:
Ex. I: Information hold on punched cards is to be transferred
to disc files for future processing. This calls for
reading datablocks og 80 bytes in length, transforming
them into datablocks of 512 bytes in length. To easily
access the information transferred, a logical block
concept could be of great help.
Ex. II: Skipping information parts, according to some
identifier-part of the physical datablock. If the third
logical block is false, then skip the physical block,
reading the next logical third block.
\f
Thus to easily take care of handling logical information parts
not necessarily fitting the physical blocklength, a logical data
block concept a r_e_c_o_r_d_ is introduced. In the following, the
physical datablock is referred to as a datablock or simply as a
block.
\f
Example 21
\f
As mentioned earlier, the physical datablock (block) is used by
the basic I/O procedures, f.ex. INBLOCK and OUTBLOCK, as infor-
mation interchange element. Therefore, to introduce a logical da-
tablock (record) information element, the record I/O procedures
GETREC and PUTREC are developed as a second I/O procedure level,
interfacing the basic I/O procedures to care for transfer of lo-
gical datablocks between a zone and its document.
GETREC reads in the next record to process here after defining
this record as the current record, thus stepping through the re-
cords in the current block reading in a new block if necessary or
so wanted.
PUTREC makes the next record to process available as the current
record in reserving space for it in the current block. If no more
space is left or the rest is not to be used, the current record
and the records behind it, if any, belonging to the current
block, are output and space is reserved in a new block. So, PUT-
REC does not actually care about how data is transferred to the
current record. Current record is only made available for proces-
sing.
If a record is to be transferred from an inputzone to an output-
zone, you must call GETREC on the inputzone to access the record.
Then PUTREC must be called on the output to reserve space for the
record and hereafter the record must be interchanged, calling f.
ex. MOVE (chapter 6) on current records.
The current record is printed out according to ZFIRST, ZTOP and
ZLENGTH in the zone (see ex. 21). The current record length could
be initially set up or handled over as call value.
When talking about a block being processed, you should notice
that:
Using GETREC sharelength of bytes is asked for in input using IN-
BLOCK. Bytecount of answer is put to ZREM, which then defines
current block length in use. \f
Using PUTREC only the record areas actually reserved are output
to the document as a physical datablock, except for a document of
disc kind. In this case, 512 bytes are transferred.
So when creating a zone, the block-length is not in all future
equal to ZSHAREL. ZSHAREL actually defines the maximal
block-length to be used.
Using the concept block-transfer, current block is found running
the buffer wheel, if multibuffering is used (see chapter 5).
6_._2_ _ _ _ _ _ _ _R_e_c_o_r_d_-_F_o_r_m_a_t_s_._ 6.2
A varity of record formats exist as listed below, common to
GETREC and PUTREC.
zone.ZFORM Mnemonic Description
0 : U ; Undefined recordlength, unblocked
1 : UB ; Undefined recordlength, blocked
2 : F ; Fixed recordlength, unblocked
3 : FB ; Fixed recordlength, blocked
4 : V ; Variable recordlength, unblocked
5 : VB ; Variable recordlength, blocked
Table 21.
Unblocked means: only one record is contained in one block.
Blocked means: one or more records are contained in one
block.
Below an illustrating treatment of the various formats are given.
For details about the block, record and unused buffer space rela-
tionship, refer to section 6.3 and 6.4,
\f
6_._2_._1_ _ _ _ _ _U_n_d_e_f_i_n_e_d_,_U_n_b_l_o_c_k_e_d_._ 6.2.1
NB R NB R NB R NB R NB
R = Record
NB = New Block is called.
One record equals one block. Each time GETREC/PUTREC is called, a
block is transferred from or to the document. This format is
suitable simple to use, when data processing is f.ex. stright
forward datatransfer and the document is not known in advance.
Ex. I: Reading from a card reader, one card is transferred to
the zone, if the length in bytes of one card _ZSHAREL.
Ex. II: Reading from a paper tape reader, share length of
bytes are transferred.
Ex. III: Reading from magnetic tape, one block of data is trans-
ferred, if ZREM _ ZSHARELENGTH.
GETREC returns the current recordlength found (no. of bytes
transferred).
The number of bytes to be transferred using PUTREC, is given as
call parameter and should not exceed the value of ZSHAREL. If
this is the case, you will get an error indication, reading the
status 1b8 + 1b15 in your GIVEUP procedure. If this status is ac-
cepted in this procedure or if no GIVEUP procedure is defined (a
zero in the zone-entry), then return is made from PUTREC with
ZSHAREL put into the call parameter, and thus space is made
available for a record of length ZSHAREL.
Notice: This error information is only delivered when dealing
with a block (1b8: block error) but is valid for any\f
format in use calling PUTREC. As it is to be seen on
the next pages, a somewhat different error handling is
made in case of GETREC-call.
6_._2_._2_ _ _ _ _ _U_n_d_e_f_i_n_e_d_,_ _B_l_o_c_k_e_d_._ 6.2.2
NB R R R NB R NB R R R NB
One block contains one or more records, not necessarily of the
same record length, which is set up using GETREC and PUTREC in
this case. Each time of call of GETREC/PUTREC recordlength of
bytes are made available reading in/putting out the current
block, if necessary.
This format could be used, when the data transfer is not simple
sequential, f.ex. if data are augmented with head and tail re-
cords not to be processed or if data error indication marks,
causing you to skip the next record, are given.
6_._2_._3_ _ _ _ _ _F_i_x_e_d_,_ _U_n_b_l_o_c_k_e_d_._ 6.2.3
NB R NB R NB R NB
Each block contains one record. Each record is of equal length.
The record length is initially set up in ZONE.ZLENGTH. This for-
mat is to be used, if the record-length is known in advance. It
provides you with an error indication, whenever GETREC is called
and a record of the right size is not found, standard error
1b8+1b15. 1b15 is set too, to indicate that 1b8 is not driver
set.
If the error is accepted, the record is delivered as a short re-
cord: the block is not filled up. Using PUTREC the current block
is simply output and space reserved in the next block for a re-
cord of length ZONE.ZREM if possible.
\f
Notice: error handling should be defined in a user defined
GIVEUP procedure (chapter 5).
6_._2_._4_ _ _ _ _ _F_i_x_e_d_,_ _B_l_o_c_k_e_d_._ 6.2.4
R R R NB R R R NB
The block size should be an integral multiplum of the record
length leaving no space behind. The record length is initially
set up in ZLENGTH and all records should be of equal length. This
format is very useful in handling wellknown documents, say to
example a magnetic tape with a file containing card-image-records
or a discfile with some database sort of linking of the records.
As compared with the format F, a better utilization of the zone-
concept is provided for here, especially in case of very small
records, saving I/O overhead.
As for F-formats, a record-length check is performed on each re-
cord processed. Again a short record can be delivered - if the
error is accepted - at return from GETREC.
Using PUTREC space is simply reserved for next record. If not
enough space is left, no error is given, but space is reserved in
a new block. If this is not possible, error is given.
6_._2_._5_ _ _ _ _ _V_a_r_i_a_b_l_e_,_ _U_n_b_l_o_c_k_e_d_._ 6.2.5
NB C1 C2 R NB C1 C2 R NB
L2
L1
IBM>s record format V. One block contains one record. Block
length and record length are not to be known in advance, but
supplied to\f
the user at call of GETREC. Call of PUTREC results in creation of
the fields C1 and C2 and reservation of space for a record. The
record length (and hereby information about L1, L2) is delivered
as call value.
Incorrect block size: 1b8+1b15 is set in status.
C1: 4 bytes in length.
The first 2 bytes contain the value of L1, thus defi-
ning a block length. The value of the two last bytes is
zero.
C2: 4 bytes in length.
The first two bytes contain the value of L2, thus defi-
ning a pseudo recordlength, the value of the 2 last
bytes is zero.
The recordlength equals (L2-4) bytes, which is the va-
lue delivered from GETREC and the value to deliver,
using PUTREC.
NOTICE: Errorhandling is performed as described in the section
dealing with F formats with the very one exception:
If using GETREC, having in progress a short record,
then this situation is not reported as an error situa-
tion, if discfile is in use. That is: a short block is
delivered without status indication. Notice that the
transferred number of bytes always can be found in the
return parameter of GETREC.
\f
6_._2_._6_ _ _ _ _ _V_a_r_i_a_b_l_e_,_ _B_l_o_c_k_e_d_._ 6.2.6
C1 C2 R C2 R NB C1 C2 R NB
L1
L2
L2
L2
L1
IBM>s recordformat VB. One or more records contained in one
block. The records must fill up one block (no free space left).
In case of incorrect block length, a short block is delivered, if
the error is accepted.
Call of PUTREC results in creation of the field C2, if current
block must be changed, the fields C1 and C2 are created.
Notice: C1 is updated each time PUTREC is called, to provide
for the increasing record number. The record length is
delivered as call value using PUTREC. C1 and C2 are
defined as illustrated in section 6.2.5
Blockerror: 1b8+1b15 is set, refer to the section dealing with FB
formats. Again in case of dischandling using GETREC an exception
as the one mentioned above is made.
6_._3_ _ _ _ _ _ _ _G_E_T_R_E_C_._ 6.3
6_._3_._1_ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _G_E_T_R_E_C_ _(_Z_o_n_e_,_ _A_d_d_r_._,_ _B_y_t_e_s_)_._ 6.3.1
Call Return
AC0 bytes bytes
AC1 addr
AC2 zone zone
AC3 link destroyed \f
Next record is made available in the current input buffer. IN-
BLOCK is called, if current block covers the demand for a record
insufficiently according to the various formats.
P_a_r_a_m_e_t_e_r_s_ _i_n_ _u_s_e_:_
bytes: call value is used in case of UB format only
to set up zlength. At return, the value of
bytes is set to zlength or blockerror - re-
turn value:
Non error return: U: bytes:= zlength:= zrem
UB: bytes:= zlength:= bytes
F, FB: bytes:= zlength (constant, initi-
ally set up)
V, VB: current record length in bytes is
set up in zlength using C2.
Bytes: = zlength.
Error return: bytes:= zrem;
addr: ZFIRST (byteaddress)
zone: ZONEADDRESS (wordaddress)
After call of OPEN (zone, operation) the bufferarea of used share
is pointed out as shown. Operation = input:
ZSHAREL
ZTOP
ZREM: = 0, ZFIRST undefined. No data transfer.
Fig. 22. \f
F_i_r_s_t_ _c_a_l_l_ _o_f_ _G_E_T_R_E_C_ _(_z_o_n_e_,_ _b_y_t_e_s_)_:_
INBLOCK is called.
At INBLOCK-return ZREM:= bytecount of answer.
Internal return: left
ZREM unused
ZTOP
ZFIRST is undefined. Datatransfer is done
Fig. 23.
Hereafter the current record is pointed out according to the va-
rious formats in use:
Return from GETREC:
External GETREC return.
ZLENGTH
ZREM
xxx ZFIRST ZTOP xxxxxx
8 bytes are left behind in case of V and VB format.
Fig. 24.
S_u_c_c_e_d_i_n_g_ _c_a_l_l_s_ _o_f_ _G_E_T_R_E_C_ _(_z_o_n_e_,_ _b_y_t_e_s_)_:_
If ZREM covers the demand for a record insufficiently INBLOCK is
called and the action illustrated above in fig. 23 and fig. 24 is
repeated for the next buffer to use. If this is not the case, re-
fer to fig. 25. \f
(UB, FB, VB)
External GETREC return: ZREM
8 ZLENGTH
bytes
D_D_C2U_U_
xxx
C1, C2
ZFIRST ZTOP
4 bytes left behind (VB only)
V and VB only
Fig. 25.
6_._3_._2_ _ _ _ _ _P_s_e_u_d_o_-_A_l_g_o_l_ _D_e_s_c_r_i_p_t_i_o_n_._ 6.3.2
In the following, a detailed pseudo-algol-description of GETREC
is given according to the various formats:
Local procedures: BLOCKERROR and UPDATE and GETHEAD.
U_:_ A buffer is made available for processing containing a data-
block. In case of let us say paper tape in usage as input
medium (zone.zname = PTR) , the datablock fills up the buf-
fer where as usage of card as input medium results in one
card being read defining one datablock not necessarily fil-
ling up the buffer.
repeat INBLOCK until Zrem' 0;
bytes:= Zlength:= Zrem;
UPDATE;
0: ;GETREC return
\f
U_B_:_ Bytes characters are made available for processing. If IN-
BLOCK is called, refer to comments given above.
Zlength:= bytes;
If bytes ' Zrem, then repeat INBLOCK until Zrem '_ Zlength;
bytes:= Zlength;
UPDATE;
0: ;GETREC return.
F_:_ Notice: Zlength should be initially defined.
Zlength of bytes are made available for processing.
Comments as for U except that data read left unaccessed
results in blockerror, which is of interest using discfiles
as input medium in that INBLOCK results in 512 bytes being
read and therefore requires Zlength:= 512.
1: If Zrem ' 0, then BLOCKERROR;
repeat INBLOCK until Zrem ' 0;
bytes:= Zlength;
if bytes ' Zrem
then goto 1
UPDATE;
0: ;GETREC return
F_B_:_ If INBLOCK is called, refer to comments given above. If this
is not the case, notice that zlength of bytes is being ac-
cessed:
bytes:= Zlength;
if bytes ' Zrem
then goto 1;
UPDATE;
0: ; GETREC return
\f
V_:_ This format equals the IBM V-format. Incorrect format length
is handled as for F-formats. Please notice that in case of
discfile as input medium, rounding off input block is
provided for. Decoding of block- and recordlength is made
acc. to the description given earlier (GETREC/PUTREC -
format) and accomplished for in the local procedure
GETHEAD:
2: repeat INBLOCK until zrem '0;
GETHEAD; !a local variable l.bytes is declared.!
If l.bytes ' zrem then
Begin
If zone.zkind (11) ' 1 then BLOCKERROR;
Zrem:= l.bytes !a short block is delivered!
end;
5: If Zrem = 0 then goto 2;
GETHEAD;
bytes:= Zlength;
UPDATE;
0: GETREC return
V_B_:_ This format equals the IBM VB-format. If INBLOCK is called,
refer to comments given above:
if Zrem = 0 then goto 2;
GETHEAD;
bytes:= Zlength;
UPDATE;
0: ;GETREC return.
\f
PROCEDURE GETHEAD;
if zrem 4 then BLOCKERROR;
zrem:= zrem -4;
ztop:= ztop +4;
zfirst:= ztop -4;
l.bytes:=C;! C equals C1 OR C2!
l.bytes:=C - 4;
zlength:= l.bytes;
if l.bytes 'zrem then BLOCKERROR:
END GETHEAD;
PROCEDURE UPDATE (bytes);
BEGIN: zrem:= zrem - bytes;
ztop:= ztop + bytes;
zfirst:= ztop - bytes;
END;
END UPDATE;
PROCEDURE BLOCKERROR
BEGIN
Z0:= 1b8 + 1b15;
IF Zgiveup ' 0 then go to GIVEUP;
bytes:= zrem;
UPDATE;
GOTO 0 ;
END;
END BLOCKERROR;
\f
Notice that if a GIVEUP procedure is called, ZREM must differ in
value from zero at GIVEUP bottom-out return. If ZREM equals zero,
the GIVEUP procedure is called again and a loop is established in
your program.
\f
6_._3_._3_ _ _ _ _ _P_r_o_g_r_a_m_m_i_n_g_ _E_x_a_m_p_l_e_._ 6.3.3
; Use of GETREC, no. of bytes on tape:600.
LDA 0 .1 ;AC0:= 1
LDA 2 UZONE ;
OPEN ;UZONE OPENED FOR INPUT,
;ZMODE is defined
GETREC ;512 bytes are asked for
;
STA 0 GNORW ;GNORW:= no delivered
;The first byte of cur-
;rent record is addres-
;sed via AC1.
GETREC ;Notice:
;88 bytes are delivered
;OK but status EM is
;found. Return is made to
;GIVEUP. The CPU is
;stopped.
GNORW: 0 ;No of bytes read
UZONE: .+1 ;Zone in use.
.TXT.PTR0'0'. ;Document: 6 bytes name
0 ;ZMODE: undefined
1 ;ZKIND: char oriented
65535 ;ZMASK: errormask for
;giveup
UGIVE ;ZGIVEUP address
.LOC UZONE + ZCONV ;
0 ;No conversiontable
.LOC UZONE + ZFORM ;
0 ;Undefined, unblocked
.LOC UZONE + ZSHAR ;Bufferarea in bytes
512 ;
;For a fully set up of
;zonedescr., sharedescr.
UGIVE: . ;+ buffers refer to ch.5
.
HALT ;Stop CPU.
Example 22. \f
6_._4_ _ _ _ _ _ _ _P_U_T_R_E_C_._6.4
6_._4_._1_ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _P_U_T_R_E_C_ _(_z_o_n_e_,_ _a_d_d_r_._,_ _b_y_t_e_s_)_._ 6.4.1
Call return
AC0 bytes bytes
AC1 - addr
AC2 zone zone
AC3 link destroyed
In current output buffer, space for next record is reserved. If
no space is left or format is unblocked, then current block is
output using OUTBLOCK, and hereafter space is reserved in next
output buffer of the bufferwheel.
P_a_r_a_m_e_t_e_r_s_ _i_n_ _u_s_e_._
bytes: call value is used in case of U, UB, V, VB to
set up zlength. In case of F and FB-format,
zlength should be initially defined.
Return value equals zlength in all cases of non
block error return else zrem.
addr: zfirst (byteaddress).
zone: Zoneaddress (wordaddress).
\f
After call of OPEN (zone, operation), the buffer area of used
share is pointed out as shown.
Operation = output.
ZSHAREL
ZTOP
ZREM:= ZSHAREL.
ZFIRST is undefined. No datatransfer.
Fig. 26
F_i_r_s_t_ _c_a_l_l_ _o_f_ _P_U_T_R_E_C_ _(_z_o_n_e_,_ _b_y_t_e_s_)_._
External PUTREC return.
ZREM:=ZREM-ZLENGTH-(C1,C2)
ZLENGTH
ZFIRST ZTOP No datatransfer
C1 and C2 are defined in V and VB formats
else no space is left behind.
Fig. 27.
N_e_x_t_ _c_a_l_l_ _o_f_ _P_U_T_R_E_C_ _(_z_o_n_e_,_ _b_y_t_e_s_)_._
In case of unblocked formats, OUTBLOCK is called with bytecount
equal to ZSHAREL-ZREM. In case of discfiles in use, ZREM is put
to zero unconditionally.
At OUTBLOCK-return ZREM:= ZSHAREL: \f
Internal return.
ZSHAREL
ZTOP
ZREM:= ZSHAREL.
ZFIRST is undefined. Datatransfer is done.
Fig. 28.
Return from PUTREC:
External return:
C1,C2 ZLENGTH ZREM:=ZREM-ZLENGTH-(C1,C2)
ZFIRST ZTOP
V, VB formats only.
Fig. 29
In case of blocked formats, next call of PUTREC is done according
to fig. 28 and fig. 29, if OUTBLOCK is called. If this is not the
case (zrem covers the demand for a record), refer to fig. 30.
\f
Return from PUTREC, no datatransfer.
External return:
C1,C2 C2 ZLENGTH ZREM
ZFIRST ZTOP
ZREM:= ZREM-ZLENGTH-C2;
Fig. 30.
6_._4_._2_ _ _ _ _ _P_s_e_u_d_o_-_A_l_g_o_l_ _D_e_s_c_r_i_p_t_i_o_n_._ 6.4.2
In the following, a detailed pseudo-algol-description of PUTREC
is given acc. to the various formats.
local procedures: UPDATE and BLOCKERROR
C_a_l_l_ _o_f_ _P_U_T_R_E_C_ _(_z_o_n_e_,_ _b_y_t_e_s_)_:_
U_:_ Current block of data is put out. Then space is reserved in
the next buffer for the record to be output next time PUTREC
is called.
zlength:= bytes;
OUTBLOCK;
if zrem zlength then BLOCKERROR;
UPDATE (0); !init. of zfirst.!
UPDATE (zlength)
0: ;PUTREC return
\f
U_B_:_ If no room for next record of length >bytes> OUTBLOCK is
called.
zlength:= bytes;
if zrem bytes then OUTBLOCK;
if zrem zlength then BLOCKERROR;
if ztop = sfirst then UPDATE (0);
!after call of outblock.!
UPDATE (zlength);
0: ;PUTREC return.
F_:_ Comments as for U-formats. Notice that zlength should be
initially defined.
bytes:= zlength;
zlength:= bytes;
OUTBLOCK;
if zrem zlength then BLOCKERROR;
UPDATE (0);
0: ;PUTREC return
F_B_:_ Comments as for UB-format. Notice that zlength should be
initially defined.
bytes:= zlength;
zlength:= bytes;
if zrem bytes then OUTBLOCK;
if zrem zlength then BLOCKERROR;
if ztop = sfirst then UPDATE (0);
UPDATE (zlength);
0: ;PUTREC return
\f
V_:_ IBM-V-format. C1 and C2 are defined. Comments as for U-for-
mat.
60 bytes:= bytes +4;
zlength:= bytes;
OUTBLOCK;
is zrem zlength then BLOCKERROR;
UPDATE (4); !reservation of space for C1!
1: UPDATE (zlength); !reservation of space for C2 and the
record.!
insert (C2, zlength); !local production: C2:= zlength!
zlength:= zlength - 4; !record alone defined.!
zfirst:= zfirst + 4;
l.zlength:= ztop - sfirst;
evaluate (C1, l.zlength);!C1 is updated acc to current
length of current block.
Note: sfirst is used.!
0: ;PUTREC return
V_B_:_ IBM-VB-format. C1 and C2 are defined. Comments as for UB
format.
bytes:= bytes + 4;
zlength:= bytes;
if zrem bytes then OUTBLOCK;
if zrem zlength then BLOCKERROR;
if ztop = sfirst then UPDATE (4);
goto 1;
\f
PROCEDURE UPDATE (bytes);
BEGIN
ZREM:= ZREM - bytes;
ZTOP:= ZTOP + bytes;
ZFIRST:= ZTOP - bytes;
END;
PROCEDURE BLOCKERROR;
BEGIN
Z0:= 1b8 + 1b15;
If Zgiveup '0 then goto GIVEUP;
bytes:= ZREM;
UPDATE (bytes);
GOTO 0;
END;
Notice that if a GIVEUP procedure is called, ZREM must differ
from zero at GIVEUP bottom-out return. If ZREM equals zero, the
GIVEUP procedure is called again and a loop is established in
your program.
\f
6_._4_._3_ _ _ _ _ _P_r_o_g_r_a_m_m_i_n_g_ _E_x_a_m_p_l_e_._ 6.4.3
;Use of PUTREC ;IZONE should be defined
;
LDA 0 .3 ;AC0:= 3
LDA 2 OZONE ;
OPEN ;OZONE OPENED FOR OUTPUT
;ZMODE is defined
;bytes not defined here
PUTREC
LDA 3 PADDR ;Parameter address for
;MOVE
LDA 2 ZFIRST,2
STA 0 +0,3
STA 2 +1,3
LDA 2 IZONE
LDA 2 ZFIRST,2
STA 2 +2,3
MOV 3,2
MOVE ;FROM IZONE TO OZONE
LDA 2 OZONE ;space is made for 144
PUTREC ;bytes (return from
;GIVEUP)
.
MOVE
LDA 2 OZONE ;400 bytes are trans-
PUTREC ;ferred to mag. tape and
. ;256 bytes are reserved
.
\f
OZONE: .+1 ;zone in use
.TXT .MT00'0'. ;ZNAME
0 ;ZMODE
13 ;ZKIND
65535 ;ZMASK
UGIVE ;ZGIVEUP
.LOC OZONE + ZCONV
0
.LOC OZONE + ZFORM ;
2 ;Fixed blocked
256 ;ZLENGTH defined
.LOC OZONE + ZSHAR ;
400 ;
UGIVE: ;
JMP +0,3 ;Return to call point
;in PUTREC
Example 23.
6_._5_ _ _ _ _ _ _ _M_O_V_E_._ 6.5
P_r_o_c_e_d_u_r_e_ _M_O_V_E_ _(_p_a_r_a_m_._a_d_d_r_)_
Call Return
AC0 - destroyed
AC1 - destroyed
AC2 param.addr param.addr
AC3 link destroyed
\f
P_a_r_a_m_e_t_e_r_s_ _i_n_ _u_s_e_._
Param.addr: count, no of bytes to be
transferred.
Param.addr+1: to address
where to put the first byte
Param.addr+2: from address
where to take the first byte.
Param.addr+3: work location.
Param.addr: wordaddress.
Example of use:
ZFIRST OF INPUTZONE zone.ZFIRST
from (IN +M):
to (OUT ):
ZFIRST OF OUTPUTZONE zone.ZFIRST
The >to>- and >from> - strings need not to be disjoint. In case
of IN=OUT the procedure may fail to work, if >to-address> is
greater than >from-address> (data in >from> may be destroyed
before they should be used).
Notice: The parameter area pointed out by the parameter address
is destroyed.
\f
6_._5_._1_ _ _ _ _ _P_r_o_g_r_a_m_m_i_n_g_ _E_x_a_m_p_l_e_._ 6.5.1
E_k_s_:_
.
.
LDA 2 PADDR ;
MOVE ;
.
.
.
.
PADDR: PSTAC ;
;
;
;P_a_r_a_m_e_t_e_r_ _f_i_e_l_d_._
PSTAC: MCOUNT ;bytecount
MOTO ;To address
MOFRO ;From address
0 ;work location
Example 24.
\f
7_._ _ _ _ _ _ _ _ _C_H_A_R_A_C_T_E_R_ _I_/_O_ _P_R_O_C_E_D_U_R_E_S_._ 7.
The single character - and the string oriented transfer proce-
dures are contained in the module MUC.
These procedures can be looked upon as a special case of the re-
cord I/O procedures. Thus the concepts around the fundamental
datastructure, the zone, are equally valid.
The character I/O procedures are augmented with the two utility
procedures DECBIN and BINDEC.
7_._1_ _ _ _ _ _ _ _S_i_n_g_l_e_ _C_h_a_r_a_c_t_e_r_ _P_r_o_c_e_d_u_r_e_s_._ 7.1
Before call:
ZREM
ZTOP
After call
ZREM
ZTOP
7_._1_._1_ _ _ _ _ _I_N_C_H_A_R_ 7.1.1
Call Return
AC0 - - - destroyed
AC1 - - - character
AC2 zone zone
AC3 link destroyed \f
Gets the next byte from the zone. INBLOCK (see chapter 5) is
called if ZREM upon entry equals 0.
7_._1_._2_ _ _ _ _ _O_U_T_C_H_A_R_._ 7.1.2
Call Return
AC0 - - - unchanged
AC1 character destroyed
AC2 zone zone
AC3 link destroyed
Outputs the character contained in AC1 onto the zone. OUTBLOCK
(see chapter 5) is called, if ZREM upon entry equals 0.
7_._1_._3_ _ _ _ _ _O_U_T_S_P_A_C_E_._ 7.1.3
Call Return
AC0 - - - unchanged
AC1 - - - destroyed
AC2 zone zone
AC3 link destroyed
Calls OUTCHAR with a preloaded character value equal to 32 (ASCII
space).
\f
7_._1_._4_ _ _ _ _ _O_U_T_E_N_D_._ 7.1.4
Call Return
AC0 - - - destroyed
AC1 character destroyed
AC2 zone zone
AC3 link destroyed
Outputs the character onto the zone by means of OUTCHAR. In order
to avoid any blocking effects on character oriented devices,
OUTBLOCK will be called if the device is character oriented. Thus
the share will be emptied by outputting that part presently being
filled with characters.
E.g. the terminating line, when outputting a disc file on the TTY
could else be displayed in two steps, if the line was spanning
across two disc sectors.
7_._1_._5_ _ _ _ _ _O_U_T_N_L_._ 7.1.5
Call Return
AC0 - - - destroyed
AC1 - - - destroyed
AC2 zone zone
AC3 link destroyed
Calls OUTEND with a preloaded character value equal to 10 (ASCII
New Line).
\f
7_._2_ _ _ _ _ _ _ _S_t_r_i_n_g_ _O_r_i_e_n_t_e_d_ _P_r_o_c_e_d_u_r_e_s_._ 7.2
7_._2_._1_ _ _ _ _ _O_U_T_T_E_X_T_._ 7.2.1
Call Return
AC0 address (byteaddr) destroyed
AC1 - - - destroyed
AC2 zone zone
AC3 link destroyed
Outputs the text by means of OUTCHAR, until a character equal to
0 is encountered. The terminating 0 will not be output.
7_._2_._2_ _ _ _ _ _O_U_T_O_C_T_A_L_._ 7.2.2
Call Return
AC0 value destroyed
AC1 - - - destroyed
AC2 zone zone
AC3 link destroyed
Converts the value to a 6-digit octal character and outputs this
string onto the zone by means of OUTCHAR.
E.g. 115 will be output as 000163
\f
7_._2_._3_ _ _ _ _ _I_N_N_A_M_E_._ 7.2.3
Call Return
AC0 - - - destroyed
AC1 address (word addr) destroyed
AC2 zone zone
AC3 link destroyed
Calls INCHAR repetively until the character string being input
follows the definition of n_a_m_e_ (from 1 to 5 characters long and
having unused positions equal to 0).
E.g. >32'32'NAME13'> will be stored as >NAME0'0'>
7_._3_ _ _ _ _ _ _ _U_t_i_l_i_t_y_ _P_r_o_c_e_d_u_r_e_s_._ 7.3
The user must realize that the utility procedures are using the
location SAVE, SAVE1 and SAVE2 or CUR+24, CUR+25 and CUR+26,
where the displacements are octal.
7_._3_._1_ _ _ _ _ _D_E_C_B_I_N_._ 7.3.1
Call Return
AC0 - - - destroyed
AC1 address (byteaddr) value
AC2 cur cur
AC3 link destroyed
The address must point at a sequence of ASCII characters and the
procedure will deliver its binary equivalent in >value>. The
procedure will terminate, when the first non-digit character (a
character outside the range of 48 to 57) is encounted. No check
for overflow is made. If address upon entry is pointing at a\f
non-digit character (e.g. a sign character) the value delivered
will be 0.
E.g. >+123> will be returned with value 0
>1232'34> will be returned with value 12.
7_._3_._2_ _ _ _ _ _B_I_N_D_E_C_._ 7.3.2
Call Return
AC0 value destroyed
AC1 address (byteaddr) destroyed
AC2 cur cur
AC3 link destroyed
The binary value >value> is converted into a 5 decimal and a 0'
byte string.
E.g. value =123 will be converted into >001230'>.
\f
7_._4_ _ _ _ _ _ _ _P_r_o_g_r_a_m_m_i_n_g_ _E_x_a_m_p_l_e_s_._ 7.4
.
.
OTEXT: .+1
.TXT .OUTPUT STRING.
.
.
.
LDA 2 IZONE ;
INCHAR ; GET CHARACTER
.
.
.
LDA 1 CHAR ;
LDA 2 IZONE ; OUTPUT CHARACTER
OUTCHAR ;
.
LDA 0 OTEXT ;
MOVZL 0,0 ; ADDRESS:=BYTEADDRESS
LDA 2 IZONE ; OUTPUT TEXTSTRING
OUTTEXT ;
.
.
.
WORK: .+1
0 ; NAME
0 ; NAME
0 ; NAME
.
.
.
LDA 1 WORK ;
LDA 2 IZONE ; GET NAME
INNAME ;
\f
8_._ _ _ _ _ _ _ _ _C_A_T_A_L_O_G_ _S_Y_S_T_E_M_._ 8.
8_._1_ _ _ _ _ _ _ _I_n_t_r_o_d_u_c_t_i_o_n_._ 8.1
RC3600 file system makes it possible to divide a disc drive into
smaller independent units, f_i_l_e_s_. These files are identified by
names, with a length of 5 characters. The descriptions of the
files, e_n_t_r_i_e_s_, are kept in a c_a_t_a_l_o_g_ stored on the disc. The
entries give among other things the name, the length, and the
starting position on the disc of the file.
RC3600 file system allows up to 255 discs to be connected to the
same RC3600 central unit. Each disc is handled independent of all
others as it holds one or more catalogs of its own. Each catalog
and the disc space covered by the catalog files is called a
c_a_t_a_l_o_g_ _u_n_i_t_. Up to 255 catalog units can be handled by the file
system, and more than one catalog unit can be placed on the same
physical disc pack or cartridge. Files on different catalog units
may have the same name, and it is therefore necessary to give the
number of the catalog unit, when accessing a file.
With the RC3600 file system you can create, remove and change
files, and read or write into existing files.
Operations involving update of the catalogs are handled in a
special catalog handler process, CAT, and this process
administrates the creation and removal of a_r_e_a_ _p_r_o_c_e_s_s_e_s_. The
area process will when created act as a normal driver process,
and file read/write operations are directed to this area process,
which will modify and read data only on the file with the same
name as the area process. Moreover the area process administrates
the current position in the file for up to three different user
processes, and takes care of the different kinds of user
reservations. \f
A file may be a new catalog (s_u_b_ _c_a_t_a_l_o_g_) for a number of files.
To access files in a sub catalog, a c_a_t_a_l_o_g_ _p_r_o_c_e_s_s_ must first be
created for that sub catalog. Creation and removal of catalog
processes are also done by the process >CAT>. All operations on
the sub catalog and the files within it are carried out by
sending messages to the catalog process for the sub catalog in
question.
Catalog operations are in the basic level of procedures requested
by sending messages to the process CAT. A detailed description of
the message interface can be found in 5.
In the MUS Basic I/O system a number of procedures have been
build to ease the use of the catalog system. These procedures are
working on the file descriptor (zone) structure as described in
chapter 5, and enable the user to work on well known structures
and with simple exception handling by means of the defined giveup
procedure.
8_._2_ _ _ _ _ _ _ _C_a_t_a_l_o_g_ _S_y_s_t_e_m_ _D_i_s_c_ _S_t_r_u_c_t_u_r_e_._ 8.2
The smallest unit accessible on an RC3600 disc is one s_e_c_t_o_r_,
each with 512 bytes data. Each file created by the catalog system
consists of a number of sectors random distributed over the disc
surface, and the relative position on the disc of each sector is
collected on one sector, called the i_n_d_e_x_b_l_o_c_k_. In order to get
fast access to each sector in the file the sectors are collected
in physical contiguous blocks called s_l_i_c_e_s_, each consisting of a
fixed number of sectors.
The indexblock contains then a number of slice discriptions each
describing a collection of contiguous slices. The first word of
the indexblock gives the number of slice descriptions in use. The
maximal number of slice descriptions for a file is 127. \f
A slice description consists of two words. The first word gives
the number of sectors and the next word gives the start address
relative to the catalog start.
If a file is extended the catalog system will use the physically
next slice on the disc, if possible. Thus it suffices to increase
the number of sectors occupied by the last slice description in
the indexblock. I.e. if a new disc is created all files will be
physical contiguous and described by only one slice description
in the indexblock.
s_l_ice 1
_ _I_N_D_E_X_ _B_L_O_C_K___ _ _ sector with 512 bytes
No. of desc. _______3________ __
slice size _ _ _ _ _ _ _5_ _ _ _ _ _ _ _ __
address _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
_ _ _ _ _ _1_2_ _ _ _ _ _ _ _ __
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
_______6________
_______________ s_l_ice 2 and 3
__
__
__slice
__
__
__
__ __
__ __
__ __
__ __
__ __
__ __
__
slice 4
Fig.31 : Index block structure. The index block is the first
segment in the first slice. \f
The reference to the file indexblock is placed in a file entry
which also contains the filelength, name and specifications bits
(attributes).
All file entries on a catalog unit are collected in a standard
data file SYS. This file can be read by the user, and the file
only differs in the fact that its indexblock is fixed on sector 6
and it is protected against user writing and removal.
S_Y_S_ _I_N_D_E_X_ _(_6_)_ S_Y_S_ _F_I_L_E_
______1_______
______6_______
_____________
________ Reference to
FILE ________
ENTRY ________ file index
Sector
_____________ ________
Fig.32 The catalog file SYS. Please note that the entry SYS is
represented in the file itself.
Each entry in the SYS file is represented by 16 words with the
layout given in fig.33.
\f
_______________________
_ _
_ Entry name _
_______________________
_ _
_ Optional words 1 _
_______________________
_ _ _ _E_n_t_r_y_ _a_t_t_r_i_b_u_t_e_ _ _ _ _
_ _ _E_n_t_r_y_ _f_i_l_e_l_e_n_g_t_h_ _ _ _ _
_A_d_d_r_e_s_s_ _o_f_ _i_n_d_e_x_b_l_o_c_k_ _
_ _ _ _R_e_s_e_r_v_e_d_ _l_e_n_g_t_h_ _ _ _ _
_ _
_ _
_ DDOptinal words 2UU _
_ _
_ _
_______________________
Fig.33 Entry layout in file SYS.
Entries not occupied in the catalog file are given by a zero
name, and all entries are placed in the file SYS by means of a
hashkey value computed from the entryname.
Entries with the same hashkey are thus found in the sectors k,
k+n, k+2n,.... in the catologfile, where k is the hashkey and n
is the SYS-size, which is an integral multiple of the slice size.
A new entry is inserted in sector k (the hashkey), but if this
sector is occupied sector k+n is used, an so on. The catalog is
extended and the added sectors are zeroized if no space is found
in existing sectors. \f
Slice 0 Slice 1 Slice 2
Sec_tor sli_ce _______ _______ _______
Hashkey = Ø
_______ _______ _______
Hashkey = 1
_______ _______ _______ .
.
.
.
_______ _______ _______ .
.
Hashkey = n
_ _______ _______ _______
Fig.34 Hashkey organisation in file SYS.
As seen from the entry layout two lengths are connected to each
file, the filelength and the reserved length. The reserved length
is always an integral number of the number of segments in a slice
minus the one occupied by the indexblock, and the relation
file length _ reserved length
is therefore valid, as the file length is the number of user
accessible segments (data segments) on the file, and the reserved
length is the number of segments occupied on the disc by the
current file.
\f
Each slice on the disc is mapped on a bit in the map sector,
which means that if a slice is included in a file and placed in
the fileindexblock, the equivalent mapbit is zeroized, else it is
set to one.
Further information about the catalog unit structure is kept in a
fixed sector on the disc. These informations are catalog size,
slicelength and data sector start.
The map sector and disc description sector are placed in a user
accessible datafile too, called MAP.
first data sector
_0_ _ _1_ _ _2_ _ _3_ _ _4_ _ _5_ _ _6_ _ _7_ _ _8_ _ _9_ _ _1_0_ _ _1_1_ _ _1_2_ _ _1_3_ __________X____
Not used
Map block
Disc description block
MAP index block
Catalog (SYS) index block
System bootstrap
Fig.35 Disc and catalog organisation
\f
When the MAP file is read the first sector contains the following
information :
________________________
Word 0 _ _ _ _ _ _ _ _S_Y_S_ _s_i_z_e_ _ _ _ _ _ _ _ _ must be an integral multiple
1 _ _ _ _ _ _ _s_l_i_c_e_ _s_i_z_e________ af slice size.
2 _ _ _n_u_m_b_e_r_ _o_f_ _s_e_c_t_o_r_s_ _ _ _ _
3 _n_u_m_b_e_r_ _o_f_ _f_r_e_e_ _s_e_c_t_o_r_s_ _
4 _ _ _f_i_r_s_t_ _d_a_t_a_ _s_e_c_t_o_r_ _ _ _ _
5 _ _ _ _t_o_p_ _d_a_t_a_ _s_e_c_t_o_r_ _ _ _ __
Not used
Fig.36 Disc description sector.
The next sector is the bitmap. A free slice is indicated as a one
in the appropriate bitposition.
The physical position on the actual disc configuration of each
catalog unit can be found in a seperate description program,
which gives the connection between the catalog unit and the name
of the used disc driver process and the start address of the
first sector on the disc. The description program is created as
an assembler program containing a predefined data structure. The
catalogprocess CAT is then the same in all system configurations
and the actual configuration is given by the tables in the
description program with the fixed name CATW. A part of the disc
description sector is read and moved to the description program
when the actual catalog unit is initialized.
A detailed description of the formats in the CATW program can be
found in 5.
\f
8_._3_ _ _ _ _ _ _ _C_a_t_a_l_o_g_ _S_y_s_t_e_m_ _P_r_o_c_e_d_u_r_e_s_._ 8.3
8_._3_._1_ _ _ _ _ _G_e_n_e_r_a_l_._ 8.3.1
When catalog system procedures are called a fixed parameter is
always the file descriptor address. By this reference to the
file descriptor the name of the file to be manipulated and the
giveupprocedure to be called in case of errors, are defined. In
addition the conversion table address in the file descriptor
(zone.zconv) is used to specify if the catalog procedure should
be performed on a main catalog or on a sub catalog. When
accessing files in a sub catalog the conversion table address
should point to a string containing the sub catalog name.
8_._3_._1_._1_ _ _ _M_a_i_n_ _C_a_t_a_l_o_g_s_._ 8.3.1.1
If zone.zconv = 0 the operation is send to the process CAT, which
handles operations on main catalogs. The document name in the
file descriptor must hold the name of the file to work on (zero
characters for unused positions), a_n_d_ _t_h_e_ _m_a_i_n_ _c_a_t_a_l_o_g_ _u_n_i_t_ _n_u_m_-
b_e_r_ _i_n_ _t_h_e_ _l_a_s_t_ _b_y_t_e_ _o_f_ _t_h_e_ _n_a_m_e_.
Operations which can be performed on main catalogs are:
1) Createentry
2) Removeentry
3) Lookupentry
4) Changeentry
5) Setentry
6) Initcat
7) Newcat
8) Freecat
\f
8_._3_._1_._2_ _ _ _S_u_b_ _C_a_t_a_l_o_g_s_._ 8.3.1.2
If zone.zconv ' 0 the operation is send to a process with name
pointed out by the byteaddress in zone.zconv. This name should be
the name of a c_a_t_a_l_o_g_ _p_r_o_c_e_s_s_ consisting of the 5_ _c_h_a_r_a_c_t_e_r_ _s_u_b_
c_a_t_a_l_o_g_ _n_a_m_e_ _f_o_l_l_o_w_e_d_ _b_y_ _a_ _s_u_b_ _c_a_t_a_l_o_g_ _n_u_m_b_e_r_ _a_s_ _t_h_e_ _6_._ _c_h_a_r_a_c_t_e_r_.
The sub catalog number is gained from the catalog system when the
catalog process is created by using the catalog procedure NEWCAT.
The document name in the file descriptor must hold the name of
the file to work on (zero characters for unused positions) in the
first 5 characters. The 6. character is automatically supplied
with the sub catalog number specified as the 6.th character of
the catalog process name.
Operations which can be performed on sub catalogs are the same as
for main catalogs except for 6, 7 and 8. Before the operations
can be used the catalog process must be created by using the
procedure NEWCAT. Catalog processes are removed by the procedure
FREECAT.
8_._3_._1_._3_ _ _ _P_r_o_c_e_d_u_r_e_ _C_R_E_A_T_E_E_N_T_R_Y_._ 8.3.1.3
Call: Return:
AC0 attributes destroyed
AC1 size destroyed
AC2 zone zone
AC3 - destroyed
The file given by the document name in zone is created with the
given size and the given attribute mask. \f
The attribute mask has the following interpretation:
bit 15 = 1 The file should be extendable, else the file is
created with fixed length, i.e. it is not allowed
to change the file length.
bit 14 = 1 Not used in createentry. Device descriptor in
DOMUS.
bit 13 = 1 Not used in createentry. Entry only.
bit 12 = 1 The file is writeprotected, i.e. it is allowed
only to read from the file.
bit 11 = 1 The file is permanent, i.e. removal and change
(except attribute change) of the file is not
allowed.
bit 10 = 1 Not used in createentry. Link entry.
bit 1 = 1 Sub catalog. The file is a sub catalog.
bit 0 = 1 Catalog file. Can be read by the user, but is
protected against write, change and removal. Only
system use is allowed.
If other bits are set in attribute mask, the giveup procedure is
called.
For status, see table 1.
\f
Create the file PIP on catalog unit 0:
FD0: ; ZONE:
.TXT .PIP0'0'. ;
. ;
. ; STANDARD LAYOUT
. ;
.
.
.
.
.
WMASK: 1B12+1B15 ;
FD1: FD0 ; REF ZONE
ENTRY: LDA 2 FD1 ;
LDA 1 .1 ; ATTRIBUTE:= 1B12+1B15;
LDA 0 WMASK ;
CREATEENTRY ; CREATEENTRY(>PIP>, 1,
; ATTRIBUTE);
. ;
. ;
Example 25.
8_._3_._1_._4_ _ _ _P_r_o_c_e_d_u_r_e_ _R_E_M_O_V_E_E_N_T_R_Y_._ 8.3.1.4
Call Return
AC0 - destroyed
AC1 - destroyed
AC2 zone zone
AC3 - destroyed
\f
The entry given by the document name in zone is, if allowed, de-
leted, and the slices reserved are released for other files.
Status: see table 1.
Remove the file PIP created in example 1:
FD2: FD0 ; REF ZONE
. ;
.
.
ENTRY: LDA 2 FD2 ;
REMOVEENTRY ;
.
.
.
.
Example 26.
8_._3_._1_._5_ _ _ _P_r_o_c_e_d_u_r_e_ _L_O_O_K_U_P_E_N_T_R_Y_._ 8.3.1.5
Call Return
AC0 - destroyed
AC1 storage area. destroyed
AC2 zone zone
AC3 - destroyed
The catalog entry given by the document name in the filedescrip-
tor is transferred to the 32 bytes area given by the word address
storagearea. The entry can then be examined for its length,\f
attributes and optional words.
The entry format is:
WORD 0-2 : Entry name
WORD 3-5 : Optional words
WORD 6 : Attributes
WORD 7 : File length (in segments)
WORD 8 : Sector address of indexblock relative to
catalog start
WORD 9 : Reserved length (sectors)
WORD 10-15 : Optional words.
Status: see table 1.
Find the length of the file PIP created in example 25:
FD3: FD0 ; REF ZONE
LENGTH = 7 ;
AREA: .+1 ; AREA:
.BLK 16 ;
ENTRY: ;
LDA 2 FD3 ;
LDA 1 AREA ;
LOOKUPENTRY ; LOOKUPENTRY(>PIP>,
; STORE);
LDA 3 AREA ;
LDA 0 LENGTH,3 ; LENG:= STORE.LENGTH;
. ;
. ;
Example 27.
\f
8_._3_._1_._6_ _ _ _P_r_o_c_e_d_u_r_e_ _C_H_A_N_G_E_E_N_T_R_Y_ 8.3.1.6
Call Return
AC0 - destroyed
AC1 storage area destroyed
AC2 zone zone
AC3 - destroyed
The storage area is destroyed after call.
The function is to change the name, filelength, attribute or op-
tional words of the entry given by the document name in the file-
descriptor.
The parameter storage area is the word address of a 32 byte memo-
ry area, with a layout as the area used in LOOKUPENTRY.
If the name has to be changed, the first 3 words of the area must
hold the new name, else the first word must be set to zero, or
the name must equal the filename.
If the file attribute has to be changed, word 6 of the area must
hold the new attribute mask, obeying the same rules as given in
CREATEENTRY. If the attribute has to be unaltered, the word must
be equal to -1.
If the filelength has to be changed, word 9 of the area is de-
fined equal to the new length, else the word must be equal to -1,
meaning no change in filelength.
It is allowed to change both name, optional words, attribute and
length or a mix of these in the same call. Status can be found in
table 1.
\f
Change the name of the file PIP to PAP using the same filede-
scriptor as in example 25.
FD4: FD0 ; REF ZONE
AREA: .+1 ;
.TXT .PAP0'0'. ; NEWNAME
0 ;
0 ;
0 ;
-1 ; OLD ATTRIBUTE
0 ;
0 ;
-1 ; OLD LENGTH
.BLK 6 ;
;
ENTRY: LDA 2 FD4 ;
LDA 1 AREA ;
CHANGEENTRY ;
.
.
.
Example 28.
8_._3_._1_._7_ _ _ _P_r_o_c_e_d_u_r_e_ _S_E_T_E_N_T_R_Y_._ 8.3.1.7
Call Return
AC0 - destroyed
AC1 storage area destroyed
AC2 zone zone
AC3 - destroyed
\f
This is an extended CREATEENTRY function as all the parameters
are taken from the storage area pointed out by the word address
storagearea.
With this function the optional words are copied to the file
entry, and they can then be used for a number of user information
concerning the file.
The storage area has the same layout as shown in the LOOKUPENTRY
call, and only word 7 and 8 are set by the catalog system.
If the catalogbit no. 13 (entry only) is set in the word defining
the attribute mask, the length of the file is set to zero by the
catalog system.
The catalog unit and entry name are taken from the first three
words of storage area, i.e. the file descriptor is only used to
define the user giveup action and the sub catalog.
Status: see table 1.
\f
Create an entry PIP with the same user information in the optio-
nal words.
FD5: FD0 ; REF ZONE
ENTRY: .+1 ;
.TXT .PIP0'0'. ; NAME (USER SET)
0 ;
0 ; OPTIONAL
0 ;
1b12+1b15 ; ATTRIBUTES (USER SET)
0 ; LENGTH (SET BY CAT)
0 ; INDEX BLOCK (SET BY
CAT)
10 ; RES.LENGTH (USER SET)
.TXT .MYFILE. ; OPTIONAL (USER SET)
.BLK 3 ;
SET: LDA 1 ENTRY ;
LDA 2 FD5 ;
SETENTRY ; SETENTRY(ZONE, ENTRY);
.
.
.
Example 29.
\f
8_._3_._1_._8_ _ _ _P_r_o_c_e_d_u_r_e_ _I_N_I_T_C_A_T_._ 8.3.1.8
Call Return
AC0 - destroyed
AC1 unit destroyed
AC2 zone zone
AC3 - destroyed
The catalogunit given by parameter >unit> is initialized, i.e.
made accessible to the process running. During initialization,
the number of free segments are counted and the catalog descrip-
tion in the configuration program CATW is updated. This procedure
must be called before any access to the unit in question, either
by the user program or by the operator by a command to the opera-
ting system if this supports disc.
The filedescriptor reference is only used for definition of the
giveup procedure.
Status: see table 1.
FD6: FD0 ; REF FILE DESCR
ENTRY: LDA 2 FD6 ;
LDA 1 .0 ; UNIT:=0;
INITCAT ; INITCAT(UNIT);
LDA 1 .1 ; UNIT:=1
INITCAT ; INITCAT(UNIT);
.
.
Example 30.
\f
8_._3_._1_._9_ _ _ _P_r_o_c_e_d_u_r_e_ _N_E_W_C_A_T_._ 8.3.1.9
Call Return
AC0 key destroyed
AC1 destroyed
AC2 zone zone
AC3 - destroyed
This procedure creates a catalog process for the sub catalog spe-
cified by the name starting in the byte address in zone.zconv.
The first 5 characters should contain the name of a sub catalog
(zero characters for unused positions). The 6th. character is
updated by the procedure. A sub catalog number delivered by the
catalog system is inserted into this character, and the name of
the created catalog process consists of all six characters. The
sub catalog number is also delivered in zone.zfile.
Each sub catalog has a sub catalog key (sub-key), which is
checked against the parameter >key>. The result is delivered in
zone.zblock, which thus gives an indication of the use of the sub
catalog. If zone.zblock = 0, then only reading should be done. If
zone.zblock ' 0, then all operations are legal.
Zone.zblock is calculated in the following way:
if (>key> = sub-key or sub-key = 0) then
zone.zblock:= ' 0
else if >key> = 0 then zone.zblock:= 0;
In all other cases the status error i_l_l_e_g_a_l_ will be
returned.
\f
The parameter >key> should thus be used in the following way:
If only reading is wanted, then >key> = 0.
If other operations will be used on the sub catalog, then
>key> = sub-key.
A sub-key equal to zero will never result in an >illegal> sta-
tus.
NOTE The catalog system does not check the usage of a sub cata-
log, except for this key checking.
If zone.zconv = 0 or points to a string containing >CAT0'0'0'>
then the operation is dummy.
8_._3_._1_._1_0_ _ _P_r_o_c_e_d_u_r_e_ _F_R_E_E_C_A_T_._ 8.3.1.10
Call Return
AC0 destroyed
AC1 destroyed
AC2 zone zone
AC3 - destroyed
The sub catalog pointed out by zone.zconv is released. The sub
catalog name must be the full name including the sub catalog num-
ber as the 6th. character. If the catalog process has no more
users and no more area processes for files in the sub catalog
exists then the catalog process is removed.
If zone.zconv = 0 or it points to a string containing
>CAT0'0'0'> then the operation is dummy.
\f
\f
8_._4_ _ _ _ _ _ _ _C_a_t_a_l_o_g_ _F_i_l_e_ _I_N_P_U_T_/_O_U_T_P_U_T_._ 8.4
When accessing data on a catalog file normal zone procedures can
be used. The only difference is that the kindbit 11 must be set,
which is checked by the basic I/O procedures when performing
OPEN, CLOSE and block shifts.
8_._4_._1_ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _O_P_E_N_._ 8.4.1
A create area process message is send to the catalog process if
zone.zconv = 0, otherwise to the sub catalog process given by the
name address in zone.zconv//2. If the mode is input, the opening
process is inserted as user. If the mode is output, the process
is inserted as exclusive user.
If no area process exists, a free area process is taken from a
common pool and initialized with the file characteristics read
from the file entry.
The file can be read/written in two modes random or sequential.
When sequential mode is used, the file is read/written from the
last defined position, i.e. the position can be initialized or
reset by a SETPOSITION command. If random mode is selected, the
block number to read/write is taken from the MESS3 part of the
resulting message. MESS3 is fetched from the zone record word
ZBLOCK, which then must be set by the user before the block is
input/output.
\f
; AC2 equals zone address
LDA 0 .5 ;
OPEN ; OPEN(ZONE,
; RANDOM INPUT);
LDA 0 .10 ;
STA 0 ZBLOCK,2 ; BLOCKNO:= 10;
INBLOCK ; INBLOCK(ZONE);
; When PUTREC is used, the procedure only makes space in the
; zone, i.e. the block number must be specified before the next
; PUTREC procedure causing a block transfer.
; AC2 equals zone address (UB format).
LDA 0 .7 ;
OPEN ; OPEN(ZONE,
; WRITE RANDOM)
LDA 0 .512 ;
PUTREC ; PUTREC(ZONE, 512);
; MOVE DATA TO BUFFER ;
. ; MOVE (DATA, ZONE);
.
.
LDA 0 .10 ;
STA 0 ZBLOCK,2 ; BLOCKOUT:= 10;
LDA 0 .512 ;
PUTREC ; PUTREC(ZONE, 512);
Example 31.
\f
MODE/RESR Random Sequential
Read 5/USER 1/USER
Write 7/EXC.USER 3/EXC.USER
Fig. 37 Modes for read/write operation and reservation status.
In fig. 37 the possible modes can be found. Other modes are al-
lowed too, but only the last three bits of the modeword is
checked by the catalog system (bit 13, 14, 15), and the mode bits
8, 9 ... 12 are transferred unmodified to the disc driver in
question, thus enabling use of special disc driver features as
read after write, word address etc. Please consult the disc dri-
ver description for further information.
During read/write only one sector is transferred, and the user
sharelength must then be defined as 512 bytes, else a blocklength
error is indicated, and no data is transferred.
For each OPEN call (create area process) the user OPEN/CLOSE
count is incremented by one. This count indicates how many zones
the user has opened to the same file and is used by the catalog
system in the decision when to remove the area process, as this
happens only when all 3 user OPEN/CLOSE counts has reached zero.
(Further details, see procedure CLOSE).
\f
8_._4_._2_ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _S_E_T_P_O_S_I_T_I_O_N_._ 8.4.2
The user position is set to the block parameter, which indicates
number of sectors from file start, i_._e_._ _t_h_e_ _f_i_r_s_t_ _s_e_c_t_o_r_ _i_s_ _s_e_c_-
t_o_r_ _0_. The file parameter is ignored. Negative block numbers are
illegal and positions outside the file are rejected by a status.
See table 2 for status.
8_._4_._3_ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _C_L_O_S_E_._ 8.4.3
After normal close action, a remove area process command is sent
to the catalog system or to the sub catalog process as indicated
by zone.zconv, if the release parameter is nonzero. When the re-
move command is received the user OPEN/CLOSE count is decremen-
ted, and if zero, and no other user reservations exist, the area
process is removed and included in the common pool of free area
processes.
Please note that when release parameter is zero no remove area
process command is send, i.e. the sequence
CLOSE(zone, 0);
OPEN(zone, mode);
increments the OPEN/CLOSE count and removal of the process is on-
ly possible, if CLOSE with nonzero release parameter is called
twice.
8_._4_._4_ _ _ _ _ _C_a_t_a_l_o_g_ _I_n_p_u_t_/_O_u_t_p_u_t_._ 8.4.4
During input/output bytecount must equal 512 bytes, else the
message is rejected with blocklength status. It is then a general
rule that if kind bit 11 is set (which it must be when OPEN/CLOSE
is used) the whole share is output/input independent of the ac-
tual state of zone pointers and values, i.e. the zrem record ele-\f
ment does not give the number of bytes output, except when zrem
equals 512 and defines no bytes to be output. After input to a
zone with kind bit 11 set, zrem is always defined to 512. This
fact can cause trouble when the formats F, FB, V and VB are used
in connection with disc files with the Record I/O procedures if
the record size does not fit in a 512 bytes block.
Special care must also be taken, if partiel updating of single
file sectors is wanted, i.e. mixed read/write are performed.
; PROCEDURE PART _UPDATE
;
; CALL RETURN
; AC0 SECTOR DESTROYED
; AC1 VALUE DESTROYED
; AC2 ZONE ZONE
; AC3 LINK DESTROYED
;
; WORD 10 IN THE GIVEN SECTOR IS SET EQUAL THE VALUE GIVEN IN AC1.
; THE SECTOR IS OUTPUT AFTER MODIFICATION. BEFORE CALL THE ZONE
; MUST BE OPENED IN MODE 5 (RANDOM READ);
; AFTER RETURN THE ZONE IS OPENED IN MODE 5 AND NO BYTES DEFINED
; INPUT.
\f
PARO0: STA 3 PARO1 ; PART _UPDATE:
STA 1 PARO2 ;
STA 0 ZBLOCK,2 ; ZONE.ZBLOCK:= SECTOR
INBLOCK ;
LDA 3 ZTOP,2 ; INBLOCK(ZONE); !ONLY
; ZTOP DEFINED!
MOVZR 3,3 ;
LDA 1 PARO2 ; WORD(ZONE.ZTOP//2):=
; VALUE
STA 1 +10,3 ;
LDA 1 .7 ;
STA 1 ZMODE,2 ; ZONE.ZMODE:= 7; !WRITE!
DSZ ZBLOCK,2 ; ZONE.ZBLOCK:=
; ZONE.ZBLOCK-1;
JMP .+1 ;
LDA 1 .0 ; ZONE.ZREM:= 0;
STA 1 ZREM,2 ; OUTBLOCK(ZONE);
OUTBLOCK
LDA 0 .5 ;
STA 0 ZMODE,2 ;
LDA 0 .0 ;
STA 0 ZREM,2 ;
JMP@ PARO1 ;
PARO1: 0 ; LINK
PARO2: 0 ; SAVED VALUE
Example 32.
The example can be used for more special update tasks if the
assigning of word 10 is replaced with appropriate code.
It should be noted that the zone in question is defined with a
single share, as multibuffering in random access makes no sense.
\f
\f
A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_._
1 DOMAC, Domus Macro Assembler,
User>s Guide.
Keywords: RC3600, Macro Assembler, User>s Guide.
Abstract: This paper described the RC3600 Macro Assemb-
ler Language and operation of the DOMAC macro
Assembler.
2 RC3600 Pagings System,
System Operators Guide.
Keywords: MUS, Paging System, Virtual Memory, Address
Mapping.
Abstract: This manual describes, how to use the RC3600
paging system from assembly programs under
the MUS system.
3 Extended RC3600 Coroutine Monitor.
Programmer>s Manual.
Keywords: RC3600, Coroutine Monitor, MUS.
Abstract: The coroutine monitor is a set of reentrant
utility procedures for RC3600 MUS, with faci-
lities for mutual synchronization and ex-
change of data between cooperating parallel
activities. This manual is the MUS program-
mer>s reference for the extended monitor.
4 XCOMX, Processor Expansion.
User>s Guide.
Keywords: RC3600, MUS, Processor Expansion.
Abstract: This manual describes the use of the proces-
sor expansion system, XCOMX, under the MUS
monitor for the RC3600 line of computers.
\f
5 RC3600 Catalog System.
System Programmer>s guide.
Keywords: Catalog system, file system, area process,
subcatalog.
Abstract: This manual describes, how to use the RC3600
Catalog System from assembler programs. Also
the organization of the disc(s) is described.
The user must be familiar with the MUS sys-
tem.
6 DOMUS Linkage Editor.
Keywords: DOMUS, Macro Assembler, Linkage Editor.
Abstract: This manual describes the linkage editor for
the disc operating system DOMUS for RC3600
line of computers.
7 DOMUS, USER>S GUIDE, Part 1, Version 3
Keywords: DOMUS, MUS, Operating System, Loader, Disc.
Abstract: This manual describes the disc operating
system DOMUS for the RC3600 line of compu-
ters.
8 DOMUS, System Programmers Guide, Version 3
Keywords: MUS, Operating System, Loader, Disc, Version
3.
Abstract: This manual describes the interface between
assembly programs and DOMUS.
9 MUS Operating System, User>s Guide
Keywords: MUS, Operating System, Master Device Media
Abstract: This manual describes the operating system S
contained in the MUS system for the RC3600
line of computers.
\f
B_._ _ _ _ _ _ _ _ _T_E_R_M_I_N_O_L_O_G_Y_._
a_d_d_r_e_s_s_ An address may be a w_o_r_d_ _a_d_d_r_e_s_s_, which is a
15 bit unsigned integer, corresponding to a
physical address in primary storage. Or it
may be a byte address, which is a word add-
ress left shifted one bit and with a one ad-
ded into bit 15 if the byte addressed within
the word is the rightmost.
b_i_t_ A computer word consists of 16 bits, numbered
from left to right:
B0, B1, B2, .........B15.
b_y_t_e_ A computer word is regarded as two 8 bit
bytes. The left byte B0 to B7 has an even
address and the right byte B8 to B15 an odd
address.
c_h_a_r_a_c_t_e_r_ A character is a byte. The common alphabet
within the system is the ASCII alphabet.
t_e_x_t_ A text is a sequence of characters. Starting
at a byte address and left justified. A text
is terminated by a Null character with byte
value zero.
d_e_s_c_r_i_p_t_o_r_ A collection of information, which describes
an object, is called a descriptor. Descrip-
tors are found as part of i_t_e_m_s_ and as part
of z_o_n_e_s_.
i_t_e_m_ An item is a primary storage area, which is
headed by a descriptor, the first part of
which usually has a standard layout. This en-
sures that an item always may be in some
c_h_a_i_n_ and possibly also in a q_u_e_u_e_. The first
words of an item contain the f_i_e_l_d_s_:
\f
next: next item in a queue
prev: previous item in a queue
chain: next item in a chain
size: the size of the storage
area of the item
name: (3 words) a text identi-
fying the item
f_i_e_l_d_ A field is a displacement, which identifies a
piece of information within a descriptor.
Some important fields are predefined in the
system assembler, and/or in the musil compi-
ler.
c_h_a_i_n_ (linked linear list). A chain consists of a
chain head and a number of chain elements.
The head and each element points to the next
item in the chain, the last element equals
zero.
q_u_e_u_e_ (doubly linked cyclical linear list). A queue
consists of one or more queue elements. One
of the elements is the queue head. A queue
element consists of two consecutive words
pointing to the next element in the queue and
the previous element in the queue respec-
tively.
When the queue is empty, the head points to
itself. When an element is not in a queue, it
normally points to itself.
l_e_n_g_t_h_ The term length is used to express the number
of b_y_t_e_s_ contained in some storage area.
\f
s_i_z_e_ The term size is used to express the number
of words contained in some storage area.
p_r_o_g_r_a_m_ A collection of instruction and data which
may be executed or accessed by one or more
processes.
p_r_o_c_e_s_s_ A sequential execution of programs under con-
trol of the monitor. All information about a
process is collected in a process
descriptor.
m_o_n_i_t_o_r_ The nucleus of the system which implements
multiprogramming, i.e. the parallel execution
of several processes on a single processor.
d_e_v_i_c_e_ One of a collection of units which can re-
ceive data from the processor or transmit da-
ta to the processor, often in parallel with
the execution of computer instructions.
d_r_i_v_e_r_ A process executing a driver program in order
to control input/output to a device.
d_i_s_c_ Any random access storage unit connected to
the computer.
d_r_i_v_e_ A disc unit station in the system. All drives
are numbered from zero and to a maximum and
are administrated by the cat process.
f_i_l_e_ A logical collection of data residing on a
disc having a name (discfile). Sometimes we
shall denote a roll of paper tape or a col-
lection of data between two tape marks on a
magtape reel as a file too.
\f
z_o_n_e_ A collection of information and associated
storage areas necessary to perform operation
on files and devices.
\f
C_._ _ _ _ _ _ _ _ _D_E_V_I_C_E_ _C_O_D_E_S_._ C.
Decimal Octal
code code Mnemonic Maskbit Device
01 01 Extended Memory
02 02
03 03
04 04
05 05 ASL Automatic System Load
06 06
07 07
08 10 TTI 14 Teletype Input
09 11 TTO 15 Teletype Output
10 12 PTR 11 Paper Tape Reader
11 13 PTP 13 Paper Tape Punch
12 14 RTC 13 Real Time Clock
13 15 PLT 12 Incremental Plotter
SPC2 9 Third Standard Parallel
Controller
14 16 CDR 10 Card Reader
15 17 LPT 12 Line Printer
16 20 DSC 4 Disc Storage Channel
17 21 SPC 9 Standard Parallel control-
ler
18 22 SPC1 9 Second Standard Parallel
controller
Second Dial-up Controller
19 23 PTR1 11 Second Paper tape Reader
20 24 AMX3 2 Fourth 8 Channel Asynchro-
nous Multiplexor
TMX10 0 Second 64 Channel
21 25 TMX11 1 Asynchrounous Multiplexor
22 26 TMX0 0 64 Channel Asynchronous
23 27 TMX1 1 Multiplexor \f
Decimal Octal
code code Mnemonic Maskbit Device
24 30 MT 5 Magnetic tape
25 31 PTP1 13 Second Paper Tape Punch
26 32 TTI2 14 Third Teletype Input
OCP-Function, Button Out
27 33 TTO2 15 Third Teletype Input
OCP-function, Button IN
28 34 TTI3 14 Fourth Teletype Input
OCP-Numeric Keyboard In
29 35 TTO3 15 Fourth Teletype Output
DISP 7 OCP-Display
30 36 OCP-Autoload
31 37 LPS 12 Serial Printer
32 40 REC 8 BSC Controller
33 41 XMT 8
34 42 REC1 8 Second BSC Controller
35 43 XMT1 8
36 44 MT1 5 Second Magnetic Tape
37 45 CLP 12 Charaband Printer
38 46 FPAR 3 Inter Processor Channel
Receiver
39 47 FPAX 3 Inter Processor Channel
Transmitter
40 50 TTI1 14 Second Teletype Input
41 51 TTO1 15 Second Teletype Output
42 52 AMX 2 8 channel Asynchroneous
Multiplexor
43 53 AMX1 2 Second 8 channel Asynchro-
neous Multiplexor
44 54 HLC 8 HDLC Controller
FPAR2 3 Third Inter Processor
Channel Receiver
45 55 HLC1 8 Second HDLC Controller
FPAX2 3 Third Inter Processor
Channel Transmitter \f
Decimal Octal
code code Mnemonic Maskbit Device
46 56 CDR1 10 Second Card Reader
47 57 LPT1 12 Second Line Printer
LPS2 12 Third Serial Printer
48 60 SMX Synchronous Multiplexor
49 61 FDD 7 Flexible Disc Drive
50 62 CRP 10 Card Reader Punch
51 63 CLP1 12 Second Charaband Printer
52 64 FDD1 7 Second Flexible Disc Drive
53 65 LPS3 12 Fourth Serial Printer
54 66 DTC 9 Digital Cartridge Control-
ler
LPS4 12 Fifth Serial Printer
55 67 LPS1 12 Second Serial Printer
56 70 DST Digital Sense
57 71 DOT Digital Output
58 72 CNT Digital Counter
Dial-up Controller
59 73 DKP 7 Moving Head Disc Channel
60 74 FPAR1 3 Second Inter Processor
Channel Receiver
61 75 FPAX1 3 Second Inter Processor
Channel Transmitter
62 76 AMX2 2 Third 8 channel Asyn-
chronous Multiplexor
63 77 CPU Central Processor
\f
D_._ _ _ _ _ _ _ _ _F_I_R_S_T_ _A_N_D_ _S_E_C_O_N_D_ _P_A_P_E_R_ _T_A_P_E_ _P_U_N_C_H_ _D_R_I_V_E_R_._ D.
\f
\f
\f
\f
\f
\f
«eof»