|
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: 125440 (0x1ea00)
Types: TextFile
Names: »D10«
└─⟦53be6501e⟧ Bits:30005867/disk02.imd Dokumenter (RCSL m.m.)
└─⟦this⟧ »D10«
\f
Page of 3
CHECKIO Søren Lauesen/May 1970 RCSL No 55-D70
\f
1_._ _ _ _ _ _ _ _ _G_E_N_E_R_A_L_
Checkio may supervise all actions on a particular document. That
is performed in the following way: Assume that checkio is
executed in a job process called d_e_v_. Then all messages sent to
dev are passed on by checkio to the document supervised. The
answer from the document is passed back to the original sender
process, which seems to be handling the document in the normal
way.
Checkio can easily print all messages and answers as they are
passed on, and you can later find out about parity errors from
the document, rereading etc.
2_._ _ _ _ _ _ _ _ _C_A_L_L_
The process dev must be created with a protection register which
enables it to modify the contents of all other processes.
Checkio must be called with one parameter specifying the name of
the document to be supervised. The messages and answers are
printed on the current output of dev. A console communication to
start dev may look like this:
to s
new dev size 5000 pr 1 2 3 4 5 6 7 pk 1 run
to dev
o lp ; print on the line printer
checkio t6 ; check the document t6
You will then see nothing from dev until some messages are sent
to it, for instance from another job started like this:
to s
new sl run
to sl
s=set mto dev ; edit to the 'magnetic tape' dev,
s=edit tre ; which acts as the magnetic tape t6.
\f
Dev will now start listing the communication on the line printer.
When you have finished using dev for supervising of t6, you can
proceed like this:
to s
proc dev break ; the remaining output from dev appears on
; the printer.
*** fp break
checkio reader ; select a new document etc.
3_._ _ _ _ _ _ _ _ _R_E_S_E_R_V_I_N_G_ _T_H_E_ _D_O_C_U_M_E_N_T_
Checkio cannot simulate those actions on a document which involve
reservation of the document, creation of it as an area process
etc. So a process which tries to reserve dev (the document) or
create it as an area process, a_n_d_ checks the result, cannot be
supervised.
To remedy the problem for other processes, checkio proceeds as
follows when the document does not exist: First a call of create
area process is attempted. If this does not succeed, checkio
outputs the console message
mount <document>
and performs the usual wait action. Then the operation is
repeated before the original sender gets his answer.
If the document rejects the message, checkio reserves the
document and repeats the operation before the original sender
gets his answer.
\f
4_._ _ _ _ _ _ _ _ _O_U_T_P_U_T_
The output from checkio consists of one line for each message:
message <operation> <mode> <first addr> <last addr> <segment> <sender>
and one line for each answer:
answer <bits of logical status> <bytes> <characters> <file> <block>
If the answer is not transmitted back to the original sender, the
reason is printed as one of the lines
create
<result> reserved
\f
LIST OF CONTENTSPage
1 INTRODUCTION.............................................5
2 OVERVIEW OF USER APPLICATIONS............................7
2.1 Invoicing Module.....................................7
2.1 Inventory Module.....................................8
2.3 Debtor/Creditor Module...............................8
2.4 Order Module.........................................8
2.5 Daily Statistics.....................................9
2.6 Data Entry to Batch Systems..........................9
3 USER OPERATION...........................................10
4 USERS' TERMINAL EQUIPMENT................................13
4.1 Description of Terminal Equipment....................15
5 SERVICE CENTRE EQUIPMENT.................................17
5.1 RC 8000..............................................20
5.2 Peripherals..........................................20
6 SOFTWARE PACKAGE.........................................23
6.1 General Software Tools...............................23
6.1.1 DUETCOM........................................23
6.1.2 DUET System....................................23
6.1.3 Database Systems...............................24
6.1.3.1 DATABASE80.............................25
6.1.3.2 SODA...................................26
6.1.3.3 DB-Utilities...........................26
6.1.4 GENIUS.........................................27
6.2 TELEDATA System Programs.............................27
6.2.1 TELEOP's Role in the Running System............28
6.3 TELEDATA Application Modules.........................30
6.3.1 Online Functions...............................30
6.3.2 Daily Statistics...............................34
6.3.3 DB Reports.....................................34
7 SERVICE CENTRE OPERATION.................................35
8 MODEL SOLUTION...........................(Under Preparation)
9 INSTALLING THE TELEDATA..................(Under Preparation)\f
1 I_n_t_r_o_d_u_c_t_i_o_n_
TELEDATA is a system for the performance of administrative data
processing tasks in the r_e_a_l_-_t_i_m_e_ mode.
TELEDATA is a multi-user service centre system. In other words,
it is capable of serving a number of users simultaneously; these
users utilize the same computer, programs and database.
Each user is equipped with remote terminals connected o_n_l_i_n_e_ to
the service centre computer. This connection is established
through the telephone network, usually via leased lines.
The items of data typed in will be processed 'immediately' there-
by enabling an interaction of the system in the user's daily
work. For example, entered invoice data may result in a message
from the system informing the user that the article for which
invoicing has been attempted is not available in sufficient quan-
tity (stock low).
TELEDATA consists of typical on line applications such as:
invoicing, order processing, inventory control and debtor/-
creditor control. In addition the system provides an accumula-
tion of data which can be used by batch systems for financial
control, sales statistics, etc.
The first version of TELEDATA has been running routinely since
1971 in RC's Service Centre in Oslo, and since 1972 in RC'sSer-
vice Centre in Copenhagen. A large number of users are, at pre-
sent (November 1977), connected to the systems installed within
the RC Group. Furthermore, a number of non-RC Service Centres
have the system under implementation.
A new version of TELEDATA (version 3) has now been developed. It
is based on the principles and concepts of the first version.
But:
a) As a result of the experience gained from version 1 a set of
new user-applications have been implemented.
b) The new version uses the standard RC database description
system. It has thereby been possible to use a number of
advanced DB Utilities e.g. programs for the reorganisation
and restructuring of a database. \f
c) High priority has been given to system maintainability.
d) The system has been designed to facilitate easy adaption to
the individual service centre's requirements.
TELEDATA is especially designed for service centres who for a
number of years have been offering a Financial Control Service
using batch systems.
This class of service centres have found themselves facing a
steadily increasing demand from their customers for an on-line,
real-time service. Often they consider the possibility of deve-
loping their own systems using the existing hardware, but they
quickly discover the extent of this development task together
with the amount of hardware expansion necessary.
TELEDATA gives these service centres an alternative possibility.
In a relatively short time and with limited resources they can
offer their customers an on-line, real-time service thanks to
TELEDATA. \f
F_ 2 O_v_e_r_v_i_e_w_ _o_f_ _U_s_e_r_ _A_p_p_l_i_c_a_t_i_o_n_s_
By user we mean end-user, that is the companies which avail
themselves of the service centre's TELEDATA-service.
TELEDATA includes the following applications:
a) Invoicing
b) Inventory Control
c) Debtor/Creditor Control
d) Order Processing
e) Data Entry to Batch Systems
T_ 2.1 I_n_v_o_i_c_i_n_g_ _M_o_d_u_l_e_
The invoicing routine uses information stored in a data base
&_ (item records, customer records, etc.) thus reducing the input
necessary to generate an invoice.
Invoicing causes debiting of the customers account and stockad-
justment to occur immediately and automatically. A comprehensive
set of charging and discount rules can be activated automatical-
ly.
The i_n_v_o_i_c_e_ _l_a_y_o_u_t_ can be programmed for each individual user.
An invoice can include these line types:
1) item (article)
2) addition (surcharge)
3) item group discount
4) comment
Back orders can be generated automatically during invoicing.
At the end of the day an invoice journal will be produced.
\f
T_ 2.2 I_n_v_e_n_t_o_r_y_ _M_o_d_u_l_e_
The inventory module keeps constant track of the quantities of
&_ each article in stock and warns the operator when stock levels
reach a specified minimum (during invoicing or order entry).
Stock intake is entered in a separate routine, whereas invoicing
causes automatic adjustment of stock quantity.
Information on a specific article is easily obtained through the
enquiry facility.
At the end of the day a reordering list will be produced.
T_ 2.3 D_e_b_t_o_r_/_C_r_e_d_i_t_o_r_ _M_o_d_u_l_e_
Debtor payment registration occurs via the open-item technique.
Enquiries on open-items are easily made.
&_ Customers' accounts are automatically debited or credited when
an invoice, credit note or payment is entered. The operator is
warned when a customer exceeds his specified credit limit.
The creditor routines work in almost the same way as the debtor
routines.
T_ 2.4 O_r_d_e_r_ _M_o_d_u_l_e_
The order module handles sales orders and purchase orders. It
deals with the accumulation of 'orders to be delivered in the
&_future' and 'purchases to be received in the future'. Orders,
once entered, can be further processed and enquired upon.
The order types are: reservation, back order, and quotations.
The sales order part of the order module is fully integrated
with the invoicing module so that invoicing of a complete order
(or part of an order) can be performed by entering simple codes
at the keyboard. Stock quantity and debtor balance are automa-
tically adjusted. In addition to invoices order confirmation
notes can be produced.
Purchase orders are handled in almost the same way as sales
orders.
\f
Many types of enquiries on orders can be made to the system.
For instance, information can be obtained on the contents of an
order, on articles to be delivered to a specific customer in a
specific time interval, back orders on a specific article, and
so on.
For a specific item a profile of future stock can be displayed.
Such a stock profile is based on the current stock level, recor-
ded sales orders and recorded purchase orders for that item.
T_ 2.5 D_a_i_l_y_ _S_t_a_t_i_s_t_i_c_s_
During the day the system generates data for daily statistics,
&_ such as:
invoice journal
receipts list
credit excess list
reordering list
order survey
stock entry list.
In addition to these lists, which show the events of the day,
the user can order reports based on the contents of the data-
base.
T_ 2.6 D_a_t_a_ _E_n_t_r_y_ _t_o_ _B_a_t_c_h_ _S_y_s_t_e_m_s_
In addition to the updating of the database and output process-
ing the system generates data records which can be used in batch
&_systems. In order to make the best possible use of such systems
it is possible to type in items of information, via the termi-
nal, that are not used by TELEDATA but are simply passed on to
the batch systems. An example of this type of batch processing
could be the generation of sales statistics.
TELEDATA is not tied to any specific batch system. It has, in
fact, been implemented with several batch systems. \f
F_ 3 U_s_e_r_ _O_p_e_r_a_t_i_o_n_
The user can login and logout as he wishes. The login procedure
involves giving a password to TELEDATA for security reasons.
This password can be maintained by the user as required. Once
the user is logged in he can enter information at the keyboard.
T_ U_S_E_R_ _O_P_E_R_A_T_I_O_N_
INPUT
T_R_A_N_S_A_C_T_I_O_N_S_:_
RECORD MAINTENANCE
ORDER
INVOICE
ETC.
SERVICE
CENTRE
DISPLAY
A_N_S_W_E_R_S_:_
ORDER
CUSTOMER
PRINTOUT
V_O_U_C_H_E_R_S_:_
INVOICE
CREDIT NOTE
ORDER CONFIRMATION
ETC.
&_
The user is equipped with one or more keyboard/display units and
one or more printers. The operator keys in transactions at the
keyboard and receives warnings, error messages and answers to
enquiries on the display. Vouchers are output on the
printer(s).
\f
T_ All information entered into the system is carried by trans-
&_ actions, i.e. units of input data.
Transactions are used to perform:
record maintenance (creation, alteration, deletion)
order creation
invoicing
enquiries
etc.
The specific syntax of a transaction depends on the type of
transaction. Transactions can also be simple transactions or
voucher transactions. Simple transactions are independent where-
as voucher transactions are interdependent and must be written
in a specific order.
E_x_a_m_p_l_e_s_:_
S_i_m_p_l_e_ _t_r_a_n_s_a_c_t_i_o_n_s_:_
SM 10101 500 (stock movement +500 pcs of item 10101)
MC 102 D 12 (modify customer number 102 to 12% discount)
?I 10101 (enquiry - item 10101)
?C 101 B (enquiry - customer 101 balance)
Each line represents a transaction. Each transaction is preceded
by a line code defining the transaction type.
The first transaction consists of a line code (SM) followed by a
key (10101) followed by data (500). The second transaction con-
sists of a line code (MC), followed by a key (102), followed by
an information code (D) pointing out the relevant field in the
record in question. The new value of this field will be 12.
Note: The line code mnemonics (SA, MC, ?I, ?C, etc.) are chosen
by the service centre to suit local language.
T_ V_o_u_c_h_e_r_ _t_r_a_n_s_a_c_t_i_o_n_s_
IC 101 (invoice head - customer no. 101)
I 10101 5 (invoice item - 5 pcs. of item 10101)
I 10506 8 (invoice item - 8 pcs. of item 10506)
F (invoice finish).
&_ \f
Because TELEDATA is a real time system response to transactions
is immediate. For example, if a customer exceeds his credit li-
mit a warning appears on the display so that the operator can
take the appropriate action. Also, the display of a voucher (or-
der or invoice) while typing in allows corrections to be made up
until the 'voucher end' line code is given.
In order to minimize waiting time communication between the user
and the computer takes place as follows:
- the user types in the first line
- the system starts processing this, and in the meantime
- the user can type in the second line,
- when the system has processed the first line, a possible
answer is sent to the user
- the user can type in a new line while
- the system is processing the second line etc.
Should the user want only one line to be processed, e.g. an in-
quiry, the second input line may just be a blank line, which
means that it only consists of the character for new line.
All vouchers are generated and recorded on disc files. The user
can obtain hard copies of these vouchers at any time and in any
number. The disc copy is deleted only when a 'print out accep-
ted' line code is given to the system.
\f
F_ 4 U_s_e_r_s_'_ _T_e_r_m_i_n_a_l_ _E_q_u_i_p_m_e_n_t_
User terminal equipment consists of one or more display/key-
boards and probably one or more printers. Any combination of
display/keyboards and printers may be used. Moreover, a terminal
installation need not be limited to a single location on the
user's premises - equipment can be placed where it is most
needed.
Where a user has a number of display/keyboards and printers,
concentrators can be used to reduce transmission costs.
If the service centre uses RC NET then the facilities provided
by the network are available to the user.
The size and capacity of the terminal installation depends on
the individual user's cost and throughput requirements.
T_ Examples of 4 common terminal configurations are described
below:-
T_y_p_e_ _1_:_
MODEM
300 bps - 1200 bps
full duplex
&_
This is a low-cost solution. But simultaneous typing in at the
keyboard and output of, for example, invoices is not possible. \f
T_ T_y_p_e_ _2_:_
MODEM
300 bps
full duplex
MODEM
1200 bps
half duplex
&_
Output from the computer to the printer and typing in at the
display/keyboard can occur simultaneously.
T_ T_y_p_e_ _3_:_
MODEM
300 bps
full duplex
MODEM
1200 bps
&_ half duplex
Output from the computer to the printer and typing in at the
keyboards can occur simultaneously. This terminalconfiguration\f
differs from type 2 only in that the printer is shared by
several keyboards thereby utilizing the printer's capacity more
fully.
T_ T_y_p_e_ _4_:_
CONCENTRATOR MODEM
1200/4800 bps
half duplex
&_
This configuration is similar to type 3 but transmission costs
are considerably reduced by the introduction of a concentrator.
4.1 D_e_s_c_r_i_p_t_i_o_n_ _o_f_ _T_e_r_m_i_n_a_l_ _E_q_u_i_p_m_e_n_t_
R_C_ _8_2_2_ _A_l_p_h_a_n_u_m_e_r_i_c_ _D_i_s_p_l_a_y_/_K_e_y_b_o_a_r_d_
- Teletype compatible
- upper/lower case with separate numerics
- 24-line, 80-character display
- V.24 interface
- 50 to 9600 bps
R_C_ _8_6_6_ _S_e_r_i_a_l_ _P_r_i_n_t_e_r_
- 7 x 7 dot matrix printer
- up to 132 positions per line
- printing speed of 180 characters per second
50 full lines per minute or
85 half lines per minute
- V.24 interface
- up to 4 copies \f
R_C_ _8_0_0_ _M_o_d_e_l_ _4_ _C_o_n_c_e_n_t_r_a_t_o_r_
- a concentrator with a tape cassette, autoload device
and a display/keyboard included
- one printer can be connected
- 4 display/keyboards can be connected
- max. 2400 bps, synchronous transmission, half duplex
protocol, 2 or 4-wire line
R_C_ _8_0_0_ _M_o_d_e_l_ _2_1_ _C_o_n_c_e_n_t_r_a_t_o_r_
- 8 input/output channels for display/keyboard and
printers - in any combination
- max. 4800 bps half/full duplex, synchronous trans-
mission
TELEDATA is not tied to this specific terminal equipment - new
RC equipment, in particular, will be applicable to the TELEDATA
system. \f
F_ 5 S_e_r_v_i_c_e_ _C_e_n_t_r_e_ _E_q_u_i_p_m_e_n_t_
The TELEDATA System runs on the RC 8000 Computer. The first
configuration shown is a start-up installation. The paper tape
equipment, RC 3665 and RC 3676, is not absolutely necessary.
T_ S_t_a_r_t_-_u_p_ _C_o_n_f_i_g_u_r_a_t_i_o_n_
TEGNING
&_ The number of users is limited by the number of multiplexer
ports. \f
The extended configuration consists of the start-up configura-
tion plus an I/O Device Controller, 2 synchronous multiplexers,
2 asynchronous multiplexers, a console, and 1 disc storage mo-
dule. This configuration can, for example, support 48 display/
keyboards and 30 printers corresponding to 28 users (depending
on their size/requirements).
T_ E_x_t_e_n_d_e_d_ _C_o_n_f_i_g_u_r_a_t_i_o_n_
TEGNING
&_ \f
The diagram on the previous page emphasized the service
equipment.
T_ The diagram below illustrates the many different user configura-
tions that can be connected to such an installation.
TEGNING
&_ See also Section 4. Users' Terminal Equipment. \f
T_ 5.1 R_C_ _8_0_0_0_
RC 8000 is a fourth generation, medium-scale, general purpose
computer system.
&_
As with most modern computers, RC 8000 is built up around a data
bus. The data bus structure allows core memory to be built up
from modules having different speeds and also permits the con-
nection of a large number of peripherals.
'Slow' peripherals like line printers, terminal displays, and
communication channels can be coupled through an I/O Device
Controller - RC 8301. The extra load of controlling peripherals
is hereby removed from the RC 8000 itself.
RC 8000 operating system, because of its modular construction,
is ideal for both small minicomputers and large computer
systems. Characteristics of the operative system are that it
allows, simultaneous running of batch and remote job entry,
transaction oriented terminals and on-line program running.
Standard programming languages are: assembler, ALGOL, and
FORTRAN.
T_
5.2 P_e_r_i_p_h_e_r_a_l_s_
R_C_ _8_3_0_ _S_i_l_e_n_t_ _P_r_i_n_t_e_r_/_K_e_y_b_o_a_r_d_ _(_M_a_i_n_ _C_o_n_s_o_l_e_ _D_e_v_i_c_e_)_
- thermo-matrix printer - therefore completely silent
- 64-character ASCII alphabet
- 6 lines per inch
&_ - 80 characters per line
R_C_ _8_2_2_4_ _D_i_s_c_ _S_t_o_r_a_g_e_ _M_o_d_u_l_e_s_
- 66 Mbyte capacity
- 4038 bpi bit density (outer track)
6038 bpi bit density (inner track)
- average access time 30 ms
R_C_ _3_6_1_6_ _H_i_g_h_ _S_p_e_e_d_ _M_a_g_n_e_t_i_c_ _T_a_p_e_ _U_n_i_t_
- automatic tape threading and loading
- vacuum-column buffers for gentle tape-handling
- 9 track, 800/1600 bpi
- 60 000/120 000 bytes per second transfer rate
- IBM, NRZ1 and ANSI codes \f
R_C_ _3_6_4_2_ _6_0_0_ _l_p_m_ _L_i_n_e_ _P_r_i_n_t_e_r_
- drum printer
- many standard drum versions
- 64 or 96-character, character sets
&_ - 136 characters per line
R_C_ _3_6_8_1_ _4_-_l_i_n_e_ _B_S_C_ _M_u_l_t_i_p_l_e_x_e_r_
- serial synchronous transmission
- up to 9600 bps
- CCITT V.24 compatible
- V.28 signal levels
- full or half duplex
R_C_ _3_6_8_2_ _8_-_l_i_n_e_ _A_s_y_n_c_h_r_o_n_o_u_s_ _M_u_l_t_i_p_l_i_x_e_r_
- 40 to 9600 bps
- CCITT v.24 compatible
- V.28 signal levels
- half or full duplex
R_C_ _3_6_6_5_ _P_a_p_e_r_ _T_a_p_e_ _P_u_n_c_h_
- compact unit
- punching speed, 75 characters per second,
asynchronous
- punches 5, 7 and 8-channel ISO standard tape
R_C_ _3_6_7_6_ _P_a_p_e_r_ _T_a_p_e_ _R_e_a_d_e_r_
- reads 8-channel ISO standard tape
- reading speed, 500 characters per second
Demonstration Equipment:
R_C_ _8_2_2_ _A_l_p_h_a_n_u_m_e_r_i_c_ _D_i_s_p_l_a_y_/_K_e_y_b_o_a_r_d_
- Teletype compatible
- upper/lower case with separate numerics
- 24-line, 80-character display
- V.24 interface
- 50 to 9600 bps \f
R_C_ _8_6_6_ _S_e_r_i_a_l_ _P_r_i_n_t_e_r_
- 7 x 7 dot matrix printer
- up to 132 positions per line
- printing speed of 180 characters per second
50 full-lines per minute
85 half-lines per minute
- V.24 interface
- up to 4 copies.\f
F_ 6 S_o_f_t_w_a_r_e_ _P_a_c_k_a_g_e_
The TELEDATA Software Package consists of:
1) General Software Tools
2) TELEDATA System Programs
3) TELEDATA Application Modules
The purpose of this division is to achieve a well-structured
system which is easy to maintain and frees the application pro-
grammer/maintainer from the more systems-oriented tasks.
6.1 G_e_n_e_r_a_l_ _S_o_f_t_w_a_r_e_ _T_o_o_l_s_
Tools is a category of programs which perform general functions.
Tools are interposed between Basic Software ('hard software')
and application software. A short description of the Tools used
by TELEDATA follows.
T_ 6.1.1 D_U_E_T_C_O_M_
DUETCOM is a terminal handler/transaction router. It handles all
communication between terminal equipment and the TELEDATA System
&_ itself. DUETCOM contains a catalog of users' terminal equipment
and a coroutine for each display/keyboard and for each printer.
The coroutine technique allows DUETCOM, amongst other things, to
route output to several printers simultaneously.
T_ 6.1.2 D_U_E_T_ _S_y_s_t_e_m_
DUET is an interpretive programming system. It consists of a
compiler and an interpreter ('DUET-machine').
&_
The DUET language is a high level, general-purpose programming
language facilitating structured programming. TELEDATA'son-line
applications are programmed in the DUET language.
DUET contains special facilities for input/output, including
communication with a database, which makes it very attractive
for programming, for example, TELEDATA applications.
The DUET System contains mechanisms rendering it insensitive to
minor programming errors. That is, if a programming error is\f
detected then an 'escape function' will cause a jump to a pre-
determined program point where processing will continue, thereby
avoiding a system breakdown. This escape facility is often used
in TELEDATA because the TELEDATA online application modules are
often updated at the service centres. If, for example a new
transaction routine containing errors is implemented, then the
user cannot use the transaction (an error message will appear),
but he can still use all others. In other words TELEDATA
continues to function.
T_ 6.1.3 D_a_t_a_b_a_s_e_ _S_y_s_t_e_m_s_
TELEDATA uses RC's basic database system - the CF System (Con-
nected Files). The diagram below shows the structure of the TELE-
DATA Database - in other words, the files making up the database
and the relations between them.
&_ \f
The CF System is based on two file types - master files and list
files. Master files are shown as rectangles, list files as dia-
monds.
Master files are organised index sequentially. They can be
accessed either directly or sequentially. A master file record
can be the mother record for one or more lists.
Lists are represented by arrows in the diagram. List is a term
used for a relation between two files under the CF System. A
list enables a record in one file to act as a mother record for
records in another (daughter) file, which is stored physically
in a list file.
A list file is a sequential access file where the records are
organized in chains. The records in the list file will always be
'daughters' of a mother record in another file. Access of a
chain in the list file must be preceded by an access of the cor-
responding mother record.
NOTE: Those familiar with CODASYL terminology will observe the
use of mother record for owner record, and daughter record
for member record.
The master records (see diagram) contain data on entities such
as debtors/creditors, items (articles), orders etc.
The list records contain additional data relating to the enti-
ties and may, furthermore, express a relationship between these
entities.
The CF-System consists of a number of procedures (subroutines)
with which operations on a database can be performed. These
procedures are not referred to directly from the DUET language,
in which TELEDATA applications are written, but through a set of
'high-level' database-operators (see under SODA).
T_ 6.1.3.1 D_A_T_A_B_A_S_E_8_0_ is the name of RC's standard database description
system. It consists of a formal language and a 'compiler' that
generates a database description file.
&_
NOTE: Database description corresponds roughly to the CODASYL
term, schema.
In addition to its documentary value, the database description's\f
role is to supply information to:
1) local database description systems (subschema)
2) general modules, for example reorganization programs.
The DB-description describes the files which make up the data-
base, their mutual relations, the record types which are con-
tained in the individual files and the fields constituting the
individual record types.
T_ 6.1.3.2 S_O_D_A_ is the name of a Tool for access of a common database from
individual application programs.
&_
The SODA (i.e. s_et-o_riented d_atabase a_ccess) system comprises a
Database Management System, the SODA Local Definition Language,
and the SODA LD Compiler.
NOTE: Local data description corresponds roughly to the CODASYL
term: subschema.
SODA lets the individual application program take a logical view
of the relevant part of the database, with groupings of record
types in record sets suited to the task at hand.
From the application program one communicates with the SODA DBMS
by means of 7 DB-operators: GET, NEXT, LOOKUP, PUT, CREATE, DE-
LETE and NEWSET.
6.1.3.3 D_B_-_U_t_i_l_i_t_i_e_s_._
REORG 80 is a system for initializing and reorganizing a
database described by DATABASE80. By reorganization we mean:
1) the trivial job of rearranging records so that they are more
evenly distributed over the individual blocks (index sequen-
tial files)
2) jobs such as: insertion of new fields in a record type,
insertion of new record types in a file,
insertion of a new file in the database, etc.
P_R_I_N_T_ _8_0_ is a program for printing of records from a database
described by DATABASE80.
\f
6.1.4 G_E_N_I_U_S_
GENIUS is a report generating system for the production of arbi-
trarily structured reports.
GENIUS reads the source data for these reports from a sequential
file containing the so-called GENIUS transactions. The sequen-
tial file must be produced by another program, for example a
standard DB-extraction program.
6.2 T_E_L_E_D_A_T_A_ _S_y_s_t_e_m_ _P_r_o_g_r_a_m_s_
One of the fundamental design principles of TELEDATA has been to
separate the system oriented functions from the actual user
applications (invoicing, order processing, etc.).
The system oriented functions are therefore contained in a
separate category of programs called TELEDATA System Programs.
These programs are perceived as black boxes by the application
programmer. They are maintained centrally by RC's TELEDATAgroup.
TELEDATA System Programs include:
1) A number of specific TELEDATA 'utility programs'.
2) TELEOP a 'virtual machine'.
Utility programs cover functions including: the reestablishment
of the database after breakdown, checking of DB files, DB extrac-
tion, user-accounting etc.
TELEOP is a program written partly in ALGOL and partly in
assembler. Here, it is called 'a virtual machine' because it
contains the system environment under which TELEDATA's on-line
application programs work.
In other words, it contains:
1) The DUET machine (DUET interpreter)
2) SODA's DBMS
3) The Security System (logging etc.)
4) Communication routines (with DUETCOM) \f
5) General routines (sorting, etc.)
A simpler version of TELEOP, consisting mainly of the DUET
machine and the DBMS, is available for batch processing of
TELEDATA's database.
T_ 6.2.1 T_E_L_E_O_P_'_s_ _R_o_l_e_ _i_n_ _t_h_e_ _R_u_n_n_i_n_g_ _S_y_s_t_e_m_
The diagram below shows schematically RC 8000's memory and the
related disc/tape files in a running TELEDATA system.
&_ \f
Memory is shared by the monitor, the operating system 's', DUET-
COM and TELEOP.
The monitor and the operating system 's' constitute RC 8000's
'hard software'.
D_U_E_T_C_O_M_ is a terminal handler/transaction router (see section
6.1.1). DUETCOM runs in its own internal process ('internal pro-
cess', corresponds roughly to 'partition', but is a more dynamic
concept). All communication between the user's terminal equip-
ment and TELEOP goes through DUETCOM.
T_E_L_E_O_P_ runs in another internal process - the process where the
actual transaction processing takes place. TELEOP includes SO-
DA's DBMS, the DUET interpreter and parts of the DUET program:
TELEAPP.
T_E_L_E_A_P_P_ is the 'translated' DUET program containing the online
applications. During execution TELEOP inserts the required pro-
gram blocks into a buffer - DUETSTORAGE (automatic paging).
L_D_-_F_I_L_E_ contains local data descriptions (subschema) which are
used by the DBMS.
T_E_R_M_I_N_A_L_ _F_I_L_E_S_ - one for each terminal - are used as inter-
mediate storage for voucher processing.
T_h_e_ _D_A_T_A_B_A_S_E_ is common for all users of the system. The indivi-
dual user's records are linked to him by means of a key field:
user number. The structure of TELEDATA's database is shown on
page 24.
T_E_X_T_ _F_I_L_E_S_ are used for spooling of output. When, for example,
invoices are generated they are written in a text file. The
actual printing (communication with a user's printer) is per-
formed by DUETCOM.
S_T_A_T_U_S_,_ _L_O_G_ _a_n_d_ _R_E_P_R_O_C_E_S_S_I_N_G_ _L_O_G_ are related to TELEDATA's
security system.
STATUS contains:
1) a number of system parameter
2) a tape catalog (tapes for log and DB-dump)
3) a security catalog \f
The security catalog contains the status of the database so that
after a breakdown it is possible to ascertain whether the data-
base is: in a defined state so that immediate restart can be per-
formed, or in an undefined state which means that the database
must be reestablished before restart.
LOG contains an image of all updated DB records. It can be
located on disc and/or tape. The log is used for:
1) reestablishing the database after a breakdown
2) daily statistics
3) to communicate the day's events to the batch systems.
REPROCESSING LOG contains a copy of all input transactions. With
this log a rerun can be performed after a breakdown, if for some
reason a reestablishment is not possible. A rerun will generally
be considerably slower than a reestablishment.
In addition to functioning as host for the DUET machine and SO-
DA's DBMS, TELEOP performs a number of system functions like:
spooling output, communicating with DUETCOM, maintaining STATUS
and logging the input transactions and updated DB records. In
other words, these functions are isolated from the application
program.
T_6.3 T_E_L_E_D_A_T_A_ _A_p_p_l_i_c_a_t_i_o_n_ _M_o_d_u_l_e_s_
TELEDATA's applications can be divided into three groups:
1) Online functions
2) Daily statistics
&_ 3) DB reports
The structure of the software supporting each of these is
briefly described in the following.
T_ 6.3.1 O_n_l_i_n_e_ _F_u_n_c_t_i_o_n_s_
The online part which handles the transaction processing is the
essential and by far the largest part of the application
&_ software. \f
All the routines are integrated in one program common to all
users. This program, called TELEAPP, is written in the DUET
language (see section 6.1.2).
TELEAPP is structured as a s_k_e_l_e_t_o_n_ _p_r_o_g_r_a_m_, with a_d_a_p_t_i_o_n_
p_o_i_n_t_s_ and associated a_d_a_p_t_i_o_n_s_.
The s_k_e_l_e_t_o_n_ _p_r_o_g_r_a_m_ is the 'static' part of TELEAPP, its
structure being determined by the relatively static structure of
the input/output data. The skeleton program is common to all
TELEDATA installations.
A_d_a_p_t_i_o_n_ _p_o_i_n_t_s_ is the term used for particular points in the
execution of the skeleton program, where the state of the
program is uniquely and logically defined by accessible data,
and where the processing of this data can be effected.
A_d_a_p_t_i_o_n_s_ are routines which will be activated from the adaption
points of the skeleton program. The adaptions constitute the
'dynamic' part of TELEAPP. In order to facilitate modifications
the adaptions are grouped and located separately from the
skeleton part.
T_ The diagram below illustrates TELEAPP's structure:
&_ \f
Under execution the skeleton program, which has the initiative,
will from time to time reach an adaption point. Control is then
transferred to the corresponding adaption which continues the
processing. When the adaption is 'finished', control is returned
to the skeleton program until another adaption is reached. Du-
ring the processing of a single input transaction the skeleton
will generally activate several adaptions.
The division of tasks between the skeleton and the adaptions is
as follows: the skeleton contains the control logic for the
processing of transactions and handles the DB-accesses; the
adaptions perform the actual processing of the user's data,
based on current records and the user's input.
For example alteration of a debtor record: the skeleton reads
the line code and checks its validity with the terminal and
program state and GETs the record. An adaption construes the
rest of the transaction and updates the record accordingly.
Finally, the skeleton program INSERTs the record.
User oriented outputs (error messages, warnings, etc.) are
located in adaptions thereby facilitating translation to other
languages.
The division of tasks between skeleton and application programs
is reflected in the documentation.
In addition to the verbal description the skeleton program manu-
al contains:
1) flow charts showing the skeleton program's routines and the
location of the individual adaption points
2) adaption point descriptions which include short descriptions
of: the function of the adaption point, the records which are
currently available, reading in/writing out possibilities
etc.
The adaptions are described as individual routines linked to the
individual adaption points.
As stated the skeleton is the 'permanent' part of TELEAPP
whereas the adaptions represent the more 'dynamic' part.
The skeleton is common to all TELEDATA installations. Main-\f
tenance will be performed centrally by RC's TELEDATA Group, and
new releases will be relatively infrequent.
However, the adaptions will differ from installation to
installation in order to satisfy the individual service centre's
requirements. RC supplies a set of adaptions - a so-called m_o_d_e_l_
s_o_l_u_t_i_o_n_ - which demonstrates the skeleton program's possibili-
ties. It also serves as a basis for the construction of the l_o_-
c_a_l_ _s_o_l_u_t_i_o_n_s_.
It should be emphasised that the skeleton program and the model
solution together, form a completely functional TELEAPP which is
ready for routine running.But, as the model solution uses the
English language, it will be necessary to translate the line
codes and user-oriented outputs for use in non-English speaking
countries.
TELEDATA is a multi-user service centre system. It must there-
fore be able to satisfy a large number of differing requirements
with regard to how the individual routines (invoicing, order
processing, etc.) must proceed. Therefore, TELEAPP contains pos-
sibilities far in excess of those the individual user utili-
zies.
The individual user will choose a subset of the functions (trans-
actions) available which best suit his requirements. Further-
more, during implementation of a new user, parameters will be
set up defining for example, whether the user requires price
calculations to be performed at order entry or when invoicing.
Moreover, in order to provide a flexible TELEDATA service, it is
possible to add several adaption sets as shown in the diagram
on the following page. Model 0 is, for example, the 'standard
solution' for the installation. Model 1 is used by, say, 5 users
with similar requirements, and Model 2 is used by a single large
user with special requirements.
The adaptions are grouped according to function (invoicing, or-
der processing, etc.). User parameters define which adaption
groups the individual user employs. A user can, therefore, uti-
lize a special invoicing model even though he mainly uses the
'standard solution'. In this way TELEDATA offers real potential
for the provision of widely differing solutions without compro-
mising the clearness and integrity of the system.\f
TEGNING
It is naturally up to the individual service centre to choose
the strategy best suited to their product policy. However, a
service centre with many small users will probably be unwilling
to develop individual models, whereas the opposite is true of a
service centre with a few large users who are prepared to pay
for special adaptions.
6.3.2 D_a_i_l_y_ _S_t_a_t_i_s_t_i_c_s_
The daily statistics (invoice journal, receipts list, stock en-
try list, etc.) can be generated exclusively from the log, which
reflects the events of the day. Generation of the daily statis-
tics is performed as follows:
1) extraction of relevant records
2) sorting
3) run through the sorted file, calculation, printing.
The third phase is carried out by means of GENIUS (see section
6.1.4).
6.3.3 D_B_ _R_e_p_o_r_t_s_
DB Reports can, for example, consist of overviews of orders on
hand, customer balance/open entries, stock volume, etc. They are
generated in the same way as daily statistics or by running
through the DB files and printing simultaneously. \f
F_ 7 S_e_r_v_i_c_e_ _C_e_n_t_r_e_ _O_p_e_r_a_t_i_o_n_
L_o_c_a_l_ _m_a_i_n_t_e_n_a_n_c_e_ of TELEDATA centres on the adaptions to the
skeleton program and the systems connected to TELEDATA, i.e. the
module for communicating with batch systems, the system for the
generation of daily statistics, and the system for the genera-
tion of DB statistics.
I_m_p_l_e_m_e_n_t_a_t_i_o_n_ _o_f_ _n_e_w_ _u_s_e_r_s_ who do not require special adaptions,
will demand that the following is carried out:
1) insertion of entries describing the user's terminal equipment
in DUETCOM's catalog,
2) creation of administrative DB records containing user
parameters,
3) programming of voucher (invoice, order confirmation)
layouts,
4) preparation for the generation of daily statistics and
database reports.
The above represents roughly 2-3 days routine work. If, however,
new adaptions are required then more time will be needed, depen-
ding on the extent of these adaptions.
T_h_e_ _d_a_i_l_y_ _o_p_e_r_a_t_i_o_n_ _o_f_ _T_E_L_E_D_A_T_A_ on the computer is controlled by
an administration program (TELEADM). This virtually automatic
administration minimizes the risk of incorrect operation occur-
ing and also reduces the demands on the operator's time.
In the morning the operator initiates the start-up, TELEADM
activates the job files for checking and starting up the TELE-
DATA system.
During the day the system normally does not demand operator ac-
tion. But if the system breaks down (e.g. because of hard error)
the operator must intervene. He must initialize the recovery pro-
cedure. TELEADM, thereupon checks the state of the system and
selects the job files necessary for recovering the database and
restarting the system.
In the evening the operator stops the TELEDATA system and starts
jobs for: copying the log tape, dumping the database, generating
input files for the batch system and generating the daily statis-
tics. \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. GENERELLE METODER ...................................... 2
2.1 NCT loggen ........................................ 2
2.2 Lagerdump i RC3502 ................................ 3
2.2.1 Debug mode ................................. 4
2.2.2 Print kommandoen ........................... 4
2.3 Forskelle på exception/trace/panic i TC software .. 4
2.4 Forholdsregler ved TES202 moduler ................. 6
3. CN PROGRAMMEL I TC (RC3502) ............................ 7
3.1 CNADAM (release xxxxxx) ........................... 7
3.2 HDLC (release 810917) ............................. 7
3.3 DTE (release 3.01) ................................ 8
3.4 TS, Transport Station (release 820326) ............ 9
3.5 SC, Session Control (release 820503) .............. 10
3.6 X.28 SMT (release 820325) ......................... 10
3.7 NCP, Network Control Probe (release 811124) ....... 12
3.8 Host Interface (release HI 820304, HPM 820210, FDLC
820210) ........................................... 12
3.9 SCAT, Session Control Artificial Traffic (release
820326) ........................................... 13
4. CN PROGRAMMEL I RC8000 HOST ............................ 15
4.1 NPM, Network Port Module (release 2.00) ........... 15
4.2 SMM, Scroll Mode Mapping Module (release 1.21) .... 15
4.3 FTU, File Transport Utility (release 1.03) ........ 17
4.4 NCC, Network Control Center (release 1.5) ......... 17
4.5 NCT, Network Control Terminal (release 820322) .... 17
4.6 Event Collector (release 820420) .................. 18
B_I_L_A_G_:
A. REFERENCER ............................................. 19
B. FEJLRAPPORT ............................................ 21 \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_
C. EKSEMPLER PÅ LAGERDUMP I RC3502 ........................ 22
C.1 List af proces hierarki ........................... 22
C.2 List af proces hovedet for dte _test ............... 23
C.3 Lagerdump ved hjælp af debug konsol ............... 24
C.4 Lagerdump ved hjælp af opsys kommandoen 'print' ... 25
D. LISTNING AF PARAMETRE TIL SMM TESTPRINT ................ 27
E. EKSEMPLER PÅ HÅNDTERING AF NCTLOGFILE .................. 29
E.1 'Dump' af NCTLOGFILE .............................. 29
E.2 Print af gammel NCTLOGFILE ........................ 30
\f
F_ 1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_K_T_I_O_N_ 1.
Dette skrift er tænkt som en hjælp til at få bevaret/udskrevet
den nødvendige information i tilfælde af software fejl i
CENTERNET programmellet.
Første del beskriver nogle generelle metoder, anden del omhandler
TC modulerne og tredje del modulerne i RC8000.
For hver enkelt modul er beskrevet de specielle metoder/ønsker,
samt henvisning til de generelle, hvis de skal benyttes.
Som bilag B er vedhæftet en kopi af CENTERNET FEJLRAPPORT, som
s_k_a_l_ udfyldes i tilfælde af programmel fejl.
Note: Hvis der er foretaget ændringer i den af RC releasede kil-
detekst, skal en listning af den ændrede kildetekst
vedlægges sammen med anden dokumentation.
I alle eksemplerne er den tekst en bruger skal indtaste under-
streget.
\f
F_ 2_._ _ _ _ _ _ _ _ _G_E_N_E_R_E_L_L_E_ _M_E_T_O_D_E_R_ 2.
To generelle dokumentations måder vil blive beskrevet i dette ka-
pitel. Det drejer sig om NCT loggen og lagerdump på RC3502.
2_._1_ _ _ _ _ _ _ _N_C_T_ _l_o_g_g_e_n_ 2.1
Hvis NCT log filen skal gemmes for senere udskrift eller kopie-
ring til magnetbånd anvendes følgende procedure:
M_ a_t_t_ _n_c_t_ (att esc)
kun >c_l_o_s_e_
hvis -
nct'en -
kører -
end 388
from s
pause nct finis fp
a_t_t_ _s_
j_o_b_ _n_c_t_
ready
to nct
o_l_d_n_c_t_l_o_g_ _=_ _s_e_t_ _1_0_0_0_ _<_d_i_s_c_ _n_a_m_e_>_
s_c_o_p_e_ _p_r_o_j_e_c_t_ _o_l_d_n_c_t_l_o_g_
o_l_d_n_c_t_l_o_g_ _=_ _f_a_s_t_m_o_v_e_ _n_c_t_l_o_g_f_i_l_e_
P_ i_ _j_n_c_t_
og herefter er NCT'en klar igen. Filen oldnctlog ligger på
baserne 0-9999 og kan overføres til magnetbånd, hvis det ønskes.
Et eksempel er vist i bilag E.
Hvis filen oldnctlog ønskes udskrevet med print-kommandoen i
NCT'en kan følgende procedure anvendes (NCT'en kører i_k_k_e_)
a_t_t_ _s_
j_o_b_ _n_c_t_
ready
to nct
r_e_n_a_m_e_ _n_c_t_l_o_g_f_i_l_e_._n_e_w_n_c_t_l_o_g_
r_e_n_a_m_e_ _o_l_d_n_c_t_l_o_g_._n_c_t_l_o_g_f_i_l_e_
\f
i_ _j_n_c_t_
- ; opstart af NCT
- ; udskrift af log filen
- ; nedlukning af NCT
-
-
end <no>
from s
pause nct finis fp
a_t_t_ _s_
j_o_b_ _n_c_t_
ready
to nct
r_e_n_a_m_e_ _n_c_t_l_o_g_f_i_l_e_._o_l_d_n_c_t_l_o_g_
r_e_n_a_m_e_ _n_e_w_n_c_t_l_o_g_._n_c_t_l_o_g_f_i_l_e_
Det videre forløb afhænger af, om NCT'en skal startes igen eller
ej.
For en nærmere beskrivelse af FP utilities og s kommandoer
henvises til ref. 1 og ref. 2 henholdsvis.
2_._2_ _ _ _ _ _ _ _L_a_g_e_r_d_u_m_p_ _i_ _R_C_3_5_0_2_
Lagerdump anvendes til at få en udskrift af stakken for en proces
og evt. buffere. Starten af stakken findes ved at anvende opsys
kommandoen 'list' (se bilag C), som udskriver proces hierarkiet.
I søjlen 'stack' findes startadressen på stakken. Det 18. ord
(talt fra 1) i stakken angiver den øjeblikkelige staktop. Hvis
buffere skal udskrives må man finde de enkelte buffere (ved hjælp
af felter i pool, semaphore og reference), idet buffere ikke nød-
vendigvis ligger samlet. I bilag C er vist et eksempel.
Lagerdump kan udføres på to måder, enten ved at bruge opsys kom-
mandoen 'print' eller ved at sætte konsollen i debug mode og an-
vende M kommandoen. Nedenfor er begge metoder beskrevet og i
bilag C er vist eksempler på, hvorledes de to metoder anvendes.
\f
2_._2_._1_ _ _ _ _ _D_e_b_u_g_ _m_o_d_e_ 2.2.1
c_t_r_l_ _g_ ; konsollen sættes i debug mode
D
*
* M_ <_m_e_m_o_r_y_ _m_o_d_u_l_e_ _a_d_d_r_>_ ; M indtastes, hvorefter lager mo-
; dul adressen skrives hexadecimalt
<memory module addr> : <_a_d_d_r_ _w_o_r_d_>_ ; dette bevirker at 8 ord ud-
; skrives
Derefter udskrives de næste 8 ord ved at indtaste + og således
fortsættes. For at komme tilbage til 'terminal mode' tastes <CR>
efter ':' og så 'ctrl g'. For yderligere information henvises til
ref. 4.
2_._2_._2_ _ _ _ _ _P_r_i_n_t_ _k_o_m_m_a_n_d_o_e_n_ 2.2.2
>_ o_p_s_y_s_ ; > esc, dirigerer kommende input
; til processen opsys
p_r_i_n_t_ _<_2_ _s_i_d_s_t_e_ _c_i_f_r_e_ _i_ _l_a_g_e_r_ _m_o_d_u_l_ _a_d_r_>_ _<_s_t_a_r_t_ _a_d_r_>_ _<_s_t_o_p_ _a_d_r_>_
; adr i hexadecimal
opsys udskriver nu lageret fra <start adr> til <stop adr> med et
ord pr. linie. Hvert ord bliver udskrevet hexadecimalt, som et
heltal (pos/neg), som to bytes og som tre ASCII tegn. For
yderligere information henvises til ref. 4.
2_._3_ _ _ _ _ _ _ _F_o_r_s_k_e_l_l_e_ _p_å_ _e_x_c_e_p_t_i_o_n_/_t_r_a_c_e_/_p_a_n_i_c_ _i_ _T_C_ _s_o_f_t_w_a_r_e_ 2.3
I det software, der kører i en TC, kan der forekomme tre
udskrifter på konsollen, der ligner hinanden, men som er delvis
forskellige i oprindelse. Det drejer sig om
trace: generering af testoutput på konsol
panic: kontrolleret exception
exception: system genereret afbrydelse
\f
Nedenfor er vist eksempler på de tre udskrifter med en tilhørende
forklaring.
t_r_a_c_e_
p_a_n_i_c_
Panic består af et kald af proceduren trace efterfulgt af en pro-
vokeret exception (x div 0).
\f
e_x_c_e_p_t_i_o_n_
2_._4_ _ _ _ _ _ _ _F_o_r_h_o_l_d_s_r_e_g_l_e_r_ _v_e_d_ _T_E_S_2_0_2_ _m_o_d_u_l_e_r_ 2.4
I situationer hvor koden er placeret i TES202 moduler, skal koden
checkes ved hjælp af en CRC16 check. I hver EPROM er brændt en
CRC16 og ved hjælp af opsys kommandoen 'CH <no>' udregnes en
CRC16, som checkes mod den brændte. Hvis der er forskel vil lager
intervallet, forventede og beregnede CRC16 blive udskrevet.
\f
F_ 3_._ _ _ _ _ _ _ _ _C_N_ _P_R_O_G_R_A_M_M_E_L_ _I_ _T_C_ _(_R_C_3_5_0_2_)_ 3.
3_._1_ _ _ _ _ _ _ _C_N_A_D_A_M_ _(_r_e_l_e_a_s_e_ _x_x_x_x_x_x_)_ 3.1
Dette modul er endnu ikke releaset.
3_._2_ _ _ _ _ _ _ _H_D_L_C_ _(_r_e_l_e_a_s_e_ _8_1_0_9_1_7_)_ 3.2
Internt testoutput i HDLC driveren kan startes og stoppes dyna-
misk fra konsollen. Processen dte _test kommunikerer med konsollen
og HDLC driveren vedrørende testoutput. Nedenfor er listet de
kommandoer, der kan anvendes. Når processen dte _test (release
3.01) startes, starter den som default internt testoutput i HDLC
driveren.
HDLC testoutput kommandoer til dte _test:
hdlc <mode>
Start af intern test.
<mode> er test mode bits som specificeret i ref. 5. Hvis mode
udelades, anvendes den gamle værdi.
stop _hdlc
Stop af intern test generering i driveren.
print _hdlc
Hvis intern test er specificeret udskrives testoutput records fra
HDLC driveren i et format angivet i ref. 5.
I tilfælde af fejl udskrives testoutput fra driveren, som angivet
ovenfor. Der vil blive udskrevet 5 test buffere hver med 31 test
records.
Efter en exception er hele HDLC driveren død, dvs. at der skal
startes op igen.
\f
3_._3_ _ _ _ _ _ _ _D_T_E_ _(_r_e_l_e_a_s_e_ _3_._0_1_)_ 3.3
Generering af internt testoutput i DTE supervisor processen er en
konstant (test = true/false) som sættes inden oversættelsen.
Udskrivning af test records styres fra konsollen ved hjælp af
processen dte _test. Kommandoen dte _sup bevirker at test records
fra processen dte(supervisor) udskrives. Enten udskrives 5 test
buffere hver med 21 test records med det samme, eller der udskri-
ves først 4, og senere, når den femte er fyldt, udskrives den så.
Formatet for udskriften er angivet i ref. 6. Fejl i DTE modulet
kan inddeles i følgende 4 grupper:
1) exception
2) trace efterfulgt af panic
3) trace
4) funktionsfejl vedrørende NC operationer
For grupperne 1) og 2) er processen død bagefter, og DTE modulet
kan ikke fungere, undtagen hvis det er en dtechan proces. I dette
tilfælde vil kun den aktuelle X.25 kanal/strøm blive berørt, og
efter en restart vil alt være ok igen. For gruppe 3) gælder, at
der efter trace fortsættes på normal måde.
Egentlige test udskrifter er angivet i ref. 6.
For gruppe 4) gælder, at der fortsættes som om intet var hændt.
I tilfælde af fejl afhænger dokumentations proceduren af hvilken
gruppe fejlen falder i.
Gruppe 1):
For processerne dte _acc, dte _lcn0 og dte _hrec udskrives stakken.
For processerne dte og dtechanxxx udskrives yderligere internt
testoutput, som angivet ovenfor.
Gruppe 2):
For alle processer udskrives stakken. For dte udskrives endvidere
det genererede interne testoutput.
\f
Gruppe 3):
For processen dte udskrives internt testoutput, hvorimod der for
alle andre processer intet ønskes.
Gruppe 4):
Der ønskes en nøje beskrivelse af, hvad der er forsøgt samt
resultatet og en kopi af NCT loggen. Desuden ønskes en kopi af
konsol udskriften fra opstarten af DTE'en.
For de første 3 grupper ønskes desuden en kopi af konsol udskrif-
ter fra DTE'en (hvis muligt siden opstarten). For alle 4 grupper
ønskes DTE proces hierarkiet listet, ved hjælp af opsys kommando-
en 'list dte'.
3_._4_ _ _ _ _ _ _ _T_S_,_ _T_r_a_n_s_p_o_r_t_ _S_t_a_t_i_o_n_ _(_r_e_l_e_a_s_e_ _8_2_0_3_2_6_)_ 3.4
Ved trace i alle moduler afleveres blot en udfyldt fejlrapport og
log af trace.
En undtagelse er trace fra TSPP med værdien 1 linie nummer ca.
3400-3500 eller linie nummer 4725-4825. Her gøres følgende:
>_t_e_s_t_
w_ _4_ _2_5_0_
o_ _0_ _1_0_0_
<* Her kommer en udskrift *>
b_ _1_6_
o_ _0_ _1_0_0_
<* Her kommer en udskrift *>
s_ _4_ _2_5_0_
Ved trace kan modulerne normalt fortsætte kørslen.
Ved exception og panic bedes der venligst tages dump af proces-
sens stak. Hvis det er en TSPP incarnation, der er gået i excep-
tion, kan resten normalt køre uforandret videre.
\f
3_._5_ _ _ _ _ _ _ _S_C_,_ _S_e_s_s_i_o_n_ _C_o_n_t_r_o_l_ _(_r_e_l_e_a_s_e_ _8_2_0_5_0_3_)_ 3.5
Fejl vedrørende SC kan deles i to grupper:
exception og panic
trace
Efter en exception i processerne sc og sc _acc vil modulet være
dødt, hvorimod hvis den optræder i processen scpprocxxx vil kun
den port, som processen håndterer, være død.
Efter en trace vil modulet køre videre uden nogen ændring.
I tilfælde af fejl ønskes generelt en kopi af filen centernet, en
kopi af loggen hvor SC startes, samt en udskrift af hele proces
hierarkiet.
I tilfælde af exception udskrives stakken for den pågældende pro-
ces, og i tilfælde af en trace fra scpproc, en listning (proces
hierarki) af de applikationer, der anvendte SC på det pågældende
tidspunkt.
Hvis det drejer sig om en funktionsfejl vedrørende open/close
port, connect/disconnect ønskes et dump af sc processens stak,
samt en kopi af NCT loggen.
3_._6_ _ _ _ _ _ _ _X_._2_8_ _S_M_T_ _(_r_e_l_e_a_s_e_ _8_2_0_3_2_5_)_ 3.6
Der ønskes (naturligvis) en fyldig beskrivelse af de omstændighe-
der under hvilke fejlen er forekommet.
Derudover bør følgende foretages:
>_o_p_s_y_s_
l_i_s_t_ _s_m_t_
\f
a) E_x_c_e_p_t_i_o_n_ _(_h_e_r_u_n_d_e_r_ _p_a_n_i_c_)_
I tilfælde af exception bedes foretaget dump af processens stak.
Hvis exception kommer fra en af følgende processer:
smt _x28 _c
smt _x28 _d
smt _comd
smt _datag
bedes stakken for den tilsvarende smt _term proces også dumpes.
b) T_r_a_c_e_
I tilfælde af trace med excode = 00FF kaldt fra proceduren
vtp _error _cl i processen smt _term bedes følgende foretaget:
>_t_e_s_t_
w_ _8_ _1_0_8_
_
b_ _1_6_
o_ _1_ _1_0_3_ ; udskrift af buffer
s_ _8_ _1_0_8_
<_-_
o_ ; udskrift ad header
d_
Ovennævnte trace angiver at data med ulovligt VTP format er mod-
taget fra sessions partneren.
Alle tilfælde af trace bedes rapporteret som fejl. Den involvere-
de proces kan normalt køre videre efter trace.
\f
3_._7_ _ _ _ _ _ _ _N_C_P_,_ _N_e_t_w_o_r_k_ _C_o_n_t_r_o_l_ _P_r_o_b_e_ _(_r_e_l_e_a_s_e_ _8_1_1_1_2_4_)_ 3.7
Fejl i NCP'en kan inddeles i følgende tre grupper:
- exception
- 'ncp error' udskrift på konsol
- funktionsfejl
Generelt ønskes altid:
- NCT log
- NCT log fra opstart
- beskrivelse af net konfiguration
- 'list' på konsol
- 'lookup ncp' på konsol
Specielt ønskes ved
e_x_c_e_p_t_i_o_n_
- log af exception
- 'print' af ncp's stak
n_c_p_ _e_r_r_o_r_ _u_d_s_k_r_i_f_t_
- log af denne
f_u_n_k_t_i_o_n_s_f_e_j_l_
- detaljeret beskrivelse af fejl og hvad der er forsøgt
3_._8_ _ _ _ _ _ _ _H_o_s_t_ _i_n_t_e_r_f_a_c_e_ _(_r_e_l_e_a_s_e_ _H_I_ _8_2_0_3_0_4_,_ _H_P_M_ _8_2_0_2_1_0_,_ _F_D_L_C_ _8_2_0_2_1_0_)_ 3.8
Det drejer sig om processerne med navnene hi, him _xxxx _hos
("xxxx" angiver et HPM port nummer på decimal form),
him _xxxx _net, hpm, host _pt _answ, host _pt _xxxx, hi _cl, fdlc _rec,
fdlc _xmit, fpa _rec, fpa _xmit, hi _testout, spooler outp, spooler
inp.
\f
Hvis der er problemer med host interfacet bør følgende foreta-
ges:
1) Konsol output afleveres
2) NCT loggen bør udskrives fra opstart tidspunktet
3) NPM testoutput tages som beskrevet i afsnit 4.1
4) Host interface testoutput tages på følgende måde:
>_t_e_s_t_o_u_t_p_u_t_
<_c_r_>_
Denne tomme linie vil medføre at testoutput bliver ud-
skrevet på konsollen. Proceduren bør gentages indtil der
ikke bliver udskrevet mere testoutput.
Bemærk at dette testoutput kun har værdi hvis det er ud-
skrevet hurtigt efter at problemet er opstået.
5) Hvis en af processerne går i exception, bør stakken for
den pågældende proces dumpes. Dertil kommer:
Hvis "him _xxxx _hos" går i exception, bør "him _xxxx _net"
samt "hi" også dumpes.
Hvis "him _xxxx _net" går i exception, bør "him _xxxx _hos"
samt "hi" også dumpes.
Hvis "host _pt _xxxx" eller "host _pt _answ" går i exception,
bør "hpm" også dumpes.
6) Endelig bør bemærkes, at der kan blive udskrevet traces
fra processerne "hi _xxxx _net". Kørslen kan fortsættes,
men konsol udskriften bør håndteres som en fejl.
3_._9_ _ _ _ _ _ _ _S_C_A_T_,_ _S_e_s_s_i_o_n_ _C_o_n_t_r_o_l_ _A_r_t_i_f_i_c_i_a_l_ _T_r_a_f_f_i_c_ _(_r_e_l_e_a_s_e_ _8_2_0_3_2_6_)_ 3.9
Det drejer sig om processerne scatx (x = 0 eller 1) med børnepro-
cesserne scatlggenx, scatlgrecx, scatligenx, scatlirecx,
scattggenx, scattgrecx samt scechox (x = 0 eller 1).
\f
Hvis der optræder problemer med SCAT modulerne bør NCT loggen fra
opstarttidspunktet udskrives, og en fejlrapport afleveres.
Hvis en af processerne går i exception, bør stakken dumpes og
hvis det drejer sig om en af "scatx"'s børneprocesser, bør dens
egen stak også dumpes.
Fra "scatx" processerne kan der blive genereret en trace fra pro-
ceduren "sig _term". Denne bør rapporteres, men SCAT modulerne kan
(sandsynligvis) køre videre.
\f
F_ 4_._ _ _ _ _ _ _ _ _C_N_ _P_R_O_G_R_A_M_M_E_L_ _I_ _R_C_8_0_0_0_ _H_O_S_T_ 4.
4_._1_ _ _ _ _ _ _ _N_P_M_,_ _N_e_t_w_o_r_k_ _P_o_r_t_ _M_o_d_u_l_e_ _(_r_e_l_e_a_s_e_ _2_._0_0_)_ 4.1
I tilfælde af fejl i NPM modulet skal testoutput fra modulet
gemmes. Dette gøres (i NPM rel. 2.00) ved at anvende kommando
filen 'snpm':
Testoutput filen bliver dumpet over i filen 'testcopy' og et
udpluk af denne fil bliver udskrevet på linie skriveren.
N_o_t_e_: Filen 'testcopy' skal bevares til eventuel senere brug.
En nærmere beskrivelse af npm testoutput mm. kan findes i ref.
7.
4_._2_ _ _ _ _ _ _ _S_M_M_,_ _S_c_r_o_l_l_ _M_o_d_e_ _M_a_p_p_i_n_g_ _M_o_d_u_l_e_ _(_r_e_l_e_a_s_e_ _1_._2_1_)_ 4.2
Følgende test parametre initieres ved opstart af SMM:
log.<no>
Log print out parameter for coroutine systemet (default = 0).
ctest.<no>
Test record parameter for coroutine systemet og smm programmet
(default = 0). I jsmm sat til 255.
\f
testname.<name>
Filnavn hvor test records udskrives (default = smmtest). I jsmm
sat til smmtestmax.
cyclic.<yes/no>
Specificerer om test filen skal anvendes cyklisk eller ej (de-
fault = yes).
Test records i filen 'smmtestmax' kan udskrives på linie skrive-
ren med følgende FP job:
o_ _l_p_
i_ _j_s_m_m_t_p_r_
o_ _c_
Parametre til og kald af print programmet er beskrevet i starten
af filen 'ttestprint' (vedlagt som bilag D).
'jsmmtpr' og 'ttestprint' findes begge i lib filen libsmmtpr.
For yderligere information henvises til ref. 8, 9 og 10.
Hvis testoutput fra SMM processen ønskes bevaret, udføres føl-
gende procedure:
M_ a_t_t_ _s_ ; att esc
p_r_o_c_ _s_m_m_ _b_r_e_a_k_
M_ .
.
P_ .
a_t_t_ _s_
p_r_o_c_ _s_m_m_ _r_e_m_o_v_e_ _j_o_b_ _s_m_m_
M_ .
.
P_ .
to smm
s_m_m_t_e_s_t_<_i_d_>_ _=_ _s_e_t_ _5_0_0_ _d_i_s_c_
s_c_o_p_e_ _u_s_e_r_ _s_m_m_t_e_s_t_<_i_d_>_
s_m_m_t_e_s_t_<_i_d_>_ _=_ _m_o_v_e_ _s_m_m_t_e_s_t_m_a_x_
P_ i_ _j_s_m_m_ ; opstart af smm
Filen smmtest<id> findes nu på max baser og kan kopieres til mag-
netbånd eller udskrives.
\f
Fejlmeddelelser fra SMM er beskrevet i ref. 8.
I tilfælde af fejl ønskes en kopi af testoutput filen for SMM
processen og NPM processen som dokumentation. Desuden ønskes en
kopi af loggen, hvor SMM processen og den binære smm blev star-
tet.
4_._3_ _ _ _ _ _ _ _F_T_U_,_ _F_i_l_e_ _T_r_a_n_s_p_o_r_t_ _U_t_i_l_i_t_y_ _(_r_e_l_e_a_s_e_ _1_._0_3_)_ 4.3
I tilfælde af fejl i FTU systemet skal processen afsluttes på
normal måde ('break').
'Current output' og loggen udskrives på linie skriveren.
Hvis kommando filerne samlet i FTUJOBS (release 1.03) bliver
brugt, kan udskriften af 'current output' og loggen foretages med
kommandoen 'i log' til processen REQ. Denne udskrift indeholder
den nødvendige information fra FTU systemet.
4_._4_ _ _ _ _ _ _ _N_C_C_,_ _N_e_t_w_o_r_k_ _C_o_n_t_r_o_l_ _C_e_n_t_e_r_ _(_r_e_l_e_a_s_e_ _1_._5_)_ 4.4
Ved fejl i NCC'en ønskes en log af opstarten af modulet og en be-
skrivelse af omstændighederne.
Hvis fejlen hidrører fra kommunikation med NCT'en, ønskes filen
'nctlogfile' bevaret.
I tilfælde af at fejlen kan identificeres til kommunikationen med
NPM modulet ønskes testoutput fra NPM'en vedlagt (se afsnit
4.1).
4_._5_ _ _ _ _ _ _ _N_C_T_,_ _N_e_t_w_o_r_k_ _C_o_n_t_r_o_l_ _T_e_r_m_i_n_a_l_ _(_r_e_l_e_a_s_e_ _8_2_0_3_2_2_)_ 4.5
For dette modul er 'nctlogfile' og log af opstarten samt en fejl-
beskrivelse tilstrækkelig.
\f
4_._6_ _ _ _ _ _ _ _E_v_e_n_t_ _C_o_l_l_e_c_t_o_r_ _(_r_e_l_e_a_s_e_ _8_2_0_4_2_0_)_ 4.6
For Event Collector gælder, at den ikke genererer internt test-
output, så i fejlsituationer er log af opstart og fejl den eneste
dokumentation der er nødvendig.
\f
F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_R_ A.
1 RCSL No 31-D590:
S_Y_S_T_E_M_3_ _U_t_i_l_i_t_y_ _P_r_o_g_r_a_m_s_,_ _P_a_r_t_ _T_w_o_
Finn G. Strøbech, januar 1980
2 RCSL No 31-D693:
O_p_e_r_a_t_i_n_g_ _S_y_s_t_e_m_ _s_,_ _R_e_f_e_r_e_n_c_e_ _M_a_n_u_a_l_
Henrik Sierslev, maj 1981
3 RCSL No 43-GL11421:
C_E_N_T_E_R_N_E_T_,_ _N_e_t_w_o_r_k_ _C_o_n_t_r_o_l_ _T_e_r_m_i_n_a_l_,_ _U_s_e_r_'_s_ _G_u_i_d_e_
Jørgen Christensen, (endnu ikke trykt)
4 RCSL No 52-AA1016:
R_C_3_5_0_2_,_ _O_p_e_r_a_t_i_n_g_ _G_u_i_d_e_
Bo Bagger Laursen, november 1981
5 RCSL No 52-AA1074:
R_C_3_5_0_2_ _C_O_M_2_0_1_ _H_D_L_C_ _D_r_i_v_e_r_,_ _R_e_f_e_r_e_n_c_e_ _M_a_n_u_a_l_
Per Mondrup, november 1981
6 RCSL No 43-GL11738:
C_E_N_T_E_R_N_E_T_,_ _D_T_E_ _M_o_d_u_l_e_,_ _R_e_f_e_r_e_n_c_e_ _M_a_n_u_a_l_
Per Høgh, (endnu ikke trykt)
7 RCSL No 43-GL11763:
C_E_N_T_E_R_N_E_T_,_ _N_e_t_w_o_r_k_ _P_o_r_t_ _M_o_d_u_l_e_ _N_P_M_,_ _I_n_s_t_a_l_l_a_t_i_o_n_/_O_p_e_r_a_t_i_n_g_
G_u_i_d_e_
Carl Henrik Dreyer, marts 1982
8 RCSL No 43-GL11696:
C_E_N_T_E_R_N_E_T_,_ _R_C_8_0_0_0_ _S_c_r_o_l_l_ _M_o_d_e_ _M_a_p_p_i_n_g_ _M_o_d_u_l_e_ _(_S_M_M_)_,_ _O_p_e_r_a_t_-_
i_n_g_ _G_u_i_d_e_/_U_s_e_r_'_s_ _G_u_i_d_e_
Lis Clement, november 1981
\f
9 RCSL No 43-GL11697:
C_E_N_T_E_R_N_E_T_,_ _R_C_8_0_0_0_ _S_c_r_o_l_l_ _M_o_d_e_ _M_a_p_p_i_n_g_ _M_o_d_u_l_e_ _(_S_M_M_)_,_ _R_e_f_e_r_-_
e_n_c_e_ _M_a_n_u_a_l_
Lis Clement, november 1981
10 RCSL Nr. 31-D666:
A_L_G_O_L_ _C_o_r_o_u_t_i_n_e_ _S_y_s_t_e_m_,_ _T_e_s_t_ _u_d_s_k_r_i_v_n_i_n_g_,_ _B_r_u_g_e_r_v_e_j_l_e_d_n_i_n_g_
Lis Clement, november 1981
\f
F_ B_._ _ _ _ _ _ _ _ _F_E_J_L_R_A_P_P_O_R_T_ B.
\f
F_ C_._ _ _ _ _ _ _ _ _E_K_S_E_M_P_L_E_R_ _P_Å_ _L_A_G_E_R_D_U_M_P_ _I_ _R_C_3_5_0_2_ C.
C_._1_ _ _ _ _ _ _ _L_i_s_t_ _a_f_ _p_r_o_c_e_s_ _h_i_e_r_a_r_k_i_
NOTE: Exit betyder at processen har udført sidste 'end' eller er
gået i exception.
\f
M_M_m_m_ C.2 List af proces hovedet for dte _test C.2
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
F_ C_._3_ _ _ _ _ _ _ _L_a_g_e_r_d_u_m_p_ _v_e_d_ _h_j_æ_l_p_ _a_f_ _d_e_b_u_g_ _k_o_n_s_o_l_ C.3
\f
F_ C_._4_ _ _ _ _ _ _ _L_a_g_e_r_d_u_m_p_ _v_e_d_ _h_j_æ_l_p_ _a_f_ _o_p_s_y_s_ _k_o_m_m_a_n_d_o_e_n_ _'_p_r_i_n_t_'_ C.4
\f
F_
\f
F_ D_._ _ _ _ _ _ _ _ _L_I_S_T_N_I_N_G_ _A_F_ _P_A_R_A_M_E_T_R_E_ _T_I_L_ _S_M_M_ _T_E_S_T_P_R_I_N_T_ D.
\f
F_
\f
F_ E_._ _ _ _ _ _ _ _ _E_K_S_E_M_P_L_E_R_ _P_Å_ _H_Å_N_D_T_E_R_I_N_G_ _A_F_ _N_C_T_L_O_G_F_I_L_E_ E.
E_._1_ _ _ _ _ _ _ _'_D_u_m_p_'_ _a_f_ _N_C_T_L_O_G_F_I_L_E_ E.1
\f
F_ E_._2_ _ _ _ _ _ _ _P_r_i_n_t_ _a_f_ _g_a_m_m_e_l_ _N_C_T_L_O_G_F_I_L_E_ E.2
\f
F_
\f
F_
\f
i
T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_
1. GENERAL DESCRIPTION .................................... 1
1.1 Chassis ........................................... 1
1.2 Cooling ........................................... 1
1.3 Power Supplies .................................... 1
1.4 Switches etc. ..................................... 1
1.5 Connectors ........................................ 2
1.6 Optional Bus ...................................... 2
Bus Signals ............................................ 4
Multibus diagram, part one ............................. 5
Bus Signals ............................................ 6
Multibus diagram, part two ............................. 7
Parallel Priority Resolver, Function Table ............. 8
- - - , Diagram .................... 9
Optional Bus Signals ................................... 10
Multibus diagram (Optional Bus) ........................ 11
Bus Activity Indicator ................................. 12
Power Circuits, Diagram ................................ 13 \f
ii
\f
F_ 1_._ _ _ _ _ _ _ _ _G_E_N_E_R_A_L_ _D_E_S_C_R_I_P_T_I_O_N_ 1.
1_._1_ _ _ _ _ _ _ _C_h_a_s_s_i_s_ 1.1
Made of electroplated steel and aluminium, without fans.
Width = 19", height = 14".
1_._2_ _ _ _ _ _ _ _C_o_o_l_i_n_g_ 1.2
External cooling is needed, evenly distibuted over the whole
width.
M_m_m_ 2_._6_ _x_ _P_
V =
P_p_p_ t
V = Volume flow in m/h.
P = Installed effect (W). Add 20% for power supply losses.
t= Permissible temperature rise (C) of cooling air.
1_._3_ _ _ _ _ _ _ _P_o_w_e_r_ _S_u_p_p_l_i_e_s_ 1.3
The chassis is fitted with control module POW 738 and one +5 V
power module POW 729 (max. 20 A). POW 738 can only function in
the lower right position. The remaining 4 slots can be filled as
the need arises. For cooling reasons the lower positions should
be filled first.
W_A_R_N_I_N_G_:_ _H_I_G_H_ _V_O_L_T_A_G_E_ _(_3_0_0_ _V_ _D_C_)_ _A_N_D_ _9_0_0_ __F_ _C_A_P_A_C_I_T_O_R_S_ _A_R_E_
E_X_T_R_E_M_E_L_Y_ _D_A_N_G_E_R_O_U_S_!_
1_._4_ _ _ _ _ _ _ _S_w_i_t_c_h_e_s_ _e_t_c_._ 1.4
I/O: Mains switch (Power)
RESET switch
Light diode, green: Power OK
Light diode, red : Bus Activity Indicator
\f
1_._5_ _ _ _ _ _ _ _C_o_n_n_e_c_t_o_r_s_ 1.5
Mains connector 1 x 220 V AC + GND.
J42: Connector for external RESET, POWER OK and ACTIVITY
INDICATOR.
J51: External power (Battery back-up).
J52: Optional bus signals (control of external power).
Cables connected to the front edge of the Multibus cards can
leave the chassis by means of the two holes in the left side. The
front cover should always be refitted to assure correct cooling.
1_._6_ _ _ _ _ _ _ _O_p_t_i_o_n_a_l_ _B_u_s_ 1.6
The optional bus is fitted with 60-pins connectors in the first 3
positions, taken from the left. Further connectors can be fitted
as the need arises.
\f
F_
\f
F_ BUS SIGNALS
\f
F_\f
F_ BUS SIGNALS
\f
F_\f
F_ Parallel Priority Resolver \f
F_\f
F_ OPTIONAL BUS SIGNALS \f
F_\f
F_ BUS ACTIVITY INDICATOR
The Activity Indicator LED is driven by a one-shot with a 200 ns.
output pulse length. The one-shot is triggered by the Multibus
signal -,XACK. As the signal is issued in connection with any
type of bus access, the light intensity of the LED indicates the
intensity of the bus activity.
\f
F_\f
F_\f
907501 SE Axel Toft, Durup A/S
907502 SE Emmelev Mølle A/S
907503 SE Hornsyld Købmandsgård
907504 SE Montax Aps
907507 SE Erling Jensen
907510 SE AKO
907512 SE Bilwinco
907513 SE Oue Savværk
907514 SE Plus Vejen
907515 SE Vestkraft
907517 SE Celebrity
907506 SE DDK
907522 SE Aller Møller A/S
907521 SE Lynggaard Pedersen Data
190106 MM Viborg kommune
190108 MM Thisted kommune
190122 MM Kalundborg kommune
190123 MM Blåvandshuk kommune
190125 MM Bjerringbro kommune
190148 MM Ringsted kommune
190514 MM Gert Hansen
190124 SV Vejle Elværk
190126 SV Tandlægehøjskolen i Århus
190127 SV Handelshøjskolen i Århus
190128 SV Kystinspektoratet
190139 SV Odense Sygehus
190150 SV Frederikshavn kommune
190137 SV Aalborg Sygehus, Syd
190153 SV DSB
190154 SV RECAU
190155 SV RECKU
190156 SV NEUCC
190105 PKJ Ballerup kommune
190107 PKJ Esbjerg kommune
190157 PKJ Albertslund kommune
907016 NP Vølund
907018 NP FDF/FPF
907020 NP Chr. Egelborg
907022 NP Industrirådet
907024 NP T. H. Strålfors
907025 NP De danske Løgfabrikker (KVA)
907026 NP Plastmo
907027 NP Peerless
907028 NP Stenders Kunstforlag
907038 NP Rias
907045 NP Supp. RC, edb-afd.
907047 NP Håndværksrådet
907048 NP GEODATA
190152 BML MEF
907505 BML Joran Bor A/S
907508 BML N. C. Nielsen
907509 BML FSV
907511 BML P. M. Frlich
907516 BML Tørring
907518 BML Nordisk Fjer
907519 BML Nordfyn
900501 BNH Foreningssystemer
907001 BNH Support: Eksport, RC
907010 BNH Support: RC-Datacenter
907011 BNH Support: PKA \f
907012 BNH Support: SPS
907013 BNH Support: Unic, Finland
907014 BNH Support: Centraal Beheer, NL
907015 BNH Support: DFØ
907023 BNH Support: Svejsecentralen
907029 BNH Support: Brdr. Dahl
907030 BNH Support: Søren T. Lyngsøe
907031 BNH Support: Stålvalseværket
907033 BNH Support: B&W Energi
907034 BNH Support: Eksperto
907035 BNH Support: Multicolor
907037 BNH Support: Renholdelsselskabet af 1898
907040 BNH Support: Scan-Atlas
190002 KAM DC-Sundhedsstyrelsen
190003 KAM DC-EF-dir.
190013 KAM DC-Hardware (stat.journal)
190014 KAM DC-KLV
190015 KAM DC-Matrikel
190016 KAM DIKU
190017 KAM SCR
190018 KAM Rigspolitichefen
190101 KAM DC-Journal
190117 KAM Risø
190132 KAM DFH
190136 KAM Helsingør Teknikum
190151 KAM Frederiksberg kommune
190129 NIA Farvandsdirektoratet
190130 NIA HCØ
190147 NIA HT
190149 NIA ISVA
190158 NIA Albertslund kommune (proces)
190159 NIA Geodætisk Institut
190160 NIA CLD
190161 NIA Farmaceutisk Højskole
190162 NIA MI
190164 NIA Arbejdsmiljøinstituttet
190920 NIA Teletex
190165 NIA Crone & Koch \f
190002 KAM DC-Sundhedsstyrelsen
190003 KAM DC-EF-dir.
190013 KAM DC-Hardware (stat.journal)
190014 KAM DC-KLV
190015 KAM DC-Matrikel
190016 KAM DIKU
190017 KAM SCR
190018 KAM Rigspolitichefen
190101 KAM DC-Journal
190105 PKJ Ballerup kommune
190106 MM Viborg kommune
190107 PKJ Esbjerg kommune
190108 MM Thisted kommune
190117 KAM Risø
190122 MM Kalundborg kommune
190123 MM Blåvandshuk kommune
190124 SV Vejle Elværk
190125 MM Bjerringbro kommune
190126 SV Tandlægehøjskolen i Århus
190127 SV Handelshøjskolen i Århus
190128 SV Kystinspektoratet
190129 NIA Farvandsdirektoratet
190130 NIA HCØ
190132 KAM DFH
190136 KAM Helsingør Teknikum
190137 SV Aalborg Sygehus, Syd
190139 SV Odense Sygehus
190147 NIA HT
190148 MM Ringsted kommune
190149 NIA ISVA
190150 SV Frederikshavn kommune
190151 KAM Frederiksberg kommune
190152 BML MEF
190153 SV DSB
190154 SV RECAU
190155 SV RECKU
190156 SV NEUCC
190157 PKJ Albertslund kommune
190158 NIA Albertslund kommune (proces)
190159 NIA Geodætisk Institut
190160 NIA CLD
190161 NIA Farmaceutisk Højskole
190162 NIA MI
190164 NIA Arbejdsmiljøinstituttet
190165 NIA Crone & Koch
190514 MM Gert Hansen
190920 NIA Teletex
900501 BNH Foreningssystemer
907001 BNH Support: Eksport, RC
907010 BNH Support: RC-Datacenter
907011 BNH Support: PKA
907012 BNH Support: SPS
907013 BNH Support: Unic, Finland
907014 BNH Support: Centraal Beheer, NL
907015 BNH Support: DFØ
907016 NP Vølund
907018 NP FDF/FPF
907020 NP Chr. Egelborg
907022 NP Industrirådet
907023 BNH Support: Svejsecentralen \f
907024 NP T. H. Strålfors
907025 NP De danske Løgfabrikker (KVA)
907026 NP Plastmo
907027 NP Peerless
907028 NP Stenders Kunstforlag
907029 BNH Support: Brdr. Dahl
907030 BNH Support: Søren T. Lyngsøe
907031 BNH Support: Stålvalseværket
907033 BNH Support: B&W Energi
907034 BNH Support: Eksperto
907035 BNH Support: Multicolor
907037 BNH Support: Renholdelsselskabet af 1898
907038 NP Rias
907040 BNH Support: Scan-Atlas
907045 NP Supp. RC, edb-afd.
907047 NP Håndværksrådet
907048 NP GEODATA
907501 SE Axel Toft, Durup A/S
907502 SE Emmelev Mølle A/S
907503 SE Hornsyld Købmandsgård
907504 SE Montax Aps
907505 BML Joran Bor A/S
907506 SE DDK
907507 SE Erling Jensen
907508 BML N. C. Nielsen
907509 BML FSV
907510 SE AKO
907511 BML P. M. Frlich
907512 SE Bilwinco
907513 SE Oue Savværk
907514 SE Plus Vejen
907515 SE Vestkraft
907516 BML Tørring
907517 SE Celebrity
907518 BML Nordisk Fjer
907519 BML Nordfyn
907521 SE Lynggaard Pedersen Data
907522 SE Aller Møller A/S \f
190152 BML MEF
907505 BML Joran Bor A/S
907508 BML N. C. Nielsen
907509 BML FSV
907511 BML P. M. Frlich
907516 BML Tørring
907518 BML Nordisk Fjer
907519 BML Nordfyn
900501 BNH Foreningssystemer
907001 BNH Support: Eksport, RC
907010 BNH Support: RC-Datacenter
907011 BNH Support: PKA
907012 BNH Support: SPS
907013 BNH Support: Unic, Finland
907014 BNH Support: Centraal Beheer, NL
907015 BNH Support: DFØ
907023 BNH Support: Svejsecentralen
907029 BNH Support: Brdr. Dahl
907030 BNH Support: Søren T. Lyngsøe
907031 BNH Support: Stålvalseværket
907033 BNH Support: B&W Energi
907034 BNH Support: Eksperto
907035 BNH Support: Multicolor
907037 BNH Support: Renholdelsselskabet af 1898
907040 BNH Support: Scan-Atlas
190002 KAM DC-Sundhedsstyrelsen
190003 KAM DC-EF-dir.
190013 KAM DC-Hardware (stat.journal)
190014 KAM DC-KLV
190015 KAM DC-Matrikel
190016 KAM DIKU
190017 KAM SCR
190018 KAM Rigspolitichefen
190101 KAM DC-Journal
190117 KAM Risø
190132 KAM DFH
190136 KAM Helsingør Teknikum
190151 KAM Frederiksberg kommune
190106 MM Viborg kommune
190108 MM Thisted kommune
190122 MM Kalundborg kommune
190123 MM Blåvandshuk kommune
190125 MM Bjerringbro kommune
190148 MM Ringsted kommune
190514 MM Gert Hansen
190129 NIA Farvandsdirektoratet
190130 NIA HCØ
190147 NIA HT
190149 NIA ISVA
190158 NIA Albertslund kommune (proces)
190159 NIA Geodætisk Institut
190160 NIA CLD
190161 NIA Farmaceutisk Højskole
190162 NIA MI
190164 NIA Arbejdsmiljøinstituttet
190165 NIA Crone & Koch
190920 NIA Teletex
907016 NP Vølund
907018 NP FDF/FPF
907020 NP Chr. Egelborg \f
907022 NP Industrirådet
907024 NP T. H. Strålfors
907025 NP De danske Løgfabrikker (KVA)
907026 NP Plastmo
907027 NP Peerless
907028 NP Stenders Kunstforlag
907038 NP Rias
907045 NP Supp. RC, edb-afd.
907047 NP Håndværksrådet
907048 NP GEODATA
190105 PKJ Ballerup kommune
190107 PKJ Esbjerg kommune
190157 PKJ Albertslund kommune
907501 SE Axel Toft, Durup A/S
907502 SE Emmelev Mølle A/S
907503 SE Hornsyld Købmandsgård
907504 SE Montax Aps
907506 SE DDK
907507 SE Erling Jensen
907510 SE AKO
907512 SE Bilwinco
907513 SE Oue Savværk
907514 SE Plus Vejen
907515 SE Vestkraft
907517 SE Celebrity
907521 SE Lynggaard Pedersen Data
907522 SE Aller Møller A/S
190124 SV Vejle Elværk
190126 SV Tandlægehøjskolen i Århus
190127 SV Handelshøjskolen i Århus
190128 SV Kystinspektoratet
190137 SV Aalborg Sygehus, Syd
190139 SV Odense Sygehus
190150 SV Frederikshavn kommune
190153 SV DSB
190154 SV RECAU
190155 SV RECKU
190156 SV NEUCC \f
190137 SV Aalborg Sygehus, Syd
907510 SE AKO
190158 NIA Albertslund kommune (proces)
190157 PKJ Albertslund kommune
907522 SE Aller Møller A/S
190164 NIA Arbejdsmiljøinstituttet
907501 SE Axel Toft, Durup A/S
190105 PKJ Ballerup kommune
907512 SE Bilwinco
190125 MM Bjerringbro kommune
190123 MM Blåvandshuk kommune
907517 SE Celebrity
907020 NP Chr. Egelborg
190160 NIA CLD
190165 NIA Crone & Koch
190003 KAM DC-EF-dir.
190013 KAM DC-Hardware (stat.journal)
190101 KAM DC-Journal
190014 KAM DC-KLV
190015 KAM DC-Matrikel
190002 KAM DC-Sundhedsstyrelsen
907506 SE DDK
907025 NP De danske Løgfabrikker (KVA)
190132 KAM DFH
190016 KAM DIKU
190153 SV DSB
907502 SE Emmelev Mølle A/S
907507 SE Erling Jensen
190107 PKJ Esbjerg kommune
190161 NIA Farmaceutisk Højskole
190129 NIA Farvandsdirektoratet
907018 NP FDF/FPF
900501 BNH Foreningssystemer
190151 KAM Frederiksberg kommune
190150 SV Frederikshavn kommune
907509 BML FSV
907048 NP GEODATA
190159 NIA Geodætisk Institut
190514 MM Gert Hansen
190127 SV Handelshøjskolen i Århus
190130 NIA HCØ
190136 KAM Helsingør Teknikum
907503 SE Hornsyld Købmandsgård
190147 NIA HT
907047 NP Håndværksrådet
907022 NP Industrirådet
190149 NIA ISVA
907505 BML Joran Bor A/S
190122 MM Kalundborg kommune
190128 SV Kystinspektoratet
907521 SE Lynggaard Pedersen Data
190152 BML MEF
190162 NIA MI
907504 SE Montax Aps
190156 SV NEUCC
907519 BML Nordfyn
907518 BML Nordisk Fjer
907508 BML N. C. Nielsen
190139 SV Odense Sygehus
907513 SE Oue Savværk \f
907027 NP Peerless
907026 NP Plastmo
907514 SE Plus Vejen
907511 BML P. M. Frlich
190154 SV RECAU
190155 SV RECKU
907038 NP Rias
190018 KAM Rigspolitichefen
190148 MM Ringsted kommune
190117 KAM Risø
190017 KAM SCR
907028 NP Stenders Kunstforlag
907029 BNH Support: Brdr. Dahl
907033 BNH Support: B&W Energi
907014 BNH Support: Centraal Beheer, NL
907015 BNH Support: DFØ
907034 BNH Support: Eksperto
907001 BNH Support: Eksport, RC
907035 BNH Support: Multicolor
907011 BNH Support: PKA
907010 BNH Support: RC-Datacenter
907037 BNH Support: Renholdelsselskabet af 1898
907040 BNH Support: Scan-Atlas
907012 BNH Support: SPS
907031 BNH Support: Stålvalseværket
907023 BNH Support: Svejsecentralen
907030 BNH Support: Søren T. Lyngsøe
907013 BNH Support: Unic, Finland
907045 NP Supp. RC, edb-afd.
190126 SV Tandlægehøjskolen i Århus
190920 NIA Teletex
190108 MM Thisted kommune
907516 BML Tørring
907024 NP T. H. Strålfors
190124 SV Vejle Elværk
907515 SE Vestkraft
190106 MM Viborg kommune
907016 NP Vølund \f
«eof»