|
|
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»