|
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: 118656 (0x1cf80)
Types: TextFile
Names: »D88«
└─⟦e634bf8f4⟧ Bits:30005867/disk11.imd Dokumenter (RCSL m.m.)
└─⟦this⟧ »D88«
1. I_n_t_r_o_d_u_c_t_i_o_n_._
Development The present Skeleton Program for the Teledata version 3 has
been developed from the 01.10.1976 to the 01.04.1979. This
Experience design is based on the 3 years of experience in the routine
operation of the Teledata version 1 and a knowledge about
the users wishes for enlargements.
On-line It is intended as a framework of the on-line systems, not
only in Denmark but also in service centers and larger orga-
nizations all over the world.
Applications The primary forms of applications are:
- Maintenance of the logical file data
- Invoicing
- Order processing
Tools It is programmed in the DUET language and uses the SODA sys-
tem. The administration of the on-line transactions are at-
tended to by the operative system, TELEOP, which communi-
cates with the terminals by the DUETCOM.
It is based on the principle of on-line (transaction con-
Also Batch trolled) but it is also possible to run it in batch mode.
mode
Multi-user It is a multi-user system with a common database for all
users. The functions are implemented in the adaption can be
User Indivi- made user individual. The database is described in the DATA-
dual adaption BASE80 language.
Database The database is, with a few exceptions, a subset of the
SYSTEM80 reference database concerning the files and logical
files.
\f
1_._ _I_n_t_r_o_d_u_c_t_i_o_n_._
Skeleton Pro- In the structuring of the skeleton program it has been tried
gram to maintain the principles for the SYSTEM80 Skeleton Pro-
grams (hence the name) as e.g. record accesses, to a very
large extend, are executed in the Skeleton Program, and ac-
tivation of the adaption points are controlled by the Skele-
ton Program and the communication variables. However, on the
part of certain functions, a more rational structuring of
the SKP and a rational distribution of responsibilities be-
tween the SKP and the adaption has been considered, rather
Not quite than the fulfilling of the SYSTEM80 principles.
SYSTEM80
The distinction from the SYSTEM80 Skeleton Program is pri-
marily determined by the fact that the applied tools (SODA,
DUET) does not include an interpreter corresponding to
TRIMME80. This on the other hand allows certain liberties as
the programming language for the adaption is the DUET lan-
guage as well.
General The wide application area results in a general design, which
Framework partly gives a relative great liberty and partly demands
some implementation efforts for the adaption, in order to
start operations.
It must be anticipated that some functions in the Skeleton
Program will remain unused in some installations, while
Extensions others will need new - more advanced functions. Unlike a
SYSTEM80 Skeleton Program, new functions can be implemented
as adaption.
\f
1.1 T_e_r_m_i_n_o_l_o_g_y_._
Transaction It is not a record (as in S80) but a text line, which as a
body is controlled by the SKP. The line-code of the transac-
tion controls the progress of the SKP (see section 4, In-
put).
SKP Abbreviation for Skeleton Program.
\f
1.2 R_e_a_d_i_n_g_ _I_n_s_t_r_u_c_t_i_o_n_._
Introduction This manual describes the TD-Skeleton Program and is not an
attempt to give a general view of the TD-system. You can get
that by reading the Introduction to TELEDATA (cf. ref. 9).
Instruction After the general introduction, you can benefit by studying
the main sections about input, output and the introduction
to the functions in section 5.
After that you can concentrate upon the individual func-
tions, as you please.
\f
1.3 R_e_f_e_r_e_n_c_e_s_._
1. Database80 .......................... RCSL - 21-V045
2. Introduction - tools ................ - - 21-V001
3. Sysdok .............................. - - 21-V033
4. REORG80 ............................. - - 21-V051
5. SODA ................................ - - 21-V019
6. DUET ................................ - - 21-V046
7. TELEOP .............................. - - 21-T002
8. DUETCOM ............................. - - 21-T003
9. Introduction to TELEDATA ............ - - 21-T001
10. Boss 2 user manual .................. - - 42-i0952
11. FP - utilily programs, part 2 ....... - - 31-D422
12. TELEDATA Utility Programs ........... - - 21-T008
13. TELEDATA Utility Program TELEREES ... - - 21-T019
14. TELEDATA Utility Program TELESTATAC . - - 21-T030
15. TELEDATA Utility Program TELEDBEX ... - - 21-T020
16. GENIUS .............................. - - 21-V034
\f
2. D_A_T_A_B_A_S_E_
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_ P_a_g_e_
2.1 Database Description 8
- Logical Files and Record Types
(DB80)
2.2 Local Data - Set Descriptions 15
(SODA-LD)
\f
2.1 D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_._
The database description is the basis of the TELEDATA sys-
tem. In this description, the files, logical files, chains
and records, on which the system works are described in de-
tails. The TELEDATA Skeleton Program works on a database in-
cluding the following logical files listed in numerical or-
der.
Short
File No. Use Prefix File name file name Type
5 debtor/creditor dc debcred dc m
file
6 item it item it m
7 order file od orders od m
8 admin file adm tdadmin adm m
9 user file us userinf us m
19 debtor/creditor dcs debcred dcs l
structure file struct
20 parts - list file pl parts-list pl l
21 order line file odl orderlines l
23 debtor/creditor ae acc-entry ae l
entry file
24 order reference odr orderref odr l
file
75 terminal file ta term area ta sq
The diagram overleaf shows the structure of the files in the
database.
\f
2_._1_ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_
(tegning)
\f
2_._1_ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_._
C_o_m_m_e_n_t_s_ _o_n_ _t_h_e_ _T_e_r_m_i_n_a_l_ _A_r_e_a_:_
The terminal area is used as a working file in the voucher
manipulation. It is terminal individual, i.e. if you use
e.g. 17 terminals there will also exist 17 terminal files
but still only one description. Consequently, TELEOP does
not use the name under which the terminal area is described
in DATABASE80 but the name :WRKFILXX:', where XX indicates
the number of the actual terminal. This or these files must
exist as bs-files before the call of TELEOP. TELEOP also
handles the positioning of these files. For further details,
see the TELEOP manual.
The following pages are a summary of the record types which
the Skeleton Program can handle and a summary of the logical
files, they belong to. Only recordtypes with an >X> in the
>descr.>-column are described in the database at present.
\f
2_._1_ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_._
r_t_y_p_e_n_o_ _ _ _ _d_e_s_c_r_._ _ _ _ _ _ _ _ _r_t_y_p_e_n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _f_i_l_e_n_o_ _ _ _f_i_l_e_n_a_m_e_ _ _ _ _f_i_l_e_t_y_p_e_
501 x customer 5 debcred master
502 x supplier - - -
503 department - - -
601 x item 6 item master
602 x addition - - -
701 x sales _order 7 orders master
702 x purchase _order - - -
703 prod _order - - -
801 x user 8 tdadmin master
802 x term _admin - - -
803 x inp _form _type - - -
804 x outp _form _type - - -
805 x printer _admin - - -
806 x pool _admin - - -
901 x us _vat 9 userinf master
902 x us _texts - - -
903 x us _prices - - -
904 x us _currency - - -
905 x us _discount - - -
906 x us _group _disc - - -
907 x us _pay _conditions - - -
908 x us _add _table - - -
1901 x cust _structure 19 debcredstruc list
1902 x suppl _structure - - -
2001 x pl _structure 20 partslist list
2002 x pl _add _structure - - -
\f
2_._1_ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_._
r_t_y_p_e_n_o_ _ _ _ _d_e_s_c_r_ _ _ _ _ _ _ _ _ _r_t_y_p_e_n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _f_i_l_e_n_o_ _ _ _f_i_l_e_n_a_m_e_ _ _ _ _f_i_l_e_t_y_p_e_
2101 x odl _item _sale 21 orderlines list
2102 x odl _add _sale - - -
2103 x odl _text _sale - - -
2104 x odl _disc _purch - - -
2111 x odl _item _purch 21 orderlines list
2112 x odl _add _purch - - -
2113 x odl _text _purch - - -
2114 x odl _disc _purch - - -
2121 odl _item _prod 21 orderlines list
2122 odl _add _prod - - -
2123 odl _text _prod - - -
2124 odl _disc _prod - - -
2301 x ae _cust _entry 23 acc-entry list
2302 x ae _suppl _entry - - -
2303 ae _dept _entry - - -
2401 x ord _reference 24 orderref list
7501 x vs _sales _order 75 termarea seq
7502 x vs _purch _order - - -
7503 vs _prod _order - - -
7505 x ol _item _sale 75 termarea seq
7506 x ol _add _sale - - -
7507 x ol _text _sale - - -
7508 x ol _disc _sale - - -
\f
2_._1_ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_._
r_t_y_p_e_n_o_ _ _ _ _d_e_s_c_r_ _ _ _ _ _ _ _ _ _r_t_y_p_e_n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _f_i_l_e_n_o_ _ _ _f_i_l_e_n_a_m_e_ _ _ _ _f_i_l_e_t_y_p_e_
7509 x ol _item _purch 75 termarea seq
7510 x ol _add _purch - - -
7511 x ol _text _purch - - -
7512 x ol _disc _purch - - -
7513 ol _item _prod - - -
7514 ol _add _prod - - -
7515 ol _text _prod - - -
7516 ol _disc _prod - - -
7520 x delivery _cust 75 termarea seq
7521 x account _cust - - -
7522 x invoice _cust - - -
7523 x delivery _suppl - - -
7524 x account _suppl - - -
7525 x invoice _suppl - - -
7526 delivery _dept - - -
7527 account _dept - - -
7528 invoice _dept - - -
7530 x il _item _cust 75 termarea seq
7531 x il _add _cust - - -
7532 x il _text _cust - - -
7533 x il _disc _cust - - -
7534 x il _item _suppl - - -
7535 x il _add _suppl - - -
7536 x il _text _suppl - - -
7537 x il _disc _suppl - - -
7538 il _item _dept - - -
7539 il _add _dept - - -
7540 il _text _dept - - -
7541 il _disc _dept - - -
\f
2_._1_ _ _D_a_t_a_b_a_s_e_ _D_e_s_c_r_i_p_t_i_o_n_._
r_t_y_p_e_n_o_ _ _ _ _d_e_s_c_r_ _ _ _ _ _ _ _ _ _r_t_y_p_e_n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _f_i_l_e_n_o_ _ _ _f_i_l_e_n_a_m_e_ _ _ _ _f_i_l_e_t_y_p_e_
7550 x copy _ol _item _sale 75 termarea seq
7551 x copy _ol _add _sale - - -
7552 x copy _ol _item _purch - - -
7553 x copy _ol _add _purch - - -
7554 copy _ol _item _prod - - -
7555 copy _ol _add _prod - - -
7560 x copy _customer 75 termarea seq
7561 x copy _supplier - - -
7562 copy _department - - -
7563 x copy _sales _order - - -
7564 x copy _purch _order - - -
7565 copy _prod _order - - -
7570 x acc _entry _head 75 termarea seq
7571 x entry _line _cust - - -
7572 x entry _line _suppl - - -
7573 entry _line _dept - - -
7580 copy _ol _text _sale 75 termarea seq
7581 copy _ol _disc _sale - - -
7582 copy _ol _text _prch - - -
7583 copy _ol _disc _prch - - -
7584 copy _ol _text _prod - - -
7585 copy _ol _disc _prod - - -
\f
2.2 L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
As the DUET system and consequently the Skeleton Program
works on variables and not on zonerecords, it is necessary
to work out a description that expresses the relations be-
tween fields in the database and the above mentioned vari-
ables. This description called the SODA-LD-description, con-
tains, at record type level, information about which fields
are transferred to what variables and vice versa, dependent
on the database-operation carried out. The above-mentioned
relations between database-fields and variables are descri-
bed in record-sets.
Below follows a list of all the record-sets that the Skele-
ton Program is working on and a supplementary explanation to
each set. Finally a table shows the relations between each
Skeleton Program line-code and the used sets.
When adding adaptions to the SKP, this SODA-LD might be ex-
tended.
\f
2_._2_ _ _L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
T_a_b_l_e_:_ _R_e_c_o_r_d_ _-_ _s_e_t_s_._
subscripted
s_e_t_n_o_ _ _ _s_e_t_n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _s_e_t_t_y_p_e_ _ _ _f_i_l_e_ _ _ _ _b_y_ _s_e_t_n_o_._ _ _
1 items master it
2 reference _item - -
3 parent _item - -
4 part _item - -
5 parts _list list pl 3
6 deb _cred master dc
7 parent _deb _cred - -
8 part _deb _cred - -
9 deb _cred _ref _list list dcs 7
10 useradm master us
11 adm - adm
12 used _list list pl 4
13 part _deb _cred _ref - dcs 8
14 termadm master adm
15 adm _extra - -
16 deb _cred _read - dc
17 order _without _lines - od
18 order _line list odl 21
19 cal _start seq ta
20 order _line _get list odl
21 order _with _lines master od
22 sq _part _it _lines seq ta
23 sq _records - - \f
2_._2_ _ _L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
subscripted
s_e_t_n_o_ _ _ _S_e_t_n_a_m_e_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _s_e_t_t_y_p_e_ _ _ _f_i_l_e_ _ _ _ _b_y_ _s_e_t_n_o_._
24 user master adm
25 od _line _from _item list odl 3
26 order _line _copy seq ta
27 orderlist list odr 8
28 sq _deb _cred _copy seq ta
29 acc _entry list ae
30 cal _lines seq ta
31 disc _lines - -
32 od _dc _list list odr 21
33 ref _deb _cred master dc
34 part _dc _ref _x list dcs 16
\f
2_._2_ _ _L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
D_e_s_c_r_i_p_t_i_o_n_ _o_f_ _t_h_e_ _U_s_e_ _o_f_ _t_h_e_ _I_n_d_i_v_i_d_u_a_l_ _S_e_t_s_._
S1: Used for logical file maintenance of item records and
thus contains all fields, which are supposed to be main-
tained. Furthermore the set is used on inquiries about item
records.
S2: Used to create item record with a dynamic standard va-
lue, i.e. creation of a new item record with the content of
an old one. The set thus contains the fields to be copied,
and works on the same variables as S1.
S3: Used for parts list maintenance and inquiries plus order
processing and invoicing. In parts list maintenance, the set
is used for parent item and is on hand simultaneously with
S4 (part items) and thus these sets must never share vari-
ables. In order processing and invoicing, the set is used
for the neutral or the parent item. The variables must be
the same as in S1 (logical file maintenance) because the
adaption used here is meant to be reused.
S4: Used for parts list maintenance and inquiries, plus or-
der processing and invoicing of part item. Conflict with S3:
see here.
S5: Used for parts list processing in logical file mainte-
nance, inquiries plus order processing and invoicing toget-
her with S3 and S4. If the part item S4 is wanted, S4-key-
variables are to be assigned. They must not be assigned
through the SODA-LD.
S6: Used for logical file maintenance of debtor/creditor re-
cord and inquiries on this. Contains relevant fields for lo-
gical file maintenance.
\f
2_._2_ _ _L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
S7: Used for debtor/creditor structure processing to fetch
the higher level debtor/creditor record. Must not use the
same variables as S8.
S8: Used in logical file maintenance, inquiries, order pro-
cessing, invoicing and account entries. In logical file
maintenance and inquiries to fetch the low level debtor/cre-
ditor records. In order processing to create the debtor/cre-
ditor-order connection. In invoicing as a basis for scanning
of the debtor/creditor chain. In account entries for crea-
tion of entry lines.
S9: Used for debtor/creditor structure processing in logical
file maintenance and inquiries. If low level debtor/creditor
is wanted then assign S8-key-variables. (Commments similar
to S5).
S10: Used for logical file maintenance of user-file and in-
quiries on this.
S11. Used for logical file maintenance and inquiries on ad-
ministrative records. On hand simultaneously with S14. Thus
the variables transferred to fields by S14 must not be in
use here.
S12: Used for inquiries on where-used list.
S13: Used for inquiries on higher level list records in deb-
tor/creditor file and in invoicing to provide keys for the
high level debtor/creditor-record.
S14: Used by TELEOP to fetch the terminal administration
record of the current terminal. May be on hand simultaneous-
ly with S11 (see here).
\f
2_._2_ _ _L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
S15: Used for logical file maintenance of administration re-
cords to check the reference between output administration
and output-pool records.
S16: Used for order processing and invoicing voucher hea-
dings to fetch current debtor/creditor record. Same varia-
bles as S6.
S17: Used for updating order records and nothing else. Can-
not be used for scanning of order lines.
S18: Used for creation of order lines and scanning of order
line file.
S19: Used for voucher calculation to retrieve voucher re-
cords in the terminal file both for order processing and in-
voicing.
S20: Used for order line creation in order processing. After
a potential parts list scan the parent order line must be
fetched and updated with the number of part order lines.
S21: Used in order processing and invoicing for copying or-
der fields to terminal file and as order record set in con-
nection with order list scanning.
S22: Used to create voucher lines in terminal file for part
items accessed during parts list processing.
S23: Used for generating voucher lines in terminal file.
S24: Used for order processing and invoicing to fetch user
record.
\f
2_._2_ _ _L_o_c_a_l_ _D_a_t_a_ _-_ _S_e_t_ _D_e_s_c_r_i_p_t_i_o_n_s_._
S25: Used in order processing for scanning of order lines
from item viewpoint. On hand simultaneously with S18 and
thus they must not share variables.
S26: Used for copying order lines accessed by item order
line scanning. The copies made are put in the terminal
file.
S27: Used in order processing and invoicing to create and
fetch the debtor/creditor-order connection, respectively.
S28: Used in invoicing to generate a debtor/creditor copy-
record in the terminal file.
S29: Used in invoicing and accounting to generate account
entries.
S30: Used in voucher calculation for scanning of voucher
lines. As new voucher lines might be created with S23 during
the scan, it should not share variables with S23.
S31: Used for access of discount lines generated during the
itemgroup discount calculation.
S32: Used for control purposes concerning the connection
from order to debtor/creditor.
S33: Used for debtor/creditor reference in logical file
maintenance concerning creation of debtor/creditor records
with dynamic standard values.
S34: Used for debtor/creditor structure list processing in
invoicing.
\f
3. O_u_t_p_u_t_
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_ P_a_g_e_
3.0 Introduction 29
3.1 Errors, Warnings and Answers 30
3.2 Handling of printers 31
3.3 Print Outs 32
3.4 Transactions from DUETCOM Concerning Output 35
3.5 Extension of the Output System 36
\f
3.0 I_n_t_r_o_d_u_c_t_i_o_n_._
Print-outs in The TELEDATA Skeleton Program does not directly produce out-
adaption put, as print outs of all kinds are placed in the code
adaption in order to make all print outs in the user>s
customary language.
3 types of The Skeleton Program administers most of the print outs.
They are divided into the following types
- errors and warnings (see section 6)
- answers to inquiries (see section 5.4)
- print-outs (see section 5.10 and 5.11)
Printouts from other parts of the TELEDATA system (TELEOP,
DUETCOM) are not described in this manual.
We shall, at this point, make some comments on the admini-
stration of output (see for further information, section 8.1
concerning TELEOP-communication).
\f
3.1 E_r_r_o_r_s_,_ _W_a_r_n_i_n_g_s_ _a_n_d_ _A_n_s_w_e_r_s_._
Print-channel These are printed via printchannel 2, which SKP selects as a
2 to the ter- standard. This channel is opened by TELEOP to a reply-area
minal before the activation of the DUET-interpreter. After the
DUET-interpreter has terminated its processing, the written
text (if any) is printed out on the terminal via DUETCOM (if
TELEOP runs in the off-line mode, the text remains in the
Reply-areas reply-area). The reply-areas are terminal-individual and
one per termi- they are described in the terminal administration record
nal (name, position). TELEOP has access to this description and
updates it.
\f
3.2 H_a_n_d_l_i_n_g_ _o_f_ _P_r_i_n_t_e_r_s_
The two types of printers (common and seperate) are inter-
nally handled in two different ways, but externally the use
should not differ.
Seperate printers, i.e. printers allocated to a specific
terminal, are kept track of in the terminal administration
record.
Selective printers, i.e. printers available to a user who
knows the identification of it, have their own administra-
tion record.
For both types an output type or a textfile name is saved to
ensure that a repetition of the print out can be performed
in case of a breakdown.
For selective printers also a position in the textfile is
saved in case of abnormal termination of a print out, this
ensures the possibility of resuming the print out from a
certain position.
In general the printer administration prevents an unintended
print out of the same text file, as one print out must be
accepted before a new print out can take place.
\f
3.3 P_r_i_n_t_ _O_u_t_s_._
These include e.g. invoice, delivery notes, order confirma-
tion etc.
Print channel These are printed via print channel 1, which is selected and
1. One text opened by SKP to the text area of the current output type
area per out- (see function >print output>, section 5.11).
put type
In section 5.10 the administration of the printing of these
text areas on printer is described. The principle of this
administration is that only the text areas and their status
Control of are administered. A control of the printers can be build up
printers in the adaption and be adjusted to each individual user.
Print out or- The print out on printer is carried out by DUETCOM, but must
der be initialized by a transaction (print out order) to TELE-
DATA:
At a print out order, the SKP will call an algol operation
stating the name of the text area and the identification of
the printer on which the print out is to be made. From the
algol operation there is communication to DUETCOM which
either starts the print out or rejects it (e.g. illegal
printer identification, printer engaged).
Convert not ok If DUETCOM rejects the print out, SKP will register this and
from DUETCOM an error-message will be printed out on the terminal.
If DUETCOM accepts the print out, a transaction will later
(when the print out is terminated) be sent from DUETCOM to
TELEDATA, containing information about the results ("Convert
Convert ok OK" or Convert not OK". SKP does not itself handle these
from DUETCOM transactions, see below). The transactions have the same
identification as the previously mentioned message to DUET-
COM in the beginning of the print out.
\f
3_._3_ _ _P_r_i_n_t_ _o_u_t_s_._
This means that the transactions from DUETCOM may contain an
identification of either a terminal or a printer.
The identification must be assigned in the code adaption ac-
tivated by the print out order.
C_o_d_e_ _a_s_ _a_n_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_._
As ident-field you may assign the numbers 16 or 30 as a code
Print out on for DUETCOM. If code = 16 is used, DUETCOM will print out on
common printer the common printer (non-selective or seperate) which is at-
tached to the terminal, if such a printer exists - if not,
it will print out on the terminal (to which a hard-copy-
printer can be attached). If code = 30 is used, DUETCOM
will print out on the terminal.
P_r_i_n_t_e_r_ _N_a_m_e_ _a_s_ _a_n_ _I_d_e_n_t_i_f_i_c_a_t_i_o_n_._
Print out on According to a convention, printers are identified by a text
selective constant (3 characters), of which the 2 first are the prin-
printer ter number and the last the letter p, e.g. .19P. for printer
19. If this syntax is used, DUETCOM will print out on the
selective (non-common) printer with this identification.
Results of DUETCOM returns the result of a print out to a selective
print out on printer in a transaction with the same ident field as was
a selective used in the start transaction, and TELEDATA thus receives a
printer transaction with a printer ident field. When this happens
TELEOP will not perform the operations usual before a trans-
action (such as accessing the termadm record), but will
assign the communication variable "printerno" to the
contents of the ident field of the transaction (in all other
cases the printerno = 0). In that case SKP will at once call
the adaption code in block (23,1).
\f
3_._3_ _ _P_r_i_n_t_ _O_u_t_s_._
Result of DUETCOM returns the result of a print-out on a common prin-
print out on ter in a transaction with the ident field containing the
common printer terminal identification (of the terminal that originated the
print-out). Therefore, these transactions will be handled as
normal transactions, but SKP cannot "recognize" the line-
code (see below), and consequently call the block adaption
block (adp block 19, 1).
Results of DUETCOM returns no result of a print-out on the terminal
print out on
terminal \f
3.4 T_r_a_n_s_a_c_t_i_o_n_s_ _f_r_o_m_ _D_U_E_T_C_O_M_ _C_o_n_c_e_r_n_i_n_g_ _O_u_t_p_u_t_
Line-codes All transactions can have either a printer - or a terminal
from DUETCOM identification. The line-codes are indicated by character
values surrounded by brackets '.
Line-code meaning
3' 3' convert OK, normal termination of print
out
4' 4' convert not OK, hard error on text
6' 6' convert interrupted
\f
3.5 E_x_t_e_n_s_i_o_n_ _o_f_ _t_h_e_ _O_u_t_p_u_t_ _S_y_s_t_e_m_
As it will appear from studies of the Skeleton Program, this
also includes the maintenance of some administration records
Pooling admin which are not used in any function. They concern pooling.
These can be regarded as not yet exhausted possibilities for
the extension of the output system.
\f
4. I_n_p_u_t_._
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_ P_a_g_e_
4.0 Introduction 38
4.1 Input Structure 39
4.2 Transaction Structure 40
4.3 Transaction Summery 42
\f
4.0 I_n_t_r_o_d_u_c_t_i_o_n_._
As the present Skeleton Program includes the on-line-part of
Primarily on- TELEDATA, only on-line transactions - i.e. transactions that
line-trans are normally read in from a terminal - are included in this
description.
By this, processing of input in a batch-run of the Skeleton
Program (with the belonging adaption code) is not excluded,
neither is processing of transactions from other external
devices than terminals - all that is demanded, on the part
of the Skeleton Program, is:
State check - that the transactions are delivered in a way accep-
table to the state check made by the system, etc.
(cf. section 5.1)
Form of trans- - that the forms of the transactions suit the reading
action performed by the Skeleton Program.
Error-treat- At this point it must be emphasized that the processing of
ment based on erroneous transactions is based on on-line communication
on-line with the operator at the terminal. This causes a rather sim-
ple error-processing as the transactions can be corrected
immediately. This contrasts with a batch-processing, where
each seperate error must be considered, as to its conse-
quence for the whole voucher (if in a voucher structure).
\f
4.1 I_n_p_u_t_ _S_t_r_u_c_t_u_r_e_._
As as result of TELEDATA>s character as a real time multi-
user system, it is possible to process an arbitrary stream
of transactions of various kinds and from various users and
- in most cases - use these transactions for an updating of
One transac- the database. This circumstance is reflected in the Skeleton
tion at a time Program by the fact that each transaction is received and
finished before the next transaction is >taken in>.
A transaction is not a record but a text, terminated with a
standard character (see TELEOP and DUETCOM). It contains as
Identification the first 3 ISO - characters an identification of the ori-
of the trans- gin, usually the terminal number followed by a comma (see,
action however, section 3.3, output - system). These 3 characters
are read by TELEOP which can access the terminal administra-
tion record given by the terminal number. Then the SKP takes
Line-code over and reads the line-code from the 4th character of the
transaction.
\f
4.2 T_r_a_n_s_a_c_t_i_o_n_ _S_t_r_u_c_t_u_r_e_._
Syntax not The Skeleton Program makes very few direct demands on the
locked structure and syntax of the transactions. Apart from the
Reading in line-code, SKP does not, with very few exceptions, read in
code adaption the transaction, i.e. all reading takes place in the code
adaption. SKP however, "expects" certain variables to be
assigned with a reasonable value in the adaption points.
This, combined with the fact that the reading of the trans-
action is "from left to right" provides some fairly fixed
limits for the structuring of the transaction.
Conventions The description below is therefore to be taken as a conven-
for the syn- tion, which normally should be followed but not always has
tax to be.
An input transaction is normally built up of the following
constituents:
Line-code
fixed transaction information
variable transaction information
information code, information
T_h_e_ _l_i_n_e_ _c_o_d_e_ is read by the Skeleton Program and interpre-
Controlled by ted in a user individual adaption point into a Skeleton Pro-
SKP gram line-code. It consists of max. 3 characters as it is
read into a word variable.
Controlled by F_i_x_e_d_ _t_r_a_n_s_a_c_t_i_o_n_ _i_n_f_o_r_m_a_t_i_o_n_ is read in a user individual
SKP adaption point, but the reading is activated by the Skeleton
Program. The fixed transaction information is typical record
identifiers (keys).
Because of the Skeleton Program, it is necessary to use a
fixed format per transaction type for this part of the
transactions. \f
4_._2_ _ _T_r_a_n_s_a_c_t_i_o_n_ _S_t_r_u_c_t_u_r_e_._
Controlled by V_a_r_i_a_b_l_e_ _t_r_a_n_s_a_c_t_i_o_n_ _i_n_f_o_r_m_a_t_i_o_n_ is read in a user indivi-
adaption dual adaption point. The reading of this information is con-
trolled by the adaption and may e.g. take place in a fixed
sequence (and within a fixed format) to the effect that the
reading stops when meeting a new-line-character, an informa-
tion-code or when the format is exhausted.
The transaction information is often information which is
Not normally used during the transaction processing. But normally it does
record fields not correspond to copies of record-fields. If no variable
transaction information is read in, standard values are
used.
I_n_f_o_r_m_a_t_i_o_n_-_c_o_d_e_,_ _i_n_f_o_r_m_a_t_i_o_n_ is read in a user individual
adaption point - usually in the same which is used for vari-
able transaction information. The read information causes a
temporary deviation from the information which exists in the
records. The adaption should, as far as possible, reuse the
logical file maintenance adaption with regard to the imple-
mentation and maintenance, but so that information "dange-
rous" to maintain from a routine transaction (e.g. order en-
try transactions) is excluded. The reading is controlled by
the adaption point.
\f
4.3 T_r_a_n_s_a_c_t_i_o_n_ _S_u_m_m_a_r_y_._
Organized according to function, the Skeleton Program can
process the following types of transactions:
- system transactions, used for controlling the system
(e.g. login, logout)
- administrative transactions, used by the installa-
tions>s administration for the preparation of user>s,
etc
- logical file maintenance transactions, used (by the
user) for maintenance (creation, deletion, modifica-
tion) of the user>s basic records
- inquiry-transactions, used by the user for inquiries on
contents of logical files (record-contents)
- order-entry transactions, used by the user for creation
of orders and order maintenance
- invoicing transactions, used by the user for invoicing
- account entry transactions, used by the user for ente-
ring and maintenance of account entries
- miscellaneous transactions, containing, among other
things, display transactions, print out commands and
transactions for other systems
The above is only a rough outline and does not quite follow
the outline in section 5 and in the SKP.
\f
5. T_r_a_n_s_a_c_t_i_o_n_s_ _a_n_d_ _F_u_n_c_t_i_o_n_s_ _i_n_ _t_h_e_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_ P_a_g_e_
5.0 Reading Instruction for Skeleton Program
Dokumentation 44
5.1 Initialization and Termination 48
5.2 Logical File Maintenance 69
5.3 Administrative Transactions (Z-Transactions) 116
5.4 Inquiry Transactions 137
5.5 Order Entry Vol II
5.6 Invoicing do
5.7 Miscellaneous Transactions Vol III
5.8 Terminal Control do
5.9 Account Entry do
5.10 Print Out Transactions do
5.11 Function: >Print Output> do
Sections 5.5 and 5.6 are placed in Volume II while sections
5.7 to 5.11 are placed in Volume III of this manual.
\f
5.0 R_e_a_d_i_n_g_ _I_n_s_t_r_u_c_t_i_o_n_ _f_o_r_ _t_h_e_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_o_k_u_m_e_n_t_a_t_i_o_n_
The Skeleton Program - written in the programming language
DUET - has, in this manual, been ducumented by flow diagrams
and by descriptions of the adaption points. For further de-
tails we refer to the program print-outs from DUETABLER, and
to the SODA-LD description. In the following passage, the
rules and conventions etc. that have been used in the wor-
king out of this manual, are described.
F_l_o_w_ _D_i_a_g_r_a_m_s_
Flow diagrams are used as documentation for the Skeleton
Program. The diagrams are produced principally to show:
- record-accesses (set operations)
- the connection between adaption points
- error reactions in the Skeleton Program
The usual flow diagram symbols have been used, but the de-
scription technique uses some special conventions, which are
described in the following passage.
D_U_E_T_ _i_n_s_t_r_u_c_t_i_o_n_ _n_u_m_b_e_r_s_._ For each >operation> (rectangle)
or >condition> (rhombe) the number of the duet instruction,
where the >operation>/>condition> is carried out, has been
indicated. The single >operation>/>condition> may cover se-
veral DUET-operations. However, on a few occasions (e.g. in
certain outlinediagrams) the DUET instruction number is not
shown.
T_a_b_l_e_ _r_e_f_e_r_e_n_c_e_._ Where it has been thought appropriate, the
>operations>/>conditions> have been shown in table form - in
that case the flow diagram contains a reference to the table
in question.
\f
5_._0_ _ _R_e_a_d_i_n_g_ _I_n_s_t_r_u_c_t_i_o_n_ _f_o_r_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_o_c_u_m_e_n_t_a_t_i_o_n_
R_e_f_e_r_e_n_c_e_ _t_o_ _o_t_h_e_r_ _D_U_E_T_ _i_n_s_t_r_u_c_t_i_o_n_s_. An >operation> may co-
ver several DUET instructions. If the function of the opera-
tion is of importance for the understanding of the Skeleton
Program, a reference is given to more detailed flow dia-
grams.
B_l_o_c_k_ _r_e_f_e_r_e_n_c_e_s_ are used as reference to other DUET-in-
structions when these are placed in another block than the
one in question. The reference is given as B(block num-
ber',entry point'). Note that the DUET instruction referred
to, are actually carried out on the place in the flow dia-
gram, where the reference is met. This type of reference is
used especially by references to adaption code (adaption
points).
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
The adaption point descriptions are set up according to a
fixed scheme, which is described in the following passages:
Number: Within each transaction/function, each adaption
point has been given a number as an identifier.
The number is used in the Skeleton Program docu-
mentation and as a comment in the DUET-code for
the Skeleton Program, but it has no significance
in the running system.
Designation: A short description of the function of the a-
daption point. It is used as a supplementary i-
dentifier for the adaption point in connection
with the documentation.
Reading: Indicates the area for reading of input. In
principle it is possible to read input from all\f
5_._0_ _ _R_e_a_d_i_n_g_ _I_n_s_t_r_u_c_t_i_o_n_ _f_o_r_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_o_c_u_m_e_n_t_a_t_i_o_n_
adaption points but this point is only filled
out for those adaption points where the reading
is appropriate.
Writing: Indicates the area for printing of output. Com-
ments are analogous to comments under reading.
Conditions
for activation: Here the conditions are indicated which must
be fulfilled in order to reach the adaption
point in question from the nearest preceding a-
daption point. The description is to be regarded
as a briefing - a more detailed understanding of
the Skeleton Program>s dynamics must be based on
the flow diagrams (or the program print-out)
and the set descriptions.
Comm. vari-
ables: Communication variables are used for communica-
tion between the Skeleton Program and the adap-
tion - especially for control of certain Skele-
ton Program functions from the adaption. Usual-
ly, communication variables are only described
in those adaption points that follows immidiate-
ly after the (re-)initialization of the variab-
les.
The initialization is made by the Skeleton Pro-
gram - usually by a direct assignment (i.e. co-
ded), perhaps from a record. The communication
variables - like other variables in DUET - are
global, which means that they are all available
in all adaption points but not necessarily with
a significant content. \f
5_._0_ _ _R_e_a_d_i_n_g_ _I_n_s_t_r_u_c_t_i_o_n_ _f_o_r_ _S_k_e_l_e_t_o_n_ _P_r_o_g_r_a_m_ _D_o_k_u_m_e_n_t_a_t_i_o_n_
Use: Here, the suggested/expected use of the adaption
point is briefly described.
Block Refe-
rence: Reference to the block and the entry where the
adaption is to be inserted (as code).
Next adap-
tion point: Indicates possible adaption points after the
current one, including possible adaption points
from other functions/transactions than the one
in question.
\f
5.1 I_n_i_t_i_a_l_i_z_a_t_i_o_n_ _a_n_d_ _T_e_r_m_i_n_a_t_i_o_n_
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_ P_a_g_e_
5.1.1. Outline 49
5.1.2. Initialization and Reading of the Line Code 54
5.1.3. Unpack skp _line _code 55
5.1.4. Test of Legal Port 56
5.1.5. Test Blocking 57
5.1.6. Test State 58
5.1.7. Check on Voucher Transaction 59
5.1.8. Select Processing 61
5.1.9. Terminate Transaction 67
\f
5.1.1 O_u_t_l_i_n_e_
The TELEDATA operating System TELEOP, reads transactions
either via DUETCOM (on-line) or via a bs-area. General to
all transactions is the fact that they have a terminal num-
ber as a unique identification of their origin. TELEOP has 2
input-zones which can be used for the performance.
In order to get a well arranged control of transactions,
terminals, modes of operations etc., all transactions are
processed alike without regard to the mode of operation or
origin. In SKP, however, the restriction has been introduced
that transactions from the same terminal and via both input-
zones cannot be processed simultaneously. This situation
might arise if you run priority 1 and priority 2 (mode of o-
peration 2). The above control is decisive for whether SKP
will accept the receipt of transactions at all from a cer-
tain terminal or not, and thus it may be considered as an i-
nitialization to the transaction processing. Furthermore, it
is checked whether the terminal is blocked or not. If it is
blocked, the only legal transaction is a logout-transac-
tion.
When the processing of a transaction is finished, it is
registered in the term. admin. record whether the transac-
tion last processed has left the system in an error state or
not. This information is preserved in the field admin error
state, which by the start of a transaction is initialized to
1 and which by the termination is reset to 0 if the transac-
tion processing has not been cut off because of errors.
\f
5_._1_._1_ _O_u_t_l_i_n_e_
T_e_s_t_ _T_r_a_n_s_a_c_t_i_o_n_s_. The DUET system and the SODA procedures
can produce test output, controlled by the pattern in some
test variables, testa, testb, ..., testh (cf. DUET manual).
By some special transactions (skp _line _code =. TS.) it is
possible to "switch on" or "off" the test output associated
with variables test, testb, ..., testd. The output will be
printed in the reply area for the terminal that activated
the test output. The general input syntax for the transac-
tion is:
line _code'(onoff)((abcd)(01...23))0UU1DDDD0UU5
An example:
ts on d 1 2 3 6 12 18
\f
5_._1_._1_ _O_u_t_l_i_n_e_
(tegning)
\f
5_._1_._1_ _O_u_t_l_i_n_e_
(tegning)
\f
5_._1_._1_ _O_u_t_l_i_n_e_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 0
Designation : Convert line code
Reading :
Writing :
Conditions for
activation : When the line code is read from the input
buffer or assigned from term.admin.
Comm. variables: Translation and interpretation of the line
code read (adaptable) to internal
representation (skp-line-code).
Block reference: B(adp _block _1,1).
Next adaption
point : Adp 1 in the designated function (cf. with
section 5.1.8) or adp a.
\f
5.1.2 R_e_a_d_ _L_i_n_e_ _C_o_d_e_
(tegning)
\f
5.1.3 U_n_p_a_c_k_ _S_k_p_ _L_i_n_e_ _C_o_d_e_
(tegning)
\f
5.1.4 T_e_s_t_ _o_f_ _L_e_g_a_l_ _P_o_r_t_
(tegning)
\f
5.1.5 T_e_s_t_ _B_l_o_c_k_i_n_g_
(tegning)
\f
5.1.6 T_e_s_t_ _T_e_r_m_i_n_a_l_ _S_t_a_t_e_
(tegning)
\f
5.1.7 C_h_e_c_k_ _o_n_ _V_o_u_c_h_e_r_ _T_r_a_n_s_a_c_t_i_o_n_
(tegning)
\f
5_._1_._7_ _C_h_e_c_k_ _o_n_ _V_o_u_c_h_e_r_ _T_r_a_n_s_a_c_t_i_o_n_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : a
Designation : State control
Reading :
Writing :
Conditions for
activation : After conversion of the line _code (adp 0).
Comm. variables:
Use : Controlling whether the received transac-
tions keep the rules for voucher struc-
tures.
Error reaction when breach of rules.
Block reference: B(adp _block _1,2)
Next adaption
point : Adp 1 in the designated function (cf. with
section 5.1.8).
\f
5.1.8 S_e_l_e_c_t_ _P_r_o_c_e_s_s_i_n_g_
(tegning)
\f
5_._1_._8_ _S_e_l_e_c_t_ _P_r_o_c_e_s_s_i_n_g_
(tegning)
\f
5_._1_._8_ _S_e_l_e_c_t_ _P_r_o_c_e_s_s_i_n_g_
T_e_s_t_ _T_r_a_n_s_a_c_t_i_o_n_
(tegning)
\f
5_._1_._8_ _S_e_l_e_c_t_ _P_r_o_c_e_s_s_i_n_g_
(tegning)
\f
5_._1_._8_ _S_e_l_e_c_t_ _P_r_o_c_e_s_s_i_n_g_
(tegning)
\f
5_._1_._8_ _ _S_e_l_e_c_t_ _P_r_o_c_e_s_s_i_n_g_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : b
Designation : User-transaction
Reading : From input buffer
Writing :
Conditions for
activation : After conversion of the line-code (adp 0).
If skp _first _char = .X.
Comm. variables:
Use : Processing of transactions that cannot be
processed by the Skeleton Program - e.g.
transactions for other systems.
Block reference: B(adp _block 19,1)
Next adaption
point : Exit
\f
5.1.9 T_e_r_m_i_n_a_t_e_ _T_r_a_n_s_a_c_t_i_o_n_
(tegning)
\f
5_._1_._9_ _T_e_r_m_i_n_a_t_e_ _T_r_a_n_s_a_c_t_i_o_n_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : c
Designation : Modification of the communication variable
Reading :
Writing :
Conditions for
activation : The current transaction has been finished
and some error was detected in it.
Comm. variables: listtrans
1: the erronous transaktion is to be lis-
ted
'1: the erronous transaction is not to be
listed
call : 1
answer: 1 or '1
Use : Modify the variable, listtrans, if a
listing is not wanted.
Block Reference: B(adp _block1,3)
Next adaption
point : None
\f
5.2 L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_._
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_._P_a_g_e_
Introduction 70
Outline and Tables 73
5.2.1 Update Master 78
5.2.2 Update Structure List 82
5.2.3 Create Master 89
5.2.4 Create Structure List 94
5.2.5 Delete Master 103
5.2.6 Delete Structure List 108
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
I_n_t_r_o_d_u_c_t_i_o_n_
Logical file maintenance includes transactions for mainte-
nance of the user>s basic data, indcluding:
- creation of logical file records
- updating of user information in logical file records
- deletion of logical file records
The maintainable logical files by the here mentioned trans-
actions are:
- user file (vat-, rebate-, currency- records, etc.
- debtor/creditor file, potentially with a debtor/cre-
ditor structure list
- item file, potentially with a parts list
The transactions can be used by the user from his own termi-
nals.
Maintenance of the remaining logical files of the system is
carried out as follows:
- Administrative records are maintained with admini-
strative transactions (cf. section 5.3) and can only
be made from an administrative terminal (system-ter-
minal)
- Order file (order master), order line list and order
reference list are maintained by the user with usual
working transactions. (cf. order entry, section 5.5
and invoicing, section 5.6)
- Account entry list is maintained by the user with
account entry transactions (cf. section 5.9) \f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
C_r_e_a_t_e_ _M_a_s_t_e_r_. On creation of master-records standard values
(default values) as specified in SODA-LD, are assigned to
the system fields of the record. The user fields can also be
initiated with standard values - either from SODA-LD or by
the adaption. Furthermore the user fields - if it appears
from the user records - can be initialized with dynamic
standard values, i.e. by copying the field content from a
reference record, which is selected by the creation transac-
tion. The user fields can be modified by reading in of in-
formation from the transaction.
C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_. The transaction creates one or more
list elements, which each connects a common parent master to
a part master. The master records must exist beforehand. To
each keyed in reference to a part master, a list record is
created - if a connection is legal. The field content of the
list record is assigned as by creation of a master record,
though it is impossible to use dynamic standard value.
U_p_d_a_t_e_ _M_a_s_t_e_r_. At the transaction the user fields of the
record can be modified on basis of keyed in information.
U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_. The transaction modifies the user
field in one or more list records which each connects a pa-
rent master with a part master. All list records which are
to be updated must be selected. (By part master key).
D_e_l_e_t_e_ _M_a_s_t_e_r_. By deletion of item or debtor/creditor re-
cords the Skeleton Program checks whether any list records
are attached to the master records in question. In this case
the transaction is rejected.
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
In the adaptions control of the record contents can be made
for all records (user fields). By deletion the record is de-
leted in the Database through the Delete-operation of DUET.
D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_. Deletion of a structure list can be
made in two ways:
- if the transaction only contains line code and parent
master key the Skeleton Program tries deletion of all
list records attached to the master concerned, by the
high level chain.
- if the transaction besides line code and parent mas-
ter key contains one or more part master keys, the
Skeleton Program tries deletion of the list records
which connect parent and part master.
Potential control of record content must be made with the
adaption. Records are deleted through the Delete-operation
of DUET.
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
O_u_t_l_i_n_e_
(tegning)
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
T_a_b_l_e_ _1_
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
T_a_b_l_e_ _2_
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
T_a_b_l_e_ _3_
\f
5_._2_ _ _L_o_g_i_c_a_l_ _F_i_l_e_ _M_a_i_n_t_e_n_a_n_c_e_
N_o_t_e_s_ _t_o_ _T_a_b_l_e_ _1_,_ _2_ _a_n_d_ _3_
D110 - Update master - section 5.2.1
D120 - Create master - .3
D130 - Delete master - .5
D160 - Create struc-
ture list - .4
D200 - Correct struc-
ture list - .2
D300 - Delete struc-
ture list - .6
Rectype Recname File
503 legder account
department deb/cred
501 customer do.
502 supplier do.
601 item item
602 addition do.
907 payment con-
dition userinf
901 vat do.
902 text do.
904 currency do.
905 discount do.
906 discount do.
908 addition table do.
\f
5.2.1 U_p_d_a_t_e_ _M_a_s_t_e_r_
(tegning)
\f
5_._2_._1_ _ _U_p_d_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read master key (general read keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line code
(adp 0)
Comm. vari-
ables : read _set _no (call):
1 - item master
6 - deb/cred master
10 - user master
it _type, deb _cred _type,
user _type (call):
indicates the record type in the logical
file in question.
User : Reading in of a record identifier to the key
variable in question - possibly several i-
dentifiers.
Block refe-
rence : B(adp _block _2,3)
Next adap-
tion point : Adp 2
\f
5_._2_._1_ _ _U_p_d_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Modification of the master information
Reading :
Writing :
Conditions
for activa-
tion : After fetching of the master record
Commm. vari-
ables :
Use : Reading of information codes and information.
Modification of master.
Block refe-
rence : B(skp _adp _block, skp _adp _no) - cf. table
Next adaption
point : Exit.
\f
5_._2_._1_ _ _U_p_d_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _2_
T_a_b_l_e_:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
skp _line _code skp _adp _block skp _adp _no
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
RV adp _block _2 2
RT -"- 6
RK -"- 1
RL -"- 7
RM adp _block _3 2
RC -"- 3
RB -"- 5
RP -"- 1
RR -"- 4
RH -"- 6
RA -"- 7
RTT -"- 10
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
5.2.2 U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._2_ _U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._2_ _U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._2_ _ _U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read the primary master key (general read
keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line-code
(adp 0).
Comm. vari-
ables : read _set _no (call):
3 - item master is primary
7 - deb _cred _master is primary
item _type, deb _cred _type (call):
indicates the record type in the logical
file in question.
Use : Reading in of the record identifier for the
relevant key variable.
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 2.
\f
5_._2_._2_ _ _U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Read and convert type
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After accessing the primary master.
After reading of a terminator ' 10 (NL)
Comm. vari-
ables :
Use : Reading and conversion of the type identifi-
cation (alphanum) for the secondary master.
Block refe-
rence : B(adp _block _2, 4)
Next adap-
tion point : Adp 2, adp 3 or exit
\f
5_._2_._2_ _ _U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3
Designation : Read the secondary master key (general read
keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After reading the correct type identification
for the secondary master
Comm. vari-
ables : read _set _no (call):
4 - secondary master in item logical
file.
8 - secondary master in deb/cred logical
file.
it _part _item _type, dc _part _dc _type (call):
Indicates the record type in the logical
file in question
Use : Reading in of the record identifier (seconda-
ry master) to the key variable in question.
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 4 \f
5_._2_._2_ _ _U_p_d_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 4
Designation : Modification of the list element
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After accessing the list element
Comm. vari-
ables : readterm (answer):
value of the terminator, last read
Use : Reading in of information for modification of
the list element.
Block refe-
rence : B(adp _block _3, skp _adp _no _1)
rec _type _code skp _adp _no _1
.V. 20
.T. 21
.K. 22
.L. 23
The skp _adp _no _1 is assigned in block 4,
D235.
Next adap-
tion point : Adp 2
\f
5.2.3 C_r_e_a_t_e_ _M_a_s_t_e_r_
(tegning)
\f
5_._2_._3_ _ _C_r_e_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read master key (general read keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line code
(adp 0).
Comm. vari-
ables : read _set _no (call):
1 - item master
6 - deb/cred master
10 - user master
it _type, deb _cred _type, user _type (call)
indicates the record type of the logical
file in question
Use : Reading in of the record identifier to the
key variable in question
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 2 or adp 3
\f
5_._2_._3_ _ _C_r_e_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Modification of master information
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After accessing the master record and possi-
bly the reference record.
Comm. vari-
able :
Use : Reading of the information codes and informa-
tion. Possible assignment of the dynamic
standard values (copying from reference re-
cord). Modification of master record from in-
formation read in.
Block refe-
rence : B(skp _adp _block, skp _adp _no _1) - cf. table
Next adap-
tion point : Exit
\f
5_._2_._3_ _ _C_r_e_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _2_
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
skp _line _code skp _dynamic skp _adp _block skp _adp _no
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
OV 0 adp _block _2 2
OT 0 -"- 6
OV1 1 -"- 2
OK 0 -"- 1
OK1 1 -"- 1
OL 0 -"- 7
OL1 1 -"- 7
OM 0 adp _block _3 2
OC 0 -"- 3
OB 0 -"- 5
OP 0 -"- 1
OR 0 -"- 4
OH 0 -"- 6
OA 0 -"- 7
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
5_._2_._3_ _ _C_r_e_a_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3
Designation : Read the reference key (general read keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After the creation of the master. Only if
creation with a dynamic standard value is
wanted.
(skp _dynamic = 1)
Comm. vari-
ables : Compare with adp1.
Use : Reading in of the identifier for the refe-
rence record
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 2
\f
5.2.4 C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read the primary master key (general read
keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line-code (adp0)
Comm. vari-
ables : read _set _no (call):
3 - item master is primary
7 - deb/cred master is primary
it type, deb/cred type (call)
indicates the record type in the logical
file file in question
Use : Reading in of the record identifier to the
key variable in question.
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 2 or exit
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Read and convert type
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After accesing the primary master. After the
reading of a terminator ' 10 (NL)
Comm. vari-
ables :
Use : Reading and conversion of the type identifi-
cation (alphanum) for the secondary master.
Block refe-
rence : B(adp _block _2, 4)
Next adap-
tion point : Adp 3 or exit
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3
Designation : Read the secondary master key (general read
keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After reading of the correct type identifica-
tion for the secondary master
Commm. vari-
ables : read _set _no (call)
4 - secondary master in item logical
file
8 - secondary master in the deb/cred
logical file
it _part _item _type dc _part _dc _type (call):
indicates the record type of the logical
file in question
Use : Reading in the record identifier (secondary
master) to the key variable in question
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 4 \f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 4
Designation : Filling in of the list element
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After creating the list record
Comm. vari-
ables : readterm (answer)
value of the last read terminator
Use : Reading in of the field contents to the
list elements
Block refe-
rence : B(adp _block _3, skp _adp _no)
rec _type _code skp _adp _no _3
.V. 20
.T. 21
.K. 22
.L. 23
skp _adp _no _1 is assigned from block 4,
D235.
Next adap-
tion point : Adp 2 or exit
\f
5_._2_._4_ _ _C_r_e_a_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 5
Designation : Check structure list
Reading :
Writing :
Conditions
for activa-
tion : Before the listrecord is returned to the
database
Comm. vari-
ables : Structure _ok (answer)
0 - not ok
1 - ok
Use : Check whether a wanted list is fulfilling
some specific demands
Block refe-
rence : B(adp _block _3,29)
Next adap-
tion point : Adp 2 or exit
\f
5.2.5 D_e_l_e_t_e_ _M_a_s_t_e_r_
(tegning)
\f
5_._2_._5_ _ _D_e_l_e_t_e_ _M_a_s_t_e_r_
(tegning)
\f
5_._2_._5_ _ _D_e_l_e_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read Master key (general read key)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line code (adp0)
Comm. vari-
ables : read _set _no (call):
1 - item master
6 - deb/cred master
10 - user master
it _type, deb _cred _type, user _type (call):
indicates the record type in the logical
file in question
Use : Reading in of the record identifier to the
key variable in question
Block refe-
rence : B(adp _block _2, 3)
Next adap-
tion point : Adp 2, adp 3 or exit
\f
5_._2_._5_ _ _D_e_l_e_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Control record contents
Reading :
Writing :
Conditions
for activa-
tion : After accessing the master.
After reading the terminator = 10 (NL)
Comm. vari-
ables :
Use : Check whether the user fields of the record
allow deletion.
Creation of print out records.
Block refe-
rence : B(adp _block _3, skp _adp _no _1)
skp _adp _no _1: cf. table 3
Next adap-
tion point : Exit
\f
5_._2_._5_ _ _D_e_l_e_t_e_ _M_a_s_t_e_r_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3
Designation : Convert the user-code to a skp _code
Reading :
Writing :
Conditions
for activa-
tion : After accessing master.
After reading of a terminator ' 10 (NL)
After reading of the user code
Comm. vari-
able : skp _code (answer)
Use :
Block refe-
rence : B(adp _block _3,15)
Next adap-
tion point : Exit
\f
5.2.6 D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
(tegning)
\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read the primary master key (general read
keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line code (adp0)
Comm. vari-
ables : read _set _no (call):
3 - primary master in the item logical
file
7 - primary master in the deb/cred lo-
gical file
it _type, deb _cred _type (call):
indicates the record type in the logical
file in question
Use : Reading in of the record identifier to the
key variable in question
Block refe-
rence : B(adp _block _2,3)
Next adap-
tion : Adp 2 or adp 3
\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : User check of list record
Reading : Not possible
Writing :
Conditions
for activa-
tion : After reading the primary master.
After reading of a terminator = 10 (NL)
After fetching of the list record
Comm. vari-
ables : kill _it
call : 0, 1 (not wanted, wanted)
answer: do.
User : User control (control of the contents of the
list element) in connection with the SKP
scanning of a whole chain from the primary
master
Block refe-
rence : B(adp _block _3,28)
Next adap-
tion point : Adp 2 or exit
\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3
Designation : Read and convert type
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After accessing the primary master
After reading a terminator ' 10 (NL)
Comm vari-
ables :
Use : Reading and conversion of the type identifi-
cation (alphanum) for a part master.
Block refe-
rence : B(adp _block _2,4)
Next adap-
tion point : Adp 4 or exit\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 4
Designation : Read the secondary master key (general read
keys)
Reading : From input buffer
Writing :
Conditions
for activa-
tion : If the type _read = 1.
If the read type is legal (for further infor-
mation, compare with 5.2.2 - update structure
list, adp 3)
Comm. vari-
ables : read _set _no (call):
skp _set _3 (cf. table 3)
it _type, deb _cred _type (call): cf. table 3
Use : Reading in of the identifier for the seconda-
ry master
Block refe-
rence : B(adp _block _2,3)
Next adap-
tion point : Adp 3 or adp 5
\f
5_._2_._6_ _ _D_e_l_e_t_e_ _S_t_r_u_c_t_u_r_e_ _L_i_s_t_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 5
Designation : Check the record contents
Reading :
Writing :
Conditions
for activa-
tion : After fetching of a list element with the
correct keys
Comm. vari-
ables : kill _it
call : 0 (not wanted)
answer: 0, 1
Use : Check that the user fields of the record
allow deletion
Block refe-
rence : B(adp _block _3, skp _adp _no _1)
rec _type _code, skp _adp _no
.V. 24
.T. 26
.K. 25
.L. 27
Next adap-
tion point : Adp 5 or exit
\f
5.3 A_d_m_i_n_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
T_a_b_l_e_ _o_f_ _C_o_n_t_e_n_t_s_ P_a_g_e_
Introduction 117
Transaction Outline 118
Table 1 119
Flow Diagram 121
Adaption Point Description 126
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
I_n_t_r_o_d_u_c_t_i_o_n_
Administrative transactions are used for the creation and
maintenance of the TELEDATA installation>s administrative
records in connection with the inclusion of new users in the
system, removal of users from the system and user specific
changes at the system level. The administrative transactions
can be processed only from the system administrative termi-
nal(s) (the admin _adm _terminal ' 0 in the term. admin.-re-
cord) and not from the user terminals (admin _adm _terminal =
0 in the term. admin.-record).
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
T_r_a_n_s_a_c_t_i_o_n_ _O_u_t_l_i_n_e_ _(_s_k_p_ _l_i_n_e_ _c_o_d_e_s_)_
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Record type
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Name Admin type Create Update Delete Inquiries
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
User 801 .ZBO. .ZBR. .ZBN. .ZB?.
Term _admin 802 .ZTO. .ZTR. .ZTN. .ZT?.
Printer _admin 805 .ZPO. .ZPR. .ZPN. .ZP?.
Inp _form _type 803 .ZIO. .ZIR. .ZIN. .ZI?.
Pool _admin 806 .ZOO. .ZOR. .ZON. .ZO?.
Outp _form _type 804 .ZUO. .ZUR. .ZUN. .ZU?.
T_r_a_n_s_a_c_t_i_o_n_ _O_u_t_l_i_n_e_ _f_o_r_ _S_p_e_c_i_a_l_ _T_r_a_n_s_a_c_t_i_o_n_s_ _(_s_k_p_ _l_i_n_e_ _c_o_d_e_s_)_
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Transactions Concerning Update Inquiry
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
certain database records .ZM1. .ZM1.
hotnews variable .ZM2. -
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
T_a_b_l_e_ _1_
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D5
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
skp _line _ DUET skp _ admin _ skp _adp _ skp _adp _ skp _adp _ elected
code instruc- rec _ type no _1 no _2 no _3 part of
tion type the flow
diagram
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
ZBO D10 801 801 - 1 2 ZO
ZTO D11 802 802 - 3 4 ZO
ZPO D12 805 805 - 5 6 ZPO
ZIO D13 803 803 - 7 8 ZO
ZOO D14 806 806 - 9 10 ZO
ZUO D15 804 804 - 11 12 ZO
ZBR D20 - 801 20 - - ZR
ZTR D21 - 802 15 - - ZR
ZPR D22 - 805 5 19 - ZPR
ZIR D23 - 803 17 - - ZR
ZOR D24 - 806 16 - - ZR
ZUR D25 - 804 18 - - ZR
ZBN D30 - 801 25 - - ZN
ZTN D31 - 802 26 - - ZN
ZPN D32 - 805 5 27 - ZPN
ZIN D33 - 803 28 - - ZN
ZON D34 - 806 29 - - ZN
ZUN D35 - 804 30 - - ZN
ZM1 D160 - 801 - - - ZM1
ZM2 D180 - - - - - ZM2
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ \f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
T_a_b_l_e_ _1_ _(_c_o_n_t_n_d_)_
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D5
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
skp _ DUET skp _ admin _ skp _ skp _ skp _ elected part of the
line _ instruc- rec _ type adp _ adp _ adp _ flow diagram - see
code tion type no _1 no _2 no _3 next page
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
ZB? D40 - 801 40 - - Z?
ZT? D41 - 802 41 - - Z?
ZP? D42 - 805 5 42 - ZP?
ZI? D43 - 803 43 - - Z?
ZO? D45 - 806 44 - - Z?
ZU D44 - 804 45 - - Z?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
(tegning)
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
(tegning)
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
(tegning)
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
(tegning)
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
(tegning)
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 1
Designation : Read admin. keys
Reading : From input buffer
Writing :
Conditions
for activa-
tion : Depends on the skp _line _code - cf. diagram
Comm. vari-
ables : read _set _no (call)
11-admin.record
skp _record _type, admin _adm _type (call):
cf. Table 1
Use : Reading in of the record identifier to the
key variable in question
Block refe-
rence : B(adp _block _2,3)
Next adap-
tion point : Depends on the skp _line _code - cf. diagram
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_o_n_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 2
Designation : Read the group information
Reading : From input buffer
Writing :
Conditions
for activa-
tion :
Comm. vari-
ables :
Use : Reading in of variable values for dimensio-
ning of the repeating groups.
Block refe-
rence : B(21, skp _adp _no _2) cf. table 1
Next adap-
tion point : Adp 3
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 3 - 6
Designation : Read the information
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After fetching/creating the admin record
Comm. vari-
ables :
Use : Reading in of information
Creation and updating:
Modifications of the record contents
Deletion
Creteria for deletion.
Perhaps printing of answer
Block refe-
rence : B(21, skp _adp _no)
Next adap-
tion point : Depends on the skp _line _code - cf. diagram
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 7
Designation : Read user no and lookup user record
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After interpretation of the line code (adp0)
Comm. vari-
ables : read _set _no (call)
11 - admin record
Use : Reading in of the user no and a lookup of the
user record
Block refe-
rence : B(adp _block _2,3)
Next adap-
tion point : Depends on the skp _line _code
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 8
Designation : Update printer admin record
Reading :
Writing :
Conditions
for activa-
tion : The user admin record and the printer admin
record have been fetched
Comm. vari-
ables :
Use : Check and update the printer admin record
Block refe-
rence : B(21,48)
Next adap-
tion point : Exit
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 9
Designation : Updating of the printer table
Reading :
Writing :
Conditions
for activa-
tion : The user admin record has been fetched
Comm. vari-
ables :
Use :
Block refe-
rence : B(21,47)
Next adap-
tion point : Adp 11
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 10
Designation : Check the printer table
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After the user admin record has been fetched
Comm. vari-
ables : printer _index (call)
= the printer identification
Use : Check whether the printer no exists in the
printer table
Block refe-
rence : B(21,46)
Next adap-
tion point : Depends on the skp _line _code
\f
5_._3_ _ _A_d_m_i_n_i_s_t_r_a_t_i_v_e_ _T_r_a_n_s_a_c_t_i_o_n_s_
A_d_a_p_t_i_o_n_ _P_o_i_n_t_ _D_e_s_c_r_i_p_t_i_o_n_
Number : 11 - 12
Designation : Read information
Reading : From input buffer
Writing :
Conditions
for activa-
tion : After the printer admin record has been crea-
ted or fetched
Comm. vari-
ables :
Use : Reading of information concerning the printer
admin record
Block refe-
rence : B(21, skp _adp _no)
Next adap-
tion point : Exit
\f
\f
«eof»