|
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: 145536 (0x23880) Types: TextFile Names: »D84«
└─⟦e634bf8f4⟧ Bits:30005867/disk11.imd Dokumenter (RCSL m.m.) └─⟦this⟧ »D84«
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 1. INTRODUCTION ....................................... 1 1.1 Bus Request Procedure ........................ 1 1.2 Bus Communication ............................ 3 2. ADDRESS FORMATS .................................... 6 3. DATA FORMAT ........................................ 7 4. CONTROL SIGNALS .................................... 8 4.1 Bus Control Signals .......................... 8 4.1.1 Bus Request .......................... 8 4.1.2 Select Out/Common Select ............. 8 4.1.3 Select Acknowledge ................... 9 4.1.4 Bus Busy ............................. 9 4.2 Bus Communication Signals .................... 15 4.2.1 DATA READY ........................... 15 4.2.2 DATA ACKNOWLEDGE ..................... 15 4.2.3 DATA NOT ACKNOWLEDGE ................. 16 4.2.4 DATA OUT ............................. 16 4.3 Miscellaneous Control Signals ................ 24 4.3.1 SYSTEM RESET ......................... 24 5. CONTROLLER REGISTERS ............................... 25 5.1 Current Status Register ...................... 27 5.1.1 Compulsory Status Bist in Current Status Register ...................... 27 5.1.2 Recommended Status Bits in Current Status Register ...................... 27 5.1.3 Device Dependent Status Bits in Current Status Register .............. 28 5.2 Event Status Register ........................ 28 5.2.1 Compulsory Status Bits in Event Status Register ...................... 29 5.2.2 Recommended Status Signals in Event Status Register ...................... 29 \f T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _(_C_O_N_T_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_ 5.2.3 Device Dependent Status in Event Status Register ...................... 30 6. INTERRUPT GENERATION ............................... 33 6.1 Interrupt Generating Status Bits ............. 33 7. RC8000 BUS CHARACTERISTICS ......................... 34 7.1 Bus Transmission Cable ....................... 34 7.2 Bus Length ................................... 40 7.3 Bus Signal Levels ............................ 40 7.4 Transceiver .................................. 43 \f 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_._ 1. The RC8000 bus is a single bus, which is shared by all units (CPU, memory modules and pheripherals). This type of bus is named a unified bus. unified bus _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CPU MEMORY I/O DEVICE I/O DEVICE _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Fig. 1.1 The communication between devices connected to the bus is exe- cuted in a master - slave relationship. Since the bus is shared among different units only one device has control over the bus during any bus operation. The device currently controlling the bus is called the bus master. The device which is communicating with the bus master is called the slave. 1_._1_ _ _ _ _ _ _ _B_u_s_ _R_e_q_u_e_s_t_ _P_r_o_c_e_d_u_r_e_._ 1.1 The bus master obtains control over the bus via a centralized bus control unit called the bus control unit (BCU). The bus master is selected by means of a daisy changing method. Refer to fig. 1.2. \f Fig. 1.2 \f To give for instance CPU>s a fast access to the bus, the BCU is designed with two daisy chains of which one is primarily used for CPU>s and the other for I/O devices. A device which is capable of becoming a bus master asserts the bus request signal to the BCU. The BCU responds to the bus re- quest by asserting the signals select out and common select. The select out signal is daisy chained through the units. Each unit on the select out line passes the signal, unless it has requested bus control. The first unit which has the bus request signal as- serted, breaks the chain and responds to the select out signal by asserting the select acknowledge signal and clearing its bus re- quest signal. The BCU upon receiving the select aknowledge signal drops the select out and common select signals. The common select signals speeds up the termination of the bus request procedure, because it operates on all units in parallel. The selected unit which becomes the new bus master asserts the bus busy signal at the end of the possible current data transfer. The above descri- bed selection procedure occurs at the same time as the current bus master uses the bus. This increases the effective transfer with a factor of approximately. 1_._2_ _ _ _ _ _ _ _B_u_s_ _C_o_m_m_u_n_i_c_a_t_i_o_n_._ 1.2 The RC8000 bus utilizes the asynchronous interlocked technique. Each control signal send from the master must be aknowlegded by a respond from the slave to complete the transfer. This makes the communication independent of the bus length and the master/slave response times. The transfer rate in the bus is one 24-bit word every 400 ns. Fig. 1.3 illustrates the request/aknowledge hand- shake technique. \f Fig. 1.3 The slave must delay the data ready signal to compensate for max. cable and bus transceiver skew. In addition to this, the slave must also compensate for its internal propagation delays. The RC8000 bus uses seperate data and address bus lines. The bus lines are bidirectional. In some I/O devices it is possible to address registers in the device semilar to memory words. For ex- ample, control functions in a device may be executed by addres- sing a register in the device and transferring data to this re- gister. The individual bits within the register causes the wanted control operation to occur. Status conditions within the device may be checked by addressing of the device status registers and transfer the data from device to memory. Once the status is stored in the memory, they can be checked by the CPU. Some devices operates by means of channel programs. Operations are initiated by means of a CPU output operation, which starts the device. Once started, the device fetches its commands in a channel program stored in the memory and executes the commands without the engagement of the CPU. Direct memory access in conjunction with the RC8000 bus is fairly simple since any device which has the capability to become a bus master can transfer data directly to and from memory. A current bus master interrupts a CPU on the bus by addressing a specific\f register in the CPU and transferring the device interrupt level number to this register. A device electrically nearer the BCU has a higher priority than a device further away. \f 2_._ _ _ _ _ _ _ _ _A_D_D_R_E_S_S_ _F_O_R_M_A_T_S_._ 2. The addres lines are common to all devices connected to the RC8000 bus (memory unit incl.). A memory address is always posi- tive, i.e. bit 0 equal 0. An I/O address is always negative, i.e. bit 0 equal 1. The address format permits addressing in up to 8 388 608 24-bits words. The 24 address lines shall be interpreted as follows: bit 0 : indicates memory or I/O addressing. bit 1-22: memory or I/O address. bit 23 : parity bit, which makes the number of ones in bit 0-22 odd. _0_ _ _1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _2_2_ _ _2_3_ _ _ _ _ _ _ _ _M_E_M_O_R_Y_ _O_R_ _I_/_O_ _A_D_D_R_E_S_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_ _ _ 0: memory address 1: I/O address parity Fig. 2.1 Addressing Format \f 3_._ _ _ _ _ _ _ _ _D_A_T_A_ _F_O_R_M_A_T_._ 3. _0_ _ _ _ _ _ _ _ _ _ _7_ _8_ _ _ _ _ _ _ _ _ _ _1_5_ _1_6_ _ _ _ _ _ _ _ _ _ _2_3_ _2_4_ _ _ _ _ _2_6_ _ _ _ _ _ _C_H_A_R_._1_ _ _ _ _ _ _ _C_H_A_R_._2_ _ _ _ _ _ _ _ _ _C_H_A_R_._3_ _ _ _ _ _ _ _ _ _P_ _ _ _ _ _ _ Fig. 3.1 Data Format The RC8000 uses 27 bidirectional data lines. The data lines are common to all devices connected to the bus. A word may be divided into three 8-bit characters with 1 parity bit per character. D 0-7 : data character 1 D 8-15 : data character 2 D 16-23 : data character 3 D 24 : parity bit, character 1 D 25 : parity bit, character 2 D 26 : parity bit, character 3 Odd parity is used. \f 4_._ _ _ _ _ _ _ _ _C_O_N_T_R_O_L_ _S_I_G_N_A_L_S_._ 4. Three types of control signals are used in connection with the RC8000 bus, i.e: 1: Control signals used to obtain control of the bus. These signals are named the bus control signals. 2: Control signals used during the transfer of data. These signals are called the bus communication signals. 3: Miscellaneous control signals. These signals are used during initial start of controllers and during power failure sequences. 4_._1_ _ _ _ _ _ _ _B_u_s_ _C_o_n_t_r_o_l_ _S_i_g_n_a_l_s_._ 4.1 5 bus control signals are used to execute the bus request proce- dure, i.e: B_US R_E_Q_UEST BREQ S_E_L_ECT O_U_T_ SELOUT C_OMMON S_E_L_ECT CSEL S_ELECT A_C_K_NOWLEDGE SACK B_US B_US_Y_ BBSY 4_._1_._1_ _ _ _ _ _B_u_s_ _R_e_q_u_e_s_t_._ 4.1.1 This signal is used by the controllers to request control over the bus. 4_._1_._2_ _ _ _ _ _S_e_l_e_c_t_ _O_u_t_/_C_o_m_m_o_n_ _S_e_l_e_c_t_._ 4.1.2 These signals are generated by the bus control unit as a respond to a bus request. The select out signal is daisy chained through all controllers connected to the bus. A controller which has not\f requested bus control passes the signal to the next controller on the select line. A controller which has requested bus control breaks the chain and responds to the select signal by asserting the select acknowledge signal. The common select signal is lead to all controllers in parallel. A device must delay the select out signal 30 nS before the sig- nal is used by the device, this assures that only one controller is selected as bus master. The select signals are cleared simul- taneously. By and -ing of these signals in the controllers, the termination of the bus request procedure can be made as fast as possible, since the trailing edge of the select out signal in this way do not need to ripple through the units. 4_._1_._3_ _ _ _ _ _S_e_l_e_c_t_ _A_c_k_n_o_w_l_e_g_d_e_._ 4.1.3 This signal is set to logical 1 by the controller as a respond to the select out and the common select signals. When the bus con- trol unit receives a select acknowledge signal, it clears the se- lect signals. If a select acknowledge signal is not received within a certain time, the bus control unit generates a timeout signal, which automatically clears the bus select and common se- lect signal. After a short delay, the bus control unit again checkes the state of the bus request signal and if it is still asserted, a new select procedure is initiated. The select acknow- ledge signal being logical 1 inhibits the start of a new select procedure. The select acknowledge signal is cleared by the re- questing controller when it obtains control over the bus. 4_._1_._4_ _ _ _ _ _B_u_s_ _B_u_s_y_._ 4.1.4 The bus busy signal is set to logical 1 by the controller when it becomes bus master. The signal indicates to other controllers that the bus is being used. The signal is only asserted when the following conditions are satisfied: \f 1. Select acknowledge = "1" 2. Select in = "0" 3. BUS BUSY = "0" 4. DATA ACKNOWLEDGE and DATA NOT ACKNOWLEDGE = "0" Condition 1 indicates that the controller has received the select signals correctly. Condition 2 indicates that the BCU has recei- ved the select acknowledge signal. Condition 3 and 4 indicates that the previous bus master has released the bus. The bus busy signal is cleared when the controller has terminated its bus transfer. The use of the bus control signals are illustrated by means of the timing chart fig. 4.2 and 4.3. An example of bus request logic used in a device which is capable of being a bus master is found in section 8.0. 1. A controller needs control of the bus and asserts BUS.REQ. 2. The BCU receives a BUS.REQ signal. If SEL.ACK is cleared, the BCU responds to the BUS.REQ by asserting the COM.SEL and SEL.OUT signals. 3. Each controller on the SEL.OUT line passes the SEL.OUT signal unless it has requested bus control. The first controller which has BUS.REQ asserted becomes selected and responds to the COM.SEL and SEL.OUT signals by asserting the SEL.ACK sig- nal, blocking the SEL.OUT signal to following controllers and clearing its BUS.REQ. Before using the SEL.OUT signal the con- troller must delay (filter) the SEL.OUT signal app. 30 nS, this assures that only one controller is selected as bus mas- ter. \f 4. The current bus master, when finished with the bus cleares BUS BUSY. 5. The BCU receives SEL.ACK signal and cleares COM.SEL and SEL.OUT. If a SEL.ACK signal is not received within a ceratin time, time-out occures and SEL.OUT, COM.SEL will be automati- cally cleared by BCU. 6. The selected controller, which becomes the new bus master, re- ceives cleared SEL.OUT and provided DATA ACK, DATA NACK and BUS BUSY from the presious bus transfer are all logical 0, the controller asserts BUS BUSY and cleares SEL.ACK. 7. The BCU receives SEL.ACK and a new bus request procedure can start. \f Fig. 4.1 Bus Request Procedure \f Fig. 4.2 BUS CONTROL UNIT (Control Sequence) FLOW CHART \f Fig. 4.3 CONTROLLER SEQUENCE for BUS MASTER SECTION \f 4_._2_ _ _ _ _ _ _ _B_u_s_ _C_o_m_m_u_n_i_c_a_t_i_o_n_ _S_i_g_n_a_l_s_._ 4.2 4. bus communication signals are used during the transfer of add- ress and data between master and slave connected to the RC8000 bus: D_A_T_A_ R_EAD_Y_ DATA RDY D_A_T_A_ A_C_K_NOWLEDGE DATA ACK D_A_T_A_ N_OT A_C_K_N_O_W_L_E_D_G_E_ DATA NACK D_A_T_A_ O_U_T_ DATA OUT 4_._2_._1_ _ _ _ _ _D_A_T_A_ _R_E_A_D_Y_._ 4.2.1 The DATA RDY signal is generated by the master when a data trans- fer is wanted. During data out instructions this signal gates address and data to the RC8000 bus, and during data in instruc- tions, the signal gates address to the bus. 4_._2_._2_ _ _ _ _ _D_A_T_A_ _A_C_K_N_O_W_L_E_D_G_E_._ 4.2.2 DATA ACK is the acknowledging response to DATA RDY indicating: 1. Address has been recognized by the slave. 2. The function requested by the DATA OUT has been executed, i.e Data has been correctly received (no parity error) or data has been places on the bus lines. During data out instructions (transfer of data from master to slave) the slave must delay the DATA RDY signal to compensate for address decoding delay, transmitter/receiver skew and cable skew. During data in instructions (transfer of data from slave to mas- ter) the master is responsible for skew compensation. \f 4_._2_._3_ _ _ _ _ _D_A_T_A_ _N_O_T_ _A_C_K_N_O_W_L_E_D_G_E_._ 4.2.3 DATA NACK is the not acknowledging response to DATA RDY indica- ting: 1. Address has been recognized by the slave. 2. A parity error in the received data has been detected. 3. Memory control unit has detected parity error in the data fetched from the memory. 4_._2_._4_ _ _ _ _ _D_A_T_A_ _O_U_T_._ 4.2.4 This line controls the transfer direction. When the signal is lo- gical 0, the transfer direction is from slave to master. When the signal is logical 1, the transfer direction is from master to slave. The use of the bus communication signals is illustrated by means of the timing charts figs. 4.4, 4.5 and the flow charts figs. 4.6, 4.7 and 4.8. \f 1. The master places the address of the slave on the ADDRESS lines and places appropiate transfer code in the DATA OUT line. The master asserts the DATA RDY signal. 2. The slave receives DATA RDY, DATA OUT and ADDRESS, compensates for address decoding and skew. When the DATA RDY signal is re- ceived, the slave prepares the data for transmission to the master. When data is available, the slave places data on the DATA lines and assert DATA ACK. 3. The master receives DATA ACK and DATA and compensates for skew. After skew compensating the master stores the data and cleares DATA RDY. If a parity error is detected in the recei- ved data, the master must set its bus parity error status and generates an interrupt. If the master receives DATA NACK in- stead of DATA ACK, it sets the bus communication error status and generates an interrupt. If a DATA ACK/NACK signal is not received within a certain time, time-out occurs and DATA RDY will be automatically cleared by the master, the bus time-out status set and an interrupt generated. 4. When the slave receives cleared DATA RDY the DATA lines and DATA ACK/NACK are cleared. 5. Master receives cleared DATA ACK/NACK. Fig. 4.4 DATA IN PROCEDURE. \f Fig. 4.4 DATA IN PROCEDURE \f 1. The master places the address of the slave on the ADDRESS lines, the DATA on the DATA lines, the appropiate transfer code on the DATA OUT line and asserts DATA RDY. 2. The slave receives ADDRESS, DATA, DATA OUT and DATA RDY, and compensates for address decoding and skew. If the data is cor- rectly received (no parity error)the slave responds to DATA RDY by asserting DATA ACK. If a parityerror in the received data is detected, the slave responds to the DATA RDY by asser- ting DATA NACK. 3. The master receives DATA ACK and cleares ADDRESS, DATA, DATA OUT and DATA RDY. If the master receives DATA NACK, it sets the bus communication error status, cleares ADDRESS, DATA, DA- TA OUT, DATA RDY and generates and interrupt. If DATA ACK/NACK is not received within a certain time, the ADDRESS, DATA, DATA OUT and DATA RDY is automatically cleared, the bus time out status set and an interrupt is generated. 4. Slave receives cleared DATA RDY and cleares DATA ACK/NACK. Fig. 4.5 DATA-OUT PROCEDURE \f Fig. 4.5 DATA OUT PROCEDURE \f Fig. 4.6 MASTER CONTROL SEQUENCE DATA IN TRANSFER FLOW CHART \f Fig 4.7 MASTER CONTROL SEQUENCE DATA OUT PROCEDURE FLOW CHART \f Fig. 4.8 SLAVE CONTROL SEQUENCE DATA IN and DATA OUT FLOW CHART \f 4_._3_ _ _ _ _ _ _ _M_i_s_c_e_l_l_a_n_e_o_u_s_ _C_o_n_t_r_o_l_ _S_i_g_n_a_l_s_._ 4.3 There is one additional control signal associated with the RC8000 bus. This signal, which may be used by all controllers is: SYSTEM RESET 4_._3_._1_ _ _ _ _ _S_Y_S_T_E_M_ _R_E_S_E_T_._ 4.3.1 This signal is a general reset signal, which resets all relevant registers in the controller and places its internal logic in a well defined start position. \f 5_._ _ _ _ _ _ _ _ _C_O_N_T_R_O_L_L_E_R_ _R_E_G_I_S_T_E_R_S_._ 5. As mentioned earlier in the description, the transfer of data, status, commands, interrupt between controllers connected to the RC8000 bus takes place via registers in the device controllers. These registers may be actual storage registers or simply signals gated to/from the bus during DATA-OUT/IN transfer. The registers may be directly addressable or for instance in case of standar- dized block-oriented device controllers, which uses channel pro- grams, the contents of some registers are transferred to memory on account of certain channel commands or interrupt conditions. Some registers may be loaded via channel commands, which causes the controller in question to fetch the required information in the memory, and store this information in its internal regis- ters. To standardize controller registers, RC has specified some regis- ters which must exist in every controller connected to the RC8000 bus. These registers are called the compulsory registers, and are listed below: C_u_r_r_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_ E_v_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_ I_n_t_e_r_r_u_p_t_ _D_e_s_t_i_n_a_t_i_o_n_ _R_e_g_i_s_t_e_r_ I_n_t_e_r_r_u_p_t_ _L_e_v_e_l_ _R_e_g_i_s_t_e_r_ Some other registers may be necessary depending upon the exact nature of each device controller. These registers are called the device dependent registers, examples are: Channel Program Address Remaining Char Count Register Char Count Register First Word Register Command Register Data Buffers etc. \f The current and event status registers holds status information. The type of status information may be parted into three major groups: 1. Compulsory status, i.e. status information which must exist in every controller. 2. Recommended status. 3. Device dependent status. The interrupt destination register holds the I/O address of the central processor to be interrupted, when the desired function has been executed by the controller. The interrupt level register holds the current interrupt number to be transferred to the central processor. Block-oriented controllers usually requires two registers to hold parameters of the transfer. These controllers may use the first word address and char count registers. The remaining char count register may also be used by block-oriented controllers, this re- gister is a status register, which refers to the latest read or write command. Block-oriented controllers, which utilize the channel program princip make use of the channel program address register. The interpretation of the command register may vary from control- ler to controller depending upon the nature of the peripheral equipment connected to the controller. Some controllers may require temporary storage of the data trans- ferred to/from the controller via the bus lines. These control- lers may use data buffers. \f 5_._1_ _ _ _ _ _ _ _C_u_r_r_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.1 Current status register contains status information, which de- fines the current condition of the device controller itself or the peripheral equipment connected to the controller. Device de- pendent and recommended status bit in current status register should not be introduced unless their interpretation has been exactly defined by hardware and software people in common. Con- cerning bit assignment for status in current status register re- fer to fig. 5.1. 5_._1_._1_ _ _ _ _ _C_o_m_p_u_l_s_o_r_y_ _S_t_a_t_u_s_ _B_i_t_s_ _i_n_ _C_u_r_r_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.1.1 P_O_W_E_R_ _L_O_W_/_D_I_S_C_O_N_N_E_C_T_E_D_:_ This status bit refers to either the controller itself or the peripheral equipment connected to the controller. Power low in- dicates that power is not within certain limits. Disconnected may indicate loss of power in the peripheral device, no cable instal- led etc. D_E_V_I_C_E_ _K_I_N_D_:_ These bits contains information concerning the peripheral equip- mnet connected to the controller. Typical parameters contained within this status are: Blockoriented device Peripheral equipment type etc. 5_._1_._2_ _ _ _ _ _R_e_c_o_m_m_e_n_d_e_d_ _S_t_a_t_u_s_ _B_i_t_s_ _i_n_ _C_u_r_r_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.1.2 Following status bits are recommended since they exists in many peripheral units. \f LOCAL/REMOTE: The local/remote signal originates in the peripheral equipment connected to the controller. When the peripheral equipment is off-line, the local/remote status shall be logical 1. END OF MEDIUM: The end of medium signal may for instance indicate end of paper in a printer, paper low in a punch etc. 5_._1_._3_ _ _ _ _ _D_e_v_i_c_e_ _D_e_p_e_n_d_e_n_t_ _S_t_a_t_u_s_ _B_i_t_s_ _i_n_ _C_u_r_r_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.1.3 These status signals depends on the exact nature of the periphe- ral equipment connected to the controller. Typical device depen- dent status signals are: CARRIER ON LOAD POINT WRITE ENABLE MODE ERROR/HIGH DENSITY etc. 5_._2_ _ _ _ _ _ _ _E_v_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.2 Apart from the current status register, the status information in the event status register is always cleared when the information is read. Some of the status bits in event status register may in- dicate that a change in the status bits in current status has oc- cured, i.e. the change is indicated in event status. Status, and the current state (logical 0 or logical 1) of the status is indicated in current status. Many of the status bits in event status causes generation of an interrupt, when they occur. As a general rule recommended and device dependent status bits in event status register should not be introduced, unless their interpretation has been exactly defined by hardware and software people in common. Concerning bit assignments on the event status register refer to fig. 5.2. \f 5_._2_._1_ _ _ _ _ _C_o_m_p_u_l_s_o_r_y_ _S_t_a_t_u_s_ _B_i_t_s_ _i_n_ _E_v_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.2.1 P_O_W_E_R_ _C_H_A_N_G_E_/_I_N_T_E_R_V_E_N_T_I_O_N_:_ This status bit may indicate that power has changed from normal to low voltage or from low to normal voltage either in the con- troller itself or in the peripheral equipment connected to the controller. The status bit may also indicate that someone has in- terfered with the equipment. B_U_S_ _P_A_R_I_T_Y_ _E_R_R_O_R_:_ The bus parity error indicates that a parity error has been de- tected in data received from the RC8000 bus. B_U_S_ _T_I_M_E_ _O_U_T_:_ Bus time-out status is set to logical 1 by a bus master, when neither ACK nor NACK is returned from the slave within a certain time after the emission of the DATA RDY signal. B_U_S_ _C_O_M_M_U_N_I_C_A_T_I_O_N_ _E_R_R_O_R_:_ This status is set to logical 1 by a bus master when a NACK sig- nal is returned from slave as a respond to the DATA RDY signal. 5_._2_._2_ _ _ _ _ _R_e_c_o_m_m_e_n_d_e_d_ _S_t_a_t_u_s_ _S_i_g_n_a_l_s_ _i_n_ _E_v_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ 5.2.2 Following status signals are recommended since they exists in ma- ny peripheral units: \f DATA LOST: The data lost status bis is used in connection with synchronous data transfers to/from peripheral equipment. Typical: DISC DRIVE UNITS MAGNETIC TAPE UNITS SYNCHRONOUS DATA TRANSMISSION TERMINALS The data lost status may be set during read operations as well as during write operations, indicating that the controller by some reason was unable to follow the transmission rate of the syn- chronous equipment. PARITY ERROR IN MEDIUM: This status indicates that a parity error has been detected in the data received from the peripheral equipment connected to the controller. 5.2.3 5_._2_._3_ _ _ _ _ _D_e_v_i_c_e_ _D_e_p_e_n_d_e_n_t_ _S_t_a_t_u_s_ _i_n_ _E_v_e_n_t_ _S_t_a_t_u_s_ _R_e_g_i_s_t_e_r_._ As mentioned in the description of current status a device con- troller may generate special status signals depending upon the nature of peripheral equipment connected to the controller. Ty- pical examples are: TIMER STATUS CARRIER CHANGED BLOCK LENGTH ERROR TAPE MARK etc. \f Fig. 5.1 \f Fig. 5.2 \f 6_._ _ _ _ _ _ _ _ _I_N_T_E_R_R_U_P_T_ _G_E_N_E_R_A_T_I_O_N_._ 6. Interrupt generation in the RC8000 system takes place by means of the interrupt destination and interupt level registers, which are two 24-bits registers. By means of these registers, it is possib- le to assign interrupt destination and level under program con- trol. An interupt procedure is initiated by a bus request procedure. When the controller becomes bus master, the interrupt destination register is gated to the address bus and the interupt level re- gister to the data bus. The interrupt destination identifies the CPU to be interrupted and the interrupt level indicates the interrupt priority of the interrupting device. 6_._1_ _ _ _ _ _ _ _I_n_t_e_r_r_u_p_t_ _G_e_n_e_r_a_t_i_n_g_ _S_t_a_t_u_s_ _B_i_t_s_._ 6.1 As a general rule, interrupts are generated when a status signal changes. According to this many of the status bits in the event status register involve interrupt generation. In the following is only mentioned those status signals which must generate an inter- rupt. During the design of a controller, software and hardware people in common may define other interrupt generating status bits. Interrupt generating status bits in the event status register: BUS TIME OUT BUS COMMUNICATION ERROR BUS PARITY ERROR \f 7_._ _ _ _ _ _ _ _ _R_C_8_0_0_0_ _B_U_S_ _C_H_A_R_A_C_T_E_R_I_S_T_I_C_S_._ 7. The RC8000 bus is a matched and terminated transmission line. The following section describes the transmission cable, bus length, signal levels and transceiver circuits associated with the RC8000 bus. 7_._1_ _ _ _ _ _ _ _B_u_s_ _T_r_a_n_s_m_i_s_s_i_o_n_ _C_a_b_l_e_._ 7.1 In controllers contained within a single module cassette (CHS 802) the bus lines is realized by means of a mother board. The mother board is a printed circuit board which interconnects all controllers within the cassette. Further cassettes may be added to the system by means of a speciel bus cable with the following characteristices: Cable type : twisted pairs nx2x0.25 mmUU2DD Impedance : 120E + 15% Prop. dealy : 6ns/m Skew : 1ns/m To minimize crosstalk between bus signald, it is essential that twisted pair cable is used. The RC8000 bus is terminated in each end by means of a resistive network for each signal except the SEL. OUT signal. The terminators in the one end are contained within the Bus Control Unit (BCU 801), and the terminators in the other end are contained within the Bus Terminator Unit (BTU 801). Refer to fig. 7.1 and 7.2 To pass the select signal a jumper PCBA must be inserted in unused chassis positions. Jacks/Plugs used in the RC8000 bus system are from the "ELCO MINIVARILOCK" series 8026-75 terminals. Four jack/plug pairs are used two pairs for bus-in, and two pairs for bus-out. The two \f jacks are named: DATA JACK ADDRESS JACK For pin assignments in jack/plug refer to fig. 7.3 and 7.4 \f \f \f \f \f 7_._2_ _ _ _ _ _ _ _B_u_s_ _L_e_n_g_t_h_. 7.2 The bus length should not exceed 10 meters, minus the length of all taps, which are the wires running from the actual bus to the receiver/transmitter circuits. For correct operation these tapes should not be longer than 25 cm. In systems where a longer bus is required the length may be increased by means of bus repeaters. Since the transmission technique is asynchronous and fully interlocked the transmission rate depends upon the length of the bus. An important parameter is the maximum cable skew: m_a_x_ _c_a_b_l_e_ _s_k_e_w_ _2_0_n_s_ Calculation of the cable skew is based on a maximum cable length of 10 meters and a maximum difference between the shortest and longest wire of 1 meter. 7_._3_ _ _ _ _ _ _ _B_u_s_ _S_i_g_n_a_l_ _L_e_v_e_l_s_. 7.3 The signal level and representation of the bidirectional bus lines is as follows: logical 1 : OV_VddoutdLuuu +0.45V logical 0 : 4.3_VddoutdHuuu For the select out line the signal level and representation is as follows: logical 1 : 4.3_VddoutdHuuu logical 0 : 0V_VddoutdLuuu_+0.5V The low output voltage (VddoutdLuuu) on the bus lines is determined by the SN75138 transmitter which has a saturation Voltage of: 0.45V , Idoutu=-100mA\f The high output voltagecalculation is based upon the following parameters: Receiver load Current : max 300 A Transmitter leakage current : max 50 A Termination resistor tolerance: + 5% Terminator supply voltage tolerance : + 5% Max bus load = 20 transmitters/20 receivers This gives the following result: Load current : 20x300x10U-6D = 6 mA leakage current : 20u.d50u.d10U-6D = 1 mA Max +5v resistance = 63 E min terminator voltage = 4.75V VdoutdHuu 4.75 - 7x63x10U-3D = 4.3v \f \f 7_._4_ _ _ _ _ _ _ _T_r_a_n_s_c_e_i_v_e_r_._ 7.4 The transsceiver used in the RC8000 bus system is the Texas quad bus transceiver 75138, which is designed for twoway communication over single ended transmission lines. Each of the four identical channels consists of a driver with TTL inputs and a receiver with a TTL outpt. The driver output is of the opencollector type, and is designed to handle loads up to 100 mA. The receiver input is internally connected to the driver output and has a high impedance to minimize loading of the transmission line. The receiver design also features a threshold of 2.3V (typical), providing a wider noise margin than would be possible with a receiver having the usual TTL threshold. These circuits are designed for operation from a single 5 volt supply and include a provision to minimize loading of the bus when the power supply voltage is zero. \f 8_._ _ _ _ _ _ _ _ _B_U_S_ _M_A_S_T_E_R_ _S_E_L_E_C_T_I_O_N_ _L_O_G_I_C_. 8. 8_._1_ _ _ _ _ _ _ _M_a_s_t_e_r_ _S_e_l_e_c_t_i_o_n_ _L_o_g_i_c_ _i_n_ _C_o_n_t_r_o_l_l_e_r_. 8.1 The logic which is necessary for bus master selection is shown in Fig.8.1. When the controller wants access to the bus, the 7 MASTER REQUEST signal is lowered, which results in a BUS REQUESTS signal to the BUS CONTROL UNIT. The BCU responds to the BUS REQ by sending the SEL.OUT. and COM.SELOUT signal 30ns before the signal is used, this assures that only one controller is selected as bus master Controller, which has not the 7 MASTER REQUEST signal low, passes the SEL-IN signal, since tha ENABLE FF becomes logical 1 at the leading edge of SEL-IN. The controller which has the 7 MASTER REQUEST signal low will not pass the SEL-IN- signal since the ENABLE FF becomes logical 0 at the leading edge of SEL-IN, however, the SEL.ACK FF in this controller becomes logical 1 at the leading edge of SEL-IN. When the SEL.ACK FF becomes logical 1, the BUS REQ. signal to the BCU is removed, and provided BUS.BUSY, ACK, NACK and SEL-IN signals are all low the MASTER FF is set to logical 1. If BUS BUSY or ACK or NACK or SEL IN is logical 1, the set ot the MASTER FF is postponed utill the signal in question becomes logical 0. The BCU upon receiving the SEL.ACK signal lowers the SEL-IN and COM.SEL signald simultaneously, which causes the controller to clear the SEL.ACK FF provide the MASTER FF is set. When the BCU receives cleared SEL.ACK a new bus selection sequence is initiated if the BUS REQ signal is still logical 1. A controller with a high priority may override a bus master request procedure initiated by a controller with low priority \f this situation is illustrated by means of timing chart fig. 8.2. The necessary filter time for SEL IN is calculated as follows: a. 74S74 propagation 9 ns b. tdPHLu-tdPLHu difference in SEL OUT driver (74S38) 5 ns c. tdPHLu-tdPLHu difference in SEL IN receiver (75138) _ _ _ _ _ _ _ _ _ _9_ _n_s_ TOTAL 23 ns The cable delay/skew shown in the timing chart fig. 8.2 is based upon the following parameters: a) Cable delay -------------------------------------- 6ns/m b) Max difference between longest and shortest wire in 1 meter cable max 15 cm ---------------------------------- 1 ns. c) Max difference between longest and shortest wire en the controller 25 cm ------------------------------------------- 1.5 ns d) Physical distance between BCU and CONTROLLER 1 = 1 meter. Physical distance between CONTROLLER 1 and CONTROLLER 2 = 1 meter. The transceiver delays shown in timing chart fig. 8.2 are based upon the following parameters: a) 75138 driver propagation delay tdPLHu = tdPHLu max. 24 ns \f b) 75138 receiver propapation delay tdPLHu = tdPHLu max. 15 ns c) 74S38 driver propagation delay tdPLHu = tdPHLu max. 10 ns 8_._2_ _ _ _ _ _ _ _B_u_s_ _M_a_s_t_e_r_ _S_e_l_e_c_t_i_o_n_ _L_o_g_i_c_ _i_n_ _B_C_U_. 8.2 The SEL OUT and COM SEL generator in the BCU is realized as shown in fig. 8.3 A, B. Provided BUS REQ is logical 1 and SEL ACK logical 0, the SEL OUT and COM SEL signals are generated (fig. 8.3a) and TIME-OUT circuits started (fig. 8.3b). If a SEL.ACK signal is not returned within the time defined by the timer ( 5 us), time out occurs. The timme-out condition causes start of the TIME OUT ACK MMV, which clears the COM SEL and SEL OUT signals. After the delay time defined by this MMV the respond procedure is repeated provided BUS REQ is still logical 1. \f \f \f \f \f 9_._ _ _ _ _ _ _ _ _B_U_S_ _C_O_M_M_U_N_I_C_A_T_I_O_N_ _L_O_G_I_C_._ 9. A general bus interface for a block orientated device controller is shown in fig. 9.1 to 9.10. 9_._1_ _ _ _ _ _ _ _D_e_v_i_c_e_ _A_d_d_r_e_s_s_ _D_e_c_o_d_i_n_g_ _(_f_i_g_._ _9_._2_,_ _f_i_g_._ _9_._1_0_)_. 9.1 This device is started by means of a DATA OUT instruction from RC8000 CPU. The CPU addresses the device via the address bus and the DATA RDY signal. The response to the DATA RDY signal is the ACK signal, which indicates coincidence between the received device address and the device address stored in the device number switch. In case of non-coincidence or address parity error the ACK signal will not be returned. Fig. 9.1 shows the device address decoding, device number switch and device address parity checker. Fig. 9.9 lower part shows the ack generator. An ack signal will be returned to the master procided following conditions are all satsisfied: 1. Device not master 2. Data out in := 1 3. Data rdy in := 1 4. Selected := 1 The timing delay compensates for: 1. Skew in the master 2. Skew in transceiver 3. Skew in cables 4. Propagation delays in Address decoding and ack generator. Skew in the master is the max. timing difference between the input to the dataready transceiver and the gate signal to the data/address transceivers. \f 9_._2_ _ _ _ _ _ _ _P_a_r_i_t_y_ _C_h_e_c_k_e_r_ _&_ _G_e_n_e_r_a_t_o_r_ _(_f_i_g_._ _9_._3_,_ _f_i_g_._ _9_._1_)_. 9.2 Data bus parity is checked/generated and address bus parity generated by means of 4 parity checkers/generators. This device controller contains an internal bus, which carries information to/from I/O data register and I/O address register. The internal bus is connected to the inputs of the parity checker/generator. The outputs of the I/O data and I/O address registers are connected to the RC8000 data and address bus. Whenever the controller sends data to a device address on the RC8000 bus, these data passes the internal bus, and the parity generator will generate the correct parity bits, which are loaded into the I/O data parity register before the data rdy signal is generated. The address parity is generated according to the same princip. When the controller receives data from a device address on the RC8000 bus these data are stored in the I/O data register and the parity bits in the I/O data parity register. Afterwards the data is gated to the internal bus and the parity checked. I/O data register and I/O data parity register is shown in fig. 9.4 and 9.5. I/O data and address register and data bun, address bus and control signal transceivers (fig. 9.4 - 9.5 - 9.6 - 9.7 - 9.8 - 9.9). Data are transferred to/from the RC8000 bus via the I/O data register. This device has a I/O data register with two input port of which one is connected to the internal bus and one to the RC800 data bus receivers. The output of the I/O data register is connected to the RC8000 data bus transmitters and to a selector from which they can be gated to the internal bus. In case of data-out transters the I/O data register and the I/O address register is loaded, and simultaneously a bus cycle is requested and data-out FF set to logical 1. Rever to upper part of fig. 9.9 and I/O address register fig. 9.7 When the device controller becomes bus master the I/O data register and the I/O address register is gated to the RC8000 bus and the data ready signal is \f set to logical 1. When the slave responds with the ack signal, the data ready signal is set to logical 0 and the data-out transfer is terminated. If the slave returns a nack signal the device controller set>s the bus communication error status and generates an interrupt. If the slave returns neither ack nor mack within 3 us the device controller set>s the bus time out status and generates an interrupt. Refer to fig. 9.9 and 9.10 upper part. In case of data-in transfer the I/O address register is loaded, the data out FF is set to logical 0 and a bus cycle requested. When the device controller becomes bus master the I/O address register is gated to the RC8000 bus and the data ready signal is set to logical 1. The device controller upon receiving the ack signal from the slave delays this signal to compensate for: 1. Skew in slave 2. Skew in transceivers 3. Skew in cables After the compensation delay, which is shown in fig. 9.9 upper part, the cevice controller clears data ready, loads I/O data register with data from slave and checks the parity. If a parity error is detected the device controller set the bus parity error status and gerenates an inperrupt. Bus communication error and bus time out may also occur during data in transfer. \f 1_0_._ _ _ _ _ _ _ _D_E_V_I_C_E_ _C_O_N_T_R_O_L_L_E_R_ _E_X_A_M_P_L_E_S_. 10. 1_0_._1_ _ _ _ _ _ _S_t_a_n_d_a_r_d_i_z_e_d_ _B_l_o_c_k_-_o_p_r_i_e_n_t_e_d_ _D_e_v_i_c_e_ _C_o_n_t_r_o_l_l_e_r_s_. 10.1 Standardized block-oriented controllers, such as the disc processor and general divice processor, are started by means of an output operation, which addresses the conroller as described below. Here, the content of the working register is irrelevant. Once started, the controller fetches its commands from the channel program in the primary merory and executes whem without engaging the central processor. Data to be read from or written to a device is transferred directly between the device controller and the primary memory. The channel program is normally terminated by a ATOP command, which transfers the standard status information to the primary mo emory and interrupts the controlling central processor. D_e_v_i_c_e_ _a_d_d_r_e_s_s_ Device addresses have the following format: ______________________________________________ d _1_____________________________________________u 0 1 20212223 Bit 0 Logical 1, indicating I/O address. This bit is set by the Data Out instruction. Bits 1:20 D_e_v_i_c_e_ _a_d_d_r_e_s_s_. Bits 1:20 are also used to calculate the device description address (see below). \f In the case of multi-device controllers, the address is divided into a main device field and a sub-device field. In the disc storage system, for example, bits 1:18 contain the binary number of the addressed disc processor, preceded by zeros, and bits 19:20 the logical number of one of the four disc drives. The function of direct controller commands is defined only by the effective addredss; the data transferred by the instruction is irrelevant. Bits 21:22 D_e_v_i_c_e_ _f_u_n_c_t_i_o_n_. Bits 21:22 have the following meaning: 00 START CHANNEL PROGRAM 01 RESET DEVICE 10 (unassigned) 11 (unassigned) START CHANNEL PROGRAM cuauses the addressed controller to start its channel program by fetching the first word of the device description using the device description address (see below). During program execution the controller will not accept further START CHANNEL PROGRAM commands. RESET DEVICE causes the addressed controller to enter an idle and unassigned state, in which it awaits adressing and can generate no interrupts. Bit 23 Irrelevant. D_e_v_i_c_e_ _d_e_s_c_r_i_p_t_i_o_n_ The address of the device description is calculated using the device address (bits 1:20) as follows: device base + device address x 8. The device base, which is common to all devices connected to the controller, has an absolute address in the primary memory. \f The device description contains the following: lst word: S_t_a_r_t_ _o_f_ _c_h_a_n_n_e_l_ _p_r_o_g_r_a_m_. Address of the first channel program command. 2nd word: S_t_a_t_u_s_ _a_d_d_r_e_s_s_. First address of the area in the primary memory to which the standard status information is to be transferred at the end of the program. 3rd word: I_n_t_e_r_r_u_p_t_ _d_e_s_t_i_n_a_t_i_o_n_. I/O address of the central processor to be interrupted at the end of the program. 4th word: I_n_t_e_r_r_u_p_t_ _l_e_v_e_l_. Current interrupt number to be transferred to the central processor. C_o_m_m_a_n_d_ _f_i_e_l_d_ The basic commands can be divided into three groups according to parameter structure: some require two parameters, others only one, still others none whatsoever. The parameter FIRST CHAR ADDRESS specifies the start ddress of the memory area to or from which characters are to be transferred or fetched. The parameter CHAR COUNT specifies the maximum number of characters to be transferred or fetched. The parameters DATA 1 and DATA 2, which are device dependent, specify data areas. For some device sontrollers, only three bits of the command field are interpreted, in which case the bit pattern xlll indicates STOP. \f Bits Basic 1_2_:_1_5_ C_o_m_m_a_n_d_ P_a_r_a_m_e_t_e_r_ _1_ P_a_r_a_m_e_t_e_r_ _2_ 0000 SENSE FIRST CHAR ADDRESS CHAR COUNT 0001 READ - - 0010 CONTROL - - 0011 WRITE - - 0100 WAIT (irrelevant) (irrelevant)U 0101 (unassigned) - - 0110 CONTROL NO PARAM - - 0111 (unassigned) - - 1000 (unassighed) DATA 1 (irrelevant) 1001 - - - 1010 - - - 1011 - - - 1100 (unassigned) DATA 1 DATA 2 1101 - - - 1110 - - - 1111 STOP (irrelevant) (irrelevant) SENSE transfers data from the internal registers or memory of the controller. READ transfers data from the external data mediun. Crontrol transfers data to the internal registers or memory of the controller. WRITE transfers data to the external data medium. WAIT permits the controller to generate an interrupt on certain events, such as power low or intervention. The controller enters a semi-idle state, in which it can accept a new START CHANNEL PROGRAM command (see Section 8.3.1). For devices used for autoloading, CONTROL NO PARAM with modification 0 performs either an initializing function or no function at all. STOP terminates the channel program. \f O_t_h_e_r_ _f_i_e_l_d_s_ Other fields in the command word are not necessarily interpreted; if they are, they have the following meanings: The D field indicats data chaining and is used to link the current command to the next command, so that a connected data transfer may take place to or from a non-connected memory area, indicated by a sequence of FIRST CHAR ADDRESS and CHAR COUNT parameters. The S field means "skip data transfer" and is used only in conjuction with data chaining to transfer portions of connected data. The meaning of the modifier field is device dependent, bud modification 0 always indicateds normal use of the device. S_t_a_n_d_a_r_d_ _s_t_a_t_u_s_ _i_n_f_o_r_m_a_t_i_o_n_ Standard status information is transrerred to the primary memory starting from the status address, contained in the second word of the device description, either on normal termination of the channel program by the STOP command or on abnormal termination by a device error. The standard status information includes the following: 1st word: C_h_a_n_n_e_l_ _p_r_o_g_r_a_m_ _a_d_d_r_e_s_s_._ Indicates the command following hte current command. 2nd word: R_e_m_a_n_i_n_g_ _c_h_a_r_a_c_t_e_r_ _c_o_u_n_t_._ Refers to the latest read or write command or chain of such commands; in the latter case, the count will be the total count for the chain. 3rd word: C_u_r_r_e_n_t_ _s_t_a_t_u_s_._ Reflects the status of the device at the termination of the program. \f 4th word: E_v_e_n_t_ _s_t_a_t_u_s_._ Contains information about events that have occurred since the last sensing of the event status register. 1_0_._2_ _ _ _ _ _ _E_x_a_m_p_l_e_s_ _o_f_ _s_t_a_n_d_a_r_d_i_z_e_d_ _b_l_o_c_k_-_o_r_i_e_n_t_a_t_e_d_ _c_o_n_t_r_o_l_l_e_r_s_. 10.2 1_0_._2_._1_ _ _ _ _D_I_S_K_ _S_T_O_R_A_G_E_ _S_O_N_T_R_O_L_L_E_R_ _-_ _D_S_C_ _8_0_1_. 10.2.1 REFERENCE MANUAL RCSL 30-3' TECHNICAL MANUAL 1_0_._2_._2_ _ _ _ _F_R_O_N_T_ _P_R_O_C_E_S_S_O_R_ _A_D_A_P_T_O_R_ _-_ _F_P_A_ _8_0_1_. 10.2.2 REFERENCE MANUAL RCSL 52-AA355 TECHNICAL MANUAL \f \f i I_N_D_H_O_L_D_S_F_O_R_T_E_G_N_E_L_S_E_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_I_D_E_ 1. INTRODUKTION ........................................... 1 2. DATABESKRIVELSE ........................................ 2 2.1 Databasestruktur .................................. 2 2.2 Individbeskrivelse ................................ 3 2.3 Systemets indbyggede datakonventioner ............. 4 3. DATABASE VEDLIGEHOLDELSE ............................... 6 3.1 Opdateringskørsel (normal situation) .............. 6 3.2 Opdateringskommandoer ............................. 7 3.3 Systemfejl under opdateringskørslen ............... 9 3.4 Reorganiseringskørsel ............................. 10 3.5 Kontrol af databasens tilstand .................... 11 3.6 Afhjælpning af databasefejl ....................... 11 3.6.1 Reetableringskørsel ........................ 12 3.6.2 Recoverkørsel .............................. 12 4. UDSKRIFTER ............................................. 14 4.1 Batch udskrifter .................................. 14 4.2 Online udskrifter ................................. 14 4.3 Udskrifter og kommandoer .......................... 15 4.3.1 Udskriftskommandoer ........................ 16 4.3.2 Specielle kommandoer ....................... 16 4.3.3 Parametre til udskriftskommandoer .......... 17 B_I_L_A_G_: A. REFERENCER ............................................. 21 B. OVERSIGT OVER OPDATERINGSKOMMANDOER .................... 22 C. REORGANISERINGSKØRSEL - UDSKRIFTSEKSEMPLER ............. 23 D. PERIODETABELLER ........................................ 25 \f ii I_N_D_H_O_L_D_S_F_O_R_T_E_G_N_E_L_S_E_ _(_f_o_r_t_s_a_t_)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _S_I_D_E_ E. OVERSIGT OVER UDSKRIFTSKOMMANDOER ...................... 26 F. UDSKRIFTSEKSEMPLER ..................................... 27 F.1 Udskriftsrammer ................................... 27 F.2 Kartoteksliste - medarbejdere ..................... 29 F.3 Kartoteksliste - projekter ........................ 30 F.4 Projektoversigt ................................... 31 F.5 Opfølgningsliste - medarbejder .................... 34 F.6 Opfølgningsliste - projekter ...................... 37 F.7 Belastningsoversigt - medarbejdere ................ 39 F.8 Belastningsoversigt - medarbejderprojekter ........ 41 F.9 Belastningsoversigt - medarbejdere totalt ......... 43 F.10 Belastningsoversigt - projekter ................... 45 F.11 Belastningsoversigt - projekter totalt ............ 47 F.12 Aktivitetsgraf .................................... 49 F.13 Periodeoversigt ................................... 50 \f F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_K_T_I_O_N_ 1. PBPLAN er et administrativt system, der er opbygget af RC's ud- viklingsafdeling til anvendelse i forbindelse med afdelingens projektstyring, og har som primære formål at virke som værktøj ved: - detailplanlægning af projekter, - projektopfølgning, - udarbejdelse af bemandingsoversigter. Systemet afvikles på RC8000 under operativsystemerne BOSS og MIPS/TS. Denne manual beskriver systemet set fra et brugersynspunkt. I kapitel 2 gives en kort orientering om systemets data. Kapitel 3 beskriver anvendelsen af systemets opdateringsfacilite- ter. Endelig beskrives i kapitel 4 udskriftsmulighederne fra systemet. For en mere detaljeret beskrivelse af systemets opbygning henvi- ses til ref. 1. \f F_ 2_._ _ _ _ _ _ _ _ _D_A_T_A_B_E_S_K_R_I_V_E_L_S_E_ 2. I de følgende afsnit beskrives systemets data i den udstrækning, det anses for nødvendigt for systemets brug. 2_._1_ _ _ _ _ _ _ _D_a_t_a_b_a_s_e_s_t_r_u_k_t_u_r_ 2.1 Databasen udgøres af en medarbejderfil (M), en projektfil (P) og en belastningsfil (B). Medarbejderfilen anvendes til lagring af medarbejderindivider. Disse identificeres ved initialer og er kædet, således at det ud- fra et individ er muligt at finde det næste (i henhold til alfa- betisk sortering). Projektfilen anvendes til lagring af projektindivider. Disse identificeres ved et projektnummer og et aktivitetsnummer og er kædet, således at det udfra et individ er muligt at finde det næste (med højere aktivitetsnummer og samme projektnummer eller højere projektnummer). Belastningsfilen anvendes til lagring af belastningsindivider. Ethvert af disse er knyttet til netop t individ i projektfilen og t individ i medarbejderfilen. Individerne er indbyrdes kædet, således at det er muligt at finde det næste individ (dvs. et tid- ligere oprettet individ) enten knyttet til samme projektindivid eller knyttet til samme medarbejderindivid. Fra et projektindivid eller et medarbejderindivid er det muligt at finde det evt. sidst tilknyttede belastningsindivid. Et belastningsindivid kan således kun identificeres via det pro- jektindivid og det medarbejderindivid, hvortil det er knyttet. Databasestrukturen er søgt illustreret i fig. 1. \f P-fil B-fil M-fil Figur 1: Illustration af sammenhæng mellem databaseindivider. 2_._2_ _ _ _ _ _ _ _I_n_d_i_v_i_d_b_e_s_k_r_i_v_e_l_s_e_ 2.2 I dette afsnit gives en oversigt over dataelementerne i de tre individtyper med angivelse af de i manualen anvendte forkortel- ser. Ved en tekst forstås nedenfor et bogstav evt. efterfulgt af et eller flere mellemslag eller tegn, bortset fra komma. Et projektindivid indeholder følgende dataelementer: proj: projektnummer (prim. nøgle, heltal, max. 6 cifre) akt: aktivitetsnummer (sekd. nøgle, heltal, max. 4 cifre) beg: startår og -uge (heltal, max. 4 cifre) slut: slutår og -uge (heltal, max. 4 cifre) titel: projekt- eller aktivitetsnavn (tekst, max. 26 tegn) status: individstatus (tekst, max. 5 tegn, jf. afsnit 2.3) \f Et medarbejderindivid indeholder følgende dataelementer: init: initialer (nøgle, tekst, max. 4 tegn) afd: afdelingsnummer (heltal, max. 4 cifre) kategori: medarbejderkategori (tekst, max. 5 tegn) ansætpct: ansættelsesprocent (heltal, max. værdi 100) navn: navn (tekst, max. 32 tegn) status: individstatus (tekst, max. 5 tegn, jf. afsnit 2.3) Et individ i belastningsfilen indeholder følgende dataelementer: løb.belastn.: løbende belastning angivet som antal dage pr. uge (decimaltal, max. 1 decimal, max. værdi 5,0) abs.belastn.: absolut belastning angivet som antal dage (decimaltal, max. 1 decimal, max. værdi 99,9) status: individstatus (tekst, max. 5 tegn, jf. afsnit 2.3) 2_._3_ _ _ _ _ _ _ _S_y_s_t_e_m_e_t_s_ _i_n_d_b_y_g_g_e_d_e_ _d_a_t_a_k_o_n_v_e_n_t_i_o_n_e_r_ 2.3 Medarbejderkategorien anvendes som nøgle ved opgørelser af total- belastningen. Projektindivider med projektnummer mindre end 100 betragtes ikke som egentlige projektindivider. Eksempelvis anvendes projektnum- mer 1 til lagring af en tabel over uger mindre end 5 arbejdsdage (se bilag D). Et projektindivid med aktivitetsnummer 0 opfattes som en projekt- beskrivelse, der indeholder start- og sluttid for projektet samt projektnavn. Det sidste tilknyttede belastningsindivid anvendes som identifikation af projektlederen. Et projektindivid med aktivitetsnummer <> 0 opfattes som en aktivitetsbeskrivelse, der indeholder start- og sluttid for aktiviteten samt aktivitetsnavn. \f Projektindivider med starttid 0 (år: 0, uge: 0) eller sluttid 9999 (år: 99, uge: 99) opfattes som tidsubegrænsede projekter/ak- tiviteter. Individstatus angives ved predefinerede tekster med følgende be- tydning: plan: planlagt aktiv: aktivt ext: aktivt med extern interesse konto: aktivt, men indgår ikke i projektstyringen hvil: hviler stop: stoppet uden at være afsluttet luk: lukket men ikke egentlig afsluttet slut: afsluttet slet: slettet (individet slettes ved næste reorganisering, se afsnit 3.4) I medarbejderindivider tillades kun status 'aktiv' eller 'slet'. \f F_ 3_._ _ _ _ _ _ _ _ _D_A_T_A_B_A_S_E_ _V_E_D_L_I_G_E_H_O_L_D_E_L_S_E_ 3. Database vedligeholdelse sker under anvendelse af følgende hjæl- pemidler: - online opdateringskørsel til den løbende opdatering, - reorganiseringskørsel (batch) til periodevis oprydning i da- tabasen. Derudover findes der et antal hjælpekørsler til afhjælpning af opståede databasefejl. Kun n bruger har mulighed for afvikling af vedligeholdelseskørs- ler ad gangen. 3_._1_ _ _ _ _ _ _ _O_p_d_a_t_e_r_i_n_g_s_k_ø_r_s_e_l_ _(_n_o_r_m_a_l_ _s_i_t_u_a_t_i_o_n_)_ 3.1 En opdateringskørsel afvikles som følger (brugerindtastningen un- derstreget): '_E_S_C_'_ aktivr ESC-tasten att s_o_s_ >r_u_n_ _p_p_a_ M_ . . . (meddelelser fra systemet) . P_ . i_ _o_p_d_a_t_e_r_ (evt. meddelelser om databasefejl vil fremkomme efter denne kommando, se afsnit 3.3) pbplan-opdat<dato>.<tid> (startudskrift fra opdateringsprogram) opdateringsdialog, se afsnit 3.2 x_ afslutningskommando til opdaterings- program opdatering afsluttet (meddelelse om at opdateringskørslen er afsluttet normalt) \f 3_._2_ _ _ _ _ _ _ _O_p_d_a_t_e_r_i_n_g_s_k_o_m_m_a_n_d_o_e_r_ 3.2 I dette afsnit beskrives kommandoerne til opdateringsprogrammet. Generelt gælder det, at parametre skal indtastes i den anførte rækkefølge. Parametre anført som <param.navn> skal angives, mens parametre anført som (param.navn) kan repræsenteres ved en bin- destreg eller kan, hvis den står sidst i kommandoen, udelades. Opdateringen foregår ved separat opdatering i de tre databasefil- er. Programmet opretholder såvidt muligt hele tiden referencer til tre aktuelle individer, nemlig de sidst anvendte i hver af databasefilerne. Ved dataændring opdateres altid i de aktuelle individer, som derfor først skal udpeges. Til dette formål findes følgende kommandoer: vp,(proj),(akt): v_is specificeret p_rojektindivid. Angi- ves hverken 'proj' eller 'akt', vises det aktuelle projektindivid. Angives alene 'proj' vises projektbeskrivel- sen. np,(akt): vis n_æste p_rojektindivid. Angives 'akt' med værdien nul, vises næste projektbeskrivelse; ellers vises næste projektindivid. vpb,(init): v_is p_rojektb_elastning knyttet til det aktuelle projektindivid. Angives 'init', vises belastningen for denne medarbejder; ellers vises første be- lastning. npb: vis n_æste p_rojektb_elastning knyttet til det aktuelle projektindivid. vm,(init): v_is specificeret m_edarbejder. Angives 'init' ikke, vises aktuelt medarbej- derindivid. \f nm,(afd): vis n_æste m_edarbejder. Angives 'afd', vises næste medarbejder i den pågæl- dende afdeling; ellers vises næste medarbejder. vmb,(proj),(akt): v_is m_edarbejderb_elastning knyttet til det aktuelle medarbejderindivid. Angi- ves hverken 'proj' eller 'akt', vises første belastning. Angives 'proj' ale- ne vises belastningen knyttet til pro- jektbeskrivelsen. nmb: vis n_æste m_edarbejderb_elastning knyt- tet til det aktuelle medarbejderindi- vid. Data for de aktuelle individer henholdsvis projekt-, medarbejder- og belastningsfil rettes under anvendelse af kommandoerne: rp,(beg),(slut),(titel),(status) rm,(afd),(kategori),(ansætpct.),(navn),(status) rb,(løb.belastn.),(abs.belastn.),(status) Kun de dataelementer, der ønskes ændret skal angives. Til samlede statusændringer i projekt- og belastningsfilen anven- des en af følgende 'sp'-kommandoer: sp,<status>: s_tatusændring for p_rojekt- og belast- ningsindivider. sp,<glstatus>,<status>: s_tatusændring for p_rojekt- og belast- ningsindivider med status lig 'glstatus'. Hvis det aktuelle projektindivid er en projektbeskrivelse gennem- føres statusændringen for alle projektindivider og tilknyttede belastningsindivider. Er det aktuelle projektindivid en aktivi-\f tetsbeskrivelse gennemføres statusændringen kun for det aktuelle projektindivid og de dertil knyttede belastninger. Oprettelse af individer i henholdsvis projekt-, medarbejder- og belastningsfilen sker under anvendelse af kommandoerne: op,(proj),(akt),(beg),(slut),(titel),(status) om,(init),(afd),(kategori),(ansætpct.),(navn) ob,(init),(løb.belastn.),(abs.belastn.) En projektbeskrivelse, der oprettes uden angivelse af 'status', oprettes med status aktiv, mens en aktivitetsbeskrivelse, der op- rettes uden angivelse af 'status', oprettes med samme status som den tilhørende projektbeskrivelse. Et medarbejderindivid oprettes altid med status aktiv. Kommandoen 'ob' opretter en belastning knyttet til det aktuelle projektindivid med samme status som det- te. Parameterværdier for parametre, der ikke angives, tages fra de tilsvarende aktuelle individer. Efter oprettelse udpeges indi- videt til aktuelt individ for den pågældende databasefil. Syntaksen for kommandoen 'komm.navn' vises som resultatet af kom- mandoen: ?,(komm.navn). Angives intet 'komm.navn' vises syntaksen for samtlige kommandoer til opdateringsprogrammet. Opdateringsprogrammet afsluttes med kommandoen: x. 3_._3_ _ _ _ _ _ _ _S_y_s_t_e_m_f_e_j_l_ _u_n_d_e_r_ _o_p_d_a_t_e_r_i_n_g_s_k_ø_r_s_l_e_n_ 3.3 Såfremt en opdateringskørsel bliver afsluttet på unormal måde, kan der opstå fejl i databasen. Der findes følgende typiske fejl- situationer: - P_r_o_g_r_a_m_f_e_j_l_ Der fremkommer en længere udskrift på skærmen, hvorefter sys- temet ikke længere kan modtage normale opdateringskommandoer. I denne situation noteres mest muligt af den udskrevne medde- lelse og den systemansvarlige adviseres. Opdateringskørslen søges startet på sædvanlig vis. \f - F_e_j_l_ _i_ _e_d_b_-_a_n_l_æ_g_g_e_t_ Denne situation er opstået, hvis systemet er holdt op med at svare på de indtastede kommandoer, og det, når systemet atter begynder at svare, er nødvendigt at starte helt forfra for at komme i kontakt med systemet. Efter at forbindelsen til anlægget atter er etableret, star- tes opdateringskørslen op påny. Databasens tilstand undersøges automatisk i forbindelse med opda- teringskørslen, se afsnit 3.5. 3_._4_ _ _ _ _ _ _ _R_e_o_r_g_a_n_i_s_e_r_i_n_g_s_k_ø_r_s_e_l_ 3.4 Sletninger i databasen foregår ved at status for de individer, der skal slettes, ændres til 'slet'. Det er derfor nødvendigt med regelmæssige mellemrun, at gennemføre en reorganiseringskørsel, hvorved de slettede individer fysisk slettes fra databasen. Slet- ninger af individer med status 'slet' gennemføres efter følgende regler: - En projektbeskrivelse slettes aldrig. - En aktivitetsbeskrivelse slettes kun såfremt alle tilknyttede belastninger har status 'slet'. - En medarbejder slettes kun, såfremt alle tilknyttede belast- ninger har status 'slet'. - En belastning med status 'slet' slettes altid. En reorganiseringskørsel omfatter normalt følgende operationer (brugerindtastningen understreget): '_E_S_C_'_ aktivr ESC-tasten att b_o_s_s_ type user name and projekt p_p_a_ _2_7_0_0_0_0_ g_e_t_ _p_b_s_l_e_t_j_o_b_ \f r_u_n_ M_ . . . (meddelelser fra sletteprogrammet . P_ . r_e_n_a_m_e_ _p_r_i_m_o_u_t_ _u_d_ (meddelelser fra sletteprogrammet c_o_n_v_e_r_t_ _u_d_ _s_t_d_ udskrives på printer) l_o_g_o_ Virkningen af reorganiseringskørslen vil først have effekt i udskrifter efter næste opdateringskørsel. 3_._5_ _ _ _ _ _ _ _K_o_n_t_r_o_l_ _a_f_ _d_a_t_a_b_a_s_e_n_s_ _t_i_l_s_t_a_n_d_ 3.5 I forbindelse med opstart af opdaterings- og reorganiseringskørs- len, undersøges databasens tilstand. Såfremt der er fejl i denne, afbrydes kørslen med en af følgende udskrifter: - reetabler database - recover database Førstnævnte udskrift betyder, at databasen er definitivt ødelagt, hvorfor der må søges efter en ældre brugbar version. Dette kan ske ved kørsel af jobbet 'reetabler' som beskrevet i afsnit 3.6. Sidstnævnte udskrift betyder at databasen er defekt, men at den forventes at kunne genetableres ved kørsel af jobbet 'recover' som beskrevet i afsnit 3.6. 3_._6_ _ _ _ _ _ _ _A_f_h_j_æ_l_p_n_i_n_g_ _a_f_ _d_a_t_a_b_a_s_e_f_e_j_l_ 3.6 Nedenfor beskrives systemets procedurer til afhjælp af database- fejl. De her omtalte job bør kun afvikles efter samråd med den system- ansvarlige. \f 3_._6_._1_ _ _ _ _ _R_e_e_t_a_b_l_e_r_i_n_g_s_k_ø_r_s_e_l_ 3.6.1 Dette job henter en kopi af databasen fra det område, hvor der normalt tages udskrifter, hvorefter den kontrollerer den derved oprettede database. Jobbet afsluttes med en af følgende udskrifter: - Reetablering ikke mulig. Den ældre version af databasen var også defekt. Den eneste mulighed er herefter at hente databasen fra systemdump og gentage alle opdateringer foretaget siden dump-datoen. - Kør recoverjob. Den ældre version af databasen var defekt, men forventes at kunne reetableres ved kørsel af jobbet 'recover' som beskre- vet i underafsnit 3.6.2. Hvis dette går godt er databasens tilstand som angivet nedenfor. - Reetablering afsluttet. Den ældre version af databasen er accepteret, men de opdate- ringer der måtte være foretaget i en mellemliggende kørsel vil ikke være indført i databasen. Reetableringskørslen afvikles som reorganiseringskørslen, idet dog 'get pbsletjob' erstattes af 'get pbreetabler'. 3_._6_._2_ _ _ _ _ _R_e_c_o_v_e_r_k_ø_r_s_e_l_ 3.6.2 Dette job søger at rette op på en defekt database. Hvis jobbet afsluttes med udskriften 'recover ikke mulig', skal der i stedet køres et reetableringsjob som angivet i underafsnit 3.6.1. Vurdering af udskriften fra en recoverkørsel vil ikke blive be- skrevet her og må således i alle tilfælde overlades til den sys- temansvarlige. \f Recoverkørslen afvikles som reorganiseringskørslen, idet dog 'get pbsletjob' erstattes med 'get pbrecover'. \f F_ 4_._ _ _ _ _ _ _ _ _U_D_S_K_R_I_F_T_E_R_ 4. Præsentation af data sker dels i form af batch-udskrifter og dels i form af online listninger på skærm, under anvendelse af samme udskriftsprogram. 4_._1_ _ _ _ _ _ _ _B_a_t_c_h_ _u_d_s_k_r_i_f_t_e_r_ 4.1 Batch udskrifter rekvireres ved følgende operationer (brugerens indtastning er understreget): '_E_S_C_'_ aktivr ESC-tasten att b_o_s_s_ type username and projectnumber <_u_s_e_r_>_ _2_7_0_0_0_0_ indtast tildelt brugernavn samt projektnr. g_e_t_ _p_b_u_d_s_j_o_b_ a_u_t_o_ _6_0_ . . (indtastning af udskriftkommandoer som . anført i afsnit 4.3) . . indtastning afsluttes ved aktivering af ESC-tasten c_l_e_a_r_ _u_s_e_r_ _u_d_j_o_b_ s_a_v_e_ _u_d_j_o_b_ _d_i_s_c_1_ s_c_o_p_e_ _u_s_e_r_ _u_d_j_o_b_ n_e_w_j_o_b_ _u_d_j_o_b_ _s_t_d_ l_o_g_o_ 4_._2_ _ _ _ _ _ _ _O_n_l_i_n_e_ _u_d_s_k_r_i_f_t_e_r_ 4.2 En online udskriftskørsel omfatter følgende operationer (brugerens indtastning er understreget): '_E_S_C_'_ aktivr ESC-tasten att s_o_s_ >r_u_n_ _<_u_s_e_r_>_ indtast tildelt brugernavn \f . (meddelelser fra systemet) . . i_ _u_d_s_k_r_i_v_ (udskriftsdialog under anvendelse af udskriftskommandoer som angivet i af- snit 4.3) x_ (afslutter udskriftskørslen) 4_._3_ _ _ _ _ _ _ _U_d_s_k_r_i_f_t_e_r_ _o_g_ _k_o_m_m_a_n_d_o_e_r_ 4.3 Systemet kan levere følgende typer udskrifter: - Kartotekslister, der viser rådata fra databasen. - Projektoversigter, der giver oversigter over systemets pro- jekter opdelt på UDV-projektkategorier. - Opfølgningslister, der giver oversigter over de tidsbegræn- sede aktiviteter med angivelse af, om de er forsinkede, igangværende eller kommende i forhold til tidsplanen. - Belastningsoversigter, der giver periodeopdelte oversigter over belastningerne i henhold til tidsplanen. - Aktivitetsgrafer, der giver grafiske afbildninger af tids- planen. - Periodeoversigter, der giver oversigter over de af systemet anvendte periodiceringer. Hver liste forsynes ved udskrift med udskrivningsdato og oplys- ning om den kommando, der har ført til udskriften, samt evt. si- denummer. Derudover kan udskriften som helhed forsynes med modta- ger og de enkelte lister kan forsynes med rekvirent. \f 4_._3_._1_ _ _ _ _ _U_d_s_k_r_i_f_t_s_k_o_m_m_a_n_d_o_e_r_ 4.3.1 De til udskrifterne knyttede kommandoer er følgende: kl.m kartoteksliste- og medarbejderdata, kl.p kartoteksliste-, projekt- og belastningsdata, po projektoversigt, po.a projekt- og aktivitetsoversigt, ol.m medarbejderorienterede opfølgningslister, ol.p projektorienterede opfølgningslister, bo.m medarbejderorienterede aktivitetsopdelte belast- ningsoversigter, bo.mp medarbejderorienteret projektopdelt belastnings- oversigt, bo.mt medarbejderorienteret total belastningsoversigt, bo.p projektorienterede aktivitets- og medarbejderop- delte belastningsoversigter, bo.pt projektorienteret belastningsoversigt opdelt på medarbejderkategorier, ag.p projektorienteret aktivitetsgraf, l.per periodeoversigt. 4_._3_._2_ _ _ _ _ _S_p_e_c_i_e_l_l_e_ _k_o_m_m_a_n_d_o_e_r_ 4.3.2 Til brug for udskriftsredigeringen findes følgende kommandoer: s_e_n_d_=_<_i_n_i_t_>_,_<_a_d_r_e_s_s_e_>_ Denne kommando kan angives som første kommando ved batch-ud- skrifter og vil bevirke, at udskriften forsynes med modta- ger. Modtageren vil samtidig blive noteret som rekvirent (se nedenfor). Parametre: <init> - initialer, tekst max. 4 tegn, <adresse> - tekst, max. 30 tegn. r_e_k_v_=_<_i_n_i_t_>_ Denne kommando vil bevirke, at de anførte initialer vil blive noteret som rekvirent for alle efterfølgende udskrifter indtil en ny 'rekv'-kommando er mødt. Parametre: <init> - initialer, tekst max. 4 tegn. \f s_i_d_e_=_<_t_y_p_e_>_ Specifikation af sidestørrelse for efterfølgende udskrifter, indtil ny 'side'-kommando er mødt. Udskriftsprogrammet tager imidlertid kun højde for sidens bredde. Parametre: <type> - angiver enten antal anslag pr. linie (heltal) eller et af nedennævnte papir- formater (tekst): a4 høj a4 tværs batch (default ved batchudskrifter) skærm (default ved onlineudskrifter). Derudover anvendes kommandoen 'x' som afslutningskommando i for- bindelse med online udskrifter. (Denne kommando er integreret i standardjobbet til batchudskrifter og skal derfor ikke medtages her). Til orientering kan det nævnes, at kommandoen 'batch' er integre- ret i standardjobbet til batchudskrifter til identifikation af udskriftsarten. Anvendelse af denne kommando som første kommando ved online udskrifter vil derfor umuliggøre en fornuftig dialog med udskriftsprogrammet; programmet vil dog kunne afsluttes med kommandoen 'x'. 4_._3_._3_ _ _ _ _ _P_a_r_a_m_e_t_r_e_ _t_i_l_ _u_d_s_k_r_i_f_t_s_k_o_m_m_a_n_d_o_e_r_ 4.3.3 Nedenfor gennemgåes de parametre, der kan angives i forbindelse med udskriftskommandoer. Alle parametre kan angives, men det er ikke alle parametre, der har virkning på en given kommando. Parametrene kan angives i vilkårlig rækkefølge. Komma anvendes som skilletegn. p_=_<_p_r_o_j_>_ Specificerer et projektnummer eller et projektnummer inter- val. Eksempler: p=273031: Proj.nr. 273031 \f p=273020-273099: Proj.nr. interval 273020-273099 p=27302*: Proj.nr. interval 273020-273029 p=2*****: Proj.nr. interval 200000-299999 Ved projektorienterede lister kan parametren i stedet angi- ves i forbindelse med kommandoen, eksempelvis svarer 'bo.pt=273031,...' til 'bo.pt,...,p=273031'. Anvendelse: afgrænsning af udskriftsomfanget. p_l_=_<_m_e_d_a_r_b_>_ Specificerer en projektleder (pl=<init>) eller alle projekt- lederne inden for en afdeling (pl=<afd>). Anvendelse: alternativt til p-parametren til afgrænsning af udskriftsomfanget for projektorienterede lister. m_=_<_m_e_d_a_r_b_>_ Specificerer en medarbejder (m=<init>) eller alle medarbej- dere inden for en afdeling (m=<afd>). Ved medarbejderorienterede lister kan parametren i stedet angives i forbindelse med kommandoen, eksempelvis svarer 'bo.mp=nb,...' til 'bo.mp,...,m=nb'. Anvendelse: afgrænsning af udskriftsomfanget for medarbej- derorienterede lister. M_m_m_ 1 1 1 <periodetype> =<periodeang> dvs. uge =<ugeang> eller måned =<månedsang> P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _0_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _0_ Specificerer dels en periodetype som uge eller måned samt eventuelt en periode eller et periodeinterval i analogi til p-parametren, idet der dog eventuelt foretages korrektion for invalide perioder frem til første valide periode. Så- fremt parametren er udeladt, antages periodetypen at være uge. Anvendelsen afhænger af udskriftstypen som nedenfor angivet. O_p_f_ø_l_g_n_i_n_g_s_l_i_s_t_e_r_: Periodeangivelsen opfattes som aktuel pe- riode samt en horisont med standardværdier henholdsvis ud- skriftsperiode og uendelig. Den aktuelle periode anvendes til afgrænsning mellem 'forsinkede', 'igangværende' og 'kom-\f mende' aktiviteter, mens horisonten anvendes til afgrænsning af listens omfang med hensyn til 'kommende' aktiviteter. P_e_r_i_o_d_i_s_e_r_e_d_e_ _l_i_s_t_e_r_ _(_b_o_._._._,_l_._p_e_r_)_: Angives en enkelt peri- ode, udskrives der periodeoversigter med den angivne perio- de; standardværdien er aktuel periode. Angives et periodein- terval, udskrives der eventuelt flere sammenhængende perio- deoversigter, således at hele periodeintervallet er omfat- tet. Periodeintervallet i hver oversigt er bestemt af side- bredden. s_=_<_s_t_a_t_u_s_a_n_g_i_v_e_l_s_e_>_ Specificerer ændringer i forhold til de statusværdier, der M_m_m_ som standard medtages i udskriften. Statusangivelsen opbyg- 9 ges som <fortegn><status> , hvor fortegnet '+' indikerer, 1 P_p_p_ at individer med den anførte status skal medtages i listen, mens fortegnet '-' indikerer, at individer med den anførte status skal udelades af udskriften. Et foranstillet '+' kan udelades. I tabellen nedenfor angives de fortegn, det i forbindelse med udskrifterne kan have effekt at anvende: plan aktiv ext konto hvil stop luk slut slet kl.m - + kl.p - - - - - - - - + po... - - - - - - - + + ol.. + - - + + + + + + bo... + - - - + + + + + ag.p + + - + + + + + + l.per f_a_k_t_o_r_=_<_t_a_l_>_ Specificerer en eventuel omregningsfaktor. Anvendelse: omregninger af belastninger i belastningsover- sigter ved multiplikation med <tal>/100 før ud- skrift. En eventuel omregning vil blive anført i udskriften. \f r_e_k_v_=_<_i_n_i_t_>_ Specifikation af rekvirent for den aktuelle udskrift, uaf- hængigt af eventuel 'rekv'-kommando - se denne. s_i_d_e_=_<_t_y_p_e_>_ Specifikation af sidestørrelse for den aktuelle udskrift uafhængigt af eventuel 'side'-kommando - se denne. \f F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_R_ 1 RCSL Nr. 42-i1373: B_e_m_a_n_d_i_n_g_s_p_l_a_n_l_æ_g_n_i_n_g_s_s_y_s_t_e_m_ _-_ _B_r_u_g_e_r_v_e_j_l_e_d_n_i_n_g_ Edith Rosenberg og Karsten Kynde, Marts 1980. Denne manual beskriver en række forhold omkring systemets opbygning, dog for en tidligere version af systemet. \f F_ B_._ _ _ _ _ _ _ _ _O_V_E_R_S_I_G_T_ _O_V_E_R_ _O_P_D_A_T_E_R_I_N_G_S_K_O_M_M_A_N_D_O_E_R_ B. \f F_ C_._ _ _ _ _ _ _ _ _R_E_O_R_G_A_N_I_S_E_R_I_N_G_S_K_Ø_R_S_E_L_ _-_ _U_D_S_K_R_I_F_T_S_E_K_S_E_M_P_L_E_R_ C. På næste side er angivet et eksempel på den udskrift der fremkom- mer ved reorganiseringskørslen som følge af kommandoerne: rename primout opdud convert opdud std Udskriften indeholder følgende oplysninger: 1: brugernavn, 2: starttidspunkt angivet ved år, måned, dato og klokkeslet, 3: udskrift vedrørende berørte projekter, medarbejdere og belastninger, 4: sluttidspunkt angivet som under 2, 5: opdateringsmarkering for databasefilerne. Disse skal alle være 0 - ellers har der været fejl under kørslen. \f F_\f F_ D_._ _ _ _ _ _ _ _ _P_E_R_I_O_D_E_T_A_B_E_L_L_E_R_ D. Til brug for opbygning af periodetabeller er der under projektnr. 1 indlagt en tabel over de uger, hvori antallet af arbejdsdage afviger fra 5. Det faktiske antal arbejdsdage er repræsenteret ved pseudo-belastninger på en pseudomedarbejder med initialerne 'qtid', knyttet til en aktivitet med ugenummeret som aktivitets- nummer. Månedstabeller opbygges ud fra en fast regel, der siger, at en uge hører til den måned, hvori onsdagen falder. Nedenfor anføres et eksempel på en ugetabel. \f F_ E_._ _ _ _ _ _ _ _ _O_V_E_R_S_I_G_T_ _O_V_E_R_ _U_D_S_K_R_I_F_T_S_K_O_M_M_A_N_D_O_E_R_ E. \f F_ F_._ _ _ _ _ _ _ _ _U_D_S_K_R_I_F_T_S_E_K_S_E_M_P_L_E_R_ F. På de følgende sider gengives kommenterede eksempler på udskrifter fra udskriftskørslen. F_._1_ _ _ _ _ _ _ _U_d_s_k_r_i_f_t_s_r_a_m_m_e_r_ F_._1_ I eksemplet nedenfor vises: a. Resultatet af udskriften ved kommandoen: send=nb,Lautrupbjerg 2. sal, der viser følgende data: a1: initialer angivet i send-kommando, a2: navn, a3: afdelingsnr. a4: adresse angivet i send-kommando, a2 og a3 udskrives kun, hvis medarbejderen er oprettet i medarbejderfilen. b. Overskriftseksempel, der viser følgende data: b1: rekvirent, hvis angivet, ellers blankt, b2: kommandoen, der er årsag til udskriften, b3: sidenr., der tælles op ved sideskift foranlediget af skift til nyt projekt eller ny medarbejder, b4: subsidenr., der tælles op ved sideskift i.f.m. fortsættelse af periodeopdelte udskrifter, b5: udskriftens navn, b6: udskrifttidspunkt, b3 og b4 angives kun i de udskrifter, hvor der er mulighed for flere sider eller subsider. c. Udskrift ved afslutning af udskriftprogrammel. \f F_\f F_ F_._2_ _ _ _ _ _ _ _K_a_r_t_o_t_e_k_s_l_i_s_t_e_ _-_ _m_e_d_a_r_b_e_j_d_e_r_e_ F.2 Udskriften viser følgende medarbejderdata: 1: medarbejder initialer, 2: medarbejder afdelingsnummer, 3: medarbejder kategori, 4: ansættelsesprocent, 5: medarbejder navn, 6: medarbejder status. \f F_ F_._3_ _ _ _ _ _ _ _K_a_r_t_o_t_e_k_s_l_i_s_t_e_ _-_ _p_r_o_j_e_k_t_e_r_ F.3 Udskriften viser projektdata samt de tilknyttede belastningsdata som følger: 1: projektnummer, 2: start- og sluttidspunkt for projektet angivet ved år og ugenr., 3: projektnavn, 4: projektstatus, 5: projektleder angivet ved initialer, 6: aktivitetsnummer, 7: start- og sluttidspunkt for aktivitet angivet ved år og ugenr., 8: aktivitetsnavn, 9: aktivitetsstatus, 10: medarbejder knyttet til belastningen angivet ved initialer, 11: løbende belastning inden for aktivitetsperioden angivet som antal dage pr. uge med en decimal, 12: absolut belastning inden for aktivitetsperioden angivet som antal dage med en decimal, 13: belastningsstatus, \f F_ F_._4_ _ _ _ _ _ _ _P_r_o_j_e_k_t_o_v_e_r_s_i_g_t_ F.4 Udskriften viser projekter opdelt i 6 kategorier efter projekt- nummerets 3. ciffer (dvs. 4. ciffer fra højre): 0: administrative projekter, 1: dokumentationsprojekter, 2: analyseprojekter, 3: udviklingsprojekter, 4: vedligeholdelsesprojekter, 5: supportprojekter, 6-9: øvrige projekter. For hvert projekt vises: 1: projektnr., 2: projektleder angivet ved initialer, eller 4 stjerner, 3: projektnavn 4: starttidspunkt angivet ved år og ugenr.; udelades dog ved starttidspunkt lig 0000. 5: sluttidspunkt angivet som under 4; udelades dog tillige ved sluttidspunkt lig 9999. Ved anvendelsen af kommandoen po.a i stedet for po, udskrives tillige analoge oplysninger for aktiviteterne som vist i det ef- terfølgende eksempel. \f F_\f F_\f F_ F_._5_ _ _ _ _ _ _ _O_p_f_ø_l_g_n_i_n_g_s_l_i_s_t_e_ _-_ _m_e_d_a_r_b_e_j_d_e_r_ F.5 For hver medarbejder udskrives en oversigt over de uafsluttede, tidsbegrænsede aktiviteter, som medarbejderen er knyttet til. Aktiviteterne grupperes i op til tre dellister: Forsinkede: Sluttidspunkt < skæringstidspunkt. Aktiviteterne sorteres primært efter sluttidspunkt. Igangværende: Starttidspunkt <= skæringstidspunkt <= sluttids- punkt. Aktiviteterne sorteres primært efter slut- tidspunkt. Kommende: Starttidspunkt > skæringstidspunkt. Aktiviteterne sorteres primært efter starttidspunkt. Skæringstidspunktet er normalt rekvireringstidspunktet, men kan ændres ved uge- eller måned-parametren. I denne kan tillige angives en tidshorisont for aktiviteter, der medtages i listen. Ved anvendelse af p-parametren kan projektintervallet indskræn- kes. Følgende data vises: 1: medarbejder initialer, 2: medarbejder afdeling, 3: medarbejder kategori, 4: medarbejderens ansættelsesprocent, 5: medarbejderens navn, 6: medarbejder status, 7: projektnummer, 8: projektnavn, 9: aktivitetsnr., 10: aktivitetsnavn, dog for akt. lig 0 teksten 'projektleder', 11: starttidspunkt for aktivitet angivet ved år og ugenr. 12: sluttidspunkt som ovenfor, \f 13: løbende belastning angivet i antal dage pr. uge med en decimal, 14: absolut belastning angivet i antal dage med en decimal, 15: aktivitetsstatus. \f F_ \f F_ F_._6_ _ _ _ _ _ _ _O_p_f_ø_l_g_n_i_n_g_s_l_i_s_t_e_ _-_ _p_r_o_j_e_k_t_e_r_ F.6 For hvert projekt udskrives en oversigt over de uafsluttede, tidsbegrænsede aktiviteter. Afsluttede eller tidsubegrænsede pro- jekter medtages dog ikke. Aktiviteterne grupperes i op til tre dellister: Forsinkede: Sluttidspunkt < skæringstidspunkt. Aktiviteterne sorteres primært efter sluttidspunkt. Igangværende: Starttidspunkt <= skæringstidspunkt <= sluttids- punkt. Aktiviteterne sorteres primært efter slut- tidspunkt. Kommende: Starttidspunkt > skæringstidspunkt. Aktiviteterne sorteres primært efter starttidspunkt. Skæringstidspunktet er normalt rekvireringstidspunktet, men kan ændres ved uge- eller måned-parametren. I denne kan tillige angives en tidshorisont for aktiviteter, der medtages i listen. Følgende data vises: 1: projektnummer, 2: projektnavn, 3: projektleder identificeret ved initialer, eller fire stjerner, 4: aktivitetsnummer, 5: aktivitetsnavn, 6: starttidspunkt for aktivitet angivet ved år og ugenr. 7: sluttidspunkt som ovenfor, 8: medarbejder knyttet til belastningen angivet ved initi- aler, 9: løbende belastning angivet som antal dage pr. uge med en decimal, 10: absolut belastning angivet som antal dage med en decimal. \f F_\f F_ F_._7_ _ _ _ _ _ _ _B_e_l_a_s_t_n_i_n_g_s_o_v_e_r_s_i_g_t_ _-_ _m_e_d_a_r_b_e_j_d_e_r_e_ F.7 Udskriften giver en oversigt pr. medarbejder over belastningen opgjort på aktiviteter, sluttende med en total belastningsover- sigt summeret over alle projekter. Ved hjælp af p-parametren kan projektintervallet indskrænkes. Be- lastninger fra aktiviteter, der således ikke medtages, modregnes i den disponible tid. Belastninger angives i antal persondage, men kan omregnes ved hjælp af faktor-parametren. Følgende data vises: 1: medarbejder initialer, 2: medarbejder navn, 3: medarbejder afdeling, 4: ansættelsesprocent, 5: medarbejder kategori, 6: periodeart, 7: første periode i oversigt angivet ved år-ugenr. eller år-månedsnr., 8: oversigt over medtagne perioder angivet som u-<ugenr.> eller som forkortet månedsnavn. 9: projektnr., 10: projektnavn, 11: aktivitetsnr., 12: aktivitetsnavn eller ved akt.nr. lig 0 teksten 'projekt- ledelse'. 13: evt. venstre-pil, der angiver, at starttidspunktet for aktiviteten er før første medtagne periode, 14: belastningen pr. periode inden for aktivitetsperioden, 15: evt. højre-pil, der angiver, at sluttidspunktet for ak- tiviteten er efter sidste medtagne periode, 16: belastning ialt fra de i oversigten medtagne aktivite- ter, 17: den totale tid korrigeret for evt. fridage i.h.t. perio- detabellen og modregnet for belastninger fra aktivitet- er, der ikke er medtaget i oversigten, \f 18: resttid beregnet som differencen mellem 17 og 16, 19: resttid akkumuleret over perioderne i oversigten. \f F_ F_._8_ _ _ _ _ _ _ _B_e_l_a_s_t_n_i_n_g_s_o_v_e_r_s_i_g_t_ _-_ _m_e_d_a_r_b_e_j_d_e_r_p_r_o_j_e_k_t_e_r_ F.8 Udskriften giver en medarbejderopdelt oversigt over belastninger- ne opgjort på projekter. Hver medarbejder afsluttes med en opgø- relse af ikke-projektbunden tid og udskriften som helhed afslut- tes med en total belastningsoversigt opdelt på medarbejderkatego- rier. Ved hjælp af p-parametren kan projektintervallet indskrænkes. Be- lastningen fra projekter, der således ikke medtages, modregnes i den disponible tid. Belastninger angives i antal persondage, men kan omregnes ved hjælp af faktor-parametren. Følgende data vises: 1: periodeart, 2: første periode i oversigten angivet som år-ugenr. eller år-månedsnr., 3: oversigt over medtagne perioder angivet som u-<ugenr.> eller som forkortet månedsnavn, 4: initialer, 5: projektnr., 6: projektnavn, 7: evt. venstre-pil, der markerer et starttidspunkt før første periode i oversigten, 8: belastning i projektperioden summeret over alle aktivi- teter, 9: evt. højre-pil, der markerer et sluttidspunkt efter sid- ste periode i oversigten, 10: ikke-projektsat tid, beregnet som disponibel tid minus belastningen fra projekterne, 11: medarbejder kategori, 12: belastning ialt fra de i oversigten medtagne medarbejde- re og projekter, 13: den totale disponible persontid korrigeret for evt. fri- dage i.h.t. periodetabellen og modregnet for belastnin- ger fra projekter, der ikke er medtaget i oversigten. 14: resttid beregnet som differencen mellem 13 og 12, 15: resttid akkumuleret over perioderne i oversigten. \f F_\f F_ F_._9_ _ _ _ _ _ _ _B_e_l_a_s_t_n_i_n_g_s_o_v_e_r_s_i_g_t_ _-_ _m_e_d_a_r_b_e_j_d_e_r_e_ _t_o_t_a_l_t_ F.9 Udskriften giver en medarbejderopdelt oversigt over totalbelast- ningerne summeret over alle projekter, afsluttende med en opgø- relse over totalbelastninger opdelt på medarbejderkategorier. Ved hjælp af p-parametren kan projektintervallet indskrænkes, hvorved belastninger fra projekter, der falder uden for projekt- intervallet, modregnes den disponible tid i stedet for at blive medtaget i belastningssummen. Belastninger angives i antal persondage, men kan omregnes ved hjælp af faktor-parametren. Følgende data vises: 1: periodeart, 2: første periode i oversigten angivet som år-ugenr. eller som år-månedsnr., 3: oversigt over medtagne perioder angivet som u-<ugenr.> eller som forkortet månedsnavn, 4: initialer, 5: belastning ialt for medarbejderen hidrørende fra samtli- ge projekter eller projektnummerintervallet specificeret i p-parametren, 6: disponibel tid for medarbejderen korrigeret for evt. fridage i.h.t. periodetabellen og modregnet for belast- ninger hidrørende fra projekter uden for det evt. speci- ficerede projektnr. interval, 7: resttid for medarbejderen beregnet som differencen mel- lem 5 og 6, 8: resttid akkumuleret over perioderne i oversigten, 9: medarbejderkategori, 10: belastning summeret over den pågældende medarbejder ka- tegori, 11: disponibel tid summeret som 10, 12: resttid summeret som 10, 13: akkumuleret resttid summeret som 10. \f F_\f F_ F_._1_0_ _ _ _ _ _ _B_e_l_a_s_t_n_i_n_g_s_o_v_e_r_s_i_g_t_ _-_ _p_r_o_j_e_k_t_e_r_ F.10 Udskriften giver en oversigt pr. projekt over belastningerne pr. projektmedarbejder opdelt på aktiviteter, sluttende med en total- belastning opdelt på medarbejderkategorier. Belastningerne angives i antal persondage, men kan omregnes ved hjælp af faktor-parametren. Følgende data vises: 1: projektnr., 2: projektnavn, 3: start- og sluttidspunkt for projektet angivet som år-ugenr., 4: projektleder angivet ved initialer, eller fire stjerner, 5: periodeart, 6: første periode i oversigten angivet som år-ugenr. eller som år-månedsnr., 7: oversigt over medtagne perioder angivet som u-<ugenr.> eller som forkortet månedsnavn, 8: aktivitetsnr., 9: aktivitetsnavn, dog for akt.nr. lig 0 teksten 'projekt- ledelse', 10: initialer, 11: medarbejderbelastninger inden for aktivitetsperioden, 12: sum af belastningerne inden for de medtagne perioder. 13: sum af tidsbegrænsede belastninger, der ligger ud over oversigtens sidste periode, 14: medarbejder kategori, 15: periodeopdelte belastningssummer opgjort på medarbejder- kategorier, 16: total belastningssum inden for de medtagne perioder op- gjort på medarbejderkategorier, 17: sum af tidsbegrænsede belastninger, der ligger ud over oversigtens sidste periode, opgjort på medarbejderkate- gorier. \f F_\f F_ F_._1_1_ _ _ _ _ _ _B_e_l_a_s_t_n_i_n_g_s_o_v_e_r_s_i_g_t_ _-_ _p_r_o_j_e_k_t_e_r_ _t_o_t_a_l_t_ F.11 Udskriften giver en projektopdelt oversigt over belastninger op- gjort på medarbejderkategorier, afsluttende med en opgørelse sum- meret over alle projekter i oversigten. Belastningerne angives i antal persondage, men kan omregnes ved hjælp af faktor-parametren. Følgende data vises: 1: periodeart, 2: første periode i oversigten angivet som år-ugenr. eller som år-månedsnr., 3: oversigt over medtagne perioder, angivet som u-<ugenr.> eller som forkortet månedsnavn, 4: projektnr. 5: projektnavn, 6: medarbejderkategori, 7: periodeopdelte belastningssummer opgjort på medarbejder- kategorier, 8: totalbelastningssum for de i oversigten medtagne perioder opgjort på medarbejderkategorier, 9: sum af tidsbegrænsede belastninger, der ligger udover o- versigtens sidste periode, opgjort på medarbejderkatego- rier. \f F_\f F_ F_._1_2_ _ _ _ _ _ _A_k_t_i_v_i_t_e_t_s_g_r_a_f_ F.12 Udskriften giver en grafisk oversigt over tidsforløbet for udvalgte projekter og/eller aktiviteter. Følgende data vises: 1: periodeart, 2: første periode i oversigten angivet som år-ugenr. eller år-månedsnr., 3: oversigt over medtagne perioder, angivet som u-<ugenr.> eller som forkortet månedsnavn, 4: projektnr., 5: projektnavn, 6: aktivitetsnr., 7: aktivitetsnavn, 8: evt. venstre-pil, der markerer et starttidspunkt før første periode i oversigten, 9: stjernemarkering af projekt- og/eller aktivitetsperio- der, 10: evt. højre-pil, der markerer et sluttidspunkt efter sidste periode i oversigten. \f F_ F_._1_3_ _ _ _ _ _ _P_e_r_i_o_d_e_o_v_e_r_s_i_g_t_ F.13 Udskriften giver en oversigt over de perioder, der anvendes i.f.m. periodeopdelte udskrifter. Følgende data vises: 1: periodeart, 2: første periode i oversigten angivet som år-ugenr. eller år-månedsnr., 3: periodenavne angivet som u-<ugenr.> eller som forkortet månedsnavn, 4: startuge angivet som år-ugenr. for oversigtens perioder, 5: startuge angivet som år-ugenr. for første periode efter sidste periode i oversigten (markerer afslutningen på sidste periode), 6: antal arbejdsdage i perioden i.h.t. periodetabellen. \f Side af 2 PD 7801 \f P_A_K_K_E_B_E_S_K_R_I_V_E_L_S_E_ 1_._ _ _ _ _ _P_a_k_k_e_n_a_v_n_ SW7801/1 COMAL. 2_._ _ _ _ _ _B_e_s_k_r_i_v_e_l_s_e_ Pakken indeholder COMAL, TTY-Emulator og kataloginitialiseringspro- gram. COMAL har indbygget faciliteter, som gør det muligt at tilslutte en V24-printer, at kommunikere med en anden datamat (V24) samt at be- nytte udstyr tilsluttet via et parallelt grænsesnit. 3_._ _ _ _ _ _V_a_r_i_a_n_t_e_r_ SW7801/1, 001 til dansk tastatur, danske fejltekster. SW7801/1, 002 til svensk tastatur, engelske fejltekster. SW7801/1, 003 til US-ASCII tastatur, engelske fejltekster. SW7801/1, 004 til tysk tastatur, engelske fejltekster. SW7801/1, 005 til UK-ASCII tastatur, engelske fejltekster. SW7801/1, 006 til bibliotekstastatur, danske fejltekster. 4_._ _ _ _ _ _D_i_s_t_r_i_b_u_t_i_o_n_ Pakken distribueres på n 8" diskette. 5_._ _ _ _ _ _D_i_s_k_e_t_t_e_f_o_r_m_a_t_e_r_ Der anvendes enkeltsidede, enkelt density 8" disketter. Disse skal være formatterede med en bloklængde på 128 bytes, 26 blokke pr. spor. \f 6_._ _ _ _ _ _D_o_k_u_m_e_n_t_a_t_i_o_n_ Dokumentationen til SW7801/1, 001 og SW7801/1, 006 er samlet i SDO 0xx: RC700 COMAL, der indeholder følgende manualer: RCSL No 42-i1578: RC700 COMAL, Brugermanual. Manualen beskriver (på dansk) brugen af COMAL systemet, som er implementeret på RC700. RCSL No 42-i1599: Supplement til RC700 COMAL brugermanual. Manualen er et supplement til RCSL No 42-i1578: RC700 COMAL, Bruger- manual. Den indeholder en beskrivelse af nogle nye funktioner i COMAL og giver en supplerende beskrivelse af specielle faciliteter (semigrafik, xy-adressering m.m. Dokumentation til SW7801/1, 002, 003, 004 og 005 er samlet i SDO 0xx: RC700 COMAL User>s Guide, der indeholder følgende manualer: (engelsk version af brugermanual + supplement). Brugen af TTY-emulator, kataloginitialiseringsprogram samt systemge- nereringsprogram er beskrevet i "RC700 Brugervejledning", som leve- res med RC700 mikrodatamaten. Heri er også beskrevet opstart af COMAL systemet. 7_._ _ _ _ _ _M_a_s_k_i_n_e_l_ Pakken kan anvendes på en RC700 mikrodatamat (RC702 eller nyere mo- del) med 64 Kb og 1 maxidiskettestation (RC762). \f Side af 2 PD 7501 \f P_A_K_K_E_B_E_S_K_R_I_V_E_L_S_E_ 1_._ _ _ _ _ _P_a_k_k_e_n_a_v_n_ SW7501/1 COMAL. 2_._ _ _ _ _ _B_e_s_k_r_i_v_e_l_s_e_ Pakken indeholder COMAL, TTY-Emulator, kataloginitialiseringsprogram samt disketteformatteringsprogram. COMAL har indbygget faciliteter, som gør det muligt at tilslutte en V24-printer, at kommunikere med en anden datamat (V24) samt at be- nytte udstyr tilsluttet via et parallelt grænsesnit. 3_._ _ _ _ _ _V_a_r_i_a_n_t_e_r_ SW7501/1, 001 til dansk tastatur, danske fejltekster. SW7501/1, 002 til svensk tastatur, engelske fejltekster. SW7501/1, 003 til US-ASCII tastatur, engelske fejltekster. SW7501/1, 004 til tysk tastatur, engelske fejltekster. SW7501/1, 005 til UK-ASCII tastatur, engelske fejltekster. SW7501/1, 006 til bibliotekstastatur, danske fejltekster. 4_._ _ _ _ _ _D_i_s_t_r_i_b_u_t_i_o_n_ Pakken distribueres på n 5 1/4" diskette. 5_._ _ _ _ _ _D_i_s_k_e_t_t_e_f_o_r_m_a_t_e_r_ Der anvendes dobbeltsidede, dobbelt density 5 1/4" disketter. Disse kan ved hjælp af disketteformatteringsprogrammet formatteres rig- tigt, dvs. enkelt density, bloklængde 128 bytes. \f 6_._ _ _ _ _ _D_o_k_u_m_e_n_t_a_t_i_o_n_ Dokumentationen til SW7501/1, 001 og SW7501/1, 006 er samlet i SDO 0xx: RC700 COMAL, der indeholder følgende manualer: RCSL No 42-i1578: RC700 COMAL, Brugermanual. Manualen beskriver (på dansk) brugen af COMAL systemet, som er implementeret på RC700. RCSL No 42-i1599: Supplement til RC700 COMAL brugermanual. Manualen er et supplement til RCSL No 42-i1578: RC700 COMAL, Bruger- manual. Den indeholder en beskrivelse af nogle nye funktioner i COMAL og giver en supplerende beskrivelse af specielle faciliteter (semigrafik, xy-adressering m.m. Dokumentation til SW7501/1, 002, 003, 004 og 005 er samlet i SDO 0xx: RC700 COMAL User>s Guide, der indeholder følgende manualer: (engelsk version af brugermanual + supplement). Brugen af TTY-emulator, kataloginitialiseringsprogram, systemgenere- ringsprogram samt disketteformattering er beskrevet i "RC700 Bruger- vejledning", som leveres med RC700 mikrodatamaten. Heri er også be- skrevet opstart af COMAL systemet. 7_._ _ _ _ _ _M_a_s_k_i_n_e_l_ Pakken kan anvendes på en RC700 mikrodatamat (RC702 eller nyere mo- del) med 64 Kb og 1 minidiskettestation (RC761). \f Side af 2 PD 7502 \f P_A_K_K_E_B_E_S_K_R_I_V_E_L_S_E_ 1_._ _ _ _ _ _P_a_k_k_e_n_a_v_n_ SW7502/2 PASCAL. 2_._ _ _ _ _ _B_e_s_k_r_i_v_e_l_s_e_ Pakken indeholder UCSD-Pascal R med oversætter, fortolker, editor, assembler, hjælpeprogrammer m.m. Endvidere er et disketteformatte- ringsprogram inkluderet. 3_._ _ _ _ _ _V_a_r_i_a_n_t_e_r_ Pakken findes kun i en udgave, idet brugeren under opstarten kan specificere, hvilket tastatur, der anvendes. 4_._ _ _ _ _ _D_i_s_t_r_i_b_u_t_i_o_n_ Pakken distribueres på fire 5 1/4" disketter, hvoraf den ene ("load- disketten") indeholder drivprogrammer, formatteringsprogram m.m., specielt beregnet til RC700, mens de 3 øvrige indeholder de filer, som udgør et totalt UCSD-Pascal system. 5_._ _ _ _ _ _D_i_s_k_e_t_t_e_f_o_r_m_a_t_e_r_ Der anvendes dobbeltsidede, dobbelt density 5 1/4" disketter. Disse kan ved hjælp af disketteformatteringsprogrammet formatteres rig- tigt, dvs. enkelt density, bloklængde 128 bytes. \f 6_._ _ _ _ _ _D_o_k_u_m_e_n_t_a_t_i_o_n_ Dokumentationen til SW7502/2 er samlet i SDO 0xx: RC700 PASCAL, User>s Guide, der indeholder følgende manualer: RCSL No 42-i1583: Introduction to the UCSD Pascal System for the RC700 Microcomputer. The manual gives a short introduction to the UCSD Pascal System used in the RC700 Microcomputer. RCSL No 42-i1515: UCSD Pascal, User>s Guide. This manual (published by Softech Microsystems) gives a detailed description of the UCSD-Pascal system, however, it does not contain a description of the Pascal Programming language. 6_._1_ _ _ _ _Y_d_e_r_l_i_g_e_r_e_ _d_o_k_u_m_e_n_t_a_t_i_o_n_ RCSL No 42-i1530 Beginners Guide for the UCSD Pascal System (Kenneth L. Bowles). RCSL No 42-i1609 Pascal User Manual and Report (Jensen & Wirth). Disse to bøger er ikke inkluderet i SW7502/2, men det må anbefales at brugere af pakken anskaffer de to bøger. 7_._ _ _ _ _ _M_a_s_k_i_n_e_l_ Pakken kan anvendes på en RC700 mikrodatamat (RC702 eller nyere mo- del) med 64 Kb og 1-2 minidiskettestationer. Det anbefales, at der anvendes konfigurationer med 2 diskette stationer. Der kan tilslut- tes en V24-printer, som f.eks. RC861. \f «eof»