|
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: 169600 (0x29680) Types: TextFile Names: »D13«
└─⟦53be6501e⟧ Bits:30005867/disk02.imd Dokumenter (RCSL m.m.) └─⟦this⟧ »D13«
\f i F_O_R_E_W_O_R_D_ First edition: RCSL No 31-D191 This manual explains how a BOSS2 system is generated for a particular installation. The system generation itself is very simple, but some background information is necessary in order to utilize the resources fully. Som maintenance information is also presented, especially concerning the user catalog, the accounting, and the testoutput. The manual consists of rather independent chapters written as the need arose and the time allowed. Thus the manual does not pretend to be complete, but we expect it to grow as new chapters are added gradually. Søren Lauesen A/S Regnecentralen, July 1972. Second edition: RCSL No 31-D313 Third edition: RCSL No 31-D421 The manual has now been revised so that it should be possible for unexperienced people to generate a bossversion for a given configuration. Furthermore the manual has been divided into an installation and a maintenance part, each of which has been extended considerably. Lars Otto Kjær Nielsen and Bent Bæk Jensen A/S Regnecentralen, February 1977. \f ii Fourth edition: RCSL No 31-D628 Since the third edition of this manual appeared, five new releases of BOSS2 have been issued, and the correction list has grown to 34 pages. These corrections have been incorporated in the text, which has also been generally revised. Chapter 5 concerning the accounting system has been rewritten and chapter 9 concerning the test output types has been extended. The present edition of the manual corresponds to BOSS2 release 17.0 (the Software Package SW8101/1/17.0) John Munkholm Andersen A/S REGNECENTRALEN af 1979, May 1981. \f iii T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 1. SYSTEM GENERATION ..................................... 1 1.1 The Source Text .................................. 1 1.2 Translation of the Source Text ................... 3 1.2.1 Source Text on Magnetic Tape .............. 4 1.2.2 Source Text on Backing Storage ............ 4 1.2.3 Source Text on Diskettes .................. 5 1.3 Options .......................................... 5 1.3.1 Options to Consider ....................... 6 1.3.2 Options Concerning System Disc ............ 8 1.3.3 Other Discs ............................... 10 1.4 Standard Options ................................. 11 1.5 Editing the Options - An Example ................. 21 2. START-UP .............................................. 23 2.1 Warnings During Start Up ......................... 24 2.2 Error Messages During Start Up ................... 25 3. RUNTIME REQUIREMENTS .................................. 28 3.1 Primary Storage Utilisation ...................... 28 3.2 Resource Requirements ............................ 29 3.3 Swopping, spooling ............................... 32 3.4 Other Files Used at Run Time ..................... 33 4. BOSSOLD ............................................... 35 4.1 Bossbin .......................................... 35 4.2 Bossupdate ....................................... 35 4.3 Bosstrans ........................................ 36 4.4 Bossload ......................................... 36 5. ACCOUNTING ............................................ 37 5.1 Account Records .................................. 39 5.2 Accountjob ....................................... 45 5.3 The Standard accountjob .......................... 48 \f iv T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 6. THE USER CATALOG IN BOSS .............................. 52 6.1 Resource Allocation to a Job ..................... 52 6.2 The Structure of the User Catalog ................ 53 6.2.1 Index Segments ............................ 53 6.2.2 Record Types in the Catalog ............... 54 6.3 How to Create and Update the User Catalog ........ 58 6.3.1 Syntax for the Call of >catupdate> ........ 59 6.3.2 Explanation of Parameters to >catupdate> .. 59 6.3.3 Implementation of Subcatalogs ............. 60 6.3.4 Input to Catupdate ........................ 60 6.3.5 Example ................................... 66 6.3.6 Errormessages from >catupdate> ............ 68 6.4 Listing of User Catalog (>userout>) .............. 71 6.5 Balancing Permanent Resources Against Actual Usage 71 7. HOW TO HANDLE A BOSS FAULT SITUATION .................. 73 8. BOSS FAULT ERROR CODES ................................ 74 9. TESTOUTPUT ............................................ 79 9.1 Record Format .................................... 79 9.1.1 Type 1, send .............................. 79 9.1.2 Type 2, lock .............................. 80 9.1.3 Type 3, opch .............................. 80 9.1.4 Type 4, open .............................. 80 9.1.5 Type 5, exit .............................. 80 9.1.6 Type 6, mess .............................. 81 9.1.7 Type 7, answ .............................. 81 9.1.8 Type 8, jd-1 .............................. 81 9.1.9 Type 9, stop .............................. 82 9.1.10 Type 10 ................................... 83 9.1.11 Type 11 ................................... 85 9.1.12 Type 12 ................................... 85 \f v T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_c_o_n_t_i_n_u_e_d_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 9.1.12.1 Jobstart ......................... 86 9.1.12.2 Job .............................. 86 9.1.12.3 Procs Testoutput ................. 86 9.1.13 Type 13 ................................... 89 9.1.14 Type 14 ................................... 90 9.1.15 Type 15 ................................... 90 9.1.16 Type 16 ................................... 90 9.1.17 Type 17 ................................... 90 9.1.18 Type 18 ................................... 90 9.1.19 Type 19 ................................... 91 9.1.20 Type 20 ................................... 91 9.1.21 Type 21 ................................... 91 9.1.22 Type 22 ................................... 91 9.2 Codepage Identifications ......................... 91 9.3 Coroutine Identifications ........................ 93 9.4 Selected Testoutput .............................. 94 9.5 Analysis of Testoutput ........................... 95 9.5.1 Last ...................................... 95 9.5.2 Bossout ................................... 97 \f vi \f 1_._ _ _ _ _ _ _ _ _S_Y_S_T_E_M_ _G_E_N_E_R_A_T_I_O_N_ 1. 1_._1_ _ _ _ _ _ _ _T_h_e_ _S_o_u_r_c_e_ _T_e_x_t_ 1.1 BOSS is supplied as a magnetic tape, containing a standard label and 21 textfiles, or as two diskettes containing the 21 text- files. The files are: 1, bossold When BOSS is supplied on magnetic tape, this file generates descriptors to the other files on the tape and transfers >options> and >jobdescr> to disc. Bossold always generates some service files for managing the BOSS files (chapter 4). 2, options This file contains options for some standard configuration (section 1.3). 3, jobdescr This file describes a set of data formats, used during translation of some of the BOSS coroutines. 4, central Translates into >bos>, i.e. this file is translated by >i bossbin> into the binary coroutine file >bos>. Contains code for testoutput, Central Logic, paging, start-up, and initialization. 5, tterm1 Translates into >bterm1>. Contains code for common interpretation of on-line commands, for on-line editing, for printing of error messages, and for a few commands. 6, tterm2 Translates into >bterm2>. Contains code for most of the on-line commands, for kit change, for request output to the operator, and for job output to the on-line user. \f 7, tjobstart Translates into >bjobstart>. Contains code for interpretation of job specification and start-up of a job. Contains code for the loadspecification. 8, tjob Translates into >bjob>. Contains code for messages from a job (except mount and load messages) and for job termination. 9, tmount Translates into >bmount>. Contains all code for handling of magnetic tapes. 10, tread Translates into >bread>. Contains code for handling of paper tape reader, card reader, and other spooled input devices. 11, tprinter Translates into >bprinter>. Contains code for handling of printers. 12, tprocs Translates into >bprocs>. Contains code for receipt of messages from unidentified terminals and processes which are not BOSS jobs. Contains various large common procedures for accounting, retrieval of information from the user catalog, book-keeping concerning backing storage resources, and creation of links for remote devices. 13, tbanker Translates into >bbanker>. Contains code for priority scheduling, resource allocation, swopping, book-keeping of run time. Contains initialization code for catalog cleaning and balancing of main catalog against user catalog. 14, taccount When loaded, this file generates a simple accountjob. 15, tcatupdate Contains the text of the program >catupdate>, which is used to create and update the user catalog. Also contains a text which will create a file >boptions>, containing certain information from >options>. (chapter 6). \f 16, tuserout Contains the text of a program >userout>, which may be used to print the contents of the user catalog (see 6.4). 17, testout Contains the text of the external algol procedure >bossout> and the program >last>, which are used to analyze and print the contents of the test output file (chapter 9). 18, textxref Contains the text of a program which can produce cross references of externals used in BOSS. (For maintenance purposes only). 19, tsaveconv Contains the text of the program >saveconv> which after a break down can find all the temporary convertfiles which have been produced but not yet printed by BOSS. The files will be transferred to a magnetic tape. The program must be called before BOSS is restarted. The use of the program is de- scribed in "BOSS Operator>s Manual". 20, tgetconv Contains the text of the program >getconv> which is used to print magnetic tapes created by >saveconv>. The use of the program is described in "BOSS Operator>s Manual". 21, tusercat Contains a job which creates a simple user cata- log. 1_._2_ _ _ _ _ _ _ _T_r_a_n_s_l_a_t_i_o_n_ _o_f_ _t_h_e_ _S_o_u_r_c_e_ _T_e_x_t_ 1.2 Notice that backing storage files will be created with scope >user>. This makes it possible to have more versions of the system at the same time. It may be convenient to have the normal version on system scope while changes in options etc. may be debugged in a local version. The following three examples show how the system is generated, depending on the document used for storage of the source text. \f 1_._2_._1_ _ _ _ _ _S_o_u_r_c_e_ _T_e_x_t_ _o_n_ _M_a_g_n_e_t_i_c_ _T_a_p_e_ 1.2.1 -' bossold=set <modekind' <tapename' 0 1 -' i bossold ; the files >options> and >jobdescr> are trans- ; ferred to disc, file descriptors to the rest of ; the files are created, and the service files are ; generated (see chapter 4). -' i trf ; modification of standard options (see 1.3.3). -' i bossbin ; translation of the BOSS coroutines (see 4.1). * att -'s -' remove all boss run -' bosstest=set 200 disc ; creation of testoutput area -' scope user bosstest -' i taccount ; creation of an account job (see chapter 5). -' i tusercat ; creation of an experimental usercatalog with ; contents as shown in the example in chapter 6. 1_._2_._2_ _ _ _ _ _S_o_u_r_c_e_ _T_e_x_t_ _o_n_ _B_a_c_k_i_n_g_ _S_t_o_r_a_g_e_ 1.2.2 -' i bossold ; generation of service files (see chapter 4). ; As (in this case) the file descriptors to ; the rest of the files are already present, ; the following message will appear: file descriptors left unchanged -' i trf ; modification of standard options (see 1.3.3). -' i bossbin ; translation of the BOSS coroutines (see 4.1). * att -' s -' remove all boss run \f -' bosstest=set 200 disc ; creation of -' scope user bosstest ; testoutput area -' i taccount ; creation of an accountjob (see chapter 5) -' i tusercat ; creation of an experimental usercatalog with the ; contents of the example in chapter 6. 1_._2_._3_ _ _ _ _ _S_o_u_r_c_e_ _T_e_x_t_ _o_n_ _D_i_s_k_e_t_t_e_s_ 1.2.3 -' fdload s18101.1 ; the files 1-13 are loaded to the system disc ; with scope >temp>, i.e. when BOSS is started ; up, they will be removed. -' fdload s28101.1 ; the files 14-21 are loaded as above. -' i bossold ; generation of service files (see chapter ; 4). -' i trf ; modification of standard options (see ; 1.3.3). -' i bossbin ; translation of the BOSS coroutines (see ; 4.1). * att -' s -' remove all boss run ready to boss -' bosstest = set 200 disc ; creation of -' scope user bosstest ; testoutput area -' i taccount ; creation of accountjob -' i tusercat ; creation of an experimental user ; catalog 1_._3_ _ _ _ _ _ _ _O_p_t_i_o_n_s_ 1.3 When translating the BOSS coroutines all information used for trimming BOSS must be listed in a file, named >options>. To ease the system generation some standard configuration is described in file No 2 (options). The trimming is done by editing this file. \f 1_._3_._1_ _ _ _ _ _O_p_t_i_o_n_s_ _t_o_ _C_o_n_s_i_d_e_r_ 1.3.1 Normally only the first 3 pages of the options need to be con- sidered: Page 1 defines the computer configuration on which BOSS is to run. For instance, various device numbers are stated here. Page 2 defines the main parameters, for instance, the maximum number of jobs which may be handled simultaneously, the amount of login resources to each terminal, the maximum size of an off-line job file. Page 3 defines the time classes and the class margin. Further, standard and maximum values of options. Notice, that the class margin ought to comprise resources for at least one job with standard resources. Otherwise, short jobs with standard resources cannot be guaranteed to bypass longer jobs. For some installa- tions a class margin corresponding to two standard jobs may be advantageous. In the following table the most important options concerning various elements and possibilities of BOSS are listed. M_a_i_n_ _c_o_n_s_o_l_e_,_ _t_e_r_m_i_n_a_l_s_ ...1... i1, i4 ...2... i45, i44, i48, i47, i113, i114 ...4... i7, i9, i161, i16, i175, i176 ...5... i3, i179, i181 ...5a.. i177 O_p_e_r_a_t_o_r_ _d_i_s_p_l_a_y_ ...1... i171 ...4... i172, i173 ...5a.. i174 \f P_r_i_n_t_e_r_s_,_ _r_e_m_o_t_e_ _p_r_i_n_t_e_r_s_ ...1... e23-e17, e35-e36, e58-e59, i190 ...2... i67, i104, e40, e47 ...3... i135, i147 ...4... i115, i191, i192 ...5a.. i72, i77, i79, i73, i74, i167, i168, i169, i170, i180, i75, i185, e38-e39, i68 P_a_p_e_r_ _t_a_p_e_ _r_e_a_d_e_r_,_ _s_p_e_c_i_a_l_ _r_e_a_d_e_r_ _d_e_v_i_c_e_ _(_c_o_n_t_r_o_l_)_,_ _r_e_m_o_t_e_ r_e_a_d_e_r_s_ ...1... e51-e55, e55-e52, e53, e23-e17 ...2... i41, i117, i119, i162 ...3... i146 ...4... i32, i193 ...5... (i42) P_u_n_c_h_e_d_ _c_a_r_d_ _r_e_a_d_e_r_,_ _r_e_m_o_t_e_ _c_a_r_d_ _r_e_a_d_e_r_s_ ...1... e54, i93, i200, e23-e17 ...2... i203, i52, i118, i163, i201 ...5... (i53) M_a_g_n_e_t_i_c_ _t_a_p_e_ _s_t_a_t_i_o_n_s_ ...1... e24-e25 ...2... i35 ...3... i106, i132, i138, i144, i145, i150 ...4... i31, i33 S_i_m_u_l_a_t_e_d_ _c_o_n_v_e_r_s_a_t_i_o_n_a_l_ _d_e_v_i_c_e_s_ ...1... e18-e19, e20-e21 ...4... i9, i16 F_l_e_x_i_b_l_e_ _d_i_s_c_ _d_r_i_v_e_s_ _(_d_i_s_k_e_t_t_e_ _s_t_a_t_i_o_n_s_)_ ...1... e25-e28, e60-e61 \f O_t_h_e_r_ _d_e_v_i_c_e_s_ _n_o_t_ _s_i_m_u_l_a_t_e_d_ _b_y_ _B_O_S_S_ ...1... e23-e28 D_e_v_i_c_e_s_ _w_h_i_c_h_ _r_e_q_u_i_r_e_ _o_p_e_r_a_t_o_r_ _a_t_t_e_n_t_i_o_n_ _b_e_f_o_r_e_ _u_s_e_ ...1... e25-e17 D_r_u_m_/_d_i_s_c_ (See 1.3.2) O_t_h_e_r_ _b_a_c_k_i_n_g_ _s_t_o_r_a_g_e_ _d_e_v_i_c_e_s_ (see 1.3.3) A_c_c_o_u_n_t_i_n_g_ ...2... i105 ...3... i136, i148 ...5... e70, e71, i14 M_i_s_c_e_l_l_a_n_e_o_u_s_ ...1... e0, e79, e60-61 ...2... i116 ...5... i11, i178, (e6, e7, e9), e16 ...7... (e99, e100), e101 1_._3_._2_ _ _ _ _ _O_p_t_i_o_n_s_ _C_o_n_c_e_r_n_i_n_g_ _S_y_s_t_e_m_ _D_i_s_c_ 1.3.2 A number of options concern resources on the system disc (i.e. the disc with the name >disc>). These options (with their standard values) are: \f options page 2: i47 = 280 ; max. no. of segments in a basis file i105 = 24 ; no. of segments in account file i114 = 25 ; login slices for each terminal i162 = 4 ; max. length of job file for a papertape job ; (slices) i163 = 4 ; max. length of job file for a cardjob (slices) options page 3: i108 = 35 ; temp disc slices in class margin i121 = 25 ; temp disc slices, std. value for jobs i137 = 4 ; std. value for output (slices) i140 = 16384 ; std. value for jobsize (halfwords) The reason for the inclusion of i140 (jobsize) here, is that it determines the size of the swoparea for a standard job. The standard values are reasonable if the slicelength of the system disc is 8. The following table gives suggested values of these options for the slicelengths normally found on RC8000 system discs. DISC slice- i47 i105 i114 i162 i163 i108 i121 i137 i140 length (segm) RC8221 7 210 84 38 4 4 42 30 8 13312 RC8222 14 280 84 24 2 2 26 20 4 13312 RC8223 21 315 84 18 2 2 20 15 3 13312 RC8224 42 420 84 12 1 1 13 10 2 13312 RC8225 84 504 84 7 1 1 10 8 1 13312 RC8226 168 672 168 5 1 1 8 6 1 13312 In connection with these changes you should also change the options concerning the number of catalog entries for a standard job (options page 3) to: i107 = 12 and: i126 = 10, as the standard values given are unnecessarily high. \f If you want to use other values of these options, you should chose them so that: 1. i108 = i121 + i137 + swoparea (slices) The size of the swoparea may be calculated from the value of i140. (1 segment = 512 halfwords) 2. i114 = max. basis file (slices) + i137 The values in the table give the following standard values of the job specifications: DISC slicelength temp disc output (segments) (segments) (characters) RC8221 7 210 43008 RC8222 14 280 43008 RC8223 21 315 48384 RC8224 42 420 64512 RC8225 84 672 64512 RC8226 168 1008 129024 1_._3_._3_ _ _ _ _ _O_t_h_e_r_ _D_i_s_c_s_ 1.3.3 Discpacks (or logical backing storages) on which users are given permanent resources in the user catalog, may only be mounted on the disc drives mentioned in the list in options page 1 after e22. Therefore you should normally include a_l_l_ disc drives, except the one for the system disc, in this list. The option i29 (options page 1) stating total number of drum and disc devices, must be exactly equal to the number of disc drives (logical backing storages) stated in the monitor. Otherwise BOSS refuses to start up. The option i30 (options page 2) stating the maximum number of private discpacks in one project may as a useful standard be equal to: (i29 - 1)*2. \f 1_._4_ _ _ _ _ _ _ _S_t_a_n_d_a_r_d_ _O_p_t_i_o_n_s_ 1.4 The following is a listing of the standard option file. \f F_ \f F_ \f F_ \f F_ \f F_ \f F_ \f F_ \f F_ \f F_ \f F_ 1_._5_ _ _ _ _ _ _ _E_d_i_t_i_n_g_ _t_h_e_ _O_p_t_i_o_n_s_ _-_ _A_n_ _E_x_a_m_p_l_e_ 1.5 As mentioned in section 1.3 the trimming for the actual installation is performed by editing the standard options supplied. In subsections 1.2.1 and 1.2.2 this editing is assumed to be written on a paper tape (trf = flexomode). The following example shows how it may look. NB: If the source text is on disc, the standard options are removed during this editing. message edit of standard options (optt = edit options if ok. no end) l./...1.../, l./e0:/, r/rialto/RC COMPUTER,1981.02.18/, ; testoutput ident. l./e80=/, r/=-1/=1/, ; rc8000 l./i15=1014/, r/=1014/=2046/, ; max no of slices l./i27=/, r/=1/=-1/, ; no drum l./i29=1, r/=3/=2/, ; backing storage devices l./e24:/, l1, r/6, 7, 8/10, 11/, ; std stations l./e26=/, l1, r/10/ /, ; no special stations l./e35:/, l1, r/5 ;/5, 42, 43 ;/, ; std printers l./e58:/, l1, d, ; preselected papers: i/ -1 ; printer 5: all except paper 7 and 8 7 ; printer 42: only paper 7 8 ; printer 43: only paper 8 /, l./...3.../, l./i140=/, r/=16384/=13312/, ; std size l./...7.../, l./e101:/, d, i/ e101: <:RC COMPUTER:' 0, 0, 0, 0, 0, 0 ; login message /, \f f scope user optt if ok.no end clear user options rename optt. options end \f F_ 2_._ _ _ _ _ _ _ _ _S_T_A_R_T_-_U_P_ 2. After system generation BOSS is started by the following com- mands: att s all boss run ; the BOSS-process must be created with ; system bases base abs <min' <max' ; if the system to be started is created on ; system scope, this command may be omitted; ; otherwise it is used to set the catalog ; base of BOSS according to the base of the ; system bos ; The file named >bos> contains a two-pass loader, which loads the 9 other coroutine files one by one. Each file is entered and allowed to initialize itself. The files reserve room and define addresses in the virtual store and in primary storage. The address definitions are entered in a table of external symbols. In the second loader pass, the files are loaded and entered again exactly as in the first pass, but now the external symbols are finished and addresses become complete. Certain functions which were dummy in the first pass are active now. For instance, the files now move code, tables, and variables to the virtual store. At the end of the second pass, BOSS scans the catalog and tries to clear all temporary and login files. At the same time, the actual permanent resources for each user and project are deter- mined. Finally, the user catalog is scanned and all permanent rest claims are updated according to the actual resources used. When a user has run under s, for instance, it may happen that the actual files exceed the claims stated in the user catalog. In this case BOSS just leaves a rest claim of zero, so that the user cannot get more permanent resources under BOSS. This balancing of \f user catalog against main catalog involves all bs-devices mounted for the moment. Entries in the user catalog referring to other disc packs are left unchanged. During the initialization, a well defined access to various devices and files is established. For instance, all magnetic tapes available for jobs are unloaded. 2_._1_ _ _ _ _ _ _ _W_a_r_n_i_n_g_s_ _D_u_r_i_n_g_ _S_t_a_r_t_ _U_p_ 2.1 At start up BOSS may write some warnings on the main console, concerning catalog balancing, testoutput, and accounting. M_m_m_ slices 1. project no: <integer' rest claim: <integer' on <document' P_p_p_ entries This message occurs when a project has used more permanent resources on the specified document than allowed according to the user catalog. The message may be caused by: a) creation of files under >s> b) decrease of claims in the user catalog c) overlap of intervals in the user catalog. 2. *** test output inactive Occurs if no area exists and no tape is mounted with the name >bosstest>, or if >bosstest> is not created with system scope. 3. <error description' accountjob not ok Occurs if no jobfile with the name >accountjob> exists with system scope, or if it is not a legal job. \f 2_._2_ _ _ _ _ _ _ _E_r_r_o_r_ _M_e_s_s_a_g_e_s_ _D_u_r_i_n_g_ _S_t_a_r_t_ _U_p_ 2.2 If BOSS gets into serious troubles during startup, it writes an error message on the main console and then stops (with BOSS fault 5). The possible error messages are: 1. coroutine area missing one of the binary coroutine files is not visible from BOSS> catalog base. 2. create disccore error during start up BOSS creates two areas for its virtual core (disccore and drumcore). If the creation of disccore is unsuccessful this message appears. 3. create drumcore error see 2. 4. dummy answer coroutine one of the binary coroutine files cannot be used. 5. external outside limits references are exchanged between files via externals; such an external is out of range. 6. input error virtual core a work file could not be read during start up. 7. i116 too small : w0=min value the number of segment places in core is too small. 8. max coroutine too small option e3 is too small, there is not room for one of the coroutine files. 9. output error virtual core during start up writing in a work file was unsuccessful. \f 11. table reservation error one of the tables, which can be seen in section 3.1 is created with wrong size, possibly because different options have been used for translating different coroutine files. 12. transfer error coroutine BOSS cannot get started because of input troubles when reading a coroutine file. 13. virt core table too small possibly same cause as for error No 11. 14. too many bs devices appears if the installation (the monitor) is equipped with more bs devices than described in BOSS> options (i29). 15. catalog input trouble the main catalog could not be accessed, probably because of hardware errors. 16. drum or disc missing the value of the option i29 is too high. 17. entries do not match usercat the user catalog is inconsistent, most likely because the latest translation of it was unsuccesful. Retranslate and check the output from the translation carefully. 18. usercat incorrect the user catalog is inconsistent. See 17. 19. user cat input trouble the user catalog could not be accessed, either because of hardware errors, because it did not exist, had wrong scope, or was reserved by another process. 20. virtual storage too big the total demand on virtual storage exceeds 4095 segments. Check the values of the options i41, i52, and i67 (options page 2). \f 21. time inconsistence accountf1 date and time n_o_w_ (as defined by the system clock) is e_a_r_l_i_e_r_ than date and time when BOSS was last running. The first part of chapter 5 describes how the situation may remedied. During start up the banker is called to investigate whether the resources promised by the BOSS options and the resources stated in the user catalog are in accordance with the resources given by the monitor to the BOSS process. If the comparison of resources is not ok, one of the following messages may appear: too few stations too few temp entries too few temp disc slices too few convert operations too few account operations too few message bufferws too few area processes too few internal processes too few suspend operations too few temp drum entries too few temp drum slices too few remote readers too few standard readers too few protection keys \f F_ 3_._ _ _ _ _ _ _ _ _R_U_N_T_I_M_E_ _R_E_Q_U_I_R_E_M_E_N_T_S_ 3. This chapter is a survey of the organization of BOSS at runtime. The information is useful for understanding the options (section 1.3). 3_._1_ _ _ _ _ _ _ _P_r_i_m_a_r_y_ _S_t_o_r_a_g_e_ _U_t_i_l_i_s_a_t_i_o_n_ 3.1 At runtime the BOSS-process is organized like this: testoutput code central logic pager first free core job process a (variable size) room for BOSS pages (at least i116 segment places) job process b (variable size) last free core core table segment table semaphore table, printer buffers, etc. terminal buffers sender table coroutine table file access table testoutput buffer \f Most of BOSS> code and variables is placed in the so-called v_i_r_t_u_a_l_ _s_t_o_r_e_ consisting of two backing store files >drumcore> and >disccore>. Pages of the virtual store are transferred to/from the primary storage as the need arises. If only one or no job is present in core store, the the space thus left free will be used for pages. A large job may force the minimum room for pages to move to >last free> (or >first free>), thus also preventing another job from using the core store. 3_._2_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _R_e_q_u_i_r_e_m_e_n_t_s_ 3.2 The resources required by BOSS depend on options. The requirements of a special installation may be estimated by means of the following rules of thumb. Please be aware, that these formulas only give an approximate result, due to changes and extensions. The resource demands primarily depend on the following options: number of pseudo jobs i45 number of terminals i4 (plus main console and operator display) number of standard printers i71 number of remote printers i190 number of tape readers e52+e53 number of card readers i93+i200 number of tape stations e25+e26 number of exchangeable disc drives e23 \f Resources for each item and fixed resources: primary storage area message (halfwords) processes buffers pseudo job 56 1 1 terminal 82+i3* 1 1 std printer 56+e40** 1 1 remote printer 56+e47*** 1 1 reader 56 1 1 card reader 56 1 1 tape station 32 0 1 exchangeable disc 22 0 1 fixed resources: resident code 2450 - - test buffer 512 - - preoccupied area processes - 12 - preoccupied message buffers - - 8 * terminal buffer size ** standard printer buffer size *** remote printer buffer size Besides the demand on primary storage as computed from the table above, BOSS requires room for the following three tables: 1. f_i_l_e_ _a_c_c_e_s_s_ _t_a_b_l_e_, which describes BOSS> access to any area process in the monitor. size = 1 halfword for each area process in monitor. 2. s_e_g_m_e_n_t_t_a_b_l_e_, which describes the segments of BOSS> virtual store. size = 1 halfword for each segment in drumcore and disccore (usually 600 - 1000 halfwords). \f 3. c_o_r_e_t_a_b_l_e_, describing >free core>, (dotted line in 3.1), which is organized as a number of >segment places>. coretable size = 4 halfwords for each segment place = (BOSS> process size - primary storage from table - file access table - segmenttable) / 516 The maximum size of a job will then be: maxjobarea = BOSS> process size - primary storage from table - file access table - segment table - coretable size - 512 * i116 (minimum area for BOSS> segmentation). Apart from the resources mentioned, the BOSS process demands at least 4 internal processes (sparse, 8 will be better), plus the paper tape reader, plus the devices specified in the options, page 1. The paper tape reader must have the name >reader>, a pos- sible card reader must have the name >cardreader>. The monitor constants for input time out from typewriters should be carefully considered. If BOSS expects input from a typewriter, all output to the typewriter will pend until the user (or opera- tor) completes the input line or the monitor completes the ope- ration because of time out. Especially, messages from the operator to a terminal must await completion of input from the terminal, and operator requests from BOSS must await completion of input from the operator. Disc slices: BOSS demands a disc claim corresponding to the total disc slices as computed in the scheme plus resources to fulfil all rest claims in the user catalog. Of the total disc slices, i108*4 are available for jobs (see option i108 on page 3). Remaining disc slices are available for jobs. \f Drum slices: Analogous to disc slices, i112 replacing i108. Catalog entries: Analogous to disc slices, i107 replacing i108. The rest claims in the user catalog are defined as: -first word in user catalog - present number of catalog entries occupied by users in the user catalog. This accounts also for disc packs not mounted at present. Message buffers: Of the total number of message buffers needed, i109*4 are available for jobs. Of these, i109 are available for class 3 jobs, 2*109 for class 2 jobs, 3*109 for class 1 jobs, and 4*109 for class 0 jobs. Remaining message buffers are available for all jobs. Area processes: Of the total number of area processes needed, (i110-1)*4 are available for jobs. Of these, i110-1 are available for class 3 jobs, 2*(i110-1) for class 2 jobs, 3*(i110-1) for class 1 jobs, and 4*(i110-1) for class 0 jobs. Remaining area processes are available for all jobs. 3_._3_ _ _ _ _ _ _ _S_w_o_p_p_i_n_g_,_ _s_p_o_o_l_i_n_g_ 3.3 A job in core may be s_w_o_p_p_e_d_ _o_u_t_ because it waits for operator or user action or because a high priority job wants the core. The swop-out consists of stopping the job process and copying the core area into a s_w_o_p_ _a_r_e_a_ on disc. A corresponding swop-in takes place when the core area is free or occupied by a low priority job. The swop area is created as a separate file at jobstart. The internal resource demands of the job are increased correspondingly. I/O to some devices (terminals, tape reader, card reader, and printers) is spooled, which means that a backing store area (the s_p_o_o_l_ _a_r_e_a_) is used to collect the information in case the producer of the information runs faster than the consumer. Most\f of the spool areas in BOSS (namely those for primary output from jobs) are created as separate files at job start, and the resource demands of the job are adjusted accordingly. Spool areas for controlled i/o (readers and printers) are a fixed part of the virtual store (option i41, i52, i67). In case of off-line jobs, the resources needed to hold the job file cannot be attributed to a job initially, as the job specification is interpreted later. Thus, a set of resources is set aside for the purpose (option i162, i163). 3_._4_ _ _ _ _ _ _ _O_t_h_e_r_ _F_i_l_e_s_ _U_s_e_d_ _a_t_ _R_u_n_ _T_i_m_e_ 3.4 Catalog: BOSS scans the main catalog at job termination in order to clean away entries and areas left non-permanent by the job (can be avoided by an option in the user catalog). A logout both >temp> and >login>-entries will be removed (this can not be avoided). Usercat: BOSS searches the user catalog at initialization, job start, and login. The user catalog is modified whenever a user changes his amount of permanent files. The user catalog is reserved all the time by BOSS. Accountjob: When BOSS is started up, the account job is enrolled automatically with the job file found in the file named accountjob. The account job is then suspended until the account file is to be processed (chapter 5). Accountfile, accountf1: BOSS collects account information in the file >accountf1>. When this file is to be emptied, it is renamed to >accountfile> (if possible) and the account job is activated. Meanwhile BOSS continues collecting in a new >accountf1>. Further details in chapter 5. \f Bosstest: When BOSS starts up, it checks to see whether a magtape with the name bosstest exists. Then the tape is used for testoutput, starting at the beginning of the file on which the tape is positioned. Otherwise BOSS tries to get access to a bs-file named bosstest. If it succeeds, testoutput is generated here. Otherwise the testoutput is just stored cyclically in the core store buffer. The amount of testoutput is controlled by option e81 to e98 (see the options page 5). \f F_ 4_._ _ _ _ _ _ _ _ _B_O_S_S_O_L_D_ 4. Bossold is the first of the source text files. This file contains a variety of programs which may be used in generating, translating, and updating BOSS. The command i bossold generates the following programs (jobs): bossbin bossupdate bosstrans bossload as temporary files (scope temp). Bossold itself checks if the file descriptors are ok; if they are the program is terminated with the following message: file descriptors left unchanged In case no file descriptors exist for the files, file descriptors are created and the two files o_p_t_i_o_n_s_ and j_o_b_d_e_s_c_r_ are transfer- red to the bs device wanted. 4_._1_ _ _ _ _ _ _ _B_o_s_s_b_i_n_ 4.1 Bossbin is a job which translates all the BOSS coroutines, the >catupdate> program and the test output program. 4_._2_ _ _ _ _ _ _ _B_o_s_s_u_p_d_a_t_e_ 4.2 Bossupdate generates an updated version of all the BOSS files on a magnetic tape. The following commands may be used: bossnew=set <mode' <tapename' 0 1 i bossupdate. \f As a control of the files written on the magnetic tape the tape is check read and in the output it is possible to see if the generation of the tape has succeeded. If >bossupdate> cannot find a file descriptor named >bossnew> the errormessage - bossnew not set will appear and the program will terminate. 4_._3_ _ _ _ _ _ _ _B_o_s_s_t_r_a_n_s_ 4.3 Bosstrans is much like >bossbin> but only the BOSS coroutines are translated and stored on disc. 4_._4_ _ _ _ _ _ _ _B_o_s_s_l_o_a_d_ 4.4 Bossload loads all the files from the BOSS magnetic tape and stores the files as textfiles on the disc. The files get user scope. If temporary file descriptors exist with names equal to some of the files to be loaded these temporary entries are removed. If bossold does not exist the following errormessage appears - bossold not set Bossold must exist because the files to be loaded are assumed to be loaded from a magnetic tape described by the file descriptor >bossold>. If >bossold> exists on another document than a magnetic tape then the following errormessage will appear - bossfiles not loaded In case of an errormessage the program will terminate. If a file >bossnew> exists on a bs document, all the BOSS files will be loaded on this document, otherwise they will be loaded on the system disc. \f F_ 5_._ _ _ _ _ _ _ _ _A_C_C_O_U_N_T_I_N_G_ 5. While BOSS is running, essential information concerning the use of resources is collected as records in a file with the name >accountf1>. This file is created and maintained by BOSS as a permanent file with the size given by the option i105 (options page 2). The file will be created on >disc> and the entry base will be (-8388607, -8388607), which is called the >account base>. When BOSS starts up, >accountf1> will be looked up, and if it does not exist, BOSS will create an empty file as described above. If the file exists, BOSS will scan it in order to find out where output to the file is to be resumed. Normally there will be a special stop-record, and output will then be resumed so that this record will be overwritten at the next writing. At the same time a new stop record will be inserted, except if current segment is full. If, during the scan, BOSS finds a record with illegal contents, BOSS will assume that a crash happened, and resume writing from that point. All records contain the system time of their production, and if the value of system time in the last record found during the scan is larger than the current value of system time, BOSS will stop with the message: time inconsistence accountf1 ***boss fault 5. This is a valuable check on the initialization of system time during start up. In such cases, check if system time is correct. If not, autoload and reinitialize system time. Otherwise system time was not correct when BOSS was last running. In that case do as follows: *att -'s -'proc boss remove all boss run ready \f to boss -' base 0 0 ; set catalog base = account base -' rename accountf1.accountfile -' base ; reset catalog base (to system base) -' bos ; start boss BOSS will then make a new >accountf1> and enroll the accountjob for execution immediately after start up (cf. section 5.2). You may also use another name than >accountfile> e.g. (instead of "rename ..."): -' rename accountf1.badaccount -' scope user badaccount and then analyse the file "manually". In that case you should n_o_t_ later rename >badaccount> to >accountfile> if BOSS has been star- ted in the meantime. You might also use the standard accountjob (cf. section 5.2) to print the file and then cancel it, like this (instead of "rename ..."): -' writeacc = algol message.no accountjob -' o lp -' writeacc in.accountf1 -' o c -' scope temp accountf1 -' clear temp accountf1 Of course you may also make copies of >accountf1>, but apart from this, and obviously harmless variations of the examples given, it is not permitted to tamper with >accountf1> or >accountfile>. If you do, you may experience: ***boss fault 80 while BOSS is running, or: create accountf1 error *** boss fault 5 during start up. (Otherwise these errors will be due to errors in hardware). \f 5_._1_ _ _ _ _ _ _ _A_c_c_o_u_n_t_ _R_e_c_o_r_d_s_ 5.1 The accountfile contains fixed-length records (recordlength = 32 halfwords), blocked 16 records to a segment. All records have the following format: +0 project number (word) +2 to +6 user name (9 characters) (not always terminated) +8 user index etc. (word, see below) +10 record kind (word) +12 to +14 time (double word) +16 to +30 parameters depending on record kind. The contents of the field >user index etc> are controlled by the option e71 (options page 5). If e71=0, (which is the default value) the word will always be 0 (providing a convenient terminator for the text in >username>). If e71=1 the right half of the word will contain user index, while the contents of the left half of the word will depend on record kind (see below). In the following list of existing record kinds, only the fields +8 and +16 to +30 are mentioned. If some of these fields are not mentioned, their contents are undefined. Please notice, that the addresses given here (and above) are relative to record start as they would be in a slangprogram. The standard account job (cf. 5.2) shows corresponding suitable field variable declarations and initializations for an ALGOL program. R_e_c_o_r_d_ _k_i_n_d_ _=_ _1_,_ _j_o_b_f_i_n_i_s_ Produced whenever a job finishes (this also applies to the small jobs which actually perform on-line converts). \f +8 (hw) 0 or finis cause (see below) +9 (hw) 0 or user index +16 (word) net run time used (seconds) +18 (hw) mounts used +19 (hw) loads used +20 (word) cpu-time used (unit:08192 secs) +22 (hw) temp drum (slices demanded) +23 (hw) temp disc (slices demanded) +24 (hw) stations demanded +25 (hw) size (unit: 512 hw) +26 (word) device word (first 24 bits) (see below) +28 (word) device word (last 24 bits) (see below) +30 (hw) deliberate waiting (minutes) +31 (hw) conversation (no. of lines input) Finis cause is an integer code specifying how (or why) the job finished, the coding is: 0 (normal finis) 1 killed by user 2 time exceeded 3 replaced by jobfile: ... 4 job file exhausted 5 job file unreadable 6 killed by operator 7 mode unknown ... 8 output exceeded 9 not special station: ... 10 special station not ordred: ... 11 ring not allowed on tape: ... 12 tape reserved for other project: ... 13 stations exceeded at mount ... 14 suspends exceeded 15 login claims exceeded 16 tape used by other job: ... 17 accounts exceeded 18 convert file unreadable (see below) 19 max waiting time exceeded \f 20 bad fp 21 size too small for fp 22 no interrupt address 23 mount special after mount ... 24 corelock not allowed 25 corelock exceeded 26 load area in use ... 27 hard error on initial program or swop area ... 28 too few resources on ... 29 job name conflict 30 program does not exist 31 size too small 32 temp exceeded 33 replace file unreadable ... 34 replace file too long ... 35 temp exceeded job file 36 card deck exhausted 37 limited ... 38 option unknown ... 39 param at ... 40 syntax at ... 41 line too long after ... 42 device unknown ... 43 hard error on convert file ... (see below) 44 job creation impossible 45 file is no text file If the job was an on-line convert, 100 will be added to the codes shown above, so that (e.g.): 100 means: on-line convert, normal finis 137 means: on-line convert, limited (disc slices). The codes 18 and 43 will therefore never appear. (They are replaced by 118 and 143). The device word (+26 and +28) is a double word with one bit corresponding to each device mentioned in the device list in options (options page 1, between e24: and e17=). \f The most significant bit always equals 0, the next bit corresponds to job controlled reader, the next bit to job controlled printer, and so on backwards (i.e. from e17 and up) through the list, ending with special tape stations. Using the standard options as an example, the device word is interpreted as follows: 0 shift 47 (always zero) 1 shift 46 job controlled reader (tapes ... ordred) 1 shift 45 job controlled printer (device printer) 1 shift 44 job controlled cards (device card) 1 shift 43 device punch 1 shift 42 device plotter 1 shift 41 device 14 1 shift 40 device 0 1 shift 39 device 10 R_e_c_o_r_d_ _k_i_n_d_=_2_,_ _l_o_g_o_u_t_ Produced when a user logs out from a terminal. When the account job is being started (cf. 5.2) there is a brief period of time (some tens of milliseconds), during which the production of a logout record may be skipped. +8 (hw) 0 or logout cause (see below) +9 (hw) 0 or userindex +16 (word) time logged in (minutes) +18 (word) operations performed (see below) logout cause is an integer with the meaning: 0 normal logout (requested by user) 1 hard error on terminal 2 operator remove 3 timeout on terminal >Operations> is an estimate of the amount of work performed by BOSS during the session. \f It is increased by 1 after: - each command line and edit line read (also in autoline mode), but not for input lines to conversational jobs. - each line printed in response to simple commands like >display>, >list>, >verify>, >lookup>, etc., but not for output from jobs. - >get>, >save>, and >transmit>: one for each segment (768 characters) in the file. R_e_c_o_r_d_ _k_i_n_d_ _=_ _3_,_ _p_r_i_n_t_ Produced when a file has been printed. +8 (hw) 0 or convert kind (see below) +9 (hw) 0 or user index +16 (word) number of lines printed +18 (word) number of pages printed (see below) +20 (word) paper type (see below) >Convert kind> is an integer with the meaning: 0 normal convert, either on-line or from a job 1 primary output from a job 3 jobcontrolled printing >Pages> is 1 + number of formfeeds in the file. >Paper type> is the paper type ordered in the convert operation. For primary output >paper type> will always be 0. For jobcontrolled output, >paper type> is the last paper type used. R_e_c_o_r_d_ _k_i_n_d_ _=_ _4_,_ _j_o_b_ _(_j_o_b_s_t_a_r_t_)_ The option e70 (options page 5) controls the production of these records. If e70=0, which is the default value, they are not produced. If e70=1 the record will be produced at jobstart. +8 (hw) 0 +17 (hw) initial priority +9 (hw) 0 or user index +18 (word) expected net runtime +16 (hw) 0 +20 (word) expected gross runtime \f The record is produced when the job specification has been checked, and it has been checked that BOSS has resources to fulfil the claims of the job. This will normally be a few hundred milliseconds (typically 200-300 msec.) after the command starting the job was issued (or the paper tape or the card file containing the job was read). Notice that this is before reservation of resources, and before load-specifications (if present) are checked and executed. The accountrecord is not produced for jobs which are killed or stopped because of errors before they reach the stage explained above. The account record is also not produced for the small jobs which carry out on-line converts. In such cases a j_o_b_f_i_n_i_s_ accountrecord (kind = 1) may or may not be produced, depending on why the job finished: if errors occur before username, userindex, and project number have been checked (and approved) no jobfinis accountrecord will (or indeed can) be produced. When the accountjob is being started (cf. 5.2), because the operator started it or because the accountfile is full, there is a short period of time (some tens of milliseconds), during which accountrecords of kind 4 cannot be produced (cf. accountrecords of kind 2). R_e_c_o_r_d_ _k_i_n_d_s_ _b_e_t_w_e_e_n_ _4_ _a_n_d_ _9_9_:_ _i_l_l_e_g_a_l_. R_e_c_o_r_d_ _k_i_n_d_ _=_ _9_9_,_ _s_t_o_p_ This record signals the end of the accountfile, as already mentioned. Please notice that a_l_l_ other fields than record kind are undefined. R_e_c_o_r_d_ _k_i_n_d_ _'_=_1_0_0_,_ _p_r_i_v_a_t_e_ _a_c_c_o_u_n_t_r_e_c_o_r_d_s_ These records are produced, at the request of jobs, by means of the parent message >account>, which may be sent by means of the utility program >account> or by other programs. \f +8 (hw) 0 +9 (hw) 0 or user index +16 (word) word m+14 from the account message. +18 (word) word m+8 from the account message. +20 (word) word m+10 from the account message. The meaning of the information is defined by the user. Notice that record kind may also carry information. If you use the utility program >account>, the connection between parameters and accountrecord will be: param1 = record kind, param2 = record +16, param3 = record+18, param4 = record+20. 5_._2_ _ _ _ _ _ _ _A_c_c_o_u_n_t_j_o_b_ 5.2 The information collected in >accountf1> may be used to super- vise computer utilization, for resource planning, customer changing, etc. In order to take care of this, or at least to empty the file when it runs full, all installations must include an a_c_c_o_u_n_t_j_o_b_ with these characteristics: - The jobfile must be a permanent file with the name >accountjob>, it must be visible from the account base (-8388607, -8388607), and it must be present when BOSS is started. - The project must be defined in the user catalog with a project base which includes the account base, and it must (at least) have permanent resources on the system disc to account for the accountjob and two accountfiles. - The user must have >job width>=1, >no. of user indices>=1 and the user base must be the account base. - The accountjob must include actions to cancel or ortherwise dispose of (e.g. by renaming) a file with the name >accountfile>. \f Besides this the accountjob and the accountproject may be handled as ordinary jobs and projects. The accountjob is looked up and taken through the first stages of a normal jobstart each time BOSS starts up, and it is then stop- ped just a_f_t_e_r_ the point where the jobstart-record (cf. 5.1) is produced. Then it waits until the account file runs full or the operator types >start account>. When this happens, BOSS will rename >accountf1> to >accountfile> and let the execution of the accountjob continue. Meanwhile BOSS will create a new >accountf1> and use this file to collect the accountrecords. When the accountjob finishes, BOSS checks that >accountfile> has been removed, and initializes the accountjob as during start-up. If >accountfile> still exists when the accountjob finishes, BOSS writes the message accountjob not ok and enrolls the accountjob for execution again. The standard accountjob supplied with BOSS is shown in subsection 5.3 as an example of an accountjob. If you want to use it or modify it to suit your own needs, please notice: - The job may run with a size as small as 13312 hw but inefficiently. - The job will remove >accountfile>, even if the printing of the accountfile is unsuccessful. - You may want to change the value of lines _on _a _page, slicelength _on _drum, and slicelength _on _disc. \f If you make your own accounting system, you should try to minimize the runtime of the accountjob, and let an ordinary job carry out the main part of the work, e.g. as outlined in the following rough sketch: The accounting project in the user catalog: 10 4711 0 10 3 -8388607 -8388604 4 perm disc1 50 20 21 5 perm disc1 0 0 11 accouser 4711 0 1 1 -8388607; userbase = account base ; notice, that >boss private base> (-8388606, -8388606) ; is - and m_u_s_t_ be - left free. 11 otheruser 4711 0 1 2 -8388605 ; notice, that this user has 2 userindices, one for ; >bigjob> and one for editing etc. The file >accountjob> contains something like this: job accouser 4711 mode list.yes lookup accountfile accountf1 accofile rename accountfile.accofile scope project accofile newjob bigjob finis The file >bigjob> contains: job otheruser 1 4711 time... etc. ... ... this is where the real work is done ... finis Finally: if you want to use the jobstart records (kind=4) to keep track of job turn-around-time, please remember that there is not a one-to-one correspondence between jobstart records and jobfinis records, especially not if you only scan the accountrecords in a single accountfile at a time. \f 5_._3_ _ _ _ _ _ _ _T_h_e_ _S_t_a_n_d_a_r_d_ _a_c_c_o_u_n_t_j_o_b_ 5.3 The following is a listing of the file >taccount> which contains the standard accountjob. \f F_\f F_\f F_\f F_ 6_._ _ _ _ _ _ _ _ _T_H_E_ _U_S_E_R_ _C_A_T_A_L_O_G_ _I_N_ _B_O_S_S_ 6. G_e_n_e_r_a_l_ At start up the operating system BOSS reserves the file named >_u_s_e_r_c_a_t_>_ which must be visible from the account catalog base (see chapter 5). While BOSS is running, >usercat> is used to identify users and determine their standard resources and possible maximum resources. The file >usercat> (the user catalog) is a hierarchical structure of subcatalogs of variable-length records. Each record describes a piece of information for a user or a project available in the user catalog. The sequence of records is as follows with the sequence shown in more and more detail: first project project head project spec. second project first user user head . second user user spec. . . last project end record The project head states the project number, the project catalog base and the project pool on disc. The user head states the user name, the user>s catalog base and the number of user indices. Project specifications and user specifications may be absent, but if present they specify standard and maximum resources. 6_._1_ _ _ _ _ _ _ _R_e_s_o_u_r_c_e_ _A_l_l_o_c_a_t_i_o_n_ _t_o_ _a_ _J_o_b_ 6.1 The resources available to a job are determined partially from the information found in the user catalog and partially from BOSS options. The actual resources for a job are determined by the following algorithm: \f resources:= standard resources from options modify resources according to project specifications - - - - user - - - - - job - The final resources must be within the maximum resources and within the resources available to the time class of the job (cf. User>s Manual, section 4.2) 6_._2_ _ _ _ _ _ _ _T_h_e_ _S_t_r_u_c_t_u_r_e_ _o_f_ _t_h_e_ _U_s_e_r_ _C_a_t_a_l_o_g_ 6.2 The user catalog is sorted so that the projectnumbers appear in ascending order, and within the projects the user names appear in ascending order. 6_._2_._1_ _ _ _ _ _I_n_d_e_x_ _S_e_g_m_e_n_t_s_ 6.2.1 The first few segments of the user catalog contain an index table in which word no. n describes the contents of segment no. n. A negative number means that the segment is part of the index table, while a positive number is a project number, which indicates that the last information on the corresponding segment concerns this project number. Unused words in the last part of the index table have the value 8388607 (the maximum positive integer). Furthermore the first word in the index table is used to store the total number of entries claimed by users and projects in the catalog (represented as a negative number). The end of the user catalog is signalled by a record of type 0 with project = 8388607. \f F_ 6_._2_._2_ _ _ _ _ _R_e_c_o_r_d_ _T_y_p_e_s_ _i_n_ _t_h_e_ _C_a_t_a_l_o_g_ 6.2.2 The two first halfwords of each record describe the type and the length of the record. Type 0 and type 2 records are special records. Type 0 describes projects and type 2 users within the projects. All common information and resources follows a type 0 record and all information concerning a user follows a type 2 record. Type 0 and type 2 records are mandatory in the catalog, all other types are optional. The following lists all the record types and for each type the meaning of each field (halfword or word) is described. Many of the records correspond to options in the job specification. These records may indicate either a standard value (if the type is specified as an even integer) or a maximum value (if the type is incremented by one (odd value)). Such record types are marked with an asterisk (*). type 0 project (input: type 1 and 10) +0 0, 12 +2 project number +4,6 project interval +8,9 rest entries, rest slices on disc +10,11 total entries, total slices on disc type 2 user (input: type 2 and 11) +0 2, 16 +2-8 user name (8 halfwords) +10 user interval start +12 standard interval length +14 number of user indices type 4 priority / late (input: type 7 (no longer used)) +0 4, 6 +2 standard value of priority +4 minimum value of late \f type 6 private disc kits (input: type 4) +0 6, 16 +2-8 device name (8 halfwords) +10,11 rest entries, rest slices +12,13 total entries, total slices +14 slice length *type 8 devicemask (input: 5, 6 device) +0 8*, 6 +2 first word with device bits +4 second word with device bits *type 10 accounts (input: 5, 6 accounts) +0 10*, 4 +2 number of account buffers *type 12 area processes (input: 5, 6 area) +0 12*, 4 +2 area claim *type 14 message buffer (input: 5,6 buf) +0 14*, 4 +2 buffer claim *type 16 convert operations (input: 5, 6 cbuf) +0 16*, 4 +2 internal claim *type 18 internal processes (input: 5, 6 internals) +0 18*, 4 +2 internal claim *type 20 keys (input: 5, 6 key) +0 20*, 4 +2 number of protection keys *type 22 mounts (input: 5, 6 mounts) +0 22*, 4 +2 number of mounts \f *type 24 output (input: 5, 6 output) +0 24*, 4 +2 number of slices in primary output *type 26 size (input: 5, 6 size) +0 26*, 4 +2 size of process (in halfwords) *type 28 stations (input: 5, 6 stations) +0 28*, 4 +2 number of standard tape stations *type 30 tapes (input: 5, 6 tapes) +0 30*, 4 +2 number of job controlled paper tapes *type 32 time (input: 5, 6 time) +0 32*, 4 +2 net run time (in units of 0.8192 secs.) type 34 user with userpool (input: type 9) +0 34, 10 +2,4 user max interval +6,7 rest entries, rest slices on disc +8,9 total entries, total slices on disc type 36 drum, key 1 (input: 5 temp drum) +0 36, 4 +2 temp drum entries, slices type 38 disc, key 1 (input: 5 temp disc) +0 38, 4 +2,3 temp disc entries, slices type 40 disc, key 3 (input: 5 perm disc) +0 40, 4 +2,3 perm disc entries, slices \f type 42 output identification (input: type 3) +0 42, variable length +2 text, max. 300 characters type 44 drum, key 3 (input: type 8) +0 44, 6 +2,3 rest entries, rest slices +4,5 total entries, total slices type 46 drum, key 3 (input: 5 perm drum) +0 46, 4 +2,3 perm drum entries, slices type 48 private disc kit (input: 5 perm <kitname') +0 48, 12 +2-8 device name (8 halfwords) +10,11 perm <kitname' entries, slices *type 50 max turn-around time (input: 5, 6 latest) +0 50*, 4 +2 latest (in units of 0.8192 secs.) type 52 information for accountjob (input: type 12) +0 52, 16 +2-14 project identification in textform (max. 20 chars). type 54 program (input: 5 program) +0 54, 10 +2-8 name of program to be loaded (8 halfwords) *type 56 available suspend buffers (input: 5, 6 suspends) +0 56*, 4 +2 suspendings *type 58 online (input: 5, 6 online) +0 58*, 4 +2 conversational jobs allowed (1) / not allowed (0) \f *type 60 corelock (input: 5, 6 corelock) +0 60*, 4 +2 corelock time *type 62 degree of information (input: 5, 6 minimal) +0 62*, 4 +2 minimal yes (1) / no (0) *type 64 priority (input: 5, 6 priority) +0 64*, 4 +2 start priority factor *type 66 deliberate waiting (input: 5, 6 wait) +0 66*, 4 +2 maximum wait time swopped out *type 68 catalog preservation (input: 5, 6 preserve) +0 68*, 4 +2 preserve yes (1) / no (0) *type 70 terminal user rights (input: 5, 6 privilege) +0 70*, 4 +2 privilege bits. 6_._3_ _ _ _ _ _ _ _H_o_w_ _t_o_ _C_r_e_a_t_e_ _a_n_d_ _U_p_d_a_t_e_ _t_h_e_ _U_s_e_r_ _C_a_t_a_l_o_g_ 6.3 This program, >catupdate>, is automatically translated whenever the coroutine files are translated (by means of the command >i bossbin>, cf. 1.2 and 4.1). At the same time a small binary file >boptions> will be created. >boptions> contains information concerning the installation (device numbers and backing storage devices), extracted from >options>. This information is read and used by >catupdate>. \f 6_._3_._1_ _ _ _ _ _S_y_n_t_a_x_ _f_o_r_ _t_h_e_ _C_a_l_l_ _o_f_ _>_c_a_t_u_p_d_a_t_e_>_ 6.3.1 M_m_m_ 1 1 on 1 1 <leftside'= catupdate cat.yes list. <input file' P_p_p_ 0 0 off 0 0 <leftside' ' ::= usercat / <filename' <input file' ::= <filename' / <mode kind' <filename' is a name with at most 11 characters. <modekind' :: = trf / tre / tro / crc / crd 6_._3_._2_ _ _ _ _ _E_x_p_l_a_n_a_t_i_o_n_ _o_f_ _P_a_r_a_m_e_t_e_r_s_ _t_o_ _>_c_a_t_u_p_d_a_t_e_>_ 6.3.2 <leftside' ::= usercat / <filename' <leftside' is the resulting user catalog produced by >catupdate>. BOSS assumes the user catalog to be on the file >usercat> and reserves this file when it is running. Therefore the user catalog must either be updated while BOSS is not running or the updating may take place under BOSS producing a user catalog in a different file and this other file may later be moved or renamed to >usercat>. If >catupdate> is called without <leftside' and without parame- ters the existing user catalog is listed in a crude form corre- sponding to the input format to >catupdate>. If this kind of listing is produced when BOSS has been running, it will show the current values of rest claims for backing storage resources. \f cat.yes If cat.yes is present it is assumed that the catalog is made from scratch, otherwise it is assumed that the input specifies changes to the already existing user catalog in the file >usercat>. M_m_m_ on list. P_p_p_ off list.on has the effect that the input to >catupdate> is listed as it is read. list.off no input is listed, this is used as default. <input file' The input file from which the new catalog is created. (The input format is described in later sections). The input file can for instance be the final output from an earlier run of >catupdate>. 6_._3_._3_ _ _ _ _ _I_m_p_l_e_m_e_n_t_a_t_i_o_n_ _o_f_ _S_u_b_c_a_t_a_l_o_g_s_ 6.3.3 To be able to make input to >catupdate> (i.e. to be able to make a user catalog), it is necessary to know how the hierarchy of subcatalogs are implemented. Each subcatalog is represented by a pair of integers denoting an interval. The subcatalog represented by (l,h) is contained in the subcatalog (l1,h1) if and only if l1 <_ l <_ h <_ h1. The biggest subcatalog is (-8388607, 8388605) all other catalogs are subcatalogs of this catalog. For further explanation see the Monitor3 manual. 6_._3_._4_ _ _ _ _ _I_n_p_u_t_ _t_o_ _C_a_t_u_p_d_a_t_e_ 6.3.4 The input in most cases consists of lines which specify a new record in the user catalog, a change of a record, or deletion of a record. Each line starts with a number specifying the record type. Spaces or tabulator separate the fields of the line. \f Comments may be inserted in parenthesis between the fields, or at the end of the line after a semicolon. The input lines must occur in a sequence corresponding to the records of the user catalog, thus: project head (type 1 or 10) project specifications (types 3 to 8, 12 and up) user head 1 (type 2 or 11) user specifications (types 3 to 9, 12 and up) user head 2 (type 2 or 11) user specifications (.....) ... end input (type -1) However, all sorting of projects and users within projects are done by the program. Below we show all possible line types. These lines may be composed into various input forms according to the needs of the staff. An example is shown later. If you always make your user catalog up from scratch, it is recommended n_o_t_ to use line types 1 or 2, because it will cause you troubles when adding (or removing) projects or users. Instead you should use line types 10 and 11. P_r_o_j_e_c_t_ _h_e_a_d_,_ _s_i_m_p_l_e_ Project new=0 permanent disc Project width number change=1 slices entries (omit at change) 1 \f This record may specify a new project and its permanent disc resources. The project number must be greater than 0 and less than 1000000 and the project catalog base is allocated automatically so that it does not overlap other projects (except maintenance projects). The width of the project catalog base is given in the last field. Normally, this should be 10 times the maximum number of users ever on this project. The width cannot be changed later. The record may also specify a change of the permanent disc resources of a project (fields contain the changes, + or -), possibly followed by changes specified by other records. P_r_o_j_e_c_t_ _h_e_a_d_,_ _a_b_s_ _b_a_s_e_ _o_r_ _d_e_l_e_t_i_o_n_ Project new=0 Permanent disc Project catalog base number delete=2 slices entries lower upper 10 This record may specify a new project and its permanent disc resources. The project number must be greater than 0 and less than 1000000. The project catalog base must be supplied as a pair of numbers. The record may also specify deletion of a project and all its users. In this case the disc resources are not used. For safety reasons, the catalog base must be specified. U_s_e_r_ _h_e_a_d_,_ _s_i_m_p_l_e_ optional User name Project new=0 job width No of user number change=1 indices 2 \f This record may specify a new user under the project. The user catalog base is allocated automatically so that it does not overlap other users of the project. The user catalog base will normally have a width of 10, allowing 10 user indices (10 jobs simultaneously from that user, independent of project). The standard base of the job will thus normally have a length of 1, but a larger width may be specified (job width). User name must be one small letter followed by at most 8 small letters or digits. Notice that if the name is longer than these 9 characters, >catupdate> truncates the name. The record may also announce a change of the user specifications. The two optional fields may n_o_t_ occur in this case. U_s_e_r_ _h_e_a_d_,_ _a_b_s_ _b_a_s_e_ _o_r_ _d_e_l_e_t_i_o_n_ User name Project new=0 Job width No. of user First of number delete=2 indices user base 11 This record may specify a new user under the project. The u_s_e_r_ c_a_t_a_l_o_g_ _b_a_s_e_ is specified by its absolute first point. The last point will be: first of user base + job width * no of user indices - 1. The s_t_a_n_d_a_r_d_ _b_a_s_e_ of a job will be: (first of user base + job width * user index, same + job width - 1). User name: see type 2 above. Notice, that when a job terminates, BOSS cancels all temporary files within the standard base. Thus the abs base should be used with extreme care, especially if other users have their standard base in the base specified, or if it includes the private base of BOSS (-8388606, -8388606). The record may also specify deletion of a user. For safety, the first point of the user base must be specified. \f O_u_t_p_u_t_ _i_d_e_n_t_i_f_i_c_a_t_i_o_n_ The record specifies a textstring terminated with semicolon. Max. 300 characters. This text will appear on all print files. Leading spaces on a line are skipped. Leading underlines (ISO-value 95) may be used as significant spaces. 3 ; This record and the following types may appear after a project head (common for all users of the project) or after a user head (this user only). P_r_i_v_a_t_e_ _k_i_t_s_ Kit name Slices Entries Segments in a slice 4 A job may only create areas on a kit (even temporary) if allowed by a private kit record. If this record is used after a user head, this user will not be able to use the project resources or change project files. <kit name' may not be >disc> or >drum>. S_t_a_n_d_a_r_d_ _v_a_l_u_e_ _o_f_ _o_p_t_i_o_n_ Option name Parameters. (nearly as in job specification, see below) 5 >Device no> clears all previous device options. All device options in a set of project specifications or user specifications are combined and replace previous device information in the user catalog. \f For the options >output>, >temp>, >perm> the parameter must be specified as number of slices. Number of temp entries should be specified at most once. (i.e. either in >temp drum> or >temp disc>, but not in both). It is a good idea always to specify a standard value for permanent resources, in order to take care of the problem mentioned in User>s manual for the perm-option. Standard values for >latest> and >priority> can be specified. Remember to change possible limit values of the options when a standard value is increased. L_i_m_i_t_ _v_a_l_u_e_ _o_f_ _o_p_t_i_o_n_ Option name Parameters. Upper limit. (nearly as in job specification, see below) 6 Specifies the upper limit for options in the job specification. >Device no> prevents the user from having any devices. He may be allowed to use specific devices by means of succeeding device options. All device options in a set of project specifications or user specifications are combined and replace previous device information in the user catalog. Limit value for >output> must be in slices. Limit value for >temp>, >perm>, and >program> cannot be specified. Limit value for >latest> and >priority> can be specified. The limit value for >latest> is a lower limit, while all other limits are upper limits. Notice, that >catupdate> does not check that the limit is consistent with the standard value or the actually available resources in the computer. \f D_r_u_m_ Permanent drum resources slices entries 8 U_s_e_r_ _p_o_o_l_,_ _n_o_ _p_r_o_j_e_c_t_ _r_i_g_h_t_ Permanent resources The user will have no right to on system disc change the project files, and will slices entries not be able to use the project 9 resources. Cannot occur in project specifications (i.e. between the project head and the first user head). A_c_c_o_u_n_t_i_n_g_ _i_n_f_o_r_m_a_t_i_o_n_ Further information for account job. Max. 20 characters. Terminate with semicolon. Leading spaces are skipped. Leading underlines (ISO-value 95) may be used as significant spaces. 12 ; E_n_d_ _o_f_ _u_s_e_r_ _o_r_ _p_r_o_j_e_c_t_ -1 6_._3_._5_ _ _ _ _ _E_x_a_m_p_l_e_ 6.3.5 Creation of a demonstration user catalog from scratch. ; BOSS demonstration user catalog 10 51 0 3 3 -8388607 -8388607 2 account 51 0 1 1 ; a project No 51 is created on the account catalog base ; with the single user account (see chapter 6) \f 10 1 0 125 50 900 999 5 perm disc 50 5 5 privilege 3 5 time 3 0 6 minimal yes 6 online yes 3 RC8000 demonstration; 11 usera 1 0 1 20 900 11 userb 1 0 1 20 920 11 userc 1 0 1 20 940 ; a new project 1 is created, it has 125 slices ; on the system disc and 50 entries in the ; catalog. The project catalog base is 900 to 999 ; the project contains three users: ; usera with standard base 900 ; userb - - - 920 ; userc - - - 940 ; The explanation of the options can be found in ; the User>s Manual. 10 2 0 50 10 1000 1020 5 time 5 0 6 online yes 6 corelock 60 5 size 100000 6 preserve yes 11 user d 2 0 1 10 1000 11 user e 2 0 1 10 1010 ; a project 2 is created with two users ; who may specify that they ; want temporary files to be ; preserved after a job -1 ; end of input. \f 6_._3_._6_ _ _ _ _ _E_r_r_o_r_m_e_s_s_a_g_e_s_ _f_r_o_m_ _>_c_a_t_u_p_d_a_t_e_>_ 6.3.6 case out of range in testvalues can be ignored. delete not allowed attempt to delete a userpool record which cannot be deleted delete wrong interval a deletion record tries to delete a project or user with a wrong project/user interval device unknown in the device option a name or a number of a device has been specified which is not present different slicelength on same kit a private kit is included with a slicelength which does not match an elsewhere given slicelength existing the record already exists, nothing has been done illegal abs interval the interval specified for a user is in conflict with the project interval illegal claims attempt to change claims to an illegal value illegal devicename disc and drum are reserved names and must not be used as a name of a private kit illegal linetype the linetype of an input record is greater than 12 or is less than -1 \f illegal projno the projectnumber is out of range (linetype 1 or 10) illegal parameter a wrong parameter has been read from an option illegal update identification parameter 2 must be 0 or 1 illegal update information should not appear max. value not allowed a maximum value is not allowed for this option number of params the number of parameters are out of range in a type 1 record number out of range one of the parameters in current record is an illegal number. option unknown an option specified in the input cannot be recognized, most likely because of a spelling error out of sequence illegal sequence of input record, most likely because a project- or user-record (type 1, 10, 2, or 11) was not accepted. parameter kind text where a number was excepted, or vice versa. privilege illegal the privilege class must be between 1 and 9 project unknown the project number stated does not exist. \f record unknown attempt to delete an unknown record std usercat index too small the number of segments used as indexsegments is too small. Catupdate must be changed temp not allowed on specified device only >temp disc ...> and >temp drum ...> is allowed the catupdate program must be corrected and recompiled with a greater intervaltable size selfexplanatory too few parameters on line a record has too few parameters, the linetype is neither 3 nor 12 too many parameters an input record has too many parameters too many priv kits it is tried to reserve too many private disckits (option dependent) updated the record has been updated user unknown attempt to change or delete a non existing user -1; end of catalog the input has been transformed to usercatalog records, or if catupdate cannot find an inputfile this message will appear \f 6_._4_ _ _ _ _ _ _ _L_i_s_t_i_n_g_ _o_f_ _U_s_e_r_ _C_a_t_a_l_o_g_ _(_>_u_s_e_r_o_u_t_>_)_ 6.4 When file 16 of the BOSS text tape is loaded (by >i tuserout> or the equivalent), an ALGOL program, >_u_s_e_r_o_u_t_>_, is produced on disc with user scope. When the program is called, it prints the current contents of usercat on current output. The program should be started on the accounting catalog base (see chapter 6). 6_._5_ _ _ _ _ _ _ _B_a_l_a_n_c_i_n_g_ _P_e_r_m_a_n_e_n_t_ _R_e_s_o_u_r_c_e_s_ _A_g_a_i_n_s_t_ _A_c_t_u_a_l_ _U_s_a_g_e_ 6.5 As explained in chapter 3, BOSS during start-up computes the restclaims for users and projects having claims on the kits mounted. This computation is repeated for each kit which is later mounted by means of the >kit>-command, so that BOSS at any time has full control over the resources: entries and slices on any kit. If BOSS detects an error in this accounting of resources one of the bossfaults 12, 17, 21, or 44 will result. To avoid these errors you should stick to the following rules: All resources occupied on backing storage should at any time be accounted for in the user catalog (do not let users make over- drafts). If you have processes running in parallel with BOSS, their bases must not overlap those of a user logged in or a running job. Do not try to transfer files between such processes and BOSS-jobs or BOSS-users (and vice versa), i.e. if a file is created under s while BOSS is running, then do not change its size or scope under BOSS (and vice versa). If you have projects or users with overlapping bases, preferably do not use them simultaneously. If you have to, then make sure to use >preserve yes>, but notice that >preserve yes> is only a way to s_u_p_p_r_e_s_s_ a bossfault which ought to occur. And notice that >preserve yes> does not work for a >login>, so do not log in under such a user or project. \f For reasons of a technical nature you should also observe the following rules, especially for entries. The commands finis, logout, save, scope or clear must not cause the total number of entries available for the job, the user, the project, or BOSS to pass the number 2047, i.e. either free entries must always be kept greater than 2047 or it must be kept lower than 2047. It is quite simple to fulfil this rule: Do not give the users many more entries, than they actually use, and adjust the size of the main catalog once in a while so that BOSS starts up with a reasonable number of entries, never more than about 1000. Changing the size of the main catalog goes like this, when you have determined the new size wanted, let>s say 197 segments: autoload the system * att -' s clearcat * att -' s maincat catalog 197 * att -' s oldcat The new size of the catalog must be a few segments greater than the old size (each new segment holds 15 entries). The old size is determined by: lookup catalog. The new size should not be divisible by 2 or 17, and the largest size allowed is 273. \f F_ 7_._ _ _ _ _ _ _ _ _H_O_W_ _T_O_ _H_A_N_D_L_E_ _A_ _B_O_S_S_ _F_A_U_L_T_ _S_I_T_U_A_T_I_O_N_ 7. If BOSS suddenly breaks down, because of an internal error in BOSS, a hardware fault, overbooked resources in the user catalog, or the like, it is important that the testoutput generated by BOSS, is saved for error documentation and correction. If the testoutput is generated on disc (the area bosstest) the fastest way to get restarted is: att s remove all boss run rename bosstest.testcopy bosstest = set 200 disc scope user bosstest bos Now the testoutput saved in the file >testcopy> may be moved to a tape or analyzed and printed by the program >last> (see 9.4.1) If the error is to be reported to RC Computer then please send the testtape or the printer listing together with the error report. \f 8_._ _ _ _ _ _ _ _ _B_O_S_S_ _F_A_U_L_T_ _E_R_R_O_R_ _C_O_D_E_S_ 8. The alarm message >boss fault> contains an error code giving a hint to the trouble. Error codes in the interval 1 to 9 originate from the coroutine file >central>, those in 10 to 19 from >jobstart>, and so on as specified below. Central: 1 Program interrupt (break) 2 Access count < 0 3 Hard error, virtual store 4 No room in core for pages (i116) 5 Start-up alarm (always preceded by an explanation, see 2.2) 6 No message buffers 7 Access counter problems 8 - - - 9 Jobstart: 10 Trouble creating swop area 11 Trouble modify internal 12 Trouble term bs, all claims transferred to job 13 - - - , alarm create job 14 Trouble remove entry, load alarms 15 Trouble set cat base, catproc 16 Trouble reserve process, catproc 17 Common trouble, catproc, not done 18 Trouble, catproc, selective clear 19 Trouble, catproc, claim exceeded \f Term1 and Term2: 20 BOSS closed normally by operator 21 Trouble after term bs, scope etc. 22 Trouble after prep access, save 23 Hard error termout, next job 24 Hard error termout, block size 25 Trouble term bs-adjust, logout 26 Trouble term bs-adjust, after transmit error 27 Trouble remove entry, at create output 28 Unknown error code, newjob 29 Jobstart: 30 Trouble remove primout 31 Trouble remove jobfile, kill 32 Trouble include user 33 34 Trouble request alarm 35 Trouble in catproc 36 37 38 39 Job: 40 Hard error primout, psjob i/o 41 FP not available, break and dump 42 Hard error catalog, clean catalog 43 Hard error primout, finis 44 Trouble after term bs, finis 45 Trouble after term bs-adjust, finis 46 Trouble after remove or adjust primout 47 Trouble after remove area process, finis 48 Illegal internal operation 49 Trouble adjust primout, finis \f Mount: 50 Trouble include/exclude user 51 Illegal state 52 Trouble include user, check action 53 Trouble initialize process, name 54 Request trouble, psjob mount 55 Request trouble, remoter 56 Illegal station table change 57 - - - - 58 Device number trouble 59 Illegal station table change Read: 60 Trouble reserving reader 61 62 63 64 65 Reader not device 0 66 Card reader error 67 68 69 Print: 70 Hard error in reading usercat 71 72 Primout does not exist or area does not exist 73 Date and time too long 74 Job controlled printing inconsistent 75 76 77 78 79 \f Procs: 80 Hard error, accountf1 81 Hard error usercat, output bsadjust 82 - - - , input bsadjust 83 - - - , init from usercat 84 Hard error catalog, unknown sender 85 - - - , - - 86 - - - , - - 87 Too many private kits 88 Trouble creating accountf1 89 Action from table outside limits, init from usercat Banker: 90 Trouble priority queue, lock in core fit 91 Hard error swopout 92 Convert feature, not implemented 93 Trouble priority queue, release 94 Trouble res queue, simulate release 95 Too many free stations 96 97 Reserve reader, not found 98 Release reader, not found 99 Assign resources, reader not found Term1 and term2: 100 Login attention during run 101 Login attention during logout 102 Trouble general print, integer size 103 - - - , buffer limit 104 - bs-adjust, snapshot 105 Page troubles, kitchange 106 Hard error usercat, kitchange 107 108 109 \f Mount: 110 Station table inconsistence 111 - - - 112 No station in searched state 113 114 115 116 117 118 119 Banker: 120 121 Job in core semaphore out of range 122 123 124 125 126 127 128 129 \f F_ 9_._ _ _ _ _ _ _ _ _T_E_S_T_O_U_T_P_U_T_ 9. The testoutput from BOSS consists of a sequence of variable- length, binary records stored in blocks of 512 halfwords. Output on magnetic tape is terminated by a tape mark (generated at close down). When output on backing store meets the end of the area, output continues in the first segment after the last type-14 record (see 9.1.14). The BOSS text tape contains an external ALGOL procedure >bossout> and a program >last> which are used for analysis of the testoutput and output. These are described in section 9.4. 9_._1_ _ _ _ _ _ _ _R_e_c_o_r_d_ _F_o_r_m_a_t_ 9.1 Each record consists of a head and a variable length tail. The head is always 3 words, except for type 0, where the length is only one word. head, word1: tail length shift 6 + type head, word2: time head, word3: >third> meaning various things. The tail length is given in halfwords. The time is given in units of 0.01 second from start-up of BOSS. T_y_p_e_ _0_,_ _n_e_x_t_ _b_l_o_c_k_ Shows that the remaining part of the block is unused. Tail length = 0. Notice that the head of this record is only one word. 9_._1_._1_ _ _ _ _ _T_y_p_e_ _1_,_ _s_e_n_d_ 9.1.1 Produced when the following Central Logic entries are called: send and wait, send and wait fast, send and wait slow, stop and wait, wait answer. \f Third = name table addr of receiver, tail length = 8. tail: first 4 words of message. Tail makes no sense for the entries >stop and wait> and >wait answer>. 9_._1_._2_ _ _ _ _ _T_y_p_e_ _2_,_ _l_o_c_k_ 9.1.2 Produced when CL entries lock or lock chained are called. Third = semaphore addr, tail length = 2 tail: semaphore value (before lock or lock chained). 9_._1_._3_ _ _ _ _ _T_y_p_e_ _3_,_ _o_p_c_h_ 9.1.3 Produced when open chained is called. Third = semaphore addr, tail length = 8 tail: semaphore value (before open chained), first 3 words of operation (omitting the chain word). 9_._1_._4_ _ _ _ _ _T_y_p_e_ _4_,_ _o_p_e_n_ 9.1.4 Produced when open is called. Third = semaphore addr, tail length = 2 tail: semaphore value (before open). 9_._1_._5_ _ _ _ _ _T_y_p_e_ _5_,_ _e_x_i_t_ 9.1.5 Produced when Central Logic exits to a coroutine after all wait operations, after lock, lock chained, open chained, get pages, page jump, clear core. But not after open. Third = coroutine ident (see 9.3), tail length = 18. tail: core (x1 to x1+4), 5 absolute addresses of the pages, codepage ident (see 9.2) shift 12 + exit address relative to page 0. \f Core (x1 to x1+4) contain the first 3 words of the answer after a wait operation, the first 3 words of the operation (including the chain word) after lock chained. It is possible to generate a BOSS version where the 5 absolute addresses are replaced by virtual addresses (option e8). 9_._1_._6_ _ _ _ _ _T_y_p_e_ _6_,_ _m_e_s_s_ 9.1.6 Produced when a message is received from a job or a terminal. The record is produced when the coroutine is ready to receive the message, and this may be much later than the first detection of the message. Third = coroutine ident, tail length = 8. tail: sender process description address, first 3 words of message. 9_._1_._7_ _ _ _ _ _T_y_p_e_ _7_,_ _a_n_s_w_ 9.1.7 The record is produced the first time CL detects the answer. Third = coroutine ident, tail length = 2. tail: result of wait answer. 9_._1_._8_ _ _ _ _ _T_y_p_e_ _8_,_ _j_d_-_1_ 9.1.8 Generated whenever a jd-1 is executed. Third = coroutine ident, tail length = 12. tail: w0, w1, w2, w3, exception, instruction counter On RC8000 >exception> is replaced with >status> (see RC8000 Reference Manual, subsection 2.2.1). \f 9_._1_._9_ _ _ _ _ _T_y_p_e_ _9_,_ _s_t_o_p_ 9.1.9 Generated at close down, which always corresponds to an internal interrupt (intended or unintended). Third = coroutine ident, tail length = 24. tail contains the dumped registers: RC8000 RC4000 tail (1): w0 - 2 : w1 - 3 : w2 - 4 : w3 - 5 : status exception 6 : ic - 7 : cause - 8 : addr 3440650 9 : 3440648 - 10 : -(bossfault code) - 11 : page 0 address - 12 : ident, rel - >status> and >exception> are explained in >RC8000 Reference Manual>, subsect. 2.2.1, where also >cause> is explained (subsect. 7.1). Bossfault code: see ch.8. Page 0 address and ident, rel are the same as in the last >exit> (cf. 9.1.5 and 9.2). \f F_ T_y_p_e_s_ _g_r_e_a_t_e_r_ _t_h_a_n_ _9_,_ _p_r_i_v_a_t_e_ _o_u_t_p_u_t_ may be produced by any coroutine. Present types are shown below. Third = coroutine ident, tail length = any value. tail: anything. 9_._1_._1_0_ _ _ _ _T_y_p_e_ _1_0_ 9.1.10 Tail contains banker>s description of a pseudo job. Four consecutive records are produced to describe a psjob. F_i_r_s_t_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _2_0_ tail(1): chain, chain ;priority or idle, resource or ;deadly. jobs may be in no ;chain. ;REST CLAIMS: tail(2): all, stations ;all: pattern showing if ;static resources should be ;included: 4: converts ; 2: account ; 1: other tail(3): entries, slices ;temp disc tail(4): std, remote ;readers ;STATIC RESOURCES: tail(5): converts, accounts ; tail(6): buf, area ; tail(7): internal, suspends ; tail(8): entries, slices ;temp drum tail(9): deviceword 1 ; tail (10): deviceword 2 ; S_e_c_o_n_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_2_ ;RESERVED RESOURCES: tail(1): all, stations ;all: see first record tail(2): entries, slices ;temp disc tail(3): std, remote ;readers \f ;WANTED RESOURCES: tail(4): all, stations ;all: see first record tail(5): entries, slices ;temp disc tail(6): std, remote ;readers T_h_i_r_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_6_ _ tail(1): first segm, top segm ;coreplace tail(2): 255- pr, priority ;protection, priority factor tail(3): gross run left ;units of 0.8192 secs. tail(4): net run left ;- - - - tail(5): arrival time ;- - - - tail(6): max. waiting ;- - - - tail(7): jobname(1) ;3 chars tail(8): jobname(2) ;3 chars F_o_u_r_t_h_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_4_ tail(1): jobname(3) ;3 chars tail(2): jobname(4) ;3 chars tail(3): virt. address ;answer or dump name tail(4): state, jobclass<1+corelock;state: ;0: skip (not in one of below ; states ;1: resources wanted ;2: core wanted (after start ; job operation) ;3: waiting (only account and ; convert) ;4: killed in skip state ;5: in no queue (onlinejob ; between runs) tail(5): time to time out ;units of 0.8192 secs tail(6): time to wait swopped out ;- - - - tail(7): expected finishing time ;- - - - \f 9_._1_._1_1_ _ _ _ _T_y_p_e_ _1_1_ 9.1.11 Five consecutive records produced by the banker. F_i_r_s_t_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _4_ tail(1): psjob rel. for a-job (0 means no job in that place tail(2): - - - b-job (0 - - - - - - N_e_x_t_ _f_o_u_r_ _r_e_c_o_r_d_s_,_ _a_l_l_ _w_i_t_h_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _3_0_ Currently free resources. All values given are one too high. One record is produced for each of the four job classes (0-3): ;DYNAMIC RESOURCES: tail(1) :free stations tail(2) :free temp disc (maincat) entries tail(3) :free temp disc slices tail(4) :free std readers tail(5) :free remote readers ;STATIC RESOURCES: tail(6) :free convert operations tail(7) :free account operations tail(8) :free mess bufs tail(9) :free area procs tail(10) :free intervals tail(11) :free suspends tail(12) :free temp drum entries (dummy) tail(13) :free temp drum slices tail(14) :free devices 1 tail(15) :free devices 2 9_._1_._1_2_ _ _ _ _T_y_p_e_ _1_2_ 9.1.12 This type is used for various purposes, see below. \f 9_._1_._1_2_._1_ _ _J_o_b_s_t_a_r_t_ 9.1.12.1 output of job description page, 23 records, tail length = 20 output of job file page, 23 records, tail length = 20 9_._1_._1_2_._2_ _ _J_o_b_ 9.1.12.2 On psjob finis page (page 46a) the part of job description page containing information about runtime left (d115+0 to d115+10) is output. 9_._1_._1_2_._3_ _ _P_r_o_c_s_ _T_e_s_t_o_u_t_p_u_t_ 9.1.12.3 2 or 3 records before and 1 or 3 records after all hostmessages. The format of the records is as shown below. F_i_r_s_t_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _2_2_ _h_w_,_ _c_a_l_l_ _p_a_r_a_m_e_t_e_r_s_: tail(1): absref message area tail(2): dev.name(1) tail(3): dev.name(2) tail(4): dev.name(3) tail(5): dev.name(4) tail(6): host no. ;logical deviceno. of jobhost tail(7): host id ;devicehost tail(8): mode<12+kind tail(9): timeout ;0: don>t wait ;<128: wait up to <value' min ;'=128: wait till you get it tail(10): catalog base (lower) tail(11): catalog base (upper) \f S_e_c_o_n_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _1_6_ _h_w_,_ _m_e_s_s_a_g_e_: tail(1): operation <12+function<1+addr.mode ;operation tail(1) = 4101: lookup process tail(1) = 4102: lookup device tail(1) = 4108: linkup remote tail(2): first addr. of data tail(3): last addr of data tail(4): linkno <12 + hostno. ;logical dev.no. in jobhost tail(5): hostid ;devicehost tail(6): dh. homereg<12+dh.netid. tail(7): (irrelevant) tail(8): (irrelevant) T_h_i_r_d_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _2_2_ _h_w_,_ _d_a_t_a_: (third record is not always present) tail(1) : mode <12 + kind tail(2) : timeout <12 + buffers tail(3) : buffersize ;halfwords tail(4) : devicename(1) tail(5) : devicename(2) tail(6) : devicename(3) tail(7) : devicename(4) tail(8) : (irrelevant) tail(9) : (irrelevant) tail(10): (irrelevant) tail(11): (irrelevant) F_o_u_r_t_h_ _r_e_c_o_r_d_,_ _1_6_ _b_y_t_e_s_,_ _a_n_s_w_e_r_: (only produced if monitor result = 1) tail(1): device status <16 + link descriptor <12 + function result ;device status: bit 0: device unknown - 1: device closed - 2: - 3: - 4: - 5: device driver not loaded - 6: device reserved by another process - 7: reservation rejected from AP (only GAC interface) \f ;link descriptor: (value) 0: no link (subprocess) present 1: remote link (subprocess) present 2: local link (subprocess) present ;function result: (value) -1: sender stopped 0: function executed 1: device troubles (see device status) 2: device reserved by other host 3: no resources at jobhost 4: no resources at devicehost 5: timeout 6: device requested with higher priority 7: some link was present (see link descriptor) 8: device host unknown tail(2): number of bytes in >data> tail(3): number of chars in >data> tail(4): dh. linkno <12 + hostno. tail(5): dh. hostid tail(6): dh. homereg <12 + dh. net-id tail(7): not used tail(8): not used F_i_f_t_h_ _r_e_c_o_r_d_,_ _2_2_ _b_y_t_e_s_,_ _d_a_t_a_: (only produced if monitor result = 1 and local link is not present) tail(1) : kind tail(2) : max. buffers tail(3) : max. buffersize chars tail(4) : name(1) tail(5) : name(2) tail(6) : name(3) tail(7) : name(4) tail(8) : jh. linkno. ;tail(8) - tail(11) are tail(9) : jh. hostid ; only relevant for tail(10): jh. homereg <12 + jh.netid ;>linkup remote> tail(11): process description address (subprocess) \f s_i_x_t_h_ _r_e_c_o_r_d_,_ _t_a_i_l_ _l_e_n_g_t_h_ _=_ _4_ _o_r_ _1_0_ _h_w_,_ _r_e_t_u_r_n_ _p_a_r_a_m_e_t_e_r_s_: tail(1) : name table address tail(2) : logical device no. tail(3) : device kind tail(4) : mode tail(5) : max. buffersize halfwords If >function> (cf. second record) was >lookup process> tail length will be 4 and tail(1) = tail(2) = 0. Otherwise the length will depend on the result. If everything was ok (no link was present before the call, and the link was created as requested), the sixth record will be as shown above. If something went wrong, tail length will be 4, tail(2) = 0 and tail(1) will be 0 or >process description address> (if the device was linked before). 9_._1_._1_3_ _ _ _ _T_y_p_e_ _1_3_ 9.1.13 Produced during start-up when a coroutine file is loaded. Tail contains: name of coroutine file (4 words), first of coroutine table, first of semaphore table, first of sender table, checksum, double sum, version date, version number. The record corresponding to >bos> contains BOSS start-up time instead of first of coroutine table, first of semaphore table and >load address for coroutine files> instead of >first of sender table>. The last two words contain first and last address of the BOSS process. \f 9_._1_._1_4_ _ _ _ _T_y_p_e_ _1_4_ 9.1.14 Produced during start-up after the first loader pass. Third=2*external number of first external in the record. Tail length=100. Tail contains the corresponding part of the external table. 9_._1_._1_5_ _ _ _ _T_y_p_e_ _1_5_ 9.1.15 Produced when command or jobstart has read a line. Tail contains the line. 9_._1_._1_6_ _ _ _ _T_y_p_e_ _1_6_ 9.1.16 Testoutput from bs-adjust. One record for each bs-device. Tail contains: entry claim (key 0), slice claim (key 0) ... entry claim (key 3), slice claim (key 3). 9_._1_._1_7_ _ _ _ _T_y_p_e_ _1_7_ 9.1.17 Produced when a catalog entry is removed (i.e. after jobtermination and after logout) and when a disckit is mounted. Tail contains the catalog entry. 9_._1_._1_8_ _ _ _ _T_y_p_e_ _1_8_ 9.1.18 Produced each time the mounter is activated. Tail contains an entry of the station table. (A closer description of the station table can be found on page 3 in the >mounter>). \f 9_._1_._1_9_ _ _ _ _T_y_p_e_ _1_9_ 9.1.19 Produced each time the mounter is activated. Tail contains an entry of the tape table. (A closer description of the tape table can be found on page 3 in the >mounter>). 9_._1_._2_0_ _ _ _ _T_y_p_e_ _2_0_ 9.1.20 Generated when Central Logic entries prepare _access or terminate _ access are called. Tail contains: nametable address of area process, 1 or -1 (depending on prepare _access or terminate _access), access count, interval of entry, name of entry. 9_._1_._2_1_ _ _ _ _T_y_p_e_ _2_1_ 9.1.21 Area process description (see the Monitor 3 manual). 9_._1_._2_2_ _ _ _ _T_y_p_e_ _2_2_ 9.1.22 Produced immediately before the stoprecord (9.1.9) at close down. Tail contains i205 (options page 6, bottom) hw of the code ending with ic-2 (the instruction causing the interrupt). i205 is adjusted so that 20<= i205<=120. 9_._2_ _ _ _ _ _ _ _C_o_d_e_p_a_g_e_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_s_ The codepage identifications used in testoutput records type 5 (see 9.1.5) and type 9 (see 9.1.9) are shown below. \f 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_ 20: command input 21: commandio bulk file 22: command print 23: snapshot, autoline t_j_o_b_ 40: psjob i/o 41: psjob aux 42: psjob break 43: clean catalog 44: psjob finis t_m_o_u_n_t_ 50: psmount 52: remoter 54: rewinder 56: watchdog 58: commandio, name, label t_r_e_a_d_ 60: tape reader 61: card reader 62: start card 63: pstape 64: pscard 65: psload \f t_p_r_i_n_t_e_r_ 70: paper description 71: central page 72: triangle page 73: main loop t_p_r_o_c_s_ 80: account 81: bsadjust 82: init from usercat 83: unknown sender 84: various procedures for remote devices t_b_a_n_k_e_r_ 90: main banker 91: core allocation 92: resource allocation t_t_e_r_m_ _2_ 100: kill 101: go, run, job, newjob 102: rename, clear, scope 103: login, get, save 104: transmit 105: display 106: kit changer 107: term out 108: request display 9_._3_ _ _ _ _ _ _ _C_o_r_o_u_t_i_n_e_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_s_ 9.3 The coroutines are identified as follows in the testoutput. We also show the coroutine file which generates the coroutine. \f 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) 200* psjobs (jobstart) 300* termouts (term2) 400* card readers (reader) 450* readers (reader) * as many as there are incarnations, numbered consecutively. 9_._4_ _ _ _ _ _ _ _S_e_l_e_c_t_e_d_ _T_e_s_t_o_u_t_p_u_t_ 9.4 Testoutput is always produced during the initialization. Testoutput is not produced during the run if BOSS has been translated with e9=0. e9 is an option, which is defined in >options> on page 5, together with other options which may be used to select testoutput independently for each coroutine type. The operator may change the selection of testoutput dynamically by means of the >test> command (see Operator>s Manual). The value of e9 is regarded by the system as 3 bits. The bit with value 1 means output from Central Logic and jd-1 (type 1 to 9). the bit with value 2 selects type 10 and 15 output, the bit value 4 selects type 11 output. Type 13 and 14 output is always produced. \f When e9<'0 but no testoutput medium is available, the records are still produced in the testoutput buffer. 9_._5_ _ _ _ _ _ _ _A_n_a_l_y_s_i_s_ _o_f_ _T_e_s_t_o_u_t_p_u_t_ 9.5 When file 17 of the BOSS text tape is loaded (by >i testout> or the equivalent), an external ALGOL procedure, b_o_s_s_o_u_t_, and an ALGOL program, l_a_s_t_, are produced. They are generated on disc with user scope. 9_._5_._1_ _ _ _ _ _L_a_s_t_ 9.5.1 The program, last, prints selected parts of a testoutput file in readable form on current output. The call is: M_m_m_ 1 1 1 last <doc'.<file' .<blocks' <s'<first'.<last' <s'<anything' P_p_p_ 0 0 0 <doc' is the name of the magtape or the backing store file holding the testoutput. <file' is the file numer or >bs> meaning backing store file. <blocks' is the number of testoutput blocks to be printed counted from the end of the testoutput, as the latest blocks are usually most interesting after a break down. If <blocks' is omitted, all blocks are printed. <first '.<last' selects an interval of coroutine identifications for printing. <anything' Anything obeying the syntax for FP-parameters. The rest of the line is just copied to the testoutput and can be used for identification purposes The identification records (type 13) are always printed in order to verify the BOSS version used. \f E_x_a_m_p_l_e_: The normal call will be: last bosstest.bs. The following call prints only testoutput from commandios in the last 10 blocks. last bosstest.bs.10 100.150 maintenance manual testoutput The output may look like the following illustration: \f F_ 9_._5_._2_ _ _ _ _ _B_o_s_s_o_u_t_ 9.5.2 This procedure assumes that the program has been called in this way (see 9.5.1): M_m_m_ 1 <program' <doc'.<file' .<blocks' <possible further parameters' P_p_p_ 0 The procedure is called like this: bossout(type, time, coruno, third, record, move, print) It scans the testoutput in the file specified and in the last <blocks' blocks. If <blocks' is omitted, the whole file is scanned. Each time it gets a record, it assigns the type, time, coroutine identification, and >third> to the first four parameters (integers), and assigns the length of the record (in bytes) to record(0). Then it interrogates the parameter >move> (boolean, Jensen>s device) to determine if the record should be moved into the integer array >record> from index 1 and on (moves when true). Finally the last parameter, >print> (boolean, Jensen device), is interrogated. When the parameter is true, the record is printed. (The stop record (type 9) and the identification records (type 13) are always printed). E_x_a_m_p_l_e_: In order to print all events from time 300 (seconds) to 400 after start-up of BOSS, proceed as follows: pr = algol begin integer k,t,c,th; integer array record(0:0); bossout (k,t,c,th,record,false, 300 00 <= t and t <=400 00); end pr bosstest1.bs \f E_x_a_m_p_l_e_: If you want to examine the records yourself (e.g. making statistics on free resources), then make use of the >move> parameter: pr = algol begin integer k,t,c,th; integer array record (0:256); boolean procedure statistic; begin integer field i; if k=11 and record (0) ' 4 then begin for i:=2 step 2 until record (0) do ... statistics ... on record.i end; if k=9 then ... terminate statistics ... statistic:=false; end; bossout (k,t,c,th,record,true,statistic); end; pr bosstape.3 \f i T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 1. GENERAL ............................................... 1 2. LOGIC SPECIFICATION ................................... 2 2.1 Data Formats ..................................... 2 2.2 Memory Addressing ................................ 3 2.3 I/O Addressing ................................... 5 2.4 Interface Control ................................ 5 2.5 Interrupt ........................................ 5 2.5.1 RC3502 Interrupts ......................... 6 2.5.2 MB Interrupts ............................. 7 2.5.3 Interrupt Masks ........................... 7 2.5.4 Bus Vectored Interrupts ................... 7 2.6 Initialization ................................... 8 2.7 Read Switch-Setting .............................. 8 2.8 Bus Reservation .................................. 8 \f ii \f F_ 1_._ _ _ _ _ _ _ _ _G_E_N_E_R_A_L_ 1. The RC3502 to Multibus interface provides a means for RC3502 as a master to handle all units that may be installed in an attached Multibus crate. This may include memory device controllers, other interfaces, and other masters. One RC3502 may have only one Multibus (MB hereafter called) attached, and it regards the MB-address space as a part of its own. Hence accesses to the MB is made as normal memory accesses. Yet the accesstime to Multibus memory (or units) will occupy approximately twice the time for access to privat memory. This consideration does not apply to the dual port memory provided with the interface. Physically the interface as seen on fig. 1 consists of two printed circuitboards interconnected by means of a flatcable. Figure 1: Outlines of the interface. \f F_ 2_._ _ _ _ _ _ _ _ _L_O_G_I_C_ _S_P_E_C_I_F_I_C_A_T_I_O_N_ 2. The interface includes the MB as a part of the RC3502 memory address space. Contrarily it does not enable access from the MB to the memory situated in the RC3502 crate. 2_._1_ _ _ _ _ _ _ _D_a_t_a_ _F_o_r_m_a_t_s_ 2.1 Byte- or word-addressing from the RC3502 will correspondingly result in byte- or word-addressing on the MB. Caution should be taken that not all units or memory areas installed in the MB are wordwide; this means that word-addressing of such units or areas will result in single-byte-accesses without any indication of this fault. Also it should be noted that 16 bit numbers in the MB in contrast to RC3502 are organized as A + 256 * B, where the address of B is the address of A plus one. In RC3502 the organization is 256 * A + B (see fig. 2). RC3502 p: A p+1: B Bit: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Multibus q+1: B q: A Bit: F E D C B A 9 8 4 6 5 4 3 2 1 0 order of increasing significance p and q are even addresses Figure 2: Word formats for RC3502 and Multibus. \f The bit to bit correspondance between the busses as established by the interface is shown in fig. 3. RC3502 p: A p+1: B Bit 0 - 7 8 - 15 Multibus q: A q+1: B Bit 7 - 0 F 8 Figure 3: Transfer format. Single bytes are transferred on buslines 8-15 on RC3502 and on 7-0 on MB. 2_._2_ _ _ _ _ _ _ _M_e_m_o_r_y_ _A_d_d_r_e_s_s_i_n_g_ 2.2 Neither the RC3502 CPU nor its DMA-controllers can see any difference between memory directly inserted in the RC3502-crate and memory locations on the MB, so the controlling software has to be aware of the actual configuration in order to handle the different areas correctly. As illustrated in fig. 3 the total addressspace (1M bytes) is divided into several areas with different characteristics. The first area ranging from loc. 00000 to P0000-1 is privat memory to RC3502. This mamory is physically located in the RC3502 crate, and is not accessible from the MB. The hexadecimal digit P is definable by means of a selector located on the A-board. The RC3502 CPU has an extended address range of 2M bytes the upper half of which is intended for ROM-addressing. The interface does not respond to addressing in this area, so all addresses in this paper imply a leading zero. The interface will respond to RC3502 initiated addressing from loc. P0000 to FFFFF (Hex). \f F_ 8 bits 00000: Privat area P0000-1: P0000: MM000: Multibus 32K bytes DUAL memory MMFFF: Access area F0000: Multibus I/O area FFFF0: FFFFF: Special area (privat) Special area: FFFF0: ITRIE 1 ITROE 2 INTRO 3 INTA 4 INIT 5 RESERVE BUS 6 DERES. BUS 7 8 9 A B C D E MM Read switch-setting FFFFF P Figure 4: Layout of address space. \f F_ The B-board acts as a master on the MB, and addresses the MB controlled by the A-board. The B-board also contains a dual port memory of 32K bytes accessible directly from both the A-board (not occupying the MB) and the MB. The only difference between this memory (which is 16 bit wide) and other memory installed on the MB, is that access from RC3502 to this particular area is faster than access to other memory on the MB. As seen from fig. 4 the address of this area is configurable by means of a selector on the B-board. The number MM places the first dual port memory-byte on a 32K boundary. 2_._3_ _ _ _ _ _ _ _I_/_O_ _A_d_d_r_e_s_s_i_n_g_ 2.3 The addresses F000 to FFFFF (Hex) are used by RC3502 for I/O addressing on MB. The I/O address space on MB uses only 16 address bits, and is accessed by "IOREAD" and "IOWRITE" pulses instead of "MEMREAD" and "MEMWRITE". 2_._4_ _ _ _ _ _ _ _I_n_t_e_r_f_a_c_e_ _C_o_n_t_r_o_l_ 2.4 The addresses from FFFF0 to FFFFF are used for interface control as shown in fig. 3. 2_._5_ _ _ _ _ _ _ _I_n_t_e_r_r_u_p_t_ 2.5 In this section two classes of interrupt are discussed: a: Interrupts on the RC3502 bus, directed from the IF towards the CPU. b: Interrupts occurring on the MB-INTR-lines. Class b interrupts imply class a interrupts, if enabling is done explicitly by the RC3502. \f Class b interrupts may be set by the RC3502 to synchronize other masters on the MB. The clearing of such interrupts by other masters on the MB may result in a corresponding class a interrupt, if allowed by a special mask set by the RC3502 CPU. 2_._5_._1_ _ _ _ _ _R_C_3_5_0_2_ _I_n_t_e_r_r_u_p_t_s_ 2.5.1 The eight INTR lines on the MB are connected to eight of the RC3502 interruptlevels in the following way: MB INTR-line RC3502 IR level Highest priority: INTR (0) - IRL (irb+7) INTR (1) - IRL (irb+6) INTR (2) - IRL (irb+5) INTR (3) - IRL (irb+4) INTR (4) - IRL (irb+3) INTR (5) - IRL (irb+2) INTR (6) - IRL (irb+1) Lowest priority: INTR (7) - IRL (irb+0) Generally: INTR (irno)- IRL (irb+7-irno) where irb is an integer multiple of 8, set on a set of switches on the A-boards and irno is in the range 0-7. The class a interrupts are controlled by two masks InTerRupt In Enable and InTerRupt Out Enable. If the ITRIE (irno)-bit is set then INTR (irno) will set IRL (irb+7-irno). If the ITROE (irno)-bit is set, IRL (irb+7-irno) is set when INTRO (irno) - (see next subsection) is cleared. If the IRIM-bit is set too the IRL is set already when the INTRO is set. If both ITROE (irno) and ITRIE (irno) are false, IRL (irb+7-irno) cannot be set as function of any MB-actions. All ITRIE- and ITROE-bits are initially false. The class a interrupts can be set and cleared by the RC3502 CPU using SET interrupt and CLEAR interrupt on the corresponding device no. (irb+7-irno). \f 2_._5_._2_ _ _ _ _ _M_B_ _I_n_t_e_r_r_u_p_t_s_ 2.5.2 The class b interrupts set the RC3502 interrupt levels as described above. RC3502 is able to set the class b interrupt in order to communicate with other masters on the Multibus. The interrupt signal once set by RC3502 is not cleared until so done by another master or an INIT signal. If the ITROE bit is on, the clear action will set the corresponding class a interrupt. The eight signals INTRO (irno) are cleared by other masters by an I/O-write (devno+irno), where devno is a switch-selectable number equalling an integer multiple of 8. The class b interrupt INTRO (irno) is controlled by the RC3502 CPU by writing the value irno in the byte "INTRO" (address FFFF2). 2_._5_._3_ _ _ _ _ _I_n_t_e_r_r_u_p_t_ _M_a_s_k_s_ 2.5.3 The interrupt masks ITRIE and ITROE are controlled from the RC3502 CPU by writing into the corresponding bytes (addresses FFFF0 and FFFF1). The bits are set and cleared individually. The value to write into the control byte is 128 * new bit value + irno. 2_._5_._4_ _ _ _ _ _B_u_s_ _V_e_c_t_o_r_e_d_ _I_n_t_e_r_r_u_p_t_s_ 2.5.4 The interrupts on the MB may be of Bus Vectored or Non Bus vectored kind. The mixture of BVI and NBI is a matter of configuration, different devices supply different kinds of interrupt. \f As contrast to the NBI the BVI requires additional information (interrupt vector) transferred via the bus lines, as response on INTA from the master. The NBIs are supported directly. The INTAs necessary for supporting the BVIs are generated by reading the INTA byte (address FFFF3), and the MB contents as result of the INTA are transferred to the RC3502 CPU during this read. 2_._6_ _ _ _ _ _ _ _I_n_i_t_i_a_l_i_z_a_t_i_o_n_ 2.6 The MB has an INIT signal, which - when activated - resets the entire system to a known initial state. The RC3502 has a RESET signal with almost the same function. Through the interface, the INIT signal withdraws the RESET signal, and not reversely. The RC3502 may generate an INIT on the MB by writing in the INIT byte (FFFF4). This blocks the depency between INIT and RESET, until INIT is inactive again, preventing the CPU from resetting itself. The generated INIT pulse has a duration of at most 10 milli- seconds. 2_._7_ _ _ _ _ _ _ _R_e_a_d_ _S_w_i_t_c_h_-_S_e_t_t_i_n_g_ 2.7 The setting of the switches P and MM as described in section 2.2 are readable on the addresses FFFFE and FFFFF respectively. 2_._8_ _ _ _ _ _ _ _B_u_s_ _R_e_s_e_r_v_a_t_i_o_n_ 2.8 The RC3502 CPU may need to reserve the MB (lock other masters out), for execution of indivisible operations such as test and set. \f This is done by writing location FFFF5. Dereservation is done by writing location FFFF5. Reservation periods should be kept as short as possible. \f F_ \f «eof»