top - download
⟦8aa811c69⟧ Wang Wps File
Length: 80101 (0x138e5)
Types: Wang Wps File
Notes: CPS/SDS/039
Names: »1541A «
Derivation
└─⟦83a6a53dc⟧ Bits:30006111 8" Wang WCS floppy, CR 0176A
└─ ⟦this⟧ »1541A «
WangText
…00……00……00……00……00…&…0a……00……00…&…0b…&…05…$…0f…#…09…# "…0f…"…07…!…01… …0b… …06……1f……01……1f……05……1e……0a……1e……0f……1e……02……1d……08……1d……09……1d……0c……1d……0d……1d…
…1d……07……1c……0c……1c……0d……1c… …1b……0b……1b……02……1b… …1b……05……1b……06……1a……0c……1a……0d……1a……01……1a……07……19……0d……19……01……19……05……86…1 …02… …02… …02…
…02…CPS/SDS/039
…02…841101…02……02…
USER VDU
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .......................................
1 001
1.1 PURPOSE AND SCOPE .........................
1 001
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
1 002
1.2.1 Applicable Documents ..................
1 002
1.2.2 Reference Documents ...................
1 002
1.3 TERMS AND ABBREVIATIONS ...................
1 003
1.3.1 Terms .................................
1 003
1.3.2 Abbreviations .........................
1 003
2 SUMMARY OF REQUIREMENTS .......................
2 001
2.1 PACKAGE DESCRIPTION .......................
2 001
2.2 PACKAGE FUNCTIONS .........................
2 007
2.2.1 Main Functions ........................
2 007
2.2.1.1 Queue Status Display ..............
2 008
2.2.1.2 Information Concerning the Trans-
action in Progress ................
2 011
2.2.1.3 Display of Queued Information .....
2 011
2.2.1.3.1 The Receive Queue .............
2 011
2.2.1.3.2 The Response Queue ............
2 013
2.2.1.3.3 The Release Queue .............
2 013
2.2.1.4 Message/Comment Preparation .......
2 014
2.2.1.5 Treatment of User Request .........
2 018
2.2.1.6 Maintenance of Message Status Files
2 018
2.2.1.6.1 Outgoing Message Status .......
2 018
2.2.1.6.2 Delivery Status ...............
2 018
2.2.1.6.3 Release Status ................
2 019
2.2.2 Functional Responsibilities ...........
2 019
2.2.2.1 Initialization, Close Down and
Restart ...........................
2 019
2.2.2.1.1 Initialization ................
2 019
2.2.2.1.2 Close Down ....................
2 019
2.2.2.1.3 Restart .......................
2 020
2.2.2.2 Checkpointing and Recovery ........
2 020
2.2.2.3 Error Detecting and Error Handling
2 020
2.2.2.4 Integrity of Operation ............
2 021
2.2.2.5 Data Collection ...................
2 021
2.2.2.5.1 Log Collection ................
2 021
2.2.2.5.2 Statistics Information ........
2 021
2.2.2.5.3 Reports .......................
2 021
2.2.2.6 Security ..........................
2 023
2.3 CHARACTERISTICS ...........................
2 025
2.3.1 Timing ................................
2 025
2.3.2 Throughput ............................
2 026
2.3.3 Flexibility ...........................
2 028
2.3.4 Accuracy ..............................
2 028
3 ENVIRONMENT ...................................
3 001
3.1 EQUIPMENT .................................
3 001
3.2 SOFTWARE ..................................
3 001
3.2.1 System Software .......................
3 001
3.2.2 Development Support Software ..........
3 001
3.3 INTERFACES ................................
3 001
3.3.1 External Interfaces ...................
3 001
3.3.2 Package Interfaces ....................
3 002
3.3.2.1 Traffic Handling (THP) I/F ........
3 002
3.3.2.2 Distribution (MDP) I/F ............
3 002
3.3.2.3 Storage and Retrieval (SAR) I/F ...
3 002
3.3.2.4 Log and Accountability (LOG) I/F ..
3 003
3.3.2.5 Statistics (STP) I/F ..............
3 003
3.3.2.6 SSC Software I/F ..................
3 003
3.3.2.7 Table Management Package (TMP) I/F
3 004
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES ....
3 005
4 PACKAGE DESIGN ................................
4 001
4.1 PACKAGE OVERVIEW ..........................
4 001
4.1.1 Functional Specification ..............
4 003
4.1.1.1 TEMCO Control Functions ...........
4 006
4.1.1.2 Queue Status Maintenance ..........
4 008
4.1.1.3 User Transaction Control ..........
4 011
4.1.1.3.1 Transaction Accounting ........
4 011
4.1.1.3.2 Transaction Interruption ......
4 014
4.1.1.3.3 Transaction Execution..........
4 016
4.1.1.3.3.1 Command Interpretation.....
4 016
4.1.1.3.3.2 Command Execution .........
4 018
4.1.1.3.3.3 Start/Stop Transaction
Execution .................
4 020
4.1.1.3.3.4 Preparation of Messages/
Comments ..................
4 022
4.1.1.3.3.5 Presentation of Queued Infor-
mation ....................
4 024
4.1.1.3.3.6 Requests to CAMPS System ..
4 026
4.1.1.3.3.7 Dialogue Formatting .......
4 028
4.1.1.3.3.8 Format Validation .........
4 030
4.1.1.4 User Message Access Monitoring ....
4 032
4.1.1.4.1 Preparation Database Access
Control .......................
4 033
4.1.1.4.2 Message/Comment Status
Maintenance ...................
4 036
4.1.2 Software Specification ................
4 040
4.1.2.1 VUS Process .......................
4 040
4.1.2.1.1 VUS Coroutines ................
4 043
4.1.2.1.1.1 VDU Control Coroutine .....
4 043
4.1.2.1.1.2 User Function Control
Coroutine .................
4 043
4.1.2.1.1.3 VDU Dialogue Coroutine ....
4 044
4.1.2.1.1.4 Retrieve Coroutine ........
4 044
4.1.2.1.2 User Procedures USPR ..........
4 045
4.1.2.2 UMAM Process ......................
4 046
4.1.2.3 Software Structure ................
4 046
4.1.2.3.1 VUS Initialization
Software Structure ............
4 048
4.1.2.3.2 VCO Coroutine Software
Structure .....................
4 048
4.1.2.3.3 UFCO Coroutine Software
Structure .....................
4 052
4.1.2.3.4 VDIA Coroutine Software
Structure .....................
4 054
4.1.2.3.5 RETR Coroutine Software
Structure .....................
4 056
4.1.2.3.6 UMAM Software Structure .......
4 058
4.1.3 Data Flow and Control Logic ...........
4 060
4.1.3.1 Process Data Flow and Process
Synchronization ...................
4 060
4.1.3.2 VUS Internal Data Flow and
Coroutine Synchronization .........
4 062
4.1.3.3 UMAM Internal Data Flow ...........
4 066
4.1.3.4 Transaction Example ...............
4 067
4.1.4 Common Package Data ...................
4 071
4.1.5 Common Package Procedures .............
4 074
4.1.5.1 TEP QUEUE ERROR ...................
4 074
4.1.5.2 TEP INTERNAL ERROR ................
4 075
4.1.5.3 TEP DISMANTLE .....................
4 077
4.1.5.4 SET HEADER TXT ....................
4 080
4.1.5.5 SET HEADER CLASSIFICATION .........
4 082
4.1.5.6 VUP CONVERTION ....................
4 084
4.1.5.7 Semaphore Operation Management ....
4 086
4.1.6 Global Data ...........................
4 088
4.1.7 Interfaces ............................
4 088
4.1.7.1 External Interfaces ...............
4 088
4.1.7.2 Package Interfaces ................
4 088
4.1.7.2.1 Traffic Handling (THP) I/F ....
4 088
4.1.7.2.2 Distribution (MDP) I/F ........
4 088
4.1.7.2.3 Storage and Retrieval (SAR) I/F
4 089
4.1.7.2.4 LOG and Accountability (LOG)
I/F ...........................
4 089
4.1.7.2.5 Statistics (STP) I/F ..........
4 089
4.1.7.2.6 SSC Software I/F ..............
4 089
4.1.7.2.7 Table Management Package I/F ..
4 089
4.1.7.3 Sub-Package Interfaces ............
4 090
4.1.7.3.1 Process Interfaces ............
4 090
4.1.7.3.2 Coroutine Interfaces ..........
4 090
4.2 SUBPACKAGE SPECIFICATIONS .................
4 092
4.2.1 VDU Control Subpackage ................
4 092
4.2.1.1 Functional Specification ..........
4 092
4.2.1.1.1 Initialization ................
4 094
4.2.1.1.2 TEMCO Command Processing ......
4 094
4.2.1.1.3 Flash Item Control ............
4 095
4.2.1.1.4 Timer Event Processing ........
4 095
4.2.1.1.5 VDU Header Control ............
4 095
4.2.1.1.6 UFCO Control ..................
4 095
4.2.1.1.7 Error Reporting ...............
4 096
4.2.1.2 Software Structure ................
4 096
4.2.1.3 Dataflow and Control Logic
within VCO .......................
4 098
4.2.1.4 VCO Module Specification ..........
4 103
4.2.1.4.1 VCO CONTROL ...................
4 103
4.2.1.4.2 VCO VDU Specification .........
4 104
4.2.1.4.3 VCO CMDS Specification ........
4 109
4.2.1.4.4 VCO FLASH Specification .......
4 111
4.2.1.5 Subpackage Interfaces .............
4 113
4.2.1.5.1 VCO UFCO Interfaces ...........
4 113
4.2.1.5.2 UFCO VCO Interfaces ...........
4 113
4.2.2 User Function Control Subpackage ......
4 114
4.2.2.1 Functional Specification ..........
4 114
4.2.2.1.1 System Control ................
4 120
4.2.2.1.2 Transaction Accounting ........
4 121
4.2.2.1.3 Transaction Creation ..........
4 121
4.2.2.1.4 Format Sequence Function ......
4 122
4.2.2.1.4.1 Start Execution ...........
4 123
4.2.2.1.4.2 Stop Execution ............
4 124
4.2.2.1.4.3 Queue Request .............
4 125
4.2.2.1.4.4 Request to CAMPS System ...
4 125
4.2.2.1.5 Error Handling ................
4 127
4.2.2.2 Software Structure ................
4 127
4.2.2.3 Data Flow and Control Logic Within
UFCO ..............................
4 130
4.2.2.3.1 Data Flow .....................
4 130
4.2.2.3.2 Control Logic .................
4 130
4.2.2.4 Module Specification ..............
4 158
4.2.2.4.1 UFCO MAIN .....................
4 158
4.2.2.4.2 VUS ANSWER QUEUE PROCESSING ...
4 169
4.2.2.4.3 APPEND INVESTIGATION ..........
4 173
4.2.2.4.4 VUS F/C KEY PROCESSING ........
4 178
4.2.2.4.5 VCO CMD PROCESSING ............
4 185
4.2.2.4.6 VDIA CC PROCESSING ............
4 189
4.2.2.4.7 RETR OP PROCESSING ............
4 192
4.2.2.4.8 INSERT/DELETE LINES ...........
4 195
4.2.2.4.9 VUS CMD PENDING ...............
4 198
4.2.2.4.10 VUS SEQUENCE ..................
4 203
4.2.2.4.11 STP Reporting .................
4 206
4.2.2.4.12 Log Reporting .................
4 208
4.2.2.4.13 Status Reporting ..............
4 210
4.2.2.4.14 Execute Function ..............
4 212
4.2.2.4.15 TEP Get First CIF .............
4 215
4.2.2.4.16 TEP Get Next CIF ..............
4 218
4.2.2.4.17 TEP Receive First .............
4 221
4.2.2.4.18 TEP Receive Next ..............
4 224
4.2.2.4.19 Calculate Format ..............
4 228
4.2.2.5 Common Subpackage Data ............
4 231
4.2.2.6 Common Subpackage Procedures ......
4 231
4.2.2.6.1 Lookup Parameters .............
4 231
4.2.2.6.2 SET CURSOR ....................
4 236
4.2.2.6.3 DISPLAY VDU FIELD .............
4 236
4.2.2.6.4 DISPLAY ERROR MSG .............
4 238
4.2.2.6.5 TEP Create CIF ................
4 239
4.2.2.6.6 TEP Create New CIF ............
4 240
4.2.2.6.7 TEP New View ..................
4 241
4.2.2.6.8 TEP TRSERNO ...................
4 242
4.2.2.6.9 Calculate Menu ................
4 243
4.2.2.6.10 TEP Return View ..............
4 244
4.2.2.6.11 TEP Save View ................
4 245
4.2.2.6.12 TEP Read Buffer ..............
4 246
4.2.2.6.13 TEP Write Buffer .............
4 247
4.2.2.6.14 TEP Reserve Buffer ...........
4 248
4.2.2.6.15 Display Header Information ...
4 249
4.2.2.6.16 Update VDU Header ............
4 250
4.2.2.6.17 Send to MDP ..................
4 251
4.2.2.6.18 Send For Release .............
4 252
4.2.2.6.19 Send Release Notification ....
4 253
4.2.2.6.20 Send to THP ..................
4 254
4.2.2.6.21 Send Request to UMAM .........
4 255
4.2.2.6.22 Send Request to SSC ..........
4 256
4.2.2.6.23 Send Request to SAR ..........
4 257
4.2.2.6.24 Send to ASS Printer ..........
4 258
4.2.2.6.25 Send SC REL THP ..............
4 259
4.2.2.6.26 CTSA Logging .................
4 260
4.2.2.6.27 Signal Await VDIA ............
4 261
4.2.2.6.28 Enable FC Keys ...............
4 262
4.2.2.6.29 Set Field Attributes .........
4 263
4.2.2.6.30 Move Format ..................
4 264
4.2.2.6.31 TEP Change Profile ...........
4 265
4.2.2.6.32 Calculate Retrieval Format ...
4 266
4.2.2.6.33 TEP CUR Item .................
4 267
4.2.2.6.34 Release Stamp ................
4 268
4.2.2.6.35 Defer Stamp ..................
4 269
4.2.2.6.36 Release SCV Stamp ............
4 270
4.2.2.6.37 Send SCV to THP ..............
4 271
4.2.2.6.38 Send VDUP to UMAM ............
4 272
4.2.2.6.39 Request FC Key Input .........
4 273
4.2.2.6.40 VDIA Copy ....................
4 274
4.2.2.6.41 VDIA Append ..................
4 275
4.2.2.6.42 TEP Create New VDUP CIF ......
4 276
4.2.2.6.43 Enable Format Keys ...........
4 277
4.2.2.6.44 SAR Reporting ................
4 278
4.2.2.6.45 Expand PLA ...................
4 279
4.2.2.6.46 Search PLA at TMP ............
4 280
4.2.2.6.47 Validate PLA REF .............
4 281
4.2.2.7 Subpackage Interfaces .............
4 282
4.2.2.7.1 UFCO VDIA Interfaces ..........
4 282
4.2.2.7.2 VDIA UFCO Interfaces ..........
4 282
4.2.2.7.3 VCO UFCO Interfaces ...........
4 282
4.2.2.7.4 UFCO VCO Interfaces ...........
4 283
4.2.2.7.5 RETR UFCO Interfaces ..........
4 283
4.2.3 VDU Dialogue (VDIA) ....................
4 284
4.2.3.1 Functional Specification ...........
4 284
4.2.3.1.1 Control of Main FLow ...........
4 284
4.2.3.1.2 Interpretation of Format Control
Programs .......................
4 284
4.2.3.1.3 Input From/Output to VDU .......
4 284
4.2.3.1.4 Read From/Write to CIF .........
4 285
4.2.3.1.5 Read From/Write to Memory ......
4 285
4.2.3.1.6 Read/Write From Sequences ......
4 285
4.2.3.1.7 Validation and Conversion ......
4 285
4.2.3.1.8 Error Handling .................
4 285
4.2.3.1.9 Handling of Dynamic Memory .....
4 285
4.2.3.2 Software Structure .................
4 286
4.2.3.2.1 Main Components of VDIA ........
4 286
4.2.3.2.2 VDIA Format and Associated
Control Data ...................
4 289
4.2.3.2.3 Format Model and VDU Field Type
4 289
4.2.3.2.4 Format Control Programme .......
4 290
4.2.3.2.5 VDIA Date Layout ...............
4 291
4.2.3.3 Data Flow and Control Structure ....
4 297
4.2.3.3.1 Subpackage Interface ...........
4 300
4.2.3.3.1.1 UFCO VDIA UFCO Interface ...
4 300
4.2.3.3.1.2 VDIA USPR VDIA Interface ...
4 300
4.2.3.4 Module Specification ...............
4 307
4.2.3.4.1 VDIA MAIN ......................
4 307
4.2.3.4.1.1 VDIA Main Loop Specification
4 307
4.2.3.4.1.2 Stack Error Specification ..
4 312
4.2.3.4.1.3 Long Exit Specification ....
4 313
4.2.3.4.1.4 Wait VDU I/O Specification .
4 313
4.2.3.4.2 Format Control Program
Interpreter ....................
4 315
4.2.3.4.2.1 Format Control Program
Interpreter Main ...........
4 315
4.2.3.4.2.2 Format Control Program
Interpreter Input ..........
4 320
4.2.3.4.2.3 Format Control Program
Interpreter Disp ...........
4 325
4.2.3.4.2.4 Format Control Program
Interpreter Contr ..........
4 328
4.2.3.4.2.5 Format Control Program
Interpreter Seq ............
4 330
4.2.3.4.2.6 Format Control Program
Interpreter Misc ...........
4 332
4.2.3.4.2.7 Format Control Program
Interpreter Aux ............
4 334
4.2.3.4.3 VDU Access Method ..............
4 336
4.2.3.4.3.1 VDU Access Method Main .....
4 337
4.2.3.4.3.2 VDU Access Method Model ....
4 342
4.2.3.4.3.3 VDU Access Method IO .......
4 350
4.2.3.4.3.4 VDU Access Method Errl .....
4 359
4.2.3.4.4 CIF Access Method ..............
4 363
4.2.3.4.4.1 CIF Access Method
Specification ..............
4 363
4.2.3.4.5 Memory Access Method ...........
4 373
4.2.3.4.5.1 Memory Access Method
Specification ..............
4 373
4.2.3.4.6 Field Sequence Access Method ...
4 378
4.2.3.4.6.1 Field Sequence Access
Method Specification .....
4 379
4.2.3.4.7 Memory Management ..............
4 383
4.2.3.4.7.1 Memory Management
Specification ............
4 386
4.2.3.4.8 Common Modules .................
4 396
4.2.3.4.8.1 COPY .......................
4 396
4.2.3.4.8.2 GET ̲MHI ....................
4 400
4.2.3.4.8.3 VDIA COM ...................
4 400
4.2.4 Retrieve Subpackage .....................
4 402
4.2.4.1 Functional Specification ............
4 402
4.2.4.2 Software Structure ..................
4 404
4.2.4.3 Data Flow and Control Logic Within
RETR ................................
4 404
4.2.4.3.1 Data Flow .......................
4 404
4.2.4.3.2 Control Logic ...................
4 404
4.2.4.4 Module Specification ................
4 411
4.2.4.4.1 RETR MAIN Module ................
4 411
4.2.4.5 Common Subpackage Data ..............
4 417
4.2.4.6 Common Subpackage Procedures ........
4 417
4.2.4.7 Subpackage Interfaces ...............
4 417
4.2.4.7.1 RETR UMAM Interfaces ............
4 417
4.2.4.7.2 RETR UFCO Interfaces ............
4 417
4.2.5 User Message Access Monitoring
Subpackage ..............................
4 418
4.2.5.1 Functional Specification ............
4 418
4.2.5.1.1 Collect Status ..................
4 420
4.2.5.1.2 Generate Status .................
4 421
4.2.5.1.3 Message Access Control ..........
4 423
4.2.5.1.4 Supervisory Control Functions ..
4 424
4.2.5.1.5 Error Reporting ................
4 424
4.2.5.2 Software Structure ..................
4 425
4.2.5.3 Data Flow and Control Logic Within
UMAM ................................
4 427
4.2.5.3.1 Data Flow .......................
4 427
4.2.5.3.2 Control Logic ...................
4 427
4.2.5.3.3 Description of How UMAM Works on
Files and Buffer ................
4 437
4.2.5.4 Module Specification ................
4 460
4.2.5.4.1 EXECUTE START FUNCTION Module ...
4 460
4.2.5.4.2 UMAM MAIN Module ................
4 468
4.2.5.4.3 REQUEST QUEUE ACTION Module......
4 475
4.2.5.4.4 PREP QUEUE ACTION Module ........
4 486
4.2.5.4.5 VDU-PAGE STORAGE Module .........
4 494
4.2.5.4.6 STATUS REQUEST Module ...........
4 498
4.2.5.4.7 DELIVERY STATUS Module...........
4 503
4.2.5.4.8 APPEND QUEUE ACTION Module.......
4 507
4.2.5.4.9 PERIODIC STATUS Module .........
4 511
4.2.5.4.10 GEN REL STA Module ............
4 514
4.2.5.4.11 GEN DEL STA Module ............
4 520
4.2.5.4.12 GEN OUT STA Module ............
4 524
4.2.5.4.13 GEN SVC STA Module ............
4 532
4.2.5.4.14 DELETE REQUEST Module .........
4 539
4.2.5.4.15 INCLUDE IN INTA Module ........
4 545
4.2.5.4.16 SORT/STORE INTA Module ........
4 549
4.2.5.4.17 INCLUDE IN PREP Module ........
4 556
4.2.5.4.18 SORT RECORDS Module ...........
4 560
4.2.5.5 Common Subpackage Data ..............
4 574
4.2.5.6 Common Subpackage Procedures ........
4 585
4.2.5.6.1 UMAM QEL DISMANTLE ..............
4 585
4.2.5.6.2 VDU PAGE LOOKUP .................
4 589
4.2.5.6.3 SEND ITEM .......................
4 592
4.2.5.6.4 SEND RESPONSE ...................
4 595
4.2.5.6.5 CREATE/OPEN STATUS CIF ..........
4 599
4.2.5.6.6 CLOSE/SEND STATUS CIF ...........
4 602
4.2.5.6.7 CONVERT OUTG TO INTA.............
4 606
4.2.5.6.8 STORE PREP AREA .................
4 609
4.2.5.6.9 INPUT COMPLETE INTA .............
4 612
4.2.5.6.10 STORE INT AREA .................
4 615
4.2.5.6.11 UQ ERROR .......................
4 618
4.2.5.6.12 INPUT PREP AREA ................
4 621
4.2.5.6.13 LOOKUP STATUS CIF ..............
4 624
4.2.5.6.14 STORE SORTED DATA ..............
4 627
4.2.5.6.15 CONVERT STORE LTD ..............
4 630
4.2.5.6.16 INPUT FILE DIRECTORY ...........
4 633
4.2.5.6.17 Intentionally Left Blank .......
4 636
4.2.5.6.18 STORE FILE DIRECTORY ...........
4 636
4.2.5.6.19 INT TO ASCII ...................
4 639
4.2.5.6.20 SEND CIF TO MDCO ...............
4 641
4.2.5.6.21 LOOKUP STATUS REC ..............
4 644
4.2.5.6.22 INPUT INT AREA .................
4 647
4.2.5.6.23 INPUT EXPAND AREA ..............
4 650
4.2.5.6.24 STORE EXPAND AREA ..............
4 653
4.2.5.6.25 THRESHOLD WARNING ..............
4 656
4.2.5.6.26 LOOKUP EMPTY PREP REC ..........
4 659
4.2.5.6.27 EXCLUDE FROM PREP ..............
4 662
4.2.5.6.28 UNLOCK PASSIVE CIFS ............
4 665
4.2.5.6.29 SEND REPORT ....................
4 668
4.2.5.6.30 UINT ERROR .....................
4 671
4.2.5.6.31 PRE STATUS .....................
4 673
4.2.5.6.32 READ STATUS ....................
4 676
4.2.5.6.33 GET TIME .......................
4 679
4.2.5.6.34 UMAM REQUEST TIMEOPUT ..........
4 681
4.2.5.6.35 TO DTG TIME ....................
4 683
4.2.5.6.36 MOVE WORDS .....................
4 685
4.2.5.6.37 CHANGE STATUS FILES ............
4 687
4.2.5.6.38 SEARCH RECORD ..................
4 689
4.2.5.6.39 UMAM LOCK CIF ..................
4 691
4.2.5.6.40 UPDATE DISPLAY TABLE ...........
4 692
4.2.5.6.41 READ ADM FIELD .................
4 694
4.2.5.6.42 RESET FILE .....................
4 697
4.2.5.6.43 CLEAR COUNTERS .................
4 699
4.2.5.6.44 CLEAR BIG BUF ..................
4 700
4.2.5.6.45 UPDATE BIT MAP .................
4 701
4.2.5.6.46 RESET COLLECT AREA .............
4 703
4.2.5.7 Subpackage Interfaces ...............
4 705
4.2.6 VUS Initialization Subpackage ..........
4 706
4.2.6.1 Functional Specification ...........
4 706
4.2.6.1.1 VUS Initialization .............
4 708
4.2.6.1.2 USER VDU Software
Initialization..................
4 708
4.2.6.2 Software Structure .................
4 708
4.2.6.2.1 Process Start ..................
4 708
4.2.6.2.2 USER Subprocess Init ...........
4 709
4.2.6.3 Dataflow and Control Logic within
VUS Initialization Subpackage ......
4 711
4.2.6.4 VUS Initialization Module
Specifications .....................
4 711
4.2.6.4.1 PROCESS START Specification ....
4 711
4.2.6.4.2 USER SUBPROCESS INIT Speci-
fication .......................
4 713
4.2.6.5 Common Subpackage Data .............
4 715
4.2.6.6 Common Subpackage Procedures .......
4 715
4.2.6.7 Subpackage Interfaces ..............
4 715
4.2.7 User Procedure Subpackage ..............
4 715
4.2.7.1 Functional Specification ...........
4 715
4.2.7.1.1 Display Procedures ...............
4 716
4.2.7.1.2 Syntax Procedures ................
4 716
4.2.7.1.3 Semantic procedures ..............
4 716
4.2.7.2 Software Structure .................
4 716
4.2.7.3 Data Flow ..........................
4 716
4.2.7.4 USPR Module Specification ..........
4 717
4.2.7.4.1 VUP SYNTAX Specification .........
4 717
4.2.7.4.2 SEMAN VAL Specification ..........
4 734
4.2.7.4.3 DISPLAY FIELD Specification ......
4 736
4.3 MEMORY LAYOUT ...............................
4 730
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
a) The VDU User Package Specification for the CAMPS
Project/4040 is written to fulfil the following
objectives:
1) To provide a detailed definition of the VDU
user package function and software architecture.
2) To provide user operational and development
personnels with details of the ongoing analysis.
3) To define in details the interfaces with other
packages and to describe their facilities.
b) The VDU user package specification defines the
functions and software architecture of the package
to a level sufficient for a programmer to start
coding with a minimum of design effort of the architecture.
The VDU user package constitutes one of the building
stones of the TEP package.
All VDU user package internal data and interfaces
are defined within this document in detail. For
a detailed data description of data external to
the VDU user package and interfaces to other packages
refer the data definition document and the relevant
interface documents.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CAMPS System Requirements
CPS/210/SYS/0001 Issue 3.6
User Procedures and Associated Formats
CPS/230/ICD/0001 Issue 3.5
CAMPS System Design Specification
CPS/SDS/001 Issue 1.2
Database Design Document
CPS/DBD/001
CAMPS Software Interface Control Document
CPS/ICD/009
1.2.2 R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
DOCUMENT NAME DOCUMENT NUMBER
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
CAMPS System Functions CPS/SDS/024
Message Management CPS/SDS/025
Table Managment CPS/SDS/026
Input/Output Control CPS/SDS/028
System Status and Control CPS/SDS/029
Storage and Retrieval CPS/SDS/030
Statistics CPS/SDS/031
Logging CPS/SDS/032
Traffic Handling CPS/SDS/033
Message Distribution CPS/SDS/034
Supervisor VDU CPS/SDS/035
Supervisor Printer CPS/SDS/036
MDCO VDU CPS/SDS/037
MSO VDU CPS/SDS/038
OCR CPS/SDS/040
Printer CPS/SDS/041
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
PDB Preparation Data Base
RETR Retrieve Coroutine
UFCO User Function Control Coroutine
UMAM User Message Access Monitoring
VCO VDU Control Coroutine
VDIA VDU Dialogue Coroutine
VUP VDU User Package
VUS VDU User Sub-Process
FQT Flash Queue Timeout
HDB Historical Data Base
PRIS User Printer Sub Package
TEMCO Terminal Monitor Control
MDC Message Distribution Control
MSO Message Service Operator
SUP Supervisor Package
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The V̲DU U̲ser P̲ackage (VUP) constitutes the only means
by which CAMPS Personnel may gain access to the services
of the CAMPS user function.
a) The CAMPS user function is made up of three subfunctions,
Preparation, Reception, and Release. A VDU or user
may have access rights to one or more of the subfunction
services as specified by the Supervisor. In figure
2.1-1 overleaf the services of the CAMPS user function
and the sub-functions are depicted.
b) The VDU user package (VUP) implements all the services
of the CAMPS user function, which implies the following
responsibilities:
1) Interface the user to the CAMPS system, i.e.
Man/Machine I/F Support and monitoring
2) Direct all user requests/commands to the relevant
package within CAMPS
3) Present to the user information sent to his
VDU
4) Supervise/allow the user preparing messages
and comments.
c) The packages to which VUP interfaces are
1) I/O Control Software
2) CAMPS System Functions
3) Storage and File Management
4) SS&C Software
5) Traffic Handling
6) Distribution
7) Table Management
8) Storage and Retrieval
9) Log and Accountability
10) Statistics
Figure 2.1-1
In figure 2.1-2 an overview of the interfaces of VUP
is depicted.
SSC (TEMCO controls through the security control mechanism
all the interfaces of the user package.
In figure 2.1-3 the message flow between VUP and the
rest of the CAMPS system as well as the VUP internal
flow are depicted, highlighting the most important
functional interfaces.
Information flow between VUP and other CAMPS packages
is depicted in figure 2.1-4.
Figures 2.1-2 to -4
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
In this section the functions to be performed by VUP
are outlined. As stated in section 2.1 the main task
of VUP is to implement the CAMPS user function. The
CAMPS user function and the related requirement will
be treated as a whole, i.e. the three subfunctions
Preparation, Reception, and Release constituting the
CAMPS user function and to each of which access must
be granted by the supervisor will be treated together
in most sub-sections. For the limitations imposed if
a user only possesses access rights to one or two of
the subfunctions refer subsection 2.2.2.1 and 2.2.2.6.
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲(̲N̲o̲r̲m̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲)̲
The main functions to be implemented by VUP are:
1) Continuously display of queue status information
2) Continuously display information concerning the
transaction in progress
3) The means for display of queued information
4) The means for message/comment preparation
5) The means for directing requests to CAMPS and deliver
responses to the user
6) Maintain and update message status files
In figure 2.2-1 an overview of all transaction, which
may be initiated by the user is shown, together with
an indication of whether the transaction refers to
preparation/request or display of queued information.
2.2.1.1 Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲D̲i̲s̲p̲l̲a̲y̲
The upper 5 lines of the VDU screen is named the VDU
header area, refer figure 2.2-2.
The second line of the VDU header area is used for
queue status display. For each of the three queues;
receive queue (DISP), response queue (RESP) and release
queue (RELS) the total amount of messages queued for
presentation shall be displayed.
The total amount of messages for coordination queued
in the receive queue shall be displayed in the field
marked COOR.
The distribution of messages on precedence levels for
the two precedence queues receive and release shall
be displayed in the fields marked: ZZ (FLASH), OO (IMMEDIATE),
PP (PRIORITY), RR (ROUTINE).
…01…QUEUED INFORMATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FORMAT TRANSACTION DATA ENTRY RECEIVE RESPONSE
RELEASE
ID REQUEST QUEUE QUEUE QUEUE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A New msg. prep. X
B Msg coordination X
C1 Cont. msg prep X
D Msg release X
E1 Incom. msg. pres. X
E2 Outg. msg. present X
F Release notificat. X
G1 New comment prep. X
G2 Comment present X
G3 Cont. Comment prep X
H Retrieval X X
M Prep. predef. msg X
N Outg. msg. status X
O Append msg. X X
P1 Deletion request X
P2 Deletion notificat. X
Q Msg release status X
R Delivery Status X
SC ̲G1 New T ̲To ̲T comment X
SC ̲G3 Cont. T ̲To ̲T comment X
VDU ̲G1 New VDU ̲page prep X
VDU ̲G2 Cont ̲VDU ̲page prep X
VDU ̲H Retrieval, VDU ̲Page X
FIGURE 2.2-1…01…TRANSACTION RELATED TO THE USER FUNCTION
FIGURE 2.2-2
2.2.1.2 I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲c̲e̲r̲n̲i̲n̲g̲ ̲t̲h̲e̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲i̲n̲ ̲P̲r̲o̲g̲r̲e̲s̲s̲
The first line of the VDU Header area (refer fig. 2.2-2)
shall be used to identify to the user the transaction
in progress (TERMINAL FUNCTION) and the classification
of the information currently accessed (CLASSIFICATON).
Whenever the classification is unknown or no transaction
is in progress the maximum classification to which
the user may gain access through this VDU shall be
displayed.
2.2.1.3 D̲i̲s̲p̲l̲a̲y̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
An overview of transactions to be performed in the
Response Mode, Receive Mode and Release Mode of operation
together with the transaction control capabilities
in each mode of operation is given in figure 2.2-3.
For the sake of completeness the Interactive mode of
operation is reflected as well.
2.2.1.3.1 T̲h̲e̲ ̲R̲e̲c̲e̲i̲v̲e̲ ̲Q̲u̲e̲u̲e̲
When the user enters the command RECV (precedence)
VUP shall enter the Receive Mode of operation. The
user shall now be able to inspect the items in the
receive queue one by one, remove an inspected item
from the queue, or request a printed copy of the item.
This may be done by means of the function keys: Keep
and Present, Delete and Present, Print, Cancel.
The first message to be presented to the user shall
be the first queued of the precedence specified by
the command parameter. If none is specified the first
item queued with highest precedence shall be displayed.
When the user activates the function key Suspend or
Cancel, VUP shall exit the Receive Mode of operation.
2.2.1.3.2 T̲h̲e̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲Q̲u̲e̲u̲e̲
When the user enters the command RESP, VUP shall enter
the Response Mode of operation.
The user shall now be able to inspect the items in
the response queue one by one, remove an inspected
item from the queue or request a printed copy of the
item. This may be done by means of the function keys:
Keep and Present, Delete and Present, Print, Cancel.
The first item to be presented to the user shall be
the first queued.
When the user activates the function key suspend or
cancel,VUP shall exit the response mode of operation.
2.2.1.3.3 T̲h̲e̲ ̲R̲e̲l̲e̲a̲s̲e̲ ̲Q̲u̲e̲u̲e̲
The release queue contains messages for release.
When the releaser enters the command RELS (precedence)
VUP shall enter the Release Mode of operation. The
releaser shall now be able to inspect the items in
the release queue one by one, enter his release decision
and/or request a printed copy of the item.
To each item in the release queue is attached an input
format for the entry of the release decision. After
input of the decision the releaser notifies VUP that
a release decision has been entered by means of the
function key ENTER. VUP removes the item from the queue
and executes the decision.
Inspection and print requests are issued to VUP by
means of the function keys: Keep and Present, Print.
The first message to be presented to the releaser shall
be the first queued of the precedence specified by
the command parameter. If none is specified the first
item queued with highest precedence shall be displayed.
When the releaser activates the function key Suspend
VUP shall exit the Release Mode of operation.
2.2.1.4 M̲e̲s̲s̲a̲g̲e̲/̲C̲o̲m̲m̲e̲n̲t̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
a) Message/comment preparation consists of two functions:
Preparation of New messages/comments, Editing of
existing Messages and Comments.
b) Messages may be edited until they are requested
released. If the release request is rejected or
deferred the messages become available for editing
again. After release the message is not available
for editing.
c) Comments may be edited until they are requested
sent (distributed internally).
d) It is the responsibility of VUP to send retrieval
keys to SAR for the first draft of a message.
e) It is the responsibility of VUP to send retrieval
keys for a comment at the time of the send request.
f) Message/Comment preparation is achieved through
one of the transactions listed below:
1) New Message Preparation (format A)
2) Continue Message Preparation (format C1)
3) Prepare Predefined Message (format M)
4) New Comment Preparation (format G1)
5) Continue Comment Preparation (format G3)
6) New VDU ̲Page Preparation (format VDU ̲G1)
7) Continue VDU ̲Page Preparation (format VDU ̲G3)
8) New T ̲to ̲T Comment Preparation (format SC ̲G1)
9) Continue T ̲to ̲T Comment Preparation
(format SC ̲G3)
g) f1), f3), and f4) above requires that VUP inserts
the new item in the preparation database. Whereas
f2) and f5) above require VUP to retrieve the items
which the user wants to edit from the preparation
database.
h) In figure 2.2-4 the different stages of a preparation
transaction (refer f) above) is shown. The user
access to control the transaction by means of function
keys is shown for each stage as well.
1) For messages the request for further treatment
may be:
- APPEND
- COORDINATE
- SEND FOR RELEASE
- DEFER
2) For comments the request for further treatment
may be:
- SEND
- DEFER
3) For VDU pages:
- SEND
- DEFER (i.e. available in PDB)
- STORE (i.e. available in VDU-page database)
Figure 2.2-4
Figure 2.2-5
2.2.1.5 T̲r̲e̲a̲t̲m̲e̲n̲t̲ ̲o̲f̲ ̲U̲s̲e̲r̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
Besides the user requests which may be entered as part
of a transaction, the requests listed below may be
issued by the user:
- Retrieval (format H)
- Deletion Request (format P1)
- Outgoing Message Status (format N)
- Delivery Status (format R)
- Release Status (format Q)
- VDU Page Retrieval (format VDU-H)
In figure 2.2-5 the different stages of a request transaction
is shown, together with the user access to control
the transaction by means of function keys in each stage.
2.2.1.6 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲F̲i̲l̲e̲s̲
It is the responsibility of VUP to maintain and update
the following status files for each VDU:
- Outgoing Message Status
- Delivery Status
- Release Status
2.2.1.6.1 O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲t̲u̲s̲
The Outgoing Message Status file shall contain the
status for each message prepared at a VDU.
Each day at 24.00 hour the Outgoing Message status
file shall be cleaned up. This means that all status
information concerning items which will no longer undergo
changes shall be deleted (e.g. messages released, deleted
etc.)
2.2.1.6.2 D̲e̲l̲i̲v̲e̲r̲y̲ ̲S̲t̲a̲t̲u̲s̲
The Delivery status shall contain a list of all items
removed from the receive queue, as well as these of
the relevant type retrieved. The Delivery Status shall
be cleared each day at 24.00 hour.
Figure 2.2-6
2.2.1.6.3 R̲e̲l̲e̲a̲s̲e̲ ̲S̲t̲a̲t̲u̲s̲
The release status shall contain a list of all items
to which a release decision has been taken and a list
of the associated release notifications for each VDU
with release capability.
Each day at 24.00 hour the Release Status file shall
be cleared.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲,̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
2.2.2.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
On command from SSC VUP shall initialize the VUP software.
The initialization refers to the functions to be performed
after load or re-load of VUP and which it is necessary
to execute before VUP can initiate its normal operation.
2.2.2.1.2 T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
On command from SSC, VUP shall terminate its current
processing in an ordered manner and bring itself into
a state, where it can respond to a restart command.
2.2.2.1.3 R̲e̲s̲t̲a̲r̲t̲
On command from SSC VUP shall be able to execute a
restart function. Restart is commanded following close
down, switchover or total system failure. VUP shall
implement functions necessary to restart after each
situation listed above.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
a) Checkpointing
Checkpointing is performed by calling the SAVE-function
(CSF function) at appropriate points, that is when
a message is created, updated, and sent to queues
in the system.
b) Recovery
When VUP is restarted by SSC software following
close down, switchover, or total system failure
"recovery required" is specified by SSC.
Relevant queues will then have contents according
to latest checkpoint and VUP shall inspect the
queues to reestablish the VUP state.
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
a) Error Detecting
Errors detected by TEP are of the following types:
- Internal software errors
- Illegal contents of received QEL's
- Unknown CC's delivered by System Software
b) Error Handling
Errors detected by VUP shall be reported to the
SSC together with information on whether VUP was
able to handle the error itself or not. (Refer
also subsection 2.2.2.4). Detection of an error
which VUP cannot handle itself shall cause VUP
to stop its processing and transfer control to
SSC for further handling of the situation.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
VUP shall contain credibility check to contain the
effects of corrupt or inaccurate data to the extent
this does not introduce redundant processing which
will decrease the system throughput.
It shall be a design aim that wherever possible the
consequence of a single software fault incident will
not affect more than one transaction. The detection
of an inconsistency indicating a fault shall initiate
a report and the re-processing from a validated checkpoint
in an attempt to recover with a minimum of discontinuity.
Only after further failures should major recovery or
operator intervention action be invoked.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
2.2.2.5.1 L̲o̲g̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
Log information on user transactions shall be collected
by the VDU user package and reported to the log package.
Log information shall be reported at the time of start
of a transaction and/or completion of a transaction.
2.2.2.5.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Statistics information on user transactions shall be
collected by the VDU user package and reported to the
statistics package.
The statistics to be reported for each transaction
type is specified in table 2.2.1-7.
2.2.2.5.3 R̲e̲p̲o̲r̲t̲s̲
When the user issues a deletion request on an item,
which the user is not allowed to delete the VDU user
package shall generate a deletion request report and
queue it in the Supervisor's report queue.
CONTENTS NO STAT TYPE 1 TYPE 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Type and Contents Terminal Designator X X
of Statistics Format id X X
Duration of use X
Classification X
Precedence X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A X
B X
C1 X
Transactions identi- D X
fied through Format E1 X
ID and the statistics E2 X
to be collected F X
G1 X
G2 X
G3 X
H X
M X
N X
O X
P1 X
P2 X
Q X
R X
SC ̲G1 X
SC ̲G2 X
SC ̲G3 X
SC ̲D X
VDU ̲G1 X
VDU ̲G2 X
VDU ̲G3 X
VDU ̲H X
SC ̲B X
TABLE 2.2-7 …01…STATISTICS ON USER TRANSACTION
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The VDU user package shall implement the security related
functions listed below:
a) When a releaser requests a message to be released
the VDU user package shall request TEMCO to perform
a security interrogation. The VDU user package
shall await the answer from TEMCO and only release
the message if the Security interrrogation is reported
successful completed by TEMCO.
b) For each CAMPS user sub-function, i.e. Preparation,
Release, and Reception, the VDU user package shall
check each command entered by the user in interactive
mode of operation against the assigned sub-function,
and prevent illegal transactions to be initiated.
Refer table 2.2-8.
Access to queues are checked by System Software.
c) For each command entered by the user there exists
a function key mask. This will prevent illegal
transactions being initiated.
̲ ̲ ̲ ̲U̲S̲E̲R̲ ̲S̲U̲B̲F̲U̲N̲C̲T̲I̲O̲N̲ ̲ ̲
̲
VDU MODE OF FORMAT TRANSACTION PREP. RELS. RECV.
OPERATION ID
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
Interactive A New msg. prep. X
Mode
(Data entry C1 Cont. msg prep X
and requests)
G1 New comment prep. X X
G3 Cont. Comment prep X X
H Retrieval X
M Prep. predef. msg X
N Outg. msg. status X
O Append msg. X
P1 Deletion request X
Q Msg release status X
R Delivery Status X X X
SC ̲G1 VDU Page Prep X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
B Msg. Coordination X X
Receive Mode
E1 Incom. Msg. Present X
E2 Outg. Msg. Present X
G2 Comment Present X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
F Release Notificat. X
Response Mode
H Offl. Retr.Notific. X
O Offl. append notif. X
P2 Deletion Notificat. X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
Release Mode D Msg. Release X
TAB. 2.2-8 TRANSACTIONS ALLOWED PER ASSIGNED CAMPS USER SUBFUNCTION
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
a) Transmission to terminals of a response or other
output shall be at cadence speed once commenced.
b) Non interactive transactions shall in 90% of all
cases commence not later than 5 seconds after the
event which gives rise to the transaction, assuming
the terminal facility required is available.
c) During interactive transactions at VDUs, the response
time shall be measured as the time delay from transmission
of the last character of the input to the system
and the start of display of response/next format/menu.
d) Once an interactive transaction has been completed
or terminated/aborted the succeeding action(s)
by the system shall commence within 5 seconds in
90% of all cases.
e) Update of queue status in the VDU header area shall
take place each minute. If a message of precedence
FLASH (or above) arrives, the queue status shall
be updated immediately.
The VDU USER PACKAGE shall contribute as follows:
1) Handling of entry in the command time shall not
exceed 25 ms in 90% of all cases including table
access time.
2) Response time for validations of information (e.g.
message, edited message shall not exceed 7 sec.
in 90% of all cases including all table accesses.
3) Validation of a request (e.g. retrieval, status)
shall not exceed 100 ms. (until return of answer
of expected success) in 90 per cent of all cases.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
a) The busy second character flow from/to a CAMPS
of maximum equipment configuration employing formats
applicable to messages not yet released shall never
exceed:
To CAMPS ............... 200 Chars/sec
From CAMPS ............. 1400 Chars/sec
b) A comment will in average be of 69 characters excluding
heading information.
c) During crisis and exercise 15 messages shall be
prepared in busy hours at CAMPS VUDs.
d) The above 15 messages shall in average be sent
for co-ordination twice with 5 addressees per co-ordination
cycle.
e) Above 15 messages shall in average be edited twice.
f) 2 comments are generated in average per message
above.
g) Additionally 10 comments are generated in connection
with co-ordination of CCIS originated messages.
h) The above 40 comments are subject to 40 x 2.5 VDU
presentations.
i) During crisis and exercise busy hours 10 comments
are prepared additionally for transmission to SCARS
and 5 to CCIS.
j) Comments shall in average be subject to 1 edit.
k) With addition of 15 messages entered via OCR to
the 15 messages drafted from VDUs a total of 30
messages originated CAMPS shall be subject to local
distribution with 30 x 5 presentations to VDU
and 30 x 5 to printer.
l) A total of 35 messages generated locally at CAMPS
shall during crisis and exercise busy hours be
transmitted via Point-to Point networks (2 messages,
each with 4 separate transmissions) and TARE networks
(33 messages with one transmission each).
m) Messages will in average be subject to 1.2 presentations
for release.
n) During crisis and exercise busy hours 5 VDU pages
shall be prepared at CAMPS for transmission to
CCIS.
o) VDU pages are subject to 1 edit.
p) Maximum operator keying rate is assumed to be 10
IA5 character/s.
q) The channel capacity for transmission from VDU
to system and for system response out-put is 120
IA5 charactoers per second.
r) The throughput in this section is specified for
a CAMPS of less than maximum configuration as defined
in CPS/210/SYS/001 3.4.1.2.1.
Throughput requirements in this section shall for
a CAMPS of less than maximum configuration be reduced
as follows:
M̲a̲x̲.̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲:
VDU (32) 32 x 120 chars/s
TPs (as TRC) 24 x 10 chars/s
s) For a CAMPS with less than max. configuration the
theoretical flow shall be calculated as above and
the throughput requirements in this section be
reduced accordingly.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
a) Precedences:
Four levels of precedences shall be distinguished
by the system. To accomodate a possible increase
in the number of precedence levels used, allowance
shall be made in the design for two other levels.
Defined Precedences Precedences Foreseen
highest
Superflash
Flash Flash
Immediate Immediate
Superpriority
Priority Priority
Routine Routine
lowest
b) Formats:
Changes in formats, new formats, changes in format
tolerances and improvements in Man/Machine I/F
shall be flexibility requirements during TEP design.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
a) Accuracy of input data:
Time shall be exact within 500 ms, i.e. a tolerance
of +/- 500 ms is acceptable.
All other input data shall be exact.
b) Accuracy of output data:
Output-data shall be exact, except for time where
the tolerance mentioned in (a) above applies.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
The equipment environment of this package is the CR80D
Computer.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
VUP's system software environment consists of the following
components:
- DAMOS
- CAMPS System Functions
- Message Management System
- Storage and File Management
- I/O Control Software
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Development software is standard DAMOS and TOS (Terminal
Operating System) resident in a single CR80D configuration.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
User Procedures ref. doc. no. CPS/230/ICD/0001.
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
3.3.2.1 T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲(̲T̲H̲P̲)̲ ̲I̲/̲F̲
Message released by the releaser shall by VUP be queued
to THP for routing and ACP127-conversion.
3.3.2.2 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲(̲M̲D̲P̲)̲ ̲I̲/̲F̲
Messages for coordination are by VUP queued to MDP
for distribution. MDP returns to VUP a list of the
coordinators which could not be reached.
Comments are by VUP queued to MDP for distribution.
MDP queues messages for coordination, comments, incoming
and outgoing messages in VUP's receive queue.
Whenever MDP queues a message of precedence FLASH or
above MDP shall explicit notify VUP.
If during Quiet Hours a message of precedence Flash
or Immediate is sent or attempted sent to a terminal
which is signed off it will be queued for the Quiet
Hour Terminal as specified by the supervisor.
3.3.2.3 S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲(̲S̲A̲R̲)̲ ̲I̲/̲F̲
VUP shall request SAR to store first drafts of messages.
Together with the store request VUP reports all the
retrieval keys except for the TOC.
SAR shall retrieve items requested by VUP. VUP shall
queue the retrieve request to SAR. SAR will inform
VUP whether the requested item resides on on-line or
off-line database. After retrieval SAR shall queue
the retrieved item or an error code to VUP.
3.3.2.4 L̲o̲g̲ ̲a̲n̲d̲ ̲A̲c̲c̲o̲u̲n̲t̲a̲b̲i̲l̲i̲t̲y̲ ̲(̲L̲O̲G̲)̲ ̲I̲/̲F̲
LOG records collected by VUP shall be queued to LOG.
VUP then receives a receipt from LOG.
3.3.2.5 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲(̲S̲T̲P̲)̲ ̲I̲/̲F̲
Statistics information to be collected by VUP shall
be communicated to STP by invoking the appropriate
Monitor Procedure.
3.3.2.6 S̲S̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲/̲F̲
VUP shall be able to request TEMCO (SSC Software) to
perform a security interrogation. When TEMCO has performed
the security interrogation VUP shall be informed of
the result.
The following types of security interrogation are requested:
-release security interrogation
-deletion security interrogation
On command from SSC VUP shall execute the start function.
The start command is given VUP after a user has signed-on,
together with all information necessary (access rights,
associated release terminal, etc.).
On command from SSC VUP shall stop its current processing.
The stop command is issued from SSC when the user signs-off
or in analogous situations. VUP shall upon reception
of the stop command perform all function necessary
to clean up work space used and be ready for a new
SSC command.
3.3.2.7 T̲a̲b̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲T̲M̲P̲)̲ ̲I̲/̲F̲
TMP provides access to tables, global number series
and system parameters. The tables accessed by VUP include:
AG
AIG
PLA
SCD
SIC
Operating-signal-table
Special-handling-table
Global no. series:
Transaction serial no.
Release serial no.
Sequence-table
Command-table
Response text table
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
Security interrogations and warnings are performed
by TEMCO (SSC) without the knowledge of VUP. SSC Software
is requested by the Message Management Software to
execute the interrogation/warning when access to a
message is requested by VUP. Access by VUP will only
be allowed if granted by SSC software.
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The V̲DU U̲ser P̲ACKAGE (VUP) consists of two processes,
one process containing the software required to support
the VDU handling and one containing the software to
control the Preparation Database.
a) VDU User Subprocess (VUS)
This consists of four subpackages (coroutines):
VCO (User V̲DU C̲o̲ntrol) which reacts upon commands
from TEMCO and controls the other coroutines as
well as maintaining the VDU Header Status Area.
UFCO (U̲ser F̲unction C̲o̲ntrol) which reacts upon
commands from VCO, F/C keys from keyboard and input
from the Answer Queue, the Receive Queue, the Release
Queue and the Response Queue. It also receives
input from RETR and controls VDIA. It contains
all the functions for c̲o̲n̲t̲r̲o̲l̲ of the MMI and interfacing
to other packages as well as command execution.
VDIA (V̲DU D̲i̲a̲logue) which reacts upon commands
from UFCO and performs input and output to and
from the VDU Format Area and validation of input
data.
RETR (R̲e̲t̲r̲ieval) which receives answers from SAR
(messages or error codes). It communicates on-line
retrieval results to UFCO and off-line retrieval
results to the Response Queue.
Communication with other Packages is done via queues.
The VUS has 4 main-queues:
1) Command Queue:
Commands from TEMCO, timer events from Timer
Monitor and flash notification.
2) Receive Queue:
This consists of six subqueues, one for each
precedence level. Messages/comments for presentation
at the User VDU are sent to this queue.
3) Release Queue:
Messages for release. Six subqueues, one to
each precedence.
4) Answer, Response, Retrieval Queue, containing
3 subqueues:
4.1) Answer Queue:
Answers to requests to other packages.
4.2) Response Queue:
Release Notifications, Off-line Retrieval
Results (placed in the queue by RETR),
and Deletion Notifications and Append
Notifications.
4.3) Retrieval Queue:
Retrieval Results received from SAR.
b) User Message Access Monitoring Process (UMAM)
This consists of one subpackage.
UMAM reacts upon reception of a QEL in either the
Command or the Collect Queue.
UMAM has two queues:
Command Queue:
Commands from SSC and timer events
Collect Queue:
This consists of six subqueues
Request Queue:
The following requests are sent to this queue:
- Edit request
- Delete request
- VDU-page retrieval
Preparation Queue:
Messages/comments prepared are sent to this queue
from MSA and VUS. Also access state changes are
sent to this queue.
VDU-page Queue:
VDU-pages to be included in the Display Data Base
are sent to this queue.
Status Request Queue
The following requests are sent to this queue:
- Outgoing message status request
- Outgoing service message status request
- Release status request
- Delivery status request.
Delivery Queue:
Status information to be included in the delivery
status are sent to this queue from VUS and PRIS
Append Queue:
Messages retrieved for append are sent to this
queue by VUP.
4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section contains an analysis of the main functions
to be performed by the VDU User PACKAGE (VUP).
The analysis is carried out to a level where subfunctions
with self-contained implementation considerations may
be isolated, thereby reducing the complexity to be
grasped at one time.
Furthermore, the aim of the analysis is to identify
precisely concurrency and priorities of subfunctions.
The analysis does not include the package functions
derivable from the functional responsibilities described
in section 2.2.2. These functions will be analyzed
and described for each identified subfunction in section
4.2 of this document.
In fig. 4.1.1-1 an overview of the VUP functions is
shown. This first level breakdown represents a simple
grouping of the requirements outlined in section 2
and of the requirements stated in ref. 2.
The box marked TEMCO CONTROL FUNCTIONS reflects the
fact that the VUP functions are totally controlled
by the TEMCO part of the SSC Software. Thus VUP shall
contain functions necessary to respond to and execute
such controlling commands.
Fig. 4.1.1-1 Main Functions
The boxes marked User TRANSACTION CONTROL and QUEUE
STATUS MAINTENANCE refer to all the functions to be
performed where a user has signed on, i.e. the activation
/ deactivation of those functions are controlled by
TEMCO, so the TEMCO CONTROL FUNCTIONS are those with
highest priority within VUP.
In the following subsections, each of the functions
shown in the boxes of fig. 4.1.1-1 will be broken down
into subfunctions.
4.1.1.1 T̲E̲M̲C̲O̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
In fig. 4.1.1.1-1, an overview of the TEMCO control
functions is depicted.
The first three, Initialization, Close Down and Restart
are used at initialization of the CAMPS system and
in recovery or system switchover situations, so compared
with the other functions in the group, they are seldom
invoked.
The function block terminal is called on by TEMCO after
an unsuccessful security interrogation or warning or
on supervisor command, and indicates that all VDU communication
is stopped immediately.
Fig. 4.1.1.1-1 TEMCO Control Functions
The start session and stop session are called by TEMCO
after user sign-on respectively sign-off has occurred.
The start session command from TEMCO is associated
with a capability list, informing VUP of the access
rights and security rights of the user. VUP is thereby
indirectly informed about which queues etc., it is
allowed to access, and which user transactions it may
execute. The stop session command informs VUP that
those access rights have now been withdrawn.
The release interrogation response is a control function
used at message release. When a releaser requests a
message to be released, VUP will send a request to
TEMCO, asking if the release function may be executed.
TEMCO will then answer yes or no to the request, thereby
activating the release response function.
The nature of the TEMCO control functions, i.e. their
close relationship with system integrity and security,
requires their immediate activation when called upon
by TEMCO. Thus this group of functions shall have the
highest priority within VUP. This implies that where
sequencing of the external events activating VUP functions
is introduced, those events activating TEMCO control
functions shall be taken out of sequence and handled
before all other events.
4.1.1.2 Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
The headline Queue Status Maintenance covers the requirements
listed below:
- The periodic update of the VDU header queue status
line with a periodicity of one minute.
- The immediate update of FLASH (and superflash)
precedence queues each time an item is placed in
such a queue.
- The constant monitoring of FLASH (and superflash)
precedence levels to stay longer in the queues
than allowed by the supervisor. Such "old" items
shall be queued for the MDCO.
In fig. 4.1.1.2-1, a functional breakdown of the QUEUE
STATUS MAINTENANCE function is depicted.
Relating the figure to the summary of requirement given
in section 2.1, the breakdown should be self evident,
except for a few functions explained below.
The INVERT RELS/DISP TEXT functions are introduced
to satisfy the requirements for a unique indication
of which of the FLASH precedence queues contains elements.
As the number in the FLASH queue (ZZ-field) in the
queue status line is the total amount of items of FLASH
precedence in thje queue currrently worked upon or
if none then the receive queue, the relevant queue
(s) RELS or DISP is displayed in inverse video.
The INTERPRET FLASH NOTIFICATION function is a consequence
of System Design, where the following requirement was
introduced:
- When a package places an item in a FLASH (or Superflash)
precedence level queue, it shall place a FLASH
NOTIFICATION (indicating the relevant queue) in
the command queue as well.
The real time nature of the QUEUE STATUS MAINTENANCE,
together with the requirements for concurrency with
the User TRANSACTION CONTROL, implies that the QUEUE
STATUS MAINTENANCE functions shall have higher priority
than the User TRANSACTION CONTROL functions.
Fig. 4.1.1.2-1 Queue Status Maintenance
4.1.1.3 U̲s̲e̲r̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The User Transaction Control Function (refer fig. 4.1.1-1)
contains the functions listed below. In the following
subsections, these functions will be analyzed in more
detail:
- TRANSACTION ACCOUNTING
- TRANSACTION INTERRUPTION
- TRANSACTION EXECUTION.
4.1.1.3.1 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
User transaction accounting refers to the collection
of statistical data and of log data and the subsequent
delivery of the data to the packages LOG and STP.
In fig. 4.1.1.3-1, a functional breakdown of the User
Transaction Accounting is depicted and for the case
of reading table 2.2-7 and table 2.2.-8 of section
2.2.2.5. From the requirement overview of log records
to be reported (refer table 2.2-6), it is seen that
a log record for some transaction shall be sent to
LOG both at transaction start and transaction termination.
Furthermore, it is seen from table 2.2-7 that statistics
data contain the duration of use of a format, which
implies that the start time of transaction shall be
kept by VUP until transaction termination. The user
transaction accounting therefore splits into the two
functions TRANSACTION INITIATION ACCOUNTING and TRANSACTION
TERMINATION ACCOUNTING.
An analysis of the statistics requirements shows that
the initial data to be collected are:
- Terminal designator
- Format id
- Start of transaction
and that the termination data to be collected are:
- Termination time
- Classification
- Precedence.
The initial statistical data to be collected are a
subset of the log data to be collected, and that the
termination statistical data to be collected may be
derived from the log data except for precedence.
Log and statistics collection functions are thus related
through the data types to be collected.
Fig. 4.1.1.3-1 Transaction Accounting
4.1.1.3.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲i̲o̲n̲
A functional breakdown of Transaction Interruption
is shown in fig. 4.1.1.3-2.
The EXECUTE FUNCTION KEY FUNCTION does not contain
a unique function to be performed for each function
key defined, as the function to be performed upon reception
of a function key, depends on the mode of operation
(e.g. interactive or receive mode) and the transaction
in progress, but executes the function corresponding
to the function key within the current context.
Fig. 4.1.1.3-2 Transaction Interruption
4.1.1.3.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
4.1.1.3.3 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲
A functional breakdown of these functions is shown
on fig. 4.1.1.3-3. The functions are performed when
a command is entered in the Command Line of the VDU
Header.
Command Validation is performed to check that the command
is a valid User Command and acceptable in the current
context.
Command Parameter Validation is performed on parameters
entered with the command (if any).
Display Error Message is performed if the command or
parameters are not acceptable.
Fig. 4.1.1.3-3 Command Interpretation
4.1.1.3.3.2 C̲o̲m̲m̲a̲n̲d̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
A functional breakdown of these functions is shown
on fig. 4.1.1.3-4
The boxes marked DEFINE VALID COMMANDS reflects that
the normal Command Code Validation shall be ignored
and that only specified command codes are valid during
transaction execution, i.e. the user is not allowed
to terminate a transaction in progress by initiating
another.
The heading OPEN FOR ACCESS TO RELEVANT SUBQUEUE is
just another way of expressing that the VDU shall enter
the receive, response or release mode of operation.
Fig. 4.1.1.3-4 Command Execution
4.1.1.3.3.3 S̲t̲a̲r̲t̲/̲S̲t̲o̲p̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
In fig. 4.1.1.3-5 a functional breakdown of the start/stop
transaction group is depicted. The boxes marked REQUEST
ACCESS TO ITEM contain the functions where VUP via
system software requests access to an item and TEMCO
performs a security interrogation and/or warning. Access
to the item will only be granted if so allowed by TEMCO.
Fig. 4.1.1.3-5 Start/Stop Transaction Execution
4.1.1.3.3.4 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲/̲C̲o̲m̲m̲e̲n̲t̲s̲
In fig. 4.1.1.3-6, a functional breakdown of Preparation
of Messages/Comments is shown.
The DEFINE ALLOWED FUNCTION KEY INTERRUPTS reflects
that not all function key interrupts are allowed during
execution of the transaction. This function is not
part of the Command Execution as the analogue function
for commands DEFINE VALID COMMANDS, because function
key interrupts allowed are dependent on both the transaction
in progress and the processing state.
Fig. 4.1.1.3-6
Functional Breakdown of Preparation of Messages/Commands
4.1.1.3.3.5 P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
In fig. 4.1.1.3-7, a functional breakdown of Presentation
of Queued Information is depicted.
Fig. 4.1.1.3-7 Presentation of Queued Information
4.1.1.3.3.6 R̲e̲q̲u̲e̲s̲t̲s̲ ̲t̲o̲ ̲C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲
In fig. 4.1.1.3-8, a functional breakdown of Requests
to CAMPS System is depicted.
Comment Treatment Request, Message Treatment Request,
Release Decision Treatment and Append Request are all
of the type, where the request is not associated with
a command code, but may be input as part of a transaction
via an input format. The print request is also associated
with a specific transaction but entered via a function
key, whereas retrieval and status requests are command
requests.
Note that the OUTPUT MESSAGE TEXT function for the
Append Request is shared with Message Preparation.
Fig. 4.1.1.3-8
4.1.1.3.3.7 D̲i̲a̲l̲o̲g̲u̲e̲ ̲F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲
Functional breakdown of these functions is shown on
fig. 4.1.1.3-9. The functions all invoke calls upon
the Monitor Procedures of the FORMAT HANDLER in the
IOC Package. Via these procedures, the actual communication
with the VDU Format Area is performed. For details
refer to IOC Package Design Spec.
Fig. 4.1.1.3-9 Dialogue Formatting
4.1.1.3.3.8 F̲o̲r̲m̲a̲t̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
Functional breakdown of these functions is shown on
fig. 4.1.1.3-10.
HEADER FORMAT VALIDATION is performed after entry of
message header during Message/Comment Preparation.
TEXT FORMAT VALIDATION is performed after entry of
message text during service Message/Comment Preparation.
REQUEST FORMAT VALIDATION is performed after entry
of a request.
DISPLAY ERROR CODE FORMAT is performed when errors
are made during validation.
Fig. 4.1.1.3-10 Format Validation
4.1.1.4 U̲s̲e̲r̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
This function contains the following two functions:
- Preparation Database Access Control
- Message Status Maintenance
These are broken down in greater detail in the next
subsections.
4.1.1.4.1 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲b̲a̲s̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Preparation Database Access Control function is
not concerned with security, but only with the requirements
to access control related to the preparation state
of the item. These requirements have been extracted
from the preparation related transactions described
in ICD/0001 and are tabulated in table 4.1.-3.
In fig. 4.1.1.4-1, a functional breakdown of the Preparation
Database Access Control is depicted.
The figure shows that the Preparation Database Access
Control Function on the first level of breakdown may
be considered to consist of:
- Access control related to edit requests
- Access control related to delete requests
- Access state changes.
From the above analysis it may be derived that:
- It shall be possible to change the access state
of a message, even if no user is currently signed-on,
as the state change may be caused by the releaser
or by SAR (on completion of an off-line append).
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Access states Reported by Editing
access
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Released Releaser N
M
Release Rejected Releaser Y
E
Release Deferred Releaser Y
S
Deleted Preparer N
S
Awaiting Release Preparer N
A
Awaiting Append Preparer N
G
Sent for Coordination Preparer Y
E
Suspended Preparer Y
S
Deferred Preparer Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C
O Sent Preparer N
M
M Deleted Preparer N
E
N Suspended Preparer Y
T
S Deferred Preparer Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-3 Preparation Database Access
Fig. 4.1.1.4-1 Prepartion Database Access Control
4.1.1.4.2 M̲e̲s̲s̲a̲g̲e̲/̲C̲o̲m̲m̲e̲n̲t̲ ̲S̲t̲a̲t̲u̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
According to requirements (ref 1 and ref 2) and System
Design (ref 3) the following status shall be maintained
by VUP:
- Outgoing Message/Comment Status
- Delivery Status
- Release Status.
- Service Message Status
Some of the entries in the status are changed during
the life-period of the status and some are not. In
tables 4.1-4, 4.1-5 and 4.1-6, the entry types of each
status have been tabulated.
The functional breakdown of the message/comment status
maintenance is depicted in fig. 4.1.1.4-2.
A comparison between the Outgoing Message/Comment Status
(refer table 4.1-4) and the access states for messages/comment
under preparation (refer table 4.1-3) gives an impression
of the close relationship between these two functions.
Thus the analogous requirements derived may be derived
for the update requests to the Outgoing Message/Comment
status.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Entries Changeable
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Released N
M
Release Rejected N
E
Release Deferred N
S
Deleted N
S
Awaiting Release Y
A
Awaiting Append Y
G
Sent for Coordination Y
E
Suspended Y
S
Deferred Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C
O Sent N
M
M Deleted N
E
N Suspended Y
T
S Deferred Y
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-4 Outgoing Message/Comment Status Entries
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Entries Changeable
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Incoming Message N
Outgoing Message N
Message for Coordination N
Comment N
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-5 Delivery Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Entries Changeable
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Released N
Rejected N
Deferred N
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Table 4.1-6 Release Status
G A M M E L T = ISSUE 1
FORMAT ID A C1 M O H B E1 D F P1 P2 N Q R DUMMY
G1 G3 E2 G2
Log Re-
cord (type,
control)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Initial X X X X
Final X X X X X X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Term design X X X X X X X X X X X
Trans.ser.no. X X X X X X X X X X X
Format id X X X X X X X X X X X
Log time X X X X X X X X X X X
Item ref id X X X X X X X X
Exit Cause X X X X X X X X
Classification X X X X X
Spec.hand.cat. X X X X X
Start time of
transaction X X X X…0e…1)…0f… X
Item ref id X X X
Month + day X
Decision code X
NOTE 1: Format P2 only
TABLE 2.2-6
LOG OF USER TRANSACTION
FORMAT ID A C1 M O H B E1 D F P1 P2 N Q R DUMMY
G1 G3 E2 G2
Log Re-
cord (type,
control)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Initial X X X X
Final X X X X X X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Term design X X X X X X X X X X X
Trans.ser.no. X X X X X X X X X X X
Format id X X X X X X X X X X X
Log time X X X X X X X X X X X
Item ref id X X X X X X X X
Exit Cause X X X X X X X X
Classification X X X X X
Spec.hand.cat. X X X X X
Start time of
transaction X X X X X
Item ref id X X X
Month + day X
Decision code X
Table 4.1-1 Log of User Transactions
CONTENTS TYPE 1 TYPE 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Type and Contents Terminal Designator X X
of Statistics Format id X X
Duration of use X
Classification X
Precedence X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A X
B X
C1 X
Transactions identi- D X
fied through Format E1 X
ID and the statistics E2 X
to be collected F X
G1 X
G2 X
G3 X
H X
M X
N X
O X
P1 X
P2 X
Q X
R X
Table 4.1-2 Statistics on User Transactions
