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