|
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: 171392 (0x29d80)
Types: TextFile
Names: »D161«
└─⟦ae2411776⟧ Bits:30008864 Diskette med tekster der formodes at være 31-D-152…161
└─⟦this⟧ »D161«
\f
EX-
NAME TER- CALL RETURN DELAY
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _N_A_L_ _ _ _W_0_ _ _ _ _ _ _ _W_1_ _ _ _ _ _ _W_2_ _ _ _ _ _ _W_3_ _ _ _ _ _ _W_0_ _ _ _ _ _ _ _W_1_ _ _ _ _ _ _W_2_ _ _ _ _ _W_3_ _ _ _ _P_A_G_E_2_ _ _ _ _ _
OPEN 4 SEM RETURN UNCH. UNCH Ø PAGE1 UNCH N
OPEN CHAINED 6 OP SEM RETURN Ø Ø Ø PAGE1 0 M
LOCK 3 SEM RETURN Ø Ø Ø PAGE1 UNCH M
L_O_C_K_ _C_H_A_I_N_E_D_ _ _ _ _ _ _ _ _ _5_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_E_M_ _ _ _ _ _R_E_T_U_R_N_ _ _Ø_ _ _ _ _ _ _ _ _ _O_P_ _ _ _ _ _Ø_ _ _ _ _ _ _P_A_G_E_1_ _O_P_._P_A_G_E_ _M_ _
GET PAGES 7 RETURN Ø Ø Ø PAGE1 UNCH M
PAGE JUMP 8 PAGE0 REL Ø Ø Ø PAGE1 UNCH M
(W1-) CALL 25 RETURN PAGE0 REL Ø Ø Ø PAGE1 UNCH M
W_0_ _-_ _C_A_L_L_ _ _ _ _ _ _ _ _ _ _ _3_4_ _ _ _ _S_T_O_R_E_ _ _ _ _R_E_T_U_R_N_ _ _P_A_G_E_0_ _ _ _R_E_L_ _ _ _ _ _Ø_ _ _ _ _ _ _ _ _Ø_ _ _ _ _ _ _ _Ø_ _ _ _ _ _ _P_A_G_E_1_ _U_N_C_H_ _ _ _ _M_ _
WAIT ANSWER 35 MESSBUF RETURN STATUS ANSW Ø PAGE1 0 Y
SEND AND WAIT 1 MESS NAME RETURN STATUS ANSW Ø PAGE1 0 Y
SEND AND WAIT FAST 2 MESS NAME RETURN STATUS ANSW Ø PAGE1 BUFPAGE Y
SEND AND WAIT SLOW 9 MESS NAME RETURN STATUS ANSW Ø PAGE1 BUFPAGE Y
STOP AND WAIT 30 NAME RETURN STATUS ANSW Ø PAGE1 0 Y
C_L_E_A_R_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _1_1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _R_E_T_U_R_N_ _ _Ø_ _ _ _ _ _ _ _ _Ø_ _ _ _ _ _ _ _Ø_ _ _ _ _ _ _P_A_G_E_1_ _U_N_C_H_ _ _ _ _Y_ _
PREPARE ACCESS 32 LOW.BASE UP.BASE NAME RETURN LOW.AREA UP.AREA ACCESS PAGE1 UNCH N
T_E_R_M_I_N_A_T_E_ _A_C_C_E_S_S_ _ _ _ _3_3_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _N_A_M_E_ _ _ _ _R_E_T_U_R_N_ _ _L_O_W_._A_R_E_A_ _U_P_._A_R_E_A_ _A_C_C_E_S_S_ _P_A_G_E_1_ _U_N_C_H_ _ _ _ _N_ _
PRIV-OUT 21 HEAD1 TAIL RETURN Ø Ø Ø PAGE1 UNCH N
JD-1 - W0 W1 W2 W3 UNCH UNCH UNCH UNCH UNCH N
J_D_-_X_X_X_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-_ _ _ _ _L_E_N_G_T_H_ _ _ _T_A_I_L_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _U_N_C_H_ _ _ _ _ _U_N_C_H_ _ _ _ _U_N_C_H_ _ _ _U_N_C_H_ _ _U_N_C_H_ _ _ _ _N_ _
L_E_G_E_N_D_ _T_O_ _S_U_R_V_E_Y_ _O_F_ _C_._L_._ _P_R_O_C_E_D_U_R_E_S_
SEM - Abs address of semaphore (in semaphore table)
RETURN - Abs address of return-jump. Must be inside current page0.
PAGE1 - Abs address of first word of page1
OP - Abs address of operation
MESS - Abs address of 8 words to send as message
NAME - Abs address of 5 words: name of receiver + NTA of receiver
ANSW - Abs address of 8 words containing the answer
MESSBUF - Abs address of message buffer sent
STORE - Abs address of word where virtual return is stored.
UNCH - Unchanged
Ø - Undefined
STATUS - Logical status of answer: if result = 1 then (2+answ(1)) else 1 shift result
BUFPAGE - Address of the page used as buffer (virt/abs)
OP.PAGE - Address of the page containing the operation (virt/abs)
PAGE2 - Page 2 address: in coroutine descr (virt) and on page0 (abs)
PAGE0 - VIRT address of the wanted new page0
REL - Relative adddress to exit to on the wanted new page0
LOW.BASE - Lower limit of catalog base to lookup the area
UP.BASE - Upper limit of catalog base to lookup the area
LOW.AREA - Lower limit of the found area
UP.AREA - Upper limit of the found area
ACCESS - Total no of accesses to the area (accesscount)
HEAD1 - First word of head: length < 6+kind
TAIL - Abs address of the words to move to tail of record
EXTERNAL - No of the external variable holding address of the procedure
DELAY - Tells if the C.L. delays the coroutine. Y=yes, N=no, M=maybe
XXX - An integer 201 <= XXX <= 263. Testoutputkind will be XXX-200 \f
i
F_O_R_E_W_O_R_D_
First edition: RCSL No 31-D673.
The current version of BOSS was first developed in 1971-72. Dur-
ing the past years, several extensions and modifications have
been implemented.
For the maintenance staff, a great need arised for an updated de-
scription of the basic parts of the internal structure. The man-
ual is written to fulfil this purpose.
Part of the manual is collected from old internal descriptions.
Part of this manual replaces some chapters in RCSL No 31-D628
(BOSS2 Installation and Maintenance) in order to be able to sep-
arate installation from maintenance in the future.
The manual has no educational purpose. Still, the advanced user
may find it interesting.
The descriptions correspond to Release 18.0 (of the software
package SW8101/1).
C.H. Dreyer
A/S REGNECENTRALEN af 1979, June 1982
\f
ii
\f
iii
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. INTRODUCTION ........................................... 1
2. COMMON DATA STRUCTURES ................................. 2
2.1 Common Resident Tables ............................ 2
2.1.1 Core Table ................................. 2
2.1.2 Segment Table .............................. 3
2.1.3 Semaphore Table ............................ 4
2.1.4 Terminal Buffers ........................... 5
2.1.5 Sender Table ............................... 5
2.1.6 Coroutine Table ............................ 7
2.1.7 File Access Table .......................... 9
2.1.8 Run Test Buffers ........................... 10
2.2 Internal Queues in Central Logic .................. 10
2.3 Datastructures in Virtual Core .................... 11
2.3.1 Code Pages ................................. 12
2.3.2 Variable Pages ............................. 12
2.3.3 Operations ................................. 13
2.3.4 Job File Pages ............................. 14
2.3.5 Job Description Pages ...................... 18
2.4 Time Representations .............................. 24
3. CENTRAL LOGIC PROCEDURES ............................... 26
3.1 Survey of Central Logic Procedures ................ 27
3.2 Procedure Descriptions ............................ 28
3.2.1 Open ....................................... 28
3.2.2 Open Chained ............................... 28
3.2.3 Lock, Lockchained .......................... 29
3.2.4 Get Pages .................................. 31
3.2.5 Page Jump .................................. 31
3.2.6 W1-Call .................................... 31
3.2.7 W0-Call .................................... 32
3.2.8 Wait Answer ................................ 32
3.2.9 Send and Wait .............................. 32
3.2.10 Send and Wait Fast, Send and Wait Slow ..... 33
3.2.11 Stop and Wait .............................. 33
3.2.12 Clear Core ................................. 34
3.2.13 Prepare Access ............................. 34 \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_
3.2.14 Terminate Access ........................... 35
3.2.15 Priv-Out ................................... 35
3.2.16 JD-1 ....................................... 35
3.2.17 JD-XXX ..................................... 36
4. LOADER ................................................. 37
4.1 Core Layouts ...................................... 38
4.2 Init and Load, Step by Step ....................... 38
4.3 Loader Procedures ................................. 40
4.3.1 Algorithm for Linking a Module ............. 40
4.3.2 Set Externals .............................. 43
4.3.3 Reserve Virtual ............................ 44
4.3.4 Move to Virtual ............................ 45
4.3.5 Put in Active Queue ........................ 45
4.3.6 Simulate Lock .............................. 46
4.4 Format of a Module File ........................... 47
5. PAGER, VIRTUAL CORE .................................... 49
5.1 A Virtual Address ................................. 49
5.2 A Page ............................................ 50
5.3 A Section ......................................... 51
5.4 Use of BOSS Core .................................. 51
5.5 Working Cycle of the Pager ........................ 53
5.6 Relations to Core Table and Segment Table ......... 54
6. TESTOUTPUT FORMATS ..................................... 55
6.1 Codepage Identifications .......................... 68
6.2 Coroutine Identifications ......................... 69
\f
F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
This book is a maintenance manual, and so it is a working docu-
ment for the people maintaining BOSS: It is a collection of de-
scriptions that are needed over and over again when programming
for BOSS, and so a general understanding of the structure of the
system is more or less presupposed.
The program text for the online system is contained in 10 files,
compiled separately (but using the same option file). These files
are referred to as MODULES.
The first MODULE, named 'bos' (or central) contains the basic
elements:
- Central Logic procedures (or C.L.)
- Pager coroutine
- Initialization and loader/linker.
Besides this, the commonly used data structures are described.
These descriptions are closely related to the method of referenc-
ing the structure in slang (suppose the absolute address of first
word is contained in register W1):
+0: _ _ _ _ _ _ _ _ _ _ _ _ first word, referred as "X1".
+2: _ _ _ _ _ _ _ _ _ _ _ _ second word, as "X1+2".
+4: _ _ _ _ _ _ _ _ _ _ _ _ third word, as "X1+4".
+6: _ _ _ _ _ _ _ _+_7_:_ _ hw No 7, as "X1+6". hw No 8, as "X1+7".
\f
F_ 2_._ _ _ _ _ _ _ _ _C_O_M_M_O_N_ _D_A_T_A_ _S_T_R_U_C_T_U_R_E_S_ 2.
2_._1_ _ _ _ _ _ _ _C_o_m_m_o_n_ _R_e_s_i_d_e_n_t_ _T_a_b_l_e_s_ 2.1
The common data structures resident in BOSS core are placed in
tables in the high-address end of BOSS core at run time.
In this survey, they are mentioned from the low address end:
M_m_m_ - core table
Allocated after first loader pass.
P_p_p_ - segment table
- semaphore table Allocated during first loader pass.
- terminal buffers
- sender table
- coroutine table Allocated at init (before first loader
pass).
- file access table
- run test buffers
(- top address of BOSS)
2_._1_._1_ _ _ _ _ _C_o_r_e_ _T_a_b_l_e_ 2.1.1
Core table holds one entry for every segment place in page core
(see chapter 5). Coretable is indexed with core index: segment
places counted from 0. Segment number (in + 3) is relative to
first drum segment (cf. 5.6).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Core index: 0 1 2 3 4 5 - - - -
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _C_O_R_E_ _T_A_B_L_E_ _ _ _ _ _ _ _ _ _ _ _ _ _
Entries: 0 1 2 3 4 5 - - - -
Format of a core table entry (size = 4 hw):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0: _c_o_r_e_ _i_n_d_e_x_ _f_o_r_ _f_i_r_s_t_ _s_e_g_m_e_n_t_ _o_f_ _s_e_c_t_i_o_n_ _ _
+1: _p_r_i_o_r_i_t_y_ _(_=_ _0_ _f_o_r_ _l_a_t_e_r_ _s_e_g_m_e_n_t_s_)_ _ _ _ _ _ _ _ _
+2: _l_e_n_g_t_h_ _o_f_ _s_e_c_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+3: _s_e_g_m_ _n_u_m_b_e_r_ _o_f_ _f_i_r_s_t_ _s_e_g_m_e_n_t_ _o_f_ _s_e_c_t_i_o_n_ _ _
\f
Priority (12 bits):
M_S_B_ _ _ _ _ _ _ _ _ _ _ _ _(_7_ _b_i_t_s_)_ _ _ _ _ _ _ _ _ _ _L_S_B_
_ _ _ 1 = write page
_ _ _ _ _ _ _ _ _ _ _ _ _ priority (2-254)
_ _ 1 = fast buffer (send and wait fast)
_ _ _ _ _ 1 = slow buffer (send and wait slow)
_ _ _ _ _ _ _ _ 1 = requested and in core already
_ _ _ _ _ _ _ _ _ _ _ 1 = job place
Length:
4 * number of segments for first segment in section, 0 for later
segments, 4 for free segments and later segment places for a job.
Core table is terminated with a dummy top entry with the format:
first index = 0
priority = 4095
length = core table length - 4
segment No = 4095
2_._1_._2_ _ _ _ _ _S_e_g_m_e_n_t_ _T_a_b_l_e_ 2.1.2
Segment table holds one entry for every segment in virtual core
(drumcore/disccore - see chapter 5).
Segment table is indexed with segment No: first entry is segm No
= (last addr of BOSS) //512+1, so only segment places of virtual
core are contained in segment table.
\f
Format of a segment table entry:
Length = 1 hw, 12 bits:
M_S_B_ _ _ _ _ _ _ _ _ _ _ _ _(_1_0_ _b_i_t_s_)_ _ _ _ _ _ _ _ _ _L_S_B_
_ _ _ 0 = first segm in section
Core index for this 1 = later segm in section
segment, if section _ _ _ _ _ _ 0 = section in core
is in core (0-1023). 1 = section not in core
2_._1_._3_ _ _ _ _ _S_e_m_a_p_h_o_r_e_ _T_a_b_l_e_ 2.1.3
The semaphore table is allocated (and defined in size) during
first loader pass, by reservations in external 19.
The semaphore table contains semaphore descriptions and also a
diversity of private datastructures, not described here.
Format of a semaphore description:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
SEMAPHORE ->+0: SEM. VALUE length = 6 hw
ADDR +2: FIRST IN QUEUE (option e13)
_+_4_:_ _L_A_S_T_ _I_N_ _Q_U_E_U_E_ _ _ _ _
Examples of contents of semaphore descriptions:
CORUNO is addresses of a coroutine description
VIRT.OP is virtual address of an operation.
- SIMPLE SEMAPHORE: (OPEN USED)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
-2 -1 0 1 2
FIRST CORUNO CORUNO 0 0 0
_L_A_S_T_ _C_O_R_U_N_O_ _ _ _ _C_O_R_U_N_O_ _ _0_ _ _0_ _ _0_ _
\f
- CHAINED SEMAPHORE: (OPEN CHAINED USED)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
-2 -1 0 1 2
FIRST CORUNO CORUNO 0 VIRT.OP FIRST VIRT.OP
_L_A_S_T_ _C_O_R_U_N_O_ _ _ _ _C_O_R_U_N_O_ _ _0_ _ _V_I_R_T_._O_P_ _ _L_A_S_T_ _V_I_R_T_._O_P_ _
2_._1_._4_ _ _ _ _ _T_e_r_m_i_n_a_l_ _B_u_f_f_e_r_s_ 2.1.4
Used for terminal input/output. Allocated at init. A buffer for
each possible terminal supported. Number of buffers = option
i4+1. Buffer length = option i3 hws.
2_._1_._5_ _ _ _ _ _S_e_n_d_e_r_ _T_a_b_l_e_ 2.1.5
Each entry holds a description of a (maybe unknown) process send-
ing messages to BOSS, and a semaphore to open when it occurs. Al-
located at init. Number of entries = option e15.
When C.L. detects a message arrived from another process, this
event is signalled to a waiting coroutine by making open chained
of an operation to a specific semaphore. The possible senders and
related semaphores are found in sender table.
F_o_r_m_a_t_ _o_f_ _s_e_n_d_e_r_ _t_a_b_l_e_:
ONE TABLE ENTRY: (length = 10 hws)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_+_0_:_ _P_r_o_c_e_s_s_ _d_e_s_c_r_._ _a_d_d_r_ _o_f_ _a_ _k_n_o_w_n_ _s_e_n_d_e_r_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_+_2_:_ _A_d_d_r_e_s_s_ _o_f_ _s_e_m_a_p_h_o_r_e_ _t_o_ _s_i_g_n_a_l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_+_4_:_ OPER: +_0_:_ _C_H_A_I_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_+_6_:_ +_2_:_ _f_r_e_e_,_ _o_p_._k_i_n_d_ _(_=_0_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+8: +4: Mess. buf. addr of received mess.
or = 1: mess in queue, but no coroutine waiting
_ _ _ _ _ _ _ _o_r_ _=_ _0_:_ _n_o_ _m_e_s_s_a_g_e_ _i_n_ _q_u_e_u_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
Total number of sender table entries:
e15: = commandios + unknown sender (2)
+ pseudojobs + operator display (1);
C_._L_._ _p_e_r_f_o_r_m_s_, when message is received:
1. find sender in sendertable (last entry = unknown sender)
2. if oper already describes a mess ready for coroutine or corou-
tine not waiting (sem. value > -1) then skip the message (in
the event queue) else:
insert mess buf addr in oper.
simulate open chained (oper)
page 2 (activated coroutine): = abs addr of oper.
get event (mess. buf addr);
T_h_e_ _c_o_r_o_u_t_i_n_e_ _p_e_r_f_o_r_m_s_:
1. lock chained (SEM).
On SEM, many different operations may arrive, also an oper-
ation describing an arrived message (as address of SEM is in-
serted in a sender table entry).
"Message-operations" are distinguished by having fouth hw
(OPER+3) = 0 (op.kind = 0), by convention.
Having received such an operation, proceed with:
2. Copy message (maybe).
3. Take actions on message.
4. Send answer and set OPER(+4):= 0
OPER(+2):= 0 (= free), maybe. (hw).
5. Proceed with other tasks, maybe.
Now, a new message may be handled by C.L., but only one.
6. Return to 1.
\f
2_._1_._6_ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _T_a_b_l_e_ 2.1.6
The coroutine table contains coroutine descriptions. Allocated at
init. Number of entries = option e14 (= number of coroutines).
In the code of C.L., the variable named f1 (called coruno) holds
the abs address of current coroutine description (the abs address
of f1 is in ext (26)). And the variable named f2 (called coruno
code) holds the abs address of current coroutine code page.
Format of an entry in coroutine table, (see details below, length
= 16 hws, option e12):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0 _C_H_A_I_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+2 _S_T_A_T_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+4 _C_O_R_O_U_T_._I_D_E_N_T_,_ _T_E_S_T_,_ _R_E_L_._R_E_T_U_R_N_ _
+6 _P_A_G_E_0_ _ _ _ _ _ _ _ _ _
+8 _P_A_G_E_1_ _ _ _ _ _ _ _ _ _ Virtual
+10 _P_A_G_E_2_ _ _ _ _ _ _ _ _ _ address
+12 _P_A_G_E_3_ _ _ _ _ _ _ _ _ _
+14 _P_A_G_E_4_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
The virtual addresses of pages should be interpreted: if it is >
max core addr of BOSS, it is a virtual address. Otherwise it is
some core address (e.g. CL will sometimes use page 2 for a core
address).
On exit to a corutine, CL promises that all pages having a real
virtual address are in core.
\f
Detailed format of a coroutine description:
length = 16 hws (option e12)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
CORUNO-> +0 CHAIN:
M_m_m_ (f1) - TO NEXT IN QUEUE
IF IN SOME QUEUE
P_p_p_ - OR = 0 IF LAST IN QUEUE
_ _ _ _ _ _ _ _-_ _O_R_ _U_N_D_E_F_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+2 STATE:
= 0 when running, and other cases
= 1 after lock/lock chained, when SEM.VAL <= 0.
(for testoutput of operation at exit).
< FIRST of BOSS: waiting for answer
(= message buffer addr).
< LAST of BOSS: after lock/lock chained, when
SEM VAL > 0 during check-pages.
(= SEM ADDR)
>=LAST of BOSS: during openchained,
waiting for virtual operation to be moved
_ _ _ _ _ _ _ _ _ _ _ _t_o_ _c_o_r_e_ _(_t_o_ _u_p_d_a_t_e_ _t_h_e_ _c_h_a_i_n_s_)_ _ _ _ _ _ _ _ _ _ _ _ _ _
+4 COROUTINE IDENT <15 (No, 1-999)
+ TEST PATTERN <12 (3 BITS, TESTOUTPUT)
+ REL. RETURN
(The relative addr to return to in page 0, when
_ _ _ _ _ _ _ _e_x_i_t_ _i_s_ _d_o_n_e_ _t_o_ _c_o_u_r_u_t_i_n_e_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+6 PAGE0: (VIRTUAL ADDR)
_ _ _ _ _ _ _C_O_D_E_ _P_A_G_E_ _c_u_r_r_e_n_t_l_y_ _u_s_e_d_ _b_y_ _t_h_e_ _c_o_r_o_u_t_i_n_e_ _ _ _ _ _ _ _
+8 PAGE1: (VIRTUAL ADDR)
_ _ _ _ _ _ _V_A_R_I_A_B_L_E_ _P_A_G_E_,_ _v_a_r_i_a_b_l_e_s_ _u_s_e_d_ _b_y_ _t_h_e_ _c_o_r_o_u_t_i_n_e_ _ _
+10 PAGE2: (VIRTUAL ADDR)
SET BY CENTRAL LOGIC:
= OPERATION after lockchained
INTERNAL USE IN CENTRAL LOGIC:
= VIRT: of last operation in queue during opench
= 0 after send and wait/stop and wait
= CORETABLE REF. OF BUFFER after send and wait
_ _ _ _ _ _ _ _ _f_a_s_t_-_s_l_o_w_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+12 PAGE3: (VIRTUAL ADDR)
_ _ _ _ _ _ _S_E_T_ _B_Y_ _C_O_R_O_U_T_I_N_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+14 PAGE4: (VIRTUAL ADDR)
_ _ _ _ _ _ _S_E_T_ _B_Y_ _C_O_R_O_U_T_I_N_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
2_._1_._7_ _ _ _ _ _F_i_l_e_ _A_c_c_e_s_s_ _T_a_b_l_e_ 2.1.7
The file access table is used to control the access from corou-
tines to bs files. It is closely coupled to the name table of the
monitor.
Each entry in file accesstable is 1 hw, and corresponds to one
area process description in the monitor (= number of entries).
Allocated during init.
B_O_S_S_: R_C_8_0_0_0_ _M_O_N_I_T_O_R_:
FILE ACCESS AREA PROCESS
TABLE: NAME TABLE: DESCRIPTIONS:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0: count first area +0 first area first
+1: count second area +2 area
+2: +4 _ _ _ _ _ _ _ _
+3: second
. area
.
. _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _
last
+N: _c_o_u_n_t_ _ last area +2xN: _ _ _ _ _ _ last area area
_ _ _ _ _ _ _ _
The file access table is indexed via the name table address
(NTA), which is the absolute address of the word in name table
pointing to the process description in question. NTA is set by
C.L. procedure prepare access, which creates an area process.
"count" is counting number of simultaneous "openings" to the file
described by the area process.
An "opening" is understood as the time between call of prepare
access and terminate access.
\f
A negative count will lead to bossfault 2. If count > 1, more
than one coroutine (e.g. terminals) have opened to this specific
file, and it must not be destroyed or overwritten.
2_._1_._8_ _ _ _ _ _R_u_n_ _T_e_s_t_ _B_u_f_f_e_r_s_ 2.1.8
Allocated during init. 2 buffers, maybe only one (if option e7 =
-1).
Each buffer is 512 hws (+ one dummy word). Used by C.L. pro-
cedures for testoutput. When a buffer is full (no room for next
testoutput record), it is sent to the device.
The device may be a bs file name "bosstest" or a magtape station
named "bosstest". In the latter case, option e6 = +1 is required.
The selection of magtape/bs file is done on basis of "reserve
process". If this succeeds, it must be a peripheral process al-
ready existing (magtape assumed). Otherwise an area process is
created.
2_._2_ _ _ _ _ _ _ _I_n_t_e_r_n_a_l_ _Q_u_e_u_e_s_ _i_n_ _C_e_n_t_r_a_l_ _L_o_g_i_c_ 2.2
C.L. works on 3 queues, used in administration of the coroutines.
The queues are operated like semaphores and so the format is
similar.
CORUNO denotes a coroutine description address.
- A_c_t_i_v_e_ _q_u_e_u_e_. Chains of coroutines ready to activate (internal
name: f4).
f4 -> (-2 : no value of the queue)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0: FIRST CORUNO IN QUEUE (or = 0)
_+_2_:_ _L_A_S_T_ _C_O_R_U_N_O_ _I_N_ _Q_U_E_U_E_ _(_o_r_ _=_ _0_)_ _ _
\f
- A_n_s_w_e_r_ _q_u_e_u_e_. Chain of coroutines waiting for an answer to a
message (internal name: f3).
f3 -> (-2: no value of the queue)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0: FIRST CORUNO IN QUEUE (or = 0)
_+_2_:_ _L_A_S_T_ _C_O_R_U_N_O_ _I_N_ _Q_U_E_U_E_ _(_o_r_ _=_ _0_)_ _ _
- P_a_g_e_r_ _q_u_e_u_e_. Chain of coroutines, whose pages are not in core,
and whose pages must be moved to core in order to
proceed with some operation (internal name: f5).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
f5 -> +0: VALUE
+2: FIRST CORUNO IN QUEUE (or = 0)
_+_4_:_ _L_A_S_T_ _C_O_R_U_N_O_ _I_N_ _Q_U_E_U_E_ _(_o_r_ _=_ _0_)_ _ _
2_._3_ _ _ _ _ _ _ _D_a_t_a_s_t_r_u_c_t_u_r_e_s_ _i_n_ _V_i_r_t_u_a_l_ _C_o_r_e_ 2.3
The datastructures n_o_t_ _r_e_s_i_d_e_n_t_ in BOSS core are placed in p_a_g_e_s_
in the virtual core (drumcore/disccore), and moved to (and maybe
from) the core by the pager coroutine (see chapter 5).
The datastructures placed on pages, are:
- Code pages. Used as page0 in coroutines.
- Variable pages. Used as page1 in coroutines.
- Operations. Chained to a semaphore, or in no chain (if deliver-
ed to a coroutine).
- Job file pages.
- Job description pages.
- Work pages, no general formats.
Pages are created by the initialization code in each module file
(coroutine file), when activated by the loader.
\f
2_._3_._1_ _ _ _ _ _C_o_d_e_ _P_a_g_e_s_ 2.3.1
Code pages contain code.
F_o_r_m_a_t_ _o_f_ _a_ _c_o_d_e_ _p_a_g_e_ (values are set at EXIT to coroutine):
ABS. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
PAGE0 -> +0: ABS. PAGE0 ADDR. (=ITSELF)
ADDR +2: ABS. PAGE1 ADDR. (VARIABLES)
(f2.) +4: ABS. PAGE2 ADDR. (USED BY C.L.)
+6: ABS. PAGE3 ADDR
+8: ABS. PAGE4 ADDR
+10: CODEPAGE IDENT (hw)
+11: REL. RETURN at exit from CL (hw)
i.e.: rel.addr of the instruction
to which C.L. jumped at exit.
_ _ _ _ _ _ _ _ _ _ _ _ _ _(_t_h_e_ _r_e_s_t_ _c_o_n_t_a_i_n_s_ _c_o_d_e_)_ _ _ _ _ _ _
Before exit to a coroutine, C.L. assigns all the fields mention-
ed, except CODEPAGE IDENT.
All code pages are created as "real" pages. Except for the pager,
which is resident in core. But the head of the pager code has the
same format.
2_._3_._2_ _ _ _ _ _V_a_r_i_a_b_l_e_ _P_a_g_e_s_ 2.3.2
Contain variables, mostly dedicated to a specific coroutine. Used
as page1.
There exist no conventions about format. Note that C.L. procedure
w1-call stores virtual return address on page1:
P_a_g_e_1_:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0 Virtual page0 addr
+2 Relative return in page0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
2_._3_._3_ _ _ _ _ _O_p_e_r_a_t_i_o_n_s_ 2.3.3
Common conventions for format:
+0 _c_h_a_i_n_ _(_i_f_ _c_h_a_i_n_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+2 "Free"-mark/banker op.code HW defines use and
+3 _O_p_._k_i_n_d_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _H_W_ _ _ _ contents of operation
+4 _A_n_s_w_e_r_ _S_e_m_a_f_o_r_ _a_d_d_r_ _(_a_b_s_)_ _(_i_f_ _s_e_nding coroutine expects an
answer)
(defined by 2nd word)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
In an operation, C.L. only uses 1st word, and only when the oper-
ation is chained to a semaphore. The chain is a virtual address
of the next in chain.
Note that the length of the operation is not part of the data-
structure. It is defined at creation and not signalled later on.
E_x_a_m_p_l_e_s_ _o_f_ _s_e_m_a_f_o_r_ _s_t_a_t_e_s_:
- Semaphore with value 3 and chain (operations queued):
SEM.DESCR. (VIRTUAL) CORE:
_ _ _ _ _ _ _
+0 3 _ _ _ _ _ _ _ _ _ _ _
+2 FIRST CHAIN
+4 _ _L_A_S_T_ _ _
_1_s_t_ _O_P_E_R_ _ _
_ _ _ _ _ _ _ _ _ _ _
CHAIN
_2_n_d_ _O_P_E_R_ _ _
_ _ _ _ _ _ _ _ _ _ _
CHAIN=0
_L_A_S_T_ _O_P_E_R_ _
\f
- Semaphore with value 3 and n_o_ chain:
SEM.DESCR:
_ _ _ _ _ _ _ _ _
3
0
_ _ _ _0_ _ _ _ _
- Semaphore with value 0:
SEM.DESCR:
_ _ _ _ _ _ _ _ _
0
0
_ _ _ _0_ _ _ _ _
- Semaphore with value -2 (2 coroutines chained):
SEM.DESCR: CORUT.DESCR:
_ _ _ _ _ _ _ _ _
-2 _ _ _ _ _ _ _ _ _ _ _
FIRST CHAIN
_L_A_S_T_ _ _ _ _ 1st CORUT.
_I_N_ _C_H_A_I_N_ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _
CHAIN=0
LAST CORUT.
_I_N_ _C_H_A_I_N_ _ _ _
2_._3_._4_ _ _ _ _ _J_o_b_ _F_i_l_e_ _P_a_g_e_s_ 2.3.4
This page is not a C.L. datastructure. It is created and used in
the module term1.
One page for each commandio coroutine.
\f
F_ Layout of JOB FILE PAGE:
\f
F_ Layout of JOB FILE PAGE (continued):
\f
F_ Layout of JOB FILE PAGE (continued):
\f
F_ 2_._3_._5_ _ _ _ _ _J_o_b_ _D_e_s_c_r_i_p_t_i_o_n_ _P_a_g_e_s_ 2.3.5
This page is not a C.L. datastructure. It is described in a sep-
arate module text, and used in the modules: job, jobstart and
procs.
It is created (as a page) in the module JOBSTART
One page for each pseudo-job.
\f
F_ Layout of JOB DESCRIPTION PAGE:
\f
F_ Layout of JOB DESCRIPTION PAGE (continued):
\f
F_ Layout of JOB DESCRIPTION PAGE (continued):
\f
F_ Layout of JOB DESCRIPTION PAGE (continued):
\f
F_ Layout of JOB DESCRIPTION PAGE (continued):
\f
F_ 2_._4_ _ _ _ _ _ _ _T_i_m_e_ _R_e_p_r_e_s_e_n_t_a_t_i_o_n_s_ 2.4
Time representations are always based on the monitor clock in ad-
dress 110 (and 108).
It is loaded like this: dl W1 110
The registers now will contain:
_ _ _ _ _W_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _W_1_ _ _ _ _ _ _ _
24 bits 24 bits
48 bits real time clock
in units of 0.1 msec.
T_i_m_e_ _i_n_ _t_e_s_t_o_u_t_p_u_t_ _h_e_a_d_e_r_
Algorithm in pseudo-algol
second header-word: = time:=
((montime - bossstarttime) extract 29) //100;
After subtract of boss start time:
_ _ _ _ _W_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _W_1_ _ _ _ _ _ _ _
19 bits 5 bits
not used
29 bits, used
time is in units of 0.01 sec.
Max. value is 5368709, stored in 24 bits.
U_n_i_t_s_ _o_f_ _0_._8_1_9_2_ _s_e_c_o_n_d_s_
Algorithm in pseudo-algol:
time:= (montime shift (-13)) extract 24;
_ _ _ _ _W_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _W_1_ _ _ _ _ _ _ _ _ _ _
11 bits 13 bits 11 bits 13 bits
24 bits, used
1 shift 13 = 8192.
time unit is: 8192 x 0.0001 = 0.8192 sec.
\f
S_h_o_r_t_c_l_o_c_k_ _i_n_ _c_a_t_a_l_o_g_ _e_n_t_r_y_
Algorithm in pseudo-algol:
time: = (montime shift(-19)) extract 24;
_ _ _ _ _ _ _ _W_0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _W_1_ _ _ _ _ _ _ _ _ _ _
5 bits 19 bits 5 bits 19 bits
24 bits, used
1 shift 19 = 524288.
time unit is: 524288 x 0.0001 = 52.4288 sec.
\f
F_ 3_._ _ _ _ _ _ _ _ _C_E_N_T_R_A_L_ _L_O_G_I_C_ _P_R_O_C_E_D_U_R_E_S_ 3.
The functions of C.L. procedures are described below. The return
from the C.L. procedure to the coroutine is in most cases done as
an "exit to coroutine". Thereby it is checked that all pages
stated in the page list of the coroutine description are present
in core (page core). So, before call, the coroutine may change
its page list, and in the same call get some other pages (note
that this is not working in procedures marked with no delay).
At "exit to coroutine", C.L. promises that all pages, mentioned
in the coroutine description, are in core. And on page0 itself,
the corresponding abs. addresses of the pages is placed (see sub-
section 2.3.1).
Note that if an operation is delivered as page2, this may be a
page (comming from virtual core), but it could also point to e.g.
sender table (if it signals that a message has arrived).
\f
F_ 3_._1_ _ _ _ _ _ _ _S_u_r_v_e_y_ _o_f_ _C_e_n_t_r_a_l_ _L_o_g_i_c_ _P_r_o_c_e_d_u_r_e_s_ 3.1
\f
F_ 3_._2_ _ _ _ _ _ _ _P_r_o_c_e_d_u_r_e_ _D_e_s_c_r_i_p_t_i_o_n_s_ 3.2
3_._2_._1_ _ _ _ _ _O_p_e_n_ 3.2.1
Release a semaphore w_i_t_h_o_u_t_ chain (operation):
sem:= sem+1;
if sem <= 0 then activate another coroutine,
waiting for the semaphore.
(it is chained to active queue).
Returns immediately (no delay).
3_._2_._2_ _ _ _ _ _O_p_e_n_ _C_h_a_i_n_e_d_ 3.2.2
Releases a semaphore with a chained queue of operations, i.e. the
operation pointed out is turned over to (chained to) the sema-
phore, whose value is now increased by one.
The operation is chained as the last of the operations queued at
the semaphore.
The operation must be in core (pointed out by an abs addr), and
must be part of a virtual page.
In the operation itself,
- first word (addr+0) is used by C.L. for chain. (Virtual addr of
next in chain)
- fourth hw (addr+3) should be <> 0 (as 0 means a message).
Calling coroutine may be delayed. At least the chain from a pre-
ceding operation in the queue must be altered, and this requires
the corresponding page in core.
F_u_n_c_t_i_o_n_:
The semaphore address is temporarily saved in the chain of the
operation. The address of the operation is transformed from abso-
lute to virtual, a writing bit is added and this virtual address\f
is saved in the state of the coroutine. Page2 of the coroutine is
set to the last operation (or coroutine) chained to the sema-
phore.
Now the pages are checked and afterwards the page pointed to by
the state, the operation, is checked. If any coroutine is waiting
for the semaphore (value < 0) the first coroutine is taken out of
the chain, the operation is inserted as page2 of this coroutine
description and this coroutine is put in the active queue. The
semaphore value is incremented by one and the state and page2 of
the delivery coroutine are cleared.
If no coroutine is waiting it is checked that no other coroutine
has succeeded in sending an operation to the same semaphore dur-
ing a paging, if any, ordered by check pages. In this case the
last-pointer of the semaphore differs from page2 of the corou-
tine, the page2 is set to the new last-pointer and the algorithm
is repeated from the point of page-checking.
If no other coroutine has interfered, then the operation is in-
serted into the chain of the semaphore, the value of which is in-
creased by one and the state of the coroutine is cleared.
3_._2_._3_ _ _ _ _ _L_o_c_k_,_ _L_o_c_k_c_h_a_i_n_e_d_ 3.2.3
These procedures are identical, as the same entry in C.L. is used
for both.
P_u_r_p_o_s_e_:
- lock: wait for a semaphore w_i_t_h_o_u_t_ chain (operation):
sem: = sem -1;
if sem < 0 then wait for activation
- lock chained: wait for an operation chained to the semaphore:
sem: = sem -1;
if sem < 0 then wait for activation
else deliver first operation on semaphore.
\f
D_e_s_c_r_i_p_t_i_o_n_:
if sem <= 0 then wait for activation
else (sem is >= 1)
sem:= sem -1;
if any operations are chained to the semaphore
then deliver first operation in queue;
(even in this case the calling coroutine maybe delayed).
Note that the type of the semaphore is determined by the open
operations performed on the semaphore:
- open makes the semaphore unchained (simple)
- open chained makes the semaphore chained.
In an operation delivered,
- first word (addr+0) contains the new semaphore value.
- second word (addr+2) contains by convention
free, op.kind
op.kind = 0 if the operation signals a message arrived.
F_u_n_c_t_i_o_n_:
If the semaphore is not available (value <= 0) the state of the
coroutine is cleared, the semaphore value is decreased and the
coroutine is put into the semaphore chain.
If the semaphore is available (value >= 1) then the first oper-
ation of the semaphore chain (empty if not chained) is placed as
page2 of the coroutine and the semaphore address as state.
Then the pages are checked and after this possibly time consuming
operation the semaphore is checked again; if it is not available
any longer or if the first operation in the chain now differs
from the one which was found before the pages were checked, then
some other coroutine has locked the semaphore and snatched away
the operation during the paging which must have taken place and
the algorithm is repeated from the beginning.
\f
When the pages are ok and no other coroutine has interfered, the
semaphore value is decreased and the operation is taken out of
the semaphore chain (only if chained).
3_._2_._4_ _ _ _ _ _G_e_t_ _P_a_g_e_s_ 3.2.4
The pages (page0-page4) described in coroutine description (co-
routine table), are moved to core (if not already present), i.e.:
check that all the pages of the coroutine are in core. The corou-
tine continues when this is the case.
3_._2_._5_ _ _ _ _ _P_a_g_e_ _J_u_m_p_ 3.2.5
The calling coroutine wants to jump to another code page (page0),
as indicated in W2-W3.
Note that no return address in the old code page is saved.
The page0 addr is renewed, and the coroutine continues when its
pages are ready (in core).
3_._2_._6_ _ _ _ _ _W_1_-_C_a_l_l_ (or just Call) 3.2.6
The calling coroutine wants to jump to another code page (page0),
as indicated in W2-W3.
The return address (in W1) is stored in the first two words of
(current) page1, thus:
page 1 addr+0: virt (current) page0
page 1 addr+2: rel return in page0 (W1 - abs addr of page0)
Now page0 addr is renewed, and the coroutine continues when its
pages are ready.
\f
3_._2_._7_ _ _ _ _ _W_0_-_C_a_l_l_ 3.2.7
The calling coroutine wants to jump to another code page (page0),
as indicated in W2-W3.
The return address (in W1) is stored in the abs address pointed
out by W0:
addr(W0) -2: virt (current) page0
addr(W0) +0: rel return in page0 (W1 - abs addr of page0)
Now page0 addr is renewed, and the coroutine continues when its
pages are ready.
3_._2_._8_ _ _ _ _ _W_a_i_t_ _A_n_s_w_e_r_ 3.2.8
The coroutine asks to wait until answer arrives to a message al-
ready sent by the coroutine in the message buffer pointed out by
W2 (MESSBUF).
Note that the message sent m_u_s_t_ _n_o_t_ - if it is an I/O message -
point out a data buffer in some of the pages (virtual core).
If I/O, the data buffer must be in permanent core.
Used by transmit.
The coroutine is queued to wait for the answer.
3_._2_._9_ _ _ _ _ _S_e_n_d_ _a_n_d_ _W_a_i_t_ 3.2.9
The coroutine wants to send a message and wait for the answer.
The message to send is in addr (W1).
- if the message is an I/O mess, it m_u_s_t_ _n_o_t_ point out a data
buffer in some of the pages (virtual core).
- If I/O, the data buffer must be in permanent core.
- page2:= 0; \f
- send message;
- the coroutine is queued to wait for the answer;
3_._2_._1_0_ _ _ _ _S_e_n_d_ _a_n_d_ _W_a_i_t_ _F_a_s_t_,_ _S_e_n_d_ _a_n_d_ _W_a_i_t_ _S_l_o_w_ 3.2.10
The coroutine wants to send a message and wait for the answer.
Data are on a virtual page.
The message to send is in addr (W1).
- The message will normally be an I/O mess, and it contains abs.
addresses pointing out a data buffer in some of the pages
(virtual core).
- The page in question must be in core at call time, and now this
page is marked (must stay in core until answer arrives).
- page2:= virtual addr of page containing data buffer.
- send message;
- the coroutine is queued to wait for the answer;
F_u_n_c_t_i_o_n_:
The procedures are used in connection with input/output to or
from a virtual buffer. The corresponding bufferbit is set in the
core table entry for the buffer, otherwise it works as send and
wait (note input/output to or from a core store buffer is accom-
plished by means of the normal send and wait). The difference be-
tween fast and slow is solely reflected in the order in which the
pager selects its victims (i.e. core places to be cancelled).
3_._2_._1_1_ _ _ _ _S_t_o_p_ _a_n_d_ _W_a_i_t_ 3.2.11
The coroutine wants to perform stop process (a job process).
- page2:= 0
- stop process (monitor 60)
- the coroutine is queued to wait for the answer.
\f
3_._2_._1_2_ _ _ _ _C_l_e_a_r_ _C_o_r_e_ 3.2.12
The purpose is to reserve a part of core store before swop-in of
a job process.
Works as get pages but the coroutine has in advance replaced its
page4-addr in coroutine description, thus:
page4: +0: - first segm place (hw)
+1: + top segm place (hw)
Used by banker.
The pager is activated (put in active queue).
The calling coroutine is put in the pager queue, and the pager
will clear the pages occupying the core places pointed out.
3_._2_._1_3_ _ _ _ _P_r_e_p_a_r_e_ _A_c_c_e_s_s_ 3.2.13
The calling coroutine wants to access (read) a bs file. W0, W1
contains the "lookup-base" from where to find the file and create
area process. Calling coroutine is not delayed.
2 return jumps exist:
1) return to W3 (from call):
No entry visible, the registers are:
W0:= result of create area process
W1, W2:= undefined
W3:= page1 addr
page2:= unchanged.
In name area (addr(W2)), result of create area process is
stored instead of name table address.
2) return to W3+2:
Entry found, area process created.
Registers set as described in the survey.
In name area (addr(W2)), name table address is set (in
addr(W2)+8). \f
The catalog base (of BOSS) is set to the base of the area
process.
Access count is increased by 1 (in access table).
(if new value is < 0, bossfault 2 occurs).
3_._2_._1_4_ _ _ _ _T_e_r_m_i_n_a_t_e_ _A_c_c_e_s_s_ 3.2.14
The calling coroutine wants to terminate (a previously prepared)
access to a bs file.
Access count is decreased by 1 (in access table).
(if new value is < 0, bossfault 2 occurs).
The catalog base (of BOSS) is set to the base of the area pro-
cess.
If the (new) access count = 0, remove process is called.
The coroutine is not delayed.
3_._2_._1_5_ _ _ _ _P_r_i_v_-_O_u_t_ 3.2.15
Private testoutput from the coroutine.
The C.L. procedure coruno output is called.
The coroutine is not delayed.
The testoutput record has the format:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0 length<6+kind length: length of tail in hw.
+2 time (max 502 hw)
+4 _c_o_r_o_u_t_i_n_e_ _i_d_e_n_t_ _
+6 tail: 'length' hw,
copied from addr(W1) and on.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
3_._2_._1_6_ _ _ _ _J_D_-_1_ 3.2.16
The coroutine wants testoutput of registers.
\f
The coroutine executes the (illegal) instruction jd -1, which
provokes a 'break0'.
The interrupt routine checks, that this was the case, generates
at testoutput record containing registers and instruction count-
er, and continues with re-established registers in the instruc-
tion following the jd-1.
The coroutine is not delayed.
3_._2_._1_7_ _ _ _ _J_D_-_X_X_X_ 3.2.17
The coroutine wants to generate private testoutput (as PRIV-OUT).
This facility is just a simpler way of implementing it.
The registers (W0, W1) are assigned in advance, with W0 = tail
length, W1 = first (tail). XXX must be an integer, 201 <= XXX <=
263. Testoutput kind will be XXX-200.
The coroutine executes the (illegal) instruction jd-XXX, which
provokes a 'break0'.
The interrupt routine checks that this was the case, sets W0 =
length < 6 + kind, W1 = first (tail), calls C.L. procedure coruno
output and continues with re-established registers in the in-
struction following the jd-200.
The coroutine is not delayed.
\f
F_ 4_._ _ _ _ _ _ _ _ _L_O_A_D_E_R_ 4.
The loader in BOSS is a 2-pass loader/linker.
All the module files are loaded twice and executed. This execu-
tion is the initialization of the module, and it transforms the
module into one or several code pages, variable pages, creates
coroutines, semaphores, operations etc.
Information used in several modules is passed from module to mod-
ule via the external table. It contains abs addresses (e.g. of
C.L. procedures) virtual addresses etc. All values are initially
zero and only a few are defined before first loader pass.
The majority of the externals are defined by the modules. They
are in turn used by other modules that may have been loaded al-
ready. This is the basis reason for the 2 passes.
\f
4_._1_ _ _ _ _ _ _ _C_o_r_e_ _L_a_y_o_u_t_s_ 4.1
The figure shows the core utilization during the two loader
passes and during run.
p_a_s_s_1_: p_a_s_s_2_: r_u_n_:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
central logic B central logic central logic
pager O pager pager
init S init
external table external table for jobs
drumcoretable drumcoretable and pages
diskcoretable diskcoretable (see pager)
move virt buf move virt buf
module module
coretable coretable
segmenttable segmenttable
semaphoretable semaphoretable semaphortable
terminal buffers terminal buffers terminal buffers
sender table sender table sender table
coroutine table coroutine table coroutine table
file access table file access table file access table
run test buf run test buf run test buf
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
4_._2_ _ _ _ _ _ _ _I_n_i_t_ _a_n_d_ _L_o_a_d_,_ _S_t_e_p_ _b_y_ _S_t_e_p_ 4.2
The following description covers all the initialization performed
in the module bos, including the two loader passes.
step 1. If FP is present in the BOSS core, all the code is
moved, so the FP code is overwritten. \f
step 2. Already existing internal processes with BOSS as parent
are left unchanged i.e. the last address of BOSS core is
set below the smallest of these core processes.
step 3. Allocate run test buffer(s).
step 4. Get name of main console.
step 5. Remove all area processes.
step 6. Connect testoutput medium: bosstest (bs file or
magtape).
step 7. Zero-fill all BOSS core after the bos module.
step 8. Overwrite bosstest to zero-fill all segments (if bs
file).
step 9. Allocate core used during loader:
- external table
- drumcore table
- disccore table
- buffer for move to virtual.
step 10. Allocate (some of) common resident tables:
- file access table
- coroutine table
- sender table
- terminal buffers
- top of semaphoretable.
step 11. Assign externals (external 13, 14, 24 dummy)
step 12. First testoutput: - installation name record
- bos load record.
step 13. "Next pass": Assign externals (to initial values)
18 = post record of coroutine table
19 = post record of semaphor table
20 = post record of sender table.
step 14. Load 9 module files, one by one:
step 14.1 load next module file
step 14.2 testoutput of load record
step 14.3 link the module (see subsection 4.3.1)
step 14.4 Jump to initialization code of module file
(loader procedures called from module: see
section 4.3). \f
step 15. Assign externals, that will be active in pass2:
13 = move to virtual
14 = simulate lock
24 = put in active queue.
step 16. Adjust all virtual disc addresses in external table (all
externals < 0),
and virtual addresses in coroutine table.
step 17. Allocate and initialize - segment table
- core table.
step 18. Create and overwrite drumcore and disccore.
step 19. Proceed with pass2: Step 13 and 14.
step 20. Output external table to testoutput.
step 21. In file access table, access count is set = 1 for the
files: - bosstest
- drumcore
- disccore
- usercat
- catalog.
step 22. If BOSS is started in monitor mode and monitor mode is
not wanted (option e16) and the machine is RC4000 (op-
tion e80) then the protection key is changed.
step 23. On RC8000: Ensure, that BOSS has only write access to
its own core (mode0 removed).
step 24. Jump to C.L. entry, where first coroutine in active
queue is activated.
4_._3_ _ _ _ _ _ _ _L_o_a_d_e_r_ _P_r_o_c_e_d_u_r_e_s_ 4.3
The initialization code in a module calls some procedures to
handle the common datastructures.
4_._3_._1_ _ _ _ _ _A_l_g_o_r_i_t_h_m_ _f_o_r_ _L_i_n_k_i_n_g_ _a_ _M_o_d_u_l_e_ 4.3.1
Before exit to a module file, the link algorithm transfers the
current value of externals to places in the module itself.
\f
The linking is also used for reserving core in semaphore-, corou-
tine- and sendertable.
The module contains a_n_ _e_x_t_e_r_n_a_l_ _l_i_s_t_. This is a list of relative
addresses (REF) meaning:
"in the address relative to this is found an external number".
The list starts in module start +8 (see section 4.4)
MODULE:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0
+2
+4
+6 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+8 first external REF
second external REF external list
_-_ _r_e_l_ _a_d_d_r_._ _t_o_ _c_o_r_o_u_t_i_n_e_ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
external REF external list (cont.)
_0_ _=_ _e_n_d_ _o_f_ _e_x_t_e_r_n_a_l_ _l_i_s_t_ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
A negative value means: continue in rel.addr - ref.
A zero means: end of external list.
Now, the list is scanned, and each positive ref. is interpreted,
thus:
- REF is odd:
In the hw addressed (will always be the right half of a
word), the external number is found. Current value of this
external is inserted in the hw.
\f
_h_w_ _ _ _h_w_ _ _ _ _h_w_ _ _ _ _h_w_ _ _ _ _
if found: _ _ _ _ _ _3_0_5_ _ it becomes _ _ _ _ _e_x_t_(_3_0_5_)_ _
- REF is even, and the word addressed contains the value 10:
Reserve in semaphoretable (usually more than 4095 hws).
In the word preceding the addressed word is found the number
of hws to reserve.
Ext(19) is decreased by number of hws and stored in the word
addressed.
(meaning: first address of just reserved core).
Ext(10) is increased by number of hws.
_ _ _ _ _ _ _ _ _ _
if found: -2 _ _ _ _ _ _ _5_0_ _ , 50 hws are reserved:
+0 _ _ _ _ _ _ _1_0_ _ ext(10): = ext(10) +50;
ext(19): = ext(19) -50;
it becomes: _ _ _ _ _ _ _ _ _
-2 _ _ _ _ _ _ _5_0_ _
+0 _ _ _e_x_t_(_1_9_)_
- REF is even:
In the word addressed, the external number is found. Current
value of this external is inserted in the word.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
if found _ _ _ _ _ _ _3_0_5_ _ it becomes _ _ _e_x_t_(_3_0_5_)_ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
if found _ _ _ _ _ _ _-_1_0_ _ it becomes _ _ _e_x_t_(_-_1_0_)_ _
- Special use of external 18, 19, 20:
The left hw of the word addressed is used as "number of hws to
reserve", and the external (number in right hw) is decreased
before stored in the word addressed. So this value means: first
address of just reserved core.
\f
_ _h_w_ _ _ _h_w_ _ _
if found: _3_0_0_ _ _ _1_8_ _ _ 300 hws are reserved:
ext(18): = ext(18) - 300,
and it becomes:
_ _ _ _ _ _ _ _ _ _ _ _
_ _e_x_t_(_1_8_)_ _ _ _
ext(18) reserves in coroutine table
ext(19) reserves in semaphore table
ext(20) reserves in sender table.
4_._3_._2_ _ _ _ _ _S_e_t_ _E_x_t_e_r_n_a_l_s_ 4.3.2
The abs addr of entry to the procedure is in ext(40).
The procedure is used to assign new values to externals. Called
from the initialization code of the module.
Call: Return:
W0 = irr W0: = unchanged
W1 = irr W1: = unchanged
W2 = irr W2: = unchanged
W3 = -2 + abs.addr. of W3: = undefined
start of list Return jump is made to the
address just after the list.
The list consists of a number of entries. Each entry is 2 words,
the first is the new value, the second is external number. The
last entry must be 0, -1000.
\f
E_x_a_m_p_l_e_ _o_f_ _c_a_l_l_:
external list:
g13., g14., ...
jl. w3 (2) ; set externals:
g13: 40 ; here abs addr of entry is placed.
100 , 304 ; means set ext(304): = 100
e2 , -7 ; means set ext(-7): = option e2
g14: 26<12+19 ; here is placed abs addr of first word of
; the 26 hws which are reserved in the
; semaphore table.
335 ; and then set external will assign this
; value to ext(335)
0 -1000 ; end of set external list
(code) ; set externals returns to this addr.
4_._3_._3_ _ _ _ _ _R_e_s_e_r_v_e_ _V_i_r_t_u_a_l_ 4.3.3
The procedure is used to reserve (find room) in the virtual store
for a number of hws, and returns the virtual address of the first
word reserved.
The abs addr of entry to the procedure is in ext(12).
The reservation must be specified to either drumcore or disccore.
Call: Return:
W0 = drum or disc W0: = unchanged
(W0 extract 1 = 0 means drum)
W1 = length of reservation, in hws W1: = unchanged
W2 = irr. W2: = virtual address
W3 = return addr W3: = undefined.
- Successive calls of reserve virtual with same value of W0 ex-
tract 1 and W1 >= 512, will make reservations on consecutive
segments.
\f
- if W1 >= 512, the reserved room will start at a segment start,
and an unused part, if any, of last segment will n_o_t_ be used in
later reservations.
- if W1 < 512, the procedure will find the smallest suitable
"hole" (if any), left over from previous calls with W1 < 512
4_._3_._4_ _ _ _ _ _M_o_v_e_ _t_o_ _V_i_r_t_u_a_l_ 4.3.4
The procedure is used to move a just initialized page to virtual
core. Note that it is dummy in pass1.
The abs addr of entry to the procedure is in ext(13).
Call: Return:
W0 = first addr to move W0: = unchanged
W1 = length in hws W1: = unchanged
W2 = virtual address to W2: = unchanged
move to
(W2 extract 1 = writing)
W3 = return addr. W3: = unchanged
4_._3_._5_ _ _ _ _ _P_u_t_ _i_n_ _A_c_t_i_v_e_ _Q_u_e_u_e_ 4.3.5
The procedure is used to chain a coroutine to the active queue,
so it will be activated when the load is completed.
The abs addr of entry to the procedure is in ext(24). Note that
the procedure is dummy in pass1.
Call: Return:
W0 = irr. W0: = undefined
W1 = coroutine description addr W1: = unchanged
(in coroutine table)
W2 = irr. W2: = abs addr of active queue.
W3 = return addr. W3: = unchanged
\f
4_._3_._6_ _ _ _ _ _S_i_m_u_l_a_t_e_ _L_o_c_k_ 4.3.6
The procedure is used to chain a coroutine to a semaphore, so it
will be waiting for this semaphore to be opened when the load is
completed.
The abs addr of entry to the procedure is in ext(14). Note that
the procedure is dummy in pass1.
Call: Return:
W0 = irr W0: = undefined
W1 = coroutine descr. addr W1: = unchanged
(in coroutine table)
W2 = semaphore descr. addr W2: = unchanged
(in semaphore table)
W3 = return addr. W3: = undefined.
\f
4_._4_ _ _ _ _ _ _ _F_o_r_m_a_t_ _o_f_ _a_ _M_o_d_u_l_e_ _F_i_l_e_ 4.4
Output from slang compiler must have the following format:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+0 _f_r_o_m_ _s_l_a_n_g_:_ _s_u_m_ _o_f_ _c_h_a_r_s_ _(_S_0_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+2 _f_r_o_m_ _s_l_a_n_g_:_ _d_o_u_b_l_e_ _s_u_m_ _o_f_ _c_h_a_r_s_ _(_S_1_)_ _ _ _ _ _ _ _
+4 _d_a_t_e_ _o_f_ _v_e_r_s_i_o_n_ _(_e_._g_._:_ _8_2_0_2_2_0_)_ _ _ _ _ _ _ _ _ _ _ _ _ _
+6 _i_d_e_n_t_ _o_f_ _v_e_r_s_i_o_n_ _(_e_._g_:_ _7_5_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+8 first external REF External list:
+10 second external REF
(module code)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
(maybe continued
external list)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_l_a_s_t_ _e_x_t_e_r_n_a_l_ _r_e_f_ _ _ _ _ _ _
_0_ _(_e_n_d_ _e_x_t_e_r_n_a_l_ _l_i_s_t_)_ _ _
M_m_m_ ENTRY
-> First instruction of initialization code
P_p_p_ POINT _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
(module code)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
The module files are named:
bos loaded by FP or s. Contains Central Logic,
pager and loader.
bterm2
bterm1
bjobstart
bjob Loaded by the loader,
bmount in the order mentioned.
bread
bprinter
bprocs
bbanker
\f
F_ 5_._ _ _ _ _ _ _ _ _P_A_G_E_R_,_ _V_I_R_T_U_A_L_ _C_O_R_E_ 5.
The virtual core is defined as follows:
M_ first of BOSS core. last of BOSS core.
Central
_p_a_g_e_r_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _T_a_b_l_e_s_ _
First free addr.
_P_A_G_E_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _V_I_R_T_U_A_L_ _C_O_R_E_ _ _ _ _ _ _ _ _
_D_R_U_M_C_O_R_E_ _ _ _ _ _ _ _ _D_I_S_C_C_O_R_E_ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _A_D_D_R_E_S_S_ _S_P_A_C_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
P_
The addressing is based on core addresses. The process descrip-
tion of BOSS gives the addresses for first and last of BOSS core.
The virtual core is addressed as a continuous extension of the
BOSS core.
The address space has the limits:
- first addr = 0 (= register W0).
- last addr = last addr of disccore.
The address space is split into segments, so an address may be
decoded, thus:
_ _ _ _A_D_D_R_E_S_S_ _ _ _ _ _ _ _ _
_ _1_5_ _b_i_t_s_ _ _ _9_ _b_i_t_s_ _
Segm number Relative in segm
(0-32767) (0-511)
5_._1_ _ _ _ _ _ _ _A_ _V_i_r_t_u_a_l_ _A_d_d_r_e_s_s_ 5.1
An address pointing in the virtual core, i.e. a "core" address >
last of BOSS core. But the term may also be used for an address
which may be both in BOSS core and virtual core, e.g. the page
addresses in the coroutine description.
\f
5_._2_ _ _ _ _ _ _ _A_ _P_a_g_e_ 5.2
Initially a page is a number of consecutive hws, residing some-
where in the virtual core and moved to and from page core by the
pager. The hws of a page will always remain together, regardless
of where it is placed in page core.
A page is created during initialization by call of "reserve vir-
tual" (and output to virtual core by "move to virtual").
The length of a page is not maintained after reservation, but is
implicit known to the code.
The page is identified by the virtual address of first word. This
is often stored in an external, to pass the address to other mod-
ules.
In this way is created
- codepages
- variable pages
- some of the internal operations (e.g. convert operations)
- work pages
After the creation of a page, it might be used and addressed
freely.
For example, a variable page is created during initialization.
Somewhere on this page, an operation may be set up. It is signal-
led to a semaphore by the open chained procedure (the abs address
of the operation is set at call, and this is converted to a vir-
tual address by C.L.).
When another coroutine receives this operation, the address is
placed as page2 of the coroutine (so now only the operation is
handled as a page). The receiving coroutine may have no knowledge
or interest in the start address of the original page.
\f
5_._3_ _ _ _ _ _ _ _A_ _S_e_c_t_i_o_n_ 5.3
A section is a number of consecutive segments in virtual core.
Sections are what the pager is actually paging (and sometimes the
term page is also used for a section).
A section contains an integral number of segments in virtual
core. The segments of a section remain consecutive when moved to
page core.
A section contains one or several pages as defined to "reserve
virtual"). A "big" page (size >= 512 hws), will occupy one sec-
tion alone, but otherwise it will probably be placed on a section
together with other "small" pages.
Example:
VIRTUAL CORE
_ _ _ _ _ _s_e_g_m_ _ _ _ _ _ _s_e_g_m_ _ _ _ _ _ _s_e_g_m_ _ _ _ _ _ _s_e_g_m_ _ _ _ _ _ _ _s_e_g_m_ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
big page un- 2 small big page big page
used pages (1 segm) (1 segm)
_ _ _ _s_e_c_t_i_o_n_ _ _ _ _ _ _ _ _ _ _ _ _ _ _s_e_c_t_i_o_n_ _ _ _ _ _s_e_c_t_i_o_n_ _ _ _ _s_e_c_t_i_o_n_ _ _ _
5_._4_ _ _ _ _ _ _ _U_s_e_ _o_f_ _B_O_S_S_ _C_o_r_e_ 5.4
The core store of BOSS is divided into the following parts:
1) A part containing the code for the central logic and the pager
coroutine. This part is of fixed size and resident in core.
2) A part containing buffers, coroutine descriptions, semaphores
and tables of various kinds.
This part is resident in core but the size of it varies with
the installation.
\f
3) A part containing the processes created by BOSS and the cur-
rently and most recently used pages from the virtual core of
BOSS. The size of this part is determined by the size of the
process in which BOSS is operating. The contents of this part
of the core will change dynamically.
This gives the following layout of the core store of BOSS (cf.
section 4.1):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
1) Central Logic
and
Pager Coroutine
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
3) Job Processes
and
Pages from the
_ _ _V_i_r_t_u_a_l_ _S_t_o_r_e_ _ _ _ _ _ _ _ _ _ _
2) Coroutine Descriptions
Semaphores
Buffers
_ _ _T_a_b_l_e_s_ _e_t_c_._ _ _ _ _ _ _ _ _ _ _ _ _
The jobs running under BOSS are divided into two groups: a-jobs
and b-jobs. The jobs may have different size and the core place
is determined by the fact that a-jobs always start at the lower
end and b-jobs always end at the higher end of the exchangeable
part of BOSS (3).
This exchangeable part may at different times have the following
contents:
- no jobs in it
- one a-job only
- one b-job only
- one a-job and one b-job.
In any case the remaining core place will be used for pages from
the virtual core of BOSS.
\f
This leads to four different layouts:
no jobs in core two jobs in core
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
a-job
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
pages _ _ _ _p_a_g_e_s_ _ _ _ _ _ _ _ _ _
b-job
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
one a-job only one b-job only
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
a-job _ _ _ _p_a_g_e_s_ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
pages b-job
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
5_._5_ _ _ _ _ _ _ _W_o_r_k_i_n_g_ _C_y_c_l_e_ _o_f_ _t_h_e_ _P_a_g_e_r_ 5.5
The pager receives operations in the pager queue. An operation to
the pager consists of a coroutine description for a coroutine
which wants to be put in the active queue but needs one or more
pages from the virtual core.
Coroutines are put into the pager queue by the central logic
which checks the presence of all specified pages of a coroutine
each time it requests to operate on them (e.g. before exit to a
coroutine, at lock, lock chained and open chained operations).
The pager builds up a page information list and two chains of
pages, i.e. pages _in _core and pages _not _in _core.
\f
5_._6_ _ _ _ _ _ _ _R_e_l_a_t_i_o_n_s_ _t_o_ _C_o_r_e_ _T_a_b_l_e_ _a_n_d_ _S_e_g_m_e_n_t_ _T_a_b_l_e_ 5.6
The relations can be illustrated by this example:
_B_O_S_S_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _D_R_U_M_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _ _D_I_S_C_ _C_O_R_E_ _ _ _ _ _ _ _
_ _ _P_A_G_E_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _V_I_R_T_U_A_L_ _C_O_R_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _
one
segment
one section in core
(2 segments)
_ _C_O_R_E_ _T_A_B_L_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_E_G_M_E_N_T_ _T_A_B_L_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _
The 2 core table entries describe the section
and hold reference to the segment table (i.e.
where the section came from).
See descriptions of coretable and segment table in subsections
2.1.1 and 2.1.2.
\f
F_ 6_._ _ _ _ _ _ _ _ _T_E_S_T_O_U_T_P_U_T_ _F_O_R_M_A_T_S_ 6.
The following pages give a quick survey of record types, format
and contents.
In most modules, the term "kind" is used for what is called "re-
cord type" here.
m_m_ S_U_R_V_E_Y_ _O_F_ _T_E_S_T_O_U_T_P_U_T_ _R_E_C_O_R_D_ _T_Y_P_E_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
TEST
T_Y_P_E_ _ _ _ _B_I_T_ _ _ _ _S_O_U_R_C_E_:_ _C_O_N_T_E_N_T_S_,_ _D_E_S_C_R_I_P_T_I_O_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
1 SEND 1 CL: MESS, at send and wait etc.
2 LOCK 1 CL: SEM, at lock (simple or chained).
3 OPCH 1 CL: SEM+OP, at open chained.
4 OPEN 1 CL: SEM, at open simple.
5 EXIT 1 CL: PAGE-ADDR+REL.EXIT, at exit to code page.
After: all except open.
6 MESS 1 CL: MESSAGE, after: message ready for coroutine.
7 ANSW 1 CL: ANSWER, after: answer arrived to coroutine.
8 JD-1 2 CL: W0, W1, W2, W3, at jd-1 call.
9 STOP (-) CL: W0-W3, IC, BF etc, at BOSSFAULT + CLOSE.
10 OPER 1 CL: SEM+OP, after: lock chained (just before exit).
11 4 BANKER: PSJOB+FREE RESS, REC1: psjob a+b,
REC2-REC5: free ress.
12 JOBSTART: jobfile page, jobdescr page
PSJOB FINIS: timer values.
13 LOAD (-) START UP: REC1:install.name, REC2: startup params,
REC3-REC20: from loader.
14 EXTN (-) START UP: External table, after second loaderpass.
15 LINE 2 COMMAND/JOBSTART: line, from terminal or jobfile.
16 2 BS ADJUST: BS CLAIMS.
17 JOB TERM/LOGOUT: CAT.ENTRY, when it is removed.
18 MOUNTER: STATION TABLE, at each activation of
mounter.
19 MOUNTER: TAPE TABLE, at each activation of mounter.
20 PREP./TERM. ACCESS: ENTRY, ACCESS COUNT, output at
call.
21 : AREA PROCESS.
22 DUMP CL: CODE DUMP. Primary storage of code leading to
interrupt. At BOSSFAULT+CLOSE.
23 REQU REQ.DISPL: REQUEST OPERATION, output when received.
24 START UP: LOAD RESULT. End of loader, end of fixed
part of testoutput.
25 PSJ1 BANKER: PSJOB descr. part 1.
26 PSJ2 BANKER: PSJOB descr. part 2.
27 PSJ3 BANKER: PSJOB descr. part 3.
28 PSJ4 BANKER: PSJOB descr. part 4.
p_p_\f
m_m_ S_U_R_V_E_Y_ _O_F_ _T_E_S_T_O_U_T_P_U_T_ _R_E_C_O_R_D_ _T_Y_P_E_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
TEST
T_Y_P_E_ _ _ _ _B_I_T_ _ _ _ _S_O_U_R_C_E_:_ _C_O_N_T_E_N_T_S_,_ _D_E_S_C_R_I_P_T_I_O_N_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
29 LOOKUP HOST: call params.
30 LOOKUP HOST: return params.
31 LOOKUP DEVICE, LINK-UP REMOTE: call params.
32 LOOKUP DEVICE, LINK-UP REMOTE: message to host.
33 LOOKUP DEVICE, LINK-UP REMOTE: data to host.
34 ALL HOST PROCEDURES: answer from host.
35 ALL HOST PROCEDURES: data from host.
36 LOOKUP DEVICE, LINK-UP REMOTE: return params.
p_p_\f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_
T_y_p_e_s_:_ _1_-_2_-_3_-_4_-_5_-_6_-_7_-_8_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _9_-_1_0_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _1_1_-_1_2_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _1_3_-_1_4_-_1_5_-_1_6_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _1_7_-_1_8_-_1_9_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _2_0_-_2_1_-_2_2_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _2_3_-_2_4_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _2_5_-_2_6_-_2_7_-_2_8_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _2_9_-_3_0_-_3_1_-_3_2_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _3_3_-_3_4_ \f
F_ F_o_r_m_a_t_ _o_f_ _t_e_s_t_o_u_t_p_u_t_ _r_e_c_o_r_d_s_ _(_c_o_n_t_i_n_u_e_d_)_
T_y_p_e_s_:_ _3_5_-_3_6_ \f
6_._1_ _ _ _ _ _ _ _C_o_d_e_p_a_g_e_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_s_ 6.1
Codepage identification is found in the EXIT-record:
M_ c_e_n_t_r_a_l_
9: pager
t_j_o_b_s_t_a_r_t_
11: codepage 1 (job birth, online convert)
12: codepage 2 (load commands, set claim)
13: codepage 3 (command reading)
14: codepage 4 (create job, request alarm)
15: codepage 5 (load, rb-comm)
t_t_e_r_m_ _1_ t_p_r_i_n_t_e_r_
20: command input 70: paper description
21: commandio bulk file 71: central page
22: command print 72: triangle page
23: snapshot, autoline 73: main loop
t_j_o_b_ t_p_r_o_c_s_
40: psjob I/O 80: account
41: psjob aux 81: bsadjust
42: psjob break 82: init from usercat
43: clean catalog 83: unknown sender
44: psjob finis 84: various procedures for remote
devices
t_m_o_u_n_t_ t_b_a_n_k_e_r_
50: psmount 90: main banker
52: remoter 91: core allocation
54: rewinder 92: resource allocation
56: watchdog
58: comandio, name, label t_t_e_r_m_ _2_
100: kill
t_r_e_a_d_ 101: go, run, job, newjob
60: tape reader 102: rename, clear, scope
61: card reader 103: login, get, save
62: start card 104: transmit
63: pstape 105: display
64: pscard 106: kit changer
65: psload 107: term out
P_ 108: request display
\f
6_._2_ _ _ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_s_ 6.2
The coroutine identification is found in 3rd word in most test-
output records.
i_d_e_n_t_ _ _ _n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _(_i_n_i_t_-_c_o_d_e_ _i_n_ _._._._)_
0 output during start-up (central)
1 timer (banker)
2 banker (banker)
3 unknown sender (procs)
7 watchdog (mount)
8 request display (term2)
9 pager (central)
10 operator display (term2)
20* kit changers (term2)
40* printers (printer)
60* rewinders (mount)
80* remoters (mount)
100* commandios (term1)
(198 downer) (banker)
199 convert (banker)
200 account job (jobstart)
200* psjobs (jobstart)
300* termouts (term2)
400* card readers (reader)
450* readers (reader)
\f
Relation between coroutine numbers of psjobs and commandios:
P_S_J_O_B_S_: C_O_M_M_A_N_D_I_O_S_:
200 account
201
20 psjobs for newjobs etc.
= option 209
i45 210 <- maybe -> 100 main console
211 <- -> 101 9 terminals
= option
219 <- -> 109 i4
MATCH in run/go-jobs i.e.: run
from term-coroutine 108
uses psjob-coroutine 218
\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. OPERATING PROCEDURES ................................... 2
2.1 LOGON ............................................. 2
2.2 IBM Console Commands .............................. 2
2.3 Local Commands .................................... 3
2.3.1 General .................................... 3
2.3.2 Start ...................................... 3
2.3.3 Stop ....................................... 4
2.3.4 Restart .................................... 4
2.3.5 Stat ....................................... 5
2.4 Termination ....................................... 5
2.4.1 LOGOFF ..................................... 5
2.4.2 SIGNOFF .................................... 6
2.5 Local Reading ..................................... 6
2.5.1 General .................................... 6
2.5.2 Reading Punched Cards ...................... 7
2.5.2.1 Selection of Punched Card Input ... 7
2.5.2.2 Messages and Restart Action ....... 7
2.5.3 Reading Paper Tapes ........................ 9
2.5.3.1 Selection of Paper Tape Input ..... 9
2.5.3.2 Messages and Restart Action ....... 9
2.5.4 Reading Diskettes .......................... 10
2.5.4.1 Selection of Diskette Input ....... 10
2.5.4.2 Messages and Restart Action ....... 12
2.5.5 Reading Magnetic Tapes ..................... 14
2.5.5.1 Selection of Magnetic Tape Input .. 14
2.5.5.2 Messages and Restart Action ....... 15
2.5.6 Reading Cassette Tapes ..................... 17
2.5.6.1 Selection of Cassette Tape Input .. 17
2.5.6.2 Messages and Restart Action ....... 19
2.5.7 Other Messages ............................. 20
2.5.8 Stat Command ............................... 21
2.5.9 Stop Command ............................... 22
2.6 Local Printing .................................... 22
2.6.1 General .................................... 22
2.6.2 Messages and Restart Action ................ 22 \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_
2.6.3 Other Messages ............................. 24
2.6.4 Stat Command ............................... 24
2.6.5 Stop Command ............................... 25
2.7 Local Punching .................................... 25
2.7.1 General .................................... 25
2.7.2 Punching on Magnetic Tape .................. 25
2.7.2.1 Messages and Restart Action ....... 26
2.7.2.2 Other Messages .................... 28
2.7.2.3 Stat Command ...................... 28
2.7.2.4 Stop Command ...................... 29
2.7.3 Punching on Diskettes (3740 Format) ........ 29
3. ERROR MESSAGES ......................................... 30
3.1 Error Messages from the CON Module ................ 30
3.2 Error Messages from the SNAP Module ............... 30
A_P_P_E_N_D_I_X_:
A. GENERATION OF THE IBM .................................. 33
\f
1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.
The RC3600 SNA/SDCC TERMINAL is a remote job entry (RJE) terminal
using Synchronous Data Link Control (SDLC) and the multiple logi-
cal unit (MLU) protocol of Systems Network Architecture (SNA).
Following functions are implemented:
1) Input
a) Read card images from different devices (card, magnetic
tape, diskette (3740), paper tape and cassette tape)
b) Recognize operator requests and read from console
c) Compress card images for transmission to central site
d) Recognize control records and switch between alternative
physical devices.
2) Output
a) Identify the physical device required for output
b) Decompress output records, queuing the images for printing,
punching or typing
c) Perform the required output operation
d) Set status flags, indicating error condition on the output
devices
The terminal program can process input and output streams con-
currently, e.g. perform interleaved printing, reading and punch-
ing, depending on the options selected by the installation and
the capabilities of the remote terminal's unit record devices.
Since blocking and character compression are used to minimize
line transmission time, the operating speed of the unit record
devices will depend on the data being transmitted and the number
of concurrent functions being performed.
\f
F_ 2_._ _ _ _ _ _ _ _ _O_P_E_R_A_T_I_N_G_ _P_R_O_C_E_D_U_R_E_S_ 2.
2_._1_ _ _ _ _ _ _ _L_O_G_O_N_ 2.1
When the program has been loaded, the message
RC3600 SNA/SDLC TERMINAL
TYPE LOGON COMMAND
will appear on the console.
Type in your LOGON command and send it by pressing the return
key.
If there is a default LOGON record in the system it is only
necessary to press escape key to send the LOGON record.
When the terminal is ready to send and receive data the text
** COMMUNICATION ESTABLISHED
will appear on the console and the readers, printers and punches
will be started, so the transmission of jobs and receiving of
print and punch can start.
If the LOGON command is wrong, you will get an answer from the
IBM, which says what is not accepted.
Then you can give a DISC command and the message
TYPE LOGON COMMAND
will appear on the console and you can type in the correct LOGON
command.
2_._2_ _ _ _ _ _ _ _I_B_M_ _C_o_n_s_o_l_e_ _C_o_m_m_a_n_d_s_ 2.2
All commands given to CON starting with S or with space will be
sent to IBM as a console command.
\f
2_._3_ _ _ _ _ _ _ _L_o_c_a_l_ _C_o_m_m_a_n_d_s_ 2.3
2_._3_._1_ _ _ _ _ _G_e_n_e_r_a_l_ 2.3.1
All commands given to CON, not included in 2.2 and 2.4 are
treated as local commands.
The local commands are used to operate the data streams.
Commands exist for starting, stopping, restarting after error and
getting statistics about the data streams.
The format for a local command to a data stream is
<command> <data stream name> <parameters>
E_x_a_m_p_l_e_:
START RD1 TAPE FILE=1
2_._3_._2_ _ _ _ _ _S_t_a_r_t_ 2.3.2
The START command starts a data stream after it has been stopped
by the operator.
The START command can have some parameters:
START <data stream name> <parameters>
E_x_a_m_p_l_e_:
START RD1 TAPE FILE=1
(starts reading from magnetic tape file 1).
The parameters for each data stream are described in the section
for each datastream (2.5, 2.6, 2.7).
\f
2_._3_._3_ _ _ _ _ _S_t_o_p_ 2.3.3
The STOP command stops a data stream (normally used after serious
errors only).
The STOP command has no parameters:
STOP <data stream name>
E_x_a_m_p_l_e_:
STOP PR1
(stops printing)
When stopping a stream sending data to IBM, the sending is ter-
minated. This has to be done before the job can be cancelled on
IBM.
When stopping a stream receiving data from IBM, data are lost,
because the whole print/punchout must be received in order not to
hang up IBM. This means before using the STOP command, commands
to IBM, saving the print/punchout must be given.
2_._3_._4_ _ _ _ _ _R_e_s_t_a_r_t_ 2.3.4
The RESTART command is used to restart a data stream after errors
that require operator intervention.
The RESTART command can have some parameters saying what action
to be taken on the error:
RESTART <data stream name> <parameters>
E_x_a_m_p_l_e_:
RESTART RD1 SKIP
(skip the erroneous data and continue reading)
\f
The legal parameters and the action upon them are described in
the section for each data stream (2.5, 2.6, 2.7).
2_._3_._5_ _ _ _ _ _S_t_a_t_ 2.3.5
The STAT command is used to get statistics about the data streams
such as active/not active, number of cards read or number of
lines printed etc.
The STAT command has no parameters.
STAT <data stream name>
E_x_a_m_p_l_e_:
STAT PR1
(displays statistics about printer 1)
The statistics displayed are described in the section for each
data stream (2.5, 2.6, 2.7).
2_._4_ _ _ _ _ _ _ _T_e_r_m_i_n_a_t_i_o_n_ 2.4
2_._4_._1_ _ _ _ _ _L_O_G_O_F_F_ 2.4.1
The LOGOFF command is used to send a LOGOFF to the IBM. It is
sent on all active LU's.
The LOGOFF command has the following parameters:
LOGOFF APPLID(name) TYPE(COND/UNCOND) HOLD(YES/NO)
where name in APPLID is the name of the application id.
The parameter TYPE is used to make a conditional LOGOFF or an
unconditional LOGOFF. A conditional LOGOFF means that jobs are
finished before the session is terminated. An unconditional
LOGOFF will terminate the session without finishing any jobs.
\f
The parameter HOLD is used whether you want to deactivate or not
deactivate the physical unit and the logical units.
HOLD(NO) means that the physical unit and the logical units are
deactivated, HOLD(YES) means that they are still active.
All parameters are optional.
2_._4_._2_ _ _ _ _ _S_I_G_N_O_F_F_ 2.4.2
A SIGNOFF command will send SIGNOFF to the IBM on all active
LU's.
Can only be used when SIGNOFF is defined in the IBM.
2_._5_ _ _ _ _ _ _ _L_o_c_a_l_ _R_e_a_d_i_n_g_ 2.5
2_._5_._1_ _ _ _ _ _G_e_n_e_r_a_l_ 2.5.1
Local reading is performed by the reader stream: RD1, which is
able to read punched cards, paper tapes, diskettes, magnetic
tapes and cassette tapes. RD1 is automatically started after
signon. RD1 is default reading from card reader. Selection of
other devices is done by either controlcards or local commands.
After having read from another device RD1 automatically switches
back to card reader. A controlcard starts with /* in the first
column on the card.
A job is terminated when the controlcard
1 5
/* END OF FILE
is read or the local command
STOP RD1
is given.
\f
In case of errors etc. the job must be terminated before it can
be cancelled on IBM.
2_._5_._2_ _ _ _ _ _R_e_a_d_i_n_g_ _P_u_n_c_h_e_d_ _C_a_r_d_s_ 2.5.2
Punched cards are 80 columns cards in EBCDIC code.
2_._5_._2_._1_ _ _ _S_e_l_e_c_t_i_o_n_ _o_f_ _P_u_n_c_h_e_d_ _C_a_r_d_ _I_n_p_u_t_ 2.5.2.1
At system upstart punched cards are automatically started as
input.
After end of file or end medium on any other input device, switch
back to punched cards is automatically performed.
After the local command STOP RD1 has been used to stop the
reader stream, it can be started reading punched cards by the
local command
START RD1
2_._5_._2_._2_ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.5.2.2
Following parameters to the local command RESTART RD1 can be
given when reading punched cards:
no parameter
The read operation is repeated, erroneous data are skipped.
ACCEPT
The error is accepted, erroneous data are used.
Note that the RESTART command shall be given only when an error\f
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
All other errors are automatically repeated, thus reading will
continue after the error has been corrected.
The messages are started with:
** RD1
STATUS: CDR
List of messages:
DISCONNECTED power off, disconnected.
NOT READY stacker jam, stacker full, feed
error.
NOT AVAILABLE * illegal, driver reserved by other
process.
BLOCK LENGTH ERROR * card reader transfers more than 80
columns from one card.
DATA LATE * data late (hardware).
PARITY ERROR * a card contains too many holes in
row 1 to 7.
END MEDIUM hopper empty.
DRIVER MISSING the driver is not loaded.
The system is not loaded properly.
TIMEOUT * timeout (hardware)
Messages marked with * should not appear. Hardware or software
malfunction.
\f
2_._5_._3_ _ _ _ _ _R_e_a_d_i_n_g_ _P_a_p_e_r_ _T_a_p_e_s_ 2.5.3
Paper tapes are 5 or 8 channel paper tapes, all hole combinations
are legal.
2_._5_._3_._1_ _ _ _S_e_l_e_c_t_i_o_n_ _o_f_ _P_a_p_e_r_ _T_a_p_e_ _I_n_p_u_t_ 2.5.3.1
Selection of paper tape input is done by the following control-
card
/* READ PAPER
After the local command STOP RD1 has been used to stop the reader
stream, it can be started reading paper tapes by the local com-
mand
START RD1 PAPER
After a paper tape has been read, switch back to reading punched
cards is automatically performed.
2_._5_._3_._2_ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.5.3.2
Following parameters to the local command RESTART RD1 can be
given when reading paper tapes:
no parameter
The read operation is repeated, erroneous data are skipped.
ACCEPT
The error is accepted, erroneous data are used.
IGNORE
Ignore the device, and continue reading punched cards.
\f
Note that the RESTART command shall be given only when an error
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
All other errors are automatically repeated, thus reading will
continue after the error has been corrected.
The messages are started with:
** RD1
STATUS: PTR
List of messages:
NOT AVAILABLE * illegal, driver reserved by other
process.
END MEDIUM no paper tape was mounted when
selection of paper tape as input
was done. Mount the paper tape.
DRIVER MISSING the driver is not loaded. The
system is not loaded properly.
Messages marked with * should not appear. Hardware or software
malfunction.
2_._5_._4_ _ _ _ _ _R_e_a_d_i_n_g_ _D_i_s_k_e_t_t_e_s_ 2.5.4
Diskettes are single sided, 128 bytes sector length with standard
IBM3740 datasets.
2_._5_._4_._1_ _ _ _S_e_l_e_c_t_i_o_n_ _o_f_ _D_i_s_k_e_t_t_e_ _I_n_p_u_t_ 2.5.4.1
Selection of diskette input is done by the following controlcard
/* READ 3740 <parameters>
\f
After the local command STOP RD1 has been used to stop the
reader stream, it can be started reading diskettes by the local
command.
START RD1 3740 <parameters>
Following parameters exist for diskettes:
M_m_m_ UNIT = device unit number,
<unit number>
P_p_p_ U = default unit 0.
VOLID = <volname> volume label on the diskette. Max.
6 characters. Need not to be spe-
cified. If specified it is checked
that it is the correct diskette
which is mounted.
DSN = <dataset name(s)> dataset name on the diskette. Max.
8 characters. It is possible to
give up to 4 dataset names in a
parenthesis separated by commas.
The datasets will be transmitted in
the sequence given in the parent-
hesis. It is not allowed with
spaces in dataset names or in a
parenthesis. Giving the dataset
name ALL will transmit all datasets
on the diskette until a DDR1 is
met.
E_x_a_m_p_l_e_:
/* READ 3740 DSN=ALL
will read all datasets from diskette unit 0 with no check of
volume label.
/* READ 3740 DSN = (JOB1, JOB2, JOB3, JOB4)
will read the 4 datasets with the names JOB1, JOB2, JOB3 and JOB4
in this sequence from diskette unit 0 with no check of volume
label.
\f
After having read from 1-4 or all datasets from a diskette (de-
pending on the controlcard or START command) the message:
RD1: END OF DISKETTE
will be written on the console. If there is a cardreader in the
system, switch back to reading punched cards is automatically
performed.
2_._5_._4_._2_ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.5.4.2
Following parameters to the local command RESTART RD1 can be
given when reading diskettes:
no parameter
The read operation is repeated. This means trying to read the
same record again.
SKIP
The erroneous record is skipped, reading is continued with next
record.
ACCEPT
The erroneous record is accepted and transmitted, reading is con-
tinued with next record.
IGNORE
Ignore the device, and continue reading punched cards.
NOTE that the RESTART command shall be given only when an error
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
\f
All other errors are automatically repeated, thus reading will
continue after the error has been corrected.
All messages are coming from RD1 via the CON module.
The messages from RD1 except the first are started with
** RD1
STATUS: 3740
or with
** RD1
STATUS: FDO
List of messages
RD1: MOUNT DISKETTE mount the diskette. This message
comes for each controlcard or START
command selecting diskette. Door to
diskette must be opened once for
each controlcard or START command
selecting diskette.
Status from 3740.
FORMAT ERROR the format on the diskette is not
3740 format.
DATASET NOT FOUND dataset with the specified name
does not exist.
ILLEGAL OPERATION * driver reserved by other process.
BLOCK LENGTH ERROR * input buffer less than record.
END OF VOLUME, MOUNT NEXT DISKETTE, ENTER RESTART RD1
end of volume. Dateset continues on
another diskette. Mount next disk-
ette and enter RESTART RD1.
\f
SEQUENCE ERROR occurs if a diskette is a multivol-
ume dataset and is out of sequence.
If it is desired to transfer the
dataset in spite of the sequence
error enter RESTART RD1 ACCEPT,
otherwise mount another diskette
and enter RESTART RD1.
POSITION ERROR it is not possible to read the
diskette.
Status from FDO
DRIVER MISSING The driver is not loaded. The
system is not loaded properly.
NOT AVAILABLE illegal, driver reserved by other
process.
PARITY ERROR The diskette is impossible to read.
POSITION ERROR
TIMEOUT
Messages marked with * should not appear. Hardware or software
malfunction.
2_._5_._5_ _ _ _ _ _R_e_a_d_i_n_g_ _M_a_g_n_e_t_i_c_ _T_a_p_e_s_ 2.5.5
Magnetic tapes are 9 track with maximum block length of 1080
bytes.
2_._5_._5_._1_ _ _ _S_e_l_e_c_t_i_o_n_ _o_f_ _M_a_g_n_e_t_i_c_ _T_a_p_e_ _I_n_p_u_t_ 2.5.5.1
Selection of magnetic tape input is done by the following con-
trolcard
/* READ TAPE <parameters>
\f
After the local command STOP RD1 has been used to stop the reader
stream, it can be started reading magnetic tapes by the local
command
START RD1 TAPE <parameters>
Following parameters exist for magnetic tapes:
M_m_m_ UNIT = device unit number,
<UNIT NUMBER>
P_p_p_ U = default unit 0.
M_m_m_ FILE = file number on the magnetic tape.
<FILE NUMBER(S)>
P_p_p_ F = it is possible to give as many file
numbers as can be on the card in
parenthesis, separated by commas.
The files will be transmitted in
the sequence given in the parent-
hesis.
E_x_a_m_p_l_e_:
/* READ TAPE FILE=2 U=1
will read file number 2 from magnetic tape unit 1.
START RD1 TAPE F=(1,3,9,4,2,7,8)
will read the 7 files in the given sequence from magnetic tape
unit 0.
After having read the specified files from magnetic tape, switch
back to reading punched cards is automatically performed.
2_._5_._5_._2_ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.5.5.2
Following parameters to the local command RESTART RD1 can be
given when reading magnetic tapes:
no parameter
\f
The read operation is repeated. This means trying to read the
same block again.
SKIP
The erroneous block is skipped, reading is continued with next
block.
ACCEPT
The erroneous block is accepted and transmitted, reading is con-
tinued with next block.
IGNORE
Ignore the device, and continue reading punched cards.
Note that the RESTART command shall be given only when an error
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
All other errors are automatically repeated, thus reading will
continue after the error has been corrected.
The messages are started with:
** RD1
STATUS: MT <UNIT NUMBER>
List of messages:
NOT READY the magnetic tape unit is offline.
NOT AVAILABLE * illegal, driver reserved by other
process.
BLOCK LENGTH ERROR the magnetic tape contains blocks
greater than 1080 bytes.
\f
DATA LATE * data late (hardware).
PARITY ERROR a block contains a parity error.
END MEDIUM EOT (end of tape) mark is reached.
POSITION ERROR positioning at non-existing block
(should not appear).
DRIVER MISSING the driver is not loaded. The
system is not loaded properly.
TIMEOUT wrong density, positioning at non-
existing file or timeout (hard-
ware).
Messages marked with * should not appear. Hardware or software
malfunction.
2_._5_._6_ _ _ _ _ _R_e_a_d_i_n_g_ _C_a_s_s_e_t_t_e_ _T_a_p_e_s_ 2.5.6
Cassette tapes are ECMA 34 vers. 1, ECMA 34 vers. 2, or M10. The
2 first types with maximum block length of 256 bytes, M10 with
maximum block length 1024 bytes.
2_._5_._6_._1_ _ _ _S_e_l_e_c_t_i_o_n_ _o_f_ _C_a_s_s_e_t_t_e_ _T_a_p_e_ _I_n_p_u_t_ 2.5.6.1
Selection of cassette tape input is done by the following con-
trolcard:
/* READ CASSETTE <parameters>
After the local command STOP RD1 has been used to stop the reader
stream, it can be started reading cassette tapes by the local
command
START RD1 CASSETTE <parameters>
\f
Following parameters exist for cassette tapes:
M_m_m_ UNIT= device unit number,
<UNIT NUMBER>
P_p_p_ U = default unit Ø.
M_m_m_ FILE= file number on the casette tape. It
<FILE NUMBER(S)>
P_p_p_ F = is possible to give as many file
numbers as can be on the card in
parenthesis separated by commas.
The files will be transmitted in
the sequence given in the parent-
hesis.
FILL=<fillchar> decimal value of fillchar, default
= 64 (EBCDIC SPACES). Records less
than 80 bytes are filled with
characters of this value.
cassette tape format, default = E2
E1 E1 = ECMA 34 VERS.1
M_m_m_ E2 E2 = ECMA 34 VERS.2
FORMAT =
P_p_p_ M10 M10 = M10 CASSETTES
FREE FREE = no check is performed
E_x_a_m_p_l_e_:
START RD1 CASSETTE F=1
will read file 1 from cassette tape unit 0 with format E2, fill-
ing records less than 80 bytes with 64 (EBCDIC SPACE)
/* READ CASSETTE U=1 F=(1,2,3) FORMAT=E1
will read file 1, 2 and 3 from cassette tape unit 1 with format
E1, filling records less than 80 bytes with 64 (EBCDIC SPACE)
/* READ CASSETTE FORMAT=M10 FILL=0 F=1
will read file 1 from cassette tape unit 0 with format M10,
filling records less than 80 bytes with 0 (zero).
\f
After having read the specified files from cassette tape, switch
back to reading punched cards is automatically performed.
2_._5_._6_._2_ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.5.6.2
Following parameters to the local command RESTART RD1 can be
given when reading cassette tapes:
no parameter
The read operation is repeated, this means trying to read the
same block again.
SKIP
The erroneous block is skipped, reading is continued with next
block.
ACCEPT
The erroneous block is accepted and transmitted, reading is con-
tinued with next block.
IGNORE
Ignore the device, and continue reading punched cards.
Note that the RESTART command shall be given only when an error
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
All other errors are automatically repeated, thus reading will
continue after the error has been corrected.
The messages are started with:
** RD1
STATUS: CT <UNIT NUMBER>
\f
List of messages:
NOT READY the cassette tape unit is offline.
NOT AVAILABLE * illegal, driver reserved by other
process.
BLOCK LENGTH ERROR the cassette tape contains blocks
greater than 256 bytes.
DATA LATE * data late (hardware).
PARITY ERROR a block contains a parity error.
END MEDIUM EOT (end of tape) mark is reached.
POSITION ERROR positioning at non-existing block
(should not appear).
DRIVER MISSING the driver is not loaded. The sys-
tem is not loaded properly.
TIMEOUT rewinding or timeout (hardware).
Messages marked with * should not appear. Hardware or software
malfunction.
2_._5_._7_ _ _ _ _ _O_t_h_e_r_ _M_e_s_s_a_g_e_s_ 2.5.7
One more message exists from the reader stream:
** RD1 SYNTAX ERROR IN COMMAND
<erroneous command>
** OPERATOR INTERVENTION REQUIRED
This means that syntax error has been detected in a controlcard
or a START command.
\f
The error can be corrected with the command:
RESTART RD1 <correct command>
or the controlcard can be skipped with the command:
RESTART RD1 IGNORE
E_x_a_m_p_l_e_:
** RD1 SYNTAX ERROR IN COMMAND
CASSETTE FILE = ABC
** OPERATOR INTERVENTION REQUIRED
the file number is illegal, to correct the error:
RESTART RD1 CASETTE FILE = 1
to skip this command and continue reading punched cards:
RESTART RD1 IGNORE
2_._5_._8_ _ _ _ _ _S_t_a_t_ _C_o_m_m_a_n_d_ 2.5.8
When giving the STAT RD1 command one of the following texts will
be displayed:
** RD1 IS STOPPED
the reader stream has been stopped by the local command STOP
RD1.
** RD1
STATUS <device name>
OK
** NUMBER OF RECORDS = nnnnn
the reader stream is active reading from the device given in
devicename, nnnnn = number of punched cards read in this job.
\f
** RD1
STATUS <device name>
<device message>
the reader stream is active reading from the device given in
device name, the device is in state given in device message (see
the paragraph list of messages in the section for each device).
2_._5_._9_ _ _ _ _ _S_t_o_p_ _C_o_m_m_a_n_d_ 2.5.9
When giving the STOP RD1 command the active job (if any) is ter-
minated as if the /* END OF FILE has been read, so the execution
of the job can start in the IBM. If this is not wanted because
the RD1 has been stopped due to an error, remember to cancel the
job with a console command to the IBM.
2_._6_ _ _ _ _ _ _ _L_o_c_a_l_ _P_r_i_n_t_i_n_g_ 2.6
2_._6_._1_ _ _ _ _ _G_e_n_e_r_a_l_ 2.6.1
Local printing is performed by the printer stream: PR1, which is
able to print on line printer. PR1 is automatically started after
signon. After having printed one job the printer stream is auto-
matically started again so it is ready for the next job. After
the local command STOP PR1 has been used to stop the printer
stream, it can be started printing (waiting for next job) by the
local command:
START PR1
2_._6_._2_ _ _ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.6.2
Following parameters to the local command RESTART PR1 can be
given:
no parameter
\f
The write operation is repeated, trying to print the line again,
no data is lost.
ACCEPT
The write operation is not repeated, data (1 line) may be lost
depending on the error.
IGNORE
The whole block received from IBM is ignored, several lines may
be lost.
Note that the RESTART command shall be given only when an error
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
All other errors are automatically repeated, thus printing will
continue after the error has been corrected.
The messages are started with:
** LPT STATUS:
List of messages:
DISCONNECTED power off, disconnected.
NOT READY the printer is offline.
ILLEGAL * illegal, driver reserved by other
process.
PAPER ERROR paper run away, paper torn.
DATA LATE * data late (hardware).
CCW ERROR * illegal carriage control word
(ccw).
\f
END OF PAPER end of paper.
DRIVER MISSING the driver is not loaded. The
system is not loaded properly.
PAPER RUN AWAY timeout, paper run away.
Messages marked with * should not appear. Hardware or software
malfunction.
2_._6_._3_ _ _ _ _ _O_t_h_e_r_ _M_e_s_s_a_g_e_s_ 2.6.3
One other message exists from the printer stream:
** LPT STATUS: DATA LOST
If the printer stream was active when the local command STOP PR1
was given, the active job must be received in order not to hang
up JES2 (see 2.6.5).
2_._6_._4_ _ _ _ _ _S_t_a_t_ _C_o_m_m_a_n_d_ 2.6.4
When giving the STAT PR1 command one of the following texts will
be displayed:
** PR1 IS STOPPED
The printer stream has been stopped by the local command STOP
PR1
** LPT STATUS: NOT ACTIVE
The printer stream is waiting for the next printfile from IBM
** LPT STATUS: OK
** NUMBER OF LINES PRINTED = nnnnn
\f
The printer stream is active printing, nnnnn = number of lines
printed in current printfile.
** LPT STATUS: <device message>
The printer stream is active printing, but the printer is in the
state given in device message (see 2.6.2).
2_._6_._5_ _ _ _ _ _S_t_o_p_ _C_o_m_m_a_n_d_ 2.6.5
When giving the STOP PR1 command the active job (if any) must be
received in order not to hang up JES2, in this case the data are
lost. Therefore before giving the STOP PR1 command, console com-
mands saving the printout should be given to IBM (purge and re-
start printer: SPPR1 and SEPR1).
2_._7_ _ _ _ _ _ _ _L_o_c_a_l_ _P_u_n_c_h_i_n_g_ 2.7
2_._7_._1_ _ _ _ _ _G_e_n_e_r_a_l_ 2.7.1
Local punching is performed by the punch stream: PU1, which is
able to write punchout on either magnetic tape unit 0 or 3740
formatted diskettes. Each block is 80 bytes and contains one
punch record. If a punch record is less than 80 bytes it is fill-
ed with zeroes. PU1 is automatically started after signon.
2_._7_._2_ _ _ _ _ _P_u_n_c_h_i_n_g_ _o_n_ _M_a_g_n_e_t_i_c_ _T_a_p_e_
PU1 is initiated to write in file 1. After having punched one job
the punch stream is automatically started again so it is ready
for the next job (still in file 1, but the tape is rewound and
set offline after each job). After the local command STOP PU1 has
been used to stop the punch stream, it can be started punching
(waiting for next job) by the local command
START PU1 <parameters>
\f
Following parameters exist for PU1
M_m_m_ FILE = file number on magnetic tape in
<file number>
P_p_p_ F = which the punchout should be
written. Default file 1.
E_x_a_m_p_l_e_:
START PU1 FILE=3
will write the next punchout in file 3 on magnetic tape.
2_._7_._2_._1_ _ _ _M_e_s_s_a_g_e_s_ _a_n_d_ _R_e_s_t_a_r_t_ _A_c_t_i_o_n_ 2.7.2.1
Following parameters to the local command RESTART PU1 can be
given:
no parameter
The write operation is repeated, no data are lost.
ACCEPT
The write operation is not repeated, 1 record is lost or is er-
roneous written on the magnetic tape.
IGNORE
The whole block received from IBM is ignored, several records may
be lost.
Note that the RESTART command shall be given only when an error
message is followed by the text:
** OPERATOR INTERVENTION REQUIRED
All other errors are automatically repeated, thus punching will
continue after the error has been corrected.
\f
The messages are started with:
** MT STATUS:
List of messages:
OFFLINE the magnetic tape unit is offline.
WRITE LOCK no write ring is mounted on the
tape.
ILLEGAL * illegal, driver reserved by other
process.
BLOCK LENGTH ERROR * trying to write block greater than
80 bytes (software).
DATA LATE * data late (hardware).
PARITY ERROR writing a block results in perma-
nent parity error.
END OF TAPE EOT (end of tape) mark is reached.
POSITION ERROR positioning at non-existing block
(should not appear).
DRIVER MISSING the driver is not loaded. The sys-
tem is not loaded properly.
TIMEOUT wrong density, positioning at non-
existing file or timeout (hard-
ware).
Messages marked with * should not appear. Hardware or software
malfunction.
\f
2_._7_._2_._2_ _ _ _O_t_h_e_r_ _M_e_s_s_a_g_e_s_ 2.7.2.2
Two other messages exist from the punch stream:
** MT STATUS: DATA LOST
If the punch stream was active when the local command STOP PU1
was given, the active job must be received in order not to hang
up JES2 (see 2.7.2.4).
** PU1 SYNTAX ERROR IN COMMAND
This means that a syntax error has been detected in a START COM-
MAND. The error can be corrected with the commands:
STOP PU1
START PU1 <correct command>
E_x_a_m_p_l_e_:
START PU1 FILE=ABC
** PU1 SYNTAX ERROR IN COMMAND
the file number is illegal, to correct the error:
STOP PU1
START PU1 FILE=2
2_._7_._2_._3_ _ _ _S_t_a_t_ _C_o_m_m_a_n_d_ 2.7.2.3
When giving the STAT PU1 command one of the following texts will
be displayed:
** PU1 IS STOPPED
The punch stream has been stopped by the local command STOP PU1.
** MT STATUS: NOT ACTIVE
The punch stream is waiting for the next punchfile from IBM.
\f
** MT STATUS: OK
** NUMBER OF RECORDS = nnnnn
The punch stream is active punching, nnnnn number of records have
been written to magnetic tape in the current punchfile.
** MT STATUS: <device message>
The punch stream is active punching, but the magnetic tape unit
is in the state given in device message (see 2.7.2.1).
2_._7_._2_._4_ _ _ _S_t_o_p_ _C_o_m_m_a_n_d_ 2.7.2.4
When giving the STOP PU1 command the active job (if any) must be
received in order not to hang up JES2, in this case the data are
lost. Therefore before giving the STOP PU1 command, console com-
mands saving the punchout should be given to IBM (purge and re-
start punch: SPPU1 and SEPU1).
2_._7_._3_ _ _ _ _ _P_u_n_c_h_i_n_g_ _o_n_ _D_i_s_k_e_t_t_e_s_ _(_3_7_4_0_ _F_o_r_m_a_t_)_ 2.7.3
Will appear later.
\f
F_ 3_._ _ _ _ _ _ _ _ _E_R_R_O_R_ _M_E_S_S_A_G_E_S_ 3.
3_._1_ _ _ _ _ _ _ _E_r_r_o_r_ _M_e_s_s_a_g_e_s_ _f_r_o_m_ _t_h_e_ _C_O_N_ _M_o_d_u_l_e_ 3.1
** INVALID COMMAND
An invalid command has been given. The command is skipped.
** NOT ALLOWED
A command that is not allowed at this moment has been given.
It could be starting an already started data stream or stop-
ping an already stopped data stream. The command is skipped.
** WAIT
A command has been given to a data stream that is not able to
handle the command right now. The command is skipped.
3_._2_ _ _ _ _ _ _ _E_r_r_o_r_ _M_e_s_s_a_g_e_s_ _f_r_o_m_ _t_h_e_ _S_N_A_P_ _M_o_d_u_l_e_ 3.2
A message will come from the SNAP module when the SNAP module re-
ceives a status message from the SDLC driver, when the SNAP mod-
ule receives a negative response from the IBM or when the SNAP
module will give an error message. The last message should not
appear.
The status messages from the SDLC driver has the following for-
mat:
> SNAP
SDLC I: 8'xxxxxx
or
> SNAP
SDLC 0: 8'xxxxxx
where the first message is from input messages and the other is
from output messages. xxxxxx is the status word.
\f
Following status bits may appear:
1B0: The channel is logical disconnected.
1B0 + 1B9: An SNRM frame (Set Normal Response Mode) is received
from the IBM while the channel was connected.
1B0 + 1B11: A DISC or DM frame has been received.
1B0 + 1B12: An FRMR has been transmitted.
When the SNAP module receives a negative response from the IBM
the following message will be displayed on the console:
> SNAP
NEG. RESP. REC. ERRORCODE X'nnnnnnnn
where nnnnnnnn is the sense code received in the negative re-
sponse.
The last error message should not appear under normal conditions.
The format is:
> SNAP
ERROR: nn
where nn is a number.
L_i_s_t_ _o_f_ _e_r_r_o_r_ _n_u_m_b_e_r_s_
01 A negative response is transmitted to the IBM.
02 An SCB indicating compaction is received.
03 Internal error message. Contact RC.
04 Internal error message. Contact RC.
05 Wrong sequence number in data from IBM.
06 Internal error message. Contact RC.
07 A Set Virtual Format is received.
08 A Set Line Density is received.
09 An ACTLU with an LU number greater than the number of LU's
generated in the terminal is received.
10 A Crypto Verification is received.
11 An illegal Session Control Command is received.
\f
F_
\f
F_ A_._ _ _ _ _ _ _ _ _G_E_N_E_R_A_T_I_O_N_ _O_F_ _T_H_E_ _I_B_M_ A.
The RC3650 SNA/SDLC Terminal is generated to a certain number of
Logical Units (LU's). The IBM must be generated with the same
number of active LU's. It is not possible to activate further
LU's without making a new generation of the RC3600 software.
The number of readers, printers or punches generated at the IBM
must not exceed the number generated in the RC3600 SNA/SDLC Ter-
minal.
Following parameters must be generated in JES2:
RMTnnn BUFSIZE = 256, COMP, CONSOLE, NOCMPCT, DISCINTV = 0,
SETUPMSG, SETUPINF, WAITTIME = 1
Rnnn.PRm OPERATOR, CCTL, NOCMPCT, COMP, COMPACT = 0,
NOFCBLOAD, LRECL = yyy, PRWIDTH = yyy, SELECT =
PRINTn
(yyy in LRECL and PRWIDTH maximum 132)
Rnnn.PUn OPERATOR, CCTL, NOCMPCT, COMP, COMPACT = 0, LRECL =
zzz, SELECT = PUNCHn
(zzz in LRECL maximum 80)
\f
F_
\f
SW1720
PASCAL/MT+ *
til RC700
. OVERMÆNGDE AF ISO STANDARD PASCAL
. DIREKTE OVERSÆTTELSE TIL EFFEKTIV MASKINKODE
. EN RÆKKE HJÆLPEPROGRAMMER INKLUDERET
. SEGMENTERING OG SAMMENKÆDNING AF PROGRAMMER
. BÅDE HØJNIVEAU OG BASAL I/O-BEHANDLING DIREKTE FRA PASCAL
. RUTINER TIL MANIPULATION AF DATA
. KØRER UNDER OPERATIVSYSTEMET CP/M*
GENERELT
Pascal/MT+ programmelpakken består af en integreret serie af pro-
grammer, der muliggør udvikling af kvalitetsprogrammel i Pascal
på RC700 mikrodatamaten. Programmellet kører under CP/M og pro-
grammer skrevet i Pascal/MT+ åbner mulighed for et bredere sigte
mod andre CP/M-baserede systemer, både 8-bit og 16-bit.
Pascal/MT+ er et yderst velstruktureret sprog med avancerede
muligheder inden for fejlretning; det er designet til fuldt ud at
* Varemærker fra Digital Research. \f
udnytte modulær kompilation bl.a. med henblik på reducering af
oversætterressourcer under programudvikling.
Foruden at implementere alle faciliteter i henhold til ISO Stan-
dard Nr. 7185, byder Pascal/MT+ på mange yderligere faciliteter.
Udvidelserne inkluderer for eksempel dynamiske strenge og en ræk-
ke nyttige, indbyggede funktioner og procedurer.
Ved udvikling af store programmelsystemer kan segmentering/sam-
menkædning af programmer med fordel benyttes. Segmentering af
programmer bevirker, at hele programmet ikke ligger i arbejdsla-
geret på samme tid, men at for eksempel en række sjældent benyt-
tede procedurer kun hentes ind fra baggrundslageret, når de be-
nyttes. Sammenkædning af programmer betyder, at man kan kalde nye
programmer fra et kørende program, desuden er det muligt at over-
føre globale data til det kaldte program.
Især til administrativ brug tilbydes BCD (Binary Coded Decimal)
aritmetik, hvor tal består af 18 cifre, heraf de 4 som decimaler.
Håndteringen af input/output er kendetegnet ved, at den giver mu-
lighed for indlæsning og udskrivning på både record- og byte-ni-
veau. Desuden er der mulighed for at få tilgang til de enkelte
I/O-porte direkte fra Pascal/MT+.
Pascal/MT+ inkluderer også rutiner til flytning og manipulation
på bit- og byte-niveau, ligesom den indeholder rutiner til at
flytte data rundt i arbejdslageret, samt til at få fat i indhold-
et af bestemte lagerpositioner.
\f
Pascal/MT+ SPROGELEMENTER
S_æ_t_n_i_n_g_s_s_t_r_u_k_t_u_r_e_r_ S_t_a_n_d_a_r_d_ _p_r_o_c_e_d_u_r_e_r_
BEGIN...END CLRBIT
CASE...END DELETE
FOR...TO DISPOSE
FUNCTION EXIT
GOTO FILLCHAR
IF...THEN...ELSE INSERT
MODULE MOVELEFT
PROCEDURE MOVERIGHT
PROGRAM NEW
REPEAT...UNTIL SETBIT
WHILE...DO TSTBIT
WAIT
S_t_a_n_d_a_r_d_ _f_u_n_k_t_i_o_n_e_r_ I_/_O_ _p_r_o_c_e_d_u_r_e_r_ _o_g_ _f_u_n_k_t_i_o_n_e_r_
ABS ASSIGN
ADDR BLOCKREAD
ARCTAN BLOCKWRITE
CHR CHAIN
COS CLOSE
EOF CLOSEDEL
EOLN GET
EXP GNB
LENGTH IORESULT
LN OPEN
MAXAVAIL PAGE
MEMAVAIL PUT
ODD PURGE
ORD READ
POS READLN
PRED RESET
ROUND REWRITE
SIN SEEKREAD
SIZEOF SEEKWRITE
SQR WNB
SQRT WRITE
SUCC WRITELN
TRUNC
WRD
\f
D_a_t_a_k_o_n_v_e_r_t_e_r_i_n_g_s_p_r_o_c_e_d_u_r_e_r_ D_y_n_a_m_i_s_k_e_c_ _a_l_l_o_k_e_r_i_n_g_s_ _p_r_o_c_e_d_u_r_e_r_
PACK(A,I,Z) DIPOSE
UNPACK(Z,A,I) NEW
FORUDSÆTNINGER
Pascal/MT+ programmelpakken forudsætter en RC700 mikrodatamat med
CP/M og enten en 8" eller to 5 1/4" diskettestationer.
RCSL Nr. 42-i2145
\f
«eof»