SH20 9002 2_CICS_VS_System_Application_Design_Guide_Jul75 2 CICS VS System Application Design Guide Jul75
SH20-9002-2_CICS_VS_System_Application_Design_Guide_Jul75 SH20-9002-2_CICS_VS_System_Application_Design_Guide_Jul75
User Manual: SH20-9002-2_CICS_VS_System_Application_Design_Guide_Jul75
Open the PDF directly: View PDF 
.
Page Count: 394
| Download | |
| Open PDF In Browser | View PDF |
SH20-9002-2
Program Product
Customer Information
Control SystemNirtual
Storage (CICSNS)
SystemlApplication
Design Guide
Program Numbers S740-XX1
S746-XX3
(CICS/OS/VS)
(CICS/DOS/VS)
Third Edit.ion (July 1975)
This is a reprint of SH20-9002-1 incorporating changes released
in the fol.lowing Technical Newsletter:
SN20-9089 (dated May 22, 1975)
This edition applies to Version 1, Modification Level 1, Release 1,
of the program product Customer Information Control System/Virtual
Storage (CICS/VS), program numbers 5740-XX1 and 5746-XX3, and to all
subsequent: versions and modifications until otherwise indicated in
new editions or technical newsletters.
Informaticm in this publication is subject to significant change.
Any such (:hanges will be published in new editions or technical
newslettel:s. Before using this publication, consult the latest
IBM System/360 and System/370 Bibliography, GA22-6822, and the
technical newsletters that amend the bibliography, to learn which
editions iwd technical newsletters are applicable and current.
Requests jEor copies of IBM publications :should be made to the
IBM branch office that serves you.
A form fOlt:' readers' comments has been provided at the back of
this publication. If the form has been removed, address comments
to IBM United Kingdom Laboratories Ltd., Publications Department,
Hursley Pi3.rk, Winchester, Hampshire, S021 2JN, England. Comments
become th4~ property of IBM.
C Copyright International Business Machines Corporation 1973, 1975
PREFACE
This publication provides the system analyst and system administrator
with guidelines which assist in the design of online applications to
run under the control of CICS/DOS/VS or CICS/OS/VS, here~after referred
to as CICS/VS or simply CICS. It assumes that the readE!r is familar
with the CICS/VS General Information Manual (GIM). The GIM provides
an introduction to the CICS/VS facilities, using several applicat~on
examples to highlight the various facilities which theSE! applications
demand of CICS/VS. These applications are then develope!d further in
this publication.
The ·publication is directed mainly towards the inexpe!rienced CICS
user, and assumes no prior CICS knowledge apart fram that presented in
the CICS/vS General Information Manual.
It presents separate chapters, covering the following design topics:
•
•
•
•
•
•
•
•
•
•
•
Introduction to Systems Design
Program Design
Data Communication Design
Data Management Design
Data Base Design
Advanced Features
Performance Considerations
Recovery and Restart
Testing and Integration
Cutover and Follow-up
Application Design
Each chapter is presented in a tutorial fashion, generally first
with an outline of various CICS/VS facilities relevant to that chapter,
followed by specific design techniques utilizing those facilities.
To enable experienced CICS users to concentrate only on these CICS/VS
facilities which differ from previous versions of CICS, each chapter
commences with a reading guide identifying only those topics which may
need to be read by experienced users.
To enable the publication to be subsequently used for reference
purposes, various CICS/VS facilities relevant to several areas of design
are identified in those areas.
However, whenever a CICS./VS facility
is discussed, cross-reference is made to the section of the publication
which describes that facility in more detail.
RELATED PUBLICATIONS
VTAM
Introduction to
~
GC21-6981
DOS/VS Data Management Guide
GC33-5312
OS/VS VSAM Planning Guide
GC26-3799
Preface
i
CICS/VS
Adv'anced Communication Guide
SH20-9049
~llica tion
SH20-9003
Programmer's Reference Manual
System Programmer's
Referenc~
Manual
SH20-9004
Terminal Operator's Guide
SH20-9005
System Administrator's Guide
SH20-9006
OpE!rations Guide (CICS/DOS/VS)
SH20-9012
opE!rations Guide (CICS/OS/vS)
SH20-9011
Subset User's Guide (CICS/DOS/vS)
SH12... 5404
Ref:erence Summary:
0pE!rator
Master Terminal
SX26-3700
Reference Summary:
Program Debugging
SX26-3101
DL/I !>OS/VS
System/APplication Design Guide
SH12-5413
General Information Manual
GH20-1246
~)lication
SH12-5100
Programming Reference Manual
DLI'I Bridge General Informat:ion Manual
GH12- 51 06
IMS/VS
System/Application Design Guide
SH20-9025
~eneral
GH20-1260
Information Manual
System programming
~)lication
Referenc~
Manual
Programming Reference Manual
SH20-9027
SH20-9026
Utilities Reference Manual
SH20- 9029
General Information Manual
GH20-1251
Video/370
General Information Manual
ii
CICS.lVS System/Application Design Guide
SC27-6960
CICS Productivity Aids
Installed User Programs
CICS Online Test/Debug Program
DeSCriPtion operations Manual
SH20-1258
CICS/COBOL Call Interface Program
Description Operations Manual
SH20-1359
Field Developed Programs
CICS Dynamic Map Program Description
Operations Manual.
SB21-1075
CICS Performance Analyzer Program
Description operations Manual
SB21-1181
CICS/3270 Simulator Program Description
Operations Manual
SB21-1036
Preface i i i
Chapter 1. Introduction to Online System Design
system Design in the IRplementation Phase.
The Need for Good System Design.
Turnaround or Response Time.
User Acceptance.
Resource utilization
Design strategy.
structured System Design
Application Design
Chapter 2. CICS/VS Program Design
CICS/DOS/VS Subset Option.
CICS/DOS/VS starter System •
Modular Programming.
Batch Environment.
CICS/VS Online Environment
virtual Storage Environment.
High Level Languages
Tabular Structures
structured programming
Traditional Program Development.
Top-Down Programming
structured Programming with CICS/VS.
Application Functions.
Message Routing.
Terminal Paging.
Terminal Device Independence
Extended 3270 Support.
Input Formatting •
Tabl E; Search
Field Verify/Edit.
Bit Planipula tion
Phonetic Conversion.
weighted Retrieval •
Asynchronous Transaction Processing (ATP).
QUasi-Reentrant Programming.
Task Initiation.
Transaction Codes.
Automatic Task Initiation.
Interval Control
Task Control
PrograDl Control.
Transfer Control to Program (ICTL)
Link to Program (LINK)
Load Program (LOAD).
Delete Program (DELETE).
Return from program (RETURN)
Abnormally Terminate Program (ABEND)
Abnormal Termination Exit (SETIIT)
Program Error Recovery
Program Error Processing •
Program Error Program.
Chapter 3. CICS/VS Data Communications Design
Basic Happing Support.
BMS Haps
Terminal Device Independence
Input Messages •
output Messages.
iv
CICS/VS System/Application Design Guide
1
1
2
2
2
2
3
3
10
13
13
14
14
14
14
15
15
15
17
18
19
21
21
22
22
22
23
23
23
23
23
24
24
24
25
26
27
27
27
27
27
27
28
28
28
29
29
29
29
30
30
31
31
33
33
35
35
Terminal Paging.
Terminal Paging status •
Message Routing.
Message Delivery •
Message switching Transaction (CMSG)
CICS/VS Terminal Control and BMS •
CPU Console as a CICS/DOS/VS Terminal.
Basic Telecommunication Access Method (BTAM)
Basic Graphic Access Metbod (BGAM)
Telecommunication Access Method (BTAM)
virtual Telecommunication Access Method (VTAM)
Synchronous Data Link Control (SDLq
VTAM Network •
Use of VTAM by CICS/VS •
CICS/VS Session Types.
Establishing CICS/VS Sessions with VTAM.
Terminal Control Communication Using VTAft.
Basic Mapping Support Communication with VTAM.
Terminal Device Independence with VTAM and BTAM.
Terminal Paging Using VTAM •
Message Routing and Message Switching Using VTAM •
Conversational Applications.
Task Initiation.
Input Transaction Design •
Transaction Editing.
Error correction •
output Formatting.
Batch Applications •
Asynchronous Transaction Processing.
General Batch Processing •
Terminal Error Recovery.
Terminal Abnormal Condition Program (TACP)
Terminal Errcr program •
Node Abnormal Condition Frogram (NACP)
Node Error Program (NEP)
Message Logging.
Security Design.
CICS/VS Operator Security.
Security Enhancements.
Operator Error statistics.
Priority processing.
Task priority.
Change Priority.
.
.
'
35
37
37
38
39
40
41
41
42
42
42
43
44
45
45
52
53
54
56
57
57
58
58
61
66
70
72
73
73
74
75
75
76
77
77
78
78
79
81
83
83
60
85
Chapter 4. CICS/VS Data Management Design •
Application Requirements •
Work File Capability •
CICS/VS Temporary storage Management •
Temporary storage Usage.
Data Identification.
Use of Dynamic storage by Temporary storage.
Accessing Records in Temporary Storage •
Temporary storage Recovery •
Selection of Temporary Storage or Transaction Work Area.
CICS/VS Transient Data •
Transient Data Usage •
Extrapartition Transient Data.
Intrapartiticn Transient Data.
Intrapartition Queue Usage •
Reusable Intrapartition Queues •
Indirect Destinations.
87
87
87
88
88
89
91
91
92
93
94
94
95
97
98
105
106
Chapter 5. CICS/VS Data BasE Design •
Application Requirements of Data Bases •
Data Base Definition •
111
112
112
Contents
v
Manufacturing Industry •
Banking Industry
Insurance Industry •
Medical Industry •
Pharmaceutical Industry.
Distribution Industry.
Law Enforcement Industry •
utilities Industry
Data Base Implementation for Applications.
Data Base Support for CICS/VS.
CICS/VS File Control (151M, DAM, VSA~)
Direct Access.
Sequential Access (Browsing)
Record Identification.
Indirect Access.
Segmented Records.
Advantages of segmented Records.
CICS/VS File control Design Considerations •
Recovery Considerations.
DL/I Products.
DL/I ENTRY
DL/I DOS/VS.
IMS/VS OL/I.
DL/I Access from CICS/VS
Introduction to DL/I •
Advantages of DL/I •
Segment Design •
Data Independence.
Logical Data structures.
Data Base Access Calls •
Data Base Organization and Access !ethods.
Logical structure Design •
Updates, Additions, and Deletions.
Logical Relationships.
secondary Indexing •
Data Base utilities.
Data Base Recovery •
DL/I Log •
DL/I Data Base Design.
Data Base Selecticn Criteria •
114
115
117
118
119
120
121
123
124
126
127
127
135
1,40
144
153
165
166
167
168
168
169
169
169
169
173
174
176
177
180
181
182
186
187
189
190
190
191
192
192
Chapter 6. CICS/VS Advanced Features.
Task Control •
Interval Control •
197
197
198
Chapter 7. CICS/VS Perforaance Considerations.
Design Criteria.
Application Design •
Message Design
Program Design •
Data Base Design •
Dynamic storage.
Multitasking •
Priority processing.
System Administration functions.
CICS/DOS/VS Subset Option.
•
Virtual. storage considerations •
•
CICS/OS/VS - 3850 Mass Storage S:ystem Operation.
Performance Evaluation •
201
201
201
201
201
202
202
203
204
205
208
208
215
219
Chapter S:.
Recovery
Recovery
Recovery
Recovery
221
221
222
223
223
vi
CICS/VS Recovery and Restart •
and Restart Overview.
from Prcgraa Errors and lbends.
from Terminal I/O Errors.
from Disk I/O Errors.
CICS/VS System Application Design Guide
•
Recovery froll Device Failure • • •
• •
Termination of CICS/VS System. • • • •
• •
Reestablishment of CICS/VS System.
• •
Temporary storage Recovery • • • •
• •
Transient Data Recovery. • • • • • • • • • • • • • • •
• •
Recording CICS/VS File Centrol Data Set Modifications.
• •
CICS/VS File Centrol Data set Backout.
• •
Transaction Restart on System Restart.
• •
System Recovery prcgrall (SBP). • • • •
• • • •
• •
Program Check Interception in SRP. •
• •
CICS/VS partition/Region ABEND •
• •
System Recovery Table. • • • • •
• • • • • •
Frogram Control ABEND Reguests •
• •
Program-Level ABEND Exit Routine
• •
Program Error program. • • •
• •
PCT/PPT Disable and Enable •
• •
Dynamic Task Backout • • • •
• •
Program Eackup • • • • • • • • • • •
• •
Dump Data Set. • • • • • • • • •
• •
Online program Maintenance • • • • •
• • • •
• •
Keypointing of CICS/VS • • • •
• •
System Warm Keypcints. • • • • • • •
• •
System Activity Keypoints. •
• • • • •
• •
Logical Task Synchronization
• • • •
• •
Protected Resources.
• •
Protected ftessages • • •
• • • •
• • • •
CICS/VS Termination. • • •
• • • •
• •
Controlled Shutdown. •
• • • •
• • • •
• •
Abnormal Terllination •
• • • •
• •
Uncontrolled Shutdown. •
•
CICS/VS Initialization •
• • • • •
• • •
• •
Complete Cold Start.
• • • •
• •
Complete Warm Start. • • • •
• • • • • •
• •
Partial Warm Start •
• • • •
• •
Emergency Restart. • • • • • •
System Failure during Emergency Restart.
• •
Data Base Recovery • • • • • • • •
• •
CICS/VS File control Recovery. • • • • • •
• •
Read-Only Data Sets. • • • • • • • • • •
• •
Update, Deletion, and Addition to Data Sets.
• •••••
Journaling • • • • • • • • • • •
• •
Preparation of User Journals • •
• • • • • •
Data Set Backout • • • • • • •
••
Online DL/I Data Base Backout. • •
• •
DL/I Logging Using CICS/VS System Log. • • • • •
• •
• •
DL/I Termination Activity. • • • • • • •
DL/I Data Base Backout Druing CICS/VS Emergency Restart. • •
Online DL/I ENTRY Data Base Eackout Technique. • • •
• •
DL/I ENTRY Segment Scheduling • • • • • • • • • • • • • • • •
Temporary Storage Recovery • • • •.• • • • • • • • • • • • • •
Temporary Storage Recovery after Ccntrolled shutdown • • • •
Temporary Storage Recovery after Uncontrolled Shutdown • • •
User Recovery of Temporary Storage Using Dynamic storage • •
Transient Data Recovery. • •
• • • • • • •
• •
Intrapartition Data Set Recovery after Controlled
Shutdown. • • • • • •• • • • •
• • • • • • •
•
Intrapartition Data Set Recovery after Uncontrolled
Shutdown. • • • • • • • ••.• •
• ••
• •
Extrapartition Data Set Becovery
• •
Use of Journal Contrel for Seguential Data Sets.
• •
Indirect Destinations. • • • •
DUllp Data Set Recovery • • • • • • • •
•
crcs/vs Program Library Recovery • • •
•
Transaction Recovery and Restart • • • • • • • • •
Recovery of ftessages Associated with VTAft Terainals.
• •
Contents
223
223
224
224
225
225
225
226
228
228
229
229
230
230
231
233
233
235
236
237
237
238
238
239
240
242
244
244
245
246
247
247
247
247
248
255
256
256
257
257
258
260
261
264
264
264
264
265
265
266
266
267
267
269
269
270
271
276
278
278
279
279
279
vii
Recovery of Messages Associated with BTAM Terminals.
Transaction Restart (BTAM and VTAM Terminals).
Terminal Operator Restart.
Terminal Error Recovery.
Terminal Backup.
Terminal Reconfiguration
Device Recovery.
Extrapartition Device Failure.
Batch DL/I Data Base REcovEry.
Batch DL/I System Log.
DL/I REcovery utilities.
Backup Design.
Backup Procedures.
Fallback DEsign.
cutover Design •
280
282
• 282
283
283
283
284
285
285
286
287
289
290
290
290
Chapter 9. CICS/VS Testing and Integration.
Tracing and Debugging.
single-Thread Testing.
Multithread Testing.
System 'Test.
Topdown Testing.
293
293
294
295
295
295
Chapter 10. CICS/VS Cutover and Fellow Up •
cutover.
Terminal Operator Training •
Master Terminal Operator Training.
System Operator Training •
Followu'P •
297
297
297
298
298
298
Chapter 11. CICS/VS Application Design.
Manufacturing Industry •
Production Order and status Reporting System
Data Sets.
Onlinl9 Programs.
Offline programs •
Data Base Support Selection.
Banking Industry
Savings Bank and MortgagE Loan System.
Data Sets.
Onlinl9 Programs.
Offliine programs
custome:r Informaticn System (Customer Inf()rmation File).
Data sets.
Onlin 9 Programs.
DataBase Support Selection.
Insurance Industry •
Policy Information System.
Data Sets.
Online Programs.
New-Business Policy Entry System
Data sets.
Onlin,e Programs.
Data 'Base Support Selection.
Medical Industry •
Patient Information SystEm •
Data Sets.
Onlin 9 Programs.
Data Base Support Selection.
Pharmaceutical Industry.
Pharmaceutical Order Entry System.
Data Sets.
Online Programs.
Offline Programs •
Data Base Support Selection.
l
l
viii
CICS/VS System Application Design Guide
301
301
302
303
• 304
304
305
307
307
309
310
313
314
315
316
317
319
319
321
323
324
325
326
326
328
329
330
330
331
333
333
334
336
337
• 337
Distritution Industry.
Order Entry and Invoicing System
Data Sets.
Online Programs.
Retail Store System.
Data Base Support Selection.
Law Enforcement Industry •
Police Information Systeu.
Data Sets.
Online Programs.
Data Base Support Selection.
utilities Industry
Customer Infcrmation System.
Data Sets.
Online Programs.
Data Base Support Selection.
338
338
339
341
342
343
343
343
345
345
347
348
348
349
351
352
contents
ix
This chapter presents an cverview of CICS/VS system design, and
introduces inforaaticn ccvered in more detail in later chapters of this
publication.
The installation of an online system involves a number of activities.
These include, but are not limited to:
• Feasibility study
• System design of online applications
• Application programming
• Program testing
• Documentation
• System testing
• Training
• Installation of equipment
• cutover to online application
• Follcwup of system
The purpose of this publicaticn is to discuss only one activity of
those detailed atove, namely, ~~!!§~§ De§ig~ ~! ~~l!»§ !EEli~1!2D§'
because of the effect of system design on the overall success or failure
of the installation. O~line system design is presented in the same
sequence as would be covered in real-life. The various factors to
consider during each steF of the design process are identified in terms
of the application requirements. some design factors and application
requirements are satisfied by ClCS/VS-provided support. These
facilities are explicitly defined and identified.
Many applications will not require additional user-developed support
beyond that provided by ClCS/VS. However, online applications may
exhibit unique requirements, for example, high online system
availability beyond the standard provided by CICS/VS. This publication
presents these additional sUFPort requirements, eutlines suggested
design solutions, and discusses some of the Fotential preblem areas
that should be ccnsidered by the user.
To utilize ClCS/VS facilities efficiently and satisfy various design
requirements, it is important that the system designer be aware of the
manner in which ClCS/VS iaplements these facilities. Thisinformation
is presented at the conceptual level, assuming there is no prior
knowledge beyond that covered in the ~I&~L!~ §~p~rA! lD!2I!sti2D Manual.
More detail can also be obtained, if necessary, ty referring to other
CICS/VS documentation.
Chapter 1.
Introducticn to Online systems Design
1
The design of any system, whether it be a batch processing system
or an online system, is a cCRFlex and involved procedure. A "cookbook"
approach to system design cannot be followed because of the variety of
ways the same application may be igplemented in different organizations.
Eowever, guidelines can te reccmaended which direct the designer to
consider those functions or requirements which exist in the design of
most online systems.
TURNAROUND OR RESPONSE TIME
The effect of poor system design in a batch processing environment
increases the tctal ~rocessing time of applications, with consequent
delays in turnaround time befcre results of that processing are
available. with an infreguently run batch application, the effect of
poor system design on the installaticn may not be great. However, with
frequently run batch processing aF~lications, poor system design and
long run times may impact the ability of the installation to provide
adequate turnaround for that and other applicaticns. This will Frobably
necessitate a change in the system design of the offending application.
In an online environment, the effect of poor system design is often
immediately apparent, generally through the cnline system providing
unacceptable response tiaes for the Farticular applications concerned.
The definition of an "acceptable resFonse time" is generally very
application-dependent. Fer exam~le, in an online order entry
application, where the terminal cperator takes an order from a customer
directly over the teleFhcne, any response time that keeps that customer
waiting unnecessarily can be regarded as unacceptable.
WITHOUT DOUET, THE SINGlE MOST I8FOETANT FACTOR IN ONLINE PERFORMANCE
IS TEE SYSTEM DESIGN OF THE CNLIN! AFPLICATICNS~
USER ACClPTANCE
A factor that can affect the acceFtability of an online application
is the way in whjch it aeets the needs of the users of that application.
It is pointless for the user to design a system that provides fast
response time if the information provided cannot be used. In this
regard, measured by the usability of the system, an unusable system is
thereforE! a "poor performance" system.
RESOURCE UTILIZATION
A final factor to consider is the utilization ef resources such as
the CPU Frccessing capability, CFU storage, and inFut/outFut devices.
An onlinE: system which unnecessarily uses so much CPU processing
capability, or storage, or so many input/output devices that it impacts
the ability cf the installaticn to carry out other processing in other
partitions or regions may be a "~oor performance" system.
Thus, poor system design can have a significant impact on:
• Custcmer
ser~ice
(because of Fcor response time)
• Application usability
• Installation processing caFatility
2
CICS/VS System/Application Iesign Guide
Once the system designer realizes that poor design can result in
the opposite of the desired cbjectives being met, he is well on the
way to producing a well designed system.
Generally, online systems cannot be designed in isolaticn. To ensure
that the foregoing objectives are Det, it is important that a design
grcuF comprise people with kncwledge of:
• Application reguire.ents
• CICS/VS facilities
• Installation reguirements
Usually, the optimum size for the design grouF is three or four.
Fewer than this number increases the probability that bad design
decisions can slip through, while many more than four may affect the
productivity of the design group as a whole.
The system design phase is an iterative process. Based on the
decisions taken at one stage of the design, it may be necessary to
change decisions which were Dade earlier in another area of the design.
This change may in turn affect other decisions. Thus, the design group
must be flexible in its aFFrcach and be prepared during the design
phase to change its decisicns if necessary. However, once the system
design has been completed, it should bE frozen at that point, and not
changed unless serious errors or omissions are found which will affect
the ability of the system to run effectively.
During implementaticn of the design, there is always the temptation
to incorForate improvements from an application point of view. While
each improvement may not represent a great deal cf extra implementation
effort, all ef these impreve.ents Day affect the project completion
date. Also, the effect of these iDprovements on the overall system
performance must be evaluated. The danger is that this evaluation may
not be carried out for those changes introduced after the system design
phase has been ccmpleted.
These changes or enhancements must be controlled. The best way of
achieving this ccntrol may bE to incorporate all of these enhancements
in a later versicn of the cnline aFplication or system. These
enhancements beccme a project in their own right, and must therefore
go through the system design phase befcre implementation. In this way
their effect on system performance can be readily evaluated.
A structured approach to system design is possible, and such a
structurEd approach should direct the design group to consider all of
those areas of the online system which may require decisions to be
taken. This structured desigD apFroach is ill~strated in Figure 1-1.
This figure also illustrates some of the topics Fresented in this
publication, and the description cf each topic following the figure
Frovides an overview of this publication.
STRUCTURED SYSTE! DESIG6
A~~li~s!iQn ~~§igB
The starting point for online system design is the application
design. The initial application design steps require that the
objectives to be achieved by an cnline application be defined and the
Chapter 1.
Introducticn to Online systems Design
3
requirements of the users of that apFlication be identified. A broad
system flow of the 8Fplicaticn is then developed as part of the initial
design. 'fhis system. flew and apFlication design are an extremely
important part o~ the overall design process, since thEY define the
interface between the ter.inal use]: and the computer. Unless the online
application meets the require.ents of its users, it is destined to
fail.
The online application shculd te designed initially to identify the
broad inFut, processing, and outFut requirements ef the application.
The need for conversational and/er batch data transmission between the
terminals and the CPU can be identified. the terminal outFut
requirements of the application can be determined, after which the
broad processing logic and data set accessing necessary to produce that
output can be designed. At this stage, the input data required for
that processing and output can also be defined.
Applicati(
Design
I
Data
Communication
Design
I
I
Recovery
And Resta
Design
Data Base
Design
I
Data
Management
Design
Program
Design
.L
I .m.,,,,,y
T
Storage
Figure 1-1.
I
I
Transient
Data
~
/1
EN TRY
DL/I
Products
File
Control
DL/I
DOSIVS
DL/I
IMSIVS
structured Systems tesign
The result of this apFlication design phase is a broad system
flowchart shOVing, in aPF1ication terms only, the flow of information
to and from terminals, the bread Frocessing te be carried out by the
CPU, and the file accessing necessary to allow that processing. ligures
1~2 and 1-3 illustrate two types of flcvcharts, bcth representing the
system flow of an Order Entry a~d Invoicing application in the
Distribution industry.
With the troad application design mapped out, design of transactions
to be initiated from terainals and the responses tc be sent back to
the terainals can be developed. Alec, during this phase the editing
and validation of input messages can be defined in more detail.
Consideration should be given to the design of security procedures
and the handling of high pricrity transactions. The effect of
4
CICS/VS System/Application tesign Guide
unrecoverable terminal and line errors should be considered, together
with approaches which may be used to provide a co •• unications backup
capability (if required) to enable the online applications to continue
to function, if possible, in the event of a co •• unjcations equipment
lIIalfunction.
After determining systelll flow and broad processing to be carried
out by the CPU, this processing sheuld now be trcken down into
particular functions. Par exaaple, the initial function on receiving
a terminal transaction weuld be that of editing or validation.
APPLICATION PROCESSING
1. Access Customer Record.
2. Display Name and Address.
3. Generate Order-In-Progress
Data Set.
4. Access Product Record.
5. Update Order-In-Progress
Record.
6. Display Order Quantity
Accepted.
7. Record Back Order Quantity,
If Necessary.
B. Update Product Inventory
With Accepted Quantity.
9. Access Order-In-Progress
Data Set.
10. Place In Warehouse Location
Sequence.
11. Transmit Packing Slip.
12. Extend Invoice.
13. Transmit Invoice.
14. Access Product Record.
15. Update Product Inventory
With Received Quantity.
Figure 1-2.
Order Entry atd Invoicing Function tiagram
Chapter 1.
Introduction to Online Systeas Design
5
This validation may require access tc various data sets. Following
validation~ it may be necessary to retrieve information from other data
sets fer processing, follcwed by possible updating of those data sets.
Finally, it would te necessary tc Frepare a respense to te sent to the
terminal.
The processing for each type ef transaction in the apFlication should
te broken down into logical secticns in this Danner. These logical
sections may subsequently tecome separate CICS/VS application program
modules, or can te incorForated into one module. Figure 1-q illustrates
the various modules in the program design for the Order Entry and
Invoicing applicatien shewn in Figures 1-2 and 1-3.
Note that the separate prcgrams and broad processing required,
developed in Figure 1-4 from the flowchart in Figure 1-3, are described
as part of the function diagram in Figure 1-2. In effect, the first
three boxes in Figure 1-2 define the three separate programs in Figure
1-4.
A point to consider when defining program modules is the frequency
of use of different modules. For ExamFle, excepticn routines cr error
routines which are infrequently used should teo separated from the more
frequently used main processing modules. In this way Frogram design
and subsequent iuplementation will be able tc take best advantage of
the dynamic storage capatilitie~ of CICS/VS and the virtual storage
capatilities of DOS/VS, CS/VS1~ or CS/VS2.
Application ~rograms can te ceded in Assembler Language, INS COBOL,
or PL/I. The user can select the most appropriate language for ea~h
program. Prcgrams written in one language can pass control to programs
written in any other language.
Application requirements for thE temporary storage of information
and the gueuing cf inforDaticn should te defined. CICS/VS Temporary
storage management provides a "scratchpad" capability and allows
information to te stored temlorarily in main storage or, alternatively,
on secondary storage.
The queuing, or sequential data set requirements, of the application
can te defined. The need to pass information through sequential files
to and from the CICS/VS partition and other batch Fartitions or regions
using the CICS/VS Transient Data management facility can also be
determined, together with tread recovery procedures.
The nEed for the application Frcgrams to pass small seguential queues·
of information between eaoh ether in the CICS/VS partition using CICS/VS
Transient Data can be determined.
Particular application data baSE characteristics and requirements
are considered when selecting the best data base support. This can be
based on CICS/VS File Control facilities or on one of the DL/I products.
6
CICS/VS system/Application Iesign Guide
DESCRIPTION
SYSTEM FLOW
Order Entry
Order Entry
Enter customer number and customer reference number.
Customer
Data Set
Edit
Customer
Details
Validate customer number and extract credit limit.
If an error is found, display error message back at terminal.
Display customer name, address, ship-to-address and credit limit.
Enter product number and quantity for each line item.
Edit Check
Stock Avail.
And Update
Validate product number against product data set. Determine
current stock availability, and update product data set.
If insufficient stock, indicate quantity on-hand. Then allow operator
to either order available quantity, cancel item, or cancel order;
If not end of order, read next line item from order terminal.
Sequence products in order to warehouse loacation sequence. Extend
invoice. Write order to orders data set.
Orders
Data Set
Place In Whse
Location
Seq & Entend
Invoice
Transmit packing slip ans invoice to terminal in warehouse.
End Of Order
Figure 1-3.
Packing
Slip
Order Entry aDd InvciciDg Flowchart
Chapter 1.
Introducticn to Online Systems Design
7
SYSTEM FLOW
PROGRAM
ORDER ENTRY
ORDER START PROGRAM
(
~:a,t_o_; _;_r_- Ji
Accept customer details and edit to
commence order.
Edit
Customer
Details
Order
Start
Program
ORDER DETAI L PROGRAM
Accept product order, edit, and update
product data set.
Edit Check
Stock Avail.
And Update
Order
Detail
Program
ORDER FINISH PROGRAM
Orders
Data Set
Place In Whse
Location
Seq & Extend
Invoice
Invoice
Complete order, put orders* in
warehouse location sequence, extend
invoice, log order to orders data set
for audit, and transmit packing slip
and invoice to warehouse printer.
Order
Finish
Program
*Note: Standard batch sort is not used; products
are placed in location slots in storage
table, to carry out sequencing,
Packing
Slip
Figure 1--4.
8
Order Entry aId Invcicing Program Design
CICS/VS Syste8/Application Cesi9D Guide
Factors to be considered in this decision include the need to access
the data base from both online a.~~lication prograas and batch processing
programs, and the number cf ways in which infcrmation is to be
retrieved, such as by the use of different record keys (for example,
part numter or part name in an inventory control applicaticn). Further
factors in this decision are the numter of times certain information
occurs in each rEcord, and the a.cunt cf information which may be absent
in seme records, yet present in ethers.
After selecting the a~proIriate data base sup~crt, the structure of
the data base is designed, and hew that data can te retrieved from
application programs is defined. Figure 1-5 shows the design of a DL/I
logical structure fer the Crder Entry application discussed above.
(This logical structure is diSCUSSEd in "Distribution Industry" in
Chapter 11.)
The effect of various errer or system failure situations on the
integrity of the data base is considered, and a data base recovery and
backup aFproach (if required) is defined.
I
I
ITEM
~
CONTAINS - ITEM NUM BER
- ITEM NAM E
---
I
I
WAREHOUSE
INFORMATION
I
-
SUPPLIER
~
~
CONTAINS
CONTAINS
CONTAINS
-
- WAREHOUSE NO.
NO. OF ITEMS IN STOCK
• STOCK LOCATION
• REORDER POINT
- SUPPLIER NO.
PRICE PER UNIT (PURCHASE)
UNIT OF ITEM
DELIVERY TIME
• QUALITY INDEX
• DELIVERY INDEX
• PURCHASE Y.T.D.
SUPPLIER INFORMATION
PRICE PER UNIT (SALES)
DATE OF LAST CHANGE
UNIT OF ITEM
TURNOVER LAST YEAR
TURNOVER Y.T.D.
o
o
o
o
o
Figure 1-5.
Order Entry Application Data Base Design
R~~12~!~D~~ ~~§ig!~g!i~n§
The designed system is starting te take shape. The extent to which
the application objectives and rEquirements are ~et by the designed
system must be evaluated. The petential Ferformance of the system must
be evaluated to identify areas where improvement can be made if
necessary.
Chapter 1.
Introduction to Online Systems Design
9
Performance evaluation may include one, or both, of:
• Simulation techniques
• Benchmark technigues
Based on this performance evaluaticn, changes in the system design
may be considered, with possible iteration through the above steps.
1§£Ql§I~ ~nd ~~§!jI!
The success of an online system is dependent cn its availability.
Procedures must te designed fcr tackup in the event of failure of
varicus components of the system, and for recovery and restart following
abnormal termination of the system.
I.§stin,g j!1l9 lJl!§.9IJ!i2Jl
The a~ount and ty~e of testing to be carried out should be broadly
defined as part of system design, together with the way in which the
varieus online a~plications are tc be integrated.
of
in
to
to
It is important to define the procedures to be followed fer training
terminal operators, system administrators, and all personnel involved
the cutover and subseguent operation of the system. The procedures
be used for cutover Dust be fully defined to ensure smooth transition
the new online system.
The logical starting ~oint for online system design is the broad
system flow design of the applications to be implemented. In the normal
design phase of an online system, the design team would com.ence with
application design. However, 'in the presentation of topics in this
publication, application design will be left until the various CICS/VS
facilities and design techniques have been discussed. In this way,
application design in a number of industries can te described more
effectively, indicating hew specific CICS/VS facilities can be utilized
for different applications. Using these application design gUidelines,
the design team may wish te use the larious techniques described as a
starting point for their own applications. The apFlications discussed
in Chapter 11 of this publication are those introduced in the
"ftanagement Overview" section of tlbe ~E~Ll~ §§nUY Inf2.LU!i!;U! l!AW!al
(GIft). The applications described in the GIft are:
•
Jj!nYiJ~!Y'iD9 1Jlgj§!'~
- Production Order and Status Reporting System
• J§Dk!ng
l~g~!,~
- Savings Eank and !ortgage Loan System
- Customer Infermation System (often called
customer Information Pile)
•
10
lli~JD~§ lDgj~!.~
- policy Information System
- New-Business Policy Entry System
CICS/VS System/Application Design Guide
•
l!gi~gl l~g~§!.l
•
RbgImg~§y!icgl
•
~§~ j~!~.~§!~~! l»g~!~l
•
~i§!.i~]!iQn lng]§!~~
•
~!iliti~§
- Patient Informaticn System
lDg]§SII
- Pharmaceutical Crder Entry System
- Police Information System
- Order Entry aId Invoicing System
lng]stIl
- Customer Infcrmaticn System
The reader may wish to refer to these application descriptions from
time to time as he reads this ~~~Ll~ ~1§!§!LjRR1!£!ti2n n§§ign gyid~.
Deferring the applicaticn design now until Chapter 11 in this
publication. the next design topic is that of Prcgram Design.
Chapter 1.
Introducticn to Online Systems Design
11
CHAPTER
1.
CICS/VS PROGRAM DESIGN
Chapter 2 presents Program Design in a tutorial manner. Experienced
CICS users may wish to omit most of this chapter. However, it is
strongly recommended that such users still read the following topics:
• CICS/OOS/vS Subset option
• Virtual Storage Environment
• Tabular structures
• structured Programming
• Application Built-in Functions
• Program Error Recovery
CICS/VS is a transaction-oriented DB/DC system which uses the
techniques of:
• Multitasking
• Quasi-reentrant programming
• Dynamic storage allocation
These techniques are described in the CICS/VS General Information
Manual. The design of applicaticn programs to take advantage of them
for efficient online operation will now be discussed.
In this
discussion, the facilities available to the system design team are
outlined first, followed by a discussion of the various program services
provided by CICS/vS. The design facilities available for use are:
• CICS/DOS/vS Subset Option
• Modular programming
• High-level languages
• Tabular structures
• structured programming
• Application functions
CICS/DOS/VS SUBSET OPTION
Facilities are provided to generate a subset of CICS/DOS/VS for new
CICS/DOS/vS users. It is easy to install and is fully compatible with
the complete CICS/DOS/VS system. No changes need be made to application
programs when the user generates a complete CICS/DOS/VS system. The
subset option identifiesCICS/VS facilities which may be utilized by
a CICS/VS user with limited CPU Storage. See "CICS/DOS/VS Subset
Option" in Chapter 7 for additional information.
Chapter 2.
CICS/VS Program Design
13
CICS/DOS/VS STARTER SYSTEM
A set of object modules, generated using the subset option of
CICS/DOS.fVS, is supplied with the CICS/DOS/VS system. The starter
system includes precompiled sample application programs and predefined
tables, and need only be link-edited into a OOS/VS core image library
before UBe.
INSTALLA~rION
AND USE
The UBer can install the Fregenerated CICS/DOS/VS system as described
above, and expand it as his needs dictate. CICS/VS facilities which
are not part of the subset oFtion can be generated when required to
support advanced CICS/VS capabilities. These can be achieved by
regenera 1t:.ing only those CICS/vS management modules and table options
required to support the advanced capabilities.
The subset option is described in the Subset User's Guide (OOS)
SH 12-540 I~.
MODULAR JROGRAMMING
BATCH ENVIRONMENT
Moduliir programming techniques in a batch environment may involve
the consolidation of similar progI.·am functions in one program module.
For example, the main execution code used may be incorporated in one
module, '~hile exception rout ines may be in another modul e and error
routines in other modules. In this way, modular programming enables
sections of the program to be written by programmers at different times.
Apart from the advantage of distributing the program workload across
several people, another advantage of modular programming is that it
generally makes the application program logically easier to follow for
someone '~ho is unfamiliar with it.
CICS/vS ONLINE ENVIRONMENT
CICS/VS is oriented around the concept of modular programming.
Transactions received from terminals are analogous to transaction cards
read froIn a card reader. A transaction code defines the format and
processing required for an online transaction, in the same manner as
a card code defines the format and processing of a card.
This 1:ransaction code identifies the CICS/VS application program
that will process the transaction. The use of such modular programming
techniquE~s is an integral part of CICS/vS and enables large programs
to be broken into smaller logical modules. However, program size and
CICS/vS address space availability should be balanced with the
additional overheads involved in passing control between many small
modules.
When a transaction is received from a terminal, only that program
code relE~vant to the processing of that transaction need be loaded into
storage, if it is not already present. As modules tend to be smaller
than complete programs, more application program modules may reside in
a given address space than may full programs. This enables one copy
of each of many different modules to be currently resident in the
CICS/VS dynamic storage area. A high degree of multitasking may
thereforE~ be achieved within a limited storage size.
'4
CICS/vS System/Applica tion Design Guide
VIRTUAL STORAGE ENVIEONMENi
using the modular programming techniques discussed above, a CICS/VS
application program .odule should include code which is relevant to
the processing of the specific transaction.
From the system design point of view, the design team should specify
the various application Frograms which are to be written to implement
the particular aFplicaticn. They should also idEntify th6se application
functions (and hence program coding) which willke frequently used by
transactions, and those which will be infrequently used. In this way,
the design team is able tc broadly specify the modular program structure
of the application, and define the necessary application programs.
The various aFplicaticn programs executing concurrently in the
CICS/VS partition, and the demands made by them for CICS/VS servicEs
and resources, ccntribute to the total "working set" of CICS/VS. This
term is used in a virtual stcrage environment to describe that part of
a program which is active over a specific period of time. The CICS/VS
working set is influenced hy the sizes of the various concurrently
executing application prcgrams, the online transaction load and its
use of various application prcgrams, and the degree of multitasking
permitted by the CICS/VS master terminal operator. Techniques for
varying the working set are discussed in "CICS/VS Working Set" in
Chapter 7.
CICS/VS accepts applicaticn programs written in Assembler Language,
American National Standard (ANS) COBOL, or PL/I OptimiziDg CODFiler
for DOS/VS, OS/VS1, or OS/VS2. In addition, application programs may
be compiled with the PL/I F compiler for OS/VS1 cr OS/VS2.
CICS/VS is basically table driven. Tables define the terminal
network configuration, data set and data hase specifications, online
transaction details, application programs, and output message
destination information. Since CICS/VS is written as a generalized
program and is table-oriented, the unique requirements of an
installation can be tailored by sFecifying thcse requirements in the
various CICS/VS tables. CICS/VS uses the tabular information in a
direct manner to cODFlete the particular functions required. In the
event of the installation characteristics changing (such as the addition
of more terminals, or extra data sets for example), that change in the
installation require.ents can be incorporated into the system by
modifying and reassembling the relevant tables.
The tabular structure of CICS/VS is one of the main factors which
enables fast implementation and easy installation growth--two of the
significant advantages of CICS/VS.
This same tabular structure concept can be extended to application
programs. An example of a tabular structure application is a savings
hank and mortgage lean system in the banking industry. Figure 11-7
illustrates a typical savings bank and mortgage loan system.
This application is characterized by a large nu.ber of transaction
types with similar transacticn fcrmats, similar processing, and similar
output formats. certainly, unique modules may be written to accept
each different transacticn, process that ~nformation, and send back an
output response. However, the overall IC9ic in the separate aodules
is basically identical, with differences appearing only in the
Chapter 2.
CICS/VS Frogram Design
15
particular input and output formats. In some caSES certain information
is processed by addition (a deposit transaction amount to be added to
the current balance), and in ether cases by subtraction (a withdrawal
transaction amount to be subtracted frcm the current balance). It is
expensive in the initial a~plicaticn programming and subsequent
maintenance to write separate programs for these various similar
transactions.
In this banking application, a generalized application program may
be written utilizing a tabular structure. A numter of application
tables wculd be requ~red in this environment. These are illustrated
in Pigure 2-1, and are listed and discussed below:
• Input format table
• Processing rEquirements table
• Output format tatle
Alternatively, the information described in these tables may be
consolidated into one cCB~csite table.
On receipt of a transactien from a terminal, that transaction type
(Bank Trancode) may be identified in the input fermat table. switches
in this tablE specify the locaticn of information within the
transaction. This informaticn is used together with information
obtained from the precessing requirements table which is also accessed
based on the transaction type (Bank Trancode). Fer that transaction
type, the processing require.ents tatle entry may indicate certain
fields of the transactien are to be edited based u~on specific editing
criteria, and fiElds are tc be added to or subtracted froa specific
applicaticn counters.
Based on the particular transaction type, the relevant entry in the
output format tatle may specify the Exact locatien in the eutput message
into which certain fields are to be inserted. Besponses may then be
sent back to the terminal to update the custome~'s bank passbook based
upon the particular input transactien entered.
Use of tabular structurES results in less programming effort. Only
one generalized application ~rogram is written, determining the editing
and processing required cf transactiens by means of various switches
in the relevant tables.
However, the power of this pregram design approach beco.es more
apparent when it is necessarl to mcdify the application req~irements.
Typically such application modification may require considerable
recoding and testing if a tabular structure is not used. In this
environment, the relevant tatle Entry may be quickly and easily changed
to reflect a changed input fermat, changed processing requirements, or
a changed output format. In many cases, no modification of the generalized application Frogram is rEquired.
The net effect is greater resFonsiveness to the application needs
of user departments, as well as the needs of the ccmpany's customers.
The IBft 3600 Finance Communication System, a banking system, consists
of an IBft 3601 programmatle controller and several terminals. Some of
the functions perfcrmed ty the previeusly descrited tables may be
executed in the 3601 contrcller. For example, the terminal input
message Day be cenverted to a standard format input message by the 3601
controller for transmission to CICS/VS with precessing requirement
switches inccrporatEd in the input message. Similarly, a standard
format output response may be transmitted by CICS/VS back to the
16
CICS/VS System/Application DeSign Guide
controller, which performs any uniquE foraatting ~Equi~ed by the
response and transmits it to the c~iginating terminal.
APPLICATION PROGRAM PROCESSING
INPUT
I~
:':~:nal I
L-..L..-_----"-...>
Input Format Table
Bank TRANCODE
---Input
Format
Specifications
r--..-----..........
>
"..--~_---,..,........>
Processing
Requirements
Table
>
L-...I-_ _.........
Bank TRANCODE
Processing
Specifications
.---.-__.........>
Output Format Table
>
Bank TRANCODE
Output
Format
Specifications
>
.---.-----,.v""
OUTPUT
1. Receive input message from teller
terminal.
2. Use banking trancode in message to
locate entry in input format table.
1 I
3. Format input message based on input
format table specs.
4. Use banking trancode to locate entry
in processing re·Quirements table.
Amount MiSC·1
1<
5. Process input message based on pro·
cessing table specs.
6. Using banking TRANCODE to locate entry
in output format table.
7. Prepare output message based on
output table specs.
~~n~~l
Update
Banking
Data Sets
>
(
1<
-"'-> ~~dit Il
L-...L._ _
no
8. Transmit output message to teller
terminal.
Is
Date Illcode
18'1
I;] Amount
181
Irll l Bal·l
161 91 arlce
Teller
Terminal
Passbook
Figure 2-1.
Tabular Program structure in Banking
Using this aPFroach, the tabular structure concept described in
Figu~e 2-1 can also te aFplied tc the application programming performed
in the 3601. The functicns cutlined in steps 1 through 4 and 6 through
8 in Figure 2-1 are then executed by the 3601 and only step 5 is
executed by the eIeS/VS apFlication program. See "Virtual
Telecommunications Access !ethod" in Chapter 3 fer additional
information regarding 3600/CICS/VS oFeration.
structured programming is a modular prog~amming technique which has
been developed tc Fermit easier integration cf modules into a working
program. It is sometimes ~eferrEd to as "top-down prograaming," and
provides a useful toel fcr centrel and development of large programming
projects. The fcllowing remarks serve to introduce the concept of
top-down programming.
Chapter 2.
CICS/VS Frogram Design
17
TRADITIONAl FROGEA! DEV!LOFMENT
Traditionally, some programs have been developed from the bottom
up, as illustrated in Figure 2-2. That is to say, each routine or
module has been designed and written, then these Dodules have been
combined, or integrated, tc Froduce a working program. programs at
the lowest level are combined by integrating them with a Frogram at a
higher level, which calls them.
Thus a large program is built up from separate .odules, with the
lowest level of modules combined first, and then the successively higher
levels of modules until eventually the entire prcgram, with all of its
mo~ules, has been integrated.
If thE system design has been well done,
and all of the linkages and interfaces have been fully designed,
documented, and completely adhered to by all programmers, a working
program results.
However, as is often the case, each programmer's understanding of
the way in which his modules fit into the total Frcject may be slightly
different. These differences are cften reflected in errors in the
module interfaces. These errors are not determined until integration
cr system test, and may involve ccnsiderable mcdification to enable
the entire program to be built up.
A further problem that arises with the traditional "bottom up"
develoFment of mcdules is that of testing. To test a lower level
module, a test driver invariably has to be develcped. The function of
this driver is tc present to the .cdule to be tested the same interface
which will be presented ty the higher level module which will eventually
call that lower level Bodule. Thus, the testing of these lower level
modules can require considerable additional work on the part of the
Frogrammer in develoFing test vehicles.
In addition, in testing higher level modules, changes may have to
be made to lower level modulES bEcause of errors identified or interface
Order
Imple~ntation
[
Module
1
Module
2
1
I
Module
7
[
MO~""
I
[
Level*
Module
Module
4
5
I
I
MO~""
Module
8
1
I
[M.'OUO'
Module
Figure 2-2.
18
I
Traditicnal Frogram Develcpment
CICS/VS System/ApFlication Design Guide
* Levell
Level 3
= Highest Level
= Lowest Level
changes. Consequently, the lower level changes must be fully tested
before testing can continue with the higher level module.
TOP-DOWN PROGBAM!ING
Top-dcwn programming a~treaches the problem of program development
in a different way. The highest level module is defined and coded
first, including the necessary linkages to lower level modules.
However, these lower level modules are not developed at this time.
Instead, a general "dumay" test module is used in Flace of the lower
level modules. The high level module links to this test module in
place of lower level modules which are yet to be written. The dummy
test module notes the fact that control was passed to this module from
the higher level module (perhaps by a test output message, or a dump,
for exam~le), and then returns centrol to the higher level module.
It is not until the high level module has been tested that coding
commences on the next lewer Bodules. At this time, the interface
between the higher level and lower level modules has been completely
defined, coded, and tested. Furthermore, the higher level module now
becomes a test driver for thE lower level modules.
As each low level module is ceded, it replaces the common dummy test
module which was used in the higher Rodule testing. When the higher
module passes control to this low level test module, the only functions
which have to be tested are the functiens re~resented by that low level
module.
This testing continues, with trogressively lewer level modules being
integrated into the total trcgraa structure in this way, until the
entire program has been developed and tested. TOF-down programming is
illustrated in Figure 2-3.
A~!A~!AgS§
2!
l~l=~~!~ i's~'!!!i~~
The advantages offered by this technique over traditional "bottom-up"
programming are:
• Chief Programmer Operatien
Top-down programming lends itself to the chief programaer method
of program develepment. This aethod involves an experienced (or
"chief") programmer, who definES the overall logic flow of the
program by developing the highEst level modules, and leaving the
lower level modules to leSS-Experienced prograamers. In this way,
the controlling high· level modules benefit from the skill of the
chief programmer, resulting in better overall control of the total
program develop.ent to ensure that processing objectives and
performance requirements are mEt.
• Module Developuent IndepEndence
Modules can be coded and tested from the highest level down to the
lowest level without consideration for the progress of other modules
at the same level. For exam tIe, developing a Frogram from the
bottom up generally requires all of the lower level modules to be
coded and available before integration with the higher modules can
be achieved.
Chapter 2.
CICS/VS Frogram Design
19
LEVEL*
ORDER
OF
IMPLEMENTATION
Main-line
Module
I
1
Module
1
I
I
Module
Module
2
2
3
I
I
Module
Module
Module
4
5
6
I
I
ij
Module
7
Module
3
8
* Level 1 = Highest Level
Level 3
Figure 2-3.
= Lowest Level
Tcp-Dcwn prcgra. DeveloF.ent
• Bodule Testing Independence
Because higher level modules are coded and tested before lower
level modules, the testing of these lower level modules is not
dependent upon code which may not have been written at that time.
The familiar problem of the testing of the lower level module being
held up because the higher level module which called it (or
alternatively a test driver in its place) was not ready, is now
not !:ignificant •
• EasiEr Evaluation of Testing Progress
The ~rogress of testing can be mcre readily evaluated using the
top-down programming approach. As testing descends to lower level
modules, the probability of errors detected in these lower level
modules affecting already tested higher level modules is much less.
However, with bottom-up frogra.ming, a problem area encountered
during integration fro. lower level modules up to higher level
modules may reguire considerable medification of the lover level
modules to ensure that the interface reguireaents are met.
Furthermore, the amount of testing necessary fer integration or
system test is variable and difficult to predict. All too often,
communication between meabers of a project is such that each
programmer has a slightly different view of the function and
integration of his module into the overall program. This
misunderstanding dces not generally become apparent until testing
and integration are well advanced. lith top-dcwn programming, all
interfaces are fully defined, coded, and tested before coding starts
on lower level modules.
20
eIeS/VS system/Application Design Guide
• Programmer Besource flexitility
with the top-down technique, if a particular program falls behind
schedule, ether Frograaming resources can support the coding of
lower level moduleS while the original program.er continues with
his higher level module.
The system design technique described in this publication is also
a top-down des~gn technique. As shown in Figure 1-1, systems design
occurs at the highest level first by broadly defining the application
requirements in terms of the input, general processing required, and
the output. This highest level application design then allows the
design team to descend to a lower level data com.unication design to
define input and output, program design to define .processing, and data
base design. Furthermore, within these functions are additional levels,
each level taking the design to a greater depth of detail.
The CICS/VS program structure accommodates the top-down programming
technique. A terminal transaction initiates an application program,
which can be regarded as being at the highest level. This program can
utilize a module at a lover level to carry out the necessary editing,
another module tc carry out the processing required by the transaction,
and still ancther to prepare the output response.
Each of these lcwerlevel modules can be written separately, but
does not have to be availatle before testing starts. For example, the
editing 80dule can be tested without the processing or output module
being ready. Instead, du.my mcdules can be used in their places to
indicate that control did pass frOB the higher level module to the
prOCEssing and output modules. In the editing module, control can pass
to lower level modules in the event cf errors. Again, these error
modules are not coded until the editing module has been tested.
In this way, development cf the CICS/VS application program proceeds
from the top down. Top-down programming definitely offers the most
advantages fer ccmplex programs. In this case, the number of functions
to be coded and tested aay be sufficiently coaplex that the development
of the applicaticn program is a aajor task.
Lower level modules need not necessarily te separate CICS/VS
application p-rograms. Instead, the technique of tcp·down programming
can te used in a single CICS/VS application program, with the aain-line
of the program teing the highest level. This may call various
subroutines. These subroutines aay te replaced during testing with a
dummy subroutine to iaplement the top-down approach. An exaaple would
be the use of the PEBPOB! verb in COBOL to execute a number of "dummy"
paragraphs. The actual paragraphs may be incorporated in the program
at a later time, when the main lcgic flow of the program has been fully
tested. This technique allows easier initial testing, without having
to test cut all prcgram logic right from the start of testing.
The use of ctCS/VS as the DB/DC system represents the start of a
top-down program.ing teChnique. CICS/VS is the aain controlling
routine, which in turn calls a number of modules at a lower level--that
is, the application programs.
In designing an online apFlication to execute under control of
CICS/VS, the design team should te aware of those application functions
offered ty CICS/VS. Seme of these are referred to as built-in CICS/VS
Chapter 2.
CICS/VS prograa Design
21
functions, while other functions (such as message routing, terminal
paging, and device independence) use ClCS/VS basic mapping support
(BMS). Consequently, these functiens can only be used with terminals
supported by BMS. These application functions provide the facilities
listed in Figure 2-4. They are summarized here, and described in detail
in Chapter 3 unless stated otherwise.
MESSAGE l;OUTING
CICS/VS provides an cFtio~al aessage routing and broadcasting
capability_ This enables any terminal to transmit messages to other
EMS-supported terminals in the system, either im.ediately, or at some
future time, provided that all affected terminals are of a type
supportecl by basic mapping support. While message routing may have
relevanc~: in specific apFlication design, it is particularly important
in enatling the master terminal cperator, who has the overall
responsibility fer centrel of the enline applications, to communicate
with each terminal operator.
TERMINAL FAGING
The t,:rminal Faging facility cf CICS/VS enables application programs
to develop information to be presented to BMS-supported terminals as
a series of pages. However, the sequence of these pages requested by
the terminal operator is net impcrtant to the application program.
CICS/VS-provided terminal eperatcr commands enable the operator to
reguest the dis~lay of pages in any seguence desired.
r:
L
,--
MESSAJ
ROUTI:J
I:RMINAL
IGING
-
TERMINAL
DEVICE
INDEPENDENCE
SUPPORTED BY
BASIC MAPPING
SUPPORT, FOR USE IN
DATA COMMUNICATION
Figure 2-4.
3210
EXTENDED
SUPPORT
INPUT
FDRMATTING
USED FOR DATA
COMMUNICATION
TABLE
SEARCH
FIELD
VERIFYI
EDIT
BIT
MANIPULATION
USED FOR
PROCESSING
PHONETIC
CONVERSION
WEIGHTED
RETRIEVAL
USED FOR
DATASET
ACCESSING
ATP
USED FOR
BATCH DATA
ENTRY
ClCS/iS Application Euilt-in Functions
TERMINAL DEVICE INDEFENDENCE
CICS/VS terminal device independence enables transactions to be
entered from any BMS-suEFerted terminal type, and Fresents those
transactions to the application Fregram in a standard form. The output
response developed by the apFlica1:ion Fregram can be presented in
standard form to CICS/VS, which then prepares it fer transmission to
22
CleS/VS system/Application Design Guide
the relevant BMS-supported terminal. The application Frogram is
relieved of most consideraticns regarding device-dependent requirements
for terminals. It can accept inFut frcm any BMS-supported terminal in
the network and prepare terminal outFut as a seriEs of lines regardless
of the particular terminal tjFe tc be used.
EXTENDED 3270 SUPPORT
This added support enables the design of input transactions to take
advantage of the 3270 Pregram Attention (PA) or Frogram Function (PF)
keys to initiate transactiens. This enables frequently used
transactions to be initiated by cne key depressicn, instead of the use
of a transaction code which normally is from one to four characters
long.
In addition, a sFecific PA or PF key can be defined as a 3270 PRINT
key. DeFression of this key enables the contents of the 3270 screen
to be printed on the first available printer ide~tified for this
purpose. The 3270 selector light Fen can aleo be used to initiate
transactions.
INFUt FOEMATTING
This CICS/VS built-in function enables infut transactions to be
entered in a variety of formats. They are converted to a standard
format for presentation to aFplicaticn programs fcr processing. This
can enable applicatien Frcgrams tc be developed relatively independent
of the way in which specific transactions are entered at a terminal.
TABLE SEARCH
This built-in function enables a table of infcrmation to be readily
searched to extract the apFrcpriate value from that table based upon
a search argument. The table search can be either a sequential or a
binary search.
FIELD VERIFY/EDIT
Editing macro instructions are Frovided bj this CICS/VS built-in
functicn to enable the ccntents of a field to be examined for:
• All numeric (0 tc 9)
• All alphabetic (A to Z, er blanks)
• All packed decimal (CO~PUTATIONAl-3 in American National Standard
(ANS) COBOL or FIXED tECIMAL in FL/I)
User routines can be e~ecuted in the event that characters other
than those specified for a field are present.
A macro instruction is also provided to edit nonnumeric information
from a field (for e~ample, part number 119-445/B) and present the
remaining numeric characters in EECDIC.
BIT MANIPULATION
The ability to test the status of individual bits, and to turn bits
cn or off, is prcvided thrcugh the use of ClCS/VS macro instructions
for Asse.bler, Pl/I, and CCBCL. This built-in function is especially
Chapter 2.
Cles/VS Program Design
23
useful in COBOL, which does not have a standard bit maniFulation
capability.
PHONETIC CONVERSION
This built-in function enables misspelled names to be used as keys
to access data sets. The name is converted to a standard key based
upon the phonetic sound ef the naDe. For example, the names Smith,
Smyth, Suythe, and Smiths result in the phonetic code S530.
This is particularly useful for identification ef names, such as in
a police inferDaticn system, custcDer information systems in banking,
insurance and medical aFplications, or product names in order entry
applications.
A phonetic conversion subroutine is also Frovided for use by batch
executing in partitions other than the ene containing CICS/VS.
This subroutine can be used for batch programs executed under the
control of DOS/VS, OS/V51, or OS/V52.
~rograms
Refer to "Reccrd Identificaticn" in Chapter 5 fer a more detailed
discussicn of phenetic ccnversion.
WEIGHTED RETRIEVAL
This powertul built-in functien provides ClCS/VS applicaticn programs
with the ability to search part, or all, of a specified VSAM data set,
and retrieve infcrmation fro~ that data set based upon user-specified
selection criteria. Furthermore, records satisfying the criteria are
indicated as relevant only if they fall between user-specified limits.
The records that fall between the specified limits are then presented
to the applicatien Frograw, ~ith these records best satisfying the
criteria presented first, followed by records satisfying the criteria
least.
This function is useful for the design and development of query
applications. Queries can be designed based upon the selection of
information meeting fixed criteria sFecified in a program.
Alternatively, the design team can define user transactions and programs
which permit terminal operatcrs to sFecify the relevant selection
criteria" or selection limits, tc permit "ad-hoc" queries to be entered
by terminal operators. Refer to "ieighted Retrieval" in Chapter 5 for
more detail and for specific applicaticn examples of the use of this
function~
ASYNCHRONOUS TRANSACTION PEOCESSING (ATP)
This is not a built-in functien, but is supplied by CICS/VS to
provide a batch data collection capability, oriented to high-volume
data transmission frcm remote batch terminals. Specifically, this
function enables batches of data tc be entered froI remote terminals
and queued by CICS/VS for Frccessing. On receipt of the entire batch,
CICS/VS initiates the processing of that batch while the terminal is
able to transmit further batches to the system.
MEssages describing any errors detected during application-Frogram
processing of the batch are queued by CICS/VS. These error messages
are transmitted back to the remote terminal on reguest, to permit batch
error correction and resubuission cf corrections if required. Refer
to "Asynchronous Transaction processing" in Chapter 3 for more detail.
24
CICS/VS system/Application Design Guide
For efficient utilizatien of storage, CICS/VS ensures (unless
requested otherwisE) that cnly ODe copy of a Frogram will reside in
the dynamic storage area. All tasks requiring the use of that program
are able to execute that program concurrently.
In order to achieve a high degree of multitasking, CICS/VS supports
quasi-reentrancy. This allows several tasks to utilize the same section
of COdE over the same period of time. However, it differs from fully
reentrant programming in that control is only ~assed from one task to
another when the active task issues a CICS/VS macrc instruction.
control will not pass from one task to another on an I/O interrupt,
for Exam~le, as is the case in a DOS/VS or as/vs multitasking
environment. CICS/VS provides a quasi-reentrant capability for
Assembler, ANS COBOL, and PL/I.
Infcrmation unique to the Frocessing of a transaction (such as the
terminal input area, file I/e areas, or work areas) is separated from
the body of the application Frogram.
Instead of these areas residing
within the program, they are allccated from dynamic storage. ihe
execution of each separate transaction in a multitasking envircnment
is contrelled by a task centrel area (TCA) that contains address
pointers and other vital information for that particular transaction
(task). Because the inferaation uni9ue to a task is separated from
the main body of a program, the Frogram can be used concurrently by
several tasks.
ihe access methods are incorporated within the CICS/VS
nucleus, and exception or error routines are included in other Cles/vs
application programs. Figure 2-5 shews the concept of quasi-reentrant
programming. This figure is discussed in the ~!~~L!~ §~D~I5!
lDfo~ms!j~D ~gnysl.
Chapter 2.
CICS/VS program Design
25
IIII PUT
APPLICATION TASK PROCESSING
'-'
OUTPUT
.--'
CICSIVS
Nucleus
--
Access
Methods
Dynamic Storage Area
Task 1
Control
Area
..-----J
Terminal
Table
I Terminal
~
--
'>
'>
!F".
Input
Task 2
Control
Area
----T,",
Terminal
Input
Appli·
cation
~I
Work
Area
As For Task 1. Then:
Task2
Control
Area
6. Process File Input Record.
A
Code
)
L""
Terminal
7. Free File Input Area.
,---- )
)
Terminal
/
5. Free Terminal Input Area.
Code
-
Task 1
Area
~ ~o"ol
2. Allocate Work Area.
3. Allocate File Input Area.
4. Get File Record.
~
Work
Area
1. Locate Terminal Input
Area .
,
Input
"-
Dynamic Storage Area
~
'\
A
_.
Access Methods
':>
--- .........
Appli·
cation
\
CICSIVS Nucleus
'>
Table
Terminal
Table
I
Terminal
Input
-
-
~
~-.
':>
Task 3
Control
Area
Appli
cation
,----
~
Terminal
Table
B
Code
1. Locate Terminal Input
Area.
2. Allocate File Input Area.
7. Set Up Terminal Response.
Input
8. Send Respon.H.
Task 3
Control
Area
,---- ~
4. Allocate File Input Area.
5. Get File Record.
,-
File
Input
3. Get File Record.
6. Allocate Terminal Output
Area.
I Terminal
'>
File
Input
o
Terminal
Table
T"m'o,'
Input
Application
B
Code
I Terminal
L_
--
Output
----
0---._-----------
Figure 2--5.
Quasi-Reentrant Programaing and ftultitasking
There are several methods utilized by CICS/VS tc initiate tasks.
These arE briefly outlined here, but discussed in .ore detail in later
sections of this publicaticn.
26
CICS/VS System/Application Design Guide
TRANSACTION CODES
CICS/VS examines a transaction code receivEd as part of a terminal
message, to identify the particular transaction involved. This
transaction code must occu~y the first one to four characters of the
transaction invocation messagE. An inFut messagE is considered a
transaction invocation when it occurs and no task is active on the
terminal. This transaction code is validated by CICS/VS against a
program control table (ECT). If the specific transaction code exists
in that table, the transaction is assumed to be a valid one, and the
transaction is passed te that prcgram identified in the relevant PCT
entry, for processing (see "Task Initiation" in Chapter 3 for more
detail).
The 3270 enables transactions to be initiated by thE use of a program
Attention (PA) key, FrograD Functicn (El) key, or selector light pen.
AUTOMATIC TASK INITIATION
Automatic task initiation invelves the queuing cf transactions on
disk using eICS/VS transient data management. A number of transactions
may be queued based upon a s~ecific trigger level. When the numter of
transactions queued reaches this trigger level, CICS/VS automatically
utilizes a specified transaction code for that queue to initiate a task
and allow those queued transactions to bE processed by a specific
program.
(See "Intrapartiticn Queue Usage" in Chapter 4.)
INTERVAL CONTROL
CICS/VS enablES a task to be initiated using a specified transaction
code at some future time, based upon time of day or on elapsed time.
Data may be passed to that future task for use in Frocessing when it
has been initiated.
(See Chapter 6.)
TASK CeNTRaL
,A task can be explicitly initiated from a eICS/VS application program
by the use of the CICS/VS task centrol ATTACH macro instruction. This
macro instruction specifies the transaction code tc be used to id_ntify
the program which will precess the transaction.
(See Chapter 6.)
A program may pass control to other programs in a variety of ways.
These are illustrated in Figure 2-6 and described briefly below. See
the ~~L!~ ARR1i~s!io~ i.~XA~§'!§ E§!~~ ~s~YA1, SH20-9003, for
additional information.
TRANSFER CONTROL TC FROGEI! (XCTL)
This Dacro instruction (XCTL) enables one application program
(referred to as the calling program) to pa$s contrel to another
application program (referred to as the called program). Control is
not returned to the calling Frogram cn completion of execution of the
called program.
Chapter 2.
CICS/VS Program Design
27
Program
A
CICSIVS
Nucleus
XCTLB
link A
Program
B
Program
C
Program
D
Load E
link D
Return
Program
E
Process
link C
Delete E
Return
Figure 2-6.
LINK TO
Return
CICS/VS program Contrel Pacilities
FBOGBA~
(LINK)
This lacro instruction specifies the name of an application program
to be executed. ~he calling program passes contrel to the called
program. On com~letion of ellecuti,cn, control is returned to the calling
program, to the statement following the LINK.
LOAD PEOGBA! (LOJD)
This macro instruction enables a program, identified by name, to be
loaded into storage. BOleger, centrel is not ~assed to that program
for execution, but is returned to the statement following the LOAD
macro iustruction. The lOAD macro instruction can be used to load
application programs, which may subsequently be linked to or transferred
to. Alternatively, this maClO instruction aay be used to load tables
of inforDlation.
DELETE PFOGBJ!
(IELET~)
Normally, on completion of execution of a task, all storage utilized
by that task is auto.atically freed and made available for use in
28
CICS/VS system/Application Design Guide
processing other transactions. Active programs tEing used by tasks
will continue to reside in storagE. If, however, the storage occupied
by an inactive program is re9uired fer some other Executing task, that
storage will be freed. WhEn a program is loaded, its sterage can be
automatically freed if it is currently inactive, allowing another task
to use that storage.
Alternatively, the LOID macro instruction can s~ecify that the
storage is not te bE freed, tut that the program is to remain resident
in storage even though inactive, fer perfermance reasons.
The DELETE macro instruction is used to deletE such a resident
program at a point which will enable its storage te be utilized for
other functions.
RETUEN PEO! FBCGFA! (EETORN)
The Program Control RETURN macro instruction enables a program to
return centrel to a higher level pregram, that program can be either
another application program cr CICS/'S if the RETURN is issued by the
application program at the highest lEvel. The RETURN indicates that
the relevant program bas new completEd processing. At task completion,
CICS/VS frees all of the storage asscciated with the task, such as
terminal I/O areas, file I/O arEas, and file work areas, and eventually
also frees the storage occupied ty the task control area. Optionally,
a transaction code may bE specified in the RETURN macro instruction.
The transaction code is used with the next input message from the same
terminal that originated this coapleted task.
ABNORMALLY
TERMIN~TE
PROGEAM (ABEND)
This .acro instruction enables a program to immediately terminate
execution of a task, with an optional dump if required. In conjunction
with the optional operator signon facility (see Chapter 3), the ABlND
macro instruction can be used to develop operator error statistics.
ABNORMAL TER!INATION !XIT (SETXI!)
This macro instruction enables a task to activate, deactivate, or
reestablish a pregraa-previded exit routine to be executed in event of
abnormal termination of the task. This exit routine can be utilized
either on CICS/VS abnormal task termination, or ty termination through
the use of the ABEND macro instruction by the task.
An abnormal terminaticn exit routine is used to complete urgent
processing by a task for reccvery purposes, or it may attempt recovery
of the particular error condition itself. Refer tc "Program Error
Recovery" in the following sEctien fer more detail.
CICS/'S features facilities fer detection of pregram error
situations, and protection of the online system frem the effect of
these errors. If a program-check error is detected in an application
program, CICS/VS will attempt to atnormally terminate that task while
still permitting other tasks to continue processing.
Chapter 2.
CICS/VS Program Design
29
FROGRA~
ERROR PROCESSING
CICS/VS enables an application pregIam to indicate, through the use
ef the program centrcl SETXI~ macro instruction, that control is to be
passed tc a specified routine in the program in the event of a program
error, or to another program. This routine (or Fregram) .ay attempt
recovery of the error situatien, record certain critical information
necessary to the application befer,: the error program is abnormally
terminated, er ignore the errer situation and continue program
processing.
FROGEA~
EBROE
PRCGEA~
In the event that a prcgram errcr requires abnormal termination of
a task, the terminal operator who invoked the transaction to be
abnormally terminated will be notified of this fact by CICS/VS, if
a~~ropriaite.
CICS/VS passEs centrel tc a prcgram error program (PEP),
after all SETXIT processing has teen completed for the task and the
decision bas been Dade tc ~erDit the abnormal termination to continue.
This PEP is a user-written rcutinE, given centrol through a LINK from
the CICS/VS abnermal conditicn pregram (ACP), which enables the user
to perform installation-level abncrmal termination action.
SETXIT program processing and PEP are described further in'"System
Recovery Program" in ChaFter 8. These facilities can be used to provide
program tackup capability for online a~plications.
30
CleS/Vs System/Application Design Guide
This chapter presents Data Communications Design in a tutorial
fashion. Experienced CICS users may wish to omit reading much of this
chapter. It is suggested, however, that such users should read the
following topics:
• Terminal device independence
• Terminal paging
•
~essage
routing
• Virtual Telecommunications Access Method (VTAM)
• Task initiation
• Input transaction design
• Field verify/edit
• Table search
These topics describe changed, er new, facilities which were not
available in previous versions of CleS.
-----------~-~---~---~-~~---~-----~-~--~----~~--~--------~-~--.~-----~-
The Data Communications design has a significant effect on the
success er failure of the overall preject. It is in this area that
the interface bEtween the user and the computer is defined. This
definition should be oriented toward satisfying the requirements of
the user and the applicaticn, while still presenting information to
the computer in a suitable form for processing.
Before discussing various Data Communications design approaches, it
is important that the reader understand the following CleS/Vs support
and telecommunications access method facilities which will aid him in
his design:
• Basic mapping support
• Terminal device independence
• Terminal paging
• Message routing
• Virtual Telecommunications Access Method (VTAM)
with these features available to the system designer, various
approaches fer ccnversational CICS/VS applications and batch CICS/VS
applications can be considered.
The basic mapping support function (BMS) enables the application
program to have access to input data, and prepare output data for
transmission to terminals, without regard to the physical location of
Chapter 3.
CICS/VS Data Communications Design
31
the data in the terminal message. Additional infcrmation reqarding
tasie ma~ping su~pcrt can be found in the ~!~~L!~ !2pli~Atio~
FIQg.~gm.!!L~f.!.§ Re!~~§1!~~ !!l!llY.Al, SB20-9003.
B~S uses "maps" to descrile the input for.at cf data received from
terminals, and (if necessary) to describe the format of output data to
be transmitted tc terminals. These maps are defined by the user
(generally the system prcgraamer) and are separately assembled and
cataloged into the CICS/VS prcgram library for retrieval when needed
by application programs.
The applicaticn program accesses data from in~ut messages, and
prepares data for cutput res~onses, by field rather than by location
of that information in the terminal message. Consequently, the
application becomes less dependent on the actual message format.
This
format independence is one of the most significant advantages of BMS.
Changes to message fcrmats tc meet various aFplication requirements
can te readily applied, by mcdifying only the EMS maps describing those
affected formats, reassembling the., and cataloging the changed maps
to the Cles/vs program library.
All programs using these map'p reflect
the changed formats without modification of the prcgram~. However,
recompilation of the programs might be necessary. In this manner, the
installation will be more responsive to applicaticn nee~s. The use of
EMS ty applicaticn ~rcgrams is illustrated in Figure 3-1.
EMS MAFS
An in~ut map can specify data in an input message which is relevant
to a particular program and ignore other data in the input. Several
programs can then operate on the same input message format, using a
unique map for each ~rograD. In addition, constant (or descriptive)
information, if desired, can te defined in an output map and be
automatically incorporated by BMS in an output message.
Basic mapping support provides the following services:
• Terminal device independence
•
~erminal
paging
• Message routing
Because Basic Mapping SUPFcrt remcves the need for the apFlication
programmer to code Dcst terminal device-dependent support in his
programs, programs can be written withcut regard to the input or output
device used fer transmission of Dessages to those terminals supported
by BMS.
BMS accepts input mEssages and transmits cutput messages to
and from the devices below (see Figure 3-2).
• 1050 Data communication System
• 2740 Communications Terminal,
• 2741 Communications
~cdels
1 and 2
~erminal
• 2110 Data Ccmmunication SystED
• 2780 Data Transmission Terminal
• 2980 General Banking System (keyboard and printer only)
32
CICS/VS System/Application Design Guide
• 3270 Information Display System
• Teletype Terminals
• communicatins Magnetic Card SELECTEIC
6610, used as a 2741
I
BMS
Input
Map
>
Input Message
Input
Message
Typewriter (CMCST) Model
CICS/VS AND APPLICATION
PROGRAM PROCESSING
INPUT
/
(!)
A
BI
C
~~>
Terminal Input
OUTPUT
I
1. Application program issues
CICS/VS BMS in macro instruc·
tion, specifying relevant input
MAP, to initiate terminal input.
Alternatively, BMS MAP macro
instruction is issued by appli·
cation program, specifying
relevant input MAP to be used
for task initiation message.
2. BMS issues terminal control
get macro to read message, if
application program issued BMS
in macro instruction.
3. BMS extracts defined fields
from input message.
4. BMS positions fields in standard
format message.
Application
Program
/
5. Program access fields using
input MAP structure or DSECT.
Output Map
Structure Or
DSECT
(
1
F
BMS
Output
Map
I
=>
~nL I
G
H
~
~
Terminal Output
-l--'c
~
Application
I
Input Map
Structure Or
DSECT
6. Application program prepares
output in standard format,
using output MAP structure
or DSECT.
7. Program issues BMS output
macro, specifying output MAP
and also fields to be included
in output message from MAP.
I
8. BMS extracts fields and sets
up output message, including
fields contained in MAP, if
specified by program.
">
9. BMS issues terminal control
put macro to write message.
=>
Figure 3-1.
Formatted Messa ge:--1
AlB
Progri:lm
Formatted Message
E
>
I
I
I
Output Message
D
I
E
I
F
i
I
G
I
H
I
Output
Message
CICS/VS Basic Sapping Support (BSS)
Chapter 3.
CICS/VS Data Communications Design
33
CICSNS AND APPLICATION
PROGRAM PROCESSING
INPUT
Input
r---
1050
• 2740
• 2741
•
• TWX
2980
•• CMCST
• 2700
• 2780
• 3600
3650
•
•
•
cJ
~I""""
1. BMS removes devicedependent code from
input message.
1"">
Keyboard/Printer
c:5D
0
Line
• Printer
Cd]
---
---
cD
~>
3. Application program prepares output message as if to
be output on line
printer.
g
.........
~I""""
........
~-
Seqtl Unit Record
1050
•• 2740
• 2471
• TWX
2980
•• CMCST
•
•
2770
2780
3600
•• 3650
• 3780
Communication systems
4. Program inserts opional new line
characters (X'15') in
output, if desired.
0
~>
5. Program issues BMS
output request.
Seqtl Unit Record
• Disk
• Tape
Keyboard/Printer
Output
Displays
• Card
Reader
cJ
~>
2. Inputmessage is presented to program
as if read from card.
3780
Communication Systems
3270
OUTPUT
•
3270
•
Card
Reader
Displays
6. BMS sets up new ter·
minal line for each
new line character
specified.
Cd] •
~>
7. BMS breaks lines
greater than terminal line length
specified, into separate lines.
Line
Printer
Seqtl Unit Record
8. Device-dependent
code (carriage
return, idles) inserted by BMS.
cD
w>
9. Output message
then transmitted
to terminal
• Disk
• Tape
Seqtl Unit Record
:-e:-:-I.::'::t7::::~~:UC~::~-h;~360:
......-D-e-v-ic-e.-d-e-pe-n-d·-e-n-t-CO-d-e-'-m-a-y-be-r-em-o-ve-d-··-by-p-ro-g-r-a:-x...
For the 3600 and 3650, input mapping requests are ignored.
.
-------,_._."--,
Figure 3-2.
I
bef::n-s-m-i-SSion to CICSfVS. ::
,----,
CICS/VS Terainal Device Independence
• 3780 comaunication Systea
•
360~
Finance Ccmmunicaticn SysteD (BMS input requests are ignored)
• 3650 Retail stcre System
Furthermore, the following seguential devices can be used to simulate
online terminals, and transmit simulated terminal messages to and from
the systelo:
34
CICS/VS System/Application Design Guide
• Card reader/line printer
• Tape drives
• Disk drives
INPUT MESSAGES
ClCS/1S accepts input messages frem any of the above devices and,
using the input map specified by the application program, converts the
input message into a fixed fermat message, as specified ty that map.
Device-dependent characteristics in the input message are removed, and
the appropriate fields are selected from the message and inserted in
fixed locations in the mapped message.
In the case of the 3600, device-dependent characteristics in the
input message are removed ty the 3601 Controller and the input message
is formatted for CICS/VS applicatien program processing before
transmission to ClCS/VS. Consequently, BMS input mapping requests
associated with 3600 input messages are ignored, and the data received
from the 3600 is passed to the CICS/VS applicaticn program without
change. See "Basic Mapping Suppcrt Using VTAM" for additional
information.
OUTPUT MESSAGES
output messages fer transaissicn to terminals can be prepared without
the control characters required for field positicning, or line
separation. output Dessages can be Fresented to CICS/VS as a data
stream. Optionally, the application program can insert new line (X'1S')
characters in the output data stream if required.
CICS/1S device-independent sUFPcrt divides the data stream into
lines no longer than those defined for the particular terminal. If
new-line characters appear occasionally in the data stream to further
define line lengths, they are honored. CICS/VS inserts the appropriate
leading characters, carriage returns, and idle characters, and truncates
trailing blanks from each line.
Terminal device independence permits an application program to be
independent of the terminal type (or types) in the installation, and
can provide for support of mixed terminal types ty the same program.
This allows the use of backup ter.inals of a different type, or
changeover of hard-copy terminals to display terminals when transaction
volumes warrant the change, with little or no additional programming
eff~rt.
It also reduces the amount cf program maintenance necessary
when changes are made in the terminal devices used by online programs,
and permits increased growth flexitility in the installation.
Terminal device independence is the only EMS support available with
the subset option of CICS/DOS/VS. Terminal paging and message routing
are not supported.
(See "CICS/DOS/VS Subset Option" in Chapter 7.)
Terminal paging is an additional feature that extends the
capatilities of terminal device indeFendence. The application
programmer can prepare mere output than can be conveniently or
physically displayed at the receiving terminal. That output can be
presented by CICS/VS as a series of pages. CICS/VS identifies and
saves each page of infor.aticn prepared by the application program.
Chapter 3.
CICS/1S Data Communications Design
35
ClCSIVS AND APPLICATION
PROGRAM PROCESSING
INPUT
["'';' .'0
.>
Program
OUTPUT
1. Applicatic,n program
presents output pages
in normal application
sequen, e.
J
~
2. CICS/vS write pages to
temporary storage.
Page 3
Page 2
Temporary
Storage
=>
Page 1
• Page Forward
•
Page Back
• Skip Pages
Forward
Paging
Command
Request Pagi;'g Status
LlJF>
-;:::>
•
Page Next
Page Previous
•
Page Current
• Terminate An
Purge Pages
• Copy Page
• Query Page ID
Figure 3-3.
3. Terminal operator
enters page commands
requesting pages in
desired sequence.
4. CICS/vS retrieves each
page requested. and
transmits it to the
terminal.
-- ,--
~
I
Page 1
Page 3
• Skip Pages
Backward
•
(
T,m,,,,,, (
Storage
---
Automatic Paging StatuI
'--
'--",>
5. CICS/VS retrieves each
page in same sequence
prepared by program
and transmits it
automatiocally to
the terminal when
able to rE:ceive it.
L_
~>
Page
Display
CICS/VS Terminal Paging
The terminal operator can thEn rEtriEve this output as a nuaber of
pages in any ordEr; tbat is, in the erder tbey were prepared, ~r by
skipping forward or backward in the output page seguence.
CICS/VS provides a seriEs of pa9ing co •• ands which can be used by
the terminal operator to selEct Iages for display in whichever sequence
he desirEs (see Figure 3-3).
Terminal paging also provides the atility to co.bine several small
sections of data inte cne pa9E which is then sent to the t~rminal.
This is referred to as "page building" and enablEs the application
programmEr to prEpare his output independent of the physical output
capability of the terminal.
Terminal paging further relieves the application programaer of the
need to ccncern himself with the p~esentation of infor.ation in a form
36
CICS/VS systea/Application Design Guide
suitable for display at the appropriate terminal, or with presentation
of that information to the terminal in the sequence requested by the
terminal operator. The ap~licaticn ~rogram.er can nov prepare a series
of pages of information, on the assumption that the terainaloperator
may wish to examine all of that information, and then present those
pages directly to CICS/VS. Ne further programming is necessary to
handle the selection of ~ages for display at the terminal. Page
selection is made by the terminal operator, using the CICS/VS paging
commands.
This will simplify program development of conversational applications
and consequently increase prcgra.mer productivity and decrease the
amount of future program maintenance necessary.
It is important that the system designer recognize that terminal
pages are saved ty CICS/VS in temporary storage. Temporary storage
may be supported in main storage alone, or on auxiliary storage using
VSAM; both will increase the demands for real stcrage during execution.
Using VSAM on a CPU with limited real storage available for virtual
storage paging may increase ~aging and therefore influence online
performance. Refer to Chapter 1 for recommended ainimum CPU sizes when
VSAM is used. Terminal ~aging is not supported by the subset option
of CICS/tOS/VS.
(See "CICS/DOS/VS Subset Option.")
TERMINAL PAGING STATUS
Terminal paging is particularly oriented toward display terminals.
However, it can also be used for hard-copy terminals. A terminal can
be defined as having a "reguest ~aging" status or an "automatic paging"
status.
Display terminals must use a request paging status, while hard-copy
terminals can use either request ~aging or automatic paging status.
Request paging status enables pages to be displayed at the terminal on
request by the terminal operator, whe can specify the sequence of pages
to be displayed based upon his requirements.
Automatic paging status, such as normally used for a hard-copy
terminal, causes CICS/VS tc automatically output the next page of
information on completion ef a previcus page. In this way, all
information is presented tc the hard-copy terminal in a continuous
output stream. If required, an automatic paging terminal may be changed
to request paging status by either the terminal operator or the
application program, enabling only those pages to be printed which are
of significance to the terminal cperator. Similarly, the terminal
operator or the application program can change request paging status
to automatic paging for all terminals except display terminals.
Other terminal status specificaticns can also be used to indicate
whether a terminal automatically receives messages sent from the CPU
or from cther terminals. This is discussed under "Terminal Status" in
Chapter 4. Additional infcrmaticn on terminal paging can be found in
the ~lCSL!~ ABB!j~§!i2D fI2g1~!!§I!§ jef§I~~§ ~~~s!, SH20-9003.
Message routing directs messages to one or more terminals in the
system, either by use of the message switching transaction, CMSG,
supplied by CICS/VS, or by the E!S ROUTE macro instruction. In this
context, the term "message switching" refers to the use of CMSG. The
term "message routing" refers to the use of the EMS ROUTE macro
instruction.
(The CMSG transaction itself uses the services of the
EMS BOUTE macro instructicn.)
Chapter 3.
CICS/VS Data Communications Design
31
The CMSG transaction is entered by a terminal operator together with
a message to be directed tc ancthel= terminal, or to several terminals
identifiecl by the terminal oFera tor..
(This is discussed further in
"Message switching Transactien (C!!SG)" later in this chapter.)
The message routing macro instruction permits an application program
to send messages to one or mere terminals not in direct centrol of the
transaction. Message routing uses EMS, and saves messages in temporary
storage to be automatically sent to the specified destination terminals
if the status of those tEruinals allcws for reception of the messages
(refer to "Terminal Status" in ChaptEr 4). If a terminal is not
immediatEly eligible to receive the message, CICS/VS preserves it in
tempoary storage until such time as a change in terminal status allo.s
it to be sent, cr a user-sFecified period of timE elaFses, whichever
occurs first (see Figure 3-4). The message to te delivered is separated
into a message for each terminal type that will receive it. Each
separate terminal-type message is saved in tempoary storage, together
with a destination terminal list fer that particular terminal type.
In addition, an applicaticn Frogram can prepare pages of information
to be transmitted to terminals, using EMS and the terminal paging
facilities as described above. These Fages can te routed to one or
more terminals or operators, through the use of the BMS ROOTE macro
instruction.
MESSAGE DELIVERY
The application programmer spEcifies the identification of the
terminal (or terminals) to receivE the message, and, optionally, can
also specify a time when the message is to be delivered. If the message
cannot be delivered either iaaediately or at the sFecified future time,
CICS/VS retains the message fcr a user-specified period of time. If
it still <:annot be dElivered, CICS/VS notifies the originating terminal
or an alternative terminal sFecified when the original message was
entered.
CICS/VS allows messagEs to be dirEcted, not only to specific
terminals v but also to sFecific operators or operator classes. In this
way, sensitive security information will only te delivered to those
operators authorized to receive it. It is retained in temporary storage
until the specified operaters sign on to the specified terminals, and
only then will relevant messages te dElivered.
If a message is to be sEnt to a specified operator without
identifying a terminal, that operator must already be signed on when
the message is first presented te CICS/VS to establish the terminal
identificatien tc be used. If a message is sent to a specific operator
and terminal, and that operator can never use that terminal (because
of geographic location, for exam FIe), the message will be accepted by
CICS/VS but may never be dEliverEd. This is noted by CICS/VS upon
expiratien of thE specified time within which the message must be
delivered ..
Terminals in the IBM 3600 PinancE Communicatien System are identified
a lcgical device code (tDC). Me_sages from CICS/VS are received by
the appropriate 3601 application program which represents the specified
terminal ID and controls the devices attached to the 3601. The message
from CIeS/VS identifies the IDC (SFecified by the application
programmer) that is to rEceive the messagE; it is the responsibility
of the 3601 application Fregram to ensure that the message is delivered
to the device indicated ty the LDC. Logical device codes are described
in detail in "Basic !apping Suppert Osing VTAM" in this chapter.
by
38
CICS/VS System/Application Design Guide
INPUT
CICS/VS PROCESSING
OUTPUT
Initiate Message Routing Operation
iSk
~K""""dlP';&
1-
Tape
Display
>
1. CICS/VS accepts message
switching transaction
from terminal, or BMS
route macro instruction
from application
program.
Card
2. Message is written to
temporary storage.
Originator (Terminal Or
Program I Specifies:
•
•
•
•
•
D"k
>
1
Temporary
Storage
(
\
4. When delivery time is
reached, message is
read from temporary
storage and sent to
specified terminal(s)
or operatods). Ifable
to receive message.
>
Line Printer
(
\
5. If terminal(s) or oper·
ator(s) is unable to reo
ceive message after defined delivery delay
period, origin'ating (or
notification) terminal
is notified.
Keyboard/Printer
Line Printer
Destination Terminallsl
Or Operator(s) Unable
To Receive
Figure 3-4.
I
~
Tape
Destination
Terminallsl
Or Operator(s)
Display
Tape
(
~"b:::;:""~
1
Disk
(
<
3. If message is to be de·
Iivered later, interval
control task initiation
is specified for required
time(s).
Destination Terminal(sl
Destination Operator(s)
Delivery Time
Notification Terminal
Message To Be Sent
Temporary
Storage
>
r--..-----......,/">
~
iSk
Line
Printer
l~_
Display
Tape
Keyboard/Printer
Originating (Or Notificationl
Terminal
CICS/VS ftessage Bouting
MESSAGE SWITCHING TRANSACTION (CMSG)
CICS/VS provides the message switching transaction CftSG for
transmission of information between terminals. Pigure 3-4 shows the
use of this transaction.
The availability of the message routing feature in CICS/VS provides
a valuable capability fer coamunication of information, not only tEtween
terminals to satisfy application reguirements, but also for better
control cf the online applications by the master terminal cperator or
supervisory terminal operators. These operators may broadcast messages
to all terminals under their control informing them of cErtain
significant information.
CICS/VS message routine utili2Es temporary storage, which will use
VSAft if auxiliary storagE residence cf messages is desired. Message
routing and message switchin9 are not supported by the subset option
of CICS/DOS/VS.
(See tlCICS/DOS/VS Subset Option" in Chapter 7.)
Additional information abcut basic aapping sUfpcrt can be found in
the CItSL!~ A~R!i~~~i2D !!9gXjm~§!!§ Eef~!~DS~ a~YA!' SH20-9003. 3600
logical device codes are described in more detail in the ~~Ll~
A.QvanSfji.Q ~Q.mlQYDi~!!i2D§ 1iyjg!, SH20-9049.
Chapter 3.
CICS/VS Data Communications Design
39
CICS/VS application programs can communicate directly
using:
• Basic mapping support
~~S)
~ith
terminals,
macro instructions
• Terminal control macro instructions
BMS enables application programs to request terminal input or output,
using the DFBBftS macro instructicn:.
• For input (TYPE=IN or
~AF)
• For output (TYPE=OUT)
• For terminal paging (TYPE=TEXTELD, PAGEBLD or FAGEOUT)
• For message routing (TYPE=BOUTB)
Terminal control enables Frograms to request additional functions
by using application programmer tPfiTC macro instructions to:
• Write data to a terminal (TYFE=WEITE or TYPE=FUT)
• Eead data from a terminal (TIPE=BEAD or TYPE=GET)
• Synchlconize terminal I/O with processing (TYPE=WAIT)
• Transmit a page of data ahd read reply (TYPE=PAGE)
• Transmit to the buffer of a banking terminal (TYPE=CBUFF)
• Test for the presence of a banking passbook (TYPE=PASSEK)
• Beset a line (TYFE=RESET)
• Disconnect a switched line (TYFE=DISCONNECT)
• Erase and write data to a visual display (TYFE=(ERASE,iBITE»
• Specify the last outFut message to a VTAft-suppcrted terminal
(TYPE:=LA ST)
In addition, the system programmer may
instruct ilons to:
USE
the following DFBTC macro
• Change the status of a terminal (CTYFE=STATUS)
• Loca t4a a terllinal entry in the TCT (CTYPE=LOCATE)
• Check the results of a previcus STATUS or LOCATE request (CTYPE=CBECK)
These macro instructions are described briefly in "Terminal Control
Using VTAI!" and in acre detail in the g~L!~ ~j!g f~.91U!!I!§
~~!!I~D~§ A!DY~l, SH20-9004.
The particular communication macro instructions used in programming
are not significant to the fcllowing discussion of data communication
design. However, if BftS is not used, the following facilities canDot
be provided by CICS/iS:
40
CICS/iS System/Application Design Guide
• Terminal format independence
• Terminal device independence
• Terminal paging
• Message routing
3270 BMS can be specified during system generation to provide
compatibility with previous versions of CICS. Terminal device
independence, terminal paging, and message routing need not be
specified. However, if they are specified, they require that temporary
storage (and also VSAM) be used.
BMS and terminal control macro instructions can be used in the same
application program, if required. Refer to the CICS/VS Application
Programmer's Referen~ Manual for further information.
CPU CONSOLE AS
~
CICS/DOS/VS TERMINAL
CICS/DOS/VS allows the CPU printer keyboard or display console to
be used as a CICS/DOS/VS terminal. Users with only remote terminals
may enter master terminal operator, system administration, and CICS/VS
application transactions at the CPU, thereby isolating these activities
from any network considerations.
See the Subset User's Guide (DOS),
SH12-5404 for additional information about this feature.
BASIC TELECOMMUNICATIONS ACCESS METHOD (BTAM)
The Basic Telecommunications Access Method (BTAM) is used by CICS/VS
to support a wide variety of terminals. These include the following:
• 1050 Data Communication System
• 2260 Display Station
• 2265 Display Station
• 2740 Communication Terminal
• 2741 Communication Terminal
• Communicating Magnetic Card SELECTRIC
used as a 2741
~ Typewriter (CMCST) Model 6610,
• 7770 Audio Response Unit
• TWX Common Carrier Teletypewriter Exchange Terminal Station (Model 33/35)
• 2770 Data Communication System
• 2780 Data Transmission Terminal
• 2980 General Banking Terminal System
• 3270 Information Display System
• 3735 Programmable Buffered Terminal
• 3740 Data Entry System
• 3780 Data Communications Terminal
Chapter 3.
CICS/VS Data Communications Design
41
• system/3
• system/7
• System/310
• 3161 Communications Terminal (using 2140/2741 Compatibility Feature)
• 3170 Data Communications System (using 2170 Compatibility Feature)
See the CICS/VS System Programmer's Reference Manual for additional
information concerning components supported and features required for
these terminals.
The subset option of CICS/DOS/VB uses BTAM to support the following
terminals:
• 3270 Informa tion Display System (local and remote)
• 2140 Communication Terminal
• 2141 Communication Terminal
See the Subset User's Guide
(DO~
for additional information.
BASIC GRAPHICS ACCESS METHOD (BGAM)
The Basic Graphics Access Method (BGAM) is used by CICS/OS/VS only.
It supports the local connection of the 2260 Display Station.
TEI,ECOMMUNICATIONS ACCESS METHOD crCAM)
CICS/OS/vS provides an interface to the Telecommunications Access
Method (TeAM). This interface enables CICS/OS/VS to run with other
TCAM appl.ications under a common TCAM environment, or under TCAM through
a VTAM-controlled terminal environment.
CICS/VS accepts data streams from TCAM-supported terminals which
can be edited in the message handler portion of the TCAM message control
program (MCP) to appear as EBCDI C or 3270 da ta strea ms.
With the exception of 1110 and 3210/2260 compatibility support, the
TCAM support provided in CICS/OS Standard Version 2.3 (Program Number
5136-XX1) is upward compatible to the CICS/OS/VS TCAM interface. See
the £!£§ ~eneral Information Manual, GH20-1028 (for information
regarding CICS/OS STANDARD Version 2.3, Program Number 5134-XX7) and
the OS TCAM programmer's Guide and Reference Manual, GC30-2024, for
information regarding the terminals supported.
other IrCAM-supported terminal s, which were not supported by CICS/OS
STANDARD Version 2.3, are supported as data streams which are
terminal-'type transparent to CICS/OS/vS.
TCAM i:9 an optional access method which may be used alone, or in
combination with other access methods supported by CICS/OS/VS. When
communica'ting with terminals attached to 3704 or 3705 Communications
Controllers in NCP mode, TCAM must communicate through VTAM.
42
CIC13/VS System/Applica tion
DE~sign
Guide
The virtual Telecommunications Access Method (VTAM) is used by
CICS/VS to support a numter cf programmable terminal systems. These
terminal systems enable programming tasks (such as transaction editing,
validation, and formatting) relevant to a remote location to be carried
out in programmatle control units at the remote location. The
programmable control units can o~erate either online to a CPU, or
offline in a standalone mode. Operating offline, many of the control
units can permit terminal operation to continue independent of
availability of the main CFU or associated communication links.
Terminal transa~tions cab te recorded on disk storage (whicb is part
of the programmatle centrol unit) for later transmission when CPU
communication is available. Disk storage also enatles selected
application data sets te be stored in the programmable control unit
for direct reference by ap~licatien ~rograms executed in the control
uDit on tehalf of terminals.
This concept ef "distributed function" enhances performance and
permits cost efficiencies to be realized in the areas of data
transmission, system availability and configuratier, and application
flexibility.
The Network Control System (NCS), which may be used by CICS/DOS/VS,
provides a subset of the support available with 1TAK. Refer to "Related
Publications" in the Preface for NCS publications.
SYNCHRONOUS DATA LINK CCNTEOI (StLC)
Purther efficiency in data transmission and data integrity is
realized through the use of synchronous data link control (SDLC) data
transmission. stLC allows data to be transmitted in full-duplex mode
(transmitted simultaneously in both directions along a communications
line). VTAM supports both StLC and full-duplex transmission.
A significant feature offered by SDLC is data integrity. Eoth VTAM
and the control unit can check fer error-free transmission of data and
can reguest retransmission if an error is detected. Each transmission
between VTAM and a programma tIe control unit is assigned a sequence
number. Messages lost, because cf cemponent or ccmmunication failures,
are easily detected and the lost data recovered. If recovery is not
possible at the time of detection, the end component (VTAM or the
control unit) requesting recovery can switch to an alternate processing
mode.
If communication is lost tetween the CPU and the control unit, the
control unit may switch to offline mode. Transactions entered from
the attached terminals are processed by referencing data sets stored
on the disk storage in the ccntrcller. The transactions can be stored
on the disk for later batch transmission to the CPO when ccmmunications
are restored.
Message recovery and resynchronization are handled auto.atically by
VTAM and the ~ontroller. Either end of the link can transmit a command
to test the sequence nuabers ef the last transmitted aessages and to
set the sequence numbers to reflect the status of the CPU and control
unit. If this operation determines that messages were lost,
resynchronization is accomplished ty retransmitting the lost messages
from copies stered on the disk storage.
See l]~ ~~D~l!l.ml.Q'y§ ~.9!.9 lillls 5;"Il.u~: .§iuul 1n!2lll tiop ,
GA27-3093, for additional information concerning StLC.
Chapter 3.
CICS/VS Data Communications Design
43
CICS/VS uses VTAM and SDLC to
unit terminal systems:
sup~o~t
the following programmable
cont~ol
• IBM 3600 Finance Communication System
• IBM 3650 Retail Store System
• IBM 3790 Communications System
See "CICS/VS Session Types" fox additional info~mation about these
systems, and see ~1~~!~ §~!i~ 1!2S~lmi!!§ iii!!§n~! A!D»Al SH20-9004,
for features sUPForted er reguirEd by CICS/VS.
'
VTAM NETtiOEK
The V1AM netwcrk consists of the follcwing comFonents:
• communications
ccnt~clle~s
• communication lines
•
prog~ammable
terminal systems
These components are
ccnt~ollEd
• CPU Frogram CVTAM apFlicatioD
by the following
prog~ams:
F~eg~am)
• Network Contrel Fregra. (NCP)--This program resides
in the communication controller.
• Function program or application FIogra8 block (AP)-This program resides i~ the ~rcg~a.mable control unit.
CICS/VS support of BTAM, EGA!, 1CAM, and V!AM can
CICS/VS Fartition/region.
co~reside
in the
~2mmYn!~§.!ion§ ~~DlI~llj'§
VTAM uses the IEM 3704/37C5 Ccmmun1cations controllers to enable
of the telecommunications processing to be aoved out of the central
computer and inte the netwcrk. 'lhe 3604/3705 control the flow of
inforaation between VTA! and terminals through use of a network control
program (NCP). The 3704/3705 and its NCF support a variety of ~emote
terminals. An NCP can be generated to handle lines in either n~twork
control mode (for VTAM-suPFo~ted terminals), in emulation mode (for
BTAM-supported terminals), or in toth modes. An NCP genE~ated with
both functions is called an NCP with partitioned emulation programming
(PEP) extension. This permits bcth VTAM- and ETAM-supported terminals
to communicate with application Frog~ams (such as CICS/VS) through one
pa~t
3704/370~i.
Functions provided by the 3704/37C5 include:
• line control
• dynamic buffering
• deleting and inserting line control characters
• translating character codes
• handling recoverable errors
44
CICS/VS system/Application Desigm Guide
• detecting permanent line errcrs
• gathering line statistics
• activating and deactivating lines and closing down the network
By performing these functions, the 3704/3705 and NCP conserve central
computing resources. See lB!12~~~!i~D 12 !h~ IBM 37~! ~~ ~1~~
~I!Ynic~tioD§ ~sD1IR!1~1, GA27-3051, for additional information.
~hAl~g j~§QY~~§
VTAM permits its network resources to be shared among the various
VTAM applicaticn ~rcgraDs being executed in separate partitions/regions
in the CFU. One VTAM application ~rogram may be CICS/VS, which uses
VTAM to establish communication tetween CICS/VS application programs
and terminals, and another program could be IMS/VS operating in a
different partition/regicn.
VTAM controls the use of ~aths through the 3704/3705, communication
lines, and programmatle controllers so that several applications may
communicate with different terminals on a single line. Also, the
terminals on the same line may co.municate with any of the application
programs using ViAM. Thus, cne terminal on the line may be
communicating with CICS/VS, while anotber terminal on the same line is
communicating with IMS/VS. However, once a terminal begins to
communicate with a VTAM application program, that terminal cannot
communicate with another ViA! apFlication program until tbe first
program breaks its logical connection and releases the terminal. While
connected to CICS/VS, the terminal may, of course, enter transactions
to initiate different CICS/VS application programs.
for further information on VTAM, refer to l~!l~~Y'1i2~ 12 ITAM,
GC27-6987, and 11JI ~~D~.i!s IDg I1~DniDS' GC27-6998.
CICS/VS
use~
VTAM to communicate with the following terminal systems:
• 3600 finance Communicaticn System
• 3650 Betail Store system
• 3790 Communication Systes
These terminal systems bave "intelligent" capabilities and use a
programmable contrcller tc direct the operation of a number of attached
terminals. The controller ccmmunicates with VTAM, which directs traffic
between CICS/VS and the controller. The 3601, 3E51, and 3791 are the
controllers for the 3600, 36~0, and 3790 systems respectively.
A logical connection is established bEtween CICS/VS and a controller
program. The ccntrcller program and its associated terminals, is called
a logical unit. The VTAM connection with a logical unit is regarded
by CICS/VS as similar to a physical connection with ETAM-supported
terminals. The CICS/VS terminal control table (iC~ is used to define
the status of each VTAM logical connection. A 4-character terminal
identification is used to idEntify each particular TCT terminal entry,
and hence identifies the lcgical unit.
Chapter 3.
CICS/VS Data Communications Design
45
CICS/VS SESSION TYPES
CICS/VS sUPForts several different logical connections (called
sessions) with the 3600, 3650, and 3790.
~ 600 ~§!HiiQ!l§
A 3600 session is established between eICS/VS and a 3600 application
program tlcck (AF) in the 36C1 ccntrcller. The AF is regarded by
CICS/VS as a logical unit, referred to by its terminal identification
in the TeT. The AP, in turn, controls the operation of one or several
of the following terminals attached to the 3601:
•
IBM
~1604
Keyboard Display
•
•
IBM
~1610
Document Printer
IBM
~1611
Passbook Printe I
•
IBM
~1612
Passbook and Document Frinter
•
•
IBM
~1618
Administrative line Frinter
IBM
~1614
Consumer Transaction Facility
The 3Ei14 may also be attached directly to a 3704/3705 and is then
regarded as a separate logical unit. As many as 96 terminals may be
attached to a 3601. Disk stcrage in the 3601 cor.tains 288,000 bytes
of storage which permits Dultipregrammed execution of several APs.
Each AP may control several terminals. Individual terminals are
transparent to CICS/VS and it is the r~sponsibilitJ of the AP to
interpret specific requests from the terminals, communicate them to
CICS/VS, interpret the output from CICS/VS, and direct it to the
appropriate ter.inal.
CICS/VS communicates directly with an
and is unaware of the operation of other
APs may }:e commun1cating with CleS/VS as
other VTAM application programs (such as
IP as a separate logical unit,
APs in the 3601. The other
other logical units, or with
IMS/VS).
3600 sessions permit the following eleS/VS services to be supported.
• Operator signon
• Basic mapping sUFPort
• Terminal paging
• Message routing and Dessage switching
• Automatic task initiation
• Master terminal operatcr functions
• supervisory terminal operator functions
• Message recovery and resynchronization
Befer to 1!l!.ggY~iDg !D~ 1~~ ~~~~ lin!D~ CO~aYn!C~tiQD 31§1§!,
GI22-276 1" for further infor.atien on 3600 units and features, and to
the ~1~~~!1~ Jg!!!l~§g ~Q!!~ni~l!i~B §~i~, 5820-9049, for information
on the support of the 3600 by CleS/VS.
46
CleS/VS systeD/Application Design Guide
J.§~Q ~§§si2!l~
The 3E51 store ccntrcller is a ~rcgra •• able centrol unit to which
as many as 191 terminals may be attached for use in a retail store
environment. The terminals are:
• IBM 3653 Point of Sale Terminal
• IBM 3215 Display Station
• IBM 3284 Printer
• IBM 3657 Ticket unit
• IBM 3659 Remote Communications unit
(Befer to I~~ ~~~~ i§isil §121J §~§1!. lD!~~!s!i~n, GA27-3075, for
further information on 3650 units and features.)
The 3657 and 3659 are nct directly used by CICS/VS, but are· used by
the 3651. The 3651 controller ccntains up to 9.3 million bytes of disk
storage and function programs (PEs) which control the operation of the
various terminals attached tc the 3651. CICS/VS ccm.unicates with the
FP and is not aware of individual terminals. It is th~ responsibility
of the pp to interFret specific reguests from the terminals, select a
relevant session type for co •• unication to CICS/1S, interpret the output
from CICS/VS, and direct it tc the a~propriate terminal. The different
session types which may te selected are:
• 3215 host conversational session
• 3653 host conversaticnal sessicn
• Pipeline session
• Application
~rogram
session
3215 Host conversational Session: This session Fer.its a 3275 to enter
transactions to be transmitted to CICS/VS and to initiate CICS/VS
application programs similar to transaction entry fro. BT1M-supported
terminals. A number of 3275 host conversational sessions can be defined
in the 3651 (less than or equal to the number of 3275s).
The 3215 terminal operator reguests the 3651 ccntroller to connect
him to an availatle 3275 hest conversational sessicn. It is then the
responsibility of the 3651 to establish the logical connection (session)
between the 3215 and CICS/1S. The session is allocated an available
terminal entry in the TCT and is kncwn to CICS/VS by the~elevant TCT
terminal identification.
3275 host conversational sessions permit the following CICS/VS
services tc te sup~orted.
• Operator signon
• Easic mapping support
• Terminal paging
• Message routing and message switching
• Automatic task initiation
Chapter 3.
CICS/VS Data Communications Design
47
• Master terminal cperatcr functicns
•
Su~ervisory
terminal e{erator functions
The following service is not sUFPcrted:
• Message recovery and resynchronization
3275 host cenversational sessions are the only 3650 sessions which
permit B~S maps to be stored on disk in the 3651 instead of in the cpu.
CICS/VS transmits the unformatted output data, plus the map name, to
the 3651, which inserts deviee-deFendent characters and, using the
specification in the map, formats the output fer display cn the 3275.
See "Basic MapFing Support ccmmunication using V~AM" for further
details.
3653 Host Conversational Session: This session Fermits a 3653 to enter
transactions to te transmitted tc CICS/VS, and to initiate CICS/VS
application programs in a manner similar to that used for 3275 host
conversational sessions.
A number of 3653 hest ccnversational sessions
can te defined in the 3651 (less than cr equal te the number of 3653s).
The 3E53 terminal operator requests the 3651 stere controller to
connect bim to an available 3653 best conversaticnal session. This
connectic:n, and allocaticn of an available terminal entry in the TCT,
is performed by the 3651 in a manner similar to that used for 3275 host
conversational sessiens. The session is then identified to CICS/VS by
the relevant TCT terminal identificaticn.
3653 host conversational sessions permit the fcllowing CICS/VS
service to be sUFPorted:
• Easic
ma~ping
sUFPort
The following services are net sUFPorted:
•
O~erator
signon
• Automatic task initiation
• Terminal paging
• Message routing and message switching
• Master terminal cperatcr functiens
• Supervisory terminal oFerator functions
• Message recovery and resynchronization
Pipeline Session: One pipeline session may be established in a 3651
to support multiple 3653 terminals. The purpose of this session is to
support loinimum delay transactions from 3653 terminals, such as a credit
status check and update prior to initiating a particular customer
transact:ion, or adjustment of a custemer's credit status cn cancellation
of a credit transaction.
CICS/1S permits a number ef TCT entries to be specified as belonging
to the pipeline session. ihese are used as a FocI of entries to permit
multiple tasks to be initiated fer different 3653s using the pipeline
session. A separate pocl cf TCT entries can be specified for each
3651, or all TCT entries can be combined in a single Fool to service
all 3651 pipeline sessicns.
48
CICS/VS
System/Ap~lication
£esign Guide
The TCT pools represent a number of user-specified tasks to be run.
CICS/VS passes an input transaction from a pipeline session to one of
the available TCT entries in the pool for that session. This permits
the processing of a number of credit transactions to be multitasked
for optimum response.
To identify the 3653 initiating pipeline transaction, the 3651
transmits a terminal identification to CICS/VS at the beginning ot the
input transaction. This is not used by CICS/VS, but is passed to the
CICS/VS application prograre.
The program may use the identification
to maintain audit trails or statistics. The only change to data that
can be made is to the status byte. All other data must be returned
unchanged.
Pipeline sessions permit the following CICS/VS service to be
supported:
• Basic mapping support
The following services are not supported:
• Operator signon
• Terminal paging
• Message routing and message switching
• Automatic task initiation
• Master terminal operator functions
• supervisory terminal operator functions
• Message recovery and resynchronization
The following restrictions apply for pipeline sessions:
• CICS/VS logging is not performed.
• Only one input message and one output message are supported
for each task.
• Each input message results in the initiation of a new task.
• A pipeline session can only be initiated by the 3651.
• A conversational transaction cannot use a pipeline session.
• The transaction code to initiate a task is defined in the TCT
when i t is generated. The input message is not examined for a
transaction code.
• Unique operator identification is not associated with the TCT
entry used by a task.
• Request volume that exceeds the user specified number of concurrent
attached tasks is not queued within the system.
To meet the rapid response needed for credit transactions, the
pipeline session provides fast throughput for a specific transaction
type. In addition, the user can specify to the 3651 a time value at
which the 3651 will use an alternate user-defined procedure for
responding to these transactions.
Chapter 3.
CICS/VS Data Communications Design
q9
A,pplication Program Sessions: This session (also referred to as an
Interpret:er session) results in communication between crcs/vs
application programs and specific application programs in the 3651.
rrhe appli.cation program session is primarily intended for the
noninteractive data transfer of application-oriented information such
as:
•
~ransaction
log from 3651 disk to the CPU
• Inventory receipts file from 3651 to CPU
• Batch store messages and reports from the CPU to 3651
• TickE!t data to be used in the preparation of magnetic
stripe tickets on the 3651
In most cases, where CICS/vS is involved with application programs
in the 3651, the logical terminal in the 3651 is disk.
In some
applications, disk serves as an intermediate or staging area between
the CICS/VS application program and the ultimate destination. This
usage is not detected by CICS/VS.
Application program sessions may be initiated either by CICS/VS or
by the 3651 controller. When initiated by CICS/VS, the CICS/VS
application program issues a terminal control PROGRAM macro instruction
to identify the particular 3651 application program with which it wishes
to communicate. This 3651 program may then exchange data with the
CICS/VS program or may perform some function independent of CICS/VS as
specified by the user.
Anothf~r possibility is to initiate the session from the 3651
controller. This type of session occurs as the result of a user-written
program :requesting (through the RCP interpreter) to establish a session
with the host.
Application program sessions permit the following CICS/VS service
t,o be sUI::ported:
• Basic mapping support
The following services are not supported:
• Operator signon
• Terminal paging
• Message routing and switching
• Automatic task initiation
• Master terminal operator functions
• supervisory terminal operator functions
• Message recovery and resynchronization
Multiple input and output messages may be transmitted between CICS/VS
and 3651 application programs.
See the CICS/VS Advanced Communication Guide, SH20-9049, for further
information on the use of the 3650 by CICS/vS.
50
CICS/VS system/Application Design Guide
3790 Sessions
The 3791 controller is a programmable control unit, to which up to
16 terminals and 2 line printers may be attached. It is used in a
general-purpose data collection environment by many types of industries.
~he terminals are:
• IBM 3793 Keyboard Printer
• IBM 3277 Display Station
• IBM 2741 Communications Terminal
• IBM Line Printer
• IBM 3792 Auxiliary Control unit, remotely located
from the 3791, to which may be attached 3793 or 3277
terminals, and one additional line printer.
The 3791 Controller contains a diskette and up to 27.5 million bytes
of disk storage. Operation of the various terminals attached to the
3791 is controlled by the 3790 function programs.
A 3790 terminal operator can select an appropriate 3790 program to
accept data entered at the terminal, edit it, and store it on disk for
later transmission to the cpu.
General-purpose data entry editing
carried out by the 3790 program ensures that:
• Alphabetic fields contain only alphabetic characters,
and numeric fields contain only numeric characters
• Fixed-length fields contain the required number of characters
• Variable-length fields do not violate the minimum or maximum
length specified
• Required fields are not omitted
• self-check digits are valid
• Numeric fields fall within a specified value range
• Field values are valid based upon application criteria
such as a field's relationship to other fields, or to
data held in tables or stored on 3791 disk data sets
• Field values are valid based upon the existence of required 3791
disk data set records, or the status of a particular data set
record. For example, the 3790 program can ensure that an inventory
update that reduces "quantity on hand" does not produce a negative
quantity.
The 3790 can operate coropletely offline, accepting and editing data
from terminals, and storing it on disk for later batch transmission to
the cpu.
It can also operate online to the CPU, establishing sessions
between CICS/VS and 3790 FPs, which edit terminal input, pass input to
CICS/VS for further processing, and accept output from CICS/VS to direct
to the te'rminal. The 3790 is suited for remote offices where the
functions of data entry, data inquiry, calculation, and document
preparation are required.
Refer to An Introduction to the IBM 3790 Communication System,
GA27-2767, for further information on 3190 units and features.
Chapter 3.
CICS/VS Data Communications Design
51
CICS/VS application programs communicate with 3790 function programs,
do not support or directly interact with terminals controlled by
thE' 3790 programs. CICS/VS is not aware of any other function programs
which may be concurrently executing in the 3790.
These FPs may each
separately establish sessions with CICS/VS, or with other VTAM
npplication programs (such as IMS/VS) •
~nd
.3790 Host Inquiry Session: This session permits a 3790 FP to accept
t.ransactions from the terminals i"t controls and transmit those
transactions to CICS/VS.
Each host inquiry session is allocated the
specific terminal identification of its TCT entry. Any number of
CICS/VS transactions can be transmitted during a session, and each
transaction can involve several input and output messages.
3790 host inquiry sessions permit the following CICS/VS services to
he supported.
• operator signon
The following services are not supported:
• Terminal paging
• Message routing and message switching
• Automatic task initiation
• Master terminal operator functions
• supervisory terminal operator functions
• Message recovery and resynchronization
• Basic mapping support
The following restrictions apply to 3790 host inquiry sessions.
• TheFP must initiate the session.
unsolicited output from CICS/vS.
The 3790 cannot accept
• The .FP must start the exchange of data with a CICS/VS transaction
by issuing a PUT, and must issue a GET to receive the last output
from the CICS/VS transaction.
• The lmaximum input message is 240 bytes. However, several input
messages can be transmitted by the FP and be concatenated by the
CICS.IVS application program (through user programming) for input
qrea"ter than 240 characters.
• The
:~P
is responsible for the unchaining of chained output.
Refer to the CICS/VS Advanced Communication Guide, SH20-9049, for
further information on the use of the 3790 by CICS/vS.
ESTABLISHING CICS/VS SESSIONS WITH VTAM
sessions between CICS/VS and VTAM can generally be initiated either
from the CPU or from the logical unit. However, the 3790 must initiate
a session with the cPU.
It cannot accept a session initiated by the
cPU.
cPU s4?ssions are initiated by:
• CICS/vS automatically at CICS/VS initialization time
52
CICS/vS System/Application Design Guide
• VTAM system
operato~
• CICS/vS master
te.quest
termin~l
cperator request
• CICS/vS to automatically initiate a task for
a logical unit
Logical units initiate sessions by:
• the remote controller automatically at controller
initialization time
• the remote controller on terminal operator request
When a connection is established, CICS/vS allocates the logical
connection (and hence the logical unit) to a relevant TCT terminal
entry. The logical unit may then transmit transactions to CICS/VS for
processing. These transactions result in the initiation of CICS/VS
application programs the same as for BTAM-supported terminals. Refer
to the CICS/VS Advanced Communication Guide, SH20-90Q9, for further
details on establishing connections. ----CICS/VS application programs communicate with logical units by means
of terminal control or basic mapping support.
TERMINAL CONTROL COMMUNICATION USING VTAM
Each of the basic terminal control operations, READ, GET, WRITE,
PUT, WAIT, SAVE, and CONV~RSE, is available for cOItmunication with
VTAM-supported terminals.' ERASE, when used to erase the display screen
of a 3604 attached to a 3600, can only be specified using BMS.
Terminal I/O Overlap
VTAM permits terminal' I/O operations to proceed concurrently with
application program processing. This enables terminal I/O to be
overlapped with CICS/VS application program processing. The CICS/VS
application programmer can specify whether a terminal control request
is to be initiated immediately to communicate with a VTAM-supported
terminal while application program processing continues. The programmer
can check for completion of the request at a later time by iSSuing the
terminal control WAIT macro instruction.
Alternatively, the programmer may specify that a terminal control
request is not to be initiated immediately, but is to be delayed until
the program issues a terminal control WAIT macro instruction, passes
through a user-defined synchronization point, or terminates.
Delayed
initiation of VTAM terminal control requests provides compatibility
with the manner in which BTAM-supported terminals are controlled.
Further, it can ensure that no output is transmitted to a logical unit
until the task which generated that output is no longer vulnerable to
backout in the event of a system failure.
(See "Deferred Output
Integrity" in Chapter 8.)
Full-Duplex Transmission
VTAM supports full-duplex transmission of data between the CPU and
logical units. Thus, input and output may be proceeding concurrently
on the same line, to different controllers multi-dropped on that line.
CICS/VS enables the application program to request terminal input when
Chapter 3.
CICS/VS Data Communications Design
53
needed, and to direct terminal output to the relevant terminal or
logical unit when processed (halt-duplex processing).
Although CICS/VS application program~ process in ~ half-duplex mode,
for optimum line efficiency d?ta can stl.ll ~e ~ransml.tted by VTAM in
full-duplex mode. Logical unl.ts may transm1t l.nput to CICS/VS
application programs on an anticipatory basis. V~AM queues this input
until the relevant CICS/VS application program issues a terminal control
FEAD or GET macro instruction.
The input message has already reached
the CPU, and is then presented to the application program to satisfy
the request.
Function !"1anagement geader
output messages transmitted by terminal contrel to particular
VTAM-supported terminals require certain information within thE~ message
to identify the disposition of the output by the logical uni1;:. This
information is called a function management header (FMH) and c<:mprises
the first part of the output message. It is 3 bytes long for the 3600,
and is of variable length, 6 bytes or greater for the 3650. The FMH
comprises at least a length byte, a message· description byte, and a
logical dE!vice code byte. When used for communication with a 3275 host
conversational session in a 3650 it may also contain a BMS map name,
The message description byte indicates to the logical unit whether
the output. message was generated by CICS/VS itself or by a CICS/VS
application program.
It also identifies whether the output message
has already been formatted (either by BMS or the CICS/VS app1i,cation
program) and contains device-dependent characters. The logical unit
can deliver the formatted message to the relevant device with no further
processing, if required.
The logical device code (LDC) in the FMH identities the description
of the output by the logical unit.
(See "Basic Mapping Support
communication using VTAM" in this chapter, for additional information
about LDCs.)
It is the responsibility of the CICS/VS application program to insert
the appropriate FMH for the logical unit at the beginning of the output
message. See the CICS/VS Advanced communication Guide, and the CICS/vS
App1icatiOll Programmer's Reference Manual for further details.
SysteIll Proqrarnme.r MacrQ
Instruction~
Additional terminal control macro instructions are available for
use by the CICS/VS system programmer. These enable t.he status of a
terminal to be changed in the TCT, or a specific terminal entry to be
located in the TcT, using the terminal control STATUS and LOCATE macro
instructions respectively.
The result of these operations can be
checked using the terminal control CHECK macl."O instruction.
The STA'I'US, LOCATE, and CHECK terminal control macro instructions
are intendE~d primarily to be used by the system programmer in the
network error program (NEP).
The NEP enables the system progranuner to
attempt recovery of error exception conditions encountered with
transmission to VTAM-supported terminals.
See the CICS/VS Advanced Communication Guide and the CICS/VS System
Progranuner's Reference Manual, for further details on these system
progranuner macro instructions.
54
CICS/VS System/Application Design Guide
BASIC MAPPING SUPPORT COMMUNICATION WITH VTAM
The benefits of format (mapping) and terminal device independence
offered by BMS to BTAM-supported terminals are also available to
VTAM-supported terminals.
Input Mapping
BMS performs input mapping for the 3650 system (3653, 3270HC), but
does not perform input mapping for the 3600 or 3790 system. The 3601
application program associated with the logical unit is responsible
for removing device-dependent characters from the terminal input
message, It is also responsible for formatting input data prior to its
transmission to CICS/VS.
EMS MAP macro instructions are ignored, and
the input data is passed to the CICS/VS application program without
change.
BMS IN macro instructions result in BMS issuing a terminal control
GET macro for the application program. The received input data is not
mapped and is passed to the application program ~ithout change.
The application program may use the built-in function INFORMAT macro
instruction to locate delimiters inserted in the input message by the
3601.
(see "Input Transaction Design" in this chapter for additional
information. )
BMS Output Mapping
BMS performs output mapping for VTAM-supported terminals (except
for 3790). Device-dependent characters are inserted into output
messages by BMS based upon the characteristics of the device intended
to receive the output.
BMS constructs and inserts the function
management header (FMH) into the output message prior to issuing
terminal control output requests on 'behalf of the CICS/VS application
program.
The FMH has the same format as described in "Terminal Control
Communications using VTAM." The message description byte is set up by
BMS to define a formatted output message. The CICS/VS application
program identifies the output device to BMS for VTAM-supported terminals
by means of the logical device code (LDC). The LDC is used by BMS to
identify the page size and device type.
BMS inserts the LDC in the
FMH prior to requesting terminal control output. The CICS/VS
application program is relieved of the responsibility of constructing
the FMH. This permits programs to be written independent of particular
terminal characteristics.
Logical Device Code Uses
The LDC may be used to identify, to BMS and the APB, any 3600 device
(except the 3614) attached to a 3600 work station with an appropriate
page size. BMS uses the map specified by the application program to
format the 3604 output data.
It inserts the device-dependent characters
into the output stream to ensure that the data is displayed as specified
by the map. The LDC is also inserted into the output stream for
transmission to the 3601. On receipt of the data, the 3601 application
program determines (from the LDC) which device is to receive the output.
In addition to identifying specific devices and their associated
page size, the LDC can also communicate other information to the
controller application program.
For example, the LDC may identify a
specific preprinted form number to receive the output on a specific
printer, or on any printer available to that logical unit. The LDC
may also be interpreted by the logical unit as a request to turn on
Chapter 3.
CICS/VS Data Communications Design
55
(or off) particular terminal indicator lights, transmit data accumulated
on disk during offline. operation to the CPU, or change processing modes
(for example, change to after-hours processing operation) •
~he LDC is used by the CICS/VS application program to communicate
logical disposition of output to the logical unit, and can represent
any logical meaning useful to the installation's purpose.
CICS/VS permits the use of as many as 255 different logical device
codes.
E:ach may have a di ff erent weaning, dependent upon the pa rticular
controllE~r applica tion program interpretation.
Map Residence in controllers
Some VTAM-supported controllers, such as the 3651, permit formats
residE! outside the CPU on di sk in the controller for 3275 host
conversational sessions.
A EMS output request from a CICS/VS
applicati.on program results in transmission of the output data (without
mapping) and the format name in the FMH, to the remote controller. The
controllE!r retrieves the specified format from the 3651 disk, and writes
it to thE! screen on the relevant 3275 attached to the 3651. Thus, CPU
processing is reduced, and additional flexibility is available to the
installa t:ion to tailor a general purpose map to specific 3650 systems
in individua 1 retail stores.
t.O
EMS Al any! Indi ca tor
~he CICS/VS application program, using EMS, can request that an
alarm indicator be turned on at the terminal upon receipt of the output
message. This alarm indication is transmitted by EMS to the logical
unit by means of the function management header (FMH). The logical
unit responds to this request by turning on an appropriate indicator
light on the terminal that is to receive the output.
EMS I/O Overlap
The CICS/VS application program can request that a BMS operation,
and the associated terminal I/O, be initiated immediately.
Alternati.vely, the program can request that the BMS operation be delayed
until a WAIT macro instruction is executed, the program passes through
a user-dE~fined synchronization point, or the program terminates.
This
immediatE~, or delayed, request is specified as part of the BMS macro
instruction in the manner described in "Terminal Control Communication
using VT]~." It has the same purpose as for terminal control: to
provide compatibility with BTAM operation and to improve output message
integrity.
TERMINAL DEVICE INDEPENDENCE WITH VTAM AND BTAM
The use of BMS permits CICS/VS application programs to be written
independEmt of the particular terminal to be used.
For VTAM-supported
terminals, default options provide compatibility with BTAM supported
terminal operation. For example, the default option (unless specified
otherwisE~) is to delay the initiation of terminal I/O until the
application program issues a WAIT macro instruction, passes through a
user-defined synchronization point, or terminates.
If a ]~DC is not specified in a BMS request to VTAM-supported
terminals, a default value is used. This can be specified when the
TCT is gE~nerated as a unique value for a specific TCT entry, for a
group of entries, or for all entries in the TCT.
If, however, a LDC
56
CICS/VS system/Application DeSign Guide
is specified in a BMS request to BTAM-supported terminals, i t is
ignored.
BMS requests which specify 3270 attribute characterists can be used
with VTAM supported terminals.
In this case, the 3270 attribute
information is ignored. The same function may be specified either in
the particular map associated with the VTAM-supported terminal, or in
the program in the remote controller which receives the output.
For these reasons CICS/VS application programs can be written to
communicate with a variety of BTAM- and VTAM-supported terminals.
Unique device characteristics may be specified in a map generated
specifically for a terminal to achieve a general format function
required by the CICS/VS application program. The CICS/VS application
program identifies a map name in its BMS request; BMS appends to that
map name a character which identifies the particular terminal type
which is communicating with the program. BMS then retrieves the unique
device-dependent map for that terminal type and uses it to format the
terminal data.
Consequently, existing BTAM-supported terminals may be used to test
CICS/VS application programs intended primarily for operation with
VTAM-supported terminals before the installation of the VTAM terminals.
Alternatively, sequential terminals, such as card reader / line printer,
disk, or tape, may be used for testing.
However, testing must model
the operation of remote controller programs. For example, input must
be presented to CICS/VS in exactly the same format as would be presented
by the remote controller. Output must be accepted from CICS/VS as
presented to the remote controlle~.
In the case of input mapping for
testing for the 3600, the mapped input from BTAM-supported or sequential
terminals must be the same as presented by the 3601. This is necessary
because mapping with actual 3600 input is ignored, and the input data
is presented to the application program without change.
Testing is limited to those operations which can be performed by
the relevant testing terminal, or which can be preplanned in the test
input. BTAM-supported and sequential terminals are unable to exercise
the same data handling and processing capability possible with remote
controllers.
TERMINAL PAGING USING VTAM
Some sessions established with remote controllers support terminal
paging.
(See "CICS/VS Session Types.")
The CICS/VS application program
can build pages to be associated with specific logical device codes
used by a logical unit.
BMS separately controls the page construction
for each LDC, and then makes available all pages built for each LDC
used by the logical unit.
The terminal operator at the remote controller can request that
pages associated with a particular LDC for that logical unit be
displayed.
(See Figure 3-3 for terminal paging commands.) The
appropriate LDC pages desired can be requested by appending the LDC to
the terminal paging command; all LDC pages can then be displayed on
request.
However, any LDC pages which have not been viewed will be
lost when the terminal operator requests purging of pages associated
with the logical unit.
MESSAGE ROUTING AND MESSAGE SWITCHING USING VTAM
Some sessions established with remote controllers support both
message routing and message switching.
(See "CICS/vS Session Types. It)
Pages, built by CICS/VS application programs or by terminal operators,
Chapter 3.
CICS/VS Data Communications Design
57
can be associated with particular logical device codes for transmission
to one, or a group, of logical units. The only restriction is that
the same LDC be associated with all logical units in a message routing
or switching request.
Pages delivered to the specified logical units can be viewed by the
terminal operator using the appropriate LDC appended to the terminal
paging commands as described for "Terminal Paging using VTAM" in this
chapter.
The basic concepts and facilities of:
• Basic mapping support
• Terminal device independence
• Terminal paging
• Message routing
• Virtual Telecommunications Access Method
(VTAM)
have now been outlined.
The remainder of this chapter describes
techniquE~s for using these CICS/VS facilities in data communications
design.
The effectiveness of an online application depends to a large degree
on man-machine communications.
The computer is a tool used to achieve
+he objeetives of the online application. To ensure success of online
applications, the computer must provide the user with information to
enable him to carry out his function effectively.
Data communication design represents the interface between the
application and the machine.
This is particularly true for
conversa ~tional application design.
At all times during conversational message design, the system
designer must keep in mind that the main objective of an online
application is to assist the terminal operator. ThUS, message formats
should b49 designed to make the terminal operator's job easier.
For
example, input message formats generally should not be deSigned as
fixed-fo:rmat messages as for a card, but should enable the terminal
operator to enter information in a variable-length format. CICS/VS
can convert the variable-length input message into a fixed-length format
for processing of the application program, as discussed below.
Also, if the task response time for a terminal operator is limited,
the oper;ator should be inforrred of the interval in which he is expected
to respond.
TASK INI'TIATION
CICS/VS determines whether an input message received from a terminal
satisfies an outstanding read request placed for that terminal by a
currently executing program.
If no application is currently active
for the 'terminal which originated the input transaction, a task is
initiated to process it.
58
CICS/vS system/Application DeSign Guide
Task initiation refers to the identification of a particular input
transaction, the program to be used, and the creation of a task to
process the transaction. Transaction identification can be achieved
in several ways, as shown in Figure 3-5.
Chapter 3.
CICS/VS Data Communications Design 58.1
INPUT
CICSNS PROCESSING
OUTPUT
1. Use permanent
transaction code
if specified in TCT
during SYSGEN
Appli·
2. Use temporary
transaction code
if specified in TCT
by prior program.
• Transaction Code
(1·4 Chars)
• Temporary
Transaction Code
cation
Program
3. Use PA, PF or
light pen as
transaction
code, if utilized
by terminal
operator
• Permanent
Transaction Code
4. Use first 1 through 4
characters of input
message as trans·
action code.
•
Program Attention
(PA) Key
•
Program Function
(PF) Key
5. Scan PCT for
transaction code
as identified in
steps 1 through 4
above.
Program
Control
Table
(PCT)
6. If found, deter·
mine relevant
program.
7. Allocate TCA,
load program if
not in storage,
aM transfer
control.
• Selector Light Pen
Extended Description
. , . Only one of steps 1 through 4 is used to identify the
transaction code.
iii
figure 3-5.
Task Initiation
The first one to four chaxacters ef a ter.inal message, deli.ited
by a defined character, arE used as a transaction code. Valid
transaction code delimitEr characters are the field name start character
or field separator character (both of which can te defined in the system
initialization table), and any cede with a hex value less than or egual
to X'40'. The transaction cede is used to search the prcgram control
table (PCT) to identify that transaction code. Cn locating the
appropriate entry in the PCT with thE samE transaction code, the namE
of the program to be first used to pxocess the transaction is obtained.
CICS/VS then creates a task ccntrel area (TCI) to control thE processing
of the transaction by the prcgram. The PCT can also identify the size
of a transaction work area (~WA) to be appended to the TCA and used as
a program work area during processing.
The program na.e identified in thE PCT entry is located by CICS/VS
using an address pointer in the ~CT Fointing to the relevant program
entry in the processing program tatle WPT)~ The PPT entry for that
program indicates the language in which it was written (Assembler,
COBOL, or PL/I), the size of the pxograa in bytes, whether it is
presently in CICS/VS address space and if so, the nu.ber of other tasks
concurrently using it, and the lccation of the program on the CICS/VS
prograa library on disk. If the program is not already in CICS/VS
address space, it is loaded from the program library and control 1s
passed to it to process thE transaction.
ChaptEr 3.
CICS/VS Data Co.munications Design
59
J~lQ A!!jmti~211 112 1!!D.§Jcti2J1 !ii!i.!ti~D
In the case of the 3210 Information Display System, each of the
three PrcgraD Attention (PA) cr twelve Program Punction (pr) keys or
the selector light pen can bE defined in the PCT tc initiate specified
programs.. By prEssing the relevant PA or PP key, or by selecting a
pen-detectable field with the selectcr light pen, the appropriate
program is initiated. This is equivalent to entering a transaction
code of from one to four characters.
The use of the selector light pen for transaction initiation is
discussed in more detail in UMultiple Choice Pormat" later in this
chapter.
On completing the processing cf an input transaction, an application
program optionally may identify thE transaction code to be used with
the next input sent fro II tha t terminal. 'l'he next input need not be
preceded by any transaction code, or PA or pp' key, or be selected by
the light: pen.
This ~rogram-identified transaction code is referred to as a
temporary transaction code, and is specified in the program control
RETURN macro instruction prier te termination of a task associated with
that terminal. This temporary transaction code is used, with the next
input from the terminal, to identify a program to be used to process
that input. Any PA, Pl, light pen, or transacticn code in the input
is ignored. After use, the temperary transaction code is removed, and
must be reestablished by a subsequent RETURN macro instruction, if it
is to be used with further input from the terminal. Therefore, an
application program can transllit a response to a terminal requesting
further informatien from the operator. The next transaction code to
be used is set by the prcgraa so that, when the requested. information
is supplied by the operator, the program to process that inf~rmation
will automatically be initiated.
A permanent transaction code can te defined for any CICS/VS terminal,
at the time the CICS/VS terminal control table (TCT) is generated.
This is particularly useful for those terminals lIhich, by the nature
of their device characteristics, are unable to start an input
transaction with a valid transaction identification. In this case,
every input message is initially passed to the saae application program,
which is related to the permanently defined transaction code for that
terminal. This application program Examines the input to determine
the processing required, and identifies subsequent application programs
which operate on that transaction. The permanent transaction code. is
used with any input message froa a terainal which does not satisfy a
pending read request issued by a program. It also overrides any PA,
PF, selector light pen, or transaction code used in that aessage. A
temporarytran~action code cannot he used with a terminal utilizing a
permanent transaction code. certain tTAB sessions established for the
3650 or 3790 require that a permanent transaction code be specified in
the relevant TCT entries for the sessions.
(See "CICS/VS Session Types"
in this chapter.)
60
CICS/VS system/Application Design Guide
INPUT TRANSACTION DESIGN
The following design techniques for input messages may be used for
terminals attached directly to CleS/VS or for terminals attached to
programmable ccntrollers such as the 3601, 3651, and 3791.
The fixed-format technique relates to the design of input messages
such that each field of informaticn occupies a fixed location in the
input message (see Figure 3-6). While this is the normal technique
for design of transactions entered from cards, it is not generally
suitable for conversational applications. While a fixed message format
makes it easy for the application program to extract information from
the message for ~rocessing, this technique makes it more difficult for
the terminal operator to enter that information, and is subject to
operator error.
The variable-format technique is similar to the fixed-format
technique previously described, exceFt that required fields need not
always be located in the same positions in the input message (see Figure
3-6). Fields are identified by their relative positions within the
message as for fixed-format messages, tut each field is separated from
ethers by a delimiter character or characters. Possible delimiter
characters are the blank, slash (/), equal (=), comma (,), or dash (-).
Using delimiters, the terminal operator can enter information in the
required sequence, without ccncern for the actual physical location of
fields within the message.
CICS/VS provides a built-in function, which uses an input formatting
macre instruction to ccnvert this variable-format message into a
fixed-format message for processing by the application program. Pields
are located in the input message based upon the field separator
character, which is a delimiter character defined ty the user at CICS/'S
system initialization time. TheSE fields are inserted by CICS/VS in
the appropriate locations in the converted fixed-format message based
upon the requirements of the application program. Befer to the ~~
!REli£~!iQn R~Qg~ABB~~§ I§!§.~DS§ ~§nY§l, SH20-9003, for aore details.
Consequently, the terminal operatcr can enter the required
information in the specified sequence, without ccncern for the actual
physical location of that information in the message transmitted to
the cPU. The input message is converted to fixed format and presented
to the applicaticn program as if it had been entered by the terminal
operator as a fixed-format message. This enables the terminal operator
to enter the input message in variable format suitable to him, yet-be
presented to the program in fixed format for easy processing.
Chapter 3.
CICS/VS Data Communications Design
61
FORMAT ENTERED AT TERMINAL
I1362.st'J IJON ES.s.s.s~~~~~.s~.s~~ IJA I314-AZ I
(t'J IS BLANK)
---------------'
US:CT.CUSTOMER NAME
~
NO.
\INITS\CUST.
REF. NO.
I
FORMAT PRESENTED TO PROGRAM
------~--~--~
FIXED-FORMAT MESSAGE
-----------------------~
FORMAT ENTERED AT TERMINAL
COMMA IS FIELD SEPARATOR
CHARACTER (MAY ALSO USE
~,./ -)
~
UST·I
CUSTOMER NAME
NO.
_ _ _ _ _ _- - ' _ - - - . . J L - -_ _- - - - '
AFTER PROCESSING BY CICS!VS
INPUT FORMATTING MACRO
INSTRUCTION
VARIABLE-FORMAT MESSAGE
,--------------------'"'"'
FORMAT ENTERED AT TERMINAL
INO=1362,IN=JA,NM=JONES,RF=314-AZ I
[]EC
UST.
NO.
-
CUSTOMER NAME
_ _. _ _ _ _ _ _- L - _ - ' -_ _ _........
EQUAL SIGN IS FIELD NAME
CHARACTER
COMMA IS FIELD SEPARATOR
CHARACTER
AFTER PROCESSING BY CICS!VS
INPUT FORMATTING MACRO
INSTRUCTION
KEYWORD-FORMAT MESSAGE
Figure 3-Ei.
Fixed-, Variatle-, and Keyword-Format Input Messages
This tE!chDic;Jue can be usee wi th CICS/VS application programs designed
to process input from the 3600 Finance Communicatien System. EMS does
not map input data from a 3601 ccntroller, but passes it to the
applicatic)D {:rogram wi thcut change.
(See "Basic Mapping Support using
VTAM.") Therefore, the 3601 Contreller can format the input message
prior to transmission to CICS/VS fer processing ty the CICS/VS
application program by using the built-in function INFORMAT macro
instruction. This formatting involves insertion (by the 3601 AF) of
delimiter characters in a variable fermat message entered from terminals
attached to the 3601. The same delimiter characters defined by the
user at CICS/VS system initialization time shoule also be used by the
appropriate 3601 APs which prepare the input for transmission to
CICS/VS.
62
CICS/VS System/Application Design Guide
This format is similar to the variable-format Dessage described
above, except that each field is preceded by a field name start
character (defined at system initialization time) and a unique keyword.
The keywcrds and fields can be variable format. Eecause each field is
identified by its appropriate keyword, the sequence of fields in the
input message may vary.
The terminal eperator enters information in variable format, in the
sequence which is best suited to his requirements. The CICS/VS input
formatting macro instruction locates each field based on its keywQrd
and positions that field in a fixed-format message presented to the
application program. If a particular keyword is emitted, that field
is left blank in the converted fixed-format message.
Both variable-format and keyword-format information can be included
in an input message. The eICS/VS input formatting macro instruction
can process both input techniques as part of the same message.
Figure 3-6 illustrates typical fixed-, variable-, and keyword-format
ipput messages.
Keyword-format messages offer maximum flexibility to the terminal
operator, not only in the positicning ef informaticn in the message,
but also in the sequencing of information in the message. However,
the information can still be presented to the application program in
fixed format for processing.
A disadvantage for the terminal operator, however, is that he must
accurately key in additienal infcrBation, namely, the keyword for each
input field. This additional keying takes time and is vulnerable to
error, although it provides positive identification of each field.
Because this keyword fermat permits a number of input fields to be
present or absent, depending upon the characteristics of the
application, it could in some instances result in less keying than for
variable-format messages.
The keyword format technique can also be used for input from a 3601
controller, as described in "variable Format Messages." The additional
keying overheads of the keywcrd format technique are a consideration
with input from 3601 controllers. The terminal eperator can enter
input to the 3601 in any cenvenient format. The 3601 AP can then insert
the necessary keywords and delimiter characters before transmission to
CICS/VS.
lill=in=!h~~lgD~§ l~~~!
This message format acccmBodates the inexperienced terminal operator.
It involves the display of descriptive informaticn identifying each
field to be entered, as illustrated in Figure 3-7, and applies mainly
to display terminals.
The most useful approach is to display an image of the information
normally provided on the input dccuments used by the application. For
example, an image of a product order form Bay be displayed for an order
entry application. The terminal operator, using the description
preceding each field, enters the Iequired information. In the case of
the 3270, only medified fields, such as that infcrmationentered from
the keyborad, will be transmitted to the computer. The descriptive
information is net transmitted, unless specified by the application
prcgram for identificaticn purposes. Each input field transmitted from
a 3270 is identified by its kuffer address. This buffer address is
Chapter 3.
CICS/VS Data Communications Design
63
WORK ORDER REQUEST FORM - FILL IN BLANKS
WORK ORDER NUMBER: 1 23466
DEPT.NO.:~
[!::]
lONE:
I
STATUS:[~
MONTH:
[2J DAY: ~J YEAR: ~
DEPT. NAME: 1 MAINTENANCE
AREA:
EQUIPME~n NAME:
I
G:=J
PRIORITY:
~
]
TYPE:
PROJECT NO.:
0
HOUR:
[!2J
MIN:
~
13090 I ACCT. NO.: ~
EQUIPMENT NO.: 1...._2_13_3_---1
BOILER FEED PUMP - UNIT NO.2
REQUESTER: 1
WORK ORIOER TITLE: 1
:-
J. JONES
J
EXTENSION:
~
BOILER FEED PUMP MAINTENCE
WORK REC}UEST: [YOILER FEED PUMP NO.2 LEAKING
C
I
EXCESSIV~LY
.----.----~------===:J
HARD COpy REQD.:
W
, - - -_ _ _ _ _ ,._ _ _ _,_ _ _ _ _ _ _ _ _ _ _....J
~
Figure
3-~1.
Fill-in-the-Blanks Input Message Format
used by tasic mapping support (BMS), in conjunction with the input map
defined for the transaction, to idEntify each input field and map the
input message into a fixed-fcrmat message. Figure 3-7 illustrates a
typical fill-in-the-blanks input message format.
An example of the use of this technique is found in the Dispiay
Management Systea II (prcgra8 numbers 5736-XC4 for DOS/VS, and 5736-XC4
for OS/iS). RefEr to "Belated Publications" in thE ~reface for relevant
DMS II publicaticns.
~.Yl!iJ21~
!;ho i~~
l.Q~'!!.5l!
This fc)rmat USES the cptional selector light pen on the 3210
Information Display System and involves the display of a number of
pen-detectable fi-elds. These fields present a series of multiple
choices, one or several of which can be selected by the terminal
operator by placing the light pen to the pen-detectable fields to be
selected.
The output response froa a previous application program may define
certain fields displayed on the 3270 screen as pen-detectable. Such
pen-detectable fields are identified by a guestion mark, "greater than"
(» symbel, or blank character at the start of the field.
A
pen-detectable field with its first character blank is referred to as
an "imm~diate" field.
64
CleS/Vs system/Application Design Guide
The appropriate choicES are made by the operator, by simply touching
the light pen to the relevant fields. A guestion mark is changed to
a "greater than" (» sign to signify selection of that field. The
greater-than character is changed tack to a gUEsticn mark if the field
is selected by the light pen a second time, to indicate that the
previous selection of that field is to be ignored. Selection of an
immediate field (first character blank) results in the transmission of
a message to the cpu. This message contains only the buffer addresses
of fields selected by the ~en and changed to a greater-than character.
The attention ID (AID) character transmitted from the terminal on
selection of an immediate field is used to locate the PCT entry for
immediate pen-detectable fields, and to transfer control to a common
user-written program. This ~rogram examines the tuffer addresses
representing selected fields, and interprets these selections through
the last BMS map used with that terminal. When designing pen-detectable
screen formats, each screen format to be supported by this common
program should be identified.
Another technigue for multiple cheice input is for the application
program to list (or display) several choices, identifying each choice
by number. The terminal elerator maj then select an appropriate
response by keying in its identifying number.
Figure 3-8.
Multiple Choice Input Message Fermat
Selection of multiple choice fields can be used by unskilled terminal
operators in user deFartoents, te enter information for online
Chapter 3.
CICS/VS Data Communications Design
65
applications. Figure 3-8 illustrates a typical multiple choice input
message format using pen-detectable fields.
Any of these transaction formats may be used for terainals which
communicate with eleS/YS either dil:ectly or through programmable
ccntrollers.
TRANSACTION EDITING
After defining the aethods to be used for transaction initiation
and designing the input message formats, the editing and validation to
te perfor~ed on the message ty the CtU or programmable controller must
te definet:!.
with the combination of Bes and the eleS/YS input formatting macro
instruction, the applicaticn program is presented with an input message
in a defined fixed format. The editing to be done by the application
program is application-dependent; Figure 3-9 suggests sOlie of the
techniques available. Seme of these editing techniques are supported
by eleS/YS built-in functicns, while others aust te supported by
user-written routines.
--_._----------_._......_- ----
1362, JONES, JA, 314-AZ, 843.21
6148, SMITH, HW, 031492, 6332.50
3882, BROWN, AA, 1131,28.00
5199, WILSON, JJ, 00316, 93998.60
TOTALS
101202.31
TRANSACTION EDITING TECHNIQUES
• FIELD VERIFY/I:DIP- ALL ALPHAISETIC (A-Z)
- ALL NUMEf1:IC
(0-9)
- ALL PACKEI) DECIMAL
• LIMIT RANGE
• TABLE SEARCH"
-BINARY
- SEQUENTIAl.
• CHECK DIGIT
-MODULUS 10
-MODULUS 11
• HASH OR CONTIFlOL TOTALS
• ZERO PROOF TOTALS
•
•
•
•
REASONABLENESS CHECK
DATA seT CHECK
SIGHT VERI FICATION
KEY VERIFICATION
"'CICStvS MACR:O INSTRUCTIONS AVAILABLE FOR APPLICATION! PROGRAM USE
Figure 3-9.
Transaction Bditing Techniques
Built-in functions are not supported by the subset option of
eleS/DOS/"S.
(See "eleS/DeS/VS Subset option" in Chapter 7.)
66
eleS/VS system/Application Design Guide
Many of these techniques may te iaplemented by the user in
programmable centrcllers tc ~rovide for detection and correction of
invalid data before transmission to the cpu. Editing of data at the
time of initial entry at the source permits: earlier detection of
errors, more efficient data transmission, and reduced cpu processing.
with the offline capability cf ETAM ~ufPorted prograDmable controllers
such as the 3735, 3740, and lTAM supported programaatle ccntrollers
such as the 3600, 3650, and 3790, data entry application availability
is enhanced. Data may be edited and cellected offline on disk storage
for later transmission to CICS/VS. Only validated data need be
transmitted to the cpu. Thi~ data may be transmitted at line speed,
resulting in significant time and cost savings.
crcs/vs provides editing macrc instructions as built-in functions
to enable the centents of a data field tc be verified as either
alphabetic or numeric. On determining the contents of the data field,
CICS/VS tranches to the ap~rcpriate routine in the application program.
Any field may be checked fer the fcllowing:
• Entirely alphabetic (blanks, or A to Z)
• Entirely EECtlC numeric (0 tc 9)
• Entirely packed decimal
DECI eAL in PI/I)
~OMEUTATICNAL-3
in ANS COEOl or FIXED
If alphabetic characters have teen entered inte a data field that
must be all numeric, the CICS/VS field verify function enables control
to be passed to a user-specified routine. Usually an error message is
sent to the terminal operator notifying him that ncnnumeric data was
entered in the particular field.
The crcs/vs field edit fUDction allows the application program to
present a field centaining BECDle numbers intermixed with ether values
(for example, part number 119-445/E) to CICS/VS, and receive a result
with all nonnumeric characters remeved. The result can be in EBCDIC
decimal format. In effect, this function is the reverse of editing
(that is, a de-edit cperation) that is performed en a field for output.
See the ~1~~L!~ J~~li£~!i2~ fIsg!~!!~!§ ~§!~I§Df~ ~~Y~l, SH20-9003,
for additional information.
Numeric fields may be checked by user-written routines for validity,
ty means of a check digit apFended to the end of the field. Modulus
10 or Modulus 11 check digit editing is provided by the user program
to verify the correctness cf a field or to identify errors. This
technique can be used for an identification field such as a part number.
When the number is first assigned, a user pregram computes the revelant
check digit and appends it tc the identification number. The check
digit is then considered an integral part of the number, and can be
used to check the accuracy of the entered number whenever that number
is referenced.
contrcl totals can be developed by user programming of specified
fields in a number of transactions. Contrel totals can also be
developed for a batch of transactions and co_pared by the user program
against similar control or hash totals developed manually prior to
entry of the batch into the system. If the program-developed and
Chapter 3.
CICS/VS Data Communications Design
67
manually developed totals do not agree, the particular error or errors
can te located by comparing the information entered in that field with
the origine original source inforDation for each transaction in the
batch.
!!~2 ~Qj~ ~2!~1§
Generally, zero proof tctals operate on a numter of data fields
within one transaction. !hese fields are added and subtracted together
according to the requirements of the application. A nonzero result
indicates an error in one cr several of the fields. !his editing
technique may be supported by uSEr-written reutinEs.
!his technique checks that the value in a data field lies tetween
certain application-dependent limits. A field lying outside those
limits is identified as an error. The user is resFonsible for
developing this Editing sUFPcrt.
Iul.§
Sej~ch
!his editing techniquE USES the data field contents to locate a
similar entry in an application-depEndent table. If the exact field
contents cannot te located in the table, an error is indicated. A
substitute value can be presented to the applicaticn program, if
required.
CICS/VS provides a tatle search built-in functien to assist
application programs in utilizing tables for transaction editing or
processing. Either a sequential or a binary table search may be
specified. Refer to the ~1&~!~ JRR1!cotion f.QSX~.~.!§ l!fe,e~
ManUAl, SH20-9003, for more information.
B ej§Qlllll!.!l!§§ ~u~1s
!he program applies various legical tests (prcvided by user-written
routines) to the ccntents cf a data field, to determine the
reasonableness of that informatien as related to the particular
application. If the contents of the field have not met the application
criteria, it is identified as having an error. For examFle, the program
may examine a prcduct number entered as part of an order en~ry input
message, .in relation to the quantity of that product ordered. The
application may require that certain products only be ordered in
particular quantities. An ordered quantity outside that defined for
the predu
1. Receive input message from
terminal.
2. Edit input message and send error
message back to terminal.
3. Write original input message to
temporary storage.
Enter
Correct
Field
Temporary
Storage
>
(
>
OUTPUT
Display
Error
Message
>
T.m,",,,, (
:>
Storage
4. Receive corrected field from
terminal.
5. Retrieve original input message
from temporary storage.
6. Combine corrected field with
original input message.
7. Re·edit input message, and process
if no error.
Figure 3-10.
>
I
Edited Input Message
I
Error Field Correction
ChaptEr 3.
CICS/VS Data Communications Design
71
.Y§.§
Q!
~§"I!.£Q'!;li.I ~!Q~~!
If the terminal operator is required to input only the field in
error, the applicaticn program must sale the valid sections of the
input transaction. Temporary storage enables application programs to
save data either in dynamic storagE or on disk, identifying the data
uniquely for later retrieval by the same program cr another prcgram.
As the ter.minal operator may take some time to enter the necessary
correction, the valid part of the input transaction should normally be
stored in temporary storage cn disk, rather than in dynamic storage.
Dynamic storage may then be utilized more efficiently fOl other
purposes.
When transmitting an error message to a terminal, the application
program may set a temporary transaction code (see "Task Initiation" in
this chapter). Using this, when the cerrected field is retransmitted
from the terminal, a unique correction program may be initiated, based
on the temporary transactien code, requiring no further action by the
terminal operator other than correction of the field.
The user's correction program retrieves from temporary storage the
transaction that was originally entered by the terminal operator. The
corrected field is then inserted in place of the error field, and the
entire transaction is rEedited te determine whether the correction is
valid, and that no ether errers have been introduced. In the event of
other errors being detected, further error messages are sent to the
terminal operator.
The error correction prccess may be iterative until the input
transaction has teen completely validated. In the event that the
terminal cperator is unatle to correct the transaction, he should be
allowed to enter a unique code (such as "CANCEL") instead of the
corrected field, indicating that this error transaction is to te
ignored. The transaction will then need to te ccmpletely reentered at
a later time.
OUTPUT
FORMA~TING
The actual format of output responses is application-dependent.
However, a number of guidelines Day prove useful here.
The output response is the main interface between the online
application, under the centrel of the computer, and the terminal user.
Accordingly, it should be easily read and understood by a typical user
of that online application.
The amount of informaticn that Dust be presented in response to an
input reguest depends upon the requirements of that request. For
example, an inquiry requesting display of a customer's current account
balance is a request for specific information. However, a request for
display of a customer's account details generally requires all
informaticn relating to that acccunt.
Depending upon the particular terminal device bEing used, the amount
of inforDatien te te displayed may eXCEed the physical capacity of that
device. For example, a 3270 Model 1 displays 480 characters in 12
lines of qO characters per line. !he display of 15 lines of information
requires that information be trokeD into two pages.
The use of terminal paging in CICS/VS enables considerable
flexibility to be achieved in output formatting, rEgardlESS of the
72
eICS/VS System/Application Design Guide
physical capacity of the terminal which will receive the output.
feature is available only for BMS-suFPorted terminals. Refer to
"Terminal Paging" for further detail.
This
Batch applications are generally associated with high-speed data
transmission terminals such as the 277C, 2780, 3600, 3650, 3735, 3740,
and 3790, or comFuters used as terminals, such as the system/3 Models
6 and 10, the System/7, cr the System/370.
In this envircnment, the emphasis is on the transmission of data
from the terminal (or remote comFuter) to the central computer. Because
of the nature of these devices, they are not designed for easy terminal
operator interaction as is the case for conversational terminals.
Generally, a batch of transactions is transmitted to the central
computer, which Frocesses that batch and then transmits any error
messages back to the remote terminal or computer.
This online application ervironment is similar to the normal batch
processing environment. In both cases, a batch cf transactions is read
and Frocessed, and error messages are produced in an error list for
offline correction.
This application approach is useful in an online environment where
considerable amounts of informaticn are to be transmitted across long
distances. A high-speed batch terminal is able tc transmit larger
volumes of information than a ccnversational terminal, thus utilizing
expensive long-distance transmission lines more eccnomically. In this
instance, the emFhasis is cn transmitting the data to the central
computer as quickly and efficiently as possible, Editing that data,
and then transmitting any errcr messages back to the remote location
quickly and economically.
ASYNCHBONOUS TRANSACTION EEOCESSING
ClCS/VS provides a fUDcticn, called asynchronous transaction
processing (ATP), which is designed for easy implementation of batch
applications. ATP allows transactions, and the data associated with
those transactions, to be transmitted in batches. Each batch is given
a unique identification by the terminal operator. CICS/VS accepts each
transaction frem a batch ter.inal and delays its initiation until all
specified input tatches have teen transmitted.
ATP requires that transient data intrapartition file support be
generated as part of the user's CICS/VS system. This enables ATP to
save batches of data for future Frecessing and editing.
When all input batches haVE been transmitted, the transactions within
the batch are then processed by apFlicatien programs based upon their
respective transaction cedes. Any Error messages are directed by the
editing program to transient data for later trans.ission back to the
terminal.
When the batches have CCD.Ileted processing, the terminal operator
may thEn request that the eutput, if any, be sent to the terminal that
originated the batch, or to a different terminal. Depending upon the
amount of processing tc be carried out on transmitted batches, the
batch terminal may be disconnEcted from the transmission line by the
user until output is available tc be transmitted back to it.
The AiP facility is designed specifically for handling input from
batch terminals such as the 3780, 2780, or 2770. Generally, ATP can
Chapter 3.
CICS/VS Data communications Design
73
be used from other interactile terminals (such as the 2741). However,
~TP does not support input from 3210 or 2980 terminals.
Also,
application programs which intend to execute under control of ATP must
not use the BMS terminal ~aging macre instructions. Figure 3-11
illustrates the use of the CEDE and CiTE ITP commands, which are used
respecti l ely fer input and output of batched data.
j
The sulbset option of CICS/DOS/VS does not support ATP.
CICS/VS AND APPLICATION
PROGRAM PROCESSING
INPUT
~
c::J
CRDR NAME=BATCH1,DELlM=$$$$,
PASSWD=PA Y0061,EXIT=A 1
m
~
(
~
,-L
r
1
r
L
>
TRNA
-'
TRNC
data
nlNB
$$$S
data
~
TRNA
T"",;,,,
]
Data
CWTR
[iJ
1. Operator enters CRDR
command specifying A TP
input.
2. ATP allocates batch
queue in transient data.
$$$$ HOLD
$$$$
data
(
CWTR
I
NAME=(BATCH1,BATCH2),
SOURCE=TRM1,PASSWD=PAYOO61,
COPIES=2,EXIT=A2, SAVE OR
RELEASE OR DELETE OR STATUS
I,
OUTPUT
I
DJ~'>
3. Transactions are transmitted to CPU and
written to batch queue
by ATP.
{
1
m
4. At end of all input
batches, they are
scheduled for processing by application programs.
.>
5. Application programs
direct output to transient data.
>
0""'0""""
command, requesting
ATP output.
>
Transient
Data
CWTR
7. Output is sent to requesting terminal by
CICSIVS ATP program.
>
Processing
Program
Transient
Data
~
From
Processing
Extended Description
Operator specifies batch name in CRDR command, and optional delimiter characters for
batch, password to prevent unauthorized
access to output, and user exit routine for
extra proce5sing.
Figure 3-11.
iii Two consecutive delimiters
L:.II
indicate batch end. Batch
can be held or saved if not
finished.
r.:I
CWTR command identifies batch
~ name(sl. password source terminal(s) and number of copies. Us~r
exit can be specified. Batch can
be saved, released or deleted, or
status may be requested.
ATF Terminal OFerator Commands
GENEBAL fATCH FROCESSING
Some guidelines are presented below to assist in the design of batch
applications when the design team does not wish to use ATP.
Execution of a batch applicaticn is, by its nature, of long-term
duration. Accordingly, any Etorage required in executing batch
application programs will be in use for a relatively long time, compared
to conversational applications. Depending upon the amount of dynamic
storage available for both batch and cenversational applications, this
requirement for long-term stcrage may affect th~ ~Erformance of
conversational a~plications. Tc minimize the amount of storage used
by batch programs, the following aFproach may be ccnsidered.
14
CICS/VS System/Application Design Guide
Ideally, an application program should be written to accept batch
input transactions from the terminal, and queue these transactions on
transient data.
At the completion of each batch, the last transaction
may automatically initiate a user program to validate and process the
queued batch. In the meantime, the remote terminal is freed to allow
further data input. On completion of batch processing, any error
messages which were queued on transient data to send back to the remote
batch terminal may be either automatically transmitted back as soon as
that terminal is idle, or transmitted on request by the remote terminal.
This approach is similar to that adopted by ATP as described
previously. It offers the principal advantage of very efficient
utilization of data transmission lines, and the overlapping of
processing one batch with the transmission of the next batch to be
processed. On the other hand, ATP enables all input batches to be
transmitted to the CPU, and then allows the user to disconnect the
batch terminal from the transmission line until all of those batches
are processed. At that time, the user or the CPU may reestablish
connection between the terminal and CPU for output transmission.
This ATP approach is particularly economical when the processing
time for all batches is longer than the input transmission time.
An alternative approach that can be used involves the batch
application program reading a transaction, immediately following which
the input transaction received is edited and error messages are queued
on transient data for later transmission. However, this approach
suffers from the disadvantage of less efficient data transmission.
Data is transmitted from the remote terminal, followed by a pause for
processing. Then the next transaction is transmitted and processed,
with the line again being idle while the second transaction is being
processed. No overlap of processing with data transmission is possible.
Either the first method described above, or the use of ATP, is
recommended for most efficient and economic line utilization.
TERMINAL ERROR RECOVERY
CICS/VS uses BTAM, BGAM, TeAM, or VTAM for the control of terminals.
These telecommunications access methods detect transmission errors
between the central computer and a remote terminal, and automatically
invoke error recovery procedures, if specified. These error recovery
procedures generally involve the retransmission of data a defined number
of times, or until that data is transmitted error-free.
In the event
that the error is not corrected after the specified number of retries,
CICS/VS passes information;connected with the error to the terminal
abnormal condition program (ETAM-supported terminals) or to the node
abnormal condition program (VTAM-supported terminals) for additional
processing.
TERMINAL ABNORMAL CONDITION PROGRAM (TACP)
The TACP is used by BTAM-supported terminal. After determining that
the error is unrecoverable, the ~ACP sets default actions based on
keeping the network live. These may involve:
• setting the terminal out-of-service
• setting the line out-of-service
Chapter 3.
CICS/VS Data Communications Design
75
• Abnormally terminating the transaction
• Disconnecting a switched line
Before t-hese defa ul t actions are taken, CICS/VS passes control to
a user-supplied terminal error program (TEP) for application-dependent
action if necessary (see Figure 3-12). On return from the terminal
error program, TACP performs the indicated action as previously set by
TACP or as altered by the TEP.
CICS/VS provides a sample TEP, which can be used to generate a
specific TEP to meet the user's terminal error recovery requirements.
A generated example of a TEP is supplied as part of the subset option
of CICS/DOS/VS.
(See the Subset User's Guide (DOS) for additional
information.) This TEP can be used without change or as an example when
developing a unique user-written TEP.
Generation of a sample TEP is described in CICSIVS system
programmer's Reference Manual, SH20-9004.
CICSIVS AND lISER TERMINAL
ERROR PROGRAM PROCESSING
INI'UT
OUTPUT
Application Program
1. Program issues terminal control
WRITE macro to originating terminal,
specifying output message.
2. CICS/VS sends output message to terminal.
3. On transmission error, BTAM attempts
error recovery.
4. If not successful, CICS/VS terminal
control attempts recovery.
5. If still not successful, default actions are set by terminal abnormal
condition program ("r.ACP).
6. Control passed to user-written terminal error program (TEP).
User-Written
Terminal
Error
Program
Program
7. TEP may:
- Attempt further recovery
- Allocate alternate terminal or
device to receive output
- Accept default actions and return
to TACP, or
- Alter default actions and return
to TACP.
C"SNST] iii
Default
Actions
User-Written
Terminal
Error
11:'1
8. CICSIVS T ACP terminates task and
carries out other defaults, unless
changed by TEP.
CICSIVS
TACP
Extended Description
TACP sets default actions to:
- -A-bn-o-rm--a-lIy-t-er-m-in-a-te--ta-Sk---J
- Mark terminal out·of·service
- Mark line out·of·service
- Disconnect switched line
altered
user-written
terminal error program
(TEP). _
L . unless
.- by
- -_
_
Figure 3-12 ..
CICS/VS Terminal Error Recovery
TERMINAL ERROR PROGRAM
The terminal error program may be supplied by the user to attempt
further e:l:'ror recovery, if necessary. Alternatively, a sample TEP can
be genera,ted or the CICS/DOS/vS subset option TEP may be utilized.
(see CICS/VS System Programmer's Reference Manual, SH20-9004.) For
76
CICS/VS System/Application Design Guide
example, a user-written TEF can specify additional retries to te carried
out by CICS/VS bEfore thE error is considered comfletely unrEcoverable.
Alternatively, the user-written TIP can request that the output
message he queued on disk using CICS/VS transient data, to be
automatically transmitted to the error terminal when the problem has
teEn rectified.
The user-written terminal error program might specify that the error
terminal and linE are not to be markEd out-of-service, a switched line
is not to be disconnected, or th~ ta~k is not to 1:e abnormally
terminated. On return from the tEP, the task may te reactivated as if
the error had not cccurred.
This may be a satisfactcry solution, if transmission of the output
message is not critical to the application, tut continued processing
of the task is~ For example, it may be necessary to allow the task to
continue processing to enatle various data sets to be completely
processed and updated. Alternatively, the task may be allowed to
abnormally terminate. and a frogram control SETXIT routine provided by
the user may be utilized tc ccmplete urgent processing for the task
(see "Program Error Recovery" in Chapter 2).
Generally howEver. all ~rocessing associated with a transaction and
task, and updating of relevant data sets, should he completed before
the programmer makes any attempt to transmit an output message to the
terminal. This can be ensured on VTAM-supported terminals by specifying
that transmission te delaYEd until a terminal control WAIT is issued,
the program passes through a user synchroni2ation point, or terminates.
This is also the standard method used for ETAM-supported terminals.
Receipt of an output message at the terminal sheuld be regarded as an
indicatien that all cf the processing for the particular input
transaction has been completed successfully.
The error recovery precedures described abeve fer the terminal error
program are discussed in mere detail in the secticns "Terminal Backup"
and "Dynamic Terminal Reconfiguration" in Chapter 4.
NODE ABNCEMAL CONDITION fBCGFA8 (NACF)
The NACP is used for VTAM-supported terminals te process abnormal
situations associated with lcgical units. Information concerning the
processing state of a logical unit is contained in the relevant TCT
terminal entry, and in the VTAM reguezt parameter list (RPL). There
is no accompanying line entry as there is for ETAM-supported terminals.
NACP is scheduled any time a VTAM request made by CICS/VS completes
in errer or cannot be honored. The receipt of a negative response sent
by a logical unit also causes NACP to be scheduled. This permits
analysis of the sense information and issuance of any appropriate
messages.
Whenever NACP is scheduled, its analysis routinES determine the
actions that are mandatory te the recovery procedure. Prior to
performing these actions, NACP links to the user-written node error
program (NEP).
NCDE EERCE PROGRAM (NEP)
The user is responsible fer coding an NEP for V~AM-supported
terminals. To aid the user, certain optional actions are generated in
the NACP.
(For example. retry of a message.) If the user wishes any
Chapter 3.
CICS/VS Data Communications Design
77
of these actions to be performed, he can set the relevant optional
actien cedes in the ~CT during NIP processing.
The user can issue VTAM responses or commands in the NIP.
(See
"Terminal Control Using VTAM.") The user can also issue VTAM responses
or commands frem remcte Frcgrammable ccntrollers. For example, if a
printer on a programmable controller runs out of paper, the user may
code the contrcller to send a negative response to the CPU, specifying
a relevant user sense code. This will cause NICP (and NEP) to be
scheduled in the cpu. The NIP can then quiesce the logical unit using
that printer, until the paper supply is replenished. Refer to the
CICSL!~ jAd~AD~§g ~9~!Y~!~~!iSD §Yig~
for additional information.
MESSAGE JLOGGING
Input and output messages may be automatically logged by CICS/VS
for message recovery and resynchronization. In the event of loss of
contact with VTAM-supported terminals, logging and recovery protect
message integrity. Transactions requiring message integrity are
specified in the PCT. The programmable controllers should also log
(as a minimum requirement) the VTAM sequence numters of protected tasks.
Fer performance reason~transactions that do not change the system
environment (such as inguiries that do not update data sets) should
not specify message inte9rity.
In thE event of system failure. CICS/VS emergency restart identifies
in-flight tasks and backs cut in-flight task activity. The input
message for an in-flight-protected task can be used durin9 emergency
restart to establish message resynchronization with the controller.
This is also true for a committed output message fer which a pcsitive
indicaticn of receipt was not received by the CPU before system failure.
(See "Transaction Recovery" in Chapter 8.)
The main objective of an cnline application is to make timely,
and accurate infer~aticn available to the people who need
it. The availability of up-to-the-minute infor.ation will help maintain
control over online applications, or facilitate changes which could be
made onl:y at considerable ti~e and expense. Applications should be
responsive to the needs of the aFplication user, and should provide
improved service to the company's customers.
complete~
However, responsiveness and ready availability cf information can
also be disadvantages if that availability is not controlled.
Information accessible online should only be made available to those
people who are authorized to use it. Thus:
• Only manufacturing personnel may inquire into or change
manufacturing werk orders
• Only bank tellers or authorized personnel may initiate savings or
loan transactions
• Only authorized perscnnel may inguire into a customer information
system for banking, insurance, or utilities
• only authorized dccters cr medical staff may inquire inta a
patient's history
• only authorized police personnel may inquire into a police
information system
78
CICS/-VS System/Application Design Guide
• Only authorized personnel may
or distribution industriEs
~lace
orders in the pharmaceutical
Regardless of how effective an online application is, if it does
not have security provisicns to Frevent unauthorized access to or abuse
of information, the consequences can bE far-reaching.
CICS/VS OPERATOR SECURITY
CICS/VS provides an c~tioral cperatcr security facility. Each
terminal operator is identified to CICS/VS in an oFerator signon table
(SNT). ~he following information is contained in the tat1e:
•
•
•
•
•
•
Operator name
Operator initials
Operator password
Operator security codes
operator security class
Operator priority
Each terminal operator is required to signon to CICS/VS at a
terminal, by entering the signon transaction code CSSN, together with
his allocated 4-character ~a!sword and his name, up to 20 characters
in length (see Fi9ure 3-13). OpeIator security is also discussed in
~l~.§L!.§ l§ilin~l .Q.E§!!!2!!§ §J!ig~, SH20-9005.
INPUT
CICS/VS PROCESSING
Operator
Signs On
(CSSN)
;>
OUTPUT
1. Operator enters sign on transaction with his name and password.
CSSN PS=XXXX,
NAME=XXX ... XX
CICS/VS Sign On Table
[(
Name
Password
~~D
Operator ID
2. CICS/VS loads signon table,
and scans for name.
3. If no name in table, error
message sent to terminal.
r--r--
Security Codes
Security Class
r'1'>
Priority
CICS/VS
Terminal
Control
Table
~
.>
4. If password does not check,
error message sent to terminal.
;>
CICS/VS Terminal
Control Table
Operator ID
Oper. Priority
5. Operator ID, security codes,
and priority transferred to
terminal control table entry
for terminal used.
6. "Signon complete"
response sent back to
terminal.
Figure 3-13.
f?
Sign on
Error
Message
Oper. Sec. Code
Oper. Sec. Class
;>
"Signon
Complete"
Message
Operator Signon
Chapter 3.
CICS/VS Data Communications Design
79
The CSSN transaction code initiates the CICS/VS signon program (SNP).
This program loads the signon tatle (SNT) an~ locates the operator ~ame
an~ password in the table.
If these tvo do not agree exactly, the
operator is prevented frem entering further transactions until he signs
on successfully.
Once signon is achieved, the signon program Extracts the operator
identification (for exam~le, his initial~, security codes, an~ class
and operator priority from the signon table. This information is
transferred to the terminal ccntrol table (TCT) entry for the physical
terminal to which he has signed on. This information remains in the
TCT entry until the operator signs off with a CSSP transaction.
The three-character operator identification is used for subsequent
operator identification, and the operator priority is used in
conjunction with terminal and transaction priorities to establish the
overall task priority. This is discussed in more detail in "priority
Frccessing" later in this chaptere
The o~erator security codes consist of a series of numbers ranging
from 1 to 24. The function of these sEcurity codes is defined by the
user, hut conventionally security code 1 implies low security while
security code 24 implies high security.
These security cedes arE used in conjunction with a security code
defined for each application transaction code. 1 transaction code with
a defined security cede of 10, say, can be used only by those operators
who also have a security code of 10. An operator may have more than
one security code. Operator security codes 5, 6, 10, and 12, for
example, would enable those cperatcrs to use only those transaction
codes which also have been defined as security 5, 6, 10, and 12.
The power of the CICS/VS operator security lies in the vay the system
designer defines the relevant transaction security codes for the
application. For example, in an inguiry system, low security
transactions may be given a security code of 1, vhich allows any
operator to use that transaction code. However, only those operators
who are authorized to make certain other high security inquiries are
given the same sEcurity code as allocated to those inquiry transactions.
All operators Day be alloved to see general information following
an inquiry, while only authorized operators are presented additional
information base~ on their sEcurity codes. This aay be achieved by
baving two versicns of the inquiry program: one which displays limited
amounts of information, and another which displays the full information.
The limited infor.aticn prcgram ~ay be given a security code of 1, for
example, while the more detailed information inquiry transaction code
may te given a different security code.
If an operator attempts to enter an unauthorized transaction code,
CICS/VS viII reject the transaction and send an error message indicating
a security violation to the terminal operator. ihe master terminal
operator is also notified by CleS/VS of the attempt to enter an
unauthorized transaction code. ihe operator identification, terminal
identification, and transaction code used are detailed in the
notification message to the master terminal, as shown in Figure 3-14.
(See the ~!~~L!~ ~§§§Ag§~ An~ ~2~!§ J§»YAl, SH20-9008, for additional
information.) The master terminal operator Day then take appropriate
action.
The operator security class is used primarily in conjunction vith
the CICS/VS message routing facility. Messages may be directed to
specific terminals, specific opE:!rators, or all operators with a specific
security class. In operator may have more than ene security class.
80
CleS/VS system/Application Design Guide
Messages directed to specific operators. or to specific operator
classes, are net transmitted until the particular operator or operators
sign on to CICS/'S. Befer to "Message Bouting" in this chapter for
more detail.
INPUT
Enter
Input
Transaction
Program Control
Table (PCT)
Oper Sec Code
>
1. Operator enters
transaction code and data.
Trans Code
Secty Code
OUTPUT
CICSNS PROCESSING
2. CICSIVS locates transaction
code in program control
table (PCT) entry.
-~
Trans
Code
I
Input Message
il
J
3. CICS/VS compares security
code in PCT entry with operator security codes in terminal control table entry for
terminal that operator
Signed-on.
'--"--
4. If operator does not have
transaction security code,
CICSIVS sends violation message to terminal.
Terminal Control
Table (TCT)
,<
I
5. CICSIVS notifies master
terminal of security violation.
>
>
Security
Violation
Message
~
At Term XXXX
By Oper XXX
With Trans XXXX
Malter Terminal
6. If security codes agree, CICSIVS
passes transaction to application program for processing.
Figure 3-14.
>
Application
Program
CICS/'S Operatcr security
SECUBITY ENH1NCE!ENTS
The CICS/'S o~erator security feature relies en an operator's name
and his knowledge of a unigue password to allow him to signon. Once
he has signed on, he has full access to all transaction codes which he
is authorized to use.
However, a password is like the combination to a safe. It is
effective when it is known only ty those persons authorized to use it.
To avoid the possibility of tnauthcrized persons learning the signon
procedure and an operator naae and relevant password, the design team
may incorporate some security enhancements into their system design if
reguired by the application.
The security enhance.ents which may be develoFed depend upon the
particular application reguirements and the cost of providing that
security in time and effort, as well as the potemtial cost to the
organization if that additional security is not provided.
Chapter 3.
CICS/'S Data Co •• unications Design
81
The following techniquEs are suggested user enhancements which may
be considered as part of the system design, and which could be readily
imFlemented by user-writter coding in the application programs. These
enhancements build upon the CICS/VS security features and provide
increasing degrees of security with each technique discussed. They
may be inplemented within CICS/VS application programs or in application
programs written for program&able controllers. Iaplementation of these
security enhancements in program.atl~ controllers permits authorization
to be performed before transmission to the CPU, and enables security
checks tc be carried cut based on each reDote location's requirements.
This provides security on the tasis cf authorized operators entering
transactions only frem authorized Fhysical terminals. Normally a
terminal operator may sign-on tc any terminal supported by CleS/vS.
This includes conversational and batch terminals, together with
simulated terminals such as eard reader, tape, or disk.
On initiation of a task, CICS/VS makes the terminal identification
available to the user's applicaticn Frogram. For security purposes,
the CICS/VS (or Frogrammable ccntrcller) application program may check
this terminal identification against a user-supplied table of authorized
terminal identifications. If the terminal is unauthorized, the
transaction can te rejected ty the application prcgram, together with
an error message. The program may alse notify the master terminal
operator ..
For a transaction entered by an authorized operator using an
terminal, the system designer may require the terminal
operator to provide an additional password (or security code) to the
user program to permit access to high security functions or information.
This additional password may be prcvided in the main body of the
transaction when it is first entered, or be explicitly re9uested by
the application prcgram when it reaches that point in its execution.
authoriz~~d
This security technique requires the terminal operator to supply a
password to the user program tefere a specific data set er data base
can te accessed. A data reccrd pass~ord may additionally require a
specific password to be supplied by the operator tc the program before
information in particular Iecords is displayed. This password may be
incorporated as part of the record. A data field password is an
extensiom of data record passwords, and requires a password to be
provided before specific fields can be displayed fer the operator.
This applies to all of the passwords described above, and requires
that a password te changed frequently by the user to prevent
unauthorized persons gaining knowledge of it.
For maintenance purposes, the current password is best recorded on
disk, and is changed on disk by a specific transaction. This reduces
the need to modify programs, but intIoduces the requirement that access
to this password data set be strictly controlled both in the online
environment and in the batch environme~t. To guard against possible
unauthorized aCCESS of this data set, the passwcrds may be recorded by
the user in a ceded (scramtled) ferm on the data set; this code is
82
eICS/VS system/Application Design Guide
unintelligible and useless unless it is translated using, for example,
a unique translaticn table in the aFFlication prcgram.
This translation table can also be changed dynamically by the user,
if required, to further reduce tie possibility of vnauthcrized access
to the password data set and the scrambled passwcrds.
~~D~i£ QR~g!~~ i~§I2~g§
Support of dynamic operator passwords is achieved by periodic
regeneration of the sign en table (SNT). An alternative which is also
equally effective is dynamic passwords as descrited previously.
The extent of security precauticns is limited only by the imagination
of the design team. Howe~er, the apFlication requirements will
generally dictate the point at which security prccedures should stop.
A battery of locks on a door is useless if the person authorized to
open that doer dces not ha~e all cf the keys. In the same way, the
use of dynamic passwords may prevent even authorized access if the
person attempting that access forgets the current password and
procedures. Furthermore, the security precautions adopted by the user
may be se stringent as tc ~re~ent him from ever finding out those
passwords and procedures.
OPEBATOB BEBOB STATISTICS
As a ty-product of the cperatcr signon feature of CICS/VS, a count
is maintained of all transactions entered by that operator, together
with all operator errors as indicated by abnormal termination of
applicaticn programs using the prcgram control AEEND macro instruction.
When the operator signs off, using the CSSF transaction code, CICS/VS
directs a message containing the o~erator identification, number of
transactions entered, and nu.ber of transaction errors to a transient
data destination. This transient data destinaticn may be allocated to
a terminal, a disk or tape data set, a line printer, or any other
CICS/VS-supported device. When directed to tape or disk, these operator
statistics may be accumulated for audit, control, or evaluation
purposes.
Each terminal operator is allocated a priority code as well as
security codes. This operater priority is used in conjunction with
terminal and transaction prierities to establish the overall task
processing priority.
TASK PEICBITl
CICS/iS uses priority cedes ranging from 0 to 255.
low priority while 255 represents high priority.
The 0 represents
Each operator, terminal, and transaction code can be allocated a
priority code ranging frc. 0 to ~55. The operator priority is contained
in the signon table (SNT) and is ccpied across to the terminal control
table (TCT) when the operator signs on. The ter.inal priority is also
contained in the TCT, while the transaction priority is contained in
the program control table (PCT) entry for that transaction code (see
Figure 3-15).
Chapter 3.
CICS/iS Data Com.unications Design
83
When an operator enters a specific transaction code, his priority
and the priority of the terminal he is using are extracted, together
with the priority associated with the transaction code entered. These
three priorities are added together to produce a tctal priority. This
total priority is used as the task priority, and also ranges from 0 to
255. In the event that the sum of the three priorities exceeds 255,
the task priority is rcunded down to 2~5.
This calculation of task ~riority provides the design team with
considerable flexibility tc ensure that the best performance and
response time are ~rovided in the areas where they are most needed.
Thus, operators carrying out higher priority functions than other
operators may be given a higher ~riority code by the user. Similarly,
some terminals may be given higher priorities than other terminals.
Also, high priority transactions may be given a higher priority value
than other transactions.
A very high priority transaction may be given a priority value of
255. In this case, regardless of the operator or terminal priority,
that transaction is always given the highest task priority. In the
same vay, very higb priority operators or terminals may be given
operatcr or terminal priorities of 255.
CICS/vS PROCESSING
INPUT
OUTPUT
E"'g ~~ m
1. Operator enters input transaction
code and data.
>
Input
Tran"action
Trans Priority
'--r--
Termn Ident
'>
I
3. CICSIVS extracts terminal priority
from TCT entry for terminal.
>
I
-Terminal Control
Priority~200
Term.
>
I
Oper. Priority=255
m
5. CICS/VS sums transaction. terminal
and operator priorities to develop
task priority.
>
I
'>
6. If task priority exceeds 255. CICS/VS
rounds down to 255.
I
I
I
=
Task Priority=455
Task Priority=255
Application
Program
7. Task commences execution at task
priority.
Extended Description
m
m
Priorities range from 0 (low priority)
to 255 (high priority).
Priority Examples
Transaction:
Terminal:
Operator:
Task
----_._-
84
Piiority~O
J
Round Down
Table
Figure 3-·15.·
I
+
4. CICS/VS extracts operator priority
from TCT entry for terminal.
-'---
Trans.
+
Termn Priority
Oper Priority
I
Input Message
__d
1<
T% m
Program Control
Table
Trans
Code
2. CICSIVS locates PCT enny. After
security check. transaction priority
is extracted from PCT by CICSIVS.
~ur> m
Trans Code
I I
-
Task Priority
CICS/VS system/Application Design Guide
0
0
0
100
100
0
~
_Q
~
100
0
100
100
100
100
0
100
100
200
255
I
The task priority is useful in those cases where, because of the
transaction volume, there Day be several tasks ccncurrently executing.
In this event, CICS/VS passes control to the highest priority task
which is able to ccntin~e executing, and that task retains control of
the CPU until it requests various elcS/VS services. If the high
priority task is not able to continue processing until a particular
event (such as an I/O operation) has occurred, CICS/VS passes control
to the next highest task which is able to execute. A high priority
task is given preference in the use cf the CEU and other facilities
even if entered later than a loveI priority task.
CICS/VS
preference
that task.
value (for
control to
ensures that such high priority tasks are given first
in prcc~ssing to enable gcod performance to be achieved by
In the event that twc tasks with the same high priority
example, 255) are both ready to process, CICS/VS gives
that task which reachEd the system first.
CICS/VS is an event-driven system, and as such does not seize control
from a currently dispatched (executing) task. Therefore, even a low
priority task will continue to eXEcute once it has been dispatched,
until it voluntarily relinquishes control by issuing a CICS/VS macro
instruction. If no CICS/VS serviCES are required by such a task, it
should periodically issue a task centrol dispatchable WAIT, or a CHAP
(change priority), macro instruction. The CHAP need not changE the
task's priority, but merely relinquish control.
(See the next topic,
or Chapter 6, for Dore detail.)
CHANGE PEIOEITY
A task may commence execution at one priority, and then may need to
change its priority at anothEr phase in its procEssing_ CICS/VS
provides this capability through the task control change priority (CHAP)
macre instruction (see ChaFter 6). A high priority task may be changed
through the use of this macrc instruction to low priority, or vice
versa. In this way, secticns of an application Frogram may be given
a high priority for processing, while cther sections may be given lower
priority. This enables a task to dynamically change its priority based
on differing requirements determined through execution. Some examples
when sections of a program may wish to change the task priority are
illustrated in "Friority ChaDge" in Chapter 6.
Chapter 3.
CICS/VS Data Co.munications Design
85
This chapter discusses CICS/VS temporary storage and transient data
in a tutorial fashion. Ex{erienced CICS users mal wish to omit the
section en transient data. However, it is reccaDended that such users
read the s~ction on temporarJ storage in its entirety. The temporary
storage control program (TSP) is changed from that ~vailable in previous
CICS versions. While still lrcviding compatibility with previous CICS
versions, this new TSP.provides additional seguential as well as direct
accessing capability, and utilizes VSAft.
.
. .
-~----~--~--------~-~---~-----~~-~-----~-----~---------~-------~-------
CICS/VS, together with DL/I, provides extensive data base capability
to online applications. In-additicn to this data base capability (which
is discussed in Chapter 5), CICS/VS offers additional facilities for
internal data management. This chapter first identifies various
application reguiiements which demand the services offered by CICS/VS
tempcrary storage Danage&entand transient data management. It then
describes those services which can be used as "design tools" by the
system designer to satisfJ his own application reguirements.
It is first necessary to define the various data management functions
(as distinct frem data base capability) which online applications
require of a DB/DC system. These functions are triefly described below.
WOEK FILE CAPABILITY
Most online applicatiens reguire the ability to store information
for later retrieval and use. This function is sometimes referred to
as a "scratchpad" or work file capability, and is analogous to a person
using sheets of Faper to jet down the intermediate re~ults of
calculations for later use in processing.
The following are two main work file requirements used for most
online aFplicaticns:
• Scratchpad capability
• Cueuing capability
This capability refers to the teaporary storage of. information for
later retrieval. In a batch environment, this capability is. often
provided through the use of work data sets. In CICS/VS, this capability
is provided by the CICS/VS temporary storage contrel p"rograa. The
application program identifies data which is to be temporarily stored
by name, and subseguently retrieved by name without any consideration
of its physical location. Online apFlication uses of temporary storage
include the following.
l»~DSdi~!§ Ei2Yl!§:
ThE storagE of intermediate results developed
during the processing of a transaction, for use later in the processing
of that transaction.
Chapter 4.
CICS/VS Data !anageaent Design
81
1;J;J;:.QI ~I§~:tie.!!: The stcrage ef input transactions which were
found to be in error, for subseguent use when the corrected error fields
are received from the terminal.
12.9:t.9 ~J;:I91!§!§I: A tempora ry storage of data se it can be used to
transfer data between programs. This data transfer may eccur
immediately or at scme future time.
1!i!:mi!ll\! fS.9i!l.9: An apFlicatien Frogram may develop several pages
of information to be displayed at a terminal. This inforaation should
be temporarily stored until the terminal operator requests that it be
displayed for his attention.
In addition to the tempcrary storage of data, online applications
generally require a facility which will enable data to be queued for
subsequent processing. The difference between this and temporary
storage is that temporary storage stores and retrieves individual
sections of data, while a gueuing caFability enablES several different
sections of the same type o( data to be queued, and then all sections
retrieved together, sequentially, in the order that they were queued.
In eIeS/VS, this queuing capability is provided by the eleS/VS transient
data centrol program. EIaDples in which cnline applications may utilize
a queuing capability follow:
~at~h .Tra.n§A5:!ig iI.Q~§~i.ng:
Transactions of a particular type
may be received from many terminals. If the applicatien requires that
all ef these transactions be Frocessed together, they may be stored in
a unique queue for that transaction type, in the crder that they reach
the cpu. This queue of transactions may then be processed in the
eIes/vS partition as a small sequential group of transactions.
,l!atcJl§.g .H!i§§.9.9.i 1ran§.!i,g§i2!l: The online application may require
that messages be batched and tralsmitted to specific terminals.
~s.:t~l! .~.9!::ti:ti.Q'!! 12.91.9 l~Jl!§!.i":
The online application may require
that infermation be transferred tc batch partiticns for further
processing, and the results cf that Frocessing be provided to the online
application for input at a later time.
The temporary storage management facility of CICS/VS provides a
scratchpad capability for online aFplication programs. It enables data
to be stored either in dynamic storage or on auxiliary storage. Data
to be stored can be identified symtolically, and retrieved symbolically,
without application progra.s being ccncerned with the actual physical
location of that data. Data can be retrieved on request by an
application program in either a sequential or a direct access manner.
Temporary storage allcws reccrds tc be up to 32,000 bytes in length,
but supports variable-length reccrds only.
TEepOEARY STOEAGE USAGE
The previous discussion of application requirements identified the
general u:se of a scratcilpad facility by applicaticn programs. eIeS/VS
temporary storage management is used to meet these application
requirements as follcvs.
88
eIeS/VS System/Application Design Guide
The atility to temporarily save data for later use, and retrieve it
symbolically by name at a future time, enables easier implementation
of complex processing. This complex processing may be broken into
several logical steps, each step carried out by a separate module.
Information may be passed tetween these modules using temporary storage.
Depending upon the amount of information to be passed, and the time
period before that informaticn will te used, this data may be stored
either in dynamic storage cr, alternatively, in auxiliary storage.
Temporary storagE may be used to save information for later use.
An example would be the saving of error transactions for later
combination with corrected fields received from a terminal, as described
in "Error Correction". Using this capability, ccrrect information in
the original errcr tran~acticn dces not have to te reentered by the
terminal operator. Consequently, error correction is easier, and the
potential for further operater errors is reduced.
~§~inal R~ing
Terminal paging in CICS/VS is also supported through the use of
temporary storage. Fages cf infcrmaticn developed by application
programs are presented by them to CICS/VS. These pages are stored in
tempQrary storage for transmissien tc the terminal operator on request.
Refer to "Terminal Paging" in ChaFter 3 for more detail.
The ability to transmit messages frem one terminal to another
using the CICS/VS message switching transaction CMSG, or the
EMS BOUTE macro instruction, is sUFPcrted through the use of temporary
storage. These messages are automatically transmitted to the relevant
terminal when that terminal is atle to receive them, or the specified
operator has signed on to CICS/VS. Refer to "Message Bouting" in
Chapter 3 for more detail.
term~nal,
The CICS/VS interval control pregram uses temFcrary storage to pass
data from one task te anether task which is to be initiated at a future
time. An application program may indicate the task to be initiated at
a specified time (based cn elapsed time or, alternatively, time of day)
and may transfer data to that future task. The interval control PUT
macro instruction results in the data to be transferred being written
to temporary storage on disk for subsequent retrieval by the interval
control GET macro instruction. Eefer to "Interval Control" in Chapter
6 for more detail.
DATA
IDENTIFIC~TION
Each record may be presented to temForary storage with a unique
eight-character data identification. Alternatively, several records
may be presented with the same data identificaticn. 1 queue of re~ords
associated with a particular logical function (as indicated by the data
identification) can be develeped, and subsequently retrieved in the
same sequence.
ChaFter 4.
CICS/VS Data Management Design
89
The data identificaticn is used by CICS/VS to develop a data element
which contains that identificatien, the sequence or entIY number of
the recoId i~ a gueue of records with the same data identification,
and the location of the record eitheI in dynamic storage or on disk.
These data elements are maintained in CICS/VS dynamic storage. As
records are written to temForary stoIage, data elements are dynamically
built by CICS/VS and saved in dynamic storage. The number of temporary
storage records which may te retained is limited only by the
availability of dynamic stcrage and/cr the amount of disk space
allocated to the temporary storage data set.
Because many tasks may corcurrently use the same FrogIam, the use
of a constant in the prcg~am for identification of individual records
is not advisable. The data identification may be dynamically generated
by the program based upon information such as:
• A combination of transaction identification (four characters) and
operator identification (three characters) will enable that operator
to store one record at a time for each transaction identification.
• A combination of oFerator identification and time of day, or
transaction identification and time of day, will enable the record
to be uniquely identified. However, it requires the application
program to determine the time of day and then respond to the
terminal operator with the allocated data identification. He may
then use it to uniquely identify the record in a lateI transaction.
• Each task initiated by CICS/VS is given a unique task sequence
number. This task numter may be used as the data identification;
it may be returned to the terminal operator fer subsequent reentry
ky him when the relevant recerd is to be retrieved.
The techniques for unique data identification described above assume
an application environment where infermation is te be stored by the
user's pIogram, and directly retrieved at some future time under control
of the terminal operator.
If temporary storage is used to pass data from ene aPFlication
program to another, the allocated data identification may be passed to
a subsequent application program (exEcuted under ccntrol of the same
task) thIough the transaction work area (TiA) appended to the task
control area (TCA) for that task. !he program (executing under the
same TCA) which is to retrieve the data from temporary storage can
obtain the allocated data identificaticn from the !WA. This data
identification is then used to identify the record to be retrieved.
If a r'9cord within a temperary storage gueue is to be directly
retrieved, it must be uniguelyreferenced by the data identification
(10) and its relevant entry (or sequence) number. When a record is
written tiD a temporary storage queue (data identification is nonunique),
it is placed at the end of the queue of records with that same data
identification. Temporary storage management will allocate the next
sequential entry numker and return this entry numter to the program.
The recoId is now uniquely identified by the data ID and the entry
number.
This data ID and entry number may be transmitted to a terminal
operator for subsequent reentry, if the retrieval is to be initiated
by the terminal eperator. If the xetrieval is to te in~tiated
automatically by subsequent application programs executed by the same
task,-the data identificaticr: and entry number should be saved in the
TWA. The program which is tc retIieve that unique record may then
extract this infermatien fIom the TWA for use.
90
CICS/VS System/Application Design Guide
USE OF DYNAHIC StORAGE BY
TE~PORAEY
STCRAGE
Dynamic storage is a valuable resource, and the overall perfo~mance
of the online system is directly related to the al:cunt of available
dynamic storage and its relationship to real storage available for use
as a virtual storage page pool (see "CICS/VS iorking Set" in Chapter
7) •
Generally, dynamic sterage residence of records should be used only
when the life of those recerds is to bE of very shert duration. Its
main purpose is in passing data between program modules which are
executed Qnder control of the same task. Once the data has been passed
between modules through dynamic stcrage, that data should te deleted
and the storage occupied by it freed. Dynamic storage may be used for
record queues as well as unique entries; however, write requests to
dynamic and auxiliary storagE with the same data identification cannot
be used. CICS/VS will fcrce all subsequent write requests with the
same data identification to use the same storage facility specified by
the first request.
The length of records to be stored in dynamic storage may be up to
the VSA" control interval size specified during CICS/VS system
initialization, less 84 bytes for CICS/VS control information.
CICS/VS permits temporary storage records to reside in dynamic
storage only if the CICS/VS system is generated indicating no auxiliary
storage residence sUIPort is required. The specification of no
auxiliary storage support removes the requirement for VSA" by temporary
storage. Instead, virtual storage is utilized; temporary storage
information is only paged into real sterage when referenced.
Any temporary storage infcrmation residing in dynamic storage is
lost if a controlled or unccntrolled shutdcwn cccurs. See the Gl~~!~
~Y§!~~ R'2~gmm~~!§ ~!!~!~§ ~gD~sl, 5H20-9004, and "Temporary Storage
Recovery" in Chapter 8 for atditicnal information.
As a general rule, if a record must be stored for more than one
second, it should be directed to auxiliary or secondary storage rather
than to dynamic or main storage. Dynamic storage is then available as
much as possible for use in initiating concurrently executed tasks.
certainly, the writing of Iecords to disk, and the subsequent retrieval
from disk, will involve file accesses and so increase the processing
time of those particular tasks. However, the overall effect on the
entire online system is ene of potentially better ferformance than
would result if considerable dynamic storage were utilized for temporary
storage residence.
ACCESSING RECORDS IN TEMPOEAEY STOBAGE
Temporary storage sUPIorts variable-length records only. A queue
or message set of records may be developed by issuing a temporary
storage ~UTQ macro instruction fcr each record, using the same data
identification. As each reccrd is ~ritten, temporary storage allocates
the next sequential entry nu.ber and returns it to the application
program.
Using the data identification and the entry number, the records in
the queue can be retrieved by application programs either seguentially,
in the chronolcgical order in which they were written, or directly
accessed by referencing a specific entry number.
A queue of records can te retrieved seguentially by specifying the
data identification allocated for that queue and issuing a temporary
storage GETQ macro instructicn. Temporary storage management retrieves
Chapter 4.
CICS/VS Data Management Design
91
the first record in the queue for that data identificaticn and presents
it to the application prograa. Each subsequent GETQ macto.instruction
retrieves the next record in sequence until the last record has been
retrieved., when an end-of-queue indication will te returned to the
Frogram.
Alternatively, if it is required to commence sequential retrieval,
not from the beginning of thE queuE tut from a lcgical point within
the queue, both the data identification and the entry number are
specified by the program. GITQ macro instructions are then issued to
retrieve each record sequentially frem the logic~l starting point in
the queue.
The program may directly retrieve records by issuing a temporary
storage GETQ macro instructicn with the specific entry number of the
record in a queue to be directly retrieved.
A record can subsequently be uFoated by issuing a temporary storage
PUTQ macro instructien specifyin9 the relevant entry number.
The facilities offered ty temporary storage for direct and sequential
retrieval of information make it a powerful work file capability for
online aFplicaticns. Infermation may be retrieved as often as required
until it is no lenger needed. At that time, the records may be deleted.
Queues of records based upon a specific data. identification may be
purgEd by an apFlicatien program PURGE macro instruction. The deletion
or purging of these records results in the logical deletion~f those
records in the temporary storage data set, with the disk space occupied
by those records being reclaimed when the space is subsequently used
for another record. The data eleaents describing the deleted or purged
records are freed, and the dynaaic storage occupied by these records
is reclaimed for other uses.
The eICS/VS temporary storage centrol program supports requests for
specific records using the POT, GET, and RELEASE macro instructions
provided in previous versicns of eles. However, PUT, GE~, and RELEASE
are mutually exclusive with FOTQ, GETO, and PURGE on a data
identification basis. That is, a record written by a PUT macro
instruction cannot te retrieved by a GETQ, or deleted by a PURGE, for
example.
TEMPORARY STORAGE RECOVEEY
After a ccntrclled or unccntrclled teraination of CleS/VS, temporary
storage records on disk may remain available for use, if desired.
Temporary storagE in dynamic storage is lost.
On restart of CICS/VS, either a "cold start," "warm start," or
emergency restart aay be specified. If a cold start of temporary
storage is specified, any information recorded on disk is lost.
If a warm start is specified on system restart, the information in
the temporary stcragE data set is retained. The temporary storage
keypoint recorded at system termination (see "Termination Keypoints"
in Chapter 81 is used to reccnstruct the data elements in eICS/VS
dynamic storage, to enable subsequent retrieval of information by
applicaticn prcgrams once the system has been restarted.
If an E~mergency restart is specified, the information in the
temporary storagE data set is retained. The contents of that data set
and any tE~mporary storage update activity automatically logged to the
eleS/VS system log prior tc uncontrolled shutdown are used to
reconstruct temporary storage tables in dynamic storage. These tables
92
CICS/VS system/Application DeSign Guide
identify the status of temporary sto~age at unccntrolled shutdown. The
data identification of temForary storage records and queues, the number
of entries in queues, the location of each entry in auxiliary storage,
and the status of available space in the temporary storage data set
are reconstructed during emergency restart.
The processing of in-flight tasks is also backed out during emergency
restart. A task is considered in-flight if it did not pass through a
user synchronizaticn point (with IC subsequent logging activity) or
terminate before uncontrolled shutdown.
Thus, a consideration in the use cf dynamic storage or auxiliary
storage as a temForary storage medium is the requirement for
recoverability. Information stored in main storage will be lost;
information stored in auxiliary storage may be recovered, if a warm
start is specified cn restart.
SELECTION OF TEftFOBAEY STOFAGE OE
TBANSAC~ION
WOEK AREA DATA TRANSFER
The design team must indicate whether infor.aticn to be passed .from
one module tc ancther may be transferred using the transaction work
area (TWA) appended to the task control area (TCA), or that temporary
storage must be used.
II!
!Q~ ~~ta I~Jn§i~~
The TWA can be used only if the information will be subsequently used
by the same application Frcg~am, or by another application program
which executes under control of the same TCA. That is, ccntrol must
be passed to the subsequent Frogram either by prcgram control ICTL or
by LINK macro instructions. If the information is to be passed to some
future task initiated by time, or by a subsequent transaction entered
by a terminal operator, then the TWA cannot be used. This is because
the TCA and associated TWA are destroyed when the task which generated
the information terminates execution. Consequently, the TWA may be
used for data transfer of a short-term nature, while temporary storage
is generally used for data transfer of long-term nature.
A consideration in the use of a ~WA or temporary storage is the
ameunt of data tc be stored. The size of the TWA associated with a
transaction code is stored in the Fregram control table (PCT). This
TWA size is used to allocate a TWA aFpended to the TCA. Thus, if a
TWA of 200 bytes is indicated in the PCT, the TCA is allocated 200
bytes more than if no TWA size is specified.
A further factor is the duration of execution of the task, and the
ameunt of time between when data may be stored in the TWA and when it
will be subsequently retrieved from the TWA. As a general r~le, if
data may remain in the TiA fer lenger than one second it should be
stored in temporary storage. This would be particularly advisable if
a TWA much larger than 200 te 300 bytes was to be used. Furthermore,
because of the relatively low activity of use of this data (because of
the long executicn time) I it should be stored on disk rather than in
dynamic storage address space.
Chapter 4.
CICS/VS Data ftanagement Design
93
Va~iable
I!J
~i~~ ~§gYiI!!~~!§
Another factor is the pessible requirement of the pre9ram for
different size TiAs based upen the processin9 required. For example,
90~ of transactions which use the saKe transaction code and application
program may require a TWA ef 50 bytes. However, the remaining 101 of
these transactions may require a TiA of 500 bytes, say. If a TWA was
used for all transactions by this program, a SOO-byte TWA would have
to be specified in the relevant FCT entry. This would mean that for
901 of t:ransactions using that program, 450 bytes'cf storage would be
wasted.
A more efficient soluticn in this case would te to allocate a 50-byte
TWA, and utilize this TWA for the 90' of transacticns which need 50
bytes. In the case of the remaining 101 of transactions, temporary
storage on disk should be utilized. Thus, storage is used most
efficiently, with the additicnal time to store information on disk and
retrieve it from disk only affecting 101 of the transactions in this
example. .
The queuing facility provided by CICS/VS for online applications is
supported by the transient data management routine of CICS/VS. There
are two types of transient data queues. These are:
~~traparj;i ti.Q1}:
Extrapartit ion queues are sequential da ta sets used
for transfer of informaticn tetween CICS/VS and tatch partitions.
In!~gRgI!i!iQn:
The intrapartition data set supports queues used within
the CICS/VS partition itself, to transfer information between CICS/VS
tasks.
TRANSIEN~
DATA USAGE
The application uses cf extrapartition and intrapartition data sets
will new be discussed.
EX!Ig~~Ili!iQD ~S!2 ~!§
Extrapartition data sets in CICS/VS are used for the following main
purposes:
~g!£b
Dais I~gn§!§~: Information which is to be passed from CICS/VS
to batch partitions is directed to extrapartition data sets or queues.
These data sets are normal sequential data sets using OSA! for OS/VS
or SA" for DOS/VS.
Similarly, information to be passed .from a batch partition to crcS/VS
is read by the relevant CICS/VS task from an extrapartition input data
set.
•
.§§g.Y§.Dli~,l ~§.!.i£§§:
Extrapartition Clata sets may be used by CICS/VS
to ccmmunicate with varicus sequential devices, such as line printers.
Because the stanClard sequential access methoCl under as/vs or nos/vs is
used to support extrapartiticn data sets~ those devices supported by
the stanClard sequential access method can be utilized by CICS/VS. These
include card reaCler, line printer, disk, and tape. Particularly because
of as/vs device independence, most sequential devices which are
supported by OSA" may be utilizeCl as either input cr output data sets
by CICS/VS, when the user specifies them as extrapartition data sets.
94
CICS/VS System/Application Design Guide
l~!~~~~!iti~~ ~g!g ~!
Intrapartition queues are used to pass direct access organized data
(chained sequentially) between CICS/VS tasks. A number of
applicaticn-oriented uses fOI intrapartition files are detailed below.
Data received from many terminals for the same
application may be consolidated in one queue for FIocessing as a batch.
Each concurrently executing task may direct the data to the relevant
batch queue, where it ~s chained sequentially. Subsequently, this
batch or queue of data may be precessed as an input file of information
by a CICS/VS task.
~~tch ~y~y§§:
!Y!Q~s!i£ Ta§~§:
.Data stored as a queue as described above may be
automatically processed by a CICS/VS task when a specified amount of
information has been queued. Based upon a trigger level (or count)
for that queue, a specified task gay be automatically initiated to
process that quantity of data. ~he trigger level Day vary from 0 (which
implies nc automatic task initiation) through 1 (which initiates a task
each time information is written to the queue) to a trigger level of
greater than 1.
l§~~ina!
QY1RY!: Output may be automatically directed to a terminal
from several tasks. ~his automatic output may nct be able to be sent
to the terminal for some time, because it is engaged in other activity
such as entering an input transaction or receiving output from previous
transactions.
In addition, the terminal may be one to which output is only sent
when requested. An example ef such a terminal weuld be a video
terminal. Automatic output directed to a video terminal may not be
displayed at a convenient time, or may not allow sufficient time for
assimilation of the information displayed. Hard-copy terminals,
however, may be able to receive automatic· output at any time they are
not active, unless they are used with preprinted stationery. In this
case, automatic output for a terminal must be queued on disk until the
terminal is able to receive it, cr until the terminal operator has
explicitly requested it.
output to be directed autcmatically to a terminal is queued on an
intrapartition queue. A trigger level may be associated with this
queue such that when a specified number. of output messages have been
queued a task is automatically initiated to transmit those messages to
the terminal, if the terminal is able to receivE those messages at that
time.
Aygi!: Intrapartition (or extraFartition) queues Day be used to
accumulate information for audit purposes~ Intrapartition queues may
be specified as being nonreusable. Data written to these queues is
accumulated throughout the oFerational period of CICS/VS, and will only
be deleted (and the disk space used viII. only be freed) by an explicit
transient data PUBGE macro instruction issued by an application program.
Alternatively, queues may be specified as reusable, in which case
information on these queues is purged auto.atically by CICS/VS when
the data has been read by application programs. The subset option of
CICS/DOS/VS supports extrapartition data sets but Dot intrapartition
data sets.
(See "CICS/DeS/VS Subset Option" in Chapter 1.)
EXTEAPAB~ITION
TEANSIENT DATA
As discussed above, extrapartition data sets Frovide a sequential
data set capability te eICS/VS. Standard access aethods such as QSAM
for OS/VS or SAM for DOS/VS are utilized. ~he specification of the
Chapter 4.
CICS/VS Data
~anagement
Design
95
particular sequential data set is made at system generation time.
Further information describing that data set may be provided at CICS/VS
system initiation time from CS/VS DD, or DOS/VS tLEL and EXTENT, job
control statements. Extrapartition data sets can be either fixed-length
or variatle-length, blccked cr unblocked data sets.
F.~£Q!g A!;£~§.§!n~
Each extrapartition data set is identified by a four-character
destination identification. This destination identification is
specifie
DFHTD TYPE=GET,
DESTlD=ABCD
Destination
Control Table
>
1. Application program issues
transient data get macro,
specifying destination 10
(DESTID=ABCD for example).
2. CICSIVS locates entry in des·
tination control table (DCT)
for DESTlD=ABCD.
~BCD--
1-----Extn,partition
>
J,
DCB!DTF Name
'-------
~
DCEI!DTF
_._----
Figure 4-1.
-'--
3. DESTI 0 is for extra partition
data set. CICSIVS allocates
input area for task.
4. CICSIVS gets record via seqtl
access method and moves to
input area for task.
[IJp>
5. CICS!VS returns extrapartition record in input area to
user program.
JT
Inp~
~
DFHTD TYPE=GET,
DESTID=ABCD
Program
Extrapartition Data set Accessing
For output to a sequential data set, an application program first
requests the CIC~/VS storage contrel program to allocate storage to be
used as an output area. The cutFut record is then constructed by the
application program, after which the program issues a transient data
PUT macro instruction indicating the relevant destination identification
of the output data set. The output record is then written by transient
data to the specified seguential data set. On successful completion
of output, without error, the allocated output area is automatically
freed by eICS/VS and ieturned to dynamic storage for use by other tasks.
When an application Frogram has to initiate input from a sequential
data set, it issues a transient data GET macro instruction specifying
the relevant destination identification. Transi€nt data determines
96
CICS/VS system/Application Design Guide
the data set involved, automatically rEquests that an input arEa large
enough tc contain the next record beallecatEd for the particul.r task,
and moves the next seguential in~ut record into tbat area. The address
of that input area is returned to thE requesting task after successful
completicn without error. The accessing of extrafartition data sets
is illustrated in Figure 4-1.
ExtraFartition data sets may te either fiXEd-lEngth or
variable-length, blccked OI unblccked.
~~~Q~~~
21
1~!~§R~.!i!is~ ~~!g ~~!§
CICS/VS does not attempt to reccver extrapartition data sets after
a centrolled shutdown or in the event of abnermal termination or system
failure.
(This subject is discussed in more detail in Chapter 8.)
INTBAPARTITION TEANSIENT DATA
As discussed Freviously, the intra~artition data set provides a
useful queuing facility for ~assing information between CICS/VS tasks.
Its main use is to provide sup~ort for accumulation of data to be Either
processed as a batch or automatically transmitted to a terminal, for
exam~le.
~ecord !s£~§§ing
Data is written to or rEad from intrapartition queues by CICS/VS
applicatien prograDs in exactly the same way as fer extrapartition data
sets. However, only variatle-Iengtb records are supported. An
application ~rcgram requests an cutput area to be allocated to it by
CICS/VS storage control, sets up the output record, and issues a
transient data PUT macro instructicn s~ecifying the relevant
four-character intrapartition destination identification.
Similarly, for input, when a transient data GE~ macro instruction
is issued by an ap~licatien ~rcgIam, transient data requests that an
input area be allocated. ThE record is then read and passed to the
requesting task.
From a general programming point of vie~, there is no effective
difference between reading and writing extrapartition data sets or
intrapartition queues. ~he indicaticn by the program as to whether an
extrapartition data set or an intrapartition queue is to be used is
the specification of the'relevant destination identification.
One main difference between extra~artition and intrapartition queues,
however, is that intrapartition queues may be specified as being
reusable, if required.
Thus they can be used as work files if needed,
queuing data to be processed, and then, after precessing that data,
deleting it so that the disk space it occupied can be utilized for
other purposes. This is discussed in more detail in "Beusab1e
Intrapartition Queues" later in this cbapter.
CICS/VS uses a direct access data set to suppcrt intrapartition
qUEues. The disk s~ace allocated for the intrapartition data set is
regarded as a pool of tracks which may be allocated to intrapartition
queues (destinatiens) as required (see Figure 4-2).
Chapter 4.
CICS/VS Data
~anagement
Design
97
OUTPUT
CICSIVS "ROCESSING
INPUT
r-------------.----'----------~
Program
1. Application program issues
transient data put macro,
specifying destination ID
(DESTID=JKLM for example).
--.----"-- ::>
DFHTD TYPE~PUT,
DESTID oJKLM
Destination
Control Table
2. CICS/VS locates entry in des
tination control table (DCT)
for DESTlD-JKLM
JKLM
DESTID
1-------3. DESTID is for intrapartition
queue. If it is first record for
this DESTID, CICS/vS allocates
track from pool of tracks and
writes DESTID to track,
~~_ar_ti_tio_n_...J
4. CICS/VS writes output alea to
track as first datd record.
--
r-r----
Intra~laritition
5. CICS/vS places disk address of this
record in DCT as g"t pointer, if
it is first record for this DESTI D.
,I-___
OCT
JK_L_M_ _ _--l
"
Get Pointer
6. CICSIVS places disk address of next
Data !iet
available record location in DCT, as
put pointer to writr! next record
to this DESTID.
OutP~
Put Pointer
7. CICSIVS updates put pointer as
each record is written. At end of
track, CICSIVS allocates new
track chained to first, for use
when subsequent records are put.
~------.--------.---
Figure 4-2.
Intrapartiticn Disk Crganization
Transient data maintains a series of tracks allocated to each active
destination, based on the dYEamic requirements fer intraFartition disk
space. However, recerds are logically read from a destination in the
seguence in which they were written; it thus appears to the CICS/VS
task as if it were oFeratiEg on a normal sequential data set. The data
set is actually a direct access file.
INTEAPAR~ITION
QUEUE USAGE
As discussed above, intraFartltion queues are generally used to
accumulate and process data as a batch of records. The various
application uses to which intrapartition queues can be applied are new
discussec in more detail.
Records may be accumulated as a batch on an intrapartition queue or
destination. Retrieval and Frocessing of these records are achieved
98
CICS/VS system/Application Design Guide
by a task issuing transient data GE! macro instructions specifying that
intrapartition destinaticn. !he initiation of these tasks .ay be
achieved in one of three ways:
!I§D§A£!12D Ini!i§!i2D: A transaction entered by a terminal can
initiate a task which issues transient data GE! .acro instructions for
a particular intrapartition destination. Data retrieved in this way
can then be processed as required.
In!~~§l ~~ntr~l
Ini!i§!i2D: A task can be initiated at a future time
based upon elapsed ti.e cr time cf day. !his task can issue transient
data or interval control GE! .acro instructions to read records queued
on an intrapartition destination and process the.. (See "Interval
Control.")
Ii§k I~i!i~!i~D: A task .ay be automatically initiated by
transient data when a specified nu.ber of records have been written to
an intrapartition destination. ~he trigger level specified in the DC!
entry for that destinaticn is co. pared with the count of records which
still remain to be read. ihen the queue count eguals the trigger level,
a specified task (as identified by a transaction code in the DC! entry)
is initiated. !his task may issue transient data GE! .acro instructions
to read and process the data on that queue. !his is discussed further
in the sEction, "~erDinal outFut."
!Y~~~i~
CICS/VS supports the recovery of intrapartition transient data
queues on a warm start fcllowing a ccntrolled shutdown, and on an
emergency restart following an unccntrolled shutdown. The DC! status
of each intra partition desticaticn is reestablished to reflect the GET
pointer, PUT pointer, gueue count and trigger level status as it was
prior to the shutdown. Intrapartition queues are recovered, and
automatic task initiation can then proceed after eICS/VS restart as if
shutdown had not occurred.
On emergency restart follcwing an unccntrolled shutdown, any
intrapartition destinatitns can be recovered to .reflect all activity
against those destinations up to the point of unccntrolled shutdown.
This is called "physical reccvery." Alternatively, any intrapartition
destinations can be recovered to rEflect the activity of co.pleted
tasks prier to uncontrolled shutdowni all in-flight task activity at
unccntrolled shutdown is backed out during an emergency restart. This
is called "logical recovery." ThE User specifies in the DCT, at syste.
generaticn time, whether an intrapartition destination reguires physical
recovery or logical recovery. Befer to "Transient Data Becovery" in
Chapter 8 for additional infermatien.
Data may be directed to a ter.in~l from many tasks. That ter.inal
may presently be active either entering input or receiving output fro.
one task. When ether tasks wish to transmit output messages to that
same terminal, it is necessary for these messages to be gueued on disk
until the ter.inal is ready to rEcei~e the ••
This message queuing is achieved tyreguiring the other tasks to
write the terminal output .essages ~o a transient data destination.
This destination is intrapartition, and further.ore is identified as
being associated with a terminal. The destination identification used
~y§! be identical to the terminal idEntification in the ter.inal control
tablE (TCT) entry for the associated terminal. Tasks may. issue
transient data PUT macro instructions specifying as a destination
ChaptEr 4.
CICS/VS Data Banage.ent Design
99
identification the terminal identification. These output messages will
be ~ueued in the intraFartition data set (see Figure 4-3).
t~en
To initiate transmissien of these output messages to the relevant
terminal, a trigger level ef 1 is generally specified for that terminal
destination. As socn as cne cutFut message has been written to that
terminal intrapartition destination, a task (identified by a transaction
code in that DCT entry fer the relevant destination) is eligitle to be
automatically initiated. The prcgram used by that transaction code
will conventionally be a ccmmcn Frcgram, developed by the installation,
to transmit data from various destinations to their relevant terminals.
However, to be able to transmit messages from the intraFartition
destination to the terminal, that terminal must be idle and able to
receive automatic output-~that is, the output sent to the terminal is
not in response to a transaction entered earlier by the terminal.
Accordingly, unless the associated terminal is idle and able to
receive output, a task is not automatically initiated based upon the
trigger level of a term~nal destination. If these conditions exist,
the task is initiated. The terminal is allocated to that task as if
the terminal itself had entered the transaction code which initiated
the automatic task. The automatic task ma~ now issue transient data
GET macrc instructions tc retrieve outFut messages from the particular
terminal intrapartition destination. These messages may be transmitted
directly tc the terminal using CICS/VS terminal centrol or basic mapping
support macro instructions.
100
CICS/VS System/ApFlication Design Guide
CICSIVS PROCESSING
INPUT
Program
_._
--r--
---- .;>
DFHTD TYPE ,PUT
DESTIDcTRM1
~
OCT
TRM1
~
Terminal
Trans Code
Trigger Level
Queue Count
TCT
1. Application program issues transient data 'put macro, specifying
same destination ID (DESTID) as
terminal I D of terminal to receive message (TERMID=TRM1 for
example).
2. CICSIVS locates entry in OCT for
DESTlD=TRM1.
3. DESTID is for terminal queue,
CICS/VS puts output message to
intrapartition data set.
Term. Able To Rec.
~
~~>
r-:=>
4, CICS/VS uses transaction code in
DCT ENTRY=TRM1, If trigger level
equals No. of messages queued on
disk. (That is, queue count).
TRM1
>
OUTPUT
'--r--.--
Task
I
~
r-;:::>
5. If terminal able to receive message
(as shown in terminal control
tablel. a user task is initiated by
DESTID=TRM1..
Area
C"""
~
----TCT
TRM1
)
Program
~
~>
-'--
6, Initiated user task is given control of TERMINAL=TRM1. User task
gets output message from disk
DESTID=TRM1.
r-r--
DFfHD TYPE=GET
DESTlD=TRMl
1<
-..-"'>
7, User task transmits output message to TERMINAL=TRM1.
Intrapartition
Data Set
Figure 4-3.
'--'--
Terminal output Via
Intra~artition
~
Data Set
To indicate whether a terminal may receive autcaatic output or not,
a processing status is defined fer each CICS/VS terminal. The
precessing status codes are:
•
TEANSACTICN status
•
TEANSCEIVI status
•
EECEIVE status
•
INPUT status
•
PAGE status
•
AUTOPAGE status
Chapter 4.
CICS/VS Data "anagement Design
101
TRANSACTION processing status indicates that a terminal is unable
to receive automatic output. It can receive outFut only as a result
of an inFut transaction entered from that same terminal. Output queued
from other tasks for a TRANSACTION status terminal can be transmitted
to it only when the terminal oFerator enters a transaction code which
will read the data from the relevant intrapartition queue, and send it
to that teiminal~ The terminal oFerator has contrel over when he will
receive the gueued output. Generally, and particularly for video
terminals, one intrapartition message would be trarsmitted each time
the relevant transaction code is entered~ The terminal operator can
then assimilate the information Fresented to him before the next output
message is requested.
TRANSCEIVE status indicates that a terminal may enter input
transactions, but can also receive automatic outFut from ether tasks.
This is generally used fer hard-ce~y terminals, where several lines of
output may be automatically transmitted when the terminal is idle.
RECEIVE status indicates that a terminal is unable to enter any
input data, but is only able to receive automatic output from other
tasks. This is generally used fcr printers.
INPUT status indicates that a terminal can enter data but cannot
receive data.
PAGE status indicates that a terminal can only retrieve pages on
request, one at a time.
AOTOPAGE status indicates that a terminal will receive all pages
queued fo:r it.
Two additional terminal status codes are used to indicate the
activity status of each CICS/VS terminal. These are:
•
IN-SERVICE status
•
OOT-OF-SERVICE status
IN-SEFVICE status indicates that the terminal is presently active
and able to process as defined above.
OOT-OE-SERVICE status indicates that the terminal is presently
inactive, either because it has been marked out-of-service by the master
terminal operator for example, or because of an unrecoverable I/O error
which occurred on that terminal. In this case, it is unable to enter
any messages or receive any output, automatic or ctherwise.
Thus, for a task to be automatically initiated based upon a terminal
intrapartition destinaticn trigger level, the relevant terminal must
have the following status:
•
IN-·SERVICE status
•
TRANSCEIVE status, or RECEIVE status
If the terminal is OO'I-CF-SERVICE, messages are accumulated on the
intrapartition destinatien qteue until the terminal is placed
IN-SERVICE. If the status is TRANSACTION, messages are also accumulated
on the intrapartition queue until either the status is changed to
RECEIVE or TRANSCEIVE, or the terminal operator enters the transaction
code to initiate a task which will read the messages from transient
data and sEnd them tc the terminal.
A VTAM-supported terminal (such as the 3600) which supports automatic
task initiation, may be IN-SERVICE and in ~RANSCEIVE or RECEIVE status
102
CICS/VS System/Application Design Guide
as indicated in its relevant TCT entry but may not currently bE
connected to CICS/VS. It may be operating offline or be communicating
with other VTAft application prograas. If a task is to be automatically
initiated for that terminal, CICS/VS will re~uest VTAft to establish
connection with the relevant logical unit. This Day require VTAft to
request that another VTAM application program communicating with the
logical unit release it for connecticn to CICS/VS, or may require VTAft
to establish a new logical ccnne~tion (session) to the logical unit
currently in offline mode.
B2!iij~~!iQD
2t
~~~~ed
Qy!]Y!
~~§§sg§§
In the case of a TBANSACTION status terminal, some indication should
be given to the·terminal operator that messagEs are queued. This can
be done either by the terDinal cperator periodically requesting that
any messages queued be sent to him, or through th~ techniques shown in
Figures q-q and 4-5.
Figure 4-4 shows one terminal operator notifi~ation technique. The
application program that retrievEs the data from Transient Da~a may .
indicate in a standard area cf a display screen the·number of messages
to be sent. This is then presented to the prograa for incorporation
into the output message that is sent to the terminal. Part of the
response sent back to that terminal then indicates the number of
messages presently queued to be transmitted to the operator upon his
request.
APPLICATION PROGRAM PROCESSING
INPUT
Application
Program
----(
Output
Message
f
1. Application program links
to common user routine
after preparing output
message, and before sending
it to terminal.
Uo. '0",;0.
~
Examine OCT
Entry Queue
Control For
Terminal
Insert Queue
Control In Messageq
I(~
Appl ication
OCT
I
(
;.
Terminal
Queue Control
~lJ
2. Common user routine examines queue count in OCT
entry for this terminal.
3. If messages are queued to send
I
Msgs Queued
to terminal, user routine
Output
Message
inserts number of messages
queued in standard area
of output message.
4. User routine returns
5. Application program sends
output message, with count
of messagas queued, to
terminal.
(Cont'd)
I
con~
trol to application program.
Program
Figure 4-4.
OUTPUT
1<
-f
Msgs. Queued
I
\~
--Output Massage
At Termlnel
Notification to Terminal Operator of Autoaatic output
A second technique is shown in Fig~re 4-5, and utilizes the terminal
paging facility of CICS/VS to control automatic output to the terminal.
Chapter 4.
CICS/VS Data Manage.ent Design
103
The terminals must be specified as T~ANSCEIV! or EFCEIVE status, such
that autcmatic output may te sent to them. Tasks preparing output to
be transmitted tc a specific terminal preFare that output as a series
of pages to be displayed tc the teLmina1. These Fages, however, are
directed to tempcrary stcragE through the use of the BMS terminal paging
macro instructions, instead cf to the intrapartition destination for
that terminal.
The terminal operator may then Leguest at his convenience pages of
information to be displayed in whichevEr sequEnce he requires.
INPUT
OUTPUT
API'LICATION PROGRAM PROCESSING
Application
Program
1. Application program prepares
pages to be sent to terminal
(for e~ample, Termid·TRM1).
~
page4
I
Page 3
I
Page 2
Page 1
Put Pages
Prepare
Output
Message
1
Output Msg.
"MSGS READY
2. Program issues BMS paging
macro instructions to
write pages to temporary
storage.
rlTLE
~XXXXXXX"
tor him.
Message
Routing
DFHBMS
Type:
Route
(
3. Program prepares output
message to notify operator
of titles of pages stored
-- r----- ~
PAGEID~XXXX
1
Temporary
Storage
,I
r---"1----,...,.........,
"MSGS READY
-PAGEID=XXXX
- TITLE=XXXXXXX"
Route=TRMl
1
4. Program uses BMS message
route macro instruction
to send message to
t.rminal·TRM1.
Terminal-TRM1
5. Message is sent by CICSIVS
'MSGS READY·
PAGEID=XXXX
TITLE=XXXXXXX'
as soon as terminal is able
to receive it.
~-------------------"-------
---.----------------,
Paging
Command,
TempOrary]
Storage
""""'-'-- - - - - ":>
6. Tmminal operator later
enters paging command,
requesting pages in
sequence desired,
Terminal-TRM1
Figure 4-5.
L:PJ
Pagel
I
Page 4
Page 2
Notification of PagEd output
The task that generated tbe pages for display may also issue the
BMS BOUTE macro instruction to send a message to the terminal notifying
it of the fact that pages have bEEn stored, and identifying the pages
so that they can be disF1ayed, when convenient, ty the operator entering
CICS/VS terminal paging commands. Thus the amount of information the
terminal operator has to'rEad as the result of automatic output. is
limited to one 1ine# and he can USE the CICS/VS paging commands to
request subsequent output when he desires it. Terminal output formats
should be designed to reserve at least one line cn display terminals
for autoDatic system-to-operator messages of this nature.
This second technique is based on terminal Faging, which utilizes
temporary storage and VSI!.
If a task is to be autc.atica1ly initiated to SEnd output to a
VTAM-supported ter.ina1 such as the 3!OO, CICS/VS Establishes a logical
connection, if the relevant logical unit is not currently connected to
CICS/VS. The 3600 IP controlling that logical unit is then notified
of the requirement by CICS/VS to automatically initiate a task on behalf
104
CICS/VS syste./lpplication Design Guide
of that logical unit. This is achie~ed by CICS/VS requesting VTAft to
send a "tid" command. On receipt cf the bid, the AP can notify the
terminal operator (perhaps by displaying a message or by turning on an
indicator light cn the 3604) that automatic output is to be sent to
him. If he indicates that he can receive that output, the AP can
respond positively to the bid. CICS/VS then automatically initiates
the task to send data to the AP, and henc~ the terminal operator. If,
however, the terminal operatcr dces not wish to accept automatic outp9t
at that time, the AP can res Fond negatively to the bid. CICS/VS viII
not reissue the tid at a later time. ihen the terminal oFerator is
able to accept the automatic outFut, he notifies the AP. The AP then
transmits a "ready to rec·eive" cClllland to VTA!!, and hence CICS/VS.
CICS/VS then automatically initiates the task as discussed abo~e. Refer
to the ~1~~!~ Ag~~n~~g ~~Jm~Di~~!i2D gyig§ for further information.
If none of the above techniques is to be utilized, the terminal
operator can periodically enter a user transaction which reads any
messages queued for that terminal ~estination in transient data, and
transmits those messages tc the terminal. This does not require the
use of the techniques Fre~iously described, but has the disadvantage
that it is completely dependent upon the terminal cperator.
121
~
High gXi2Xiil
iI2~§§§iD~
CICS/VS intrapartition queues may be utilized fcr low (or high)
priority processing_ A prcgram can receive transactions froll a
terminal, validate them, and notify the terminal cf any error messages.
Valid transactions are directed to an intrapartition destination, and
queu~d for that destination until a specified trjgger level is reached.
A terminal is not associated with this destination. When the trigger
level is reached, a task is autcDatically initiated based upon the
transaction code specified for that destination. As no terminal or
operator is associated with this task, the task Friority used in
processing these transactions is the transaction priority as specified
for that transaction code in the program control table (PCT). The
initiated task may read the transactions queued to that intrapartition
destination, process the., and update any required data sets depending
upon the application requirements. Frocessing of data may then proceed
independently of subsequent terminal input.
This technique is utilized by the asynchronous transaction processing
(ATP) facility in CICS/VS (see Chapter 3). A batch of transactions
may be entered frOB a batch terminal using the ATP transaction, CBDR
(refer to Figure 3-11). This batch is given a batch name by the
terminal operator, and each transaction is queued on a transient data
intrapartition queue until all batch input is completed. At this time,
a task (or tasks) is initiated, tased upon the transactions in the
batches, to Frocess those batches. In the meantime, the terminal
operator is free to enter any other transactions, including other ATP
batches.
During processing of the ATP tatches, terminal output is directed
by application programs to intraFartition destinations. This terminal
output may be retrie~ed and transmitted to th~ terminal, when requested
by the terminal operator. This is achieved by entering the ATP
transactio~ code CiTE (see Figure 3-11).
REUSABLE INTEAPAETITION CUEUES
IntraFartition destinations can be specified as nonreusable or
reusable. Nonreusable queues accumUlate data ever the entire CICS/VS
operational Feriod, including any warm starts following termination of
Chapter 4.
CICS/VS Data
~anagement
Design
105
CICS/VS (see "CIeS/VS Initialization" in Chapter 8). Data on
nonreusatle destinations is not destroyed until transient data is cold
started, or until explicitly purged by user programs.
If reusable queues are emFloyed, when an application {rogram issuing
a transiEnt data GET macre in~truction causes data to be read from a
new trac)t, the track just read is automatically returned by transient
data to the pool of tracks available for use in satisfying other PUT
reguests~
This also causes transient data to refermat the returned
track for later use, and may in some cases result in performance
degradation during this refor.atting.
The intrapartition data set can therefore be utilized most
efficiently for those destinations for which data does not need to be
retained; however, other destinations containing data which must be
retained for audit or recovery pur{oses, are not disturbed.
INDIBECT DESTINATIONS
CICS/"S transient data uses extrapartition, intrapartition, and
indirect destinaticns.
An inclirect destination has its own destinaticn identification, but
in turn identifies another destinaticn. Output Eventually to be
directed to specific devices may be written to a "logical"
intrapartition destination. This logical destination identification
is an indirect destinaticn, which in turn specifies the destination
for the Fhysical device to be used to receive that output (see Figure
4-6) •
OCT Entry
PROGRAM A
OFHTD TYPE=PLJT
DESTID=INVC
(
INVC (DESTID)
(TYPE)
INDIRECT DEST
PRTR
OCT Entry
I
PRTR (DESTID)
(TYPE)
INDIRECT OEST
PRTI
OCT Entry
I
PRTl (DESTID)
Access Method
f
DCB/DTF
(TYPE)
EXTRAPARTITION
J
DCB/DTF NAME
~
=PRTl
OCT Entry
PROGRAM B
PACK (DESTID)
(TYPE)
OCT Entry
TRMl (DESTID)
INDIRECT DEST
(TYPE)
DFHTD TYPE=PUT.
DESTID=PACK
Figure 4-6.
TRMl
TERMINAL
Indirect Destinations
If the output is to be subsequently directed to seme other device,
the application ~rograms dc not have to be changed. The output is
directed to the relevant logical destination. However, the entry for
that indirect logical destination is changed in the DCT to refer to
106
CICS/VS
Syste./Ap~lication
DEsign Guide
the new device, which may be either intra~artiticn, such as a terminal,
or estrapartition, such as a tape, disk, or printer.
Thus the amount of maintenance resulting from a change in the
terminal network configuratien, for example, is reduced to only a change
and reassembly of the DC!.
Different types of output to be directed to the same terminal should
be written to different lcgical indirect destinatiens. These different
destinations may refer indirectly to the same terminal destination.
If, at scme later time it is decided to separate logical output across
terminals, instead of havitg it appear on the saDe terminal, this can
bE achieved merely hy changing the relevant indirect logical
destinations to point to the new terminals tQ receive that output. No
change need be made to the afplicaticn programs.
As well as reducing the a.eunt cf program maintenance resulting from
a change in the terminal net~ork c~nfiguration or a change in
application requirements directing output to different terminals,
indirect destinations have other useful purposes. These are summarized
below.
By directing output to logical indirect destinations instead of to
specific terminal destinations, the ~rcgrams now become independent of
the particular device selected te receive that output. An indirect
destination may ~oint to any intra~artition or extrapartition
destination. Por exampl~, the output which may ncrmally be directed
to a terminal printer may be directed to an extrapartition destination
line printer. This can be achieved by writing the output to an indirect
transient data destinatien, and then reassembling the DCT to point to
the line printer extrapartition destination identificaticn.
The use of indirect destinaticns and device independence raises the
question of terminal backup. Through the use of indirect destinations,
programs are no lODger dependent u~on the availability of specific
terminals. In the event of a terminal going down, an alternative
terminal or device (tape, disk, cr printer) may be assigned to receive
the output logically directed to the failing terminal.
On terminal failure (see figure 3-12), it is not practical to
reassemble the destinatien centrel table to changE the indirect
destination to the backup device, without terminating CICS/VS. In this
case, the system design team should evaluate the requirement for a
backup capability to enable critical information to be received.
If it is necessary that infor.atien be directed to an alternative
device, then the destinatien control table may be changed dynamically
by user-written programs. The user may write an application program
(initiated by a specific transacticn code) to search the destination
control table for the specified indirect destinatien. The destination
identificaticn pcinting indirectly tc the failed device can then be
modified to point indirectly te the destination cf an alternative
device. Data already gueued for the original destination cannot be
sent to the failed terminal, but must then be copied by the user program
to the destination gueue of the allocated device. Subsequent data
written to the indirect destination will then automatically be directed
to that device (see Figure 4-7).
Cha~ter
4.
eICS/VS Data ftanagement Design
107
~9!~:
In the event of abnerRal termination because of a Fcwer failure
or machine check r and subsequent reinitiation of CICS/VS r such user
modifications to the nCT may be lost. The neT will be initialized by
CICS/VS as if the user modification had not occurred, since it is not
aware that the nCT was changed by the user. This can be overcome by
the user program journaling each neT modification and reestablishing
each modification itself after reinitiation.
(SEe "Journaling.")
INPUT
Program
I DFH"!"C_TYPE=
~:E
APPLICATION PROGRAM PROCESSING
I
OUTPUT
1. Application program Issues terminal control WRITE macro
instruction to transmit message to terminal.
(Terminal)
2. Terminal indicates transmiss~
error occurred, and message
failed to be sent correctly.
Transmis·
sion Error
Indication
3. CICSIVS attempts recovery. If not
User-Written
Terminal
Error
Program (TEP)
successful, control is passed to
user-written terminal error
program (TEP).
t
User-Suppl ied
Alternative
Device
Table
--
r-r-
~>
'----.----1
\
TEl>
DFHTD TYPE=PUT,
DESTID=XXXX
Figure q-7.
-'--
4. User-written TEP scans userprovided alternative device
device table to identify an
alternative terminal or device
(tape, disk, printer) to receive
message.
5. User TEP writes failed message
to transient data destination
for alternate device XXXX, to
send message when terminal
available.
6. User TEP then copies messages
queued to destination of failed
terminal across to destination
of alternative device.
II
<
7. OCT for error terminal is modified by user TEP to point to
alternative device for subsequent reference.
~------------------------
~
OCT
~
TransFrient
Data
LJ
Terminal Backup and Beconfiguration
The transactien code allocated to the nCT modification program may
be given a security code se that only certain authorized terminal
operators, such as the master terminal operator, may use it.
DI~g!i~ l~!ingl Ej~Qnfi~YXAti9D
The user-written tCT Modificaticn program for terminal backup
described above Day also be utili2ed for dynamic terminal
reconfiguration. If at different tiDes of the day it is required to
change the destinatien of logical eutput to different physical devices,
this can be achieved by using the [CT modificatien transaction code
and frogram.
This raises the possitility of dynamically reconfiguring the terminal
network, or other devices, tc receive output. Per example, at one time
of the day output may be directed to a particular terminal printer,
while at other times it may te directed to a disFlay screen, and again,
to a linE printer.
As described above, any dynamic neT modification made by user-written
programs should be journaled by the user r and ut'ilized after CICS/VS
reinitia1ization to reestablish the modified nCT.
108
CICS/VS SysteD/Apflication Design Guide
The availability of CICS/VS terminal device independence, which
enables application progra.s to FresEnt output Bessages in a standard
form regardless of the terminal type which will receive those messages,
lends itself to such dynamic reconfiguration capability. Dynamic
terminal reconfiguration is discussed further in "Terminal Backup" in
Chapter 8.
Because CICS/VS allows an] terminal (or simulatEd terminal such as
card reader, disk, or taFe) to enter any transaction, the user-developed
support of dynamic rEconfiguraticn also enables the master terminal
operator to exercise centrcl over where output is to be directed hased
upon online application reguiremEnts. Used in this way, transient data
and indirect destinations become pcwerful online aFplication tools.
Some VTAM-supported terminals (such as the 3600) permit dynamic
terminal reconfiguration to te pErformed by the ccntrollet for the
devices controlled by an AP. Through use of logical device addresses,
the AP identifies devices to be used for I/O. The contrc11er relates
their logical device addresses tc Fhysical device addresses using a
table associated with that AI. The controller also permits this table
to be changed dynamically so that a specific logical device address
may refer to a different physical device. The 3€00 system operator
may request this reassignment to te carried cut ty a user-developed
AP. Por example, a 3600 system cFerator may reassign an alternative
printer for use ty an AP with an inoperative printer.
This device reassignment is transparent to CICS/VS. CICS/VS
communicates output disposition to an AP through use of logical device
codes (LECs). The IP then relates the logical device code to a logical
device address and issues the relevant output reguest. The controller
then relates the logical device address to a physical device as
previously described.
The AP can interpret the tDC tased upon app1icaticn requirements
and identify a legica1 device address to the contreller. The controller
can then identify the physical device currently assigned to that logical
device address fer that AP.
Use of alternative devices and device reassignment support in the
3601 provides additional system flExibility and availability for 3600
users.
Chapter 4.
CICS/VS Data !anageaent Design
109
This chapter presents a tutorial discussion of data base design.
Experienced ClCS users may wish to omit reading about those facilities
which are identical to those provided in previous versions of ClCS.
New facilities provided i6 CleS/VS include support of VSAM data sets
and DL/l data bases. Appreciation of these facilities can be obtain~d
ty reading the following topics:
• Data base iuplementaticn for applications
• Bandom record deleticn (VSAM only)
• Locate mode Frocessing (VSAM only)
• Mass record insertion (VSAM cnly)
• Skip sequential browsing
• ieighted retrieval function (VSAM only)
• Becord identification
• Phonetic conversion function
• segment updating (key-se9uenced VSAM)
• Becovery considerations
• DL/l products
• Data base selection critEria
Because of thE. significant caFability available both to the
ClCS/DOS/VS and the eleS/eS/vs user for accessing DL/I data bases, it
is strongly recommended that the CleS/VS user whe is not familiar with
DL/l concepts and advantages read the DL/I Products section in its
entirety.
In designing data bases, it is important to identify thE data base
requiremEnts of each apFlication to te implemented. Accordingly, this
chapter first examines the data t~se requirements of a number of
diffErent applications, to identify these factors most important to
the applications in selecting the appropriate data base support.
Following this, the services offered by eleS/VS file control and by
the various DL/l products are deserited. ~echniques are identified
for thE design of data baSES using these facilities to satisfy various
application requirements. At the end of the chapter, a number of
selection criteria are discussed for the determination of the most
appropriate data baSE support in specific environments.
Chapter 5.
eIeS/VS Data Base Design
111
DATA BASE DEPINI7ION
The term "data base" lay have a different meaning to different online
applications or installaticns. A general definitien of a data base,
which covers mest consideraticne, is:
"A structured nonredundant collection of interrelated informatien
accessible to many users at the same time."
The term "structured" in the definition refere to the organization
01 informatien in a manner by which it can be easily retrieved. The
following two structuring apFroaches can be used:
• Fhysical structure
• Logical structure
To reguire an applicatien Frogram to be aware of the physical
structure of the data base ilplies that any change to the organization
of inforDation OD that data tase might also necessitate modification
of the applicatien programs which access the data tase.
A logically structured data base is one in which an application
program can refer to infer.ation in that data base by name, without
necessarily being aware cf the physical organizaticn or location of
data on the data base. The Fhysical structure or organization may be
separately described by a data description table, while the application
prograD can describe its 1cgica1 accessing and usage of the data using
a program description table. ThesE: tables provide an interface between
the ap~lication Frogram and the Ehysical structure of the data base.
The advantage of logical ~tructureS is that a change in the data
base generally only requires a changE in the rel~vant tables, often
without ne~essitating any change in the application programs. This is
termed data independence, and results in reduced maintenance of prograDs
follewing modificaticn ef a data basE.
Data tases which are referenced b] Fhysical structure usually have
limited (or no) data independencE, and programs may require considerable
modification following a data base change. However, programs that
refer to data bases logically, exhibit a much higher degree of data
independence. Any data base changes are reflected in the data base
tables and program tables rather than in the program itself.
The term "noriredundant" in the above definition refers to the abil{ty
of a data base to record certain information (for example, a customer's
name and address) once only, but make that information available to
other prograDs that use it.
Traditionally, batch apFlicaticns and programs are developed with
their own data sets, often disregarding information that is recorded
on separate data sets for seEarate aFP1ications. The result in the
traditional batch environment is the existence of redundant
information--that is, the sale infer.ation is often recorded in many
data sets. A change to that information must be propagated through
all data sets to ensure that the infermation remains in step across
112
eleS/VS System/Application Design Guide
all applications. The advantage in recording information only once,
and yet making that cne record of. information available to all
applications, is that once that information is changed, the change is
reflected across all applications that us~ the infermation.
A further advantage resulting from nonredundant storage of
information is storage econo.y, either on disk or tape.
The term "collection of interrelated information" in the definition
refers to the consolidation ef infer.ation relating to applications at
one common point. The advantages offered by such consolidation include:
• More readily available irformatien
• More timely information
• Elimination of redundant information
• Saving in disk or tape storage requirements
• Easier maintenance of informatien
• Development cf infor.atien relationships
The last advantage listed refers to a significant advantage of data
bases: the determination of the logical relationship of all information
referring to a particular entity. 7he identification of such 10g1cal
relationships of information enables that information to be utilized
for better management of ancrganizaticn's activities. This information
may have been available previously, but may not have been utilized
effectively before iDplementing the data base.
To illustrate the importance of the data hase factors
discussed above, namely:
• Interrelated infermaticn
• Logical structuring of information
• Data independence
• Nonredundant information
the application reguire.ents for data base support in the following
industries are discussed:
• Manufacturing
• Banking
• Insurance
• Medical
• Pharmaceutical
• Distribution
• Law Enforcement
• utilities
Chapter 5.
CICS/VS Data Base Design
113
The entire data base reguire8ents will not be described for each
However, some data base requireDents will be identified
here, to use as a base fer subseguent discussion in this chapter and
in Chapter 11. The reader aay wish to read only that section below
relevant to his ewn industry, and then refer to the topic "Data Base
Implementation for Applicatiens."
industry~
One of the most iRFortant reseurces in each of the industries next
discussed is data. iithcut access te such data or information in these
indugtries, the following ap~lications cannot exist. The availability
of such information can open apF1ication Fotentials which were not
practical previously.
The application design in each of these industries is discussed in
more detail in ChaFter 11. However, the data base requirements
introduced here highlight the main requirements fer data base support
in each industry. References are also made to diagrams in Chapter 11.
The DL/I products provide extensive data base support, which exceeds
that prolrided by CICS/VS file centrol. File contrel is· a da ta
management system which can te utilized to access data sets. However,
the user must be aware of the physical organization of data on those
data setsl. DL/I refers te data in a data base, while CICS/VS file
control refers to data in data sets. ihile recognizing the different
levels of data base suppert effered ty DL/I and by CICS/VS file centrol,
te avoid confusien of terminology between data sets and data bases,
all infoI:mation is discussed belcw as teing part of a da ta base,
regardless of whether CICS/VS file centrol or DL/I is used.
8ANUFACTURING IanUSTRY
Some of the infor.atien requireaents of this industry relate to
(or production) work orders. The data d~scribing the
products to be manufactured,· parts to be utilized, availability of
materials: and resources, and status and location of work orders in the
manufacturing process are essential to manufacturing control. Figure
11-1 illustrates a manufacturing Froduction order and status reporting
system.
manufact~ring
~~!A~!~ri~g !~~~ ~rde~ ~!1!,~§!
At least three data bases aay te·reguired for control of information
relating to manufacturing. Cne is the manufacturing order data base,
on which the entire manufacturing apFlication deFends. This generally
contains the record for each manufacturing order as illustrated in
Figure 11-2. This manufacturing order data tase centains information
describing the manufacturing requirements for each werkerder, together
with infermation reporting the status of that work order at each step
in the manufacturing process.
!!~1 !Y!!~~ ~~2§§=~!i!I§~~s ~!5 ~!§s
A second data base is used to indicate relationships between part
numbers and open manufacturing orders using a particular part. This
data base is called the part numter cross-reference data base. By
accessing this data base for a particular part, each current
manufacturing crder which uses that Fart may be identified, as
illustrated in Figure 11-3. Further information relating to that
manufacturing order may te obtained from.the manufacturing work order
data basE:.
11q
CICS/VS systeR/App1ication Design Guide
A third data tase is the Danufacturing planning data base, which
contains information for each manufacturing ordEr that has been planned
and that will be released to the shop flcor for ~ork. This data base
is used mainly fer audit trail and control functions. The information
containea in this data base is illustrated in Figure 11-4.
As manufacturing crders are received, they are added to the
manufacturing oraer data base, and all parts utilized by that
manufacturing werk erder are added tc the part number cross-reference
data base. As each work order is planned for manufacturing, it is
entered into the manufacturiDg planning data base.
!!!l t a
~~~ 1!§.9Yi~SJ!n.1§
The data base reguireeents for this application should support:
• Logical relationships of data to be established; for example, all
work orders using a particular part.
• Multiple occurrences of infor.ation relating tc particular data,
for example, multiple status infermation relating to a work order,
or multiple work orders relating to a part.
• Adding inforaation to tbe data base, replacing or altering
information, or deletilg infcr.ation. This enables new work orders
to be added, existing work orders to be altered, or completed work
orders to be deleted. In addition, one work crder may be split
into two or more work orders. ~his implies the need for changing
the original werk order and adding each new split work order.
Additional facilities which should, ideally, be provided by data
base support in this. industry are:
• Data indepenaence
• Nonredundant informaticn
• Easy maintenance
• Batch and online aCCESS to the data base
BANKING INDUSTBY
The applicaticns often cf interest in this industry are:
• savings tank and mortgage loan system
• customer information system (called Customer Information File CIF)
The savings bank and .ortgage loan system, when iapleaented as an
online application, enables savings bank deposits and withdrawals and
mortgage loan transactions to be entered from teller terainals located
in various branches of the bank. These transactions are used to update
savings bank and loan accounts. Pigure 11-7 illustrates a typical
savings tank and mortgage loan system.
Chapter 5.
CICS/VS Data Base Design
115
The customer information system is used to identify all information
relating to a customer's activities with the bank. This enables the
following informaticn to be identified for each customer:
• Savings accounts
• Checking accounts
• Loan accounts held
Furthermore, given a custemer's name and account number, it can also
be determined frcm that account all ether accounts owned by that
customer. Figure 11-11 illuEtrates a typical banking customer
information system.
To implement these applications, several data tases are required.
These data bases should te interrelated, to allow implementation of
the custcmer inferaaticn system. A descIiption of these possitle data
bases follows.
~~!i~g§ J££2~~! ~g!s Ba§~
The savings account data tase contains information relating to each
savings account·-such as aeceunt numter and current balance.
Information describing each transaction against that account, such as
deposits, withdrawals, and interest, is also contained in this data
base. There may be multiple transactions against each account, as
illustrated in Figure 11-8.
The mortgage loan data base may bE similar to the savings account
data baSE, as illustrated in Figure 11-8, except that the multiple
transactions that occur against a loan account are normally payments.
The initial granting of a loan usually results in the cr~ation of a
new loan account, against which there may be multiple transactions
reflecting periodic payments against that loan, and interest
calculations based upon the current talance.
~~~£~!~g Acccu~! ~s!g ~g§!
The checking account data base is somewhat sioilar to the savings
account data base, except that the multiple tran~actions that occur
against the checking acceunt are checks written, or deposits received,
together with fees charged against the account, as illustrated in Figure
11-12.
~~sto.!!.§l:
!££2.Y.n!
g;2§§=j~!fi~~£!
.R!!g
~§~
The customer account cress-reference data base generally provides
information describing the customer, such as namE, address, and
telephone number, and contains inf~rmation describing every type of
account and account number held ty that customer at the bank. Because
a customer can have many different types of accounts, multiple account
references may exist (see Figure 11-9).
116
CICS/VS System/Application Design Guide
The data base support required for this application should support:
• Multiple occurrence of transacticns relating to an account.
• Logical relationship of accounts to a specific customer, to produce
an interrelated data basE.
• Add new accounts, change accounts, and delete accounts from the
data base.
• Add new transactions, change transactions, and delete transactions
from accounts.
• Using related data tasEs, record custcmer information only once,
but allow that informatien tc be available te all of the customer's
accounts se as te aveid redundant infcrmation.
• Modify the data tase without requiring program modification--that
is, data independence.
• Access the data base beth online and offline.
INSUEANCE INDUSTEY
The applicatiens within the insurance industry, covered in the
following paragraphs include:
• Policy information system
• New-business policy entry systEm
A policy information systEm is somewhat analogous to a customer
information systEm in the banking industry. It utilizes a numter of
data bases which describe all of the policies issued by the insurance
company for each customer (see Figure 11-14). Other information
relating to claims and renewals against each policy enable the insurance
company to assess more accurately a customer's insurance value.
The new-business policy entry system enables new policies to be
entered and added to the policy data tase (see Figure 11-18). In
addition, provision is made through this system to alter or delete
policies already in the policy data tase.
!Qli~x ~§!~ ~~§~
The policy data base generally contains all the information relating
to each current insurance ~olicy. In additicn, claims and renewals
against that policy are associated with the policy inforaation. There
may be multiple claims or renewals against each policy, as shown in
Figure 11-14.
The customer cress-reference data base contains information relating
to the customer, such as name and address, together with identification
of each policy number owned (see Figure 11-1E).
Chapter 5.
CICS/VS Data Base Design
117
In some cases, a representative or a territory data base may be
used. This identifies each insurance company representative, or
geographic territory, together with all the policy numbers relating to
that representative or territory (see Figure 11-17).
Data base sUPFort for these aFFlications should support the
following:
• Multiple occurrences of information, such as claims and renewals
to be associated with each Fclicy
• Multiple policy numbers to be associated with each customer
• Logical relationships of a customer's ownershiF of various policies
• Nonredundant storage of infcrmation, so that information describing
a particular customer cr policy may appear only once and yet be
accessible in many different ways
• Data independence, tc enable the data base to be modified without
requiring corresFonding IrograD maintenance
• Batch and online access to data base
I1EDICAL INDUSTRY
One online application in this industry is the control and
maintenance of infcrmaticn relating to all the patients. in a hospital
or clinic, in a Fatient informatic:o system (see Figure 11~20). This
application enables a history to bE developed for each patient,
describing all visits, diagncses, and treatments received for that
patient. In addition, each Fatient receiving certain medication or
with a particular disease can be nated to enable rapia identification
cf such Fatients receiving certain treatment or suffering from
particular diseases.
!g!i~D! ]ist~l ~!!! ~!§~
The patient history data base generally ccntains all the information
describing each patient, such as name, address, sex, and physical
characteristics. In this data baSE Day be information describing each
visit by each patient to the hosFital or clinic, each diagnosis made
for that patient, and all Dedicaticn or treatment received (see Figure
11-21) •
~~gi~ati9D ~~9§§=~§~~~~~§ ~!!!
ls§§
The medication cress-reference data base .ay contain information
describing the particular medication, together with identification of
all patients who have received that aedication, as illustrated in Figure
11-22.
Y!~ss§§
Y!!! ]s§!
A diseases data base Day be used, which contains information relating
to each disease, together with identification of all patients suffering
118
CICS/VS system/Application DeSign Guide
from that disease. Alternatively, the patient history data base can
be searched sequentially, to select all patients with a particular
disease. The use of a separate diseases data base is reccmmended if
there will be a significant Dumber of disease inquiries.
Data base support fer such a patient information system should
support:
• Multiple visits, diagncses, and treatments to te recorded for each
patient, or .,ultiple patients to be recorded for each medication
or disease
• Logical relationships of Dedication or disease to patient history
and vice versa
• Add, change, or delete patients or patient history information such
as visits, diagnoses, and treatment
• Add, change, or delete identification of patients receiving certain
medications cr suffering frOB specified diseases
• Nonredundant storage of information, such that information
describing a patient occurs only once
• Data independence, such that a modification of the data base will
not require corresponding modification of programs
• Access to the data base from batch and online programs
PHARMACEUTICAL
INDUS~RY
One online application in this industry is the entry of orders from
pharmacists for various products and the filling of those orders in
the pharmaceutical company's warehouse, as illustrated in Figure 11-24.
This application uses a pharmacist data base, describing the
information relating tc a pharmacist such as name, postal address,
ship-to address, and credit rating (SEe Figure 11-26).
Prod'y£!
~~ ~g§§
The products which may be ordered are held in a product data base
which describes the infcrmaticn relating to each product.
The synonym data base may contain display images of all product
names with the same first few characters (first four, five, six, or
seven characters for exanple), together with product information such
as unit price, unit size, discounts, and warehouse location, as shown
in Figure 11-25. This data tase is used to identify by name the product
ordered. The display image is transmitted to the terminal operator to
enable the appropriate product name to be identified.
Chapter 5.
eICS/VS Data Base Design
119
The accepted order data base contains orders which are to be filled
by the warehouse. The ~roducts within each crder may subsequently be
sequenced into warehouse location sequence for production of warehouse
packing slips (see Figure 11-27).
The order in-progress data base may have the sa~e record format as
the acceFted order data base (see Figure 11-27), and is used for
temporary storage of products ordered, until the entire order is
complete v to allcw for changes in the rirder.
The data tases used for this a~~lication may need to support multiple
occurrences of information, such as multi~le product details for
products stored in more than one warehouse. The particular data base
support used should provide:
• Access of informatien relating to
~harmacists
and products
• Add crders to the order data base
• Multiple occurrence ef deta!ls fer products in the data tase which
may te stored in several wa~ehouses
• Nonredundant storage of data, with all the information relating to
a pharmacist or a preduct, fer example, stored only once
• Data independence, such that modification of the data base does
not require corresponding modification of pregrams
• Access to the data base ty batch and online programs
DISTEIBU1ION INDUSTRY
A common apFlication in t~e distribution industry is order entry
and invoicing. This application is sometimes similar to the
pharmaceutical order entry system described above, but differs mainly
in the area of stock status checking. Orders are accepted against
products, and the product inventory is imRediately updated.
Furthermore, informatien such as issues and receipts against each
product can be retained online as part of the ~urrent preduct
information. Figure 11-28 illustrates one example of an order entry
and invoicing system.
Some of the data bases used in this applicaticn may be similar to
those used in the pharmaceutical order entry system, but with additional
inventery control information in the product data base.
~y§toB~. .~s ~~§!
The customer data base is generally a record of information relating
to the customer, such as na.e, pestal address, shi~-to address, and
credit rating (see Figure 11-30).
120
CICS/VS System/Application Design Guide
The product data base Day contain information describing the product,
together with current balance, minimum balance, reorder quantity, unit
price, and disceunts acress several warehouses (see Figure 11-31). In
addition, each accepted product order may result in an issue against
inventory, while each reorder placed a9ainst suppliers may eventually
result in a receipt into inventory when the reordered quantity is
deli vered.
These issues and receipts may be recorded in se~arate data bases or
associated with the criginal Froduct in the product data base. In this
case, there may be multiple issues and receipts against each product
in the product data base.
The orders data base may contain information describing each accepted
erder, and the products cCDprising that order (see Figure 11-29).
Products in the accepted order data base may be sequenced into warehouse
location sequence for prcduction cf a warehouse packing slip.
The order in-progress data base temporarily helds each product
erdered until the entire order is co.p1eted, in case it is necessary
to alter the order before completien (see Figure 11-29).
The ftata base support requirements for this apF1ication should
support:
• Accessing of customer information
• Accessing and updating of product informatien and inventory levels
of products in the data base which may be stored in several
warehouses
• Application of issues and receipts against a product in the product
data base
• Addition of accepted orders to the order data base
• Nonredundant infermation, by asseciating product issues and receipts
with the original product record
• Data independence, such that modification of the data base will
not require correspondin9 modification of the programs
• Access to the data base from both batch and online programs
LAW
BNFOECEHEN~
INDUSTE!
One online application in this industry is a police information
system. This is generally an inte9rated data base system containing
all information relating tc known criminals, and data available on
crim.es such as JI~'y§ 2.ES'l.DA! and suspects (see Figure 11-33).
A police information system provides a useful function, not only in
the recording and maintenance of all. information relating to criminals
Chapter 5.
CICS/VS Data Base Design
121
and crimes, but also throUgh the rElationships. of information. A police
information systEm c~n be utilized as a powerful law enforcement tool,
by examining various relatioDshi~s; for examFle:
• The personal characteristics of suspects against personal
characteristics of known criminals
• compi!lring the ..~gy§ .Q]iIJD,gi used for a particular crime against
the ):nown J!!2..9.Y§ ,gl!~'jl!g.! of various criminals
• The examination of all factc~s relevant to a particular crime and
the relation of those factors to other information
A numtler of separate data bases may be used in this ap~lication to
produce an integrated police data tase. Some of these data bases are
described in the following parag~aFhs.
~'iJiDjl ~J!9 ~j~~
The c~iminal data basE .aJ contain all information relating to each
known criminal, such as naae, kncwn addresses, aliases, and reference
information in other data bases, such as personal characteristics and
particula.r lIQgy§ .QR$UJlgi.
giaD
~S!:.t9 b§~
The crimes data base aaJ contain all kncwn information relating to
particular crimes, together with details of the crime, such as ~
2l!~IJJl9!, and referEnce to Fcssitle suspects.
~Y§R~ts ~!9 ~j~~
The suspects data baSE may be similar in nature to the cri.inal data
base, and records all kncwn information relating to each suspect of a
crime.
~2D!ic:.ti~Jl§ ~9!J ~9§!
The convictions data base may relate SOlVEd crimes to criminals,
and may indicate the punishmEnt dispEnsed.
This data baSE may contain the personal characteristics (such as
height, weight, age, and descripticn) of all known criminals, suspects,
and participants in crimes.
Mo..9.Y§ .QR!"n..9i
~9!J b!i.!i
This data baSE may contain thE .2~~ 2l!~IJag! used by known
criminals, suspects, and ~artici~ants in crimes.
122
CICS/VS system/Application Design Guide
The data tase support requirements for this aPElication are quite
extensive. The data base sUfport sheuld allow:
• The multiple occurrence ef infermation, such as aultiplereferences
to crimes and convictions for each criminal, or multiple references
to criminals for each crime
• The ability to readily aad, change, or delete information on the
various data bases
• The ability to manipulate coded and textual infor.ation of data
bases--that is, the sUFpert of variable-length text information
• The ability to identify logical relationships between various
information
• The capability to search data tases, selecting infermation based
upon specified criteria
• Nonredundant information, to reduce the a.ount of disk storage
space required
• Data independence, such that medification of the data bases will
not require corresponding modification of programs
• Access to the data bases by batch and online programs
UTILITIES INDUSTBY
One online application in this industry .ay be a Custemer Information
System (see Pigure 11-35). ihis may contain all inf~r.ation relating
to the utility company's customers, such as na.e, address, account
details, appliances installed, and their aaintenance history.
The customer data base cODtains descriptive information such as
name, address,aFpliances installed, consumption history, account
details and history, installment lean account details, and history and
maintenance history for aFFliances (see Figure 11-36). The historical
information may be part of, the customer data base and requires that
multiple entries of inforaatioD relating to the particular account or
appliance be associated with each customer.
To enable scheduling of maintenance technicians to repair faulty
appliances as reported by customers, a maintenance technician data base
can be used. It may contain infermation describing the maintenance
technician, his particular experience, a planned werk schedule for that
technician, and, possibly, service calls and repairs already carried
out. Based upon customer service calls, and unallocated slots in a
technician's schedule, technicians may be allocated to answer particular
service calls. This s~rvice call information refers to the particular
customer and appliance invc11ed. Infor.ation describing the service
call and repair may also be added to the maintenance history for that
customer's appliance in the custcmer data base.
Chapter 5.
CICS/VS Data Base Design
123
The data base support requirements for this aFplication should
permit:
• Multiple occurrence of information, such as account history er
maintenance history, te be asseciated with eacb custo.er or
appliance, or each maintenance tecbnician
• Ability to add, change, or delete customers, appliances, account
information, and maintenance infermatien
• AbiljLty to generate main tenance work erders for technicians,
accessing prior maintenance bistery for an appliance
• Ability to contain varying a.cunts of information for each customer,
such as infoImation relating te multiple appliances, or no
appliances, and extensive acceunt history, or no account history,
while still utilizing disk storage space efficiently
• Nonredundant infermaticn
• Data independence
• Access to the data bases from batch and enline programs
tATA BASE I!PLEMENTATION FCR APPIICATICNS
~s!s ~s§! ReB~j~s~~!§ ~YI~~1
The most common requirements ef data base support for the
applications are:
f~regoing
• Ability to support the multipleeccurrence of information, with
the number of occurrences varying from zero te many
• utilize disk storage mcst efficiently, without requiring storage
space to be allocated for infermation which is net present for a
particular record
• Handle variable-length informatien such as names, address~s, or
textual information fer tetter disk storage efficiency
• Add, change, or delete rEcords in a data baSE
• Add, change, or delete multiple cccurrences of information for a
record
• Nonredundant storage of information
• Data independence
• Access to the data bases by batch and online programs
Before examining the various data base support techniques available
to determine how these can satisfy tbe abcve requirements, it is
particularly important to exaainE the way in which multiple occurrences
of information fer a particular data base record can be implemented.
The two techniqUES are:
124
CICS;VS System/Application Design
Guid~
• Fhysically related cccurrences
•
lo~ically
related cccurrEnces
Physically related occurrEnces generally are imFlemented by utilizing
separate data sets. The main "rcot" information is stored in one data
set. This may be specific customer data in a customer information
system, account information in a savings b~nk and loan system, or
product information in an order Entry system.
The multiple cccurrences cf rElated informaticn are then stored in
a separate data set or data sets, and are related back to the 8ain root
information in the root data set ty means of pointers. Furthermore,
the separate occurrences cf information relating to a root can be
chained ty means of pointers.
For example, in the banking industry, all the accounts relating to
a bank~s customers Bay bE recorded in savings and loan account data
sets, with each account record ccrtaining pointers which refer back to
the customer's rcot information, such as name and address. Bach account
record for that customer may also contain a Fointer to the next account
for that samE customer in a chain of accounts. A further data set, a
transaction data set,contaiDs deFosits and withdrawals for accounts.
Bach transaction refers back to its relatEd account record by means of
a pointer, and to the ne~t transaction against the same account-in a
chain of transactions, using another pointer. This is illustrated in
Figure 5-1.
Savings
Transactions
Data Set
Figure 5-1.
Loan
Transactions
Data Set
Savings and Loan Data Base Chaining
Chapter S.
CICS/VS Data Base Design
125
The separation of the root information in one data set, with the
variable transacticn infcraation in ether data sets chained logically
to the root data set and alse to ether transacticns for that same root,
enables standard access methcds to be utilized in Froviding data base
support. The root i~formaticn may be organized as a standard DAM
(Direct Access Method), 1SlM (Indexed sequential Access Method), or
VSAM (Virtual stcrage Access Methcd) data set. Generally, the
transaction data set would be organized as a DAM data set, or an
entry-seguenced VSAM data set, tc enable direct retrieval of transaction
records. Retrieval of all the transactions relating to a particular
root requires retrieval of the root information itself, followed by
retrieval of each transaction in the chain--with a possible separate
physical access for each transaction.
This physically related chaining technique may be supported by the
CleS/VS file centrol indirect access feature, which is discussed. in
more detail later in this chapter.
The lcgically related technique for the multiFle occurrence of
information generally inccrpcrates the multi FIe transactions in the
same data set (or data base) with the root information. Most of the
transactilons relating to the root information are Fotentially accessible
in fewer physical disk accesses than for physically related information.
The data base sUFPort endeavcrs to place multiple transactions as close
physically to their logically related root information as possible.
For example, root information such as customer details is recorded
immediately followed by multiple occurrences of information, each
detailing a separate acccunt for that customer and transaction activity
against each particular account.
The data base support tc implement a logically related technique
must enable new informaticn related to the root informatien to be added
to other information for that root, existing information to be changed,
or informaticn to be deleted. This may require the utilization of
internally controlled pointers and chains which are known only to the
data base support and which are transparent to the application program.
The application program may logically regard the multiple occurrences
of information as if that information were physically adjacent to the
root information.
Alternatively, the data base support may attempt to physically insert
added information with the rcot and existing information, thus shifting
aleng other information in the data base.
The data base support available for such logically related
informaticn is:
• eleS/VS file control segmented record feature
• DL/I products
These are discussed in more detail in the rellainder of this chapter.
The features and system design_~spects of CleS/VS file control and
DL/I products are presented below. Included are the factors to consider
when selecting appropriate data base support and selecticn criteria.
126
CleS/VS system/Application Design Guide
The CICS/VS file centrel ~rogra. ~rovides data tase support fot
application programs executing under its control. It uses the standard
access methods availabl. under DOS/VS and OS/VS1 or OS/VS2 -- nam~ly
the Indexed Seguential Access aethod (DOS/VS ISA! cr OS/VS BISAa),
Direct Access Method (DOS/VS DAa or OS/VS BDA!), and Virtual storage
Access aethod (VSAM). Per the re.ainder of this chapter, "DAM" will
be used to refer both to DOS/VS DAa and OS/VS BDA!, and "ISAM" will
refer to both DOS/VS ISAM and OS/VS EISAM.
The facilities provided by the standard access methods are extended
in some cases by CICS/VS file control to provide additional support.
For example, file centrel supports the following data sets:
• Fixed-length and variable-length records
• Blocked and unblocked data SEts
• ISAa, DAft, and VSAft
Extensions provided by CICS/DOS/VS file centrol enable the support
of variable-length DOS/VS 151M data sets, which are not part of standard
support ~rovided by ~OS/VS ISAft. Si.~larly, filE control provides
support for blocked fixEd-lergth or variable-length DAB data sets,
which. are not included in the standard support provided by DOS/VS DAa
or as/vs BDAft. ~he suppert ef blecked direct access data sets is
particularly useful if those data sets are processEd seguentially by
CICS/VS programs, as discussed bElow in "Seguential Access (Browsing)."
CICS/VS file centrel allcws toth direct access and seguential access
to ISAft, DAB, and VSAa data sets.
DIRECT ACCESS
Direct access, seaetiDes referred to as random access, is supported
by file control for ISAft, CAM, and VSAM data sets. The following
services are provided by CICS/VS filE control for DAa, ISAft, and VSAft:
• Randem recerd retrieval
• Random record update
• Randcm record additien
• Random record deletion (VSAM only)
• Logically opEn/close data sets
• Exclusive control of recerds during update operations
• Variable-length ISAft recerds (both DOS/VS and OS/VS)
• Blocked DAft records
• LOCATE mode, read-only rEtriEval (VSAft only)
• Mass record insertion (VSAB cnly)
• segmented records
• Indirect access
These services enable CICS/VS file centrol to provide data manage.ent
Chapter 5.
eICS/VS Data Base Design
127
support that surpasses OS/VS or DOS/VS data management support in many
areas.
Direct access to data sets is .ade on the basis of record
identification of the particular lcgical record to be retrieved. The
record identification may be either a record key in the case of IS AM
or key-sequenced VSA! data sets, or a record location within the data
set for DAM or entry-sequenced VSlft data sets. The use of record keys
or lccations for direct access is discussed in more detail under "Record
Identification. II
Based upon presentation of the appropriate record identification by
the application ~rcgram, CICS/VS file control viII access the data set
requested by the program tc carry out the services listed above, and
described in detail in the fcllowing sections.
]~1!dc.m 1!~.S;;21:9 1!!2!~!~.!Sl!
File control viII directly acce~s the record identified by the
application program using either key or record lecation (depending upon
the type of data set) frcm the s~ecified data set. The application'
program issues a file control GET maero instruction, identifying by
name the data set tc be accessed, and indicating the location in the
program which contains the record identification. The data set name
is used by CICS/VS to locate the relevant entry for that data set in
the file control table (FC'l). ThiE entry contains specifications for
that data set, such as:
• Access method used
• Record length
• Elock length
• Key
len~th
(if applicable)
• Key location (if applicable)
This information is not contained within the application program.
In the event of a change tc the data set, the relevant changes ~ay be
made to the FCT, without affecting the application program. This
provides a limited degree ef data independence.
When the applicatien {rogram issues a file control GET .~cro
instruction, CICS/VS dynamically allocates storage to be used as an
input area (file I/O area--FIOA), and a work area ~ile work area--F8A,
or virtual storage work area--VSiA--for locate mcde procEssing of VSAM
data sets) if required. The input o{eration then begins. The
application prcgram vaits until that requested operation is completed.
Any I/O errors on completien, which cannot be recovered by the access
methcd or by file centrol, are thell returned to the application program
for action. See Figure 5-2.
Although an applicaticn program does not continue processing while
a requested I/O cperation is being carried out, CICS/VS utilizes the
available processing time during the I/O for other concurrently
executing tasks. Consequently, all tasks are given an equal opportunity
to process, based upon their respective task pricrities, vhile I/O is
in progress. The net result is im~reved overall performance of all
concurrently executing tasks in thE: system, eveD though the full
processing overlap pctential of the single task issuing the I/O
operation request is Dot utilized.
128
CICS/VS System/Applicaticn Design Guide
INPUT
OUTPUT
CICS/VS PROCESSING
Application Program
--
DFHFC TYPE=GET
DATASET=FILE1
RDIDADR-KEY1
I
1. Application Program Issues GET
Macro Instruction, Specifying
Data Set Name (FILE1) And Record
Identification (Contained In
KEY1).
-FCT
Dataset (Filel)
:>
Blocksize
Received Length
G
2. CICS/vS Locates Data Set Entry
In File Control Table.
3. CICSIVS Allocates File I/O Area
(FIOA) For DAM or ISAM Data Sets
Based On Block Size In FCT.
:>
4. CICSIVS Retrieves Relevant Record
From Data Set.
5. CICSIVS Allocates File Work Area
(FWA) Based On Record Length In
FCT, If Data Set Is Blocked And/Or
Segmented, Or Virtual Storage
Work Area (VSWA) If VSAM Locate
Mode Processing Is Specified.
File 1/0 Area
:>
FK[ III
>
6. CICSIVS Moves Logical Record
From FIOA To FWA, If Allocated.
However, If VSAM Locate Mode Is
Specified, CICSIVS Places Address
Of Logical Record (Within VSAM
Control Interval) Into VSWA.
7. CICSIVS Returns Record Address
To Program, Via TCA. Address Will
Be of FIOA For Unblocked, Unseg·
mented Read-Only Data Sets, Or
Of VSWA For Locate Mode ReadOnly Processing Of VSAM Data
Sets. In All Other Cases, Address
Will Be Of FWA.
Figure 5-2.
FIOA
VSAM Control
Interval
File Work
........Area
I
FWA
I
~
Storage
Work Area
I
VSWA
Task Con trol Area
TCA
~
:>
---Program
----
CICS/VS File Control Randcm Record Eetrieval
A file I/O arEa (FIOl) is dynamically allocated before the GET
operation commences. On com~letion of that I/O cpEration without error,
in the case cf blocked and/or segmented data sets a file work area
(FiA) is allocated of sufficient size to contain a logical record. The
requested logical record is then lecated in the tlock in the FIOA, and
transferred across to the FiA. For locate mode ~recessing of VSAM data
sets, a VSWA is allocated, and information identifying thE record in
the control interval is ~laced in the VSiA. This is discussed in more
detail in "Locate Mode Processing (VSAM Bead-Only)" later in this
chapter. The ap~lication Fregrav is then presented with the address
of the FiA or VSiA, or of thE FICA for an unblocked unsegmented
read-only data set. The aFplicatien program may then process the
logical record.
When the record has been ~rocessed and is no le[ger required, the
FIOA and FWA or VSil (if allccated) can be dynamically released by the
application program, and the storage utilized by these areas may be
returned to the CICS/VS dynamic storage area for use in satisfying
other sterage requests. Figure 5-2 illustrates the function of CICS/VS
file control random record retrieval.
A record can te directly accessed using a file control GET Dacro
instruction, as described abeve, for potential subsequent update. An
indicatien that this recerd may subseq~ently be updated is made by the
application program at the time that the GET macro instruction is
issued, ty indicating that the type cf operation is a GET for UPDATE.
Chapter 5.
CICS/VS Data Base Design
129
In this case, the record is retrieved as descrited above for the
GET macro instruction. After the apFlication program has updated the
logical records in the paA, it issues a POT macro instruction, supplying
to CICS/VS the address in storage of that FWA. CICS/VS file control
determin€s the fact that this is a POT of a record which was earlier
retrieved for update. The lcgical record then rEplaces the original
record OD disk (see Figure 5-3).
APPLICATION PROGRAM AND
CICS/VS PROCESS'ING
INPUT
OUTPUT
r-----File I/O Area
Program
---
--
r--r--
,.....--~
DFHFC TYPE=GET.
DATASET=FILE1
RDIDADR=KEY1
TYP OPER=UPDATE
---
~
Record Indicating Intention To Sub·
sequently Update It.
'--'--
\C
3. Application Program Processes
Retrieved Record.
r--r---
;;>
I
~
FWA
I
I
Task Control Area
TCA
(
4. If Record Is Not To Be Updated.
Program Issues DFHFC TYPE=RELEASE
Or Next DFHfC TYPE=GET MACRO
Instruction.
I
FIOA
' ( . ,;,. W.,k ..
2. CICS/VS Applies Exclusive Control To
Block For This Task. To Prevent Con·
Current Updating By Other Tasks.
c::J
DF"'tTY":""T
1. Application Program Retrieves
.
5. If Record Is To Be Updated. Program
Issues DFHFC TYPE:PUT To Write
Updated Rccord Back.
6. CICS/vS Releases Exclusive Control
To Permit Other Tasks To Update
Block. If Required.
-Program
--
B
-Figure 5-3.
CICS/VS File Control Bandom Record Update
If thE application Frcgra~ does net wish to UFdate the record which
was retrieved, it does not issue a PUT macro instruction. The
application program should issue a File Control BELEASE macro
instruct ic:m.
If the exclusive control feature was specified when the file control
manage.eDt routine was generated f~r the installation, file control
will ensure that no other concurrently executed task is able to. issue
a GET with UPDATE macro instruction for the same logical record for
ISAft data sets, physical reccrd for DAft data sets, or control interval
for VSAft data sets (referred to as the "physical record" below). This
is necessary in a multitasking environment to avoid two or more
concurrently executing tasks updating the same physical record on disk,
with the I?Ossibility of losing information resulting frem ene or more
concurrent updates. However, a GET request without update .ay be
concurrently issued with a GET reguest for updatE, for the same physical
record. Several tasks may read that record at the same time, tut only
one task is permitted to uFdate it.
If it is not necessary to updatE the record retrieved, exclusive
control on that Fhysical reccrd can te released ty issuing a file
130
CICS/VS System/Application Design Guide
control RELEASE macro instruction
any other waiting task which alse
record to commence its update, at
application program did not iSSUE
(see Figure 5-3). This will permit
wishes to updatE the sase physical
an earlier time than it could if the
a RELEASE .acrc instruct-ion.
Records may be added to a data set through the use of a File Control
PUT macro instruction indicating that the type of operation is a new
record addition. In this caSE, the application trogra~ sust first
request that a file work area lFiA) be allocated to enable the new
record to be constructed in .ain storage. ThE allocation of an FWA is
achieved by issuing a file ccntrcl GETAREA macro instruction specifying
the data set name to which the record will be sutse9uently added. The
data set name is used to locate the appropriate entry in the FCT and
so deter~ine the record length tc be used by CICS/VS in allocating the
FiA.
After constructing the new record in the allocated FIA, the
application program issues a PUT sacro instruction, specifying that
the type of operation is the addition of a new record. The record
identification supplied by the program is used to determine where the
new record will be added.
If the record identification trovided is a recerd key for addition
of new records tc IS1M or key-sequenced VSAM data sets, the record is
placed in sequence in the data set based upon that key. For DAft data
sets, the new record is inserted as clcse as possible to the specified
record location as described below.
For fixed-length unblocked DAft records, such data sets,.ust be
initially generated with a nu.ber of dummy records interspersed
throughout the data set. A dummy record is one containing hexadecimal
FF in the first byte of the record. The record to be added is inserted
in the first available du •• y record, location following the specified
record lccation. If no du.my records are availatle in the sase cylinder
(for DOS/VS), the application program is notified; it may then reissue
the PUT request for the new record to another part of the data set
until a dummy record is found. ihen the new record replaces the du •• y
record, file control returns the,record location where the new record
is stored to the application program (see Figure 5-4).
Chapter 5.
eICS/VS Data Base Design
131
APPLICATION PROGRAM AND
CICSNS PROCESSING
INPUT
1.
DFHFC TYPE=GETAREA,
DATASET=FI LEl
p,",,,m
"q"""~110"<;O=-
file I/O area and file work area.
OUTPUT
----l
File 1/0 Area
2. Program constructs output
record.
3. Program issues new record put
request specifying record
location in data set.
DFHFC TYPE=PUT,
TYP OPER=NEWREC,
RDIDADR=ADDRl
4. If unblocked data set, CICS/VS
scans cylinder from specified
location for first dummy record
(X'FF' in first byte).
5. When dummy record found, new
record replaces dummy.
6. If blocked data set, CICS/vS
writes new record to specified
location.
Data Set
7. CICS/VS returns address of new
record to program.
J
. L . . - - - -_ _
Figure 5-4.
CICS/VS Pile Control Addition to Fixed-Length
DAM Data.Set
For variable-length record DA! data sets, CICS/VS file control
attempts to add the new recoId at the end of the specified track, for
CICS/DOS/'S, providing theIe is sufficient space cn that track to
contain i,t. For CICS/OS/VS, a spec·ified number cf tracks may be
searched to locate a track on which to add the record. If there is
not sufficient s~ace, the ap~lication ~rogram is notified, and may
Ieissue the POT request for the new record, indicating another track
to be used. When the new record has been successfully written at the
end of the specified track, its record location is returned to the
application program (see Pigure 5-5).
Por entry-sequenced VSA! data sets, new records are always added to
the end of the data set regardless of whether they are fixed or
variable-length. The relati~e byte address of the added record in the
data set is returned to the application program.
lt~.ngS!m Ii~=.Q!:g ]~l~!iS!Jl
(l~j~
Qnl.t)
The file control DBLETE macro instruction is used to specify the
deleticn ()f records in a VSA! key-seguenced data set. The specified
recoId is physically deleted. The space occupied by that record is
reclaimed and added to the available free space in the particular
control interval which contained that deleted record.
132
CICS/VS SysteR/Application Design Guide
.
OUTPUT
PROCESSING
INPUT
File
·~D·-AF~TA;:SOE:T:;FEI~L-GE-El::~~-~J-11'--'I"---l-.---.---' ---l.-P
Selection
Transaction
I
1. Operator Enters Transaction To Initiate
User Program Which Will Issue Weighted
Retrieval Macro Instructions.
2. User Program Issues Macro Instructions
To Identify Selection Criteria To CICS/vS.
;.
K
USER PROGRAM
DFHBIF
DFHBIF
DFHBIF
DFHBIF
----
CI CS/VS Weighted Retrieval
""""'U "'j
;>
VSAM
Data Set
I
I
-u
ReCOr(~
Weighted
Counter
I
[Total
Counter
~
""",",~d (
VSAM
Data Set
---11.
3. CICS/vS Initiates Weighted Retrieval On Key·
Sequenced VSAM Data Set Using Specified
Selection Criteria.
4. If Record Field Matches Criteria, CICS/vS
Adds Match Value To Weighted Counter,
And To Total Counter.
V
Weighted
Counter
5. If Record F,eld Does Not Match Criteria,
CICS/vS Subtracts Non-Match Value From
Weighted Counter.
~
Percent
Weighted
Total
= - - ..-
CICS/vS Dynamic
Storage
<
9. CICS/vS Drops All Record ID's After UserSpecified Maximum Number.
10. CICS/VS Retrieves Remaining Records From
Data Set And Presents Each One To User
Program, Together With Percentage.
UI
Total
Counter
V
7. If Percent Falls Between User-Specified
Limits, CICS/VS Saves Record Ident. And Per·
cent In CICS/vS Dynamic Storage.
8. After All Records Are Examined, CICS/vS
Retrieves Selected Record ID's And Percents From Dynamic Storage And Sorts
Into Descending Sequence Based On Percent.
II
f}
6. After All Criteria Are Applied To Record
Fields, CICS/vS Calculates Percent Of
Weighted Counter Divided By Total
Counter.
I
WTRETST
WTRTPARM
WTRETGET
WTRETCHK
Ij
PROGRAM
--DFHBIF WTRETGET
-=>
J
Figure 5-,7. eles/vs ie1ghted Retr1eval
Associated with each selection criterion are both a match value and
a nonmatch value. In additicn, counters are maintained for each
selection criterion to accumUlate statistics relating to the degree of
matching achieved. In thE event cf an exact match, or a match within
specified limits, a match value associated with that criterion is added
to a weighted counter and to a current total counter. In the event of
a match not being achieved, a nonmatch value is suttracted from the
weighted counter, tut not frcm the current total counter. The match
and nonmatch values may be either positive or negative, but they must
have the same si~n.
If a particular criterion is matched, the weighted counter is
increased appropriately. However, if another criterion is not matched,
the weighted counter may be decreased. After all selecticn criteria
have been applied to the necessary fields in the record, ~ percentage
of acceptability is calculated by dividing the value of the total
counter into that of the weighted counter. If this percentage falls
within defined limits for the weighted retrieval operation, the full
key identification of that record and the percentage are saved in
CICS/VS dynamic storage by the built-in weighted retrieval function.
After all required record~ are examined, the keys and percentages
are read back from dynamic storage and sorted into sequence based upon
the percentage of cORpliance cf each record with the selection criteria.
138
CICS/VS system/Application Design Guide
If the number of keys satisfying the selecticD criteria exceeds a
maximum, say H, specified by the apFlication program, then all keys
having a percentage equal to or lower than that cf the H+1th key are
dropped. Follcwing this, the re.aining records are retrieved and made
available to the application program one at a time in order of
decreasing acceptability, together with each reccra's percentage. Refer
to the ~l~~L!~ A]£li~i!i~! ~rogrsii§~!§ ~~~~!~~ A!DYil for more
detailed information about the use of weighted retrieval.
A~E1i£g!lQn ~§~§
19.
j~igh!~g ~~!~i~lgl
IYn£ ti 2!
The weighted retrieval functicn uses the browsing capability of
CICS/VS file control and is applicable only to key-sequenced VSAM data
sets. Use of this weighted retrieval capability opens significant
online application opportunities in a number of industries. For'
example, in a manufacturing industry, weighted retrieval may be used
to search a key-sequenced VSAM werk erder data set to identify specified
part numbers, quantities,. revenUE, and completior; ~eriods for all work
orders. Alternatively, a VSAM manufacturing planning data base can be
searched to identify all wcrk orders planned to he manufactured by
specified equipment cr with farticular materials or parts.
In the banking industry, the weighted retrieval function can be a
powerful tool. It enables all customer records cf various branches of
the bank to be examined. These with a current balance ahove or below
a specified amount for certain types of accounts, can be selected.
Alternatively, Weighted retrieval can be used to provide an exception
report of all checking acccunts with an overdraft greater than a
specified amount.
Weighted retrieval can be used in the insurance industry to search
key-sequenced VSAM policy data bases. It can identify those pclicies
with claims exceeding a certain value for specified types of policies
in particular geographic locations or owned by a Farticular class of
policyholder.
In the medical industry, a patient information system can use the
weighted retrieval function to identify all fatients receiving
particular medication in sFecified quantities over ~ particular period
of time. Alternatively, all patients with a particular coabination of
symptoms may be selected.
Weighted retrieval can also be used in law enforcement agencies to
5earch a key-sequenced VSAM criminal data base te select all criminals
with specified personal characteristics and !2SY§ ~~~Si that co.pare
with characteristics and ~od]§ Q!~~!g! of particiFants in a sFecific
crime. Alternatively, a key-sequenced VSAM crimes data base ~an be
searched, selecting those crimes with the same .fSY! 2R~~~!' and
using this .~~ QR~~~~gi to select those criminals known to use that
iody§ 9~§~ADgj from a criminal data base. The recerds of these
identified criminals can be further searched to select criminals who
satisfy ether criteria identified ty the nature of a particular crime.
using weighted retrieval in this aFplication beccmes a powerful tool
for crime analysis and the identification of criminals or susFects
associated with these cri.es.
As shown by previous examfles, the application potentials offered
by the use of the built-in weighted retrieval furction can be
significant. In fact, utili2ing weighted retrieval maybe an important
consideration in determining the data base support to be used for the
particular infor.atien tc be retrieved.
The weighted retrieval fUlcticn can only be used with key-sequenced
VSAM data sets. As will be seen later in thE discussion of the Dl/I
Chapter S.
CICS/VS Data Base Design
139
products 4, DL/I DOS/VS usesVSAM. IMS/VS DL/1 may use either VSAM or
BISAM and BDAM. A DL/I VSAM data base utilizing root segments only
can be accessed as a standard VSAM data set and operated upon by the
weighted retrieval function.
For effective online perfcrmance, VSAM data sets (and, hence,
weightEd retrieval) should net bE used with systems having less than
144K of real storage. This is discussed further in "Data Base Selection
criteria" at the end of this chapter.
EECOED I£ENTIF1CATION
As di~:cussed above, data sets supported by CICS/VS file control can
be accessed either directly cr sequentially. Records are accessed
based upon the record identification supplied by the application
program. The record identification utilized depends upon the particular
data set being accessed. There are twc types of record identifications:
• ReCOl:d key
• Eecord location
Record identification based uFcn a key is used to access ISAM data
sets and key-sequenced VSAM data sets. The key may be either a full
key for retrieval of a particular logical record, or a partial (generic)
key, to indicate a logical peint in a data set from which a browse
operation is to cemmence. This generic key contains' sufficient
information in the high-erder bytes of the key tc uniquely identify
the logical section of the data set. The remaining low-order bytes of
the key may be either binary zercs or blanks. Fer key-sequenced VSAM,
a truncated generic key aay te utili2ed, with the first byte of the
key specifying (in binary) the number of significant bytes in the
generic key which follows.
For instance, the orders data set discussed above for btowsing can
utilize a key containing a branch number in the high-order bytes of
the key, and specific product numbers in the low-erder bytes of the
key. F01: example, crders for prcduct number 1016 frem branch number
12 may be contained in a record which utilizes the key of 121016. The
generic Itey to enable the fiIst Frcduct record tc te accessed for branch
number 12 would then be the generic key 120000 for ISAM, or 212 for
VSAM. The "2" indicates (in binary) that a generic key of length two
bytes follows, fer branch Dumber 12 in this example.
When a full record key is used to access an ISAM data set, it must
lecate a record on that data set with the identical key; etherwise, an
errOI indication is xetuIDed to the application program.
However, when a full record key is used to access a key-sequenced
VSAM dat~l set, any search fOI relevant VSAM records must be specified
as:
• Full ~~~ jgy~l - indicates that the key provided by the application
program is a full key, and failute to locate a record with this
exact key will result in an error indication being returned to the
application FrcgIam.
• tyll ~§l §!§i!§~ ~~ jgYAl - specifies that the record key is a full
key, and that the first data record with a key equal to or greater
than the supplied record key is to be retrieved. ~his is equivalent
to using a gen~ric key in 151M.
140
C1CS/VS SysteR/Application Design Guide
!gys! - indicates that the record key is a generic key
with a specified generic length. A record whose key is equal to
the supplied generic key for the number of bytes indicated is then
retrieved. If rine cannot be fcund, a "no record found" condition
is returned to the program.
•
~~~ri£ ~~l
•
~~~!i£ !~l ~~§g!~I ~I
!SYS! - indicates that a generic key is
Frovided, and the first data reccrd with a key equal to or greater
than this generic key for the number of bytes indicated is to be
retrieved.
An additional advantage in the utilization of record keys is in the
addition of records. When new records are added to the data set, they
are inserted in sequence in the data set based upcn their record key
value.
To facilitate retrieval from tA~ or VSAM data sets, records are
identified by their lccatiens in the data set. VSAM record
identification is based on relative tyte address (RBA) within the data
set. In the case of DAM, the physical block (record) identification
can te on the basis of:
• Actual disk address (MEBCCHHB)
• Relative track and recerd within the data set
• Relative block number (fer CICS/CS/VSonly)
If a physical key is recorded for the physical record, it may be
appended to each of the record identifications detailed above. Figure
5-8 shows some representative record identification field formats.
DAM data sets with or wit bout physical keys can be accessed. If a
physical key is reccrded cn disk preceding the data record, the record
identification can indicate the relative track within the data set,
and the key which is physically recorded with the data record to be
retrieved.
Both blocked and unblecked DAM data sets are supported by CICS/VS
file control. In the case of blocked DAM data sets, additional
information may be provided to identify the logical record within the
physical block. This logical record identificaticn immediately follows
the physical block identification (as detailed atove) in the record
identification field provided by the application program. Logical
records may be selected freB a physical block based upon:
• Record number within block
• Record key within block (as illustrated in Figure 5-8)
where the location of the record key within each logical record is
defined in the file centrel table.
CICS/VS file control uses this logical record number or key to
deblock the relevant logical record from the physical blcck and present
it to the applicaticn prcgraa.
For VSAM data sets, the record location utilized is a relative byte
address (RBA). VSAM data sets use this relative tyte address to
identify the location within the entire data set of information (such
as a logical record) to be retrieved.
Chapter 5.
ClCS/VS Data Base Design
141
..
PHYSICAL RECORD
(BLOCK) LOCATION
-<
PHYSICAL KEY
(IF PRESENT)
DEBLOCKING
ARGUMENT
(IF BLOCKED)
Relative Blocl< No.
-
Record No.
Relative Block No.
Key
Record Key
TTR
-
Record No.
TTR
-
Record Key
TTR
Key
Record Key
TTTTTTRR
-
Record No.
TTTTTTRR
-
Record Key
TTTTTTRR
Key
Record Key
MBBCCHHR
-
Record No.
MBBCCHHR
-
Record Key
_----.
--,
COMMENTS
I
--
CICS/OS/VS Only
--------- ---.----
Block
Referenc:e
Figure 5-8.
Physical Key
(if present)
Deblocking
Argument
Relative Track and
Record (binary)
Relative Track and
Record (zoned decimal)
Actual Disk Address
I
Format of Record
Identification Field
in Program
DA! Data set Eecord location
Initially, this appears tc restrict the size of the data set.
However, the relatiVE address is maintained in afullword, enabling a
data set to be maintained, ccntaining 2 raised to the power of 32 bytes.
This is equivalent to a data set of approximately 43 billion bytes,
extending over aore than forty-three 3330 disk drives.
Records which are written to an entry-sequenced VSA! data set are
never moved until the data SEt is reorganized. Any additions to the
data set are made at the end of the data set, and the relative byte
address by which that added record may be subsequently retrieved is
returned to the applicaticn FrograD.
Using the relative byte address for record identification of a VSAM
data set provides the following advantagES:
• Operates equally well with fixed-length or variable-length records
• Provides rapid file access, with full rotational position sensing
suppcrt even when variable-length records arE utilized
The record identification provided by an application program to
access a VSAM data set by EBA is a four-byte relative byte address.
142
CICS/VS system/Application Design Guide
This may be calculated using techniques similar to that used to
calculate a relative reccrd rumber or relative bleck number for DAM
data sets, or the relative byte address may be stored as a pointer in
logically related records.
RBQDetic ~2n~~§i2D lYD~!i~D
Phonetic conversion is an cpticnal CICS/VS built-in function that
can be utilized to develep record keys based upon ~ossible misunderstood
or misspelled informaticn. The application program presents a 16-byte
field to CICS/VS by issuing a built-in function (ElF) phonetic
conversicn macro instructien. The phenetic ccnversion routine returns
a four-byte phonetic equivalent cf the supplied field.
This returned
value consists of the first letter of the field, and three EECDIC
numbers which represent the letters in the rest cf the field.
INPUT
CICS/vS PROCESSING
II
ISIMIYITIHI E
Value
3
4
5
6
CICSIVS Moves First Letter Of Name To
First Character Position Of Code.
>
2.
Next Letter Of Name Is Selected.
>L
3.
If Not A Bypass Character, CICSIVS
Translates It To Number.
I
I
1
2
1.
:>
OUTPUT
~
lj
Is I
I
I
I
Letter
B,P,F,V
C,G,J,K,O,S,X,Z
D,T
L
M,N
R
4.
;>lr 5.
II
6.
ISIM'DTljU
~
IS ,5 ,
I
D
Translated Number Is Inserted In
Next Position Of Phonetic Code.
Repeat 2 And 3 Above Until Three
Translated Numbers Have Been
Inserted In Phonetic Code.
I
A
btl
lj
Is ,5 ,3 10 I
If Fewer Than Three Letters Used,
CICSIVS Pads To Right With EBCDIC
Zeros.
Extended Description
0
0
[J
Figure 5-9.
-
Double Letters Are Treated As Single Letters.
-
Two Or More Contiguous Letters With Same Value Are Considered As A Single Value.
Bypass Characters Are: A, E, H, 1,0, Y, W, U, Blanks, And Nonalphabetic Characters.
-
If More Than Three Numbers Can Be Computed From The Name, Only The First Three
Are Used.
CICS/VS phonetic Ccnversion
The key produced is based upon the phonetic sound of the name.
Names
which sound similar, but are spelled differently, will generally produce
the same phonetic value (see Figure 5-9). For example, the names SMITH,
SMYTH, SMYTHE, and S~ITHS produce a phonetic key of S530. Likewise,
the names ANDERseN, ANDBESBN, and ANtRESENN produce a phonetic key of
A336. This phonetic key is used as a partial key. which can then be
Chapter 5.
CICS/VS Data Ease Design
143
used to access a name data base. ~honetically similar names will
produce the same value, redncing errors caused by Fronunciation or
misunderstanding in spoken conversation. !isspel1ed names can be used
in retrieving required data~
The built-in phonetic ccnversion function is based upon the phonetic
conversic)n capability provided in the IB! Frograa ~roduct FASTER (Filing
And Selecti~n Technique for Easy Retrieval: 5734-G21 (OS),
5736-G24 (DOS)). It is particularly useful in industries which require
data sets to be accessed based uFon names cr product descriptions. It
is also useful in a Folice infor.aticn system, to identify all criminals
and suspects with phonetically similar names. Phonetic conversion,
together with the built-in weighted retrieval function, enables records
to be retrieved based uFon names, and records with phonetically sim~lar
names to be further identified based uFon selection criteria through
the use ()f the weighted retrieval function (see above).
For example, all cri.inals named Smith with SFEcific personal
characteristics can be. identified. Criminals with a particular name
and other identifying information, such as birth date and address, may
be used to select the aFFrcpriate records.
A phonetic conversion subroutine is also Frovided by CICS/VS for
use by batch programs which Frocess online CICS/1S data sets in a batch
Environment.
INDIBECT ACCESS
CICS/VS file control enables data bases to be ccnstructed. Th~s is
achieved by the use cf the indirect access feature of file centrol,
enabling various data sets tc be ccnstructed to identify logically
related records in other data sets. The indirect access feature
utilizes pointers frca a reccrd in the data set to logically related
records in other data sets. The pointers can contain the actual disk
address ()f a.logically related reccrd, the relative location of that
record in its data set, cr the kEY of that record. This enables
identification and retrieval of inforaatien logically related to the
record bEing processed.
!n~!~~! A~§§§ J~~li~a!i21 1~§.~1!§
Figure 5-10 illustrates a Froduct record in a Froduct data $et and
the supplier of that product through a supplier Iumber. This supplier
number is used as a pointer to access a separate supplier data set to
obtain further information atout the supplier of the product in
question .. The supplier numbEr in the Froduct record becomes a-pointer
to the supplier data set and can teindirectly accessed frem the product
data setH
144
CICS/VS system/Application Design Guide
Supplier Record
Product
No.
Supplier
No.
13425
8018
Figure 5-10.
Product Data set Indirect Access
Another example of indirect access is in an insurance policy
information system. In this case, a policy record in a policy data
set contains infer.ation relating te the policyhclder (for example,
customer number or name). If the customer data set is organized in
customer name sequence as an ISA! data set, the name may be used as a
key to retrieve the customer recerd relating to that particular policy.
In this way, the customer naDe in the policy record is used as a pointer
for indirect access to further custo.er details in the customer data
set (see Figure 5-11). .
Policy Record
Policy
No.
Policyholder
Policyholder
8133462
Smith, John A.
Smith, John A.
Figure 5-11.
Policy Data set Indirect Access
An indirectly accessed data set may also contain pointers to other
logically related records in ether data sets. The customer record,
indirectly accessed froa the policy record, may in turn have a field
which identifies tbat custe.erls insurance agent. The identification
of this agent (agent number) Day be used to access the related agent
record in an agent data set (see Figure 5-12).
Chapter 5.
CICS/VS Data Base Design
145
Polilcy Record
Agent Record
Policy
No.
Pol icyholder
Policyholder
8133462
Smith, John A.
Smith, John A.
Figure 5-'12.
Agent
No.
68
Indirect Access to Insurance Agent Data set
lDdi~~! !~~!§§ lJRli~i~!§!is~
The CICS/VS file centrol indirect access feature enables fields in
a record to be utilized as peinters to legically related records in
other data sets. There is nc limit to the number of indirect accesses
to other data sets which may be made throu9h the use of these pOinters.
Data sets may te indirectly accessed, re9ardless of whether they are
fixed-length or variable-Ien9th ISAM data sets, DAM data sets, or VSAM
data setsi. Depending upcn the tJpe ef data set, the pointer will be
either a record location (in the case of DAM or VSAM data sets), or a
record key (in the case of ISAM or key-sequenced VSAM data sets) •
The data set which contains a Fcinter field tc a logically related
record in another data set is referred to as the index data set. The
logically related data set is referred to as the ebject data set. An
index data set Day utilize several fields in a record to point to
logically related records in several otject data sets. These indirectly
accessed object data sets DaJ in turn utilize a field in their records
to point to logically related records in ether data sets. These
original object data sets become index data sets fer the next level of
indirectly accessed data set.
lDdi~!£!
A££!§§
IDi!iA!i~B
Indirect access enables a chain te be constructed throu9h logically
related records in many different data sets. Fi9ure 5-13 illustrates
a parts data set, which may be organized in Fart name sequence as an
ISAM data set. This data set is accessed by means of a part name. The
part name record is utilized as an index to a part number record in
the parts data set. This part numter record may in turn contain a
supplier number utilized as a pointer to the supplier data set. In
turn, the. supplier record may contain a disk address pointer to an
associated accounts payable record for that supplier in a DAM accounts
payable data set.
146
CICS/VS System/Application Design Guide
TTR
Disk
Address
Figure 5-13.
Indirect Access Chain. in a Parts Data Base
To initiate an indirect access retrieval, the application program
issues a file centrol GET .acro instruction indicating the name of the
data set to be utilized as an index data set, and the name of the data
set from which a logically related record is to te retrieved. In the
example illustrated in Pigure 5-13, the application program may provide
a part name key, indicate the part name data set as the index data set,
and specify that a record is to te retrieved froD the supplier data
set, to obtain further infcr.aticn atout the supplier of that part
name. This is shown in Figure 5-14.
Application Program
DFHFC TYPE=GET
INDEX=PARTNAME,
DATASET=SUPPLlER,
RDIDADR=RECDKEY
Process Supplier
Record
Supplier
No.
Supplier
Record
82
Pigure 5-14.
Indirect Access Operation
CICS/VS file control autoaatically retrieves the part name record
for the Fart name key Frcvided bJ the program, extracts the part number,
and uses it as a key to retrieve the part number record fro. the parts
Chapter 5.
CICS/1S Data Base Design
147
data set. Also, the sUPFlier number is extracted from that parts record
and is used as a key by file centrel to retrieve the related supplier
record from the sUFplier data set. ~his supplier record is the record
requested by the applicaticn program and is returned to it for
processing.
In one GET request, CICS/VS file control follows the necessary
indirect access chain, accessing as many data sets as required, to
retrieve the reccrd requested and ~resent it to the application program.
However, the application program is not aware of the number of data
sets indirectly accessed. It appears to the program as if the supplier
data set in the above examFle is in fact organized in part name
sequence, rather than in supplier Dumber sequence.
By following an indirect access chain in this way, file control must
be aware of the logical relationship between data sets. This is
achiEved at system generation when the file control table (FCT) is
generated.
As characteristics of each data set are specified in the FCT entry
for that data set during FeT generation, an indirect access relationship
tetween that data set and ancther data set may be specified.
Information required to define an indirect access relationship is:
• location of the field in the record to be used as a pointer to the
indirectly accessed data set
• Length of that field or peinter
• Name of the object data set
FILE CONTROL TABLE (FCT)
DATASET=PARTNAME
DATA SET SPECIFICATIONS
OBJECT D/S=PARTNO
KEY LOC=40'
DATASET=PARTNO
DATA SET SPECIFICATIONS
OBJECT D/~=SUPPLIER
KEY LOC=32
DATASET=SUPPLIER
DATA SET SPECIFICATIONS
KEY LNG=:5
KEY LGN==3
1-----.------+-------.---OBJECT D/S=ACCTPAY
KEY LOC=25·
DATA_SE_T_=_A_(_:C_T~PA~Y~__L-~D~A~T~A~S~E~T~S~P~E~C~IF~IC=A~T~I~O~N.=S~__________________________
Figure 5-15.
148
Specification cf Indirect Access Logical Relationships
CICS/VS System/Application Design Guide
All fields in the record which are to be utilized as peinters to
indirectly accessed data sets are identified, together with the data
sets to which they refer, as shown in Figure 5-15. This information
defines the data set in question as an index data set and identifies
the indirectly accessed data set as an object data set. These data
sets, when they are subsequently defined in the FCT, are also identified
as index data sets which refer to other object data sets. This is done
by defining the record fields which are to-be used as pointers in those
data sets, and the names cf the object data sets tc which they refer.
A chain of logically related data sets is defined in the FCT during
system generation. When an application program requests indirect access
retrieval, file control identifies a chain on which the object data is
located. It tben retrieles each related record in the data sets on
the identified chain in the sequence specified by the FCT, until the
related record in the cbject data set is retrieved. It is then
presented to the application program fer processing.
Indirect access retrieval enatles data bases to be constructed
utilizing logically related information in a numter of data sets. One
file control GET macro instruction causes all the required indirect
accesses to he carried out until the requested record is retrieved for
presentation to the task. This indirect accessing is carried out
asynchronously, enabling ether ccncurrently executing tasks to continue
processing.
Indirect access retrieval may be carried out with the intention of
subsequently updating the object data set record, if required. This
is indicated by the application prcgram specifying that this indirect
access retrieval is also part of an update operation. When the object
record is retrieved, exclusile centrcl is placed on that logical record
for I5AM data sets, physical record for DAM data sets, or control
interval for VSAM data sets. The application program issues either a
POT macro instruction to write the updated record hack, or a RELEASE
macro instruction to indicate that the record is net to te updated,
but that exclusive control is to te released.
In following a direct access chain through several data sets, the
pointer fie1d,in an index data set recerd can identify a number of
separate records in its relevant object data set. As shown in Figure
5-12, a policy record identifies the pelicyholder hy name. The customer
data set in this case may te organized in custemer name sequence, with
the name used as a key to access relevant records. However, there may
be several customers with the same name, such as Jones. To develop a
unique key for each policyholder with the name of Jones, additional
infor.ation covering first and second names, birth date, or address
must be added to the key. However, ,adding extra information to the
record key reduces the a.ount of disk storage available for an 15AM
data set, and wastes disk storage when additional identifying
information is not used.
To overcome this problem, CICS/VS file control provides an additional
capability with the indirect access feature, to enable duplicate records
to be identified. This is achieled by utilizing the first byte of a
pointer field in an index data set record. This first byte contains
a unique code which cannct otherwise occur as part of the key. In the
case of customer Jones, the first byte of the custcmer name field in
the policy record can contain a unique code, for example, hexadecimal
FF, as shown in Figure 5-16. This is immediately followed by the
Chapter 5.
CIC5/VS Data Base Design
149
customer name (Jones in this case). The hexadecimal code FP identifies
this as a pointer to several reccrds with thE samE key. The key is
utilized to access a separate dUFlicates data set, rather than the
normal otject data set. In this example, the key Jones is used to
access a "duplicate customer" data set that contains one record with
the name key of Jones. ~his duplicate record may in turn contain
information enabling further identification of customers with the name
Jones.
Figure 5-16.
Duplicates Data set for Indirect Access
The definition cf a duplicates data set associated with a particular
index data set is specified in the FeT as part of the index data set
PCT entry. This indirect access peT entry identifies the location and
length of the pointer field in the index record and the name of the
object data set. In additioD, the user-specified duplicates code in
the first byte of the pointer is defined, together with the name of
the duplicates data set.
Even though an indirect access chair is followed through several
data sets, the first byte of the pointer field tc teused in a record
is examined by file centrcl to determine whether it is a duplicates
code defined for that index data set. If it is, the duplicates data
set is accessed using that pcinter, instead of the defined object data
set for that index record. The itdirect access chain is broken at that
point, and the duplicates record is returned to a user-supplied
duplicates routine in the application program for further processing,
150
CICS/VS System/Application Design Guide
instead of returning the requested object data set record. The function
of the user-supplied duplicates routine is to exasine the information
presented in that du~licat~s reccrd, and uniquely identify the pointer
to be used to retrieve the next record in the indirect access chain.
This identification can be made either by the apFlication program
itself, cr by a reeguest fer further informaticn froD the terminal
operator if necessary (see Figure 5-16).
The duplicates data set feature bEcomes a powerful capability,
enabling unigue record identificaticn Froblems to te resolved so that
an indirect access chain can be maintained through the various logically
related data sets.
Records can be retrieved using the indirect access data set, either
for processing only (GET), ox for subsequent update (GET with UPDATE).
The updated object record can be written back with a PUT macro
instruction, or ignored by issuing a BELEASE macro instruction.
However, when adding ne~ records to data sets ~hich are indirectly
accessed, care must be exe.rcised tc ensure that the inditect access
chains are correctly maintained.
Records can be added to data sets which are part of an indirect
chain, using the procedures described in the topic "Direct Access."
When constructing new records, the indirect access pointer fields must
be correctly positioned, and must contain the correct information for
record identificaticn to access the cbject data set referenced by that
particular index pointer.
The order in which ne~ records are added to indirect data sets is
significant, depending uFcn ~hether a record key or a record location
pointer is utilized. If all the indirect access pcinters are record
key pointers (for example, tc be used for accessing ISAM or
key-sequenced VSAM data sets), the order in which additions should be
made to the indirect data sets is not Farticularly significant.
However, if some or all of the pcinters are record location fields for
use with DAM or VSAM data sets, the crder becomes significant, because
the actual locations of the addeo records are Dot known until the
addition is completed.
As discussed above, and illustrated in Figures 5-4 and 5-5, records
added to DAM data sets are written at a specified locaticn or near a
specified locati~n depending upon the type of data set involved. In
the case of DAM data sets with fixed-length records, an addition is
made utilizing the first available dummy reccrd after the location
specified by the applicaticn program where the addition shculd be made.
In the case of DAM variable-length data sets, the addition is made at
the end of the specified track, for CICS/DCS/VS, provided there is
sufficient room to insert that new record. For CICS/OS/VS, a specified
number of tracks can be searched tc locate a track which can centain
the record.
On adding a new record to a DAft data set, the actual record location
cccupied by the new record is returned to the apFlication program.
This record location can be used as a pointer to that new record from
an indirect access index reccrd. Ey inserting this record location
pointer in the appropriate field of the· record used to index the added
record, the indirect chain between these two data sets is maintained.
Similarly, if the index record containing this record location pointer
is a new record to be added, the lecation of that index record is
returned to the application Frogram and can be utilized as a pointer
to the higher level index record for that data set.
Chapter 5.
CICS/VS Data Ease Design
151
In this way, new records aay te addEd to a seriEs of data sets,
ccnstructing any indirectly accessEd chains in the process. This is
achieved by adding records tc thE lowest level data sets first, and
then pro~,ressing u~vard through higher level indEX data sets until the
highest level data SEt rEccrd is added. The reccrd location occupied
by each IIEW record is returned tc thE application ~rogram for use in
constructing the next higher level index record.
FigurE! 5-11 illustrates the addition of records to indirectly
accessed DAM data sets.
INPUT
PROCESSING
~l [0->
OUTPUT
Lowest Record
To Add
Lowest
Level
Data Set
Higher Reco,'d
To Add
~W
>
~
1. User Program Adds Record To Lowest Level
Data Set In Indirect Access Chain, First.
2. CICSfVS Returns Location Of Added Record
To Program.
~
I
r-~l
_
~
Locn
' " b-AM ~
Higher
Level
Data Set
4. Program Adds Record To Next Higher Level
Data Set In Indirect Access Chain.
I
Highest RecOI'd
To Add
Highest
Level
Data Set
Recor.d
Location
1l
3. Program Inserts Record Location Of Added
Record As Pointer In Record To Be Added
To Next Higher Data Set.
~.-'
~J
Lowest
Level
Data Set
I
5. CICSfVS Returns Record Location.
6. Program Inserts This In Record To Be
Added To Highest Level Data Set.
~
7. Program Adds Record To Highest Level
Data Set.
;>
Record
Location
}
Reed
Locn
;:Level
Data Set
New Rec
~,
I
~~ II
Highest
Level
Data Set
~.
~
-.---Figure 5-·17.
Additicn of Becords to Indirect Accessed Data Base
Additions to an entry-sequenced VSAM data set are made at t~e end
of the data set, as discussed under thE topic "DirEct Access." The
record lccation (BEA) of the addEd record is returned to the application
program. This BEA may be utilized as a pointer frcm an index record
to that new added record. Indirect access chains for entry-sequenced
VSAM datel sets may be built up (SEE Figure 5-11) in si.ilar fashion to
the methcd used for DAM data sets. Becords are added at the lowest
indirect access level first, and the BEA pointers returned to the
applicaticn Frogram are utilized as indirect aCCESS pointers in the
152
eIes/,S system/Application Design GuidE
nExt higher indirect aCCESS level. This progresses upward through
successively higher indirect accEss. levels until the highest indirect
access level record has teen added to its associatEd data set.
An indirect access chain can utilize any combination of DAft, lSI!,
entry-sequenced lSA!, or key-sequenced YSAft data sets. If an indirect
access chain utilizes any direct aCCESS data sets (DAB ox
entry-seguenced lSA!), additions must Froceed frem the lowest level
data set upward to the highest levEl data set. It is a good technique
to always add records at the lowest level and then at subsequently
higher levels regardless of vhether DAft, ISAft, or YSA! data sets are
used.
ln~i~~~! A~~!§§ ~AJiD ~!is.lil
Special consideration should be given to the possibility of systeR
failure during the addition of an indirect access chain. If a systeR
failure eccurs before all the logically related records are added to
their relevant data sets, an incomplEte direct access chain viII result.
Accordingly, techniques discussed in Chapter 8 should be utilized for
journaling any indirect access additions, to enatle incomplete indirect
access chains to be tackEd out on restart if neCEssary.
Normally, new indirect access chain records should be added offline
to the data sets. However, adding these indirect access record chains
online using the preceding tEchnique is required to redUCE the
vulnerability of those data sets te system failure, and it is advisable
to ensure that only one direct access chain be added at a time. This
may be achieved ty all applicaticn pxograms that generate nev indirect
access chains enqueuing cn the samE single user resource prior to
commencing an indirect access chain addition. On successful completion
of the entire indirect access chain addition, the application program
can dequeue itself fro. the single user resource. By utilizing CICS/YS
task control ENQ/DBQ macxo instructions, only one task at a tiae viiI i
be able to carry out an indirect access chain addition. ihile this
may have an effect cn online perferaance, depending upon the frequency
of adding nev chains, it viII result in a definite improvement in the
integrity and safety of the various data sets in the event of a system
failure.
SBG!ENTED EECOBDS
The CICS/VS file centxol segmented record featur~ enables data sets
to be constructed for efficient use on disk and dynamic storage space,
including those data sets cODtaining a consideratlE aRount of
variable-length information and which have various fields that are
either present or absent in specific records.
The segmented record feature considers a record to be cORprised of
a number of segRents - each segaeDt containing one or more related
fields. For example, in a customer data set (see Figure 5-18), the
customer name may te defined as one segment and each address line as
another segment. A numbEr of customEr account history fields containing
the balance outstanding (current, ene Bonth, tvo menths, three months,
and over three months) may comprise anether single segment.
ChaptEr S.
CICS/VS Data Base Design
15~
J
Postal Address
Customer
Number
6 bytes
6 bytes
Line 1
20 bytes
Line 2
20 bytes
20 bytes
Line 3
Line 4
Line 1
20 bytes
20 bytes
20 bytes
Ship-To-Address
J
(
Customer
Name
Credit
Limit
line 2
20 bytes
Line 3
20 bytes
Figure 5-18.
.(
Account History - Arrears
Line 4
20 bytes
Customer
History
60 bytes
Current
Balance
6 bytes
One
Month
6 bytes,
Two
Months
6 bytes
Three
Months
6 bytes
Over Three
Months
6 bytes
•
Record Format: Fixed-length
•
Record length: 282 Bytes
Typical Customer Becord Poraat
Another example of segmented records is shown in Figure 5-19, which
illustrates a savings acccunt data set used in the banking industry.
The account master informaticn may te defined as one segment. Each
deposit or withdrawal transaction made previously against the accb~nt
may also be defined as a segaent.
Account Master
In'formation
Account Account Current
Number Type
Balance
Figure 5-19.
~~gllel!!
Previous Transactions
)
Against This Account
Other
Passbook Passbook No Book
Passbook No Book Passbook Unused
pa~b(( Withdrawal
Account Withdrawal Deposit Deposit With
Withdrawal Deposit
Details
Typical savings Account Becord For.at
12!sign
Generally, fields are grouped within one segmEnt if they have some
similar relationship, such as si.ilar information which will be operated
upon togEther by various programs, or fields which are either all
present or all absent for a particular record, or single fields which
may contain variable-length information such as name or address lines.
A segment may contain any numter of fields up to a total segment
length of 255 bytes. Segaents may be further defined as either
154
eIeS/'S System/Application Design Guide
fixed-length segments, or variable-length segments whose length is
indicated by a one-byte tinaxy field at the start cf the segment.
Consider the storage of a customer name and address in the record
format shown in figure 5-18. How many bytes should be allocated for
the name field? Should each n~me field be allocated 20 bytes or 30
bytes or 15 bytes? Depending upcn the characteristics of various
customer names, a 30-byte name field could ccntain every possible name,
whereas a ~O-tyte name field may contain 951 of customer names, and a
15-byte name field only 80~ cf names. using the 30-byte name field
will avoid the necessity of abbreviating or reducing the. lengths of
names, as would te necessary using 20~byte or 15-tyte fields. However,
the great majority of namES &ay be less than 15 bytes. In this case,
15 bytes er more of disk s~acE in Each customer record is wasted if a
30-byte name field is allocatEd.
How many bytes should be allocated to each address line? Allocation
of 30 bytes for each address linE may enable every possible address
line te be stored in full, while 20-byte or 15-byte address lines may
require some form of abbreviation. Again, the use of 30-byte address
line fields may result in wasting approximatEly 15 bytes er more per
address line, becaUSE the .ajerity of address lines may fit within 15
bytes.
AnothEr consideration is the numbEr of address lines to allQcate
for a customer rEcerd. Many custcmer addresses have two or three
address lines, while somE may require six or morE address lines. Should
six address lines be allccated fer each customer record? Should instead
three address lines be allocated, reducing lenger addresses to three
lines, but wasting an address line field in the case of a two-line
address?
The segmented record feature enables record fermat definition
problems such as these to te easily resolved. The customer name and
each custemer address line may be defined as separate segments.
Furthermore, they may be defined as variable-length segments such that
for one additional lengtb byte at the start of each segment, the exact
length of that segment can be indicated. Thus, a five-character
customer name weuld eccupy five bytes plus one byte for the length
indication - a total of six bytes. However, a 25-byte customer name
would occupy a tetal of 25 plus cne er 26 bytes, while a 14-character
name would o~cupy a total cf 15 tytes. Only the amount of storage
required for each individual name nEEd be allocated, for more efficient
disk storage utilizaticn.
Figure 5-20 shows that each address line segment may te defined as
variable-length, with the actual lEngth of each address line occupying
only that many bytes, together with an additional byte per address line
as a length indication. Names and addresses need not be abbreviated,
but may cccupy as little or as much disk storage as required.
Chapter 5.
eICS/VS Data Ease Design
155
Variable
Format
Length
4 Bytes
4 bytes
- - . .
Varible
Length
Control
Root Segment
,____1.5..b,...y..te.s_ _ _-...
~_
Customer
Number
A
Credit
Limit
Customer
Name
Segment
12 bytes
Line 1
13 bytes
Line 2
9 bytes
,..-"-..,..-"-..,..-"-..,
Segment
*
Presence L
Indicators
Customer
*
Name
L
Account History
Segment
Postal Address Segments
Postal
Address
Line 1
*
L
Postal
Address
Line 2
Line 3
7 bytes
*
L
Postal
Addre,Ss
Line 3
LU'>Y>
* L = 1-Byte Length Field For
Variable-- Length Segments
** LLM
=
4-Byte Variable-Length
Record Control
Figure 5-20.
30 bytes
,
_ - -_ _
•
Record Format: Variable-Length
•
Length Of This
Customer Record: 90 Bytes
•
Original Record Length
If Not Segmented: 282 Bytes
~---".."_ _- " ,
Account History
Arrears (Months)
Cur.
Bal.
1
2
3
Over
3
Segnented custemer Record Format
A further advantage of variable-length segments is that segments
may be defined as being either present or absent on an individual record
basis. In Figure 5-18, eight address line segments are defined for
each customer record. However, if only three address lines are
required, only three address line segments need be present for that
record (see Figure 5-20). The remaining five possible address line
segments are not present. and do not occupy any disk space.
Fields which are always present in every record, such as a customer
number, credit rating, and other required information for each record,
are generally greuped together into one segment. This is called the
root segment and precedes all other segments in the record. This
segment is always present in a segmented record.
The presence er absence of other segments in the record is indicated
by segment indicator flags. These indicator flags are contained within
the root segment, and may comprise either bit indicators or halfword
indicator;s.
Bit indicators use a separate tit to indicate the presence or absence
of each specific segment. If the segment associatEd with a tit is
present, that bit is turned cn. HOWEver if the s~gment associated with
the tit is absent, that bit is turned off.
Halfword indicators utilize two bytes to indicate the presence or
absence of each segment. The twe tytes are used as a zer~/nonzero
switch. If the twe bytes arE nonzerc, the associated segment is
156
CICS/VS System/Application Design Guide
present; if the two bytes are binary zero, the associated segment is
absent.
COBOL programs must use halfwcrd indicators, unless the bit
manipulation built-in function supplied by CICS/VS is utilized (see
"Application Built-in Functions" in Chapter 2). Figure 5-21 illustrates
the use of segment indicator flags, and relates to the customer record
shown in Figure 5-20.
~!HJ1!!~.n! ]~fini ti.£!!
in
l~l'
While it is the responsibility of the system programmer to specify
segments in the PCT, it is important that the system designer have a
general understanding of how segments are defined, to better understand
the operation of the CICS/VS segmented record feature. this will enable
him to take advantage of facilities cffered by this feature when
initially designing the varicus data bases which will be utilized by
the application.
Either bit indicators or halfword indicators aay be used with a
particular segmented record data set, tut not both. The selected type
of indicators is specified in the file control table (FCT) entry for
that segmented record data set. As many bytes as required to contain
all of the necessary segment indicator flags (up tc a maximum of 99
segment flags) must be defined within the root segment. ~he starting
location, and length in bytes, of the segment indicator flags field in
the root segment is also defined in the FCT entry for a segmented record
data set. See Figure 5-21.
Each separate segment is then defined in the PCT entry (see Figure
5-22). Every segment is allccated a segment name up to 8 characters
long, and is specified as a fixed-length segment or a variable-length
segment of a defined maximum length. In addition, any required boundary
alignment (byte, halfword, fullword, or doutleword) necessary when the
segment is read into storage is identified. As each segment is
presented to the applicaticn program for processing, the segment is
aligned on the specified boundary. However, the extra bytes required
to ensure specific boundary alignment are not recorded on disk; they
are inserted w~en the record has been read from disk and before the
segment is passed to the application program.
An application program aay utilize several segments in a record for
processing. These segments aay te grouped together and called a segment
set. By identifying a segment set by name, all the segments comprising
that segment set are also identified.
Consider a customer data set in the utilities industry, as shown in
Figure 5-23. An applicaticn program which requires access only to the
customer name and address aay reguest a segment set comprised only of
the customer name seg_ent and each of the postal address line segments.
This may be uniquely identified as a· segment set which. is given a
specific name, such as ~AeEAtDR.
Chapter 5.
CICS/VS Data Base Design
157
Variable
Format
Length
4 Bytes
4 bytes
Root Segment
15-"'
bytes
• ___
....._ _ _ _.....
A
---~
Varible
Length
Control
LLr>r>
Customer
Number
Credit
Limit
12 bytes
Account History
Segment
Postal Address Segments
Customer
Name
Segment
...
Line 1
13 bytes
Line 2
9 bytes
,...-"-.
Line 3
7 bytes
.
"..-"-..
Customer
Segment
*
*
Presence L Name
L
Indicators
Postal
Address
Line 1
L
Postal
Address
Line 2
Postal
Address
Line 3
L
30 bytes
. ,.
Account History
Arrears (Months)
Cur.
Bal.
2
3
Over
3
•
Record Format: Variable-Length
•
Length Of This Customer
Record: 90 Bytes
• Original Record Length If
Not Segmented: 282 Bytes
* L = 1-Byte Length Field For
Variable-Length Segments
** LLr>r> = 4-Byte Variable-Length
Record Control
Flag
Number
Segment Indicator Flags
/
L.J 1 ,1 ,1 ,0, 0,0, 0 I0 I 0, 1 ,
I
1
1 2
3 4
5 6
7 8
I
I
I
I
I
I
,
,
I
9 10 11 12 13 14 15 16 1 7 18 19 20 21 22 23 24
• Segment Indicator Flags Indicate The Presence Or Absence Of Segments.
•
1 Bit or 2 Bytes May Be Used To Indicate The Presence Or Absence Of Each Segment. Here, Bit Indicators
Are Used.
•
Flag 1 Refers To The First Segment After The Root, That Is, Customer Name. Flag 2 Refers To Postal Address
Line 1, Flag 3 Is Postal Address Line 2, And So On, Up To Flag 11, Which Is Account History.
• A Bit ON Indicates The Relevant Segment Is Present; A Bit OFF Indicates The Segment Is Absent.
• The Exampli3 Here Shows That Customer Name, A 3-Line Postal Address, And Account History Are Present In
This Particular Customer Record.
•
Bits 12 Through 26, In This Example, Are Not Used. They Have Been Allocated To Enable Another 13 Segments To Be
Added To This Record Later, For Other Applications, Without Necessitating Any Modification To Existing Application
Programs.
Figure 5-21.
158
Segment Indicator Flags
CICS/V5 System/Application Design Guide
6 bytes
20 bytes
,
6 bytes
---..---'"
Customer
Number
Data Set
=
Credit
limit
Postal Address
Customer
Name
6 bytes
60 bytes
~
,~,
....
Account History - Arrears
Ship-To-Address
Li", 1Li", 'I Li",' 1Li", ,I Li", , Li", ,I Li",' 1Li",'
Customer
History
eo,,,,,,
Balance
Customer
10"
1TMonths
~ 1Th'~
10",
Month
Months Three
Months
•
Record Format: Fixed-Length
•
Record Length: 282 Bytes
File Control Table (FCT)
DATASET=CUSTOMER
OAT A SET SPECS
SEGMENT=ROOT
LENGTH=15
SEGMENT=NAME
VARIABLE
SEGMENT=ADDRl
"
BITINDICS
I
START=12
20 BYTES (MAX)
I
LNG=3
BYTE ALIGN
20
"
"
SEGMENT=ADDR2
"
20
"
"
SEGMENT=ADDR3
"
20
"
"
SEGMENT=ADDR4
"
20
"
"
SEGMENT=SHIPl
"
20
"
"
SEGMENT=SHIP2
"
20
"
"
SEGMENT=SHIP3
"
20
"
SEGMENT=SHIP4
VARIABLE
20
SEGMENT=HISTORY
FIXED
60 BYTES
WORD ALIGN
SEGMENT=ARREARS
FIXED
60 BYTES
WORD ALIGN
Figure 5-22.
Segment Definitions
For Dataset = Customer
(See Record Format Above)
"
BYTE ALIGN
"
Segment Definition in lCT
Chapter 5.
CXCS/VS Data Base Design
159
6 byes
t
20 bytes
6 bytIl S
Credit
limit
Customer
Name
"-
Account History - Arrears
Ship-To-Address
Postal Address
Customer
Number
.
6 bytes
60 bytes
,..--,
"
..--"-'-_r
Customer
History
u_~u_'IU_3IU_4Iu_' UO' ,I Uo, 31,,0,
4
Current
Balance
Dataset = Customer
00' IT~ I
Month
Months
Thm,
Months
I
0..,
~hree
onths
•
Record Format: Fixed-Length
•
Record Length: 282 Bytes
File Control Table (FCT)
DATA SET SPECS
DATASET=GUSTOMER
SEGMENT= ROOT
LENGTH=15
SEGMENT=NAME
VARIABLE
BITINDICS
I
START=121
20 BYTES (MAX)
LNG=3
BYTE ALIGN
SEGMENT=ADDRl
"
20
"
"
SEGMENT=ADDR2
"
20
"
"
SEGMENT=ADDR3
"
20
"
"
SEGMENT=ADDR4
"
20
"
"
"
"
SEGMENT=SHIPl
"
20
"
SEGMENT=SHIP2
"
20
"
SEGMENT=SHIP3
"
20
"
SEGMENT=SH I P4
VARIABLE
20
"
SEGMENT=HISTORY
FIXED
60 BYTES
WORD ALIGN
SEGMENT=ARREARS
FIXED
60 BYTES
WORD ALIGN
"
BYTE ALIGN
SEGSET=NAMEADDR (ROOT) NAME ADDRl ADDR2 ADDR3 ADDR4
SEGSET=ACCOUNT
Figure 5-23.
Segment Definitions
For Dataset = Customer
(ROOT) NAME ARREARS
Segment Set
} Definitions
Segment Set Definition in peT
Another application program may require access cnly to the customer
name and account history segaentE in Pigure 5-23. These segments may
be defined in a separate segment SEt which may bE given a unique name
160
eles/vS Syste./Application Design Guide
such as ACCOUNT. The application program in this way indicates that
it is sensitive only to segments in the specified seg_ent set.
~§gmsn! j§tri!~~l
When the application program wishes to retrieve a specified segment
set from a segmented reccrd, it Frcvides information for the
identification of that record, such as a record key or record location
field, identifies the data set tc te accessed by name, and then
identifies the segment set by name to te presented to the application
~rogram (see Figure 5-24).
INPUT
PROCESSING
OUTPUT
PROGRAM
1. Program Issues File Control
GET for Segmented Record.
---
DFHFC TYPE~GET,
DATASET=CUSTOMER,
RDIDADR=KEYFIELD,
SEGSET=ACCOUNT
V
I
l
-----
\
FILE CONTROL TABLE
DATASET=CUSTOMER
SEGSET=ACCOUNT
I) ~lliX
3. File I/O Area Allocated By
CICSIVS Based On Data Set
Blocksize.
0
File I/O Area (FIOA)
(
Data Set
(Customer)
2. CICSIVS Locates Entry In
FCT For Data Set.
«
4. CICSIVS Retrieves Record
From Data Set Into File I/O
Area.
nnl
j
5. CICSIVS Locates Segments In
Specified Segment Set In FIOA.
File I/O Area (FIOA)
I I I I I
Root Name
Arrs
UUI
I
6. File Work Area Allocated
By CICSIVS Based On Length
Of Segments In SEGSET.
IJ
I Root JName I Arrs
1ULJ)
7. CICSIVS Moves Specified Seg·
ments To File Work Area.
I
8. CICSIVS Frees FIOA Storage,
And Passes Address Of FWA
To Program.
Figure 5-24.
~
DFHFC TYPE=GET
SEGSET*ACCOUNT
V
Segment Eetrieval
File centrol uses the reccrd identification field to access the
required record from the s~ecifiEd data set. The segment set name is
then used to identify the particular segments aaking up that set. Each
Chapter 5.
CleSt'S Data Base Design
161
of the SEgment names in the segment set is defined in
being fixed-length or variable-length, of a specified
and requiring specified bcundary a1ignaent. Segments
be in the same sequence in the reccrd as the sequence
are defined in the FeT.
the PCT entry as
maximum length,
are assumed to
in which they
The segments in the segment set are extracted from the record by
file centrol. These segaents are presented to the application program
together with the root segment, as if only those SEgments were present
in the record on disk (see Figure 5-24). Other segments which are not
part of the segment set are ignored, and are not Fresented to the
applicaticn program.
The presence or absence of segments in the record passed to the
program is indicated by the status of the segment indicator flags (see
Figure 5-21). These seguent indicator flags are lecated within the
root segment, and each flag is tEsted by the application program to
determine whether it is cn QI off, and hence whether its associated
segment is present or absent. The first segment. indicator flag (which
may be a bit flag, for example) indicates the presence or absence of
the first segment in the record following the roet segment. The second
indicator flag specifies presence or absence of the second segment in
the record follo~ing the root segment, and so on. These indicator
flags specify the presence or absence of all segments within the record,
not only those segments in the segment set passed to the program.
The USl9 of DSECTs or structures in application programs can simplify
the testing and ~aniFulaticn of segment indicator flags. If the
appropriate DSECT or structure defining all indicators is copied into
the application program when it is co~piled, the use of
installation-controlled latels for each indicator may be achieved. The
applicaticn prcgrams may then be less sensitive to changes in segments,
a segment change being made to the DSECT or structure and the programs
then recclDpiled.
Applic~ltion programs aay replace segments, delete segments, or add
new segments. However, the extent to which new segments may be added
depends upon the particular access method used for the data set. If
DAM, ISAM~ or entry-sequenced VSA! data sets are used for the segmented
record da1:a set, the total segmented record length may DSi be increased,
but may te reduced if required.
(An exception is with OS/VS
variable-length 151M reccrds, where the segmented record length may be
increased if necessary.) iith key-sequenced 'SA8 data sets, the
segmented record length may be increased, either through the addition
of new segments to t~e record or by a change in the length of existing
segments. The increased recerd length is regarded by file control as
a replacement of the previous segmented record and is handled in much
the same way as the additicn of a new record to the data set. That
is, records which follow the lengthened record in the same control
interval are shifted to the right to enable the increased-length record
to be inserted.
If it is necessary to increaSE thE length of DAM, ISA8, or
entry-sequenced VSA8 seg_ented rEccrds, a different technique, segment
updating, must be utilized.
When it is determined that a segmEnted record in a D1B, 1516, or
entry-sequenced VSA! data set will be increased in length because of
the addition of a new segment, or the increase in length of an existing
162
CleS/VS system/Application
DE~ign
Guide
segment, the original segmented record retrieved must be updated by
the application program to indicate that that record is new obsolete.
This may be specified by the program placing a logical delete flag in
the root segment as shown in Figure 5-25.
Current
Record
Pointer
Segmented Record
Obsolete Segmented Record
Updated Segmented Record
(Length Increased)
Figure 5-25.
Segment Updating, ~ith Length Increase in DAM, lSI!, and
Entry-Sequenced VSA~ Data sets
The increased-length record may be written by the user program to
a separate user-defined "overflow" data set. The location of that
increased-length recerd in the overflow data set may be inserted as a
record pointer field in the root segment of the eriginal record (see
Figure 5-25). The logical delete flag in the root segment may be
utilized as the record pointer field. If this reccrd pointer field is
zero, it indicates that the segmented record is current. However, if
the record pointer field is nonzero, it indicates that the segmented
record has been logically deleted and replaced by ancther record in
the overflow data set. The record pcinter may be utilized by the user
program as a record key, or record location pointer (depending upon
the particular data set it peints to). It directs the application
program to the new current segment in the overflew data set.
with this technique, an increase in length of a segmented record
may te logically supported using DA~, ISA~, or entry-sequenced VSA~
data sets. The increased-length recerd is first written by the user
program to the overflow data set. The record location field returned
by CICS/VS as a result of that addition, or the record key for ISAM,
is then inserted into the record peinter field in the root segment of
the record in thE segmented data SEt (See Figure 5-25).
On subsequent retrieval, the application program first tests the
record pcinter field in the Ioot seguent. If the pointer field is
nonzero, the application program uses that pointer as a record
identification te the more current segmented record in the overflow
data set, and retrieves that current segmented reccrd for precessing.
The overflow data set must be specified during FCT generation as having
the same segments, and segment sets, as the original segmented data
set.
If a segment is to te updated ~ith no change in length, that update
is effected and the segments are presented by the program to CICS/VS
Chapter 5.
CICS/VS Data Base Design
163
to be written back to the data set by means of a PUT macro instruction.
If the length of a variable-length segment i~ to te reduced, the length
byte is modified to reflect the new length of the updated segment.
This segment is then written back to the data set ty issuing a file
control FUT macro instruction. File ccntrol blocks up each segment in
the segmented record, removes any boundary alignment bytes, and uses
the length byte in variable-length segments to allocate a sufficient
number of bytes to contain centents ef that segment.
To allow for a potential increa~e in length after a GET with UPDATE
macro instruction of variatle-Iength segments, or the addition of a
new segment which was missing in the segmented record, eIeS/VS file
control will present the application program with a segmented record
containing space set aside fer each segment, whether present or absent,
based upon either the fixed length of that segment, or the maximum
variable length of that segment.
~~gm~n! ~~1§!i9n
A segment may be deleted if the application prcgram turns off the
relevant segment indicater in the roet segment. File control then
physically deletes that segment when it writes the segmented record
back to disk.
Fixed- !ng
!~~i~~!§=~~~g!h a§g~~!!g ~§£2Ig§
eIeS/VS segmented reccrds Day be either fixed-length or
variable-length. For fixed-length records, the actual segmented record
may te less than the allocated fixed-length record size. Slack bytes
are therefore used at the end of the segmented reccrd to make up the
specified fixed-length recerd. Segmented records which are variable
in length because of variable-length" segments, or the absence of
particular segments, may be specified as variable-length records (see
Figure 5-26). In this case, variable-length records enable more
efficient disk storage utili2aticn4
Fixed-Length Record
~m.ntedReCOrd
~
Segmented Fixed-Length Record
Variable- Length Record
Segmented Record
Segmented Variable-Length Record
Figure 5-26.
164
Segmented Becord Disk Utilization
eIeS/VS System/Application Design Guide
Cr§A!iQD
~ng ~gi~!§Dgn£~
91
~g!~n!~g
i§£Q!g§
CICS/VS file control provides no facilities fer the creation or
maintenance of segmented reccrds. These records must be created
offline, with the various segments (either fixed- or variable-length)
blecked by user pregrams. The offline user program must set the
relevant indicator flags, to specify the presence cr absence of each
segment in that segmented record. Once segmented records have been
created offline, they may te retrieved online using the CICS/VS
segmented record feature. In the event of addition of new segments or
deletion of existing segments online, the online application program
is responsible fer determining that the appropriate bit or byte
indicator flag is en or eff, and turning on the appropriate indicator
for a segment which has teen addEd online, or turning off the indicator
for a se9ment which is to be deleted online. CICS/iS will examine
these indicator flags When the rEcord is to be written back to disk,
and take the appropriate acticn to either delete the segment or increase
the segmented record length if nEcessary to allow for an added segment.
with the availability of the built-in bit manipulation function (see
Chapter 2), Assembler, PL/I, and American National Standard (ANS) COBOL
application programs may test bit indicator flags and set bit indicator
flags on or off. Conseguently, the use of halfword indicator flags
for ANS COBOL programs is not neCEssary, and all indicator flags may
be maintained as bit flags.
ADVANTAGES OF SEGMENTED EECOFDS
The principal advantagEs in thE use of the segmEnted record feature
are described belcw.
Through the use of variable-lEngth records, variable-length segments,
and omitting unused seg_Ents, only that amount of disk storage required
for storagE of the information relevant to each record need be
allocated.
~~~i~ ~!Q!gg~ j:ii~i~n£l
On an application prcgram GET macro instruction, the entire segmented
record is read into the allocated file input/output area (FIOI), or,
for VSAM data sets, into the VSAM buffer. The segments making up the
segment sets requested by thE program are extracted by CICS/VS from
the record in the FICA, tuffEr, er VS8A and are moved into the file
work area (FWA). At this time, if the applicaticn program did not
indicate that the record will subsequently be updated and written back,
CICS/VS file control releases the PICA or VSil dynamic storage, and
transfers only the requested set of segments to the Pil. Consequently,
the amount of main stor~ge used in processing those segments is only
as large as the segments themselves. No additioral dynamic storage is
utilized for seg.ents which are not being processed.
1imi!~g ~g!g !ng§R§ng~£~
Because an application pregram identifies only that set of segments
which are significant to it, the modification of segments in the data
set which are not relevant tc the program concerned requires no
mod.ifica tions to that progra m. Limited data indEpendence is thus
achieved with a consequent reducticn in the amount of program
ChaptEr 5.
CICS/VS Data Base Design
165
modifica -tion following a change to the record format or data set
organization.
A further consideraticn of data independence is that additional
segment indicator flags may te allccated in the roct segment to allow
for the addition of future segments. If bit indicators are used, each
additional byte of hit flags will enable up to eight segments to be
added to the end of the segmented record. When these segments are
eventually added tc the records, seme-reorganizaticn of the data set
will of course be necessary. However, applicaticn programs which
utilize segment sets which de net contain the new added segments are
not affe(:ted.
eICS/VS FIlE CeNTROL DESIGN CONSIDERATIONS
As can be s~en fre. the atove discussion cf the indirect access
feature and segmented record feature of CICS/VS file control, data
bases may be constructed. A numter of factors should be taken into
account in deciding the aF~rcFriate data base support technique, either
indirect access, or segmented records, or both.
If data sets utilized online in a data base must also be processed
offline, the indirect access feature may he found to be more suitable
than segmented records. Use of this feature requires each offline
application program to provide its own support for the extraction of
segment sets from segmented records, and the insertion o~ segment sets
back into segmented records for updating. Alternatively, the code
SUFPorting the segmented recerd feature in the CICS/VS fiie control
program may be extracted by the user and modified for use by batch
FIograms.
If the batch Frocessing requirements of the installation dictate
that standard access methed support be used for tatch programs accessing
online data sets, the indirect access feature rather than the segmented
record feature should be used. This enables-logically related
information to be maintained across a series of different data sets.
However, this additional file accessing will have an effect on the
perfcrmance of the online ap~lications, and consequently on response
time. This is a further consideration in the design of a CICS/VS file
control data base.
Provided that suitable su~port can be developed to enable batch
application programs to access segmented records in online data sets,
the segmented record feature is su~ericr to the indirect access feature
when ODe considers the reduced file accessing necessary and the
efficient utilization of disk storage. with one file access, a
segmented record with all its related segments may be retrieved. with
indirect access, these related segments may have been defined in
separate indirectly accessed data sets, each requiring a separate file
access. Furthermore, only the object or target data set is returned
to the user.
A ~onsideration with segmented records is the extent to which
additicns to segments may be made. If segment additions result in an
increase in the segmented record length, then the segmented record data
set should ideally be defined as a key-sequenced VSAM data set, or a
variable-length OS/VS ISAM data set. Alternatively, DAM, ISAM, or
entry-sequenced VSAM data sets may be utilized using the dummy segment
166
CleS/vS system/Application Design Guide
and overflow data set techniques described above. However, this will
result in less efficient disk stcrage utilization, more user
programming, and more file accesses.
A further consideraticn is the extent to which information may be
added to data set records at a future time. If there is a strong
possibility of this occurring, it may be advisable to use the segmented
record feature, allocating additional segment indicator flags in the
root segment to allow for a specified number of additional future
segments. At that time, additional segments may be added, without
requiring modification of Fregrams which utilize segment sets not
associated with the newly added segments.
The use of the segmented record feature enables a large number of
multiple segments to be stered fcr a particular logical record within
a block, to a maximum of 99 segments in each logical record. The number
of multiple occurrences of segments may be further limited by user data
set creation and maintenance factors.
~sl ~toI!g§ !~!il!~ili!l
While the segDented rEccrd feature does net provide the capability
of the DL/I products, and introduces somE difficulties regarding batch
program access to segmented Iecords, this segmented record feature may
be considered for installations with real storagE of less than 1441
bytes, wbichare unahle te use the DI/I products because of insufficient
real storage. See "Data Ease Selection criteria" at the end of this
chapter for more detail.
EECOVEBY CONSIDEEATICNS
Becovery of infcrmatien in the event of system er program failure
must be considered in data base design. This subject is discussed in
more detail in Chapter 8, tut is introduced bere te identify those
factors which are relevant tc the recovery of CICS/VS file control data
sets. The optional journaling feature of CICS/VS permits a record to
be automatically logged by file central to the system log and/or to be
journaled to a user journal data set. The subset option of CICS/DOS/VS
does not support autematic lcgging or autematic journaling.
AY!QJ!~ ti,£
LoggiJ!,g
Automatic logging is reguired if data set backout is to be supported
by CICS/VS on emergency restart following an unccntrolled shutdown.
Automatic logging is specified in the file contrel table entry of each
data set for which backout is to bE supported by specifying LOG=YES.
(See ~l~~L!~ ~~~te! fIg,gIA!BSI!§ i§i!Ienc§ IADYA1.) On any update,
deletion, or addition of a nEW record, the "before" image is
automatically recorded cn the CICS/VS system log if automatic logging
is specified. The system log is journal number 1.
Automatic journaling allows the user to specify data set activity
to be recorded on any CICS/VS journal. For example, ~utomaticlogging
records the "befere" image of a record to be updated and goes to the
system log. Automatic journaling may specify that the "after" image
is to be recorded also. Additional journaling activity is identified
Chapter 5.
CICS/VS Data Ease tesign
167
in the FCT entry for each data set through use of the JREQ parameter,
and may te directed to a user journal data set or the system log through
use of the FCT JID parameter. This .ay be desired i~ a chronological
record of all data set activity is to te maintained. It permits
implementation of a user-written recovery program to recover a data
set from a previous backup copy if a'll unrecoveratle I/O error is
detected ..
The information recorded cn automatic logging, and on automatic
journaling, contains the identification of th~ task which carried out
the update, deleticn, or addition, the transaction code and terminal
identification involved with that task, the time of day, other
information required by the eICS/VS journal control program, and an
exact image of the record which was updated or deleted, or the record
identification of an added record. These records are written to the
CICS/VS system log and/or relevant journal data set in chronological
sequence '0
These logged updates, deletions, and additions to the CICS/VS system
log are utilized by CICS/VS on emergency restart fcllowing uncontrolled
shutdown to back out the data set activity of in-flight tasks.
Additional restart information can be found in ChaFter 8.
This section introduces the ccncepts, user design considerations,
and advantages of the DL/I products. It is stro~gly reco •• ended that
all eICS/VS users read the secticn in its entirety, unless they already
have prior DL/I experience.
This section is intended cnly as an introduction to some of the
significant features of DL/I, as used in the CICS/VS environment. It
should n
DATA
DESCRIPTION
>
BASE
(ABC)
1
-------
PROGRAM C
I
Figure 5-28.
DL/I Data Ease Approach
All application data is stered in one or more data bases in a
hierarchical fashion; that is, the mest significant data resides on
hierarchically higher levels, while less significant but related data
(dependent data) appears on hierarchically lewer levels, as illustrated
in Figure 5-29. This hierarchical aFproach enables programs te view
data in a data base apart frem its physical organization. Through the
use of a concept called "sensitivity," each application prcgram views
only that data in the data base which it uses.
(Sensitivity is
discussed further, in "Logical Data structures," later in this chapter.)
Chapter 5.
CIeS/VS Data Ease Design
171
DL/I accesses data in the data case and preseDts only the information
reguesteo by the program. The data Fresented to the program by DL/I
is calleo a "segment." A prcgram requEsts a segment from DL/I by
issuing a DL/I call.
In practice, a system designer reviews the data requirements of all
applications (as illustrated at the start of this chapter), then defines
the data base or bases. Tc create a data 'base, the user defines to
DL/I a common data structure and format that serve his applications
and loads his apFlication data into that data base.
The definition of thE data basE is provided by a data base
description (DED), and a tED is required for each data base (see Figure
5-29). ~his is generated Fricr to the loading of oata into the data
base, by assembling a set of DBD macro instructions which define the
data basE.
DUI
-
f'Program
Program
Communication
Block
DUI Call
(PCB)
./
Data
Base
Description
I
~
Data
Base
(DBD)
I
--
Data Base View
Program View
/
'"
Customer
No.!Name
/
---
I
I
I
Address
Account
Details
--
Figure 5-29.
DL/I Data Ease Access
The sEcond definition required is the program specification block
(PSB). ~bere is one PSB for each application prcgram. The PSB define~
to DL/I:
• The oata bases accessed ty an application program. Associated with
each data basE used by aD apFlication is a PCB. One or more PCBs
exist within a PSB.
172
CICS/VS system/Application Design Guide
• Each PCB identifies the sensitive data lsegments) in the data base,
available to the application program ~hich uses the PSB.
• Each PCB identifies the way in which the program views the data
base.
• More than one PCB defined in a FSB allows the application program
to process multiple data bases.
The PSB is generated by assembling a set
which define the above factors.
~f
PSB macro instructions
An application program specifies its associated PSB to be used to
access data bases. Each PCB is used to pass inferaation to DL/I
identifying:
• The name of the DBD describing the particular data base
• The type of calls (or precessing options)
use to access the data base
~hich
the program
~ill
• The number of segments te which this program is sensitive
In addition, fields are provided in the PCB fer DL/I te pass
information back te the Fregram, such as:
• The level number in the hierarchical structure of the last retrieved
segment
• The DL/I status code indicating the result of the last DI/I call
issued by the pregra&:
• The name of the last segment retrieved by DL/I
• The key of the last segment retrieved
Threugh DL/I's use of the DBD and PSB, application programmers can
write their programs without much regard to the physical structure of
data. Instead, they refer orly to segments of data as needed by the
program, without consideratien fer the physical location of that data
in the data base.
ADVANTAGES OF DL/I
DL/I provides applicaticn independence from access methods, from
physical storage organization, and from the characteristics of the
devices on which the data cf the application is stored. This
independence is provided by a commcn symtolic pregram linkage and by
data base descriptions external to the applicatien program. A reduction
in application program maintenance is generally realized.
DL/I provides for the reductien, and possible elimination of,
redundant data or sharing ef commOD data. The majcrity of the data
utilized by any company has Dany interrelationships that can cause
significant redundant storage of data if conventional organization and
access methods are used. For example, manufacturing and engineering
departments work with subset data which is also useful to quality
control.
The storage organization and access methods employed by DL/I
facilitate data integration ~ith a minimum of data redundancy. Ho~ever,
if an analysis of a company's data sho~s that all of the da·ta cannot
be placed in a single common data base, DL/I allcws the user the
additional capability of Ihysically st~ucturing the data across more
Chapter 5.
CICS/VS Data Base Design
173
than one data base. Before tL/I, application prcgrammers frequently
did not have the time or ability to integrate other data with their
own data to eliminate redund~ncies without the necessity of a major
rewrite of the applicatien prograDs involved.
SEG~ENT
DESIGN
The sDallest element cf data that may be retrieved by DL/I is a
segment. A segment contains ene ex more logically related data fields,
and is fixed-length for DL/I ENTFY~ and fixed- or variable-length for
tL/1 DOS/VS and IMS/VS DL/1.
The design of segments to be utilized in DL/I data bases is dependent
upon a number of factors. Seme of these are:
• The amount of data required at a time by the aFplicatien program
A segment is the smallest element of data which may be oFerated
upon in a DL/I data base and may comprise one cr several related
fields. The allccation ef fields to segments is generally based
upon common usage of the data contained within those fields. For
examFle, if a particular group of fields may be required by one
application program, it Day te desirable tc grcup these into a
segment, if ether characteristics of those fields are similar (see
below).
• The multiple occurrence cf infcrmation
The multiple occurrence cf infcrDation may require each separate
occurrence to be defined as a segment. For example, in a savings
bank system there may be many deposits or withdrawals against each
sa~ings account (see Figure 5-30).
~he savings account details
such as the account nUDber, account name, current balance, and
interest-to-date may comFrisE cne segment which, because it may be
required by many applications processing those accounts, may be
defined as a "root segment." A root segment is at the highest
level and generally contains infcrmation required by most
applicaticn FrcgraDs.
Each deposit transaction may ccntain fields such as date of deposit,
amount of deposit. and type of deposit. These fields may be defined
together as being a depoeit segment. Similarly, a withdrawal
transaction may contain fields such as date cf withdrawal,
withdrawal amount, and type cf withdrawal. These fields make up
a withdrawal segment. Because there may be maDY deposit and
withdrawal segments for a saviDgs account root segment, defining
each transaction as a separate segment will enable individ~al
transaction details te be readily accessed. Figure 5-30 illustrates
the multiple occurrence of deposit and withdrawal segDents based
upon a savings account reot seg.ent.
174
eIeS/VS System/Application Design Guide
Account
Detail
Segment
Deposit
Segment
Withdrawal
Segment
Contains
Contains
Contains
•
Account Number
•
Date Of Deposit
•
Date Of Withdrawal
•
Account Name
•
Amount
•
Current Balance
•
Type Of Deposit
•
•
Amount
Type Of Withdrawal
• Interest To Date
Etc.
Etc.
Etc.
Root Segment
Account
Detail
Segment
J
I
I
I
3
Deposit
Segment
Withdrawal
Segment
r-2
2
I--
"--
1
Figure 5-30.
1
Multiple Occurrence of Segments
• The sensitivity to data ty various programs
The requirement for certain application programs to have access to
certain infermation (tbat is, be sensitive tc certain segments),
and not be atle to access (OI be sensitive te) other information
or segments, assists in the segment design. For example, related
fields of information relevant to a particular applicaticn program
may te designed as a segment. That applicatien program may then
be made sensitive to this segment.
• Variable-length segments
In the case of IMS/VS DL/I, the ability to sUPFort variable-length
segment~ may dictate those fields which should be defined as
comprising a segment. Pcr example, a customer data set contains
customer name and address. A customer name is normally vaIiable
in length, as are custcmer address lines. In addition there may
Chapter 5.
CICS/VS Data Ease tesign
175
be a variable number of address lines. In this case, it may be
desirable to define the custcler name as one segment, called, for
example, the name segment, and to define each address line as a
separate address segment. There may be multiFle address segments
to allow a variable nUDbEr of lines in a custcmer address.
• Appl :ication-dependent reguirellents for information grouping
The design of segments, as wEll as the fields ~hich make up those
segments, is dependent upon thE application. An
application-deFendent Ieguirement lIay be the eJtent to which
information in the data tase might be expected to change in the
futul:e. If there is a high likelihood that certain fields within
a segment may change, it Day te desirable to define thcse
potentially changEable fields in a single segment, or a small number
of s4:gments. The extent of Frogram maintenancE because of a change
in the segment contents is therefore reduced. Dt/I enables new
segments to te defined very readily, vithoutaffecting application
programs which de not need to access those segments.
To assist in the design of segments, consult the appropriate
for DL/I ENTBY, tt/I DOS/VS, or IMS/VS
DL/I.
~I§!§JLAJ2Rli~J!i2D n~ig! i~idi
DATI INDEPENDENCE
Under DL/I, the data base concept gives the user data independence
between the physical storage of data and the application programs which
access tbe data in various ways. Physical data storage is accomplished
through the use cf two unique DL/1 storage organizations:
• Hierarchical Sequential
• Hierarchical Direct
The Hierarchical sequential organization is supported by two Dt/I
access methods: the Hierarchical Se~uential Acce~s Method (HSIM) and
the Hierarchical Indexed sequential Access Method ~ISAM). The·
Hierarchical Direct organization is supported by two DL/I access
methods: the Hierarchical Direct Access Method (HtAM) and the
Hierarchical Indexed Direct Access Method (HIDAM). The application
program interfacE with these two organization types and four access
methods is totally symbolic. The application is typically insensitive
to the pbysical data organizatien er the access method used. The
various (lata base organizaticns and access methods are discussed in
more detelil in tbe nlLl l!g~!.§ ~l§!~.lL'!ul~Jtig! ~'§~5U! "ui.9~ and the
!~~L!~ ~l.§te.LJRRli~J!igl l!~§ign ~Yi~~·
To pr()vide this iD.9~R!D~!~$' tbree definitions are required prior
to the use of the data base ty a program:
• The segments within a logical data base record to which a program
~ishes to te sensitive
• The logical data base record structure represented by one or more
segments frol one or more physical records
• The data base organizaticn and access methods
These definitions are madE thrcugh the use of the following data
base definition functions:
• Data BaSE Description (DED) Generation
176
Cles/vs' System/Application Design Guide
• Program Specification Eleck (PSB) Generation
• Application Control Bleck (ACB) Generation
The use of the DBD and FSE vas described above. The generated PSBs
and DBDs to be used in an online environment are processed offline by
an application centrel bleck (ACE) utility program before the first
use, to combine their se~arate specifications into an application
control klock (ACB) for use enline. ~he DED is changed by the ACB
utility into a data management block (DMB) describing the specific use
of the physical data sets re~resenting a data base. The PSB is changed
by the ACB to describe the specific use of the logical structures
available frcm one cr aore data tases to the asseciated application
program for processing. It is thrcugh the use of the DBD, PSB, and
ACB that DL/I achieves its data independence.
20 bytes
-20
-bytes
" -_ _ r
Customer
Number
Credit
Limit
Customer
Name
Uoo 1
Figure 5-31.
lOGICAL
DA~A
I
60 bvtes
Postal Address
Uri"
Line 3
Line 1
Line 2
Line 3
Line 4
"
....
Account History -- Arrears
Ship-To-Address
Line 4
6 bytes
,--,
,.,
Customer
History
Current
Bala~ce
T
One
Month
~
Th,oo
::thS.___
1
0,,,,
~~~~
::s _
•
Record Format: Fixed-Length
•
Record Length: 282 Bytes
Custcmer Account Record Pormat
STROCTURES
Application prcgrams written to use DL/I deal with logical data
structures. A logical structure refers to the manner in which the
application program sees the data. ~he logical data structure is always
a hierarchical structure cf £egaents. prograas written to process
logical data structures can te independent of the physical data
structure. A physical structure refers to the manner in which the data
is stored on a tape or on a direct access storage device. An
application program nevel: deals directly 'with a physical data structure.
Most data processing informatien, regardless of industry, can and should
be viewed as a logical data structure. Customer account infol:mation
is chosen here fer explanatQry pvrFoses because of its commonality.
Chapter 5.
CICS/YS Data Base Design
177
Figure 5-31 illustrates a typical customer account record and
the physical structure of the record as it might appear on
tape or on a direct access storage device. Each of the field groups
(name, pestal address, ship-to address, customer history, and account
history) is referred to as a segment. These segments usually contain
more basic data elements. Fcr example, one of the data elements
typically included in the name segment is a custcmer number. In
addition, the record might ccntain multiple address lines and account
fields. This is typical if address and account history are part of
the custcmer account inforDation.
desc~ibEs
This same data record appears in Figure 5-32 as a DL/I logical data
The name, postal address, ship-to address, and customer
and account history fields are considered DL/I segments. Each segment
of information may be made up of several fields.
structurE~.
The logical data structure in Figure 5-32 represents a hierarchical
relationship. Data ~elaticnships described by this hierarchical
structure have only one segment at the first level, level zero, and
may have multiple segments at sutordinate levels (for example, level
1) in the hierarchical structure. Each dependent segment in the
hierarchy has enly one parent or immediate superior segment. The
logical representation is sometimes called a tree structure. In Figure
5-32, the name segment with its associated address and account segments
constitutes a logical data base record.
Through the concept of program sensitivity, DI/l allows a program
to be structured so that only those segments of informatien that are
relevant to the precessing being Ierformed are presented to it. For
example, an account prog~am could be written for only the name and
account segments of the logical data base structure, as shown
cross-hatched in Figure 5-32. The program need net be aware of the
existence of the address segments.
Accounl
Program
Segment
Sensitiv,ity
Level 0 Segment
Root Segment
Level 1 Segment
Line :3
Line 2
Postal Address
Line 1
Figure 5-32.
178
Line 4
Line 3
Line 2
Ship-To-Address
Line 1
Customer
History
Customer Acccunt Lcgical Structure
CICS/VS system/Application Design Guide
The DL/I data base ca~abilities allow for handling hierarchically
related logical data structures cf considerable variance. The maximum
number of segment ty~es is limited for DL/I to 2~5 per logical data
base record (63 for tL/I ENTFY). A maximum cf 15 segment levels can
te defined in a logical data base record.
Figure 5-33 represents an example of a logical data structure for
a banking savings account. The structure consists of four segment
types: account detail, account name, deposit, and withdrawal.
li.2te: To illustrate DL/I terminology, the account name segment has
been specified in the lcgical structure on a level lower than the
account detail segment, tut higher than the deposit and withdrawal
segments. This imFlies that a relationship cf deposits and withdrawals
to each person operating on the account is significant to the
application. In actual ~ractice, it is generally not necessary to
identify the person who made a deposit, or withdrawal, but only the
fact that such a transacticn was made against the account. In this
case, the account name segment would be placed on the same level as
the deposit and withdrawal segments. It has beer. shown at a higher
level than these segments in Figure 5-33, only tc illustrate DL/I
terminology.
The lcgical structure in Figure 5-33 shows that account detail is
a root segment. The acccunt name segment is a de~endent segment of
the account detail segment, and the deposit and withdrawal segments
are dependents of the account names.
-----
Account Names
Account 'Detail
Acct.
No.
Acct.
Type
Namel
Curr
Bal.
peposits
Name2
Withdrawals
-.-----.-- -
-
Deposit
1
Deposit
2
Deposit
3
$600
$200
$500
Withdrl
1
-
Withdrl
2
--- 1------ - - 67321
Smith, John
Smith, Mary
$20
$50
Savings Account Record
Account Names
Are Children Of Account
Detail
Account
Detail
Ac No 67321
Account Detail
Is Parent Of
AccofJnt Names
Account
Names
Account
Deposits And
Withdrawals Are
Children Of
Account Names
Twins
Deposit
Figure 5-33.
Withdrawal
Savings Acccunt Logical Structure
Chapter 5.
CleS/VS Data Ease Design
179
A dependent segment relies on some higher level segment for its full
meaning or identification. Since the number of account name segments
may vary from one savings account to the next, logical data base records
will vary in length according to the number of segments occurring in
the hierarchy of the data structure.
The root segment in Figure 5-33 ccntains the specific account details
for account number 61321. There are multiple account name segments
for perscns using this account: John Smith and Mary Smith.
Also, for this account, there are t~o withdrawal and three deposit
segments,. The data base has four segment types, and this particular
data baSE record consists of eight segments because of the multiple
occurrences of the account name, deposit, and withdrawal segments.
The sf~gments immediately above and below a given segment are called
the "parent" and "child" seqment~ respectively. In Figure 5-33, the
account detail segment fer account 61321 is a parent of the two name
segments~
Each account name segment is a child of the account detail
segment. The deposit and ~ithdrawal segments sutordinate to the account
name segments are their children. All occurrences of a particular
segment type dependent on a particular parent segment are called "twin"
segments.. The account name segments fer John smith and Mary Smith are
twins of each other.
Refer to the ~1§!§~~jERli~ti~~ ~~§ign Qyi~§ for the relevant DL/I
product for further discussion of logical structures.
DATA BASE ACCESS CALLS
A com loon symbelic program linkage and data base description allow
batch ana online applicaticn programs to request DL/I to:
• Betrieve a unique segment (GET UNIQUE)
• Retrieve the next sequential segment (GET NEXT)
• Beplace the contents of an existing segment (REPLACE)
• Delete the data in an Existing segment (DELETE)
• Insert a new segment (INSERT)
Additional data tase access calls are pro~ided to enable all
dependent segments based on a particular parent segment to be retrieved
seguentially. The retrieval access calls may also specify that a record
being retrieved is to be held, because it will suhseguently be updated,
replaced, or deleted.
Application pregrams written in American National Standard (ANS)
COBOL, PI,II, and Assembler Language utilize the CALL statement facility
in these languages te perform the input/output functions listed above.
The external data base descriptions (DEDs) and program specification
block (PSB) descrihe the ~hysical data organization and logical data
structure of the data base to DL/I. Because of this ap~roach to data
referencE:, input/output cFerations and associated system control blocks
are not compiled into the apFlication ~rogram. This avoids program
dependence upon currently availatle access methods and physical storage
organizati~ns.
other apFlication data can be added to this data base
without necessitating changes to application programs that use the
data.
180
CleS/VS System/Application Design Guide
DATA BASE ORGANIZATION AND ACCESS
~E~HODS
DL/I supports two basic physical storage organizations as discussed
briefly above. 7he first crganizaticn, Hierarchical Sequential,
provides the base for both tbe Hierarchical Sequential Access Method
(HSAM) and the Hierarchical Inde~ed Sequential Access Method (HISAM).
The second organization, Hierarchical Direct, prcvides the base for
two more accessing techniques, the Hierarchical Direct Access Method
(HDAM) and the Hierarchical Indexed Direct Access ~ethod (HIDA~). HDAM
uses an addressing algorithm for direct access sup~ort of the
hierarchical direct organization. Standard addressing algorithms are
provided by DL/I, or may be supplied by the user installation for each
HDAM data base. HIDAM is an indexed access suppcrt of this hierarchical
direct organization.
~ach DL/I access method and data tase organization will now be
briefly introduced. Refer tc the ~~§!~L!RR1~~!lsD ~~§ign ~ide for
the relevant DL/I product for a aore detailed description of each data
base access method.
The primary differences between hierarchical direct and hierarchical
sequential organizations are the manner in which segments are related,
and the techniques of data storage and access. Segments in the
hierarchical sequential organization that represent one data base record
(that is, a physical hierarchical tree structure) are related by
physical adjacency. This requires that segments which represent one
data base record be contained in a variable number of segment blocks
unique to that data base record.
HSAM is used for sequential storage and access on tape or direct
access storage. The DOS/VS and CS/VS sequential access methods (SAM
and ESAM respectively) provide the data management services for HSAM.
Physical blocks (a variable numter) required to contain a particular
data base record are accessed by physical adjacency (H5AM).
HISAM is used for indexed sequential access to the hierarchical
sequential organization. data base record may be directly accessed
through an index. Segments within a data base record are related by
physical adjacency. All physical blocks used to store the segments of
a single data base are related by direct address pointers. The virtual
storage access method (VSAM) provides data management services for DL/I
ENTRY, DL/I DOS/VS, and IMS/VS DI/I. IM5/VS can optionally use BISAM
and a EDAM-like access method called OSAM for data management services.
(However, DL/I facilities such as variable-length segments, or secondary
indexing (see later in this chapter) are only available to data bases
which utilize VSAM.) Generally, a HISAM data base is comFrised of one
VSAM key-sequenced data set and cne entry-sequenced data set.
Note: DI/I ENTRY only uses one VSAM key-sequenced data set to support
a HISAM data base.
Chapter 5.
CICS/VS Data Base Design
181
segments in the hierarchical direct organization that represent one
data baSE record (that is, a physical hierarchical tree structure) are
stored in one or more physical blocks. However, all segments in that
data baSE record, rather than the physical blocks containing the data
base record, are related by direct addresses. Each segment in a data
base record refers to segments of the same type, as well as to adjacent
segment types, through direct addressing. Physical blocks that contain
segments of the data base record are not related by direct addressing.
In the hierarchical direct organization, the sFace requirement for
each segment is increased frc. that required in the hierarchical
sequenticll organization. This sFace is required to accommodate direct
addresses. However, the following advantages are gained:
• More rapid direct access to segments within a data base record.
• The ability to share sFace in a direct access storage block across
multiple data base reccrds. One physical blcck may contain segments
from different data tase reccrds. This may result in a considerable
saving of data base stcrage space.
• The ability to reuse sFace occupied by deleted segments through
the laintenance of free sFace addresses.
!Ul!!1 !1§£Q~gl~~.!!.2!
HDAM is used for direct algorithmic randomized access to records in
the hierarchical direct organization. Direct access is available to
each data base record. VSAM Frovides the data management services for
HDAM. OSAM provides optional data management services for IMS/VS DL/I,
but (as discussed previcusly for HIS AM) facilities such as
variable-length segments or secondary indexing cannot be utilized with
OSAM. 01/1 ENTRY does not support HCAM.
!!!12!~ Re.£_Q~g IQ~u!
HIDAM is used for indexed access to the hierarchical direct
organization. Indexed access is available to each data base record.
VSAM provides the data managellent services for HIDAM for Dt/I DOS/VS
and IMS/VS DL/I. BISAM and eSAM Frovide optional data management
serv ices in HIDAM for IMS/VS DL/I.
(See reference to EISAM and OSAM
limi tations above for HISAM and BDAM.)
DL/I EN'IEY does not support
HIDAM.
Refer -to the ~~§!nLJ~.Eli.£JU.Qll 12!§isul §.g!g§ for the aFpropriate
DL/I product for further infcrllaticn c~ncerning data base organization
and access methods.
lOGICAL STRUCTURE tESIGN
The preceding discussion has estatlished the concept and organization
of DL/I data bases. As discussed previously, the smallest data element
which can be accessed by an application Frogram is a segment. The
design of segments is a key factcr in the design of DL/I data bases.
Following this segment design, the design of logical data base
structures should be considered.
182
CICS/VS System/Application Design Guide
Logical structure design depends upon the application. However,
some of the factcrs which shculd be considered in the design of logical
structures are:
• The utilization of deFendent segments
A program may wish tc access the information in the root segment
of a data base record. In the savings account example in Figure
5-33, the account details will be contained in the root segment.
Follcwing the accessing of this root segment, the application
requirements may dictate that segments dependent on this root must
te accessed. In the savings account example in Figure 5-33, the
account name segments, then the deposit segments and the withdrawal
segments may be accessed either individually or in their order of
occurrence.
• The sensitivity of programs to segments
An account inquiry pregram, fer example, may wish to access only
the account detail (root segment) and the acceunt name segments.
In this case, the program would te defined as teing sensitive only
to these segments.
Similarly, an account process1ng program may need to access only
the account detail (roet segment) and the depesit and withdrawal
segments, withcut reguiring reference to the account name segments.
This enables deposit and withdrawal transactions to be retrieved,
updated to reflect possitle correction, cr added as new deFosit or
withdrawal transactions are received against an account. In this
case, the account processing program would be defined as being
sensitive only te the account detail root segment, and the
withdrawal and deposit segments, but not sensitive to the account
name segment.
• Application factors
In a savings account example, once an account is opened, information
such as the name segment may not be changed or added to
significantly. In fact, if there is only one name for each account,
it may be logical to Flace the name within the root segment itself.
However, because there may be more than cne ~ame associated with
an account, the Fossible multi FIe cccurrence of names may dictate
that these be separate segments which are deFendent upon the account
detail root segment and furtheI describe that account. The deposit
and withdrawal segments reflect activity of transactions against
the account. Because there may be multiFle deposit and withdrawal
transactions, it is logical to make them separate segments which
are also dependent (legical children) upon the account detail root
segment.
Similarly, in an insurance pelicy information system, a policy data
tase may contain policy details in the root segment, policy
beneficiaries in name segments dependent upon the root segment,
and Folicy claims and renewals transactions dependent upon the name
segments (see Figure 11-19).
In a manufacturing werk crder system, the manufacturing werk order
data base may contain all of the manufacturing work erder
information in a root segment, with multiple status information
recorded at different stages of manufacture in status segments
dependent upon the root segment (see Figure 11-5).
Chapter 5.
CICS/VS Data Ease nesigD
183
In a medical patient information system, the patient's na.e, birth
date~ and ctber details vould be contained in the root segment,
with his address in seFarate address line seg_ents dEpendent upon
the root seg.ent. De~endent upon these address segments would then
be visit segments, diagnosis segaents, and treatment segments of
which tbere way be aultiFle cccurrences for a patient (see Figure
11-23) •
~§gg§~! E~!§~~~~s ~§§igD 1!£12~!
In a Folice inforaaticn s}stea, the logi~al structure aay te designed
for a criminal data base by placing the personal characteristics of
the criminal in a root seg.ent tcgether with his true na.e. This is
illustrated in Figure 5-34 for reference during the discussion in the
follcwing paragraphs.
Alias names may be dependent segments of the root segment. The
particular mode of operaticn for various criaes lay be each stored in
a separate 1!.2g'y§ 2RillDgi seg_ent. ~hese G~ll§ .9~!Ey,gi segments lIay
be dependent upon the alias segments (see (A) in Figure 5-34), but more
logically are furtber descriFticns of the cri.inal who is descrited by
the root segment. Thus, tbe alias segments and ~dus 2~iI!Dg! segments
are regarded as twins if both are children of the root segment (see
(B) in Figure 5-34).
Following the J!~JL§ .2.E!.!!!S! segments may be various convictions
recorded against this cri.inal (e). Bach conviction is contained within
a conviction segment, and typically idEntifies the crime to which the
conviction is related, the particular punishment carried out, and the
extent to which that punisbment has teen carried out. Alternatively,
the conviction seg.ents aa} te children of the root segment and twins
of the .I~.g'y§ 2R!I!Dgi and alias segments (see (D) in Figure 5-34).
The decision whether tc define the logical structure in such a manner
that these dependent segaents are twins, or children, depends upon the
information which will be availatle for subsequent accessing of this
data baSE record. Tc access a child segment efficiently requires
identification of the parent.
184
CICS/VS Syste./ApFlication Design Guide
Personal
Characteristics
Name
I
I
I
J
J
2
1-
To access one
conviction here,
only the name
must be identi·
fied.
-
3
Alias
Name
Conviction
I
I
2
1
I--
Modus
Operandi
-
1
To access one
modus operandi
only the name
must be identified.
2
I
1
I
I
t;;\
V
r~---
To access one
modus operandi,
the name and
alias name must
be identified, or
all modus operandi
searched.
----l I
Modus
I 1
II
I~
Operandi
1_-.
-_'1
Conviction
G:
1
___
J
o
To access one
conviction, the
, name and modus
operandi m~
be identified, or
all convictions
searched.
I I
Conviction
I2I
I_ _ _ _ _1JL..::.J
To access one
conviction here,
the name, alias name,
modus operandi and
conviction must be
identified, or all
convictions searched.
Figure 5-34.
I
1
rl-- --, --,
- -
:
--,
J
IL-
1
I
I
1
[ - -'---1
Summary
(8)
Is most sUitable position for
modus operandi segment 10.
(0)
Is most suitable position for
conviction segment 10.
P9lice Data EaSE Lcgical Structure
In this exa.~le, if J~~J~ ~R~IA~~i were a child of alias (A), and
convicticns were children cf JRgJ§ 2R~IAn~i (E), to. retrieve information
relating to particular convictions for a cri.inal would require
knowledge possibly of his true naDe, his alias name, and various aggg§
~R~• .iD.9i (see (E) 'in figure 5-34).
Bowever, in this aFplica tion, that
idEntification aay not be availatle to access information relating to
convictions. In this case, it wculd bEtter to define convictions as
children of the roct seg.ent (D).
If the convictions, .~~i§ ~R§'j»~i, and alias segaents are twins,
any segment may be accessed knowing only the trUE name of the criminal.
KnowledgE only of a Farticularalias nalle, or of a particular l2.Qy§
2R§'~~~i for a cri.inal, in some caSES, may requirE the use of
additional DL/I features, such as logical relationships, or secondary
indexing, which are descrited below.
Alternatively, instead cf using sEcondary indexing, a separate data
base may be organized based cn alias names, which Frovides a
cross-reference to the original criminal names, and another data base
lIay be organized based u~cn !2GY§ 2R~I!ngi which again identifies the
Chapter 5.
CIeS/1S Data Base Design
185
criminal's true name. Thus, by accessing the separate data bases first,
the criminal may be identifiEd and then further information related to
that criminal may be ottained frcm the criminal data base.
Obviously, the factors which may te considered in the design of
logical structurES are cften very de~endent upon application. Refer
to the ~l~§!!:!!!!L.lJ2.Eli5:gti~1! ~§ign 2.Yi,g§ for the relevant DL/I product
for further discussion af logical structure design.
UPDA!ES, ADDITIOtiS, AND tEIEilONS
In order to update (REFtACE) segments in DL/I data bases, it is
necessary to indicate when the original record is retrieved that there
is a possibility that the record aay bE updated. ihis is indicated by
placing a "hold" cn that segDent with a GET call, such as GET HOLD
UNIQUE, GET HOLD NEXT, or GET HOLD NEXT WITHIN PAR~NT. The segment
presented on a GET HOLD call is then updated by the application program
and written back with a EEFLACE call. Alternatively, if the segment
is not tc be updated, this is indicated by the next GET call, without
an intervening REPLACE or DELETE. In effect, the HOLD used with the
GET call implies that "exclusive centrol" is to te placed on that
segment to prevent the same segment from being concurrently updated by
another task. Only when the REPlACE or DELETE call (or the next GET)
is issued is the exclusive control released.
When DL/l DOS/VS or I!S/VS DL/I is used with CICS/VS, concurrent
updating "ill be prevented at the segment-type level with the
scheduling-by-intent feature. The DL/I task will not be scheduled if
it has conflicting intent with another active DL/I task on the same
segment type. This may have performance implications, depending upon
the frequency cf reference tc the saDe segment type by concurrently
executing tasks. However, it provides the ability to back out p~ograms
independently in the event of an unccntrolled shutdown. VANDL-1 and
DL/I ENTEI, used with CICS/DCS/VS, does not perfcra checks at scheduling
time and does not previde specific backout support following an
unccntrolled shutdown.
To illustrate the significance of segment intent scheduling on data
base design and performance using ut/I DOS/VS or 18S/VS Dt/I, consider
the follewing order entry and inventory control application in the
distribution industry.
Each store carries its cwn inventory and enters orders from a
terminal located in the stcre. These orders update the inventory
maintained in a central data base for all stores. If the inventory
data base is designed with oLly cne segment type for inventory details
across all stores, only one task (that is, store transaction) would be
scheduled to update that segment type at a time. This may have
significant performance implications if several stores were concurrently
entering orders, and may result in single thread access to the data
base.
However, as each store carries its own inventory, a separate
inventory details segment type may bE defined for each store (subject
to the maximum of 255 differEnt segment types, imposed by DL/I). In
this way, each store transaction would bE scheduled on its own inventory
details segment type, with nc conflict with other stores inventory
segment types. This will permit multithread access to each stores
inventory details, with conseguent iuprovement in performance without
any loss in data integrity. However, it will be dcne at the expense
of additional HDA! data base pointers, control block storage, and
application program logic.
186
CICS/VS System/Application Design Guide
In the case of an addition (INSEE~), the seg.eDt to be added is
ccnstructed according tc the aF~licaticn require.ents, and then added
to the appropriate part of the data base by identifying the keys of
various higher level segments (using a GET HOLD UNIQUE call, for
example) and hence the lccation within the data base.
For a deletion (DELETE), the segment to be deleted may be identified
by providing the keys of various higher level seg.ents, and hence the
location of the segment within the data base by using a GET HOLD UNIQUE
call. Depending upon the hierarchical access method used, the segment
may be either physically deleted immediately (HIDA8 or BDAft), or
logically deleted, and net physically deleted until the next data base
reorgani2ation (BISAft).
LOGICAL BELATIONSHIFS
IMS/VS and DL/I DOS/VS previde enhanced data base support through
the use of logical relationships. Consider the police information
example discussed in Figure 5-34 above. Two data bases will nov be
considered, a criminal data tase and a crimes data base. If each data
base were completely separate, criminal identification vould be provided
within the crimes data base, and crimes identification vould be provided
within the criminal data base. ihile this eay be quite satisfactory,
the use of logical relationships enables redundancy of information to
be avoided. For example, the crimes data base, in identifying various
criminals associated with a ~articular crime, is duplicating information
which is already on the criminal data base. Similarly, the criminal
data base, in identifying information relating tc particular crimes,
is duplicating information already in the cri.es data base.
As described in "DL/I Access from CICS/YS," each DL/I product permits
multithread access to DL/I data bases by several concurrently executing
CICS/VS tasks. DL/I DOS/VS and I!S/YS DL/I use seg_ent intent
scheduling to ensure data integrity; DIll ENTEY issues I/C requests to
CICS/VS file control. File control maintains data integrity through
exclusive control and prctected resources. In addition, DL/I data
bases specified for DL/I ENTEY as data sets in the file control table
may also specify autcmatic lcgging fer implementation of backout
support.
(See Chapter 8.)
Name
--I
Personal
Crime
~h.aracter
IStlCS
---"---
.-
-...,
Alias
Name
Modus
Operandi
Conviction
Criminal Data Base
Figure 5-35.
--,
I Conviction I : Criminal I
I
I
L _ _ . ..J
L ___._....l
Suspect
Crimes Data Base
Police Data Ease Logical BelatioDships
Chapter 5.
CICS/YS Data Base Design
187
To avoid this duplication, logical relationshiFs utilize pointers
in the criminal data base conviction segments to identify the relevan
crimes infor.atien in the crimes data base (see Figure 5-35).
Similarl}', pointers in the crimes data base enable relevant criminal
information to be identified in the criminal data base. crimes
information and criminal infermation need appear cnly once, each in
its ewn data base.
Crime
I
Conviction
I
]
Criminal
I
Modus
Operandi
Figure 5-36.
-]
Alias
Name
]
",
I
Suspect
Conviction
Logical Data Base Viewed from Crimes Data Ease
Criminal
I
Modus
Operandi
Alias
Name
I
I
Conviction
I
Crime
Conviction
Figure 5-37.
188
Logical Data Base Viewed frcm criminal Data Base
CICS/VS systeR/ApFlication Design Guide
Consequently, that information is accessible to the other data base
through the use cf logical relatienships.
Through the concept of logical relationships, expanded data
structures can be created. These eXFanded data structures are then
available to applicatien Frograme. See Figures 5-36 and 5-37.
Once a logical data base is defined through one or more physical
data bases, the logical data base can be accessed ty an aFFlication
Frogram through a PCE.
Logical relationships and logical data bases are available with
IMS/VS and DL/I tOS/VS., and limited logical relaticnships are available
with DL/1 ENTRl.
Secondary indexing is a feature offered by 1"5/V5 and Dt/1 DOS/VS,
and to a limited extent ty 01/1 INTEl, for data bases which utilize
VSAM. Effectively, it enables separate indexes to be developed based
upon the data as key or data fields cf particular segments. For
example, in the police information system described previously, and
shown in Figures 5-34 and 5-35, it may be necessarl to access
information in the criminal data tase given the !~9Y§ 2£§IAn2i, or
given the personal characteristics of a criminal. This can be achieved
by establishing a data base crganized by !2SY§ 9I§!lDgi and another
data base organi2ed by personal characteristics.
Secondary indexing, hcwever, enables separate indexes to be developed
by DL/I for segments at any level in a logical structure of a data
base. These indexes may be used tc directly retrieve segments at that
level. Eapid access to specific infcrmation within a data base can be
achieved, as well as the ability to consider a data base as being
organized in different seguerces. In addition, secondary indexing
allows a data base structure to be inverted. Consider the criminal
data base in Figure 5-35, with a seccndary index tased on a field within
the !22YS QE§.s»9i segment. The structure may thEn be referenced in
an inverted form, as shewn in Figure 5-38.
MODUS
OPERANDI
I
CRIMINAL
Figure 5-38.
Inverted Folice Data Base Logical Structure
If secondary indexing is rct to te used, an alternative approach
may be adopted. By defining additional small data bases containing
the relevant segment key infcrmaticn, and identifying thE data base
record key information as descrited above, a similar effect may be
achieved, but with pcssibly more physical disk accesses and more user
programming.
ChaptEr 5.
CICS/VS Data Base Design
189
DATA BASE UTILITIES
A numter of data base utilities are provided for DL/I. These
facilitate the s~ecification of data bases, and the recovery of the
data bases in the event of failuIE.
g~QgIAD ~§£i!i~~!i~~ ~12~!
~~§) ~!~!~!i2n
The program specification block (ESE) macro instructions generate
the contlcol blocks that define tc Dtll the physical or logical data
bases used, the logical data structures within each physical or logical
data basE, and the operaticns allowed on each data base by a particular
application. The sensitivity of an application prcgram tc particular
information cr segments within the data base is also defined in the
PSB generation assembly.
~~!g ~.9.§~~
De§s,,:i12!i2'!! U2~IH §.§ll!.!!!i.2n
The data base description (DBI) macro instructions generate control
blocks that define to DLII fer each data base, the data base name, its
data structure, its data format, any logical relationships, any
secondary indexes, and the DI/I access method used.
Before the program and data baSE descriptions created by the PSB
and DBD generaticn utilities can be used with DL/I DOS/VS or IftS/VS
DL/I, they must te merged and expanded to an internal format.
Instruction execution and direct access I/C time, required to prepare
the program fOI execution, are minimized by prebuilding the required
application control blocks by means cf the application control block
creation and maintenance utility. Then, when an application program
is to be run, its control blccks are read in directly (if they are not
already in dynamic storage), and control is passed to the application
program. with DLII DOS/VS, the control blocks are brought into the
eICS/DOS/VS address space at initialization of CICS/VS.
~gta ~~§s ~!Q~g!ni~g!i2B Y~lS!g Jn~
i!12!g
When the data in the data base is updated, the physical structure
of the data may change, increasing access time. Also, the space
occupied by obsolete data is not in all cases reclaimed and reused.
The data base reorganizaticn unloa~ and reload utilities may be used
to unload, reorganize, then reload HISAM, HIDAM, and HDAft data bases
to eliminate these problems. Additional informaticn on DL/I data base
reorganiziaticn and recovery Day be fcund in the .Yi!lilii§ ~fere!l.£.§
~§nY~l for the relevant DLII product.
DATA BASE RECOVERY
The data base recovery system provided by DL/l DOS/VS and
comprises four utility programs and is designed to provide a
accurate, and easy-to-eaploy means of restoring the contents
physical data baEe after destruction through an I/O error or
task termination. The utilities are:
• Data base data set image copy
• Data base change accumUlation
190
eICS/VS system/Application Design Guide
IftS/VS
rapid,
of the
abnormal
• Data base data set recovery
• Data base backout
These utilities are introduced here, and discussed in more detail in
Chapter S.
DL/I ENTBY does not provide any support for data tase recovery.
All updates or additions to a data tase are autcmatically logged on
a DL/I log tape in a batch envircnment, or optionally on the CICS/VS
system log when DL/I is used on online with CICS/VS. These changes
may be utilized, together with the data tase reccvery utilities
described below, to restcre the data base to its data state at a
particular point in time, in the event of the destruction of the data
base through I/O errors, program errors, or system failure.
Data
~.Sl§~
Ba.£!,YJ2
The data base data set image ccpy utility dumps individual data sets
on tape or disk in a format suitable for use by the data base data set
recovery utility. It is run periodically for data base backup.
R~ri~i.£ ~.Sl!§ ~~~~ £h~Dgj J£~Y!,Yl~!i~n
The data base change accululaticn utility sorts records from the
data base log tape and conti res all records that update the same
segment. The result is a se9uential data set that contains a condensed
description of all changes tc the data base, and results in faster data
base recovery.
The objective of the data base data set recovery utility is to
recover from I/O error destructicn of the data base. This utility
reconstructs individual data sets cf the data base by first obtaining
from the data base backup rUD an image of each data set at a point in
time when it was known to te valid, and then merging the accumulated
application data from the most recent data base change accumulation
run. Finally, any DL/I systeD lcg tapes which were not included in
the accumulated change input are applied until the data set contains
the desired data. The net effect is tc update the backup data base to
its status at the time of failure caused by an I/O error.
Th€ data base backout utility is designed to recover from data base
"pollution" caused by abnormal prcgram terminaticn in a batch
environment. It reads the DI/I system log tape tackward and removes
(backs out) changes made to the data base from the pcint at which the
DL/I system terminated, to the pcint at which the program was scheduled.
The resulting data base is ncw restcred to its data state at the time
the application program was originally scheduled, exceFt for changes
made by ether ncn tacked-out Frograms that terminated afterward. This
utility also creates a log tape that reflects backcut changes.
Chapter 5.
CICS/VS Data Base Design
191
]~ta ~~§~~ Ba~~~y!
(2Rli~~)
In thE: online environment with CICS/VS, DL/I log activity is
optionally directed to the CICS/VS system log. Curing emergency restart
following an unccntrolled shutdown, the CICS/VS recovery utility program
(DFBBUP) identifies in-flight tasks and collects in-flight tasks to
the restart data set. (ihis identificat~on may include in-fli9ht DL/I
activity.) CICS/VS backs cut in-flight DL/I activity directly during
emergency restart. The batch DIll backout utility need not te used.
See "Online DL/I Data Base BEcovery" in Chapter e for additional
information.
DL/I DATA BASE DFSIGN
The informaticn presented above has been given to enable the CICS/VS
system designer to develcp a conceptual understanding of the
capabilities of the varicus Il/I Froducts. Guidelines were given for
the design of segments and lcgical structures, which make up part of
the design of a data base. The follcwing discussion identifies some
additional factors which should be considered in oata base design.
• Fhysical disk storage available
Boot-segment-only lcgical structures may enable an access method
to be chosen which utilizes little or no prefix information, but
contains only the data base record. Bowever, a more complex logical
structure, such as one invo11ing lcgical relationships, contains
considerable additional information in the prefix to define the
pointers tc varicus related segments.
A further consideration is the reduction of redundant storage of
information through the use of integrated data bases and lcgical
relaticnships.
• Number of disk acceSSES
The number of acceSSES which will be necessary to retrie1e
particular inforaaticn is a factor to be considered in the design
of data bases and of logical structures. These are influenced by
factors which are the responsibility of the data base administrator,
such as logical record lEngtls, block lengths~ access method chosen,
logical relaticnshiFs, and seccndary indexing.
• DL/I product to be used
Another factor in data base design is the selection of the
appropriate DL/I product. Fcr example, in the case of DOS/VS
installations, DL/I £05/VS would normally be utilized with CICS/VS
for installations ha1ing at least 160K of real storage 9r greater.
For satisfactory perfcrmance, 192K of real storage, or greater, is
recommended. support available with the particular product chosen
may influence the data base design decision.
For further informaticn on data base design, refer to the
§yid§ for the relevant DL/I product.
~~§!~.L!~!li~~!i~~ ~§§iSD
Baving broadly defined the data sets and programs required for the
various online applications, a dEcision must be made as to the
appropriate data base SUPFcrt for these applications. Various
characteristics of the application and of the data sets required, as
discussed at the beginning of this chapter, are used to make this
192
CICS/VS system/Application Design Guide
decision. The support fer CICS/VS applications should be selected from
the following alternatives:
• CICS/VS file control support
• Data Language/I (DL/I) support
Several factors should be considered when making this decision.
most important of these facters are detailed in the follewing
paragraphs.
The
• EXISiING RECORD FOReATS
The particular record format for each data set should be considered.
If the recerds are best suited te fixed fermat, any of the data
base support products may be selected, depending on other criteria.
However, if the data set can takE advantage cf variatle record
formats, the record contents should be examined in aore detail.
If the record is of variable-length because it contains a variable
number of fixed-length secticns cf information (segments or
logically related fields), then cne of the DI/I products should be
serieusly censidered.
Each of the DL/I products suppcrts the use of fixed-length segments.
An effectively infinite numbEr of segments can be present for each
record, so resulting in a variable-length record.
On the other hand, if there aay be up to a certain maximum nueber
of segments within each record, eleS/VS file centrol, using the
segmented record feature, ma] be censidered.
If
as
er
in
the variable record is made up of variable-length fields such
customer name and address, they may be sUPFcrted by Dl/I ENTRY
DL/I DOS/VS only if these variable-length fields are contained
fixed-length segments.
If the record is variatle because of the presence or absence of
different secticns cr segments of the record, the recerd aay lend
itself either to CICS/VS filE control segmented record support, or
to DL/I support depending upcn whether the segments are fixed-length
or variable-length. If variatle-lEDgth segments .!§i be used,
select CICS/VS file control, or if CICS/OS/VS is used, then 18S/VS
DL/I may te selected.
• DATA BASE PERPOR!ANCE
Prime consideration in oDline application design should be given
to the access time fer retrieval of infor.atien from a data base.
Depending upcn the performance reguirements of the application,
this may dictate the selection of data base support. Por example,
if a data set aay need te be accEssed through cther data sets, it
may lend itSElf to the use of the CICS/VS file control indirect
accessing feature. However, if several data SEts have to be
indirectly accessed to ottain the required information, these
additional file accesses could have an adverse effect on online
perfcrmance.
The particular access method selected with CleS/VS file control
for the application may affect the performance. Por example, the
direct access method (DAe) generally provides excellent online
performance. However, DAM suppert reguires that recerds be
identified by either their physical location on disk er their
Chapter 5.
CICS/VS Data Base Design
193
relative location in a data set. The application, on the other
hand, may reguire that a reccrd te accessed ty a key. In this
case, the indexed sequential clccess method (ISAM) may be suitable,
but its use will invelve at least two file accesses to retrieve
each record. FurtherDere, if many additions are made to an ISAM
data set, the access time for a specific reccrd may increase.
To o'vercome some of the above limitations, the virtual storage
access method (VSAM) may be test suited. This enables records to
be retrieved directly, based on relative location in the data set,
or by key. It also enables rapid retrieval of information for
applications with a high percentage of additions to the data set.
However, VSAM should net te us~d on CPUs with less than 144K of
real storage, if satisfactory performance is to be achieved.
Another factor which should te ccnsidered is the serial scheduling
of concurrently executing tasks, several of which may wish to update
the same record in a data set at the same tiDe (see "Exclusive
Control During Update" in this chapter). CICS/VS will permit only
one task te update a reccrd at a time, and other tasks wishing to
update that same record must wait for completicn of the first
update.
(HoweVer, other reccrds in the data set may be concurrently
updated, if required.) 1his serialization of updates may affect
perfcrmance, if applicaticn factors may cause concurrent updating
of individual data set records to be attempted.
DL/I provides a number of access methods which may be used for
satiEfactory perfermance depending upon the reguirements of the
application. These access methods are the: Hierarchical Seguential
Access Method (HSAM), Hierarchical Index Sequential Access Method
(HISAM), Hierarchical Direct Access Method (HDAM), and Hierarchical
Index Direct Access Method (BIrAM). Refer to the ~~§!~LA£Rlication
~§§!gn ~Yide for the relevant tL/I product for further informaticn
about DL/I access methcd selecticn.
The (ICS/VS-DL/I interfaces all scheduled DL/I CALLs fromCICS/VS
application programs on a multithread tasis. Several CICS/VS
application programs (tasks) may cencurrently access the same, or
different, data bases up to a maximum of 255 cencurrent tasks for
DL/I DOS/VS, 32 for DL/I ENTEY, er 15 for IMS/VS DL/I. CICS/VS
tasks may concurrently access different segment types in a data
base. However, if two or more tasks attempt to concurrently access
the Siame segment type, DL/I DOS/VS and IMS/VS tt/I determine the
type of accessing reguested. If both tasks enly wish to read the
segment type, they are permitted concurrent access. However, if
the tasks wish to update the segment type concurrently, for example,
they are not scheduled ccncurrently by DL/I. 1he second task must
wait until the first task has terminated its use of DL/I. This is
called "Scheduling by Intent." It may affect performance if several
tasks attempt ccncurrent update (fer examFle) ef specific segment
types in the data base.
(See "Updates, Additiens, and Deletions"
with DL/I in this chapter for an example of data base design to
reduce the effect of segment intent scheduling in perfbrmance.)
ihe CICS/DOS/VS-tt/I ENTFY intErface permits multithread access to
DL/I data tases, up te 32 taskE for Dt/I ENTEY. In order to prevent
double updating of a seguent, DL/I ENTRY uses CICS/VS facilities
to enqueue (tetween the GET HOlD and the REPLACE calls) on the
logical record that contains the segment to te replaced.
194
CICS/VS System/Application Design Guide
• EATCE PROGRAM ACCESS
If the online application data sets require further processing in
a batch environment, this consideration should also be taken into
account in selection of the data base support.
Factors which shculd be ccnsidered are that CICS/VS file centrol
supports variable-length reccrds within a fixed-length block for
DOS/VS ISAM data sets, standard OS/VS variable-length BISAM data
sets, and blecked records for DA~ data sets. COS/VS IS1M does not
support these variable-length records for ISAe in a batch partition.
They can be accessed in a batch environment ty defining thea to
DOS/VS 1SAM as fixed-length unblocked records. However, the batch
processing program must itself deblock the variable-length records
from the fixed-length blcck returned to it by DOS/VS ISAM.
Neither DOS/VS DAM, CS/VS1, cr OS/VS2 EDAM supports tlocked records.
If blocked DAM data sets are tc te accessed in a batch environment
seguentially, they may be defined as DOS/VS SAM data sets or as/vs
ESAM or QSAM data sets. In this instance, the sequential access
methed will handle detlocking of records.
Eowever, if the batch precessing programs need to access these
blocked records directly instead of seguentially, the responsibility
rests with the batch program to define the data set as an unblocked
DAM data set and previde its ewn deblocking of records within that
physical block.
The use online of the CICS/VS file control indirect access and
segmented record features reguires that special coding to support
these features in batch programs be developed by the installation.
The DL/1 products support the same acceSs methcds and record formats
toth online and effline. No additional coding is required to enable
batch DL/I programs to access online data bases.
CICS/VS and concurrently executing DL/I batch Frograas in other
partitions should net attempt to access the saDe data bases.
• EATCE DATA BASE CREATICN
C1CS/VS file control provides no facility for creation of the online
data bases, apart frem that Frevided by standard SAM, VSAM, DAe,
and ISAM support. The insertion of indirect access pointers in
data sets, and the preparatien and organization of segmented
records, is the responsitility of the user. Generally, special
data base creation prcgram~ must be written ty the user.
Similarly, no facilities are provided for maintenance of the online
file control data bases in a batch environmert. To provide this,
the user's data'base creation Fregram should also be designed to
allow a maintenance capatility.
DL/I allows creation and maintenance of data tases through the use
of various utilities. Furthermore, because the program is
independent of the physical data base organization and only refers
to its legical organization, considerable flexibility is offered
the installation in data base reorganization and aaintenance.
Chapter 5.
CICS/VS Data Base Design
195
• INSTALLATION DATA BASE SOPPOET DIRECTICN
In evaluating each of the selection criteria described atove, the
systEm designer Dust keep in mind the future directicn for his
installation in the use cf particular data base support.
CICS/VS file control may be utilized if desired, because CICS/VS
has teen identified ty lEe as one of its standard data base/data
communications Frogram pIoducts. However, the CICS/VS installation
may wish to take full advantage of the extensive data base support
provided by DL/I, by using the aFpropriate CICS/VS-Dl/I Interface
feature.
196
CICS/VS system/ApFlication Design Guide
CHAPTER 6.
CICS/VS ADVANCED FEATURES
This chapter describes task control, interval control, and some of
the facilities provided to CICS/VS application programs.
A number of facilities are provided to CICS/VS application programs
for:
• Immediate creation of tasks
• Task priority change
• Enqueue/dequeue resource allocation
• Terminal read timout
• Isolated task paging
• Automatic task initiation at a future time
• Wait for completion of a time event
• Cancel a future time event
These facilities are provided by the task control program and the
interval control program of CICS/vS. They are described in more detail
in the CICS/VS Application Programmer's Reference Manual, SH20-9003.
TASK CONTROL
Task control allows CICS/VS application programs to attach new tasks
for execution, if required. This may be done either by the automatic
task initiation feature of transient data intrapartition queues, by
time-ordered initiation (see "Interval Control," below), or by explicit
use of the task control ATTACH macro instruction issued by an
application program. The ATTACH macro instruction identifies the
transaction code corresponding to the program to be executed. This
program is initiated in exactly the same way as if a terminal
transaction with that same transaction code had been received. The
task attached competes for execution with other concurrently executing
tasks based upon its task priority, which is determined from the
transaction priority.
priority Change
During the execution of a task, the task priority may be altered by
use of the task control CHAP (change priority) macro instruction. The
priority may be set to any priority value between 0 and 255.
A normally
low priority executing task may temporarily change itself to high
priority (possibly during a section of logic which may involve updating
of data sets) and then later change itself back to its previous low
priority, if necessary, through use of the task control CHAP macro
instruction.
The use of the change priority facility enables data set
updating (for example) to be com~leted in the shortest possible time.
Alternatively, a task may execute initially in high priority, and then
may be able to complete its execution in low priority.
Chapter 6.
CICS/VS Advanced Features
191
The use of the task control CHAP macro instruction, without
specifying a priority value, enables control to be released by a task
to allow any high priority task which is ready for execution to gain
control of the cpu.
It is equivalent to issuing a task control WAIT
macro instruction, and causes a task switch. This should be utilized
if a tas]{ involves a considerable amount of CPU processing, to ensure
that it does not monopolize the cpu and prevent other tasks from gaining
control of the cpu.
The task control WAIT macro instruction functions in a similar
fashion 1:0 the DOS/VS or OS/VS WAIT macro instruction, enabling a task
to wait ()n completion of a single event or one event in a list of
events. However, the WAIT may first result in task switching to another
CICS/VS 1:ask which is able to process. Only if no CICS/VS task is able
to process is control passed to another DOS/VS or OS/VS
partition/region.
Terminal Read Timeout
This feature allows the user to specify a timeout limit for a
conversat:ional transaction when the transaction is waiting for a
terminal input message. This keeps a single transaction from occupying
system rE!SOUrCes for long periods of time while waiting for a reply
from the terminal.
Isolated Task Paging
This option allows the user to participate (with the operating
systems page manager) in selecting pages to be made available for
pageout.
When the TCA storage of a private or long running task is
acquired by task control, a number of additional pages may be acquired
as specified by the ANTICPG operand in the task's PCT entry.
Task
control makes these pages available for pageout when the task waits
for a response from a terminal, and causes them to be asynchronously
paged in when the task is to be given control after the response has
been received.
This allows pages occupied by data areas belonging to
conversational tasks to be paged out faster than the normal paging
process.
Enqueue/D~eu~
Task control provides ENQ and DEQ macro instructions for other
CICS/VS modules and application programs to enqueue and dequeue on
various resources.
An enqueue and dequeue facility is often necessary in a multitasking
environment, to ensure that only one task is able to utilize a
particul a:r resource at a time.
In the case of the potential concurrent
updating of records in a file control data set, file control utilizes
the task control ENQ and OEQ macro instructions to ensure that the
first task that retrieves a particular record for update is given the
exclusive use of that physical record. A second or subsequent task
which also wishes to update that same physical record while the first
task is s~till in the process of updating it, is prevented from carrying
out its update. When the first task has completed its update, and is
dequeued :from exclusive control of that record, the next task is given
exclusive control of the record through the ENQ macro instruction.
It
carries out its update until it has completed, and then is dequeued
from that record.
198
CICS/vS system/Application Design Guide
INTERVAL CONTROL
Future Task Initiation
Tasks can be initiated at a future time, based on either an elapsed
period of time or a specific time of day. These future tasks can be
initiated either with no data transfer through the use of the interval
control INITIATE macro instruction, or with data transfer through the
use of the interval control PUT macro instruction.
The INITIATE macro instruction enables a task to be attached at a
future time. A unique time request identification can be allocated to
that INITIATE macro instruction, to later identify that request if it
is necessary to cancel the request before the task is initiated.
The use of the interval control PUT macro instruction also allows
a task to be initiated at a future time, based on elapsed time or time
of day, and specify data to be transferred to that task. Temporary
storage is used to record the data to be passed to the future task.
This time request is given a unique identification, and data which is
to be transferred to the future task is written by interval control to
temporary storage for each interval control PUT macro instruction which
is executed.
Chapter 6.
CICS/VS Advanced Features
198.1
When the future task is initiated. its data may be retrieved from
temporary storage by the aFplicaticn program issuing an interval control
GET macro instruction. Subsequent GET macro instructions will retrieve
each reccrd which was initially FOT to temporary storage for the future
task, until all expired records have been retrieved.
This facility is useful when designing online aFplications, to ensure
that particular application events which must cccur at a specific time
of day, or after a specific elapsed time following scme other
application action, can be initiated automatically. However, procedures
must be developed during online systEm design to cancel these future
application events, if necessary for the application. Generally,
canceling of future events wculd be placed under centrol cf the master
terminal operator, through user-written programs which are given the
same security code as that allocated to the master terminal operator.
Application prograas Day need to wait on completion of a specific
period of time or until a specific time of day occurs. This can be
achieved by the use of the interval control WAIT macro instruction,
specifying the request identification of the original interval control
macro instruction which specified the particular time requ~st.
The use of an interval control WAIT macro instruction will utilize
CICS/VS resources (such as dynamic storage for residence of the
particular program and associated arEas), until the WAIT is satisfied.
Accordingly, the IAIT macre instruction should not be used unless the
time duration is only a matter of seconds. If it is necessary for a
longer duration wait to te in effect, this should te achieved by
initiating a future task at some short interval of time before the time
event to be waited on expires. This future task may issue the interval
control WAIT macro instructicn tc wait for completion of the specified
time event, and so ensure that CICS/VS dynamic storage is tied up for
the shortest possible time. To minimize the effect of utilizing these
resources, that future task should occupy as little storage as possible.
Application programs may also request the time cf day through the
use of a CICS/VS interval control GETI!E macro instruction.
As indicated Freviously, it may be necessary for future time events
to be canceled. This is best achieved by user-written aFFlication
programs which issue the irterval control CANCEL macro instruction,
specifying the time event request identification fer that event to be
canceled. Ideally, these canceled transactions should te placed under
control of the master terminal o~erator, by allocating a security code
to thetransacticn code so tbat it can be utilized only by the master
terminal operator.
Chapter 6.
CICS/VS Advanced Features
199
This chapter does not provide specific CICS/iS ferformance
information, tut instead discusses the various factors which should
be considered to ensure adequatE online performance fer applications
executed under centrol ef CICS/VS. It descrites various facilities
provided by CICS/VS for the evaluation and im~rcvement of online
performance and details hew these facilities can be used to vary
the working set of CICS/iS, and hence its demands for real (main)
storage. This chapter, particularly "Nucleus Load Table," is
recommended reading in its entirety for all CICS/VS users.
APPLICATION DESIGN
Good application design will ensure that the amount of information
to be transmitted between terminal operators and CICS/VS is ke~t to
the minimum required by the application. In addition, good design
ensures that only that informaticn reguired for the application is
retrieved from data sets, and possibly updated. The objective of
Chapter 11, "Ap~lication Design," is to assist the CICS/VS system
designer to develop applicaticn specifications which will result in
satisfactory online perfcrmance.
f!ESSAGE tESIGN
The amount of informaticn to be transmitted by the terminal operator
to the CPU and the amount ef infcrmation transmitted back from the CPU
should be kept to a minimum. Most efficient utili2ation of dynamic
storage fer cenversational tasks Day be achieved ty limiting, where
possible, the use of the CICS/iS terminal control BEAD or GET macro
instructions, or the Bf!S IN macre instruction, if it takes several
seconds for a terminal operator to enter the relevant data. Instead,
use should be made of temporary tran£action codes (see Chapter 3), or
entry of transaction codes by the terminal operator. This will permit
the dynamic storage occupied by the ~rograa waiting for terminal input
to be utilized fer ether pur£cses, if the transaction load requires
it. When the terminal input is received, the pregram required to
process it is then initiated as for any other CICS/iS task.
Use the versatility offered by the various programmable controllers
to perform data editing and message formatting prier to transmission
to CICS/VS.
PROGBAf! DESIGN
CICS/VS application programs may te modular, and may contain only
that code necessary to precess a particular transaction. Code not
reguired in every case fer the precessing of a transaction, such as
exce~tion routines or error routines, may be incerporated in separate
modules.
Chapter 7.
CICS/VS Performance Considerations
201
However, the a'Dount ef ~rcgra& modularity should not be extended so
far that it requires too many apflication programs to be loaded to
process the information in a particular transaction. The need to
transfer control (XeTL) or link (LINK) to many application programs in
processing each transaction ~ill add extra processing overhead to the
potential response time, because of the need to search larger tables,
dynamically allocate more register save areas for LINK macro
instructions, or dynamically load application prcgrams frcm the CIeS/VS
program library if they are net rresently resident. It Day also
increase virtual storage paging activity (see "Virtual Storage
considerations" later in this chapter) •
DATA BAS£ DESIGN
One of the mcst important factors in the design of online application
programs is the data base design. The factors identified in Chapter
5 should be considered when determining the apprcpriate data base
support. The particular supfcrt selected is a function of the
application requirements, ameunt of logically related information,
degree of data independence and reduction in data redundancy, the number
of file accesses necessary to retrieve and possitly update the required
information, and the amount cf main storage in the system to support
the CICS/VS applications.
The mere file accesses that are necessary to retrieve information
the 10ng4:r is the potential response time. The number of file accesses
necessary in following a logical chain of information across data sets
using thE~ indirect access feature ef CICS/VS file control may be quite
extensivE: in many applications. The utilization of a segmented data
base support, such as that provided by the CICS/VS file centrol
segmented record feature, and by the DL/I products, may be instrumental
in reducing the amcunt of file accessing necessary. However, the use
of complE;x logical relationships with DL/I may involve additional file
accesseso
DYNAMIC STORAGE
One of the most significant resources in ensuring adequate online
performance and respense time is the availability of dynamic storage
for program execution.
A formDula is provided in the ~!~L!~ ~~D~~Al lDfo~mati~D ~!nY!l
to enable dynamic sterage to be estimated. The amount of dynamic
storage required is a functicn of:
(~~)
• The maximum number of tasks that are active at any instant in time
• The amount of information to be
the terminals
transmitte~
tetween the CPU and
• The storage required by application programs needed to process the
transaction information
• The additional storage required foz file input/output areas, file
work areas, temporary stcrage requirements, and working storage
areas
The amount of dynamic storage allocated should te consistent with
the degree of multitasking tc be supported (see "Multitasking" in this
chapter) ~ It shculd alsc be large enough to prevent any eICS/VS short
on storage (SOS) situations from occurring. Such a situation occurs
when the storage cushion has been released to satisfy storage requests,
and subsequent storage requests EIcEed the remaining storage in the
202
CICS/VS System/Application DEsign Guide
cushion. In this instance CICS/VS will temporarily stop inviting
terminals to send input messages until sufficient storage has been
released by active tasks to reestablish the storage cushion. Terminals
will then be invited to send input cnce more. The effect of the SOS
condition then is to temporarily degrade the acceptance of input until
the condition disappears. If insufficient dynamic storage is allocated,
and SOS occurs, performance may degrade.
It was suggested with previous versions of CICS/VS that SOS be
permitted to occur occasionally, by allocating only sufficient dynamic
storage to satisfy average transacticn loads. At ~eak transaction
loads, SOS could be useful tc control the arrival of transactions for
processing by the cpu. This technique is not recommended for use with
CICS/VS, since an SOS condition can result in virtual stqrage
performance degradation. It can be avoided by allccating a sufficiently
large virtual stcrage partition/regicn to result in a large dynamic
storage area, or by reducing the maximum tasks value used by CICS/VS
(see "Multitasking" later in this chapter). The CICS/VS statistics
indicate when SOS occurs.
The dynamic storage area should also be large enough to avoid
excessive applicaticn prcgrau loadingfroa the CICS/VS program library,
but not so large as to result in the generation cf a largE number of
page faults in a virtual storage environment The amount of dynamic
storage allocated, and hence the virtual partition size, is chosen
based upcn:
• The storage required, using the formula from the CICS/VS §IM
• The amount of multitasking tc be used
• The amount of contention for real storage by CICS/VS and other
partitions
The optimum CICS/VS virtual partition size is dependent upon the
paging characteristics and storage reference patterns of CICS/VS and
its application programs, and also the type cf ccncurrently executing
batch applicatien prcgrams. While the CICS/VS virtual partition and
dynamic storage size can be estimated as descr,ibeo above, the contention
between CICS/VS and batch prcgrals fer real resources (such as main
storage, CPU computing capability, channels, and oisk file arms) must
be determined. In many cases, benchmarking the particula'r CICS/VS
online application with specific batch progralls &ay be appropriate.
Previous versions of CICS recommended that transaction processing
storage te requested in small amcunts, be acquired only when needed,
and be released as soon as pessible. with CICS/VS, several separate
requests for storage should be consolidated, so that a larger area is
acquired to satisfy the individual requirements frcm that area. This
has the advantage of localizing storage references, and so reduce the
possibility of page faults.
Alternatively, storage should te preallocated in the TWA when the
TCA for each task is created by CICS/VS. The TWA for each transaction
code may be specified by the user when the PCT "is generated.
MUlTITASKING
The ability of CICS/VS to per_it up to 999 tasks to be processed
concurrently can enable efficient resource utilization to be achieved.
As soon as a transaction reaches the CPU froll a terminal, CICS/VS
endeavers to create a task tc CODmence processing that transaction as
soon as possible. When the task has to wait on the completion of an
event, such as an I/O access, ancther task which is able to continue
Chapter 7.
CICS/VS Performance Considerations
203
processing is given control of the system. Although no Frov1s1on is
made by CICS/VS to enable a task tc continue processing while an I/O
operation is in process for that same task (except for VTAM terminal
I/O operations sFecified for immediate execution and asynchronous
journaling activity - see "Jcurnaling" in Chapter 8), the multitasking
capability enables other tasks to execute while that task is waiting
on the ccmpletion of an event.
Multitasking permits many transactions to be processed concurrently
and efficiently, with the result that a much s.aller range of response
times is achieved than if cne transaction were processed at" a time,
that is, in single-thread precessing_ with single-thread processing,
if three transactions reached the CPO at the sa~e time and each required
one second for processing, the transactions would be processed one at
a time. Thus the first transactien would have a response time of one
second, the second transacticn wculd have a response time of two
seconds, and the third transaction would have a response time of three
seconds. If, however, 50 transactions reached the CPU at the same
time, with this example the spread cf response times would range between
one second and 50 seconds.
Even though the time for Frocessing of each transaction may be
slightly increased over that achieved with single-thread processing,
the net effect is a reduction in the range of response time. This is
very significant to the overall ~erformance of a heavily loaded system.
The degree of multitasking (the "maximum tasks" value) to be carried
out by CICS/VS can be specified by the user, either at CICS/VS
initialization time, or dynamically during online execution by the
master terminal cperator.
(See the Cl~~L!~ Syst§J! !gl!ini§:!:~si2~!§
Guid§, SH20-9006.) While a large maximum tasks (MAXTASKS) value can
rednce the range ef respcnse times, an unnecessarily large value can
increase the number of virtual storage pages utilized by CICS/VS. This
can affect the a II-aunt of pag ing acti vi ty carried out by the CPO, and
is discussed further in "CleS/VS iorking Set" later in this chapter.
PRlOElTY PROCESSING
A further factor which affects the processing time and response time
of individual transacticns is the degree to which the priority
processing facilities of CleS/VS are utilized. In an environment in
which the transaction load is such that there may be several
transactions concurrently in process, certain transactions or tasks
may be given a higher priority for execution than ether transactions
or tasks. Thus, in DOst instances in which a high priority and a low
priority task are able to continue processing, the high priority task
is given control of the CPO ever the lew priority task.
Task priority can be set as described in Chapter 4, by the sum of
the allocated terminal priority, o~erator priority, and transaction
priority. The terminal and/cr tIansaction priorities may be dynamically
modified during eleS/VS operation by the master terminal operator (as
described later under "Syste. Centrol Changes") to reflect the changing
significance during operation of various application transactions or
terminals.
The various factors which influence the performance of online
applications under eleS/VS have teEn discussed abeve. The determination
of the actual performance achieved in an operating environment, and
the variation of the eleS/VS system to improve performance, is the
function of the system administrator.
204
eleS/VS System/Applica tion DI3sign Guide
SYSTEM ADMINSTRATION FUNCTIONS
The system administration, monitoring, and control of the online
system are generally functions of the CICS/VS master terminal operator
in the installation. An installation may allocate a terminal, ideally
a hard-copy printer, to the master terminal operator such that automatic
messages directed to his attention by CICS/VS may be immediately
printed.
While the master terminal operator may sign on at any CICS/VS
terminal, it is usually desirable for the installation to provide a
specific master terminal. This may be a hard-copy terminal such as a
2740 Communications Terminal or a video terminal such as a 3270
terminal, with either a 3277 or a 3275 display station and a 3284 or
3286 printer for master terminal messages.
A number of monitoring and control functions are available to the
master terminal operator. These will now be discussed.
operating Statistics
The master terminal operator can request particular CICS/VS operating
statistics or all CICS/VS operating statistics.
(see the CICS/vS System
Administrator's Guide, SH20-9006.)
These requests can be made at any
time. CICS/VS will output the various statistics which have been
accumulated since the last time they were requested.
Optionally, the CICS/VS automatic statistics feature can be used to
get statistics on a regular interval basis and have them printed in
interval and/or summary format.
Some of the statistical information maintained includes:
• Maximum number of tasks for any time period
• Number of times at the maximum tasks value
• Number of tasks initiated
• Maximum number of active tasks in system for any time period
• Total number of ATP transactions
•
•
•
•
•
Total number of ATP batches
Number of storage acquisitions
Number of times storage cushion is released
Number of times storage request is queued
Number of times storage queues were established
• Maximum number of requests in the storage queue
• Number of times each transaction was used
• Number of times each transaction was stall purged
• Number of times each transaction required storage in addition to
the specified anticipatory paging amount
• Time (in seconds) that elapsed while the first search of the PCT
was made for each transaction used
Chapter 7.
CICS/VS Performance Considerations
205
• Number of times a program is used
• Time (in seconds) that elapsed while the first search of the PPT
was made for each program used
• Total number of storage dumps
• Total number of storage dump 'irite errors
• Number of polls issued per line
• Number of input messages per terminal
• Number of output messages per terminal
• Number of transmission errors per terminal
• Number of transactions per terminal
• Number of transaction errors per terminal
• Number of pipeline messages discarded
• Number of groups of pipeline messages discarded
• Maximum length of a group of discarded pipeline messages
• Maxi.mum number of VTAM RPLs posted in RPL pool
• Tota.l number of times that maximum number of RPLs was reached
• Number of times VTAM was short on storage
• Number of READ requests per data set
•
Number of WRITE update requests per data set
• Number of WRITE adds per data set
• Number of READs from overflow area per data set (ISAM only)
• Number of times each individual segment in a segmented record data
set is operated upon
• Total number of tasks required to wait for a VSAM string per data
set
• Highest number of tasks requi.red to wait for a VSAM string per data
set
• Total number of DL/I requests of each type (GU, GN, GNP, GHU, GHN,
GHNP, ISRT, DLET, and REPL)
• Number of WRITES or READS (per data set) to extrapartition data
sets
• Number of WRITEs or READs
sets
(pE~r
• Numlber of temporary storage
data set) to intraparti tion data
l~ecords
PUT/PUTQ to main storage
• Number of temporary storage PUTs to unique IDs
• Max:imum virtual storage used for temporary storage records
206
CICS/vS System/Application Design Guide
•
For each journal:
a. Number of records written
b. Number of blocks written
c. Number of times the buffer was full
d. Number of times the block was shifted up
e. Average output block size
This statistical information is necessary not only to indicate the
actual performance of the CICS/VS system during operation but also
for management's planning for future system growth. The ~tatistics
are useful to:
• Help the system programmer determine that efficient data set
allocation has been made
• Aid the system programmer in choosing programs to be made
permanently resident during system initialization processing, as
opposed to those programs CICS/vS is to load dynamically
• Determine the activity of terminals and transactions
• Reorder the sequence of entries in various CICS/VS tables, to ensure
that the most active entries are toward the top of tables and thus
minimize table scanning
• In general, determine if the resources of the system are being
effectively used
statistics concerning DLII DOS/VS data base accesses are collected
by DL/I rather than by CICS/VS. In addition, DL/I DOS/VS provides
utilities which may be used to produce reports of these statistics.
IMS/VS DL/I also collects statistics. In addition, the
CICS/OS/VS-DL/I interface maintains statistics in the file control
table for the following DL/I CALL functions: GU, GN, GNP, GHU, GHN,
GHNP, ISRT, REPL, and DLET.
performance Monitoring
The statistics described above are particularly useful for the system
administrator or master terminal operator, to monitor the overall
performance of CICS/VS, and also to vary the working set of CICS/VS
(see "CICS/vS Working Set" later in this chapter.)
If the statistics indicate that the maximum number of tasks in the
system for any time period approached the maximum tasks value allocated,
some improvement may be realized by increasing that maximum tasks value.
However, if the maximum number of tasks in the system for any time
period is significantly less than the maximum tasks value, that value
should be decreased to the maximum number of tasks indicated by the
CICS/VS statistics. This may result in improved virtual storage
operation.
(The maximum tasks value can be varied dynamically by the
master terminal operator, as described in "System Control Changes"
later in this chapter).
If the storage cushion has not been released and a storage
has not been established, there is sufficient dynamic storage
to maintain a higher degree of multitasking, if required. On
hand, if the storage cushion has been released frequently and
Chapter 7.
queue
available
the other
storage
CICS/VS Performance Considerations
207
queues have also been established frequently, perhaps approaching the
total number of storage acquisitions, insufficient dynamic storage has
been allocated to enable effective operation of the online applications.
statistics on the number of transmission errors per terminal may
indicate a possible failing line or terminal which may require
maintenance. Similarly, a large number of transaction errors per
operator or terminal may indicate inadequate operator training.
CICS/VS statistics may be reset by the master terminal operator as
desired. The master terminal operator may also specify that they are
to be written out periodically and then reset. For example, it may be
desired to output the statistics every 15 minutes. These statistics
are directed to the transient data. destination CSSO, which may be
defined or as an extrapartition de:stination such as a tape, or disk.
A CICS/vS-supplied edit program can be used to produce a formatted
report of the statistics to illust.rate changes in the system environment
by time.
The CICS/VS Performance Analyzer Field Developed Progra.m (Program
No. 5798-'AZN) may be used to measure the performance of tasks executed
in the online system. Refer to "Related Publications" in the Preface
for relevant publications.
This feature allows the user to tune the CICS/vS system by
controlli.ng the mix of transactions within CICS/VS. Without this
feature, all transactions initiated within CICS/VS are considered equal,
and one t.ransaction type can dominate the system.
(For example, a
broadcast. to all terminals would flood CICS/VS with transactions until
the broadcast was complete and prevent terminal operators from
performing any useful work.)
The class max task feature also allows resource balancing within CICS/VS
by limiting the number of transactions allowed to run concurrently.
CICS/VS supports ten transaction classes (1 through 10). The function
of the classes is at the discretion of the user. An example of the
use of the transaction classes is:
Class 1 -
Inquiry only transactions.
Class 2 -
Update or add transactions.
Class 3 -
File browse or weighted retrieval transactions.
Class 4 -
Auto-initiated tasks (such as ICP or TOP initiated).
Classes 5 throu9h 10 - Could be used to group
tran~actions ~ith sim~lar working. set sizes by
work1ng set S1ze. Th1s feature, 1n conjunction with
Isolated Task Asynchronous Paging, can be used to
control paging load in CICS/VS through use of a data
area swapping technique.
,!his fE~atu::e ~llows the user to tune the system by controlling the
pag1ng ra't:e w1th1n CICS/VS. It provides a tuning tool for CICS/VS
conversational systems where max task cannot be less than the number
of terminaLls in the system.
The user can specify a max active task value to CICS/VS in the system
initialization table, or as an over:ride at start-up time. The master
208
CICS/vS System/Application Design Guide
terminal program can also change the max active task value.
(See the
system Programmers Reference Manual, Order Number SH20-9004 for
additional information.)
System Control Changes
Based. upon the CICS/VS operating statistics provided to the master
terminal operator, either on request or at system termination, he may
monitor the performance of the online system.
He may wish to make
changes in various significant areas of the CICS/VS online system to
attempt to improve its performance. The master terminal operator can
also dynamically vary system parameters, as well as change the status
of lines and/or terminals and/or data sets. All processing for master
terminal operation is controlled by conversational terminal interaction,
using the master terminal transaction CSMT.
(See the CICS/VS system
Administrator's Guide, Order No. SH20-9006.)
Some of the system control functions which the master terminal
operator is able to carry out include:
• Altering transaction and/or terminal priority
• Disabling and enabling various table entries (PPT, PCT, FCT, OCT)
• Placing terminals in-service or out-of-service
• Dynamically listing active tasks
• Purging active and suspended tasks
• Dynamically opening or closing selected data sets
• switching to an alternate dump data set
• Increasing or reducing the maximum number of tasks which will be
processed concurrently by CICS/vS
• Changing the storage cushion size
• Acquire and release VTAM terminals to establish CICS/VS-terminal
sessions
Of the functions detailed above, the modification of the maximum
tasks value and of transaction and terminal priorities may have most
effect on overall online system performance.
In addition, the ability to dynamically list active tasks may enablE
certain long executing tasks which are tying up system resources and
dynamic storage to be identified, and if required, to be purged
(abnormally terminated) under control of the master terminal operator.
This will enable the resources being utilized by those long-running
tasks to be freed for use by other tasks.
CICS/DOS/VS SUBSET OPTION
The subset option of CICS/DOS/vS does not support the following
CICS/DOS/vS facilities.
• Program Control - Dynamic program loading
• Interval Control - Except for system stall detection and runaway
task control
Chapter 7.
CICS/VS Performance Considerations
209
• Terminal Control - Terminals other than 3270, 2740, 2741, sequential
terminals, and CPU console
• File Control - Automatic logging
• Transient Data - Automatic loqging
• Temporary storage - Auxiliary storage residence
• Journal Control
• Sync Point Management
• supervisory Terminals
• Asynchronous Transaction Processing
• BMS Terminal Paging
• BMS Message Routing/Switching
• Syst 49m Recovery - Partition abnormal termination interception
• Emerqency Restart
• Systf9m Log/Journal Utili ties
• 2260 Compatibility
• Built-in Functions
Removal of this support reduces the working set of CICS/DOS/vS
substantially. Refer to the subse~ User's Guide (DOS), Order No.
SH12-540n for further details.
VIRTUAL
~)TORAGE
CONSIDERATIONS
CICS/VS executes in a virtual storage environment under control of
OS/VS1, or OS/VS2.
A number of factors must be considered in
the virtual storage environment to ensure that optimum online
performance is achieved, consistent with satisfactory batch program
performance.
~OS/VS,
With ine availability of virtual storage on System/310 computers,
the funct:ion of main storage (that is, real storage) in a computer has
been changed from an essential resource, necessary to enable various
programs to execute, to a performance resource.
The majority of applicaticn programs can execute in a virtual storage
environm€mt regardless of the size of the program or the amount of real
storage available.
However, the more real storage available, the less
the amount of paging which must be carried out by the virtual storage
supervisor to enable that program to execute. Because each page fault
represent~s I/O and CPU execution overheads, the real storage available
for execution of virtual storage programs should be sufficiently large
as to minimize the number of page faults necessary.
The page pool is the total real storage available to all partitions
or regions, after operating system requirements are met.
It is
difficult. to change the size of the page pool without adding more real
storage.
In many cases, the adequacy of the page pool cannot be
210
CIC'S/VS system/Application Design Guide
effectively determined without benchmarking the batch programs and
CICS/VS together and evaluating performance (as measured by response
time for CICS/VS, and as measured by throughput for the batch programs)
as the demands on the page pool vary.
The size of the page pool necessary for satisfactory performance of
the CICS/VS applications together with concurrently executing batch
programs is very dependent on the "working -sets" of all the programs
operating concurrently. The working set of a program is the number of
page frames (the amount of real storage) required by that program at
any given point in time.
Performance degrades or improves in direct
relation to the amount of contention for the page pool caused by the
working sets of all the concurrently operating programs.
To determine the factors affecting total performance, CICS/VS and
its working set on the one hand should be balanced with the rest of
the system and its working sets on the other. As the working set of
CICS/VS is increased, the available real storage for the rest of the
sys~em is decreased, possibly degrading the performance of other
operating programs. The converse is also true.
It is the user's
responsibility to determine the number of partitions or regions to be
used and the best mix of batch programs to operate concurrently with
CICS/VS.
Those factors which affect the working set and performance of CICS/VS
will now be examined.
• VSAM Shared Resources
(CICS/OS/vS Only)
VSAM shared resources enable the real storage requirements for VSAM
control block and buffer resources to be reduced. This results in a
reduction of the working set of CICS/vS.
Shared resources permit
efficient utilization of storage in an environment in which many VSAM
data sets are open and it is difficult to predict the amount of activity
against a given data set, or in a situation where each transaction may
access several VSAM data sets.
(See Chapter 5 for additional
information concerning VSAM shared resources.)
CICS/VS provides statistics to evaluate the effici,ency of resource
sharing.
If too few VSAM buffers or strings are available, tasks may
wait an excessive amount of time. If too many are available, real
storage may be being used inefficiently. The ~tatistics are calculated
by CICS/VS to provide the following information:
• Maximum key length
• Number of strings
• Size of buffers
• Number of buffers of each size
The effectiveness of these resources can be evaluated using the
following statistics:
• The highest number and total number of requests that had to wait
for the availability of a buffer according to control interval
sizes. This information may be used to change the percentage of
the maximum amount of resources required, or to specify the sizes
of buffers and number of buffers for each size to be allocated.
• The highest number and total number of requests that had to wait
for a string. This information may be used to change the percentage
Chapter 7.
CICS/VS Performance Considerations
211
of the maximum amount of resources required, or to specify the
number of strings to be allocated.
• The maximum number of strings active concurrently. This may be
used to change the percentage of the maximum amount of resources
required, or to specify the number of strings to be allocated.
• The number of successful read requests that were satisfied by data
that was already in the buffer.
• The number of buffer reads.
• The number of buffer writes.
The last three statistics may be used to change the percentage of the
maximum amount of resources required, or to specify the sizes and number
of buffers for each size to be allocated.
crcs/vs
~iVorking
set
• Activity
The mE~ssage rate, whi Ie not directly under the control of the system
programmf:!r, has the effect of increasing or decreasing the crcs/vs
demands on the system.
The batch processing load in other partitions
may need to be varied when the message rate increases at times of peak
online activity.
Throuqh the use of the MAXTASKS and/or AMXT parameters, the master
t.erminal opera tor can direct ly a ff:ect the amount of acti vi ty that
crcs/vs ~~ill attempt concurrently.
Each initiated task increases the
crcs/vs ~~orking set by the demands of the tas-k for dynamiC storage and
application programs. The MAXTASKS and AMXT parameters are tuning aids
for the system.
As discussed previously in this chapter, an arbitrarily large value
which siqnificantly exceeds the maximum number of tasks active in the
system for a given period of time (see "Performance Monitoring") can
result in unnecessarily high demands on real storage. This may result
in perfolEance degradation, if an inadequate page pool is available to
satisfy -these real storage demands. The user should vary the MAXTASKS
and AMXT values until he determines the best value for his
installa-tion's performance requirements and real storage availability.
At periods of low online activity, a method of controlling the
frequency of use of crcs/vs is by the use of the system partition/region
exit timE~ interval (rCV). A low rcv value causes control to return to
crcs/vs quickly with a strong possibility of the more frequently
utilized crcs/vs management routines remaining resident in real storage,
and thus also a strong possibility of improved response time. The lCV
value can be varied by the master terminal operator to meet high and
low ClCS/VS demands at times of differing online activity •
• Short-'I'erm and Long-Term Transactions
ClCS/VS enables transactions in the program control table (peT) to
be definE"d as being either short term or long term in execution.
Short--term execution transactions are allocated dynamic storage from
common pages. A page is utilized to satisfy the storage requests of
concurrently executing short-term transactions.
Pages are allocated
for concurrent usage by short-term transactions as required.
When all
the storage allocated in a short-term transaction page has been freed,
212
CICS/vS System/Application Design Guide
it is returned to a common CICS/VS pool of pages for use in satisfying
other dynamic storage requests. The storage required by a short-term
transaction is intermixed in pages with the storage required by other
short-term transactions.
On the other hand, all the storage required for execution of each
long-term transaction is included in one page (or more, if necessary),
-and each long-term transaction storage is kept separate from other
long-term transaction storage in different pages. If there are long
periods of inactivity for these long-term transactions, the pages in
which storage has been allocated for them may be paged out, if
necessary, to enable those page frames to be utilized for other
purposes.
Identification of short-term and long-term transactions is made by
the user in the program control table. If not specified for a
transaction, CICS/VS will default to a long-term specification for that
transaction. A large number of long-term transactions may result in
inefficient utilization of virtual storage pages, if those transactions
are in fact short-term. This will increase the CICS/VS working set,
and result in higher demands for real storage than would otherwise be
necessary, with possible performance degradation. The CICS/VS General
Information Manual, GH20-1280, and CICS/VS System Programmer's Reference
Manual, SH20-9004, describe the allocation of dynamic storage by CICS/VS
to various subpools, based upon the expected use of storage by the
application programs.
If insufficient dynamic storage is allocated, together with a large
maximum tasks (MAXTASKS) and maximum active task (AMXT) values, CICS/VS
will, in allocating storage for short-term transactions, encounter
short-on-storage (SOS) conditions. Accordingly, MAXTASKS and AMXT
values should be utilized consistent with the allocated dynamic storage
area, as discussed previously in "Dynamic storage" in this chapter.
Too large a value may result in a large number of SOS situations.
• Nucleus Load Table
The nucleus load table (NLT) is used by CICS/VS to control the load
order of the CICS/VS nucleus during system initialization. This enables
the user to vary the nucleus load sequence to reflect his installation's
use of various CICS/VS management modules, and to reduce the amount of
real storage required by CICS/VS. The purpose of the NLT is to allow
tailoring of the nucleus loading to provide the user with the smallest
possible working set for his particular environment.
The user should first identify those CICS/vS management modules most
frequently used by his applicaticn programs, and those less frequently
used, or not used at all. For example, the TCT, CSA, KCP, ICP, Tep,
and SCP are used frequently in polling terminals and servicing terminal
input. The PCT, PPT, and PCP are used when initiating task processing.
During execution, tasks may initiate activity in the FCP, FCT, JCP,
and JCT. Other management modules such as TSP, TDP, OCT, and BMS may
be referenced during execution. However, modules such as DCP, SRP,
SCR, and the SRT are only referenced to handle abnormal conditions,
CICS/VS dumps, or to intercept abnormal conditions and attempt recovery.
(See the CICS/VS system programmer's Reference Manual, SH20-9004, for
NLT examples.) Use of the NLT enables these modules to be sequenced
with all frequently referenced programs packaged together to reduce
the number of pages required, and may be page fixed in real storage if
desired •
• Application Load Table
Chapter 7.
CICS/VS Performance Considerations
213
The application load table (AL'I') is used to control the load order
of application programs. The application load table is an o~tional
feature in CICS/VS. If it is not used, application programs will be
loaded based on parameters in the processing program table. If the
applicatlon load table is used, the application programs specified in
the appl:lcation load table will be loaded first. Any programs in the
PPT not specified in the ALT will be loaded with the options specified
in the pJ:ogram processing table. Options such as page fix, page align,
page out, and so on, are available in the ALT.
• Page Fixing
The NIJT enables CICS/VS mcdules to be page fixed. By fixing these
CICS/vS management modules in real storage, their availability can be
assured when needed to ensure their responsiveness to requests fo:r
service from application programs.
In addition to fixing some CICS/vS nucleus modules, various
applicati.on programs which will be used frequently, or for which optimum
response is required, may be defined as being resident and may also be
fixed in real storage. This is specified in the program processing
ta hIe. 'I'hese fixed application programs are never paged out of real
storage.
Page fixing of parts of CICS/VS and of various application programs
may degra.de batch processing program throughput and possible CICS/VS
reponse times. These fixed page frames are available only to the
CICS/VS partition and, in effect, increase its working set. The net
effect is the reduction of the number of remaining page frames for
other partitions. When considerable contention exists for real storage,
this reduction of available page f:rames for use by other partitions
may significantly degrade the performance of programs operating in
those partitions and result in deactivation of low priority partitions
(see "Batch and CICS/vS Page Contention" later in this chapter) •
• Anticipatory Paging and T/P Balancing (CICS/OOS/VS only)
In a low volume online environment, batch program contention may
force mos't of CICS/VS to be paged out. To permit these pages to be
rapidly paged in again when needed, CICS/VS supports anticipatory paging
of CICS/VS nucleus modules.
The CICS/VS user may specify (using the NLT) various frequently used
modules w!hich are to be paged in when the CICS/VS partition is given
control by DOS/VS. These pages may have been paged out by DOS/VS to
satisfy the paging requirements of concurrently executing batch programs
in a low '~olume online environmento CICS/vS constructs a page-in list
and, as soon as it is given control, requests DOS/VS to page-in the
user-specified modules if they are not already in real storage. This
is called "anticipatory block paging," and is supported by CICS/OOS/VS
V1.0.1 or higher. It is not supported by CICS/OS/VS.
All paqes referenced in the pagE~-;i.n list are migrated by the T/P
Balancing feature of the 'OOS/VS supervisor to "most recently used"
status in its paging algorithm. Batch pages may have been paged out
to enable the referenced CICS/VS pages to be paged in. Batch partition
execution is permitted to continue if required. At this time, CICS/VS
may specify, using the NLT, certain infrequently referenced modules
which are to be paged-out.
CICS/VS modules can be paged out: at times of no activity until a
terminal 1:ransaction is received for processing. DOS/VS then pages in
blocks of pages identified by CICS/VS with minimum I/O activity. Batch
214
CICS/vS System/Application Design Guide
processing may be deactivated to ensure that CICS/VS has exclusive use
of all of the resources it needs. The result is consistent online
response time; the trade-off is possible reduced batch throughput.
Anticipatory block paging and T/P balancing of CICS/VS nucleus
modules should not be specified when CICS/VS is continually active, as
in a high volume online environment, because of the additional
processing overhead of anticipatory paging. In this case, the NLT can
be used to minimize the C!CS/VS working set. However, it should not
specify page-in or page-out for any modules. Normal CICS/VS and batch
program execution contend for the available page pool as in a normal
virtual storage environment.
If CICS/VS is executing in a dedicated environment without concurrent
batch execution, no benefit is gained by anticipatory block paging or
T/P balancing; it should not be specified in the NLT. Refer to the
CICS/VS system Programmer's Reference Manual for additional information
on anticipatory paging and T/P balancing using the nucleus load table •
• Nucleus Load Table Design
A default NLT is supplied by CICS/vS. This is documented in the
CICS/vS system Programmer's Reference Manual, SH20-900Q, together with
several examples of typical nucleus load tables. If the system
programmer wishes to design an NLT for his installation's environment,
the following factors should be considered:
• The use of BTAM and/or VTAM modules, and reference characteristics
reflected by terminal cow.munication activity
• Application program characteristics as reflected by use of CICS/VS
nucleus modules
• Individual nucleus module sizes
• Module grouping to minimize page faults
Use may be made of CICS PLOT, a Field Developed Program (Program
No. 5798-CCG), to determine the virtual and real storage usage of
CICS/VS and identify possible nucleus load table structures •
• Resident CICS/VS Application Programs
Application programs may be specified in the PPT as resident in the
nucleus or dynamically loaded (as required) in the dynamic storage
area. Resident programs are loaded with the CICS/VS nucleus at
initialization time, and are packed to occupy the minimum number of
pages. The PPT also provides facilities to define page alignment and
force pageout requirements for resident programs •. These options can
be used to improve the utilization of system address space.
When a program is selected for force pageout, CICS/VS issues a force
pageout command to the operating system when the program has terminated
processing and is no longer being used by the application program. The
force pageout command will include the complete page or pages occupied
(or partially occupied) by the program. The program will be paged out
by the operating system upon first occurrence of a page fault.
Dynamically loaded programs occupy unique pages in the dynamiC
storage area; a program occupies contiguous pages. Each program is
loaded on a page boundary and space at the end of a page is not used.
Consequently, dynamically loaded programs may increase the working set
of CICS/VS.
Chapter 7.
CICS/VS Performance Considerations 214.1
CICS/OOS/VS and its subset option permit execution using a DOS/VS
supervisor which specifies no asynchronous processing support (AP=NO).
see £!£§/DOS/vS operations Guide, SH20-9012. This reduces the size of
the DOS/VS supervisor by approximately SR. The 51< becomes available
as extra storage for the page pool. However, .if AP=NO is specified,
CICS/VS journal control facilities and the CICS/DOS/VS-DL/I DOS/VS
interface cannot be used.
• CICS/VS Generation options
As more CICS/VS generation opti.ons are selected, the size and number
of the management modules increase. As mentioned earlier, some of
these modules may be page fixed by the user, while others are always
pageable.. The CICS/VS working set will generally increase as more
generation options are selected. The user should therefore give careful
thought to planning his CICS/vS system generation.
The subset option (CICS/DOS/VS) defines an environment which
specifies only selected generation options for ease of use and
installa1:ion and for a reduced working set. Refer to "CICS/OOS/VS
subset Option" in this chapter for the CICS/vS facilities not
supported.
• Network Control System (NCS)
The user may wish to examine the relevance of NCS to his environment,
and its effect on the real storage ~equirements for his online
appl ications. Refer to "ReI ated Publication s" in the Preface for
relevant NCS publications.
• General considerations
The size of the CICS/VS dynamic storage area is an important factor
in considerations involving the CICS/vS working set, as identified
previously. The dynamic storage area increases as the CICS/VS virtual
partition size allocated by the user is increased, and the converse is
also true. Too small a dynamic storage area can cause frequent CICS/VS
program loading and use of the storage cushion, which may slow terminal
response due to a short-an-storage (SOS) condition. A large maximum
tasks value with a small dynamic storage area will also result in an
SOS condition, with subsequent performance degradation.
On the other hand, in the same online environment, too large a
dynamic s·torage area where there is considerable contention with other
partitions far the available page pool may increase the amount of
virtua I s'torage paging necessary. The most suitable dynamic storage
area for ·the user's environment can best be determined by varying the
CICS/VS virtual partition size and maximum tasks value in separate
runs, and evaluating their effect on both CICS/VS performance and the
performance of programs executing in other partitions.
Program residency in a virtual storage environment has a different
meaning than in a nonvirtual storage environment. Page fixing in
CICS/VS is equivalent to program residency in previous versions of
CICS. A l::"esident CICS/VS program is loaded when the CICS/VS system is
initialized, but can be paged in and out as needed. The user should
evaluate, in his own environment, the effect of specifying various
application programs as resident, and also as page fixed, on CICS/VS
performan(~e as well as on the performance of programs executing in
other pa r1:i tions.
214.2 CICS/vS System/Application Design Guide
The number and size of I/O areas used by application programs for
file and terminal I/O also have a direct effect on the CICS/VS working
set.
File I/O areas will be short-term page fixed for the duration of
the I/O operation. Terminal and line I/O areas, on the other hand,
are long-term page fixed while terminals are being invited to send
input.
In addition, all of BTAM and the TCT are page fixed at CICS/VS
initialization. The number and variety of different terminal types
supported by BTAM and VTAM in the user's environment increase their
real storage requirement, and hence the working set of CICS/VS.
CICS Dynamic Map (Program No. 5198-AXR), and CICS PLOT (Program No.
5798-CCG) Field Developed Prograros may be used to analyze virtual and
real storage usage of the CICS/VS partition during execution. Refer
to "Related Publications" in the Preface for relevant publications.
Batch and CICS/VS Page Contention
As discussed previously, the most significant impact on online and
batch program performance, executing.in a virtual storage environment,
occurs when there is considerable contention between the various
concurrently executing programs for available page frames in the page
pool. The extent to which the total pages required by all concurrently
operating programs exceeds the number of page frames in the page pool
is called the degree of "overcommitment." The degree of overcommitment
will determine the amount of performance degradation for both online
and batch programs. If the overcommitment of the page pool is too
great, such that the amount of paging necessary to enable various
partitions to execute exceeds certain limits (depending upon the virtual
storage operating system used), the particular operating system will
attempt to deactivate the lowest priority partition.
This situation
is called "thrashing." The page frames occupied by this deactivated
partition are made available for programs executing in higher priority
partitions. When the paging rate reaches an acceptable level again,
the lowest priority partition is reactivated.
Thrashing is a situation in which the demands made by various
partitions for real storage result in a high proportion of necessary
paging activity to enable the system to complete useful work. It is
temporarily alleviated by the operating system deactivating a low
priority partition to reduce the demand for real storage. Depending
upon the degree of overcommitment, reactivation of the low priority
partition by the operating system causes thrashing and subsequent
deactivation.
In this environment, the only permanent solutions to avoid thrashing
are either to avoid operating all programs together, or to provide more
real storage for use as a page pool.
virtual
~torage
Access Method (VSAM)
VSAM may be utilized by CICS/VS for support of temporary storage on
auxiliary storage. In addition, temporary storage is used to provide
the necessary support for the terminal paging and message switching
features of CICS/VS.
The temporary storage program can be generated specifying that
auxiliary storage residence is not to be used.
In this case, temporary
storage records reside in dynamic storage, and are paged into real
Chapter 7.
CICS/VS Performance Considerations
214.3
storage when referenced.
VSAM is thEn not required for support of
temporary storage.
(See the £l~~Ll~ Sl s !§! iI2gI§!B~!§ Ref§~
~g~ygl, SH20-9004.
However, it should be recognized that the use only of dynamic storage
for temporary sterage will increase the paging activity of the system,
depending upen the frequency of reference of temporary storage records
by CICS/VS application programs, er for terminal paging or message
switching.
This increased paging activity should be balanced against
that encountered when VSAM is used by temporary sterage for auxiliary
storage residence ef data.
CICS/VS file control enables VSAM data sets to te accessed by
application programs. Furthermore, the built-in weighted retrieval
function of CICS/VS can enly operate on VSAM data sets.
VSAM is the standard access method support utilized by DL/I.ENTRY
and DL/I DOS/VS.
It is also used ty IMS/VS tL/l fer the support of
advanced features such as variable-length segments and secondary
indexing.
The number of pages required ty various VSAM features can be
estimated frem the VSAM documentation. This infermation should be
utilized, together with ether information on CICS/VS, to evaluate the
contentien for the available page pocl between the CICS/VS working set
and the batch partitions.
DL/I
~OSL!~ g~~!2I~~£~
Refer to "Performance" in the ~ILl m!~L!~ ~§n§ral I.D!2~Dll.QJ! Manual
for a discussion of performance measurements carried out on DL/I DOS/VS,
and identificaticn ef the real sterage requirements of DL/I DOS/VS and
VSAM. DL/I DOS/VS, when used by CIeS/DOS/VS application programs,
differs from batch DL/I tOS/VS in thE online interface and program
request handler (approximately 8K bytes). The action modules are the
same as for batch.
To permit multithread access to data bases, DL/I DOS/VS uses one
PST (Program Specificaticn Table - the DL/l DOS/VS counterpart of the
CICS/VS TCA) and one PSB per DL/l task. This storagE, together with
that required by other DI/l control blocks, will determinE the amount
of real storage required for multithread accEssing by DL/I DOS/VS, and
hence its perferuance.
CICS/OS/VS--3850 MASS STCRAGE SYSTEM OPERATION
CICS/CS/VS enables the 3850 Mass Storage System to be used to support
massive data bases onlinE.
Applications which previously could only
be supported in a batch environment, or could not te placed on computers
at all because of physical size and/er cost limitations, can use the
3850 for online data base residence.
(See Chapter 11.)
Typical
applications include:
• Online residence of manufacturing engineering drawings and technical
reports
• Banking current account (checking) transaction history
• Medical and police data tases
• Legal report cases
Chapter 7.
CICS/VS PerformanCE Considerations
215
O!.§!:vie.!._ g!
38~,g 2R!IJ!i~l!
The 3950 transfers (stages) infcrmation from the 3851 8ass Storage
Facility to 3330 drives where it is accessed as needed. As the capacity
of the 3851 far Exceeds that of the available 3330 drives in an
installation, a virtual DASD storage algorithm is used. In order to
understand the performance implications inherent in the use of the 3850
in a DB/IDC environment, an analogy will be drawn between the use of
the 3850~ and the use of virtual storage by CS/VS.
The 3851 Mass Storage Facility contains from 35 billion 1 bytes to
236 billion bytes of data. this data resides on "virtual 3330 drives,"
analogous to virtual storage using OS/VS1 or OS/VS2. It represents a
third level of storage residence for data.
(CPU and DASD being the
first and second.)
When data in a virtual 3330 drive is referenced (either at CPEN
time, cr as a result of a seek and read), the 3850 first determines if
that data currently resides cn the "real 3330 drives" associated with
the 3850 ..
If it is resident on a real 3330, the data is transferred to the
CPU as if it was a normal read tc a 3330. This is analogous to a
program's reference to a virtual Fage which is currently in real storage
in the CPU.
.
If thE data is not currently resident on a real 3330, it must first
be staged from the 3851 to availatle cylinders in the real 3330
(analogous to virtual stcrage paging). The 3850 maintains tables to
indicate the location of virtual 3330 cylinders on the real 3330
cylinders (analogous to CS/VS sUFervisor page tables). A least recently
used algorithm is used tc select the most suitable real 3330 cylinders
to be used to contain the referenced virtual 3330 cylinders.
If the data presently in the selected real 3330 cylinders has been
modified, it must first he staged back to the 3851 (analogous to a
page-out operation). Following this, the referenced virtual 3330
cylinders can be staged in (analogous to a page-in) to the now-available
real 3330 cylinders. Once the data has been staged, it is available
for use as normal 3330 data.
The previous comments show the similarity between 3850 operation
and virtual storage operation. Factcrs which affect virtual storage
performance can also influence 3850 Ferformance in a DB/DC environment •
• Beal 3330 storage
The number of real 3330 drives associated with the 3850 is analogous
to the amount of real CPU stcrage in a virtual storage environment.
An overcommittment of real C~U storage results in virtual storage
paging, with consequent Ferfcrmance degradation. Similarly, an
overcommittment of real 3330 storagE results in 3850 staging. As the
3850 represents third level data storage, its staging time is measured
in seconds. Virtual storage uses 3330 or 3340 seccnd level storage
and has a paging time measured in milliseconds. ccnse~uently, the
effect of real 3330 overco8.ittment en performance is more apparent
with 3850 ..
216
CICS/VS System/ApFlication Design Guide
As the 3850 is transparent to applicaticn programs (such as
CICS/OS/VS), and appears as if it is a normal 3330, such performance
degradation seems tc the program as if a "long" seek is in progress.
A CICS/OS/VS application program is not aware of a possible need to
stage data from the 3851 tc 3330, and so cannot notify the terminal
operator of the amount of response delay expected. However, the
application Frogram should still notify the terminal operator of the
BQ~§~ili!l of a delay before the data base reference is made.
• Locality of Data Reference
Locality of reference in a virtual storage program reduces the
working set and hence real storage requirements cf that program.
Similarly, locality of data reference in a 3850 data base reduce$ the
data working set (and hence real 3330 storage requirements) of that
data base. Thus data bases ~hich have some sequential retrieval
requirements are well suited to 3850.
• Transaction Volume
High transaction volu.es in a virtual storage system increase the
activity of the systeD, and aay increase its locality of reference and
hence, paging activity. Similarly, high transacticn volumes with the
3850 increase the activity of the 3850, and may increase its locality
of data reference (access to different parts of the data base) and
hence, staging activity. High staging activity in the 3850 can also
result in queuing delays, which can increase sta9ing time.
• Frequency of Data Reference
Data which is referenced frequently will tend to remain resident on
3330 provided if sufficient real 3330 devices are available.
Infrequently referenced data Day be staged out.
(This is analogous to
paging out infrequently referenced virtual storage pages.)
• Data Binding
Data can be "bound" to real 3330 cylinders so that it cannot be
staged out, similar tc virtual storage "page fixing." Such bound 3330
cylinders, while ensuring ready availability of the bound data, reduce
the number of real 3330 cylinders available for staging, and so may
possibly increase staging activity for other parts of the data base.
• Batch Partition Activity
Batch partitions may use the 3850 to support data sets previously
held on tape files.
(The 3850 may hold data from thousands of reels
of tape.) Such "tape" data sets Day be completely staged from 3851 to
3330 at OPEN time, thereby using the 3850 as an automated tape library.
However, a request to stage a taFe data set may take minutes to
complete, and may delay a later staging request queued in proceSSing
a CICS/VS transaction. ThUS, as with virtual stcrage batch actiVity,
high volume batch partition staging activity may seriously degrade
online performance.
Chapter 7.
CICS/VS Performance Considerations
217
Based on the 3850 perfcraance ccn~iderations di~cussed previously,
typical 3850 applications can be iaentified. Such application~ .ay
exhibit some of the following characteristics:
• Large data bases
• low transaction volumes, if airEct access reguired
• Long responsE times
acce~table
• sequential retrieval of
secticn~
of the data base
• Primarily enqueuing, with limited update activity
• High activity against li.ited elements of thE aata base
• Limitea use of DL/l logical relaticnships across DL/I data bases
and aata set groups
Applications which meet these criteria includE information retrieval
applications such as technical, legal, and medical data bases containing
textual information. The STAIRS/VS Program Product (program No.
5740-XR1) can be used to sEarch a keyword index, established on""real
3330 drives, of documents stcrea on 3850. Based u~on keyword selection
criteria, documents can be rankea in order of relEvance. the aost
relevant documents can he selectEd and staged to 3330 for subsequent
printing. Refer to the ~%Jl~LI~ g~D§lAl !ni2~!!!1QD AlD»Jl (GH12-5114)
for further information.
Another typical application is theret~ieval cf banking current
account (checking) transactions. Such a historical data base ~xhibits
highest activity against the most recent transacticns for enquiry
purposes. This section cf the data base will tend to reside on 3330
due to its activity.
A Police Information SystEm (SEE Chapter 11) tYFically involves the
storage of massive aaounts ef information generally in a coded form to
reduce disk storage requirements. The 3850 permits textual information
relating to crimES and criainals tc be aaintainea online, and enquired
against (1I1sing STAIRS/VS for example).
As discussed previously, such information retrieval applications
generally exhibit low transaction volumes and arE well suited to the
3850 Mass Storage System. Banual retrieval techniques, or in some
cases batch processing against ta~e data sets, may be used currently
for these applications. ResFonsE tiaes fer information using these
techniques may be hours, or even days. The use of 3850 to store such
data bases online enables such response times to be reduced to minutes
or seconds.
DL/I DOS/VS performance may alsc be influenced hy segment intent
Refer to "UpdatES, Additions and DEletions wi tb DL/I in
Chapter 5 for an example of data base design to reauce the effect of
segment intent scheduling on DL/l Ferforaance. A eICS/VS application
program issues a DL/I scheduling call, identifying the PSBit wishes
to be scheduled against. It iSSUES a DL/l termination call when it
has completed its use of the PSB. (Eefer to ChaFter 4 of the nLLl
~!~ JRP.li~J!i9~ f~2g~~IJiI9 l!!§I§B~ IIBYA1.)
The period over
which a task is scheduled against a FSE should be kept as short as
possible by issuing the termination call at the earliest possible time.
This permits more effectiVE multithread access by DL/I DOS/VS, and
hence im~roved performance.
schedulin~J.
218
CICS/VS system/Application Design Guide
PERFORMANCE EVALUATION
Two main techniques may be utilized fcr performance evaluation.
• Simulation techniques
• Benchmark techniques
~1~Yl~1i~n I§£~Digy~§
Simulation techniques involve the develofment of simulation models
which describe the particular apFlication processing involved, CICS/VS
features utilized, transacticn loads for processing, allccation of data
sets, and machine configuratien. Simulation models may te developed
using simulation languages such as GFSS V (General purpose System
Simulator 'V--Program Product 5734-152(05), 5736-IS2(DOS», or CSS II
(Computer SysteD Simulater II--Prcgram Product 573Q-IS5(OS», or
analytical languages such as APL (A Frogramming Language--Program
Product 5734-IM6(OS), 5736-IM6(DOS».
simulation techniques are cnly apFroximations of performance and
are only as accurate as the input prcvided. If they model only the
CICS/VS partition environment, rather than the overall system together
with ccncurrently executing batch precessing programs, they will not
be able to evaluate the effect of those batch prcgrams on CICS/VS online
performance caused by page ccntention. However, the effect of a number
of different system design approaches on overall CICS/VS online
performance can be quickly evaluated to assist in the design process.
A more accurate perfor.ance evaluation technique is that of
benchmarking. Using this technique, dummy (or prototype) CICS/VS
application prograDs may be written to model the number and type of
file accesses involved in processing a transaction, and reflect the
amount of CPU precessing necessary, possibly by executing loops of
instructions to represent the expected CPU processing of the final
application programs when they are written. These du.my or prototype
application programs may then be executed with the generated CICS/VS
system to be used by the installaticn, and the CICS/VS statistics can
be examined to determine the performance of the system when executing
the type of transactions and particular transacticn volumes which will
be encountered in real life. Furthermcre, the effect of concurrently
executing batch programs, and different-sized page pools, may be
examined to evaluate their effect en the CICS/VS online application
performance. The CICS/VS Ferformance Analyzer Field Developed program
(Program No. 5798-AZN) Day bE used tc measure the perforDance of the
benchmarked system.
The transacticn volumes used for the benchmark should model actual
terminal activity as closely as possible. Use may be made of sequential
terminals such as card reader/line printer, disk or tape, or of actual
terminal input." If sequential terainals are used, time delays must be
introduced in the reading of transactions from such terminals to ensure
that the input rate approximates that of the system to be benchmarked.
Unless such delays are introduced, the rate ot input from such
sequential terminals may be significantly different from the actual
system being benchmarked, with a resultant difference in storage
reference patterns in a virtual storage environment, and hence different
performance. It should also te recognized that the use of sequential
terminals does not perDit .easurement of the effect of BTAM on the
performance of the online applications.
Chapter 7.
CICS/VS Performance Considerations
219
If input delays cannot te designed into the system to be benchmarked,
or if measurements using BTA! are required, the use of actual terminal
input may be more appropriate.
Using this technique early in the system desiqn process enables an
approximate evaluaticn of Ferforaance to be determined. Subsequently,
when the CICS/VS applicaticn programs which will be used in the
operational online system have been developed, these programs may te
substituted for the prototype prcgrams described above. The performance
of the actual system which will be utilized in an operational
environmE~nt can then be evaluated again.
At this time, too, the effect
of batch processing prcgraas and the size of the page pool on the online
application perfcrmance, and the effect of the aaount of dynamic storage
and degree of multitasking on online performance, can be further
evaluatea.
220
CICS/VS System/Application Design Guide
This chapter discusses the facilities provided ty CICS/VS in the
area of reliability, availability, and serviceability (RAS), and
describes various design techniques which may te adopted by the user.
It first examines various restart and recovery requirements of online
applications and identifies CICS/VS facilities which can be used to
meet those requirements. It identifies additional BAS facilities that
may be required ty some CICS/VS users and suggests design approaches
which may be adoFted by the user fcr their i.plementation. This chapter
is recommended reading, in its entirety, for all eICS/VS users. The
follcwing failure conditions are considered:
• Program failure
• Terminal failure
• Device failure
• CPU failure
Techniques for recovery of infcrmation following such failures are
discussed. The information covered includes:
• Temporary storage recovery
• Transient data extrapartition data set rECOVEry
• Transient data.intraFartition data set rEcovery
• File control data set recovery
• DL/I data base rEcovery
• Transaction recovery
Unless otherwise explicitly stated, the recovery procedures discussed
in this chapter apply to both CleS/DOS/VS and eICS/OS/VS, referred to
collectively as CleS/VS.
Two of the most significant aSFects in the design of applications
to execute under control of CleS/VS are the rECOVEry of the systea from
various errors and restarting the system after recovery. Depending
upon the complexity of the online application and the eICS/VS facilities
utilized, the design of recovery and restart procedures may represent
little effort on the part cf the design team or may be a major element
of the overall system design.
For example, for an inquiry aFFlication that cnly retrieves
information from data bases and dces net update that information or
add new information, recovery and rEstart generally involves
reestablishment of the CICS/VS system to its status at the time of
failure.
HoweVEr, for an online apFlication which retrieves information from
data bases, and updates, deletes, cr adds records to the data bases,
Chapter 8.
CleS/VS Eecovery and Eestart
221
the information which must be recorded by the system during normal
operation may be extensive. This information is utilized following a
system failure to recover the status of the varicus data sets and data
tases to a defined pcint, Euch that all necessary updates, deletions,
and additions up to that point have been completed. Recovery of such
an online update and addition apFlication can invclve considerable
system design effort.
Regaraless of the type cf application, the system design team should
consider the effect on the online application of each of the various
types of error or failure Eituaticns described in this chapter. The
team should determine whether any acticn is neceEsary to design
procedures which ensure that infcrmation necessary for recovery purposes
is recerded during executien.
Many online applicaticnE Frocess adequately with no recovery and
restart Frocedures. However, the value of a well-designed online
application containing recovery and restart ~rccedures is truly realized
when an error situation arises. Regardless cf how well a system is
designed' and debugged, failure situatiens will occur because of program
errors, data transmissien errors, l/e access errors, or system component
failures (such as CPU).
An enline system that allcws for error
situations and has recovery and restart procedures to handle them is
better atle to continue operation when errors occur.
A measure of the perfcr.ance ef an online system is its ability not
only to ~rovide s~tisfactcry res~cnse time, tut also to provide enline
access to applications from terminals over extended periods of time.
While error situations must inevitably occur, they sheuld not be
permitted to disrupt the availability ef online aF~lications for long
periods of time.
Good reccvery and restart design procedures can
minimize the amount of time a sYEtem is down following a failure.
They
can also minimize the effect of a system going dcwn at an unscheduled
point, by ensuring that the integrity ef any data sets or data bases
is maintained.
The iRportance of thorough design of recovery and restart procedures
has been emphasized earlier in this chapter. The next section details
the more common error or failure situations.
It provides an overview
of the recovery and restart suppcrt ~rovided by CICS/VS, and identifies
that support which may need to be ~rovided by user programming.
RECOVEBY FROM FRCGEAM EEEOBS AND AEINDS
CICS/VS intercepts program checks and system ABENDs through the use
of the system recovery prcgram (SRP). The SEP attempts recovery of
OS/VS ABFNDs identified in the system recovery table (SRT) as system
recoverable.
ABENDs may alse be specified in the SRT as being user
recoverable, in which case centrol is passed to a specified user routine
to attempt recovery.
The program centrel program intercepts prograR control ABENDs and
passes centrol te specified user-written program-level AEEND exit
routines, and to a user-written installation-level program errcr program
(PEP).
These routines may attem~t recovery cf the error condition,
ignore the ABEND and continue task execution, or record application
dependent informatien.
To prevent propagation of an error by the same transaction or program
at a later time, an option is previded by CICS/VS to permit the relevant
PCT and/or PPT entries te be dynamically marked as disabled or
inoperative ~f desired by the user). These facilities are utilized
by a design technique described in this chapter fer program backup.
222
CleS/VS System/Application teEign Guide
Partition/region ABENC processing is not suppcrted by the subset
option of CICS/DOS/VS.
RECOVERY FROM TEBMINAL I/C EERORS
Chapter 3 describes the use of a user-written installation-level
terminal error program (TEF) for recovery from terminal I/O errors.
It also describes technigues for dynamic terminal reconfiguration (by
user programming) following an unrecoverable ter~iral I/O error.
Techniques are discussed for use with ETAft-supported terminals and
VTAM-supported programmable controllers.
RECOVERY FROM DISK I/O EBRCRS
CICS/VS passes error indications to applicaticn prograas, identifying
the cccurrence of disk I/O errors. An installaticn-Ievel user-written
disk error program may be designed to obtain control following any disk
I/O error detected by an application program.
BECOVEEY FBOM DEVICE FAI1UEE
CICS/VS provides limited suppcrt for recovery from device failure.
Various facilities can be utilized by user-written routin~s to permit
recovery from many of these failures. Design techniques for such
user-written support are discussed in this chapter.
TERMINATION OF CICS/VS SlSTE!
CICS/VS supports both a ccntrclled shutdown and an unccntrolled
shutdown following sericus eIror situations.
A ccntrolled shutdown enatles CICS/VS to quiesce system activity in
such a way that currently active tasks are allowed to terminate
normally.
During controlled shutdown, information describing the operating
environment of CICS/VS at the time of termination. is recorded (by
CICS/VS) on the restart data set reserved for this purpose. This
information is referred to as a warm keypoint. It contains key system
information which will enable CICS/VS operation to be reestablished to
the same environment status as at ccntrol1ed shutdown. This
reestablishment of CICS/VS is referred to as a warm start, and is
discussed further.in following paragraphs.
An unccntrolled shutdcwn cccurs when CICS/VS is unable to quiesce
system operation to permit active tasks to terminate normally.
Recognizing the possibility of an uncontrolled shutdown occurring
at any time during operaticn, CICS/VS periodically records information
on system activity on the system log data set. System activity
information is referred to as an activity keypoint. It contains key
information describing the processing activity of the system at the
time of the keypcint, utilized on subsequent reinitialization of CleS/VS
to restore the system tables and to determine which tasks were still
active at system terminaticn (that is, in-flight tasks). This
Chapter 8.
CICS/VS Becovery and Restart
223
reinitialization of CICS/VS is referred to as an emergency restart,
and is discussed further in follcwing Faragraphs.
System logging is not sUPForted by the subset option of CICS/DOS/VS.
REESTABLISHMENT OF CICS/VS SYSTEM
CICS/VS operaticn may be reestablished following a controlled
shutdown, either as a cold start or a warm start, or following an
uncentrolled shutdewn as an emergency restart.
A cold start initializes CICS/VS system data sets and system tables
as defined during syste. generation. Cold start initialization of
CICS/VS is not influenced by previous system activity.
A warm start of CICS/VS enables iDfermation in a warm keypoint,
describing the previous CICS/VS cperating environment on a centrolled
shutdown, to be used to initialize system data sets and system tables.
The warm keypoint information is merged into the system during system
initialization, to restore system data sets and tables to their status
as they existed at the previeus CICS/VS ccntrolled shutdown.
An emergency restart enables CICS/VS to rebuild and initialize the
system to its status at the time of an uncontrolled shutdown. The most
recent system activity keYFoint recorded prior tc uncontrolled shutdown
is used to determine the activity status of CICS/VS at the time of the
keypoint. system activity keypoint and subsequent system activity data
recorded on the system log data set (such as user data set changes) is
used to determine those tasks which were still active (in-flight) when
uncontrolled shutdown occurred.
The activity of ccmFleted tasks, whose processing resulted in changes
to system and user data sets and te tables since the activity keypoint
was taken, is used to restore those data sets and tables to the same
status as they existed at cOlpleticn of those tasks prior to
uncontrolled shutdown. The activity of in-flight tasks, whose
processing resulted in changes tc system and user data sets since the
activity keypoint was taken, is used to back out the effect of
processing by thcse uncomFleted tasks. The affected data sets are
restored to the same status as it those tasks had never started
execution.
Emergency restart is not supported by the subset option of
CICS/DOS/VS.
TEMPOBARY STORAGE R!COVEFY
CICS/VS restores auxiliary storage temporary storage data
identifications (and the temForary storage use map) during a warm start
or emergency restart, to their status prior to a ccntrolled or
unccntrolled shutdown. No support is provided by CICS/VS for recovery
of temporary storage in dyramic storage.
224
CICS/VS System/Application Design Guide
Temporary storage in dynamic storage is lost following either a
controlled or unccntro11ed shutdcwn.
Temporary storage recovery is not supported by the subset option of
CICS/DOS/VS.
TRANSIENT DATA RECOVERY
The processing carried out by unccmF1eted (in-flight) tasks may have
resulted in CICS/VS transient data activity. These tasks may have
operated on extrapartition data sets or intrapartition destination~
during processing.
~ll~partition ~at~ ~! ~§£QlS.~
CICS/VS does not provide any facilities
extrapartition data sets. Hcwever, design
later in this chapter detailing aFproaches
the user to develop his cwn extrapartition
for reccvery cf
techniques are presented
which may be utilized by
recovery procedures.
1D!~~~!iti~~ ~g!g ~§! ]§~2~~.~
CICS/VS provides facilities for recovery of data cn intrapartition
destinations during warm start and emergency restart.
A warm start is carried out when a controlled shutdown is successful.
Reestablishment of the destinatien centro1 table (tCT) to its status
at system terminatien will result in the restoration of intrapartition
destination status, as systeK activity was quiesced at controlled
shutdown.
On emergency restart, CICS/VS utilizes logged intrapartition data
set activity of tasks which completed execution fcllowing an activity
keypoint, to update the DCT (for the destinations used by those tasks)
to reflect their processing activity. The activity of in-flight tasks
on intraFartition destinations is tacked out, to return those
destinations to their status as if those tasks had never commenced
execution.
Intrapartition data set recovery is not supported by the subset
option of CICS/Des/vs.
RECORDING OF CICS/VS FILE CONTROl DATA SET MODIFICATIONS
Data set modifications may optionally be autosatically logged by
the CICS/VS file centrel FIogram during nor.al operation, to either
the system log data set and/er a separate us~r jcurna1 data set. The
processing carried out by in-flight tasks may also have resulted in
modification tc us~r data sets. These data set modifications may
comprise data set record updates, additions, or deletions, and can
subsequently be used during emergency restart to tack out those
modifications made by uncoapleted tasks.
Automatic logging is not supported by the subset option of
CICS/DOS/VS.
CICS/VS FILE CONTROL DATA SET
BAC~OUT
During emergency restart, CICS/VS collects (froa the system log data
set) logged records for in-flight tasks which describe user data set
Chapter S.
CICS/VS Recovery and Restart
225
modification activity carried out by those tasks. (User journaled
records written ty those in-flight tasks to the system log are also
collected.) These ccllected:records ~re written by CICS/VS, during
emergenc:y restart, to the restart data set. The iJlformation on this
restart aata set is used by the transaction tackcut program, which is
executed as part of CICS/VS emergency restart to back out modifications
made to those user data sets by in-flight tasks.
Data set backout.is net supported by the subset option of
CICS/DOS/VS.
TRANSACTION RESTART ON
SlS~E!
RESTART
CICS/VS does not provide support for automatic transaction
reinitiation on system restart. This support, if required, aust be
provided by user-written rcutines. £uring CICS/VS execution,
VTAft-supported terminal input transactions may be logged by CICS/VS if
specified as "prctected" by the user in the PC~ fer specific transaction
codes. 'Ihe input messages for in-flight tasks are collected ty the
transaction backout prograa during eaergeJlcy restart and ~ransferred
to temporary storage. They can te:retrieved fro. temporary storage
based upon the identification of the terminals that entered the
in-flight transactions. A user-written transaction restart program
may reinitiate each tacked-out task, to reprocess. its relevant
transaction. A technique is described in this chapter for the design
of such a transaction restart prc~raa.
CICS/VS also logs the last output message that is transmitted by
"protected" tasks to VTA!-SufPotted terminals. These are referred to
as "committed output messages," and they require a pcsitive response
indicating receipt by the relevant ViA! terminal. This response is
also logged. On emergency restart, eICS/VS can determine whether a
committed eutput message was recEived by the relevant terminal prior
to the uncontrolled shutdown. If it was not received, it is transferred
to temporary storage as previously described for input transactions.
The 3600 enables committed output messages to be retransmitted to the
relevant VTAM logical unit on emergency restart for messagE recovery
and resynchronization.
The r4:cover y suppert pro.ided by eICS/VS and that support which must
be provided by the user are summarized in Figure 8-1 for easy. reference.
The rE:mainder of this cha pter describES the CICS/VS BAS facilities,
outlined previously, in more detail. It discuSSES particular instances
when each facility may be utilizEd, and outlines various design
approaches which may be adopted ty the user. The remainder of the
chapter will cover each facility in the sequence presented in Figure
8-1.
226
CICS/VS System/Application Design Guide
CICS/OSNS
CICSNSUserProvided
Provided
Recovery Activity
Recovery FromProgram Errors And Abnormal Termination
ABEND codes Marked System-Recoverable in SRT
- ABEND codes Marked User-Recoverable in SRT
YES
CI CS/DOS/VS
CICS/VSProvided
YES
YES
YES
Reestablishment Of CICSNS System
- Cold Start Of CICS/VS
- Warm Start After Controlled Shutdown
- Emergency Restart After Uncontrolled Shutdown
YES
YES
YES
YES
YES
YES
Emergency Restart Following System Failure
Due To Power Failure
Due To Machine Check
Due To Operating System WAIT/ABEND
Due To CICS/VS Partition/Region ABEND
YES
YES
YES
YES
YES
YES
YES
YES
Recording Of CICS/VS File Control Data Set Modifications
- Automatic Logging Of Data Set Modifications
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
CICS/VS File Control Data Set Backout
Identification Of Inflight Tasks On Emergency Restart
Collection Of Data Set Activity Of Inflight Tasks On
Emergency Restart
Data Set Backout On Emergency Restart
Temporary Storage Recovery
- On Warm Start After Controlled Shutdown
Logging Of Temporary Storage Activity
Temporary Storage Recovery On Emergency Restart
Auxiliary Storage Residence
- Dynamic Storage Residence
YES
Transient Data Extrapartition Data Set Recovery
- Journaling Of Extrapartition Data Set Activity
Extrapartition Data Set Recovery On Warm Start
After Controlled Shutdown
Extrapartition Data Set Recovery On Emergency
Restart After Uncontrolled Shutdown
Transient Data Intrapartition Data Set Recovery
On Warm Start After Controlled Shutdown
Logging Of Intrapartition Data Set Activity
Intrapartition Data Set Recovery On Emergency
Restart After Uncontrolled Shutdown
Transaction Backout On System Restart
Auto'matic Logging Of Terminal Input And Output
Messages (VTAM Terminals Only)
Identification Of Inflight Tasks On Emergency Restart
Collection Of Logged Terminal Messages For Inflight
Tasks
- Transaction Restart On Emergency Restart
- Message Research Of Committed Output Messages
In Doubt
Recovery From Terminal I/O Errors
Detection Of Terminal I/O Errors
Terminal/Node Error Program Recovery
Dynamic User Terminal Reconfiguration
Recovery From Disk I/O Errors
- Detection Of Disk I/O Errors
- Common User Disk Error Recovery
Figure 8-1.
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
UserProvided
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
Su •• ary of Becovery Procedures Provided by CICS/VS and
by User
Chapter 8.
CICS/VS Becovery and Bestart
227
CICS/1S supplies a system recovery program (SEP), which provides
logic for the recovery fre. varieus Fregram-check interrupts. In
addition" the system recovery program handles partition/region ABEND
recovery iDplemented within the system recovery table or within user
routiness.
The system recovery program (SRP) is a component of the reliability,
availability, and serviceability (EAS) features ef eICS/VS. In the
event of CICS/VS abnormal terDination by the operating systeD, the SRP
regains control through use of the S~AE and SPIE macro instructions of
OS/VS, or the STIlT Dacre instruction of DOS/VS.
PROGEAM CHECK INiERCEPTICN lti SRF
If a program check occurs during execution of a ClCS/VS application
program, the SRP interceFts the interrupt at the OS/VS SPIE or DOS/VS
STXIT routine defined in the SRP. ihe handling of the program check
depends cn the point reached during execution of the application
program. The following situations are identified by the SRP:
•
Progl:am Check in storage ContJ:ol
SEP activates storage
contrel recovery
•
Progl:am Check in Application
Program
SEP AEFNDs the task
•
Frogl:am Check in CICS/VS System
Module
SRP AEENDs the
partition/region
RIggI~.!! !~.h.§£! ill ~!g~ig! ~~Y2!
If the program check occurred with the storage contJ:oi program
executing, SRP passes control to the stoJ:age control recovery program
(SCR) •
I(Generally, such a prograa check occurs if a storage accounting
area (SAl) or storage chain Fointers have been destroyed by prior
incorrect execution of an application prograa.) The SCR attempts to
recover the destroyed information using either a duplicate SAA appended
to each allocated storage area, cr by using forward and backward chain
pointers connecting free area queue elements (FAQE). If recovery is
successful, the storage vielation is noted in the CICS/VS statistics
and task execution continues. If recovery is unsuccessful, a program
control ABEND macro instruction is issued to ABEND the task. This
activates progJ:aa-level ABEND exit routines associated with the task
as described later in this chapter.
If the program check occurred in a CICS/VS application program, the
task is abnormally terminated with a program control ABEND macro
instruction. This activates program-level ABEND exit routines
associated with the task (see Figure 8-2).
If thE! program check occurred while a CICS/VS management module
(such as task control) was executin9~ the SRF issues a DOS/VS or OS/VS
user ABEND macJ:o instructicn to ABEND the entire eleS/VS
partitioll/region. This is irtercepted by the OS/VS STAE or DOS/VS
STIlT routine defined in the SRP. ~he SEF may attempt recovery or
228
CICS/VS systeD/ApFlication Design Guide
recording of application dependent information pricr to initiatirig a
centrolled shutdcwn.
eles/vs FARTITION/REGION AEEND
The eleS/VS system recovery program determines what action must be
taken under the varieus ~artition/region ABEND conditions. This
determination is made froD irferBatien defined by the user in a System
recovery table (SET). In the case of DOS/VS, if the system recovery
program determines that eleS/VS execution cannot ccntinue, it Day
attempt to exercise the recording cf vital information so that eles/VS
can be warm started.
If the recerding of vital information is
impossible and the shutdewn is uncentrolled, the user must subsequently
conduct an emergency restart or, instead, a complete cold start of
eleS/VS.
SYSTEM RECOVERY TABLE
The system recovery table (SRT) utilized by eleS/VS contains
user-specified entries fer selected ABEND codes, and identifies them
as either system or user AEEND cedes. A program to be given control,
or a routine within the SRT, is identified.
Through the use of the system recevery table it is possible to
identify various eleS/vS-issued C5/VS and DOS/VS system and user ABEND
codes, and to indicate whether the AEEND error can be recovered by
eleS/VS or by user routines.
This gives the user considerable control
over the termination of applicatien Frograms and of the eleS/VS system.
Upon detecting a partition/region ABEND situaticn, the SRF gains
control and scans the SRT to determine if the ABENV code passed to it
is in the table.
If an entry for thE ABEND code sFecif~ed is found in
the table, the associated recovery rcutine is scheduled.
If the ABEND processing reutine is resident in the SRT, control is
given to that routine.
After preCEssing is complete, control can be
returned to the SRP specifying that the partition/region is to be
abnormally terminated, or (only for eleS/OS/vS) whether the
partition/region can continue precessing. Since an OS/VS ABEND can .be
recovered from, eleS/OS/vS allows the user te avcid ABENting the entire
partition or region.
The tOS/VS supervisor does net permit recovery
from a partition ABEND and dces not allew the user to avoid the ABEND.
However, the user may record informatien for a subsequent warm start.
If a nonresident ABENt processing routdne is a Fr6gram, control is
given to that prcgram thrcugh a Fregra. ccntrol LINK. UFon return to
the SRF, the same options may be specified as in resident processing.
If no ABEND code is preSEnt in thE SET (or if rEcovery is
unsuccessful), the task and the eleS/VS partition/region are abnormally
terminated.
During such task.termination, any program-level ABEND
exits for the task are processed. Following this, the user's
installation-level program error program is giver c0ntrol, and a
ccntrolled shutdown if attemlted.
Since a partition/region ABEND may occur at any time, a number of
tasks may be in-flight at the time of the ABEND.
Although the SRP
attempts a centrelled shutdown by recording information for a subsequent
warm start, the user may wish to do an emergency restart to back out
the processing carried out by the in-flight tasks.
A similar situation may occur if the master terminal operator
attempts a controlled shutdown and specifies immediate termination of
Chapter 8.
eleS/VS Recovery and Restart
229
CICS/VS.
(See ~l~~Ll~ 31§!~! Ad!i~i§!;S!R~§ ~ids, S820-9006.) Tasks
which were in-flight at immediate termination may need to be tacked
out by an emergency restart.
FROGBAe CONTBOL JBENt EECOESTS
Program contrcl ABEND macro instructions, issued either by ClCS/VS
application programs or by CICS/VS, are intercepted by the program
control program. Control may be passed to program-level ABEND exit
routines (see Figure 8-2) specified ty each separate program level
reached as the r~sult of a program control LINK macro instruction.
These ABEND exit routines may:
• Attempt recovery and retry of the situation
to be requested
~h~h
caused the ABEND
• Becord application-dependent infcrmation for later recovery and
permit the AEEND to continue
•
to ignore the ABEND and specify that normal execution is to
continue
Choo~e
control is then fassed to the next higher prcgram.level whose relevant
ABEND exit routine is given centrol if the ABEND is permitted to
continue~
If the ABEND is ignored at the lo~er ABEND exit, control is
returned to the stateaent following the LINK macre instruction whic~
originally activated the lewer level program.
FROGEA~
lEVEL JBENt
EXI~
RCU~INE
program-level ABEND exits are SUFForted by CICS/VS, so that
user-written routines can ~move the effects of incorrectly executing
tasks. The exit is activated and deactivated by a CICS/VS SETXIT macro
instructicn coded in an ap{lication {regram (see "SETXIT Program
Processing" in this chapter). The exit routine may exist either as a
separate program, or as a routine ~ithin the program issuing the macro
instruction.
Once a program control ABEND cccurs in a task and a SE~XlT exit
routine has been entered, any of the fcllowing three ways can be used
to terminate the exit routine processing:
230
1.
Issue a prograa ccntrcl RETURN macro instruction to continue
processing this task as if the ABENt had nct occurred. In this
case, co~trol is passed tc the program on the next higher logical
level (at the statelent fello~ing the LINK macro instruction)
OJ~, if the program in control at the time of the ABEND ~as at
the highest level, the task is normally terminated by CICS/VS.
(See A in Figure 8-2.)
2.
Issue a program control AEEND ~acro instruction to continue with
AEEND processing. This may indicate execution of a specified
exit routine for a prcgram on a higher logical level, or at the
higbest level may cause a LINK to the CICS/VS abnormal condition
program to complete the atnormal termination.
(See B in Figure
8-2.)
3.
Branch to a point in the prcgram tbat was in control at the time
of the ABEND, and attempt to retry the operation.
(See C in
Figure 8-2.)
CleS/VS SysteR/Application Design Guide
~~Il11 gI~g!g! gIQ~~~siD9
In order to activate the exit for a particular task, the application
prcgram may issue the prcgram control SETXIT macro instruction at each
program level reached by a LINK macro instruction.
(See Chapter 2.)
This identifies either the name ef a separate prcgram or of a routine
within the abnormally terminated program, to which ccntrol is to be
passed if an ABEND occurs while that program level is in control. If
the program level, after further processing, wishes to cancel the exit,
it issues a SETXIT ma~ro instructicn without specifying a program or
routine name.
The program control SETXIT macro instruction can be issued by any
Assembler Language, American National Standard (ANS) COBOL, or PL/I
program. The ability to pass control to a specified routine or program
on a program ABEND, conceptually allows it tc be iaplemented in a manner
somewhat similar te that provided by PI/ION-conditions. However,
normal PI/ION-conditions cannot he utilized in CICS/VS PL/I application
programs.
In program-level ABEND exit routines defined for a task, the user
may wish to record applicaticn-dependent infcrmatien relating to that
task prier to its abnormal terminatien. He may also attempt dynamic
hack out of that task's specific activity through user-written routines.
(See "Dynamic Task Backout" later in this chapter.)
PROGRAM ERROR PBCGRAM (PEP)
A program errer program (PEP) capability is provided by CICS/VS, to
offer an opportunity for a user-written program error program to carry
out installaticn-level action follcwing a prcgram error. Such action
may involve the recording of application-dependent information, for
utilization by user-prograDs when CICS/VS is reinitialized.
Alternatively, a generalized dynamic task backout routine may be
developed by the user.
The PEP is given control during the processing of abnormal task
termination through a LINK from the abnormal condition prcgram (ACP)
of CICS/VS after all program-level AEEND exit routines have been
executed by the ABENting task. Included in the data passed to the PEP
are the FCT andPPT entry addresses for the transaction code which
initiated the program, and the AEEND code. The FEP can decide that
CICS/VS is to mark the PCT and/or FP~ entry as disabled (inaccessible)
when control is returned to the ACP. ~he user may perform any
additional functions he desires. The ACP will write a message
indicating abnormal task termination to the master terminal destination,
and indicate if the PCT and/er PFT entries have teen put out of service
(disabled). Any further infcrmaticn to be passed to the master terminal
operator may be written by the user-developed PEP.
The PEP is given control on any program control ABEND requested by
a user or system module, with the exception of a fcrced ABEND, in an
effort tc alleviate a stall situation. In this case, if the LINK to
PEP would be suspended because of a shortage of storage, the LINK does
not take place and no actien is taken against the FCT entry. A message
is sent to the master terminal destination stating that the PEP was
not executed, so that the gaster terminal operator can disable the PCT
and/or PFT entries, if desired.
Chapter 8.
eICS/VS Recovery and Restart
231
PROG1
DFHPC TVPE=SETXIT,
ROUTINE=~BEND1
DFHPC TVPE=LlNK
PROG RAM=PROG2
SYSTEM RECOVERV
PROGRAM
.PROG2
DFHPC TVPE=SETXIT,
ROUTlNE=ABEND2
DIFHPC TVPE=ABEND,
ABCODE=ERR1
ABEND1
DFHPC
TVPE=ABEND,
ABCODE=ASRA
PROGRAM CONTROL
PROGRAM
®
DFHPcl
TVPE=J:j
DFHPC
TVPE=RETURN
®
DFHPC
VPE=RETURN
Figure 8··2.
232
®
DFHPC
TVPE=ABEND
Program-Level ABEND Exit ProcEssing
CICS/VS systew/ApI=lication Design Guide
ICT/PPT DISAELE AND ENAELE
CICS/VS provides suppcrt for the disabling of transaction codes and
programs following their abncrmal termination, and their subsequent
enabling when the particular protlem has teen rectified.
If an applicatien prcgram abnermally terminates (perhaps because of
a program check er a program control AEEND macro instruction), the
user, in a SETXIT routine or in the FEP, can flag the appropriate
transaction code entry in the PCT, and the program entry in the PPT,
as disabled. Any further attempt ty terminals cr programs to use that
transaction code and/or prcgram will be rejected by CICS/VS until the
transaction code and/or prcgram are enabled again. Consequently, the
effect of program checks can be minimized, so that every use of the
offending program does not result in a program check. Only the first
program check is processed, and, if the PEP indicates that the PCT
and/or PPT entries are to be disabled, subsequent transaction codes
for that program will not te accepted by CICS/VS.
Fcllowing correction cf an application program, the relevant PCT
entry for the transactien code and FIT entry for the program can be
enabled ty the master terminal operator, to allow terminals to utilize
that transaction code and prcgram again. The master terminal operator
can also disable transaction codes and programs when transactions are
not to be accepted fer applicaticn-dependent ~easons, and enable them
again at a later time.
(See the ~~~L~ ~!~m A9!iDi§!~ato~!§ §y!g§,
SH20-9006.)
DYNAMIC
~ASK
BACKOUT
The user may wish to atteDpt dynamic backout of an ABENDing task's
activity, either in program-level ABEND exit routines defined f9r that
task, or in the program error program (PEP). User-written support
placed in the various pregra&-leve~ ABEND exit routines can be tailored
to the specific processing carried out by the ABENDing task. Since
only one PEP can be used by CICS/VS, suppor~ in the PEP must be more
generalized and able to be used for all tasks in the installation.
During normal CICS/VS operation, task activity may be automatically
logged to the CICS/VS sytem log. This may include file control data
set modifications, transient data intrapartition activity, temporary
storage activity, and input and cutput terminal messages for tasks
defined as protected in the FCT.
CICS/VS journal contrel permits data to be read from the CICS/VS
system leg or_user journal data sets during normal eICS/VS operation.
(See "Journaling" in this chapter.) A user-written dynamic task backout
routine may read logged activity belonging to the ABENDin~ task from
the CICS/VS system log. ~his activity can be extracted from the system
log by user-coding using logic similar to that used by the CICS/VS
recovery utility program (BUI) during emergency restart.
(See "CICS/VS
Becovery utility Program" in this chapter.) The AEENDing task's
activity can then be backed out ty user-coding using logic similar to
that used by the CICS/VS transaction backout program.
(See "eICS/VS
Transaction Backout Frograa" in this chapter.)
However, the effect of reading the CICS/VS system log on the
execution of other cencurrently executing tasks must be considered.
To ensure integrity of the system log, system environment, and user
data sets, a task that reads to the system log (for dynamic task
backout, for example) is given exclusive control by CICS/VS of that
system leg. The log is placed in input status and any tasks which
require the log to be in output status (for a write) must wait until
it is returned to output status ty the task reading the leg. Therefore,
Chapter S.
CICS/VS Eecovery and Eestart
233
any tasks which initiate auteDatic: logging activity will wait; the
entire online system may subsequently be brought to a halt while the
dynamic task backout is perfermed~
This may impact online service te terminal users and may not be
desirable. The following alternative approach, related more to the
application characteristics, may be considered.
Many online applications have specific application backout
requirements which require processing similar to that needed for dynamic
task backout. For example, an order entry application in the
distribution and pharmaceutical industries may have to permit
cancellation of crders befere order completion by the terminal operator
if insufficient stock is available to satisfy a requirement for certain
items in the order. An incorrect banking or insurance transaction may
have to te voided by the terminal OpErator. A manufacturing work order
request may have to be reversed tecause of unforeseen unavailatility
of equipment or raw materials.
An ap~roach, which may te ado~ted by these ap~lications to Fermit
reversing (or backing out) requests to be accepted by the system, is
to record each input message relating to the operation (such as each
line iter in an erder) on telporary st~rage. If the operation is
completed normally, those input messages can be Furged frem temporary
storage at the End cf the crder. However, if the terminal operator
requests backout of the operation {cancellation of the order), all of
the input relating tc that oFeration is available on temporary storage.
A user-written program can retriEve the original input messages and
reprocess them to reverse thEir Effect on various data sets. For
example, cancellation of an order will require that the stock
availability of each previcusly acceFted line item be adjusted to
reflect the cancellation of the earlier order. 1his results in an
increase in stock availability if the stock availability was earlier
decreased when the line item was first accepted. Similar reversing
activity would be carried out for each of the other previously described
application examples.
The cancellation cf the order, as previously described, was initiated
at operator request. A Frcgram check, or program ABEND, is a
system-initiated requirement to cancel further precessing by the
offending task. Dynamic task backout is a system-initiated requirement
to reverse that task's processing up to the point ef abnormal
termination. As previously described, the application backout code
may be utilized for dynamic task tack cut.
Applicatien programs sheuld be written to reccrd all relevant input
messages on temporary stcrage. Eefore fields in data sets are updated
(for example, to reduce stock availatility by the quantity ordered for
the relevant product), the program should test a program switch to
determine whether, for example, the quantity ordErEd is to decrease
the stock availatility or increase it. This switch would normally be
set to decrease availability for an erder, or increase availability
for a receipt into inventory. The appropriate update activity is then
carried out, based on the status of the program switch.
with this program design, cancellation of the order can be initiated
on terminal operator request by having the application program first
setting the program switch to indicate receipt back into inventory,
and then executing the original Frcgram which first accepted the line
item. Similarly, on a program ChECk or ABEND, the program switch should
also be set to indicate receipt back into inventery. This is done in
the program-level ABEND exit routines for the ABENDing task. These
routines may be Fart of the crder entry program. After setting the
switch accordingly, each input message can be read from temporary
storage ty the AEEND exit routine and supplied to the order entry
23q
CXCS/VS System/Application Design Guide
program for processing. This precessing ~ill now back out each input
message's activity against data sets based on the Frogram switch status.
The result is system-initiated task cancellation, and user-developed
dynamic task backout withcut requiring access to the CICS/VS system
log. The system log is then only used for emergency restart following
uncentrolled shutdewn.
The previous discussion is oriented toward dynamic task backout
against file control data sets. The same approach may also be used
for eL/I data bases. Once the order entry program retrieves the
relevant segment, it may te updated based on a reduction in inventory
(an erder) or a receipt into inventory (backout ef an order). In either
case. the updated DL/I seg&ent replaces the segment in the data base.
PROGRAM EACKUP
CICS/VS does not provide specific support for Frogram backup.
However, a number ef CICS/VS facilities may be employed by the user,
as described in the following paragraphs.
To prEpare for the possibility of program checks occurring in a
particular versien ef an aFplicaticn program, an earlier version of
that application program can also be pr.sent in the PPT, and identified
in the PCT by a unique transaction code. This earlier version can be
utilized as a backup program in the Event of failure of the current
version. A technique fer Frogram backup is descrited below. This
considers the situation in which changes to a correctly operating
program may intreduce errors, and assumes that the previous version of
the program may be used for tack up until the errcr is corrected
(assuming that the earlier program still provides the facilities
required by the online applicaticn. and is suitablE for temporary use
by the aFplicaticn).
If a program check cccurs in the new version of the program, the
PCT and PPT entries may te disabled by CICS/VS er ty the user-written
PEP. Through the use of the CICS/VS message switching transaction
(CMSG - see Chapter 3), terminal operators may be notified by the master
terminal operator to use another transaction code, which will initiate
an earlier version of the Fregram in error (see figure 8-3).
This technigue requires terminal operators to change their operating
FrocedurEs. It lay intreducE ter.inal operating procedure difficulties,
as it reguires the ter.inal cperator to utilize that alternative
transaction code until subseguently notified by the master terminal
operator that the original transactien code can te used once more.
This notification would be madE when the prograa in error has been
corrected, recataloged to the CICS/VS Frogram library, and the PPT
updated by the CICS/VS-provided master terminal eperator transaction
(CSMT) to point to the corrected Frogram.
(See "Online Program
Maintenance" in this chapter.) Fellewing this, the CICS/VS master
terminal operator transaction may be utilized to enable the relevant
PPT and PCT entries, to activate the program and transaction code 8gain.
A CMSG transaction may then notify terminal operatcrs of this fact.
The correction ef the error program, and subsequent activation of
the original transaction cede, may take a considerable amount of time.
During this time the terminal oFErator must remember to use the
alternative transaction code (and transaction format if the backup
program demands a different format). If the ter.inal operator does
forget, and instead uses the original transaction code for the program
in error, CICS/VS will notify him that the transaction code and/or
program is disabled.
Chap~er
8.
CICS/VS Recovery and Restart
235
If a mew terminal operator later signs onto CICS/VS, he may not
receive the master terminal cperator message notifying him to use the
alternative transacticn code. Similarly, a terminal operator may forget
to use the alternative code. To allcw for these situations, the
terminal operating procedures should indicate that if a CICS/VS message
is received indicating that a transaction code and/or program is
disabled" the terminal operator should refer to a user-provided table
in the UEer's terminal cFerating procedures documentation, which
identifies the alternative transaction code to be utilized.
The atove program backuF technique does not require any modification
of CICS/'VS, but does require different terminal operating procedures
to be adopted until the error prcgram is corrected. The user must
weigh the difficulties which theSE different operating procedures
introduce in his applicaticn envircnment, with the problems involved
if the functions carried out by the error program are unavailable to
the terminal users.
INPUT
PROCESSING
OUTPUT
Program Check
~Term;nal
Code Message
. :>
..
pro~
0
Tran
Code
:>
1. Terminal operator enters input message:
2. Program check occurs in program
initiated by transaction code in
terminal message:
.
PCT
>
4. User's program error program accepts
CICS/vS disable of PCT and PPT.
r
Alternate trans ]
(
I
(
.
.,. :>
..
rn~>
message switching transaction to route
message termi nals specifying that
alternate trans code is to be used.
..
..... >
[]U~
~
Figure 8-3.
I--
7. Error program is corrected, and recataloged to CICS/VS program library.
8. Master terminal operator enables original transaction code, and corrected
program, for use again.
9. Master terminal operator broadcasts
message to all terminals specifying
original trans code to be used once
more.
"Please Use
Trancode X
Instead Of
Trancode Y"
---
6. When alternate trans code received,
backup program will be used.
Program Recovery
Backup
Program
PPT
PCT
Trans Code
& Program'
Disabled
Program Backup
5. Master terminal operator uses CMSG
\
r
3. User's program error program is given
control, if specified.
I
~
.... >
~
>
PPT
PCT
Trans Code
& Program
Enabled
.-
D
Program Backup !echnique
DUMP DAT;" SET
If a program check or program control ABEND occurs, a program dump
of all the storage associated with the task in error is automatically
produted by CICS/VS. This includes any applicaticn programs which have
been linked to, or any terDiDal I/O areas, file I/O areas, file work
areas, amd other working storage utilized by that task.
23E
CICS/VS system/Application tesign Guide
These program dumps are directed to one of two dump data sets.
Relevant CICS/VS areas such as the CSA (common system area) and TCA
(task control area), together with the associated terminal control
table entry for that task, are also dumped.
Two dump data sets are utilized by CICS/VS, but only one is in active
use at a time.
Any program dump, resulting from abnormal termination
or use of the CICS/VS dump centro1 macro instructions issued by
application programs, is directed to the active dump data set. The
master terminal operator can indicate that the second dump data set is
to be made the active dump data set, and the first dump data set is to
be left inactive. This switching of dump data sets is accomplished to
enable dumps previou:s1y written to a dump data set to be printed from
that data set while CICS/VS execution is in progress. The printing of
dumps is achieved through the use of the CICS/VS dump utility program,
which may be executed in a batch partition concurrently with CICS/VS.
(see the relevant CICS/VS Operations Guide for DOS or os.)
ONLINE PROGRAM MAINTENANCE
CICS/VS provides support for online program maintenance. The master
terminal operator is notified by CICS/VS when an abnormal program
termination occurs. If a hard-copy terminal is used for such automatic
master terminal operator output, that indication will be immediate,
provided the terminal is in service and not presently being used for
other terminal I/O. Depending upon the severity ot the problem, the
master terminal operator may decide to switch durop data sets and run
the CICS/VS dump utility program in another partition to print the
particular offending dump as soon as possible. That dump can then be
passed to maintenance programmers for debugging and correction, while
CICS/VS execution continues for other application programs.
When the error is corrected, and the corrected version of the program
is compiled and cataloged to the CICS/VS program library, the master
terminal operator can alter the processing program table entry for that
program to point to its newly link-edited version. This is achieved
by the master terminal operator transaction (CSM~) provided by CICS/VS
(see CICS/VS System Administrator's Guide). Program maintenance and
correction can therefore proceed together with CICS/VS execution.
Following correction of the program in error, the relevant PPT and PCT
entries may then be enabled by the master terminal operator, to allow
the corrected program and transaction code to be put into active use
again.
(See "Program Backup. It)
KEYPOINTING OF CICS/VS
The function of "keypointing" is to collect selected system
information to be used in a subsequent restart. CICS/VS provides two
types of keypoint:
• Warm keypoint
• Activity keypoint
These functions are described in the following paragraphs, together
with two other recovery facilities:
• Logical task synchronization
• Protected resources
Chapter B.
CICS/VS Recovery and Restart
231
SYSTEM WARM KEYPOINTS
A system warm keypoint is written by the CICS/VS-provided keypoint
program as part of controlled shutdown, when all system activity has
been quiesced.
It is used during a warm start of CICS to restore the
operating environment following a controlled shutdown.
The following
information is recorded as part of a warm keypoint:
• FCT
- File status (disabled, enabled, closed, read-only)
• TCT
- Terminal and line status and negative poll delay (for
nonswitched terminals)
• DCT
- Intrapartition destination status
• TST
- Temporary storage control blocks and data set bit map
• ATP
- Asynchronous transaction processing control blocks
• ICP
- Interval control outstanding requests
• PPT/PCT
- Disabled entries
• CSA
- Information in the common system area; for example,
storage cushion size, ICV, rcvs, ICVR, and MAXTASK
The above information is written to the CICS/VS restart data set
just prior to a controlled shutdown. Since the system may be
inoperable, this function is performed without the use of CICS/VS macro
instructions. The addresses of the data are also checked for validity.
SYSTEM ACTIVITY KEYPOINTS
The purpose of system activity keypoints is to indicate to CICS/VS,
during an emergency restart, the user tasks active at the time of the
keypoint, the status of transient data intrapartition destinations,
temporary storage data identifications, and terminal control table
status for VTAM-supported terminals. This is used to minimize the
amount of emergency restart activity necessary.
A system activity keypoint is written periodically by CICS/VS during
normal operation, to record on the system log data set the processing
activity status of CICS/VS and user tasks at the time of the keypoint.
The frequency of recording system activity keypoints is a function of
the numbfer of output operations to the system log. This frequency may
be specified by the user either at CICS/VS system generation or at
system initialization, and may also be dynamically changed during online
operation through the use of the master terminal operator transaction
(CSMT). The frequency of the activity keypoint, and the amount of
journaling performed by active tasks, determines the amount of data on
the system log to be processed when CICS/VS is restarted. The amount
of this data will influence the duration of the CICS/VS emergency
restart.
The information recorded by the system activity keypoint comprises
the following CICS/VS tables and control blocks:
• TCAs
status of tasks that have at least logged one record or
have completed a LUW by issuing a sync point
• DCT
status of transient data intrapartition destinations
• TST
status of temporary storage unit table entries
238
CICS/VS System/Application Design Guide
• TCT
identification of terminals waiting for response to
committed out~ut messages (see later)
The activity keypoint function is initiated hy the transaction CSKP
which is attached pericdically by the journal control program (JCP).
This transaction transmits system data to the system log and then issues
a conditional link to a user activity keypoint prcgram, DFHUAKF. The
purpcse cf this facility is to allow the user to insert
application-dependent information in the system activity keypoint.
In
order to operate properly, the program must te resident and should use
only storage control and journal centrol functions. Journal operations
should be asynchronous without start I/O. Synchronization is provided
by an end-of-keypoint synchronous record, written by the activity
keypoint program at the end of key~oint processing. The user should
ensure that the keypoint transaction has higher ~riority over other
tasks that are eligible tc leg data.
During an emergency restart, the recovery utility program (RUP)
copies tc the restart data set only that data which has been output by
in-flight tasks (tasks that were still active at system termination
time).
In order tc force EUf to cCIY user activity keypoint data to
the restart data set, the user must provide a journal record identifier
with the high-crder bit eN in the record ID field of the user key point
data record.
Befer to the ~1~SL1~ ~~§!gm fI2g!!JJ§!~§ i§!e,e~ H!YY!!
for more detail.
The user keypoint should be used to keypoint only
limited amounts of data, for example, selected user data or tables.
LOGICAL TASK SYNCHBONIZATICN
Logical task synchrcnizaticn defines the completion of a logical
unit of work (and the intent to begin another). It enables the user
to split a long duration task into lcgical units of work ef short
duration which hetter fit the task's recovery reguirements. A logical
unit of work (LUW) is a user unit of work which performs a complete
processing function.
One task may perform a com~lete LUW, or several
LUWs may be performed, as idEntified by the user's application program.
The completion of a logical unit of work is referred to as a "sync
point" (synchronization ~oint), and may be explicitly defined hy the
user task (see ~I~~LVS !~~li£!!!~y f!Q£~!!!~X!§ E~~ren£~ !!~yal).
A
sync point is generally implicitly defined to be at the completion of
processing of an entire task. The com~letion of a logical unit of work
indicates to CICS/VS that:
• All updates or modifications performed by the task up to that point
in time are logically completE, and should nct be backed out in
the event cf a subsequent system failure.
• Functions requested prior to the. synchronization point, but deferred
until the end of the lcgical unit of work, shculd he initiated.
An example of this is a transient data track release function which
is performed at end of LUW, in the case of recoverable
intrapartition destinaticns.
• All resources which were protected by the task up to this point
will be released. Such a resource may be a transient data
intrapartiticn destinaticn which is legically associated with a
task (see "Protected Bescurces," following).
The lccation cf a sync Ioint for a task on the system log, relative
to other journaled activity fcr that task, determines the extent to
which CleS/VS may need to prcvide transaction backout.
Transient data intrapartition data set activity of tasks which had
not reached logical task synchronization (a sync peint), at the time
Chapter E.
CICS/VS Eecovery and Restart
239
of an uncontrolled shutdown may te backed out by CICS/VS to the previous
sync peint for that task (cr to the start of the task) on emergency
restart.
Sync points are also used by eres/vs to delimit the extent to which
user data set modificaticns may need to be backed out for tasks which
had not completed a logical unit of work at the time of an uncentrolled
shutdown. ClCS/YS collects all user data set modifications during
emergency restart, only for tasks which had nct ceupleted a logical
unit of work at the time cf an unccntrolled shutdown. These data set
modifications are copied by eICS/VS to the restart data set during
emergency restart. They are read by the CICS/VS transaction backout
program to back out the data set modifications made by tasks which
fail~d to complete a logical unit of work.
This is discussed in more
detail in "User Data Set Eackout" later in this chapter.
FECTECTED BESOUECES
consider the following example ef two tasks which update the same
record in a data set. Task A gains exclusive control of the record,
updates it, and releases exclusive centrol. Then task B gains exclusive
control, updates the reccrd, and cemFletes nermally. However, task A
could not complete normally because of system termination.
Consequently, the effect of the ~artially completed task A must be
backed out on restart. When task A's update is backed out, the update
of task E will also be backed outu erroneously.
To avoid this, CICS/VS Frcvides a protection facility to enqueue a
task on specific recerds which are being updated, deleted, or added
using "protected" data sets (defined in the FCT entry LOG=YES). The
enqueue applies until the end of a logical unit of work, and protects
records from subsequent modification activity by ether tasks, until it
is determined that the lcgical unit of work is completed.
When task A issues a file centrel GET for update, Cles/yS enqueues
explicitly on that record. It then reads the record from the data set
and logs the input record to the system log. When the task issues the
subsequent POT, to update the record, CICS/VS does not dequeue its use
of that record until task A indicates completion of a logical unit of
work. ClCS/VS then dequeues the task from the data set record.
In the meantime, if task E wishes to update the same record, when
CICS/VS enqueues on that recerd, the task is placed on the suspended
task chain by CICS/VS until task A completes and dequeues from the
record. Task B then gains ccntrol of the record and carries out its
update. If the system terminates before the completion of task A, the
task A update can be backed out without affectingcther processing of
the record because task A had exclusive control of the record of
termination.
Enqueuing on the record fer the duration of the task therefere
protects the reccrd from pcssible less of an update made by a completed
task, because of backout of the uFdate of a partially completed task.
The same procedures also apply to additions and deleticns.
Similar protectien is carried cut by CICS/VS for transient data
intrapartition destinations. Only one task at a time is permitted to
access an intrapartition destinatien for input and one is permitted to
access it for output. The destination is regarded by CleS/VS as two
separate resources--one input resource, and one output resource.
set
240
By serializing updates as described above, the integrity of the data
follc~wing backout en restart is Frctected.
However, this may have
CleS/VS system/Application Design Guide
some effect on performance if several tasks are operating on the same
resource at some time during their combined total period of execution.
~his effect on performance must te evaluated in terms of improved
integrity.
The user should recognize the possibility of a lockout occurring if
several tasks attempt to update two er more records concuIrently in a
protected data set (FCT LOG=lES), and the records are not accessed in
the same sequence by each task. This is illustrated in the following
exam~le.
Consider an order entIY aFplication, which accepts orders for several
products in the same CICS/YS transaction. ~his transaction updates
the stock availability fcr each Froduct in a product data set, that
specifies automatic logging in its FC~ entry (LOG=lES). If one terminal
enters a transacticn for crders against product numbers 638, 815, and
1068, the application program will update those product records.
CICS/YS file control will en9ueue against each reccrd until the task
passes through a user-synchrcnizaticn point, or terminates. If another
terminal also enters a transacticn at the same time for orders against
product numbers 501, 1068, and 815, an enqueue interlock will occur on
product numbers 815 and 1068, and neither task will terminate. It will
appear to the operatcrs cf these terminals that the system has gone
down, while in fact it is still processing other terminal transactions
successfully.
To avoid this automatic lcgging enqueue interlock, three actions
are possible:
1.
The terminal cperator should always enter product numbers in
the same sequence (such as ascending sequence).
2.
The application program first sorts the input transaction
contents so that product numbers are ascending, before processing
begins.
3.
The application program issues a user sync point macro
instruction after processing each product cIder in the
transacticn.
The first solution requires special terminal operator action which
may not be practical within the constraints of the application. (For
example, . orders aay be taken by teleFhone in random product number
sequence.)
The second solution requires additional application programming,
but im~oses no external ccnstraints en the terminal operator or
application.
The third soluticn re9uires less additional pregramming than the
second sclution. However, by issuing a user sync point, it implies
that previously processed product crders in the transaction are not to
be backed out on emergency restart if a system failure occurs before
the processing of the entire transaction is completed. This may not
be valid for the applicaticn, and Iaises the question on emergency
restart of which products in the transaction were processed (orders
accepted) and which were backed out by CICS/VS. If the entire
transaction must be tacked out, either a user sync peint should not be
issued, or only cne product crder should te entered in each CICS/VS
transaction.
Of the three solutions, the second solution (sorting product numbers
into ascending sequence by programming) is most widely accepted.
Chapter 8.
CICS/VS Recovery and Bestart
241
The possibility of an automatic logging enqueue interlock occurring
exists fc;r any a~plicatioD which ~IocessEs several application-oriented
logical units of work (product oIders), within ODe CICS/VS logical unit
of work.
FROTECTEt "ESSAGIS
VTA"-!:upported terminals, such,as the 3600, enable message recovery
and resynchronization to be attempted during emergEncy restart of
CICS/VS. The user can specify in the FCT that vaIious transaction
codes are to be "protected."
If message-protected transacticn codes are used with VTAM-supported
terminal!:, the first input mEssage during a logical unit of work
associated with a task is logged to the system lcg. If uncoritrolled
shutdown occurs, the input mEssage fer each in-flight LUW is identified
during emergency restart and transferrEd tc tempcrary storage. 'It can
be retrieved frca temporary storage by user programs based on the
identification of the terminal which entered the message. The in-flight
activity associated. with each task is tacked out during emergency
restart. The user may then initiate reprocessing of that ihput message.
(See "Transaction Recovery and Restart" later in this chapter.)
The last output message trans8itted by message-protected tasks
without a WAIT, are regarded as "ccmmitted output" messages. The output
message is logged, and the message is transmitted ty VTAM together with
a request for a positive response frcm the VTAM terminal on receipt of
the message. When the pcsitive response. is received by VTAM, it
notifies CICS/VS, which logs the recei~t of the pcsitive response to
the syste.m log.
If an uncontrolled shutdown occurs before the Fositive response is
logged by CICS/VS, it can te detected by the CICS/VS recovery utility
program during emergency restart. The output message is transferred
to temporary storage, from which it can be retrieved by user programs
based on the identification of the terminal designated to receive the
output. The task which generated the output message may have terminated
normally prior tc uncontrolled shutdown, but the terminal may not have
received that committed output message. On emergency restart 3600
logical units; CICS/VS retransmits this output message with a request
for positive res~onse, to ensure its receipt by the terminal.
CICS/VS uses the VTAM sequence Dumbers, which are allocated to each
input and output message associate~ with a logical unit, to establish
message resynchrcnization with programmable controllers during emergency
restart. These are obtained from the system log by the CICS/VS recovery
utility program.
Inquiry transactions which de net modify data sets should not be
specified in the PCT as protected. Logging of input or output messages
will not occur. Such transactions can be reFrocessed on emergency
restart, if necessary.
An uncontrolled shutdown may cccur during the ~rocessing of an LUW
belonging to a protected task. Such an in-flight LUW will be b~cked
out on emergency restart by CICS/VS. If a coamitted output message. is
transmitted to a terminal when first requested by the application
program, it may reach the terminal even if an uncentrolled shutdown
242
eICS/VS System/Application Design Guide
cccurs before the protected task terminates normally. The contents of
the output message may indicate to the terminal that processing of the
task was completed before uncentrolled shutdown. However, if the task
was in-flight, it viII be tacked out on emergency restart. The task
must then be reprocessed followiDg emergency restart. The terminal
operator is not awar. that the task vas in-flight and was backed out,
and vould not normally reenter it cn emergency restart. The result is
the loss of that task's frecessing.
To avoid this possibility, CICS/VS defers transmission of the last
output message until completion of the task's current logical unit of
work. Thus, the outFut will be transmitted cnly if the LUW completes
normally. In the event of uncontrolled shutdown before completion of
the LUW, the in-flight LUW is backed out on emergency restart, and the
remote programma tIe controller (er the terminal oFerator) can retrieve
the original input message ~rem temForary storage and resubmit that
input message for reprocessing. If the LUW completed, and output vas
initiated, but uncontrolled shutdcwn occurred before a positive response
was received from the terminal, the completed LUW is not tacked out on
emergency restart. The committed 3600 output message is retransmitted
by CICS/VS on emergency restart as previously described.
The result of this 4eferred output is improved message integrity.
The trade-off is a delay befere transmission of the output with a
possible increase in response time at the terminal. If response time
is not to be increased, the user should either request a user sync
point, or terminate the task as soon as possible after requesting
output.
Terminal control and EMS toth permit the user to request immediate
initiation of terminal I/O fer VTAM-supported t~r.inals.
(See "Terminal
Control Using VTAM" in Chafter 2.) This avoids the deferred output
delay, but the possibility is increased that the terminal operator may
receive output indicating co.pletien of tasks which are subsequently
backed out.
An alternative approach is to treak the output into tvo or more
sections. The program Can request output of the first section,
specifying either immediate cutput or the default of delayed output.
When output of the next section is requested, the first section is
transmitted if it indicated delayed output. This continues until either
a sync peint is reached, or the task terminates when the last section
of output is considered a co.mitted cutput message and is handled as
previously described. The partial sections of outfut may satisfy the
requirement for raFid respcnse time, with each section indicating that
further output is following. Only receipt of the last $ection of output
is an indication tc the terminal oFerator of completed task execution.
The disadvantage of this approach, however, may te increased CICS/VS
and VTAM overheads.
The use of Bes terminal paging intrcduces another consideration.
If the terminal which initiated a protected task is in transaction and
request page status, terminal pages are written to temporary storage
for subsequent display, but are not directed to the terminal. The
application program should send a ccmmitted output message to the
terminal indicating completion of the task, and availability of the
terminal pages through the terminal paging commands.
(See ~!~~L!~
l§. . inAl QR~'J!2'!§ §yig!, SH20-S005.) If the terminal is in TBANSCEIVE
status, the first page viII te transmitted to it automatically when
the protected task completes.
Chapter 8.
eICS/VS Becovery and
~estart
243
The shutdown ef eIeS/VS may be either a centrolled shutdown or an
uncontrolled shutdown (such as fellowing a machine check er power
failure) •
CONTBOLLED SHU!DCWN
A centrolled shutdown preserves certain vital information about the
eIeS/VS environment during nermal or abnormal termination of eIeS/vS.
This informatien, recorded on the restart data set, may be subsequently
used to warm start eIeS/VS and reinitialize it te its status at
termination. The user may, eptionally, elect to warm start only certain
parts of eIeS/VS, and allow a cold start (complete reinitialization)
of ether parts of eIeS/VS.
Two eleS/VS tables are used to facilitate the functions of controlled
shutdown and warm start:
• Transaction list table (ILT)
• Program list table
~~~.n'§Sl~!.i.Q1)
lIi§!
l~!lj
(FL~
(111)
On eIeS/VS controlled shutdown, a transaction list table (ILT) may
be leaded. This table identifies a list of transaction codes accepted
by eIeS/VS during termination. All other transaction codes will be
rejected by eIeS/VS.
The program list table (PLT) is a list of programs to be ezecuted
either during centrolled shutdown cr during system initialization. It
is generated by the user, whc generally specifies two tables. One PLT
identifies various user-wtitten programs which are to be ezecuted during
either the first or second stage of eIeS/VS controlled shutdown (see
below). These user prograas may record applicatien-dependent
information, which will permit user recovery of that information on
subsequent system initialization.
Another PLT can be used tc identify various user-written programs
which are to be executed during the post-initialization phase of eIeS/VS
system initialization. These user programs may locate the
application-dependent infermation written by PLT-identified programs
during eleS/VS controlled shutdown, and use that informatien to
reestablish the online applicatiens as required by the user. Several
other uses of the PLT are described later in this chapter.
A normal controlled shutdewn caUSES the status of various areas to
be written to the restart data set tc permit a warm start to take place.
It uses the program list table (PL~), as described above, and carries
out termination in two stages: the "first quiescE stage" and the
"second guiesce stage." During the first quiesce stage, terminals are
still active, but they are only permitted to enter transactions defined
in the transactien list table (XIT). programs defined in the first
section of the PIT are also executed. During the second quiesce stage,
terminals are deactivatEd and prcgrams defined in the second section
of the PLT are executed. The following paragraphs further describE
the purpose of these two sta9Es of termination.
2qq
eIeS/VS System/Application Design Guide
• FIEST tUIESCE STAGE OP TEBeINATICN
During the first guiesce stage of termination, a group of user-written
programs may be seguentially executed. These programs perform special
operations that are unique to the installaticn. All CICS/VS
facilities are available tc the Frcgrams during this stage. The
programs to be linked to are defined in the prcgram list table that
is loaded during systea termination.
In addition, only those transactions defined in the transaction list
table are accepted from terminals. Existing tasks, tasks to be
automatically initiated, or ATF batches in process are allowed to
continue unhampered to their normal conclusion (see Pigure 8-4) •
• SECOND QUIESCE STAGE OF 1EEMINATION
At a user-defined point, termination activity waits until all system
activity stops. Terminaticn then continues in the second quiesce
stage without accepting any further terminal transactions.
When all program list table programs defined tc execute in the second
guiesce stage have been executed, the warm keypoint is taken and
CICS/VS terminates further executicn (see Figure 8-4).
INPUT
P~OCESSING
. -h
Dn
J
~~ ~~: J
- ..
TCT
TST
ICP
,ATP
----.~---
Figure 8-4.
1. On system error, system recovery
program (SRP) attempts recovery.
2. If recovery not possible, or controlled
shutdown requested, termination is
started.
Controlled
Shutdown
Request
I FCT
OUTPUT
3. Only transactions in transaction
list table (XL T) are accepted during
termination.
4. Programs specified by user in program
list table (PL T) are executed. Application-dependent information can be
recorded by user program for use
in subsequent system restart.
5. Warm key point program extracts
key information from system tables
and chains.
6. Warm keypoint program writes key
information to restart file for
subsequent warm start.
CICS/VS Ccntrclled Shutdown
ABNOEMAL TEBMINA1ION
An abnormal termination of CICS/VS may occur if an aPFlication
program destroys part of the CICS/VS nucleus or key system information
maintained in dynamic stcrage. 1his ~s generally the result of an
application program error, and may cause an ABEND cf the CICS/iS
Chapter
s.
CICS/VS Becovery and Bestart
245
partitioD/region. For this reasen, the CICS/VS system initialization
program issues an OS/VS STAE (or DeS/VS STIlT) macro instruction to
enable the system recovery program to regain control in the event of
a CICS/VS ABEND.
If an abnormal termination subseguently occurs, the
system recovery program (SEP) attempts to either ccrrect or circumvent
the problem (in the case of CICS/CS/VS) to continue operation (see
"System :Becovery program" in this chapter).
If recovery is not
possible" er advisable, a controlled shutdown will be initiated by the
SRP to guiesce other CICS/VS system and task activity, and record the
environment status of the CICS/VS system on the restart data set for
subsequent warm start (see Figure 8-4).
Even though a controlled shutdown may be taken tefore the CICS/VS
partition/region ABEND ccm~letes, executing tasks nay not be able to
terminate normally. These in-flight tasks may need to be backed out
by an emergency restart of CICS/VS, such as required to restart after
an unccntrolled shutdown.
If the SRP is unable te cerrect or circumvent the problem resulting
in abnormal termination, and is further unable tc initiate a controlled
shutdown (such as in the event of destruction of part of the controlled
shutdown routines), an unccntrolled shutdown will cccur.
UNCONTROLLED SHUTDOWN
An uncentrolled shutdewD ef CICS/VS can tasically result from four
different causes:
• Power failure
• Machine check
• operating system WAIT/ABEND
• partition/region ABEND
In each case, termination of system operation is 'either immediate,
or so shertly after appearance of the cause that insufficient time~
CPU resources, or system facilties are available te permit CICS/VS ~o
complete a centrelled shutdewn.
system or user tasks may still be active at the time of termination,
as eICS/VS is unable to guiesce system activity.
Conseguently, a
subseguent warm start of'CICS/VS is impossible. Instead, an emergency
restart must be carried cut.
Recognizing the possibility of any of the above failure situations
occurring at any time, CICS/VS periodically records system activity
keypoints (described earlier in this chapter).
Synchronization point
records are also written during the execution of tasks, at the
completicn of each logical unit cf work.
This information records, on the system log data set, the dynamic
activity of CleS/VS, and of active tasks, and permits an emergency
restart to be performed at seme later time using the system log. The
use of this information to restore CICS/VS to its status at the time
of the uDcontrolled shutdewn and tc tack eut the processing of tasks
which had not completed a lo~ical unit of work, is discussed in
"Emergency Restart" later in this chapter.
246
CICS/VS Systell/ApFlication Design Guide
CICS/VS can be initialized either:
• with a complete cold start
• With a complete warD start
• with a partial warm start
• with an emergency restart
COMPLETE COLD START
A complete cold start results in complete reinitialization of CICS/VS
and system data sets to their status as specified at system generation,
withcut regard for any previcus system activity. The system
initialization table (SIi) is used to specify the particular versions
of the different CICS/VS system pregrams and tables that are to be
utilized for CICS/VS initialization.
COMPLETE WABM START
A complete warm start reintializes CICS/VS to the status that existed
at the previous ccntrolled shutdown -- all system activity having been
quiesced normally prior to shutdewn. All CICS/VS system programs and
tables are first ccld started using the SIT as described previously.
If the SIT indicates that a complete warm start is to be performed,
all CICS/VS system tables are then reestablished to their status as at
controlled shutdowD, using the warm keypoint infcrmation written to
the restart data set at that time.
PABTIAL WABM STAET
A partial warm start is similar tc a complete warm start, except
that only selected CICS/VS systeD tables are warm started, as specified
in the SIT. Information is cttained from the war. keypoint written at
centrolled shutdcwn, cn1y for these tables specified to be warm started.
The remaining tables are cold started. An example requiring a partial
warm start is an applicaticn which requires a warm start of the DCT so
that data queued to intrapartiticn destinations prior to a controlled
shutdown may be retrieved en restart. The FCT and TCT may alsc need
to be warm started to reestablish file and terminal status as at
controlled shutdown. The application may, hcwever, require a cold
start of temporary storage. Figure 8-5 illustrates a CICS/VS war.
start.
Chapter 8.
CICS/VS Recovery and Restart
247
INPUT
PROCESSING
r---Q
CICS/vS
Program
Library
OUTPUT
1. CICS/vS system initialization program
(SIP) and system initialization table
(SIT) are loaded from DOSIVS or
OS/VS library.
.
SIP
2. Versions of CICS/VS nucleus programs
and tables specified by SIT are loaded.
CICS/vS
Management
Routines
'------7
Restart
/
Data:~
-:]
Program
List Table
(PLT)
[J
rn'
3. SIP reads data set and reestablishes
4. User programs in post·initialization
phase program list table (PL T) are
loaded and execu ted. These user
programs may utilize application·
dependent information recorded
during system termination.
5. Terminal polling com_m_en_c_es_fo_r_ _ _
o",m.' C>CS/VS
0''''''00.
Figure 8-5.
CICS/VS
System
Tables
And
Chains
system tables and chains to be warm
started as specified in SIT.
IJ.
_ J_
CICS/VS iarm start Frocedure
After all items have been initialized and contrcl is about to be
given to CICS/VS, the group cf user-written prograls specified in the
program list table is seguentially executed. This is referred to as
the "post-initialization" phase. ~hese programs perform
application-dependent fUDcticns, for the recovery of
application-dependent information recorded by the user on termination,
prior to complete restart cf CICS/iS. All CICS/VS facilities are
available except for direct terminal communicaticn. Following
post-initialization execution of programs in the program list table,
the terminal centrcl program is activated to enatle terminal
transactions to te received and Frocessed.
E~ERGENCY
RESTARi
An emergency restart restcres certain CICS/VS facilities to a
predefined point which existed prier to an uncontrolled shutdown.
Information describing all changes, modifications, and updates made to
various system tables and to user data sets during previous CICS/VS
execution is recorded on the system log data set. Another data set,
the restart data set, is created during emergency restart.
(Emergency
restart is not supported by the subset option of CICS/DOS/VS.)
The system log contains all changes made to reccverable file control
data sets w reccverable transient data intrapartiticn destinations, and
temporary storage prctected destinations. It also contains input and
output messages for message-Frotected tasks executed by VTAM terminals.
The restart data set is created during emergency restart, and
contains system log activity and user journal records for those tasks
whose proc:essing activity hac not reached a logical completion point
when the Uinccntrclled shutdcwn occurred.
(Such tasks are referred to
248
CICS/VS Syst€D/ApFlication tesign Guide
as in-flight tasks in the following discussion of emergency restart.)
This infcrmation can be utilized by the CICS/VS transaction backout
program, for example, to remcve the effect of data set modification by
in-flight tasks.
On an emergency restart, the eICS/VS system initialization program
(SIP) carries out a number of steps to restore CICS/VS operation to a
predefined point prior tc unccntrolled shutdown.
These steps are carried out by CICS/VS-provided routines. The user
may wish to extend the functions carried out in emergency restart by
the addition of user-written programs. One example of such an extension
to emergency restart is the execution cf a user-written extrapartition
data set backout program to repositicn extrapartition data sets to the
point reached on unccntrclled shutdown. To permit such user-written
programs to be utilized, CICS/VS identifies in-flight tasks which may
require user backout, and co~ies from the system log, in backward
sequence, all system-logged records, and user journal records, for
those in-flight tasks to the restart data set.
The design of such a user-written extrapartition recovery program
is described in "Extrapartition tata Set Eecovery." To utilize the
suggested design technique effectively, it is important that the system
designer have an appreciation of the steps carried out by CICS/VS during
emergency restart.
The remaining topics in this section provide an overview of the
CICS/VS emergency restart procedure. This procedure is illustrated in
Figure 8-6. Additional topics in this chapter discuss the information
in the following overview in more detail.
Chapter 8.
CICS/VS Eecovery and Eestart
249
PROCESSING
INPUT
c;:j2 :=::==:::::~»
(
Intrapartition
Data Set
Temporary
Storage
Data Set
(1
......1...-_-".1>
~
Repositioned
System log
......1...-_-".>
-
4. CICSIVS initiates CICSIVS recovery
utility program (RUP).
>
O
_>
I
•
pattition
pata Set
Temporary
Storag,e
Data S e t '
I
Restart
'Data Set
(------User
Data Sets
-Resta;;---f
Data~~
~
User
Extrapartition
Data Setl;
User-Written
Programs
(Identified
By PlT)
Figure 8-6.
250
7. If log or user journal record is located
before sync point, task was inflight.
Record is transferred by RUP to
restart data set.
8. System activity keypoint identifies
tasks in system at time of keypoint,
and indicates need to continue backward scan.
~>
9. OCT, TSUT, and TCT status in system
activity keypoint used to reestablish
OCT and TSUT.
I...,p
( lntr.a.~
5. CICSIVS RUP reads system log backwards
to locate logical unit of work (lUW)
sync points.
6. If first record 10catEld for a task is
sync point record, lUW was completed
before system termination.
~>
J
>
System log
3. CICSIVS cold starts TSUT but does not
reformat temporary storage data set.
Of/'
r-
RePO'itio~
>
2. CICSIYS cold starts OCT but does not
reformat intrapartition data set.
:=:=::::::»
CICSIVS
Recovery
Utility
Pr,ogram
J
l.CICSIVS repositions system log to point
reached at uncontrolled shutdown.
r
(I
OUTPUT
,Emergency Restart
.>
.
Restart
Data Set
I TpJT
I TSUT
>
DOT
10. Scan continues until sync point or start
of task located for each inflight lUW.
.......1...--..........
> 11. Transient data recovery program reestabr
lishes physical PUT activity in OCT from
intrapartition data set status.
~__-J.'> ~1___fD_C_T__~1
~~=:» 12., Temporary storage recovery program
rreestablishes TSUT pointers and
lL
OJ t:>
rr
I
TSUT
information from temporary storage data
data set physical contents.
13. Logged modifications to user data-sets,
transferred by RUP to the restart data
set, are used by the CICSNS transaction
backout program to backout infli~t
lUW activity against user data sets.
TemPQrary
( Storage
Data Sets
14. logged input messages and committed
output messages transferred to temporary
storage message cache identified by
terminal 10.
'
(
\
15. User'programs identified in PlTare
then executed (such as userextrapartition data set recovery).
16.; Terminal activity commences when all
PlT programs complete execution.
CICS/1S Emergency Restart Procedure
CICS/VS Systea/Application Design Guide
.
I
Back(
out User
Data Sets, \
user
\
E, xtra Partition
~
'Data Sets
1.
l§R2§i!i2D
~l§!~.
129
~A!A
§s!
The system initialization table (SI~ is used by the system
initialization p~ogra. tc identify whether the system log is on ta~e
or on disk. If it is on disk, the system log will be repositioned to
the point reached at unccntrelled shutdown when it is opened for
backwa~d processing (see the "CICS/VS Fost-Initialization Frocessing"
step later in this sectien).
If the system log is en ta~e, a separate system subtask is initiated
to reposition the tape te the point ~eached at uDccntrolled shutdown.
'This subtask utilizes a CICS/VS-~~ovided tape end-of-file utility
program which reads the tape system log forward and locates the last
journal record written prior to uncontrolled shutdcwn, by comparing
tiDe stamps in each journal Ieco~d. The tape end-of-file utility
program is executed as a system suttask to permit this tape positioning
to be overlapped with the emergency restart processing descrited in
the following steps. Once the tape is repositiored, it will
subsequently te ~ead backward to deter.ine system activity at the time
of shutdown (see the "CICS/VS Post-Initialization Processing" step
late~ in this section).
The system initialization program performs a normal cold start
function for the destination cont~ol table (DCT) at this stage, but
does not reformat the intrapartition data set. 1he status of
extrapartition data sets is lost fcllowing an uncentrolled shutdown.
The status of int~apartition destinations will subsequently be recovered
for those destinations identified in the DCT as teing recoverable.
This recovery is carried out by the CICS/VS-provided transient data
recovery program (TDEP) which is discussed in the "CICS/VS Recovery
utility Program" ste~ later in this section.
The system initializaticn program performs a normal cold start
function for temporary storage but does not reforDat the temporary
storage data set. Tempo~a~y storage data in dynamic storage is lost
following an unccntrolled shutdown. A design technique is described
later in this chapter fo~ user recovery of temporary storage in dynaDic
storage.
The reaainder of emergency restart processing is accomplished by
the CICS/VS-prcvided recevery utility ~rogra.. This is executed as a
normal CICS/VS application program, under control of the terminal
control program's TCA.
(This TCA is used, because normal CICS/VS
operation and terminal activity have not been initiated at this time.)
Upon completion of the system initialization steps outlined above, and
after the system log has been repositioned (if tape) to the point
reached on uncontrolled shutdown, control is then passed to the recovery
utility program.
The recovery utility
tape or disk) backward,
uncentrolled shutdown.
synchronization records
program (EUE) reads the system log (either on
to deteraine system activity prior to the
As the log is read backward, task
(sync points) are located.
(See "Logical Task
Chapter 8.
CICS/VS Eecovery and Eestart
251
synchronization," earlier in this chapter.) These define the normal
completicn of a logical unit of work for a task. If any user data set
modifications (logged either autcmatically by CICS/VS, or by the user)
or any user journal records are located for a task before a sync point
(or its initial log reccrd) is read, this indicates that the task had
not completed a logical unit of work at CICS/VS uncontrolled shutdown
(that is, was "in-flight"). The data set modifications carried out by
an in-flight task may need tc be tacked out to the previcus sync point
for that task, or to the start of the task.
CICS/VS carries out this backcut later using the transaction backout
program. The recovery utility program identifies in-flight tasks. It
collects data set or user journal records fer in-flight tasks which
were written after the start of the task or after a sync point, and
copies them to the restart data set. As the system log is read
backward, the restart data set is written forward. The restart data
set therefore will reflect in-flight task activity prior to the
unccntrolled shutdown. The restart data set can subsequently be read
by user-written tack out ~rcgrams, which are executed as
post-initialization prograas specified in the prcgram list table (PLT).
The user-written backout programs can be automatically initiated by
CICS/VS following emergency restart. and before terminal activity
starts.
The first record located for a task on the backward scan of the
system log may be a sync pcint, indicating normal completion of a
logical unit of work. Transacticn backout is then not necessary, and
journaled or logged records for that task are not copied to the restart
data set.
(Note: Eecords output by cem~leted tasks are collected to
the restart data set only if the u~er specifies a special journal-type
code with the high-crder bit QI.)
A log record located for a task on the backward scan of the system
log may have b~en automatically logged by the CICS/VS transient data
prcgram for intrapartition destinations identified in the nCT as
recoverable. These records are used by the recovery utility programs
to reestablish the nCT status for the relevant destination. Eefer to
"Intrapartition tata set Recevery after Uncontrolled shutdcwn" later
in this chapter for further discussicn.
The backward scan continues until the following two conditions occur:
(1) a system activity keypoint is reached, and (2) all jcurnal and log
records output by in-flight lUis have been retrieved. The system
activity keypoint contains irformation defining the status of
intrapartition and temporary storage destinations, TCAs for in-flight
tasks in the CICS/VS system at the time of the key~oint, and TCT entries
for VTAM terminals with committed cutput messages outstanding. The
status of intrapartition destinations is used to update the nCT, to
back out intrapartition activity carried out by in-flight tasks, and
to reflect the activity carried cut by completed tasks.
The TeAs in the system activity keypoint indicate in-flight tasks
at the time of the keypoint. A lcng-running task may have been present
when the activity key~ciDt was taken, but may not have logged any
processin9 activity, or written a sync point between the system activity
keypoint and the point when unccntrolled shutdown occurred. Such a
task had not completed a logical unit of work at the time of
unccntrolled shutdown. The back~ard scan must therefore be continued
until a sync point, or first record logged, for that long-running task
is encountered. If the first record located for the task is a sync
point, the task completed a logical unit of work and no backout is
necessary. If a data set modificaticn log record, or a user journal
record is encountered before a sync point, those records are copied to
the restart data set.
252
CICS/VS
Systelf/Ap~lication
Design Guide
The TCT identification in the system activity keypoint of terminals
which have committed output messages outstanding identifies a need to
continue the backward scan until these logged output messages are
located. These committed output messages are transferred to the
temporary storage message cache for each relevant terminal.
(See
"Temporary storage Recovery" later in this chapter.)
The TCT
information in the system activity keypoint is used to prime the TCT
with the VTAM sequence numbers from the last completed LUW from each
VTAM terminal for subsequent message resynchronization by'CICS/VS with
the programmable controller.
Activity keypoints identify the necessity of continuing the backward
scan until all in-flight tasks have been accounted for. Without
activity keypoints, it would not be possible to identify all in-flight
tasks without scanning the entire system log backward to its start.
The recovery utility program (RUP) identifies in-flight task
activity, and transfers automatically logged file control activity,
and user journaled activity from the system log to the restart data
set.
It reestablishes the OCT status of recoverable intrapartition
destinations using information from the latest system activity keypoint,
sync point, or end-of-task records of completed LUWs which had activity
against recoverable destinations.
The transient data recovery program (TDRP) then scans physically
recoverable destination queues on the' intrapartition data set to locate
their latest PUT activity prior to uncontrolled shutdown. This is used
to establish the PUT pointer in the OCT for each physically recoverable
destination.
The temporary storage recovery program (TSRP) uses status information
collected by RUP from the latest activity keypoint, sync pOint, or end
of task records of completed LUWs which had exclusive control activity
against temporary storage destinations (DATAIDs). This status
information reflects the logical status of each destination at
uncontrolled shutdown.
Following the above RUP, ~DRP, and TSRP functions, a new system log
and user journal data sets are then opened by the system -initialization
?rogram for output.
6.
CICS/vS Transaction
~out
Program (TBP)
RUP processing identifies in-flight LUWs and collects their
automatically logged file control activity and user-journaled (to the
log) activity on the restart data set. RUP also identifies user data
sets which had in-flight activity transferred to the restart data set.
Originating input messages and unresponded output messages for in-flight
message-protected tasks are also written to the restart data set.
The CICS/VS transaction backout program (TBP) is executed after
completion of RUP processing, and after a new system log and user
journal data sets have been opened for output. ~he purpose of TBP is
to back out all in-flight activity against user data sets based on
information read from the restart data set.
For messages, TBP places originating input messages and committed
output messages in a temporary storage message "cache", and primes
~CTTEs with the VTAM sequence numbers to be used for reestablishing
message traffic.
TBP provides a number of exits to permit the user to participate in
data set backout. A TBP initialization exit enables the user to ignore
backout against specific data sets. For example, uncontrolled shutdown
Chapter 8.
CICS/VS Recovery and Restart
253
may have occurred because of an unrecoverable I/O error against a data
set. This data set must be recovered by user programs from a backup
copy prior to emergency restart.
Consequently, these data sets should
not have backout activity during emergency 'restart ..
An input exit is also provided. This is given control each time a
record has been read from the restart data set and the user may choose
to ignore specific records.
An error exit is also given control if an error condition is returned
by file control when TBP attempts to back out data set activity.
The
user may specify alternative activity to be undertaken.
(One instance
when this exit is given control is when TBP cannot back out an add due
to the file organization.) If so, the user may back out adds against
VSAM entl~-sequenced data sets or ISAM or DAM data sets by flagging
the added record as "logically deleted." TBP then writes this logically
deleted l,"ecord to the relevant data set on return from the input exit.
User application programs must subsequently check this flag to identify
logically deleted records in the data set..
(see "Data Set Backout"
later in this chapter.)
The result of TBP is to back out all in-flight task activity against
VSAM key-sequenced and entry-sequenced data sets or ISAM and DAM data
sets. The functions carried out by TBP are described in more detail
in "Data Set Backout" later in this chapter.
7.
Messa~
Resynchronization for VTAM Terminals
During TBP processing, input messages for in-flight LUWs or committed
output messages are transferred to a temporary storage message cache
identified by the relevant terminal associated with the message.
Committed output messages, for which positive response had not been
received from the terminal, are optionally retransmitted during
emergency restart.
Input messages for in-flight LOWs can be retrieved
from temporary storage by user-written programs for reprocessing (see
"Transaction Restart" later in this chapter .. )
CICS/VS must establish resynchronization with VTAM terminals on
emergency restart. This is done using the VTAM sequence numbers placed
by TBP in the TCT.
These were established by RUP from information in
the lates"t system activity keypoint, sync point, or end-of-task record
for the last, completed, LUW against each VTAM terminal.
CICS/VS issues
VTAM STSN (set and test sequence number) commands to each VTAM logical
unit, not:ifying each programmable controller of the sequence numbers
known by CICS/VS. The programmable controller can compare these
sequence numbers with those logged on its own disk to determine whether
any messa(~es were lost because of the uncontrolled shutdown.
These
may either be input messages for protected tasks, which should be
retransmitted to'CICS/VS by the programmable controller, or may be
committed 3600 output messages.
Both CICS/vS and the programmable controllers participate in message
resynchronization to ensure that no protected messages are lost because
of the uncontrolled shutdown ..
8.
User ]post-Initialization Programs
Following execution of the recovery utility program and the opening
of new journals, user-written programs identified in the program list
table (PLT) are executed. These programs may carry out
application-dependent recovery functions, such as repOSitioning
extrapartition data sets or other user recovery fUnctions.
254
CICS/VS System/Application Design Guide
9.
Terminal Control Activation
At this point, emergency restart and user backout are complete. The
system initialization program (SIP) then initiates a system activity
Chapter 8.
CICS/VS Recovery and Restart 254.1
keypoint. Following this, terminal activity is initiated, and normal
eleS/VS operation commences.
10. ~.Q.n1.!ol*.§g ~Jly!g~!l! l~11:~il!9 !.m~~g§l!SI jn!~":t
If a ccntrolled shutdewn is then requested by the master terminal
operator immediately follewing emergency restart, the warm keypoint
necessary for a centrolled shutdcwn is taken, and eleS/VS terminates
operation. The system may then te initialized at a later time by a
normal warm start.
SYSTEM FAILURE DURING EMERGENCY EESTART
System failure during emergency restart represe~ts cne of the most
difficult types cf failures to diagnese and correct. The user must be
fully aware of the functions performed during emergency restart, the
sequence in which these functions are performed, aId the effect that
abnormal termination during this operation has on data sets and tables.
Prior to initiating emergency restart, an analysis of the failure
which caused the system to atnormally terminate sheuld be performed.
It is possible that the condition ~hich caused the system to ABEND will
also cause emergency restart to fail. One example of this could be a
physically damaged data set which caused an uncontrolled shutdown,
causing the identical failure during emergency restart if the eleS/VS
transaction tackeut progral attemFts to back out modifications made to
that data set.
If a file centrol data set has tecome physically damaged, a
user-provided data set recevery prcgram(s) must recover the data set
prior to the user backout pregram attempting to back out modifications
to this data set. Data set recovery involves restoring the contents
of that data set from some previeus copy, and then applying all
modifications made to it since the ccpy was taken. eles/vS automatic
journaling (see "Data Set Journaling" later in this chapter), can be
used to keep track of data set mcdifications performed during online
execution.
If the transient data intrapartition data set or temporary storage
data set is physically damaged, it will not be pcssible for eleS/VS to
emergency restart these facilities. eleS/iS reccvery of these
facilities is dependent upcn the physical contents of the relevant data
set as it existed prior to system failure. Therefcre, if the data
content cf the data set has to be restored because of physical damage,
eleS/VS may not te able to successfully reconstruct the DCT or TSUT to
reflect the status of the restored data set.
User journaling may be utilized, if required, tc produce an audit
log of all system data set activity. This audit leg can be created on
a user journal data set, and utilized by user programs for subsequent
reconstruction of all system data sets (such as intrapartiticn or
temporary storage) which Day have teen physically damaged.
CICS/VS emergency restart is net complete until the eleS/VS
transaction backout prograa has successfully completed, and an activity
keypoint has been taken.
(0 ptionally, a con trolled shutdown could be
taken at the completion of user tack out, if system execution is to be
terminated.)
If any failure is encountered prior to this time during
emergency restart, this Frocedure must be followed:
•
!R§ ~s~§ ~t !b§ :si1:Y~§: The cause of the failure of
emergency restart must be determined and corrected. If the
transient data intrapartition data set is daEaged, that
~§!§~min§
Chapter 8.
eIes/vs ReCOVEry and Restart
255
intrapartition data set and the tCT must be cold started by CICS/VS.
Its contents may subseguently te restored by the user. if required,
by post-initialization (~LT) program processing.
(This is also
true for the temporary storagE data set.) If a data set is damaged
it must be physically recovered by user data set recovery programs.
~i§!!'!:
'the emergency restart procedure is
executed again using the original system log as input. The original
systEm log is the ta~e or disk vclume which was being used for
output when the original system failure occurred. As this data
set is not used for cutput during emergency restart, its contents
are available to reinitiate the emergency restart procedure, and
recover CICS/VS to its status prior to abnormal termination.
• .b§!.9.! I.!§X.9.§.!!.£l
At thE completion of emergency restart, the recovered status of
CICS/VS bas been recorded en the new system log if system execution is
to proceed, or on the system restart data set as ~ warm keypoint if
the system is to be terminated. This status represents the predefined
point to which the system is recoverEd; system table, system data set,
and user data set status are all logically synchronized. If restart
becomes necessary from this point'cn, the new system log must be used
for restart.
If thiS system was terminated uFcn completion of emergency restart,
without an intervening systes failure, the system restart data set
contains the fully recovered CICS/VS status in the form cf a warm
keypoint. A CICS/VS warm start Day be perfor.ed using this data to
initiate CICS/VS execution with the recovered system status.
The most significant element in .ystem restart is the recovery of
various data bases utilized by CICS/VS applicaticn programs. This data
base recovery is considered in two SEctions:
• CICS/VS file ccntrol reccvery
• DL/I data base recovery
CICS/VS file control recovery and online tL/I data base recov~ry
will now ba discussed. EatchDL/I data tase recovery is discussed
later in this chapter.
File control automatically logs modification activity against
protected data SEts during nermal operation.
(See "Journa1ing" in this
chapter.) CICS/VS provides suppcrt using the transaction backout
program (TBP) during emergency restart to back out the activity of
in-flight tasks against those prctected data sets.
Since abnormal termination of a task caused by an uncontrolled
shutdown may have prevented it fIca completing its use, and possible
modification, of protected data sets, all data set activity by that
task must be completely reDoved, or "backed out" to restore the data
set to i its status as if the task had never been initiated. Once this
back out :ls complete, the abnermally terminated task may te reprocessed,
if necessary. using the transacticn restart technique descrLbed later
in this chapter in "Transaction BEcovery."
The recovery procedures fer CICS/VS file control data bases increase
in complexity depending upen whether data sets are read-only, or whether
updates, deletions, and additions are made online.
256
CXCS/iS System/Application Design Guide
BEAD-OBLY DATA SETS
Por read-only data sets, no data base recovery is required.
Retrieval of infcraation fro. these data sets dees not result in
subsequent updates, deleticns, or additions. The data sets are not
changed online, and so do not need to te restored en restart.
Bowever, an exceptlon to this is the case when an uncontrolled
shutdown may have resulted frOB an unrecoverable I/O error for a
particular read-only data set. In this case, the user may wish to
follow the procedures for use of a duplicate backup data set described
in "Device Recovery" in this cha~ter.
UPDATE, DElETION, ANt lDtI!ICN TO DATA SETS
CICS/VS provides facilities fer automatic logging of data set records
which are to be updated, deleted from, or added to various file control
data sets. This automatic legging is an cptional facility specified
in the file contrel table by the user for each required data set and
indicates that the data set is to be protected. lith automatic logging
active for a particular data set, whenever a CICS/VS application program
specifies a read-for-update eperation for that data set, the record
retrieved on the read, fer subseguent update, will be automatically
logged (written) to the system log. Similarly, any new records which
are to be added, or existing reccrds to be deleted, will be
automatically logged to the specified journal data set. In this way,
inforaation is aaintained of each record's contents prior to an update,
a deleticn, or an addition of a new record.
This logged inforaation is utilized by the transaction backout
program on emergency restart following uncontrolled shutdown. to back
out the effects of tasks wbich had not completed at the time of
termination. Tbis is discussed Rore completely in "Data set Backout"
later in this chapter.
Chapter 8.
eICS/VS Recovery and Restart
257
JOUBNALI~G
Journaling provides a generalized facility for reporting and
reviewing modifications to data bases and other important data sets •
. The journal centrol program is tatle-driven frOB information defined
by the user in the jeurnal centrel table (JCT). Application programs
may issu4e journal control macro instructions to re~uest specific
journalilog activity.
(See ~l~~L!~ J£~lic§!!2n R12gram~~r's !~i~I~D£~
~s~yal, 5H20-9003.)
Data may be journaled synchroncusly or asynchronously, thus providing
for application processing overlap with journaling operations. In the
synchronous mode, the requesting task is put in a WAIT state until the
jeurnal write has co.pleted ~uccessfully, to guarantee that a journal
copy of data exists on auxiliary storage before user processing
continues. This mode of operatien is similar to the way in which most
CICS/VS management modules function: the user task receives centrol
only when the re~uested eperation ha~ been performed.
The asynchronous mode allews the requesting task to retain control.
The journal write is not synchronized unless and until the task requests
synchronizatien either directly by use of the apprepriate journal
control WAIT macro instructicn, or indirectly by issuing a synchronous
journal request. There is ne guarantee that the journal copy of the
data is written to auxiliary storagE until the user task performs
synchronization.
Journal records consist of a system prefix, an optional user prefix,
and user data. Information Flaced in the system prefix includes:
• Task identification (that is, transaction code)
• Task sequence nu.ber allccated by CICS/VS to uniquely
identify this task
• Terminal identification associated with the task
• Time of day
• Journal data set identificatien
In addition to that detailed above, tbe following information is
provided by the automatic journaling option of file contrel.
• Data set identificatien (internallj generated by CICS/VS)
• Becord
~dentification
sUFplied bj the application program
The user prefix is generally application dependent and is defined
bt the user. For automatic logging~ the user data may comprise the
record read from the data set for updating, the record to te deleted,
or the record to be added to the data set. It may instead be data
supplied by the user task, such as terminal messages.
~~ifi~jUio~
21
~2Yl~jli~g
As in~icated previously, automatic logging may be specified by the
user in the file control table fcr each required protected data set.
Automatically logged inferaation is used by the ifF to back out data
set modification activity initiated by in-flight tasks. The user may
also specify additional journaling activity in the FCT. This is called
automatic; journaling, and it enatles the user to request that activity
(beyond that logged by file contre1 for backout purposes) also be
258
CICS/VS System/Application Design Guide
journaled by file control. This activity may include journaling of
records after an update is complEtEd; for example, for user programs
to recover a data set following an unrEcoverable I/O error based on a
previous backup cepy of the data SEt. Automatic journaling activity
can be directed to the systea log, or to a user journal data set.
(Refer to the ~l~~L!~ ~l§!s~ fI~~iJJJS'!i j~~~~D~§ ~~YAl, 5H20-9004,
for further information cn sFecificatioB of autoEatic logging and
automatic journaling.)
Automatic logging will also be initiatEd by transient data to record
activity against intrapartition destinations defined in the DCT as
recoverable. Te.porary sterage update, add, and delete activity against
exclusive control destinations (tATIIDe) will also be automatically
logged by temporary storage. Refer to 'Transient Data Recovery" and
to "Temporary storage Recovery" latEr in this chapter for further
information.
Journal requests may be made directly by user tasks, through the
use of journal centrel macro instructieBs. User journal records issued
in this way may comprise data for audit purposes, for example, or may
contain data to assist in subsequent 8Fplication-dependent rEcovery,
such as terminal messages.
On a warm start of CICS/VS, ne data set backout is necessary. All
transaction activity was comFleted aDd the system was quiesced when
the previcus ccntrolled shutdown teek place.
On an emergency restart, the CICS/VS-prcvided recovery utility
program (RUP) identifies all in-fli9~t tasks at uDcontrolled shutdown.
It transfers all autcmatically jeurnale4 data set modification journal
records (and other user journal records), written to the system log by
the in-flight tasks to the restart data set. The ClCS/VS transaction
backout program backs out Frotected data set activity initiated by
in-flight tasks. The post-initialization phase is then entered.
During this phase of system initialization, USEr programs identified
in the program list table for use during post-initialization are
executed. These user programs may issue journal centrol macro
instructions tc access user journal data sets, or may read data set
journal records from the rEstart data .et.
The following types ef journal requests can be requested during
normal execution of CIC5/VS by application progra.s. They are eIplained
in more detail in the ~l~~LI~ AE£l~J!jQB iI~g!~~!§I!§ ~!!~iD~~ ~Dyal,
5H20-900 3.
WFITE
WAIT
PUT
NCTE
CHECK
PCINT
GETF
GE'TB
Create a logical record for the relevant journal
data set.
Synchronize request.
Implies WElTE, ilIT~
Note current logical record pcsitioning of journal
data set.
Test return code for any exceptional conditions.
positicn journal to a specified logical journal
record.
Get (forward) next logical journal record.
Get (backward) next legical jcurnal record. For
further discussion c.f the WBI'!E, WAIT, PU'!', and
CHECK journal requests, refer to the ~ICS/V5 ~l§!~.
Chapter 8.
CIC5/V5 Recovery and Restart
259
f~~g.s!~I!§ E~tj!~~~§ ]5~! fer
of the ]QI~,
and .§j~
121Bl', §!II
further discussion
journal requests.
The journaling facility of CICS/VS can be utili2ed by user programs
to journa~ any aFplicaticn-dependent information, which can subsequently
be retrieved by user-written post-initialization programs. This
journaled informat~on may include terminal transactions. A transaction
journal froduced iri this way Frovides a record of every terminal
transaction received by the system, and may also include every output
message sent tc terminals. A terminal input message may te written by
the user to a unique user journal data set and/or the system log,
immediat'sly after a task is given centrol to start processing the input
message. The journaling of the input message should be the first
activity carried out by the initial frcgram which operates on that
transaction.
The transacticn jcurnal may be used for audit and for transaction
recovery purposes (see "Transacticn Eestart" later in this chapter).
Transaction journals developed in this way may avoid the need for BTAM
terminal operators to retransmit transactions on system restart, if
those transactions had teen entered completely befere system
termination.
The first input message received from V~AM terminals for each lcgical
unit of work carried out ty aessage-Frotected tasks (as specified in
the FCT) is automatically logged by the VTAM terainal control program~
Similarly, committed output aessages are logged. CICS/VS uses these
logged messages to establish message recovery and resynchronization
with VTAM progragmable ccntrcllers on emergency restart. Input messages
belonging to in-flight LUis cr ccmmitted output messages for which a
positive response had not teen received, are transferred during
emergency restart to temporary storage. In-flight input messages in
temporary storage can be utilized to resubmit transactions for
reprocessing, after their activity has been tacked out. The final
decision as to whether transacticns must te resutmitted cn restart
depends upon the applicaticn reguirements.
FREPARATION OF USER JOURNALS
Disk Extents that receive journal data set output must be allocated
and preformatted prior to their use in CICS/VS execution. A journal
format utility program is sUfplied by CICS/VS to complete this
formattilog.
(See the ~1~~L!~ QR§!s!i2~ .§uig§.) Cnce formatted,
extents can be (and are) reused for successive CICS/VS executions. The
system o~erator is notified when an extent is full, to enable the
schedulilOg (concurrently with CICS/VS) of a user-written batch program
to copy the journal extent tc an archive data set en disk or tape before
allowing the extent to be reused, if required by the user. A PAUSE
option is provided fer the user to prevent reUSE of the extent by
CICS/VS until the archive cOFY is completed. More than one journal
extent may be specified by the user to permit CICS/VS to make an extent
switch when one extent is full, and to continue CICS/VS operation while
the full extent is being ccpied to the archive data set.
Tape journals may utilize either cne or two tape drives. If one
tape dri'we is used, CICS/VS directs the system operator when another
tape must be mounted, and Frcvides its own tape label management. If
two tape drives are used, it autematically switches to the other tape
drive anla directs the operatcr tc dismcunt the previously used tape.
260
CICS/VS systea/Application Design Guide
The CICS/VS-provided taFe end-of-file utility program may be used
offline to reposition and clcse correctly a journal tape after an
unccntrol1ed shutdown. For the tape system log, this function is
performed by CICS/VS during an emergency restart. In order to enable
the repositioning program to operate properly, the tapes Dust te
formatted (with the CICS/VS-Frovided tape format utility Frogram) the
first time they are used for jourIa1ing.
Logged information is utilized by various CICS/VS programs during
emergency restart to back out the Frccessing of in-flight tasks.
Journaled infcrmation may be utilized during the post-initialization
phase on restart by user-written aFF1icaticn programs (identified in
the program list table). This infcrmation may te read either from the
particular user journal data set, or from the restart data set following
an emergency restart, if it was crigina11y written to the system log
tefore unccntrc1led shutdc~n.
The information included in the system prefix detailed above, and
in the journal control data record, can be used to identify:
• The transaction identificaticn of the task that logged or journaled
the data
• The sequence number of that task allocated internally by CICS/VS
• The identification of the terminal involved
• The time of day that the data set record was written to the journal
data set
For automatically logged data sets, the information in the system
prefix can be used to identify:
• The original data set to which that record be1cngs
• The identificaticn of the particular logical record within the data
set
DATA SET BACKOUT
Data set backcut during eaergency restart is achieved ty the CICS/VS
transaction backout program, which reads data set log records for
in-flight tasks from the restart data set, where they were written by
the CICS/VS-prcvided reccvery utility Frogram as described previously.
The transaction backout program is executed during the
post-initialization phase of emergency restart, and backs out the effect
of these in-flight tasks. See Figure 8-7 for a descripticn of the
transaction tack cut Frogra ••
Chapter 8.
CICS/VS Becovery and Restart
261
INPUT
I)ROCESSING
~
1. CICS/VS Recovery Utility Program (RUP)
reads system log backwards, identifies
inflight tasks, and copies data set log
records and user journal records, to restart
data set.
Log
Transaction
Backout
Progr.am
I
User
Data Sets
...
.. >
to
.. >
[(
\.
.. >
..
OUTPUT
~
... >
(
Restart (
Data Set
2. CICS/VS Transaction Backout Program is
executed after CICS/VS Recovery
Utility Program .
3. CICS/VS Transaction Backout Program
identified in the PLT, reads data set log
records for inflight tasks from restart
data set.
@) Data Set Log
Records are used to backout
effect of inflight tasks activity against
user data sets.
iA
< 1"1
1
.. >
to
I
Backed-Out ~
User Data
~
Sets
Extended Description
@) The "Before" Log Record of an
update replaces the original record in the
data set. A "Before Deletion" record for a key sequenced VSAM data set
is added back to the data set. An addition to a key sequenced VSAM data
set is physically deleted. An addition to other access method data sets is
logically deleted by the user by turning on a "Delete Flag" in the record.
(It is the user's responsibility to subsequently recognize this record as
being logically deleted, via this flag.)
Figure 8-7.
Transaction Eackout frogram (User Data set Backout)
The log records read frcm the restart data set ty TBP are either
the record read from the data set prior to uFdate or deletion, or the
identification of a new record addad to that data set.
For an update, the relevant logical record in the data set is
retrieved, and the ccntents cf that updated record are replaced by the
original data record contents frcm the journal reccrd. The effect of
the in-flight task prior tc system termination is therefore reversed,
and the logical record on the data set is returned to its state before
the update.
For a deletion (which can only be made to key-sequenced VSAM data
sets), the deleted record frcm th,! jcurnal must be added to the data
set again, by the backout FrcgraD p tc remove the effect of the inflight
task.
File centrol auto.atically logs the contents cf a reccrd to be
deleted, before the physical deleticn takes place. It appears on the
syste. log (and hence on the restart data set) as if it were a record
before an update operation. TBP, therefore, first attempts to replace
the data set record by the lcgged record as if to tack out an update.
If a "no record found" error indication is returned, TBP recognizes
262
CICS/VS System/Application Design Guide
that the record is associated with a prior delete operation and adds
the logged record to back cut thE delete operation. This approach
avoids possible duplication cf rEcords, which could otherwise ocCUr
under the following conditions:
a.
Uncontrolled shutdown before delete completed. CICS/VS may have
automatically logged a record to be deleted, but an uncontrolled
shutdown may have occurred tefore the physical delete operation
could be completed.
b.
Restart of emergency restart. In the event of a system failure
during emErgency restart, emergency restart can be run again as
previously described. If a deletion is always backed out by
addition, records which were added prior to emergency restart
failure are added again when restart is performed again.
The TEP therefore, first checks that the deleted record is present
on the data set. If it is, it does not add it again. This ap~roach
permits emergency restart to te rerun as often as necessary without
possible duplication of records.
If the log record indicates an addition, and the data set accessed
is a VSAM key-seguenced data set, a eICS/VS file control DELETE macro
instruction is issued to remove that added record from the data set.
However, if the added record was made to an entry-sequenced VSAM data
set, a DAM data set, or an 15AM data set, that addEd record should be
logically flagged by the user to indicate that it has been deleted.
This can be achieved by user programming developed for use in the error
exit of TBP. Such a "logically deleted" record shculd be ignored if
it is sutsequently retrieved by normal CICS/VS application programs.
Each application program which accesses that data set during normal
eleS/VS operation must check the logical deletion flag set in the error
exit of the transaction backout Frogram, and consider that record
deleted if it is ON. In this way, the addition of records by in-flight
tasks is removed.
CICS/VS application Frograms can also achieve the logical deletion
of a record in a VSA~ entry-sequenced data set, or in an IS1M or DAM
data set by turning ON the logical delete flag as ~reviously described.
The logically deleted record then "uFdates" the original record on the
data set. If the logical deletion must be backed out on emergency
restart, it must be "logically added" to the data set. This is acheived
by turning OFF the delete flag.
However, such a lcgically deleted record appears to eICS/VS as if
it is a normal u~dated reccrd. eleS/VS, during normal operation, logs
the "before" image of the record prior to its update being written.
The before image has the delete flag OFF. During emergency restart,
TBP backs out the "update" (that is, logical deletion) using the
before-image logged record, which therefore automatically "adds" ~ack
the logically deleted record. Thus, no s~ecial user backout action is
necessary.
Backout processing can take place correctly only if the data set
content has not been damaged during the abnormal teraination. This
could occur, for instance, in the case of a power failure. If the
backout cannot take place because of a damaged data set, the user must
recover the data set from a tackup copy before attempting another
restart.
Chapter 8.
eleS/VS Recovery and Restart
263
The facilities described ~revicusly for CICS/VS file centrol backout
are also used, in Fart, by DI/I when used online with CltS/VS.
DL/I LOGGING USING CICS/VS
SlSTE~
leG
Dl';I DOS/VS and IMS/VS nL/I (when used online with CICS/DOS/VS and
CICS/OS/VS respectively) cFtionally direct DL/I log activity to the
'CICS/VS system log by issuing journal control requests. Thus all
CICS/VS and DL/I log activity apFears on the saDe system log.
A CICS/VS application program schedules itself against a DLII PSB
by issuing a PCB scheduling call. (See the relevant ~l~§L!~ .§nd 111tLl
.!lUl!.i~at.~.!! iU29!i.m!~!§ i§tireD~!! .an.Y.f&l.)
The program indicates it
has finished its use of the FSB ty either issuing a DL/I TERM
(termination) call, er by terminating itself.
DL/I logs the scheduling and termination call requests to the CICS/VS
system log, identifying the task and the related PSB name. Between
the scheduling andterminaticn calls, other DL/I calls which result in
modification of DL/I data tases will initiate log activity. Similarly,
CICS/VS activity against Fretected resources idata sets or
intrapartition or temporary storage destinations) will also be logged.
Such log activity will a~peaI on the CICS/VS system log tetween the
DL/I scheduling and termination log records.
DL/I
TER~INATION
AC~IVITl
A DL/I termination call fcrces all DL/I data base records, which
bad teen modified in DL/I tuffers in storage by the relevant task, to
be written to their apprcpriate data bases. The termination call
indicates the logical completion of DL/I activity by the task, which
should net be tacked out in the event of a subsequent uncontrolled
shutdown. The termination call indicates the coapletion of a DL/I
logical unit of work. It also is recognized by CICS/VS as the
completicn of a logical unit of work for any CICS/VS log activity which
preceded the call. Thus it is regarded by CICS/VS as similar to a user
synchronization Fcint.
Similarly, a user synchronizatien pcint request issued by the task
is regarcled as a DL/I termination call request. ~hus, a DL/I
terminat:ion record, and a user sync ~oint record on the CICS/VS system
log indicate completion of the current LUW.
DL/I DATA EASE BACKOUT DURING CICS/VS EMERGENCY FESTAET
Durinq emergency restart, the recovery utility ~rogra. scans the
CICS/VS system lcg backward. End-of-task records, sync point records,
and DL/I termination records enceuntered on the backward scan identify
completed LUWs. CICS/VS and DL/l log activity initiated by in-flight
LUWs is collected by RUP as Freviously discussed. CICS/VS backs out
file control data set activity fcr in-flight LUWs using the transaction
backout ~rogram as described earlier. CICS/VS alse issues the necessary
DL/I calls to tack cut in-flight DI/I activity directly against the
relevant DL/I data bases during emergency restart. It is not necessary
to run the batch DL/I backout utility.
If thE: uncontrolled shutdown was caused by an unrecoverable I/O
error on a DL/I data base, that data base must first be recovered prior
to emergency restart. This is achieved by running the batch DL/I
recovery utilities.
'
264
CICS/VS System/Application Design Guide
ONLINE DI/I ENTBY DATA EAS! EACKOUT TECHNIQUE
DL/I ENTRY permits online replace, delete, and insert operations
against HISAM data bases. Hcwever, it does not provide a backout
utility as does tL/I DOS/VS. The follcwing technique may be considered
by users who wish to iIpleaent their o~n backout support for DL/I ENTRY.
DL/I ENTRY HI~AM data bases are defined to CICS/VS in the PCT as
VSAM key-sequenced data sets.
(A VSAM entry-sequenced data set is not
also used as it is for DL/I DOS/VS or IMS/VS DL/I HISAM data bases.)
These VSAM data sets support update, addition, and physical deletion
of logical records.
DL/I ENTRY uses CICS/VS file centrol macro instructions to carry
out I/O against the VSAM key-sequenced data set used to contain a HISAM
data base.
A DL/I HISAM data base record may cOIFrise one or more VSAM
logical records.
DL/I ENTBY will translate application program calls
to replace, insert, or delete DL/I segments into file control requests
to update, add, or delete VSAM key-sequenced logical records.
If HISAM data bases are sFecified in the FCT as protected VSAM
key-sequenced data sets (that is, LOG=YES), file centrol will
automatically log update, add, and delete requests issued by DL/I ENTRY.
The CICS/VS application program must issue an explicit user sync point
request, at the point where a DL/I termination call is issued, as DL/I
ENTRY will not leg a ter.ination record.
However, the sync point will
indicate completion of the lcgical unit of work. It will also dequeue
VSAM logical records ~hich were medified during the LUW.
In emergency
restart following an unccntrolled shutdown, the CICS/VS recovery utility
program will identify in-flight lUWs and will transfer logged data set
activity for such in-flight tasks to the restart data set. The CICS/VS
transaction backcut prograB will then back out the logged activity
against the relevant VSAM key-sequenced data sets. The user can
participate in this backcut through use of the TEF input exit.
(See
"Transaction Backout Program" earlier in this chapter.)
This backout
will restore the HIS AM data base to its status prier to the initiation
of DL/I activity by in-flight tasks.
The iaplementation of this technique is a user responsibility. The
technique does net represent a cCHmitment by IBM to support backout of
online DL/I ENTRY data baSES. It may require further investigation by
the user to ensure that data baSE integrity is nct comFromised. This
technique is practical fcr DL/I EN'IBY because it does not support HDAM
or HIDAM, and because it uses file control to request I/O.
DL/I
~NTFY
SEGMENT SCHEDULING
DL/I ENTRY does not use SEgment intent scheduling, as implemented
for DL/I DOS/VS cr IMS/VS DL/I when executed online with CICS/VS.
Instead, the specification in the FCT of automatic logging for VSIM
key-sequenced data sets used by HISAM data bases enables CICS/VS file
control protection to be used.
(See "Frotected Besources" earlier in
this chapter.)
When a task requests a replace, insert, or delete
operation through a DL/I call, the relevant file ccntrol I/O request
causes automatic logging for backout, and also enqueues the task on
the relevant file control logical record~ If a concurrently executing
task also attempts modification of the same logical record, it will
wait until the first task dequeues from the record before it enqueues
on the record.
This is done automatically when the application program
issues the CICS/VS user synchronization peint request at the termination
of DI/I activity by the task, or when the task tersinates. The second
task then enqueues on the record and proceeds with its activity.
Chapter 8.
eICS/VS Recovery and Restart
265
The result is data integrity at the VSAM logical record level,
without the potential perfcrKance disadvantage of segment intent
scheduli :Ilg.
TEMPORARY STORAGE RECOVEFY AlTER
CCN~RCLLED
SHUTCCWN
CICS/VS supports the warm start of temporary storage records on disk
following a controlled shutdcwn, but dces not attempt warm start of
temporary storage records in dynamic storage. The following paragraphs
discuss data that can be stored in main storage and that which must bi
stored Oln auxiliary storage for sutseguent warm start following a
controlled shutdcwn.
Temporary storage allocated tc main storage is not recoverable in
the event of either abnormal cr normal terminatien. Although
applicat:ion procedures can be developed to attempt recovery of this
information, main storage generally should be used as a temporary
storage luedium fer data that does net need recovery. Typically, it
should be used only for short-term storage of information, such as fcr
transferring infermation bet~een Frograms executin9 under control of
the same task. If information is to be passed to programs executed by
ether tasks (implying lenger-term stcrage of information), auxiliary
storage should be used.
If, during system initialization, ~emporary stoIage is to be warm
started, the temForary storage warD keypoint (containing, for example,
the tempcrary storage use maF and auxiliary storage data
identifications) is utilized by CICS/VS to restore the status of
temporary storage.
If, prior to controlled system termination, certain data
identifications were released or purged, the warm keypoint taken at
termination will reflect this action. On warm start, this deleted
information will not be used in reestablishing the various temporary
storage aata identifications.
Terminal pages presented ty aFplication programs to BMS are written
to temporary storage on disk for later retrieval either automatically,
or on re~luest by terminal operators. Temporary stcrage on disk is
retained on a warm start, and terminal pages are still available
following system restart.
Similarly, messages to be transmitted to terminals using the CICS/VS
message routing facility are written tc temporary storage on disk and
are still available for transmission on warm start of temporary storage.
266
C1:CS/VS System/Application Design Guide
~EMPORARY
STORAGE RECOVERY AFTER UNCONTROLLED SHUTDOWN
Temporary storage is not recovered by CICS/VS followinq an
uncontrol1 ed shutdown.
Temporary storage in dynamic s"t~oraqE' is lost.
However, a technique is presented later in this section for user
implementation of temporary storage recovery for dynamic storage.
TEMPORARY STORAGE RECOVERY AFTER UNCONTROLLED SHUTDOWN
Temporary storage (on auxiliary storage) is recovered by CICS/VS
during emergency restart following an Uncontrolled shutdown.
Temporary
storage in dynamic storage is lost. However, a technique is presented
later in this section for user implementation of temporary storage
recovery for dynamic storage.
(see "User Recovery of Temporary Storage
Using Dynamic storage. ")
Temporary Storage Automatic Logging
Temporary storage automatically logs activity which results in a
change to the temporary storage data set. This includes the following
operations:
• Output (temporary storage PUT and PUTQ macro inst.ruct,ions)
• Update (PUT or PUTQ with TYPEOPER=REPLACE macro 1nstructions)
• Release (temporary storage RELEASE and PURGE macro instructions)
(Refer to the CICS/VS Application Programmer's Reference Manual,
SH20-9003, for a description of these macro instructions.)
When a task accesses a temporary storage destination (DATAID) for
any of the above operations, temporary storage enqueues the task on
that destination until the end of its current logical task unit of work
if the destination has been defined as protected in the temporary
storage table (TST). Any other task which attempts to operate on the
same destination for other than a nondestructive read request will
result in an attempt to enqueue on the same destination, and will wait
until the first task completes its LOW and is dequeued from the
destination.
The second task is then enqueued to carry out its required
processing.
Any of these operations represent an implied enqueue issued by
temporary storage.
Alternatively, the applicarion program may issue
an explicit enqueue request by issuing the temporary storage G£~ or
GETQ macro instruction specifying TYPEOPER=EXCL.
This may be desirable
when the destination has not been separately defined as protected. The
program must ensure that no other task has concurrent access to the
same destination for the duration of its logical unit of work.
If a record in temporary storage is updated, the old copy of the
record is logged to the system log. This is used to back out the effect
of that update, if a subsequent uncontrolled shutdcwn occurs with the
current LUW still in-flight.
Automatic logging for output and release operations (PUT, PUTQ,
RELEASE, and PURGE) is deferred until the end of the logical unit of
work. At this time, temporary storage forces output of the temporary
storage VSAM write buffer if it contains changed data for the particular
destination (DATAID). The new status of the destination is logged to
the system log identifying the total record count for that DATAID.
If
the DATAID is to be retained, the logical current record count and
total record count are updated in the temporary storage tables in
Chapter 8.
CICS/VS Recovery and Restart
267
dynamic storage to reflect processing activity carried out during the
LUW.
If the DATAID is to be released, the RELEASE or PURGE operation
is carried out at this time. The task is then dequeued from the
destination.
If an uncontrolled shutdown occurs prior to completion of the LUW,
all acti'vity by the in-flight LUW against the temporary storage
destination is backed out on emergency restart.
Temporary Storage Recovery
On emergency restart, the recovery utility program identifies
in-fligh't tasks and collects information defining the logical status
of each protected temporary storage destination at the time of the
uncontrolled shutdown.
RUP links to the temporary storage recovery
program (TSRP), which reads the temporary storage data set to collect
all data pointers required to reconstruct the temporary storage tables
in dynamic storage for protected destinations.
Each record on disk is
self-describing and contains the DATAID and the record sequence number
within a message set (queue). As the data set is read, and the
temporary storage tables are reconstructed, the status of each VSAM
coni:rol interval is determined and used to reconstruct the temporary
storage use map.
At thl9 completion of TSRP processing, all recoverable destinatio~s
have been restored to their most l:ecently recorded logical status with
in-flight LUW activity backed out.
Recovery of temporary storage in this way also restores terminal
paging and message routing.
In addition, interval control requests and automatic task initiation
requests from transient data (which are recorded on temporary storage
by CICS/VS during normal operations, for subsequent recovery) are
reestablished on emergency restart.
USER RECOVERY OF TEMPORARY S'IORAGE USING DYNAMIC STORAGE
The user can specify, at CICS/VS initialization time, that auxiliary
storage residence of temporary storage is not required.
(See the
CICS/VS ~~ystem Programmer's Reference Manual.)
Temporary storage
requests are then satisfied using dynamic storage only. This may be
desirabIE~, for example, in an installation with limited real storage
availability that (except for the use of VSAM for temporary storage
residencE= on disk) does not other\ol1ise have a need for VSAM support.
In this E=nvironment, the user may wish to specify that auxiliary storage
residencE= is not required for temporary storage support, if the
potential performance degradation trade-off is acceptable.
(See
"Virtual Storage Access Method (VSAM)" in Chapter 1.)
The user should also recognize that temporary storage recovery is
not supported for dynamic storage residence. Temporary storage recovery
in this E:mvironment is a user responsibility. The following technique
may be used to implement recovery of temporary storage resident in
dyn.amic storage.
This technique can be used either for a warm start
followinq a controlled shutdown of CICS/VS, or for an emergency restart
followinq an uncontrolled shutdown. It does not attempt to back out
the processing carried out by in-flight logical units of work prior to
uncontrolled shutdown.
It does recover all temporary storage activity
up to thE= time of shutdown. Use is made of the temporary storage
program user exit "before request analysis" (XTYPREQ) to reduce the
amount of coding necessary for recovery in the user's CICS/VS
application programs.
(See CICS/VS SysteIt} Programmer's Reference
268
CICS/VS System/Application Design Guide
Manual, SH20-9004.)
recovery technique.
INPUT
Figure 8-8 illustrates this temporary storage
PROCESSING
OUTPUT
Normal CI CS/VS Operation
User-Written
Application
Program
Temporary
Storage
XTYPREO
User Exit
1. User application program issues GET /GETO,
PUT/PUTO, and RELEASE/PURGE requests.
2. Temporary storage request analysis user
exit intercepts request.
3. User exit journals PUT/PUTO and RELEASE/
PURGE information for recovery.
Temporary
Storage In
CICS/VS
Dynamic
Storage
4. User exit returns control to temporary
storage program.
5. Temporary storage completes original
request by application program.
Warm Start Or Emergency Restart
User-Written
Temporary
Storage
Recovery
Program
6. User-written temporary storage
recovery program is identified in PL T,
and executed after CICS/VS recovery
utility program.
7. User journal data set is read forwards.
8. Any PUT or PUTO journaled request is
reissued to the appropriate temporary
storage data identification.
9. Any release or purge journaled request
is reissued to the appropriate data
identification.
10. When end of user journal reached,
temporary storage has been recovered
to reflect journaled activity.
Figure 8-8.
[[]
[]
Temporary Storage User Recovery for Dynamic storage
Residence
The temporary storage "before request analysis" user exit intercepts
requests from programs which direct data to temporary storage and
journals that data to a user journal data set. This is done prior to
completing the temporary storage PUT, PUTQ, RELEASE, or PURGE request.
The user journal record must contain the record to be written by a
temporary storage PUT or PUTQ macro instruction, together with the data
ID. A request to update an existing temporary storage record must
result in the old copy of the record being journaled. A user journal
record containing only the data ID must be constructed for a temporary
storage RELEASE or PURGE macro instruction.
These user journal records are written to the user journal data set
either synchronously using a journal control PUT macro instruction (see
"Journal Requests" in this chapter), or asynchronously using a journal
control WRITE macro instruction.
Synchronous journaling will ensure
that a copy of the user journal record exists on the user journal data
set before the temporary storage operation is carried out. Asynchronous
journaling enables the journal I/O to be overlapped with subsequent
application program processing. While asynchronous journaling results
in improved performance, it introduces added complexities during
subsequent recovery.
Chapter 8.
CICS/VS Recovery and Restart 268.1
'rhis ~journaling, carried out by user-written code incorporated in
the CICS/vS temporary storage program by means of a user exit, has the
advantagE~ of not requiring any special coding by the applica tion
268.2
CICS/VS System/Application Design Guide
programmer. Furthermore, it permits records directed to temporary
storage (such as terminal ~ages cr routed messagEs) by BMS to he
journa1ed for subsequent recovery also. This additicna1 user exit code
may be easily removed frcm the tem~orary storage program in the future,
if desired.
If a controlled or unccntrolled shutdown subsequently occurs, a warm
start or an emergency restart will be carried out to restore CICS/VS
to its status at ter.ination. This will cold start temporary storage
in dynamic storage, and sucsequently execute user-written programs
identified in the prcgra~ list table during the post-initialization
program phase.
The user-written temporary stcrage recovery prcgram can be specified
in the PLT and executed. This reccvery program reads the user journal
data set forward. As each journal record is read, the data ID and
temporary storage macro instructicn, issued during previous CICS/VS
operation, is issued again tc the same data ID. Any data record in
the journal reccrd is writter to temporary storage using a temporary
storage PUT or PUTQ macrc instruction as originally issued. Any
temporary storage BELliS! or PUEGF macro instructicn identified frcm
the user journal is alsc issued to the relevant data identification.
The result of this program's execution is that all temporary storage
records ~ritten, and EEL!ASEd or PUEGEd, during previous system
operation are reestablished in the same chronological sequence as prior
to CICS/VS shutdown.
CICS/VS supports the recovery cf intrapartition destinations, but
does nct provide sup~ort fcr the reccvery of extrapartition
destinations. Such recovery is the responsibility of the user. The
procedures for recovery cf the two types of transient data are discussed
in the following.
INTBAPARTITION DATA SET BECOVERY APTEE CONTEOLLEt SHUTDOWN
On warm start after a ccntrolled shutdown, CICS/VS reestablishes
all intrapartition destinaticns and reconstructs the destiriation control
table (DCT) entries to reflect their status at termination. The
transient data use bit map (~hich is used for the allocation of tracks
to various intra partition destinations) is also reestablished. In this
way, the status of intra~artition destinations is automatically
recovered on a transient data warm start.
The queue count and trigger level of each intra~artition destination
are reestablished on war~ start cf transient data. Conseguently,
automatic task initiation can be utilized on warm start as if
termination had not cccurred.
Because of the reestablishment cf transient data intrapartition
destinations on a warm start, and the ability to use automatic task
initiation, terminal output directed to transient data intrapartition
destinations is automatically recovered, and will he transmitted to
the relevant terminal as soon as that terminal is in service and able
to receive output.
Chapter 8.
CICS/VS Becovery and Eestart
269
As discussed in Chapter 3, information received from terminals may
be edited, validated, and, if ccrrect, written tc transient data
intrapartition destinations to enable further precessing. This
processing may permit the updating of various data sets, for example,
to be carried out while the terminal is atle to continue entering other
transactions.
Information written to intrapartiticn destinaticns viII be recovered
on a warm start. This enatlEs transactions entered from terminals to
be quickly validated, and then reccrded on disk to allow the processing
necessary for those transactions tc be carried out on warm start of
eICS/VS (if necessary) after contrclled shutdovn. The terminal operator
need not be required to reenter those transactions.
INTBAPAB~ITION
DATA SET EFCOVEEY IPTEB UNCCNTEOLIED SHUT£CWN
CICS/VS provides recovery of the intrapartiticn data set during
emergency restart following an unccntrolled shutdown. The recovery
attributes of each intrapartition destination may be specified by the
user in the DC~. The definition of recovery attributes for each
intrapartition destination causes eICS/VS to autcmatically joutnal to
the systEm log the inforaaticn necessary to recover each destination
queue.
The recovery attributes of an intrapartition destination may specify
either physical cr logical recovery.
fhI§j~s! E££Q~~~l
When physical recovery is specified for a destination, the following
functions are performed duri£g CICS/VS operation:
• The destination entry is keypointed as part of a periodic system
activity keypoint.
• The destination entry is autcmatically logged by the transient data
program to the system log on the first transient data PU~' macro
instruction issued by any task in the system against each physically
recoverable destination, and when the destination is PORGEd.
• The destination entry is autcmatically logged by the transient data
program before executicn cf each transient data GET macro
instruction.
• The destination entry is autcmatically logged, by the transient
data program for reusatle queues, as a track is released - only if
it has been completely read and a new transient data GET macro
instruction is issued to the queue (that is, the record viII be
read from the next track).
During emergency restart, a physically recoveratle queue is restored
by the CICS/VS transient data recovery program as follows:
• The start of the queue, identified in the DCT, is set to the first
track in existence for the qUEue.
• The location
pointer), is
the task (or
It is set to
270
of the Dext reccrd to be read from the queue (the GET
set in thE tCT to the last record previously r~~d if
LUW) that issued the GET did Dot complete successfully.
the following record if the task or LOW had completed.
CICS/VS systeD/Application £esign Guide
• The location of the next recerd to be written to the queue (the
PUT Fointer), is set in the neT to point after the last physical
record present in the queue at emergency restart.
Fellowing emergency restart, each physically recoverable destination
will have been recovered tc reflect all FUT activity. All GET activity
to each destination will also be rEcovered, ExceFt for the last record
which had been rEad ty an in-flight task against these destinations.
This record may not have teen completely processed prior te uncontrolled
shutdown and must te reread en eaergency restart.
Logical recovery results in rEstoring the GET and PUT pointers to
their status at the co.pletien of a logical unit of work (LUW)_. When
logical recovery is specified, rEcoverable destinations are periodically
keypointed in the syste. activity keypeint, and thEir status is logged
at the end of each LUW which uses each destination (that is, at a sync
point or end of task).
This logging is deferred until the end of a LUW, in the event that
an uncentrolled shutdown may cccur during the LUW. If this haFpens,
no record of the activity of the in-flight task will appear on the
system log. On subsequent emergency restart, the status of those
intrapartition destinaticns cperated uFon ,by in-flight tasks is
automatically backed out to the status at the end ef the last LUW which
operated on those destinations.
If an uncontrelled shutdown dces not occur, at the end of the LUW
the status of all intrapartition neT entries operated on during that
LUW is legged as part of the sync point for the LUW. If subsequent
uncontrolled shutdown occurs, the DeT status will te restored to that
at the end of the last LUW fer each destination, or from the last system
activity keypoint.
Destinations are protected for the duration of a logical unit of
work, to prevent interleaved input and output activity. For protection,
each destination is considered tc consist of two separate facilities.
This permits one LUW to have exclusive control of the output facility
and another LUW to concurrently have exclusive control of the input
facility. There is no conflict tEtwEen these facilities unless the
input LUi attempts to read the data records written by an output LUW
while the output LUW is still active. In this caSE, the input LUW
waits until completion of the output LUW.
On emergency restart, the result of logical recovery is for eIes/vs
to back out, from the queues, the activity of these in-flight tasks
which had not completed a logical unit of work at system termination.
Following emergency restart, automatic task initiation, terminal
output and low or high priority Frocessing information on recoverable
intrapartition destinations are rEcovered.
EITRAPARTITION DATA SET RECOVERY
eIes/vs does not Frovide for recovery of extrapartition data sets.
If this is significant to the online application, the system design
team must develop procedures to enable that information to be recovered
for continued eXEcution cn restart, following either a controlled or
uncontrolled shutdown of eles/vs.
Chapter 8.
CIeS/VS Recovery and Restart
271
There are two areas which must be considered in recovery of
extrapartition data sets:
• Input data sets
• Output data sets
The main information required on restart is the number of records
processed up to the time of system termination. ~his may be ~ecorded
during precessing using the journaling capability of CICS/VS, as
described in the following paragraphs and illustrated in Pigure 8-9.
PROCESSING
INPUT
OUTPUT
Normal CICSIVS Operation
1. User application program enqueues on extrapartition data identifications to be operated
on by program.
2. User program reads from relevant extra·
partition input destinations, and accumu·
lates number of reads against each
destination.
13. At completion of logical unit of work, user
program journals number of reads against
each destination to user journal data set,
then dequeues from each destination.
Warm Start, Or Emergency Restart
4. User·written extrapartition input reposition·
ing program is identified in PL T~ and during
post·initialization phase.
5. User journal data set is read forwards.
_ _...... I
6. When journal record for destination is found,
user program reiussues to get macro instruc·
tions for total number of reads to that des·
tination in journal record.
,
1
7. When end of user journal reached, extra·
partition input data sets are repositioned
to point reached when CICS/VS terminated
with any inflight task activity automatically
backed out.
Ex,ended Description
3. If system terminates before user journal
record is written for a destination,
previous journaled information for that
destination is used.
Figure 8-9.
7. As inflight tasks did not complete a LUW
no activity for those tasks appears on the
user journal data set.
Extrapartition InIut tata set User Recovery (Logical
Recovery)
Each application program which reads records from extrapartition
input destinatiens should first enqueue to ensure exclusive access to
those destinations. This will prevent interleaved access to those same
destinations by ether concurrently executing tasks, and so enatle the
user's extrapartition recovery tEchnique to operate correctly. (This
provides a similar capability to that described earlier in this chapter
in "Protected Resources.")
Transient data GET macro instructions are then issued by the
applicati10n program, to read and process extrapartition in~ut records.
The application programs accumulate the total of input records. read
and processed during executicn fer each destination. The total number
of GETs is journaled by the program to a user journal data set, ~ogether
with the relevant destination identifications. This journaling is only
carried out at completion of a legical unit of work, which may be at
272
eleS/VS System/Application Design Guide
end of task or at a user sync point, such as on a conversational
terminal operation (see "Logical Task Synchronization" in this chapter).
Following output of the user journal record, the application program
dequeues itself frog the input destinations, to permit other application
programs to access those extrapa~tition input destinations.
If uncontrolled shutdcwn cccurs prior to this user jou~naling, no
records will appEar on the user jcurnal data set for that logical unit
of work, and the effect of that in-flight task is therefore
automatically backed out on emergency restart. However, if the user
journal record is written tefore unccntrolled shutdown, this completed
input data set processing will be ~ecogni2ed on emergency restart.
On a controlled shutdown, CICS/VS viII wait until the application
program completes executicn Dormally. This will Enable the input data
set activity to be ~Ecorded by thE user for subsequent warm start.
On emergency restart follcwiDg uncontrolled shutdown or on a warm
start following a controllEd shutdown, the followiDg procedure may be
utilized. This will reposition the extrapartition input data sets, to
reflect the input and processing of their records during previous
CICS/VS eperation.
An uncontrollEd shutdown does not permit a taFe journal data set to
be closed normally. This may be achieved through the use of the CICS/VS
tape end-of-file utility program (see "Preparation of User Journals"
in this chapter) prior to execution ef the USEr recovery program.
A user-written extrapartition input recovery prcgram may be
identified in thE PLT for execution during the pest-initialization
phase. This program reads the user journal data set forward. Each
;ournaled record indicates the number of GETs issued to the relevant
extrapartition input data set during previous execution of application
programs. The same number of transient data GET macro instructions is
issued again by the recovery program, to the same input destination as
referenced previously (see FigurE a-9).
On reaching the end of thE USEr journal data set, the intraFartition
input data sets are positicnEd at the same peint they had reached prior
to initiation of tasks which were in-flight at unccntrolled shutdown.
The result is the logical recovery of these input data sets with
in-flight task activity tacked out.
The user recovery of output data sets is somewhat different from
the recovery of input data sets.
For a tape output data set, a new output tape should be used on
restart. The previous outFut taFe can be utilized if necessary to
recover information ~ecerded prier tc termination.
To avoid the loss of data in tape output buffers on termination, it
may te desirable to write unklockEd records. Alternatively. data may
be written te an intrapartition disk destination (which is recovered
by CICS/VS on a warm start or emergency restart) and periodically copied
to the extrapartition tape destinaticn by an autcmatically initiated
task. In the event of terminaticn w thE data is still available on
restart to be recopied.
(This is discussed further in the logical
recovery technique presented below.)
If a controllEd shutdewn cf CICS/VS occurrEd, the previous output
tape is clcsed ccrrectly, and a tapemark is written. However, on an
Chapter 8.
CICS/VS Eecovery and Eestart
273
uncontrolled shutdown such as on a power failure
tapemark will not be written to indicate the end
may te achieved by execution of the CICS/VS tape
program ~ricr to use of that tapE for subsequent
"Preparation of User Journals" in this chapter).
cr machine check, a
of the tape. This
end-of-file utility
rEcovery (see
For a line printer output data set, if it is satisfactory to continue
output from the point reached prier to system termination, no special
action n€ed be taken. HcwevEr, if it is desired to continue output
from a dE:fined point, such as at the beginning of a page, it may be
necessary to use a journal data set. As each page is completed during
normal CICS/VS operation, that fact may be noted by writing a record
to a journal data set. Cn restart, the page which was being processed
at the time of failure can be identified from thE journal data set,
and that page reFrocessed to reproduce that same output again, from
the beginning of the page. Alternatively, an intermediate
intrapartition destinaticn may be used (as previcusly described) for
tape output buffers.
since extrapartition disk outFut data sets are normal seguential
data sets, a difficulty exists in locating the pcint where last output
was written and continuing output f~cm that point. Two technigues for
user reccvery are presented in the following paragraphs, to permit the
end of the extrapartition data set to te located fer subseguent
continuaticn of cutput.
The first technique is suitable for physical recovery of the output
data set. The end of thE data set is located, and output then continues
from that point with no attempt to back out in-flight tasks. This
technique assumes that the programs which will subsequently process
this output data set can detect Fossible duplicate (or missing) records
resulting from lack of tackout on physical recovety and take appropriate
actien. This detection may he achieved by each extrapartition record
having a consecutive sequence number, for example.
The SEcond technigue is suitatle for logical recovery of the output
data set. This also may utilize a ccnsecutive sequence number in each
record (for subsequent program detection). The lcgical recovery
capability offered by transient data intrapartition destinations is
utilized for "spooling" of a logical section ~f data to an
intrapartition destinaticn, and then subsequently copying each completed
logical section to the extrapartition destination. If an uncontrolled
shutdcwn eccurs, the in-flight tra~sient data intrapartition task
activity can be tacked out.
These two techniques are discussed further in the following
paragraphs. The physical recovery technique is illustrated in Figure
8-10.
274
CICS/VS System/Application tesign Guide
PROCESSING
INPUT
OUTPUT
Normal CICSIVS Operation
p,efor0'2
matted
Data Set
. ">
1. Preformatted data set with known
preformatted records is used as
output data set.
... >
2. User program prepares extrapartition
ouptut, but system terminates.
Program
List Table
User Extrapartition
Recovery
Program
.>
Ext,a~~
tltlon
Output
Data Set
Warm Start Or Emergency Restart
3. On restart, CICSIVS initiates user output
data set recovery program identified
in program list table.
4. User recovery program reads previous
extrapartition output data set as an
input data set.
5. User recovery program writes each
record read to extra partition output
DESTID.
6. When preformatted record is read,
ouptut data set is positioned as at
system termination.
Figure 8-10.
(
1<
[]F>
Recove~
Output
Data Set
Extrapartition output Data set User Recovery
(Fhysical Reccvery)
• Physical Recovery
Cn restart, a user program ir the prograa list table is utilized
in the post-initialization phase to read the previous output data
set as an input data set. Records read en restart from the previous
output data set are written to the output destination to be used
on restart. The result is the copying and reestablishment of a
new output data set to the same status as the previous data set
prior to ter.inaticn.
However, to terminate the copy operation, it is necessary to
identify when the end of the previous output data is reached. This
is best achieved by prefcrmatting the entire cutput data set prior
to initial use by Clcs/vs to kncwn record contents, such as records
containing binary zeros. Accordingly, as the previous output data
set is read by the post-initialization prograa as an input data
set, each record retrieved from that data set is checked to
determine whether it is a preformatted record. ihen the first
preformatted reccrd is retrieved from the input data set, the output
data set has been updated to reflect the output location reached
prior to termination. Subse9uent output to that same extrapartition
destination then continues from that point when eICS/iS restarts.
Chapter S.
CICS/VS Recovery and Restart
275
• Logical Recovery
An alternative technique, which can be utilized in the event of
either a controlled or an unccntrolled shutdcwn, takes advantage
of the recovery suppcrt pro~ided by CICS/'S for intrapartition
destinations. This technique requires extrapartition data to be
directed during normal CICS/VS operation instead of to an
intrapartition destinaticn.
(This requires applicaticn programs
to prepare that data as variable-length records, as required by
intrapartition destinaticns.)
Such data is directed to an intra partition destination, rather than
an extrapartition destination.. When a logical section of data (for
example, a printer page) has been queued to that destination (based
upen its trigger level), a task is automatically initiated. This
task reads those reccrds queued to the intra partition destination,
converts the reccrd fcrmat tc fixed-length if required, and then
writes those records to the appropriate extrapartition destination.
This transfer of data from intrapartition to extrapartition
continues until all records currently gueued to the intrapartition
destination have been read. At this point, a transient data PURGE
macro instruction may be issued to release those tracks already
read, for subsequent reuse.
Several dummy records may be written to the extrapartition
destination, when end cf queue on the intrapartition destination
has teen reached. This forcEs a complete blcck cf records in the
e~trapartiticn data set tuffers (QSA~ buffers for CICS/OS/'S) to
be written out. Subsequent programs which read this data set must,
of course, test for these dummy records and ignore them.
An uDccntrolled shutdcwn may cccur before the data currently queued
on intrapartition has teen transferred to extrapartition. If the
transfer task is unable tc ccmplete normally, the effect of that
in-flight task is backed out by CICS/VS on emergency restart. The
data is still available cn the intra partition destination, and can
he subsequently recopied to the Extrapartiticn destination following
restart when the autcmatically initiated task is activated again.
The user must positicn the extrapartition data set at the end of
the last completed logical section {using a sequence number in the
record, for exaDple), before this recopying from the intrapartition
destination (following emergency restart) is i~itiated.
USE OF JCUBNAL CCNTECL FCE SEQUENTIAL DATA SETS
As previously discussed, reeovery of extrapartition data sets on
warm start or emergency restart is a user responsibility. It can
require a considerable amount of user implementation effort. One
approach which may be considered fer user recovery of tape or disk
extrapartition data sets is based on the use of journal centrol by the
user's applicaticn programs in place of extrapartition transient data.
This requires modification of existing applicaticn programs and a
possible data conversion step before processing. However, this effort
can be offset by the additioIal support offered by journal control over
transient data. The following discussion compares the different support
offered by each facility •
• Becord Format
Journal contrel supperts cnly variable-length blocked records with
prefi~ control information preceding the data record.
Extrapartitien data sets, however, may be fixed-length or
variable-length, blocked or untlccked, with DC prefix control
276
CICS/VS System/Application Design Guide
information. Thus, journal control data sets lust be converted if
compatibility is. desired lith existing extraFartition data sets.
• Euffering
eles/os/vs uses eSAft for extraFartition I/O and ESAM for journal
control I/O. eICS/DOS/VS USES SAM for both. Journal control uses
a sOFhisticated buffering techni~ue Ihich can be controlled at
CICS/VS initialization time by using different versicns of the
generated journal centrol tatle (JCT) having varying journal buffer
size and buffer shiftuF values for each journal data set.
(See
~l~~Ll~ aI§!~~ ~I~~I~JJ~l!§ ~§1§1~~£§ ~!~Y~l, SH20-9004.)
• output Buffer Flush
Extrapartition I/O does not enable a task to force output of the
buffer on task termination. Journal control enables a task to
force buffer outFut at any time (see "Journaling" in this chapter).
In addition, a task may close and cpen journal data sets for input
or output at any time.
• Work File Capability
Extrapartition data sets can only be supported as sequential data
sets. Journal data sets effer bcth sequential and work file
capability using journal control NOTE and POINT macro instructions.
• I/O Overlap
Extrapartition I/O is synchrcneus and the task waits for I/O
completion. In additien, journal control I/C can be synchronous
or asynchronous to enable the task to continue processing Ihile
I/O is in Frcgress.
• I/O Wait Time
Extrapartition I/O results in a DOS/VS or an OS/VS WAIT being issued
which causes the entire eleS/VS Fartition/region to wait. Journal
control uses CICS/VS WAIT, which enables the partition/region to
remain active and allcls cther CICS/VS tasks tc Frocess during the
journal control I/O. The result is additional CICS/VS processing
time if journal control is used.
• Volume Switching
Extrapartiticn I/O dees net sUFpert automatic volume switching.
The master terminal cperator can, however, dynamically open or
clese extrapartiticn data sets. Journal contrel supports cne or
two tape drives (or disk extents) for each jcurnal data set with
automatic volume switching. Disk extents are automatically reused,
if insufficient space is allccated. Accordingly, if disk reuse is
to be avoided, the total disk space allocated must be sufficient
to contain the tctal journal data set contents.
• Concurrent Task Access
Extrapartition transient data does not explicitly inhibit two or
more tasks from accessing the saae destinaticn concurrently. To
avoid the consequent data integrity problems (see "Protected
Resources" in this chaFter), each task must eXFlicitly enqueue on
the destination. There is nc similar integrity exposure for journal
control output, as each journal control record identifies (in its
prefix) the originating task number. Journal control explicitly
inhitits concurrent access by two or more tasks to an input journal
Chapter 8.
eleS/VS Recovery and Restart
277
data set. Other tasks will wait until the first task has finished
its use of the data set, and close it •
• Recovery
Journal data sets are preformatted using utilities supplied by
eleS/VS (DFHTAP for taFe and DFHJCJFP for disk). A utility is also
supplied to write a tapemark at the point reached in a tape data
set cit unccntrolled shutdown. (See ~I~~L!~ g~§!~tio]§ §yig~.) The
journal control OPEN macre instruction enables an application
progIam to open a journal data set for either input or output, and
autoDatically positicn the data set at the peint reached at
uncontrolled shutdown to continue I/O against the data set from
that point.
Ther€fore, the system designer may wish to specify that journal
control be used for seguential data sets, in Flace of extrapartition
tranEient data.
INDIRECT DESTINATICNS
The use of indirect destinaticns for providing backup of
intrapartitien terminal destinations or extrapartltion destinations
has teen discussed in this chapter. with the reccvery of intrapartition
transient data bj eleS/vS en restart, all intrapartition indirect
destinations are also reestatlished to their status at the time of
system terminaticn.
However, if a user-written DeT modification program (as described
for terminal backup in this chapter and also in Chapter 4) was used to
modify indirect destinations, theSE user modifications will nQt be
reestablished in the DeT on restart by CleS/VS, since it is not aware
that any modification was DadE. It is the user's responsibility to
journal information when each user DeT modification is made. This
journaled information must then te utilized by useI prograDs on system
restart, to reestablish the same DeT modification in force at
termination.
On restart, unless specific user action is taken, the dump data set
is opened by CICS/VS as if it were a new dump data set. Subsequent
eleS/VS dumps then override earlieE dUDPS produced prior to termination.
To avoid this situation, it may te necessary for the user, prior to
restarting the online system, to print out all dumps taken up to system
termination, by utilizing the CleS/Vs dump utility program.
Alternatively, a user post-initialization program Day automatically
attach the masteI terminal transaction CSMT which will switch to the
alternative dump data set. Iumps prier to system termination are
consequently retained en the original data set, and dumps following
system restart are directed to the alternative dumF data set. The
original dumF data set mal then be FIinted out using the dump utility
program from another batch partition at some later time, when required.
While the master terminal operator can switch the dumF data sets by
using the master terminal cperaticn transaction (CSMT) on system
restart, it is better to make this an automatic fUDction of restart by
specifying a program in the Frogram list table used by the
post-initialization phase, as descrited above.
278
CleS/iS System/Application Design Guide
The CICS/VS program library is a private core-i.age library for
CICS/DOS/VS, or a partiticned data set for CICS/CS/VS.
If no changes are made to the program library during CICS/VS
execution, no special action need be taken to recover this library on
system restart.
If updated versions of CICS/VS apFlication pro9rams were cataloged
to the CICS/VS program litrary pricr to system ter~ination, and the
PPT could not be updated dynamically by the master terminal operator
to point to the new version of the program before termination, on system
restart the PPT is automatically reestablished to Foint to the current
version ef each application frogram. Accordingly, no action need be
taken during system restart fer FPT maintenance, either by
post-initialization prograas or ty the master terminal operator.
The following sections discuss message recovery and transaction
restart considerations first for VTAM and BTAM terainals.
BECOVEBY OF MESSAGES
ASSCCIA~ED
WITH VTAM
TEB~INAIS
CICS/VS automatically lcgs inFut messages for transactions specified
in the PCT as "message-protected," and legs committed output messages
and responses indicating their subse~uent positive receipt by the
terminal.
(See "Protected Messages" in this chaFter.) Automatic
logging only applies to message-protected transactions associated with
VTAM terminals which can sUF~ort message recovery. It is a user
responsitility to carry out this jcurnaling for transactions associated
with BTAM terminals. Inguiry transactions (which do not update data
sets) should not be specified as "protected" in the PCT.
The CICS/VS recovery utility Frogram (BUP) identifies in-flight
tasks during emergency restart and transfers logged input messages or
committed output messages (fer which receipt acknowledgment is
outstanding) te temporary stcrage.
(See Figure 8-11 and "Protected
Messages.")
A temporary storage message "cache" is defined for eac~
terminal which had an in-flight task at uncontrolled shutdown. This
message cache has a unigue temporary storage DATAlt of DFHMXXXX (where
XXXX=four-character terminal identification). This cache contains
either the input message fcr the in-flight LUW, or, if the LUW completed
normally but definite receipt of a cemmitted outFut message was not
acknowledged by the terainal, the committed output message.
A committed output message can cptionally be automatically
retransmitted by CICS/VS on emergency restart to establish message
resynchrcnization. Thus, committed cutput message integrity is
preserved.
An inFut message for an ir-flight LUW is not automatically
reprocessed by CICS/VS on emergency restart. CICS/VS will back out
all in-flight activity for that LUW. The decision tc reprocess the
input message is a user respcnsitility based on factors such as
application requirements and security of informatien. A technique for
user-activated transacticn restart is discussed later in this chapter.
Chapter 8.
CICS/VS Becovery and Bestart
279
INPUT
OUTPUT
PROCESSING
~
>
Terminals
1. CICS/VS logs input messages and committed ouput messages for VT AM
terminals
or
User journals input messages for BTAM
terminals.
F
CICS~
>
System
Log
Emergency Restart
">
CICS/vS
Emergency
Restart
. Support
User
J
PLT
Program
CICS/~
Restart
Data Set
1<
r .>
2. CICS/VS recovery utility program
identifies inflight tasks and transfers
inflight activity to restart data set.
1<
">
>
3. CICS/VS backs out inflight task activity
against data bases, intrapartition, and
temporary storage destinations.
4. CICS/VS transfers VTAM input messages
for inflight tasks or committed output
messages or temporary storage
.... "'----
DJu>
or
User PLT program transfers BT AM input
messages for inflight tasks to temporary
storage.
(
\
J> I
F
User Data
Bases, Intrapartition, And
Temporary
Storage
Destinations
OJ}> (
r
CICS/vS
Restart
Data
Set
/
\
I
CICS/vS
Temporary (
Storage
\
Transaction Restart
=;:-~
>
Terminal
(
C'CS/B
Temporary
Storage
=9
Terminal
Figure 8-111.
... >
., >
5. Terminal operator (or VTAM controller)
initiates user transaction enquiry program.
6. User enquiry program retrieves input
message from temporary storage (if
terminal had inflight task) and transmits
input message to terminal.
7. Terminal operator (or VTAM controller)
specifies input message to be reprocessed
(if application and security factors permit).
-'"
... >
.
~
Original
Input
Message
For Inflight
Task
)
~
Transaction
I
Reprocessing
Message Recovery Transaction Bestart
RECOVERY OF MESSAGES ASSCCIA1ED
WI~H
BTAM TEEMINAlS
To provide for implementation of a user-written transaction restart
each USer task Bust journal its terminal input message as soon
as it co.mences executioD. This can be achieved either ty each task
lINKing to an installaticn-Ievel, user-written transaction jcurnal
prcgram, or by sfecifying this transaction jcurnal program in the PCT
for each transaction code for which in~ut messagES are to be journaled.
In this latter case, aftEr jcurnaling the in~ut message the user-written
transaction journaling program examines the transaction code in the
~rogram,
280
CICS/VS systeB/ApFlicatioD :ttesign Guide
input message, and transfers contrel to the relevant application
Frogram.
Alternatively, journaling of terminal input messages may be carried
out by user-written code in a terminal contrel pregram user exit.
The informatien which ieuld be included by the user in the
transaction journal record is detailed belcw. Seme of this information
is automatically provided in the system prefix by journa1 control.
(See "Journaling" in this chapter.)
• Terminal identificatien
• Operator identification
• Transaction code used to attach the task (extracted from the TCA)
• Time of day when the journal reccrd was writter
• Task priority frem the task ccntrol area (TCA)
• Other informatien reguirEd te further identify that transaction
The above information is inserted in the systEm and user prefixes
of the journal record, and tbe original input transaction from the
terminal input area may be placed by the user's transaction journal
program in the data section ef the journal record.
The user-written transacticn journal program may journal terminal
input messages te a user jeurnal data set and/or the system log. Input
messages written to the user journal data set can be used for audit
purposes, if required. Input messages written to the system log will
be transferred to the restart data set by the CICS/VS recovery utility
program, for in-flight tasks when an uncontrolled shutdown occurred.
This is carried out during emergency restart.
Following RUP processing, the in-flight activity of that task against
data bases, intrapartitien, and temperary storage destinations is backed
out by CICS/VS.
(See Figure 8-11.) User-written Frograms identified
in the program list table (PIT) are then executed.
A user-written PLT pregram shculd read terminal input messages from
the restart data set, where they were transferred by RUP. This program
should censtruct a temporary storage record, using the same temporary
storage message cache format as that established by CICS/VS for VTAft
terminals. This centains thE terminal identification, transaction
code, and task sequence number. This information can be extracted from
the system prefix which ias constructed for the record on the restart
data set when it was originally iritten by journal control to the system
log. The program should flag the message as a task-originating input
record and then write the in~ut message (now in the VTAM temporary
storage message cache format) to temForary storage using a DATAID of
DFHMXXXX, where XXXX=four-eharacter terminal identification.
The input message is then available to the user for reprocessing
based on application requirements and security of information. By
using the same fermat as that used fer the VTAM temporary storage
message cache, reprocessing cf input messages frcm both BTAft and VTAM
terminals can be handled consistently.
(See Figure 8-11.)
As BTAM terminals are unable to indicate definite receipt of specific
output messages as can VTA~ terminals, the VTAM ccnceFt of committed
output messages is net a~Flicable to ETAM terminals. Consequently,
output message journaling by the user cannot ensure output message
integrity. User applicaticn programs should delay issuing BTAM terminal
Chapter 8.
(ICS/VS Eecovery and Restart
281
control ~rites until the comFletion of the logical unit of work. It
is a user responsibility tc identify to terminal oFerators on emergency
restBrt the transactions which were in-flight at uncontrolled shutdown
and subsequently tacked cut. This is necessary tc ensure that the
backed out transactions (whose aFFlication and security requirements
permit) are reprccessed. The follcwing is a technique for
user-activated transacticn restart following emerg~ncy restart.
TRANSACTION RESTART (ETA!
A~t
VTA! TEEeINALS)
At thE~ completion of emergency restart, input messages for in-flight
tasks which have been backed out are available in the temporary storage
message cache for each relevant terminal.
(See Figure 8-11.) An
inguiry ~rogram should be written by the user so that terminal operators
can determine whether their last transaction was fully processed prior
to unccntrolled shutdown, cr whether it was backed ont on emergency
restart. This program should issue a temporary storage GET macro
instruction, using as the DATAID DFHeXXXX, where XXXx=four-character
identification of the enquiring terminal. If that terminal had no
in-flight task, an IDERRCE error indication will te ret~rned to the
program.
(See ~!~~Ll~ JRR li Ss!i2D f!2S!s!J~!!§ R~feI~n£§ AgDYs!.) If
the task was in-flight (cr had a VTAe-committed cutput message), a
temporary storage record will be returned to the program. The program
should check the temporary storage message cache record flag for
presence of an input message, and then present that input message and
associated informaticn tc the terminal operator.
(See Figure 8-11.)
The terminal operator can then decide whether the transaction is to be
reprocessed. A reprocessing request by the terminal operator should
only be accepted if the terminal operator has the necessary authority
(based on security codes, or operator class in the TCT) to make that
decision for the particular transaction. Processing then proceeds as
if the transaction has just teen entered from the terminal.
If the input message is associated with a VTAM programmable
controller, the inquiry Frcgram may be automatically initiated by the
controller after message resynchrcni2ation and recovery have been
completed. The in-flight input message (transmitted back to the
ccntroller by the inguiry Frcgram) may be presented automatically to
the relevant terminal operatcr fcr a reprocessing decision.
Alternatively, if application and security considerations permit, the
controller itself may automatically make the reprccessing decision and
notify the enquiry program accordingly.
TERMINAL OFEEATOE RESTART
The previously described technique enables the terminal operator to
determine, on emergency restart, the status of transactions submitted
prior to unccntrolled shutdown. Ey initiating that transaction inquiry
program, the t~rminal cperatcr is notified whether his last transaction
was completely processed, or was in-flight. If it was in-flight (and
therefore backed out), he is presented with the original input message
to decide whether reprocessing is necessary. If a committed output
message had net teen received by his VTAM terminal prior to uncontrolled
shutdown, it is retransmitted on emergency restart.
Thus, the terminal operatcr is pres~nted with sufficient information
on emergency restart tc allo~ him to identify the point reached in
previous communication with CICS/VS, and reestablish application
processing activity.
282
CICS/VS System/Application Design Guide
If a terminal error is detected, ETAM or VTAM attempts to recover
from the terminal or data transmission error. If recovery is not
successful, that indication is passed to the CICS/VS terminal abnormal
condition program (TACP) for ETA~, or node abnormal condition program
(NACP) for VTAM. The TACF or NACF analyzes the terminal error failure
and may attempt additional error recovery. It then specifies various
default actions (such as requesting that the error terminal be disabled,
the error line be disabled, the errer task he abnormally terminated,
or the error line disconnected if it is a switched line). Control is
then passed to a terminal errer pregram (TEP) or node error program
(NEP) to enable further application-dependent recovery to be taken.
CleS/VS provides a sample TEl which can be utilized to generate a TEP
tailored to the user's requirements (see ~!~~L!~ ~l§!§m R~29~JI!~~
~~t~t~~£~ ~J~YJl for more detail).
Alternatively, a user-written TEP
or NEP can be utilized.
Refer to Figure 3-12 and "Terminal Error Eecovery" in Chapter 3 for
a description of procedurEs which may be coded in the terminal error
or nedE error program by the user to provide, in the event of an
unrecoverable terminal error, for:
• Additional transmission retry to overCome a terminal Error
• Transmission of an output message to an alternate terminal
• Queuing of the output message to an intrapartition destination,
for later transmission when thE terminal error has been rectified
TERMINAL BACKUP
CICS/VS does not provide specific support for tErminal backup.
However, the use of the terminal errer program or node error program
enables various forms of backup to bE implemented by the user. This
may permit terminal aessages to be received cn a backup terminal, if
an unrecoverable error occurred on the terminal which would normally
receive those messages.
Refer to "Terminal Backup" in Chapter 4 for techniques used to
provide backup facilities in the event of unrecoverable terminal errors.
This topic describes the utilizaticn of the terminal error or node
error program, together with neT modification through user programming
to allocate backup terminals or devices.
TERMINAL RECONFIGORATION
The technique described in Chapter 4 for allocation of backup
terminals permits ccnsiderable flexibility in terminal reconfiguraticn
in the event of I/C errors (see "tynamic Terminal Reconfiguration" in
that chapter).
<
Through the destination centrol table (DCT) and indirect
destinations, CICS/VS users can readily iRplement user-written terminal
reconfiguration procedures. The terminal reconfiguratien can only be
achieved by user-written cede to dynamically modify the tCT to reflect
a configuration change. It is the user's responsibility to journal
this DCT modificatien, and reestablish this modification (if necessary)
on system restart, following system termination.
(See "Terminal Backup"
in Chapter 4, and "Journaling" in this chapter, for further discussion
of this requirement.)
Chapter 8.
CICS/VS Eecovery and Restart
283
"Dynamic Terminal Reconfiguration" in Chapter 4 also illustrates
how this DCT modification may be used to dynamically allocate different
devices to receive applicaticn output at different times cf the day,
based upen application requirements.
Techniques for dynamic terminal reconfiguraticn in programatle
controllers are also discussed in "Dynamic Terminal Reconfiguration."
CICS/VS does not specifically provide support for the recovery or
backup of various devices.
If devices such as tape drives, card
readers, printers, or data sets fail during online operation, procedures
must be designed, by the user, tc enable the online application to
continue executicn.
Following failure of a card reader, transactions which would normally
be entered from such a simulated sequential terminal may be entered
from any other terminal (fer example, from conversational terminals
such as the 3270 Information Display system or 2740 Communications
Terminal, or from batch terminals such as the 3735 Programmable Buffered
Terminal, the 2770 Data communications system, or 2780 Data Transmission
Terminal, depending upon volume).
If a line printer fails, the output which would normally be directed
to that ~rinter may be directed to ether devices, depending upon whether
the printer is being used as a simulated sequential ter~inal output
device, or whether it is being used.as an extrapartition output device.
If the printer is being used as a simulated sequential terminal
output device, an alternative terminal can be allocated to receive that
output using the techniques described in this chapter (and in Chapter
4) for terminal backup.
If the line printer is being used for extrapartition output,
procedures similar tc those discussed in "Extrapartition Cevice Failure"
in this chapter may be carried out.
If a tape drive failure occurs, procedures described for
extrapartition device failure may also be applied.
To handle disk I/O errors, application programs should specify in
the CICS/VS file control macro instruction that centrol.is to be passed
to particular routines in the apflication program (or to a common disk
error routine for the installation) on detection of various error
conditions. These routines should free any file I/O areas or file work
areas which are still allocated as a result cf the error situation and
then attempt to retry the operation. If the retry is not successful,
the data set in question may be regarded as having "failed." Such data
set failure may be as significant to the operaticn of the application
as the failure of terminals cr devices as descrited above.
Depending upon the importance of that data set, the design team may
decide to carry a duplicate data set on a different pack. If a serious
I/O error is encountered in the main data set, the duplicate data set
may be utilized in place of the main data set.
When duplicate data sets are to be used, if the main data set is to
be updated, deleted frem, or added te online, then all updates,
deletions, and additions must be applied to each ccpy of the data set.
This introduces extra couplexity when recovery procedures are designed,
since all data sets must be kept in step in the event of abnormal
termination or Frogram failure.
If some of the data sets were updated
and ethers were not, those data ~ets net updated must be trought to
284
CICS/VS System/Application tesign Guide
the same status as the main data SEt, or the updatEs applied to the
main data set must be backed out on restart. See "Data Set Backout"
in this chapter. Complexity is also introduced in the handling of an
unrecoverable I/O error en a write to a duplicatE disk data set.
EXTRAPAR~ITION
DEVICE FAILURE
CICS/VS does not provide suppert for recovery from extrapartition
device failure. If an extrapartition device failure occurs, such as
failure of a tape drive, line printer, or extrapartition data set on
disk, use may be made of preFlanned extrapartition backup devices as
described in the following paragraphs.
Allocation of the extrapartition output to a backup device can be
achieved by using indirect transient data destinations, and defining
backup devices as additional destinations, which are normally open but
never referenced. A user-written DCT modificaticn transaction (see
"Terminal Backup" in ChaptEr 4) Day then be entered by the master
terminal operator to access the relevant failing extrapartition
destination and change that destination to refer indirectly to a
particular backup destinaticn, regardless of whether it is
extrapartition or intrapartition.
If the backup device is an intrapartition ter.ina1 destination, the
failing extrapartiticn destiraticn indirectly points to that terminal
destination, which in turn peints to the actual terminal to be used to
receive the extrapartiticn output. However, to enable an intrapartition
device to be used to back up an Extrapartition dEvice, only
variable-length records can be used for the extrapartition output.
If the backup device is arother extrapartition device, the DCT
modification program changEs the failing destinaticn to indirectly
point to the backup extrapartitien destination, for either input or
output backup.
DL/I DOS/VS and IMS/VS £L/I supply a number of katch utility programs
designed to provide rapid reccvery of a data base rendered unusable
because of:
• Disk I/O errors
• Abnormal task termination
• System failure
Dill data baSE recovery is designEd to provide a rapid, accurate,
and Easy to emplcy means ef restcring the contents of the physical data
base after destruction. The recovery system is supported by four
utility programs which previde fer data base rEcevery frcm the error
situations listed above.
• Becovery from disk I/O errors is achieved by the use of the:
1.
2.
3.
Data
,rata
~~§i ~1! ~! l~§~! ~2£l:
Data
I~§i ~~~I£! J~~Y!Yl~!i2n ~1!li1~:
creation of du.p images of
base data sets fer backup purposes.
accumUlation of data
baSe changes since the last cemplete backup du.p.
~~1~ l~§§ ~~~! ~! Ei~2~~~1 Y~i1i!I:
restoration of data
sets of a data tase using a prior image copy (backup dump)
Chapter 8.
CICS/VS Recovery and Restart
285
and the accumulated changes, together with changes aade
since the last accumulated change run •
• Becovery from abnormal task termination or system failure is
achieved by the use cf the:
q.
£j.§~ ~i~!~.!l.! Jlllli:tI:
relloval of changes made to data
ba$es ty selected applicaticn programs.
]2i1g
These batch data tase reccvery utilities are discussed further later
in this chapter. ThE recovery utilities do not support BSA! data tases,
since HSAft does not support insertions (additions), deletions, or
replaces (updates).
Utilities are not provided by DI/I !NTF1 for
data base tackout.
~ata
base recovery or
During execution of batch application program~ utilizi~g DL/I DOS/VS
or IftS/VS data bases, any ~ata baSE insertions (additions), deletions,
or replacements (updates) are automatically written by DL/I to a DL/I
system leg tape. eleS/VS apFlication Frograms which use DL/I online
result in DL/I activity teing written to the system log.
fATeH DL/I S1STEft LOG
The DI/I system performs the fUnction of logging to taFe of all
information associated with the mo~ification of data within a data
base. The DL/I system log is net required when a data base is loaded,
or when a batch applicatien Frograa only retrieves data (that is,
read-only). The log is required for all other cases.
The logging of data base .odifications, additions, and deletions is
done on a physical basis to facilitate a quick reccvery procedure.
Only DL/I calls that actually cause a change to te made to a data base
are logged. Two sets of infermation, a "before" set and an "after"
set, are logged for each mcdification made. This infor.ation is
directed to the DL/I syste. log when DL/I is used effline or to the
CleS/VS system log when DL/I is used online with cles/vs.
The "tefore" information is that required by the eICS/VS recovery
utility r.rogram when DL/I is online, o~ by the data base backout utility
when DL/I is used offline. It is used to back out a partially completed
update series and to restore a data base to some prior version. This
is described further under "Eatch DL/I Data Ease Eackout" and "Online
DL/I Data Ease Backout" in this chapter.
The "after" information is that required ty thE data base data set
recovery utility to restcre the data base fro. a previous backup ~opy.
This is described further in "DL/I Data Base I/O Becovery" later 1n
this char-ter. It applies to DL/I I/O recovery in both batch and online
environments.
'
In addition to the above, the DI/l system log contains:
• A eICS/VS application program scheduling recerd (for DL/I DOS/VS),
written whenever a eleS/VS aFplicaticn program issues a successful
DL/I scheduling call against a PSB that is update sensitive to one
or more DL/I data bases. See ~L~ ~~Ll lE~}i£A~i2D fk2SXiA,ing
j~~~!~n~~ ~AIY§l·
• A data set open record, written whenever a data set is opened.
• A eICS/VS appl,ication prcgrall termination record, written whenever
a DL/I application program task, iSSUES a DL/I termination call, or
286
eles/vs System/Application Cesign Guide
terminates while still scheduled to DL/I (if a scheduling record
was written for this task).
These three record types are used to facilitate data base recovery.
DL/I RECOVERY UTILI1IES
Data tase recovery is provided by both DL/I DOS/VS and 16S/VS DL/I.
information on the CICS/VS system log for online operation, or on
the DL/I system log tapes for offline operation, and periodically
created tape ccpies cf the data sets representing the data base, are
utilized by DL/I for recovery. The log informatien contains records
which describe the mcdifications made to the data sets within a data
base. The number of log tapes necessary for data tase recovery de~ends
upcn the frequency of data base eo~y executicn, the volume of data base
modification, and the total usage of DL/I. Since information from a
considerable numker cf leg ta~es may be necessary for data base recovery
(all log tapes created since the last data base co~y), a technique for
accumulating all the latest changes to each specific data set in a data
base is provided to permit faster recovery of data bases. This
accumulation of the latest data base modification is performed by the
data base change accumulation utility. ~hus, the information necessary
for data base recovery is contained within the three following sources:
~he
1.
Data base (data set) cc~y tapE created when the data base was
last dumped, through the data base data set image eopy utility.
2.
Data base change accumulatien tape, created from log tapes
available since the last data base copy creation, by the data
base change accu.ulatien utility.
3.
Log tapes employed since the last data base copy creation and
not incorporated into the accumUlation ta~e. ~his includes at
least the log tape in use when ~roblems were encountered with
the data bases.
The data base data set recovery utility program, which is the final
stage of data base recovery, eperates as an application program under
control of the DI/I system. Becevery is done for individual data sets.
In most cases, a data set is syncnymous with a data base. This is true
with HDA! and HISA8 root-only data bases. However, most HISA! data
bases consist of two data sets: a key-sequenced data set and an
entry-sequenced data set. Thus, fer HISA8, if the contents of one data
set are destroyed, it is not neCEssary to recover the complete data
base. Becovery is by direct physical replacement of data within a data
set rather than by logical reprocessing of transactions.
The following functions, illustrated in Figure 8-12, are required
to accomplish data base recovery fcllowing an unrecoverable I/O error
encountered on Dl/I data bases used either offline or online with
CICS/VS •
• log change data for a segment re~lacement, insertion, or deletion,
including the identification of the update segment. This function
is performed autcaatically by Dl/I for all data bases, using the
DL/I system log for tatch or CICS/VS system lcg for online •
• Dump the data set periodically tc provide a backup
data base data set i.age copy utility.
Chapter
e.
co~y,
using the
CICS/VS Eecovery and Restart
287
• Select the change data base leg records from the DL/I system log
or CICS/VS system log and sort the. in order by data base and data
set. If the data set is key-sequenced VSAM, the sort is ordered
by VSAM key. If the data set is entry-sequenced VSAM, the sort is
by entry-sequenced data set relative byte address (RBA). Selecting
and sorting are ~erforDed as part cf the change accumulation data
set creation by the data base change accumulation utility.
• Merge the sorted, selected changed records ~ith the ~rior
accumulated changes, keefing cnly the most recent data. Merging
is performed as part of the change accumulation data set creation
by tbe data tase change accuaulation utility.
INPUT
PROCESSING
==tL_
I
PERIODIC DATA BASE BACKUP
OUTPUT
1. DUMP DATA BASE PERIODICALLY USING DATA BASE DATASET IMAGE - - . r - - - r / l
COPY UTILITY
2. DURING PROCESSING, DLII LOGS CHANGE DATA FOR SEGMENT
REPLACE, INSERT, AND DELETE
_ _ _ _ _ _ _.. ______--1---a---"--..J
PERIODIC CONSOLIDATION OF DATA BASE CHANGES
3. DATA BASE CHANGE ACCUMULATION UTILITY IS USED PERIODICALLY
TO SELECT DATA BASE CHANGE RECORDS FROM DLII LOG, AND SORT
BY DATA BASE AND DATA SET
4. DATA BASE CHANGE ACCUMULATION UTILITY MERGES SORTED,
SELECTED CHANGE RECORDS WITH PRIOR ACCUMULATED CHANGES,
KEEPING MOST RECENT CHANGES AGAINST SPECIFIC SEGMENTS
RECOVERY FROM DISK I/O ERRORS
DATA BASE RECOVERY UTILITY
5. WHEN RECOVERY OF DATA BASES FOLLOWING DISK I/O ERRORS IS
~~=::::;> I :!~~~:::K~~~~:~::~E~C;~T~Ui~:~pC~tp~GES SINCE LAST
lITY
7. IF DATA BASE BACKOUT NECESSARY TO REMOVE EFFECT OF
PARTIALLY·COMPLETED PROGRAMS, OL/I LOG IS USED WITH
BACKOUT UTILITY BEFORE ANY DATA BASE RECOVERY ABOVE
IS CARRIED OUT
- - - -_.. --------_.
Figure 8--12.
-----_._--'
DL/I Data Ease Eecovery
• When recovery is necessary fcllo~ing I/O errors, read the Dost
recent backu~ copy of the data set to be restcred, and merge the
accumulated changes (thereby relcading a partially restored data
set).o Read log tapes Dot included in the most recent accuDulated
changes, and u~date the data set tc the point at which the error
was detected. These functions are performed using the data base
data set recovery utilit!.
All updates to the data set at recovery time may be applied froD
the log tapes rather than from the scrted accumulated changes and the
288
CICS/VS System/Application Design Guide
log tapes if desired. Hcwever, cccasional data set dumps will reduce
recovery time, by allowing all accumulated changes which precede the
dump or reload te be droFped from the sorted change accumulation tape.
When the status ef a data base is not clear because of a system
failure or because the batch programs that were updating the data base
terminated abnermally, the data base backout utility may be used to
back out the effect of those programs. This utility reads backward
the log tapes created by the frocessing of the offending programs.
Using the data base log records thus read, it restcres the data base
to its status at the time abnormally terminated frograms were orginally
scheduled. It also creates a log tafe that Dust be used as input to
any future recovery eperation.
Refer to the ~~Ll ]!il!!i§~ ~~~~~l for DL/I DCS/VS
Y!i!i~i~§ Fe!~~~~~~ ~~~YBl fer further information on
or the lMSL!~
DL/l recovery.
Procedures have been described in this chapter for the backup of:
• Programs
•
~erminals
• Data base devices
• Extrapartition devices
Facilities are provided by ClCS/VS to allow thE warm start (after
controlled shutdewn) or emer~encl restart (following an uncontrolled
shutdown) of:
• various CICS/VS system tables
• Temperary sterage data identifications
• Transient data destinatien ccntrel table
• File centre1 data set backout
• DL/I data base backout
Procedures have also been described which can be utilized through
user-written programs fer:
• Transient data extrafartitior data set recovEry
• Transaction reinitiation en restart
The function of the system design team is tc examine each of the
areas identified above, te determinE whether the facilities available
through CICS/VS and tL/I are satisfactory for backup and recovery, and
to identify whether additienal frecedures or programs should be
developed.
Regardless of how simple, or complex, the online application
may be, each of these factcrs must be considered te determine whether
a backup or recovery problem exists for the online afplications.
Chapter 8.
CICS/VS Recovery and Restart
289
EACKUP PROCEDUEES
standard backup procedures must te defined for each potential failure
situation. For exam~le, action ty the master terminal operator to
carry out program recovery, terminal recovery, or data set or disk pack
recovery must be completely descrited.
The procedures tc be carried cut ty persons such as the system
operator in running £L/1 data base recovery utilities must be defined,
and any additional procedures for recovery of file control data sets
and transaction restart (if used) must be identified.
The most critical time in an cnline application operation occurs
when the system terminates atnor.ally. Because of the need to
reestablish online applicaticn execution as quickly as possible, every
person involved in the reestablishment of the CICS/VS application must
know exactly what is required of him and must te well versed in the
backup procedures defined ty the design team.
To ensure proficiency in the use of these backup procedures, it is
absolutely essential to carry out regular backup "fire drills," either
at scheduled or unscheduled times, and evaluate the performance of each
person involved in the backuI. A wrong action made during system
restart may completely invalidate the restart prccess and the data base
recovery, with disastrous conseguences for the online applications and
the installation.
FAlLBACK DESIGN
Fallback design refers to the design of the online applications such
that information necessary tc fall back to a lower level of operation
is created during normal execution of the online a~plication. An
example ef this vay te the periodic printing of information to be
utilized in a manual fallback environment for answering inquiries. As
part of the backup procedures defined by the design team, each level
of system fallback should te identified. For example, in the case of
an installation having duple) CPUs, the switchover procedures to a
tackup CPU shou~d be fully descrihed.
However, even with two CPUs there is a possibility of both CPUs
going down at the same time (resulting from a power outage, for
example). Accordingly, the Ilext level of fallback after a backup CPU
also becemes unavailable is generally manual fallback procedures.
The design team should develop procedures for each level of fallback,
and ensure that all Ierscnnel are ccmpletely versed in the
implementation of those ~rccedures.
The most critical period in the i.plementation of online applications
is the time of initial cutover frcm the previous procedures used for
those applications to the ne,ly developed online application procedures.
It is at this time that the cnline application is most vulnerable.
Regardless of the amount cf ~rogram testing and system testing carried
out prior to cutover, bugs will invariably still te present in programs,
either because of data inccnsistencies in input cf which no one was
aware, 0:[ because of application and program requirements that were
either peorly designed or incompletely tested.
In addition, regardless of the amount of operator training carried
out prio.[ to cutover, system operators, master terminal operators, and
user terminal cperators .ay not be ccnfident of their ability to
290
CleS/VS systeD/Application Design Guide
function correctly in an online application envircnment. They have
not had an o~portunity tc develo~ full confidence in their own ability,
or in the ability of the designed system to satisfy different
reguirements.
To minimize the effect cf such ~roblems arising at cutover time, a
number of technigues may be used. ~he most commonly used and generally
satisfactory technigue is that of ~arallel processing. In effect, this
involves the doutle ~rocessi[g of information using the previous
application procedures as well as the new online application procedures.
In the event of sericus prcblems develcping in the new online
applications, the previous procedures may still be utilized to ensure
that necessary actions for the application are carried out. While this
does involve duplicate processing, parallel processing provides a form
of insurance against cutcver ~rcblems.
Accordingly, the cutover procedures must be designed before program
development commences. ~his is necessary, as it may be required that
additional facilities be designed into the system to provide for
parallel processing, and alsc prcduce information which can be used to
check the accuracy of online application processing against the accuracy
of the prior application processing.
The i~portance cf complete design for backup procedures, fallback
_ procedures, and cutover prccedures cannot be too greatly emphasized.
Unless these procedures are designed as part of the normal online
application, the system eventually developed may be workable only when
no unusual problems or device failures occur.
Lack cf backup, fallback, or cutover design will drastically affect
the availability of the cnline system and application. Regardless of
how good a terminal response is provided, the online application may
be considered a failure if it does not exhibit high availability owing
to poor backup, fallback, or cutcver design.
Chapter 10 outlines additional functions which must be carried out
during online cutover and subseguent followup, and which should be
considered during initial cutover design.
Chapter 8.
eICS/VS Recovery and Restart
291
This chapter introduces techniques for testing and integrating
CICS/VS application progra.s tc froduce an operaticnal online sys~em.
Experienced CICS users may wish to omit reading this cha~ter, except
for the section "Sequential Terminals." which describes changes in this
support in CICS/VS from that provided in previous versions of CICS.
The testing of individual CICS/VS application programs, and the
subsequent integration and system test of the entire online
applications, must be considered by the design team. CICS/VS facilities
to assist in testing and system integration will new be discussed.
eICS/VS permits the execution of application prcgrams to be traced.
Information relating to the use cf each CICS/VS management routine by
the application program is recorded by CleS/VS in a wraparound trace
table in the CICS/VS nucleus. In addition, application programs may
utilize trace control macro instructions to insert their own trace
entries in the table. When the end of the table is reached, trace
entries at the beginning of the table are overwritten by the trace
control Frcgram. Trace activity may be turned on or off during CICS/VS
execution by the master termibal operator.
(See £~~L!§ ~Y§~!
Agmini§iIA!2I§ §yig~, SH20-9006.)
CICS/VS permits trace entries tc be time stam~ed and written to
tape; a Frogram supplied by CICS/VS lists this tape offline in a
formatted form for debugging purposes. programs may also be developed
by the user to analyze the time-stam~ed trace entries for perfcrmance
evaluation. This analysis may consolidate all of the trace entries
relating to one task in a combined task report, cr may determine the
elapsed processing times of all tasks initiated from a specific terminal
or by a specific transaction code. These elapsed processing times may
be statistically analyzed to deteraine the average, standard deviation,
and 95 percentile values. Similarly, a statistical distribution of
the peak number of tasks in the system dynamic storage usage over a
defined period of time can bE develofed by user analysis programs.
Analysis of the traCE tape is invaluable for debugging purposes and
for evaluation of the performance of existing Cles programs. Potential
performance bottlenecks can be identified and conditions rectified.
In addition to utilizing trace entries, application programs may
issue dump control macro instructions to dump selected parts of
applicaticn Frograms, all the storage associated ~ith a task, or the
entire CICS/VS nucleus to disk. These dumps on disk can be printed at
the end of testing, cr concurrently with testing if the dump data set
is switched to the alternative dump data set. Refer to "Program Backup"
in Chapter 8 for more information relating to the use of the dump data
set in this environment. During testing. the eles online Test/Debug
Installed User Program (Prcgram No. 5796-AE6) may te used. Source
program errors identified by the Online Test/Debug program may be
corrected online by using the CIes Source Program Maintenance Online
Field Developed Program (Program No. 579B-BDT) to update a copy of the
source program maintained on disk.
Chapter 9.
eleS/VS Testing and Integration
293
CICS/VS enables terminal transactions to be entered frem a
"simulated" sequential terainal such as a card reader, magnetic tape,
or disk. The terminal output may be directed to a line printer, tape,
or disk. Througb the use cf simulated sequential terminals, large
volumes of test data may be prepared for what is effectively batch-type
testing. No online terminals need be used or even be present on the
system. Instead, a card reader and line printer, and/or magnetic tape,
and/or magnetic disk may be used for input of simulated terminal
transactions, and receipt cf the output responses from the application
programs.
A simulated terminal transaction may be delimited by a user-defined
end-of-data code in a card, cr by a code in a tape or disk record.
Several card, tape, or disk records may be read by CICS/VS until this
end-of-data code is reccgnized or the input area is full. Large
terminal input messages may be simulated by CICS/VS for testing in a
batch-type envircnment.
The use of CICS/VS terminal device-independence enables simulated
terminal messages from card reader, tape, or disk "terminals" to be
presented to applicaticn Frograms as if they had been read from online
BMS-supported terminals.
The output responses from the aFFlication program are directed to
the simUlated sequential cutFut terminal, which may be a line printer~
another tape, or another disk data set. Again, these output messages
are prepared by the applicaticn Frogram as if they are to be transmitted
to a particular EMS-supported terminal, and are then converted by
CICS/VS device-indeFendent rcutines for output to the appropriate
simulated terminal.
Because testing is carried out in a batch-type environment using
sequential terminals, all test data provided must anticipate the
requirements of the application prcgram for input. This is necessary,
because there is no conversational capability available in testing with
sequential terminals. Consequently, conversational error correction
carried out by the applicaticn Frogram must be simulated by successive
sequential terminal transactions.
The CICS/3270 Simulator Field Developed Program (Program No.
5798-AIC) may be used to test 3270 device-dependent characteristics
using seguential terminals.
SINGLE-THREAt TESTING
The first stage of testing involves the separate execution of each
application program. Only one task is active at a time, and each
program can be tested without considering its interaction with other
concurrently executing Frcgrams. This is achieved by using only one
simulated sequential terminal. As each transaction is read from that
single terminal, the appropriate Frogram is initiated and the
transaction is processed as a seFarate task. When that transaction
complete~ execution, the task terminates, and the next terminal
transaction is read and initiated.
Single-thread testing allcvs the logic of application programs to
be debugged withcut comFlications caused by the icncurrent execution
of other programs.
The next stage after all application programs have completed
single-thread testing is Dultithread testing.
294
CICS/VS System/Application Design Guide
MULTITHREAD
~ESTING
Multithread testing is equivalent to single-thread testing, except
that several sequential terminals are utilized for entry of simulated
terminal transactions. Each sequential terminal will result in the
initiation of one task at a time to process each transaction read from
that terminal. Not until a transaction has been completely processed
will the next transaction be read from that terminal and another task
initiated. However, at the same ti.e, tasks may te initiated to process
transactions from the other sequential terminals. These programs from
each sequential terminal execute in a limited multitasking environment,
the number of concurrently executing tasks being equal to the number
of simulated sequential terminals.
A series of simulated sequential terminals may te set up, either
using several card readers and printers, or, more commonly, using many
tape and disk sivulated terminals.
An approach which may be utilized in this multithread testing
environment is to take the test stream which was used for single-thread
testing, and copy that test stream to each separate sequential terminal
on disk or tape, at the same time randomizing thE sequence of
transactions in the separate copied test streams. A number of
sequential terminals may then be made active to allow multitasking
execution to be tested. The outIut from each terminal should be
identical to the output for each transaction as a result of
single-thread testing.
The CICS Network Activity Simulator Field Developed Program (Program
No. 5798-CCH) may be used to assist. in multithread testing with
sequential terminals. Refer to "Related Publications" in the Preface
for relevant publications.
system testing generally involves the progressive checking out of
all program logic and application functions, to Ensure that all elements
of the online apIlication, and all programs, fit together and execute
correctly.
TOPDCWN 'JESTING
In Chapter 2, the technique of "tcpdown" programming was discussed.
Briefly, this involvES develcping the programs at the highest level
first, linking to lower level programs which arE initially implemented
by dummy programs. These du~my prcgrams note thE fact that control
was passed to that lower level program and return control to the next
higher level program. Ccnse9uently, the highest level programs are
developed and tested first, and thEn successively lower level programs.
The need to develop higher level test drivers (which is a problem with
the traditional bottom-up coding and testing technique) is avoided,
since the highest level routines provide the system integration and
also function as test drivers for lower level prcgrams. As progra~
testing progresses, system testing is also carried out automatically.
Eventually, programs at the lowest level are coded and tested.
Because the development and testing of programs proceed in a topdown
fashion using the structured programming technique, the problems and
delays involved in having to move back to lower levels to check the
correction of bugs with the traditional bottom-up method of programming
are not apparent. Highest level programs and the entire system
integration are tested out first, and then successively lover level
Chapter 9.
CICS/VS Testing and Integration
295
programs are tested. As bugs are fcund in lover level programs, they
will usually only affect those lcwer level programs.
Tcpdown programming and testing ensure that prcgram interfaces are
fully defined, ccded, and te~ted befcre lower level programs are
develo~ed.
Consequently, the interfacing of all the different
components of the cnline a~plications is made easier.
296
CICS/VS system/Application Design Guide
This chapter discusses factors which should be considered by the
system design team for cutover of the online applications to live
operation, and their subsequent follcwup to evaluate the effectiveness
of the operational applications. Experienced CleS users may wish to
omit reading mest ef this chapter.
As mentioned, the cutever period cf online ap~lication development
is the most critical period of all. Regardless cf how thorough program
and system testing may have been, bugs will invariably occur at this
time, with possible disastrous ccnsequences. Similarly, regardless of
how thoreugh operator training has been, during the cutover period
operators may not have sufficient confidence in themselves, or the
system, and may make unnecessary mistakes.
Accordingly, to minimize the effects of cutover problems, it is
generally recommended that cutover to the online a~plication be made
in parallel with norgal ~rior ap~lication procedures. In this way, if
serious problems develop, the prior application procedures can continue
without disrupticn to the ap~lication. In addition, the results of
the online application execution can be compared with the normal results
of the prior application procedures for further evaluation of the
effectiveness of the online system.
TEB!INAL OPERATOR
~RAINING
Complete training must be given to terminal operators prior to
cutover, to ensure that they are completely familiar with all procedures
required of them during online a~plication execution. These procedures
should be documented in a Terminal Operator's Marual, which should
include standard CICS/VS terminal operating procedures and transactions
(such as the CICS/VS operator signon procedure), as well as the
particular terminal operating procedures and transaction formats to be
used for the online applications. All applicaticn error messages should
be fully identified in this Danual, together with the cause of each
error and the action required by the terminal operator to recover from
that error situation. The use of a "HELP" transaction, to enable
terminal operators to obtain more information relating to errors, may
be considered in addition to, or as an alternative to, a detailed list
of all error messages in that Terminal Operator's Manual. Refer to
"Error Correction" in Chapter 3 for more detail.
Procedures should be defined for the terminal operator to enable
him to recognize system, terminal, or line failure situations. The
corrective action or backup procedures which he should follow must be
completely described. The effectiveness of terminal operator training
is measured not cnly when the system is running correctly, but also
when problems occur, or when system downtime occurs. If the terminal
operators are sufficiently well trained to recognize these situations,
and know exactly what to do to recover from the situations so that
there is no panic, terminal cperator training has teen adequate. As
mentioned elsewhere in this ~ublication, the effectiveness of online
application design, develo~ment, and training can best be judged when
error situations arise.
Chapter 10.
CICS/VS Production cutover and Followup
297
MASTER TERMINAl CPERATCR TFAINING
The master terminal o~eratcr must receive all the training given to
the ether terminal operators, in addition to extra training for general
administration of the CleS/VS system and entry of all master terminal
commands. The master ter~inal cI€ratoI has the cverall responsibility
for the correct functioning of the system and must be able to recognize
failure conditions quickly and take the necessary action.
It may not be immediately evident to him that a failure situation
has arisen. Certainly if the CPU goes down, this situation is
immediately evident. However, a similarly serious failure situation
may occur because of continucus I/O errors on critical terminal lines,
or on critical data sets or data bases. This may not be immediately
apparent~ and in fact the online application may be able to continue
operation with that failure situation, even though it may be operating
in a degraded mode. However, the degree of degradation ewing to error
recovery procedures may make the cnline application unworkable. In
this situation the master terminal oFerator must be sufficiently well
trained to recognize the Ircblem and be aware of the corrective action
he must take.
SYSTEM OFEEATOE
~EAINING
The system operator must be ccmpletely trained in CICS/VS initiation
and termination, as well as in the CICS/VS warm start procedure.
Provision is made by eICS/VS to enable a tailered CICS/VS system to
be generated. This tailcred system may be initiated, or specific
functions may be overridden cr reFlaced, during system initialization.
Different versions of tables may te utilized at system initialization
to support different terminal configurations, data set configurations,
transaction codes, or programs on different days if necessary, or in
the event of failure situatiens. ~he master terminal operator specifies
the particular initialization requirements to the system operator, if
the standard application Eystem is not to be initiated. The system
operator should normally not be required to interact with CICS/VS except
for system initiation. The master terminal operator normally' specifies
through a master terminal command when the system is to be terminated.
The system operator is therefore able to concentrate on other
concurrently executing batch applications.
Particular care should be observed hy all personnel during cutover.
with the parallel processing of Frior application procedures with the
online aFplicatien procedures, personnel must be fully trained in the
use of additional information produced by the online application to
aid in parallel cutover, or in the checking of online application
results against results frcm the prior application procedures.
Once cutover has been successfully made, and the prior aPFlication
procedures are stopped to enable the online apFlication to assume full
control, regular followup must be made. This follcwup comprises a
number of factors, such as:
• Accuracy of operation
• online application user satisfaction
• statistics evaluation
298
CleS/VS System/ApFlication Design Guide
• Ferformance evaluaticn
• Accuracy of operation
During parallel testing, the accuracy of the online application should
be fully checked. Procedures should be developed during system design
to allow this accuracy to te further spot-checked at various stages
after cutover, to ensure that no changes have cccurred in the
applications or data to invalidate particular application programs
or system design. Procedures should be initially designed into the
online application to ensure that necessary information to allow this
checking will be provided •
• Online application user satisfacticn
Regardless of how well an cnline application operates, or how
satisfactory a terminal response is provided, the ultimate evaluation
of the usefulness cf thcse cnline applications comes from terminal
users. As mentioned at the beginning of this publication, to ensure
that application requirements are fully met, a member of each
particular user department which will use the online applications
should be present at certain phases during system design. output
produced by the system, and the information which the user department
must be able tc enter into the system, must be meaningful to that
user. Proper participation of user departments during the initial
design phase will ensure that the subsequently developed system meets
their requirements.
During the training of user terminal operators, any areas overlooked
during the initial design phase may become obvious. Although this
is very late in the development cycle, depending upon the
modifications necessary and the urgency of providing those
modifications, action may te taken at that time to increase the
usability of the system to the terminal operators.
The design team should be aware that, regardless of how well a system
may be designed, and even with considerable user department
participation during design, it is often not until user departments
have had some operational experience with the online application that
they realize t~at certain improvements may be desirable. Their
understanding of their own requirements prior tc cutover of the online
application may differ froa their requirements after they have had
some experience with the online application.
Modifications identified through actual terminal experience in a live
environment may be incorporated into the system in a future version.
The design, development, and testing of this future version must be
carried out using the design techniques already discussed.
• statistics evaluation
Statistics provided by ClCS/VS, either on individual request by the
master terminal cperatcr, cr periodically on request, or automatically
at system termination, should te accumulated historically. Through
user-written programs to analyze these statistics or through use of
the ClCS/VS program supplied to edit periodic statistics, the
performance of the system cver a period of time may be evaluated.
(See "Ferformance Monitoring" in Chapter 7.) For example, generally
the transaction volumes in an inquiry application will rapidly
increase once the system is operational, particularly if the inquiries
are providing useful informaticn to the user departments. This
increase in transaction volumes Day have an effect on the overall
Chapter 10.
ClCS/VS Production cutover and Followup
299
performance of the online system. Historical analysis of the CICS/VS
statistics enables these situaticns to be identified, and action to
be taken, before the overall Ferformance is drastically affected •
• Performance evaluation
Performance evaluation may be cased upon the eleS/VS statistics taken
at particular times or uFon the historical statistics analysis
described above. Using the information provided by the eleS/VS
statistics, it may be desirable to change the allocation of various
data sets on disk, tc recrder some of the eleS/VS tables (such as
the pct or PPT, for example, tc ensure that high activity transactions
and prcgrams are near the head of the table and so reduce the amount
of table searching), or to increase the maximu~ number of tasks
allowed to execute concurrently~
In addition, it may be desirable to increase the total eICS/VS virtual
partition size to enable mcre dynamic storage to be utilized. This
may increase the CICS/VS wcrking set and hence ccntention with other
partitions for the available page pool, and may result in increased
paging with a consequent effect on online performance. The master
terminal operator may dynamically control the si2e of the eICS/VS
working set, and hence real storage contention, ty varying the
MAXTASKS value if more than one task may be concurrently executed.
Befer to "CICS/VS Working Set" in Chapter 7 for &ore detail.
eICS/VS is generally given the highest priority partition, so that
increased paging may ce reflected in reduced thrcughput for
concurrently executing batch partitions. If the amount of dynamic
storage which must be allocated for CleS/VS increases significantly,
so as to cause sufficient Fagin~ to seriously degrade lower priority
batch partitions, it Day be necessary either to reduce the numter of
batch partitions executing concurrently with eICS/VS, or to increase
the real storage size of the machine and so increase the available
page pool.
(Befer to "eICS/VS Working Set" for further discussion.)
The flexibility available to the CICS/VS installation through the
use of virtual storage enables CICS/VS online applications to be
tuned for satisfactory operation, provided the system design has been
carried out intelligently and effectively. The ability of a virtu~l
storage system, and of CICS/VS, to dynamically adjust to changing
work leads enables satisfactcry cnline performance consistent with
batch performance to be achieved.
When the available page FocI is increased by the installation of
additicnal real storage, that real storage is made available not only
for extra online performance, tut also for extra batch processing
performance. Bea1 storage in a virtual storage environment is a
performance resource, rather than a critical machine resource without
which the applications may not have been atle to be executed.
300
CICS/VS system/Application Design Guide
This chapter cutlines a number of typical CICS/VS applications in
several industries. Its objective is to identify common functions,
data sets or data bases required, and the online and offline programs
which may be needed. Guidelines are presented tc assist the user in
the selection of the most ap~ropriate data base support for his
installa tion.
Because of differences in usage of applications across various
installations, this chapter does nct attempt to develop complete
application designs. It identifies only the most common problems and
approaches, and is intended as a starting point for more detailed
application design by the user.
Only those application areas relevant to the user's own industry
need be read in detail. Hcwever, review of other industry applications
can be useful in identifying solutions to application design problems.
As discussed in Chapter 1, the logical starting point for the system
design of an online application is tc define the application
requirements, objectives, and system flow, and outline the programs
and data sets or data bases required. This phase is referred to in
this publication as Application Design.
Obviously, it is not possible to discuss all data processing tasks
that lend themselves to cnline operation. However, by examining the
design of a number of representative applications, a fundamental
approach to application design can be defined. At the same time,
requirements which are peculiar to a particular application, and which
require specific attenticn during system design, can be identified.
The applicaticns discussed in this section are introduced
conceptually in the ~l~LI~ §§n~~~l lni2~Bati~D ~~~. The following
topics describe these applications in more detail and use these
applications to illustrate various design approaches for systems and
applications to be executed under the control of CICS/VS.
Specific design techniques relating to data base support are
described for certain applications. In most cases these techniques
are applicable nct only for the applications to which they refer, but
also to most of the other applications discussed below.
In the manufacturing industry, a typical online application may
provide the following functicns:
• Add new manufacturing crders
• Locate orders in process
• Provide order status
• Monitor manufacturing orders in the shop
Chapter 11.
CICS/VS Application Design
301
This c)n1ine app1icaticn may be referred to as an online manufacturing
work order system or as a prcducticn order and status reporting system.
CICS/OS/VS supports the IEM 3ESC Mass storage System. 'Ihis system
allows large data tases tc be accessed online for applications with
low transaction volumes which can tolerate low response times.
(See
"CICS/OS/VS - 3850 Mass Storage Operation" in Chapter 7.) Typical
applications are the online residence cf engineering drawing data bases
and technical reports to te retrieved using the STAIRS/VS Program
Product (Program No. 57LO-XR1). See ~1l1i~L!~ §!D§I~ lDi2I!J!i2D
Ma.lli:lg!, GH 12-5114, for addit ional information.
PRODUCTICN OEDER AND STATUS FEPOETING SYSTEM
This online app1icaticn provides manufacturing management and shop
supervision with accurate, comprehensive reports concerning:
• Order location
• Schedule viatility
• Status condition
Figure 11-1 illustrates this online application.
has the capability to:
The application
• Add new manufacturing work crders
• Change existing manufacturing werk orders
• Split a manufacturing werk order
• Beport the status of a particular work order
• Provide a general inguiry capahility
PROCESSING
INPUT
1. Intertogate parts status and
report progress.
Add
2. Add work order record and
alloc.ne work order number.
Change
3. Correct or modify work
order record.
Split
4. Split work order into two records
and ddjust quantities.
C
'-----J,------.""""
_~
5. Store inquiry request for
batch processing.
1...--..-_ _
6. Extract requested information and
sort
7
IOt0
required sequence.
Extract records of unfilled
orders.
8. Determine work loads.
9. Determine behind schedule
positiOn.
Figure 11-1.
302
Manufacturing Froduction Order and Status Reporting System
CICS/VS system/Application Design Guide
DA'rA SETS
Three data sets are required by this application. One contains the
manufacturing werk crders, which are the heart of the application.
This data set contains a reccrd for each manufacturing order. A typical
record format for this data set is shown in Figure 11-2, which details
various information to be keFt fcr the manufacturing order, together
with the last reported status of the order. Following this, there may
be a variable number of status transactions against this order, other
than the last reForted.
~
Split
No.
Work
Order
No.
Planning
Dept.
Date
of
Issue
Lot
No.
InWork
Date
Complete
Date
Part
No.
Initial
Stores
Final
Stores
Qty.
r
J
Authorization
Model
No.
Figure 11-2.
Next
Assy.
Part
No.
Quantity
Complete
Material
Type
Last
Status
Of Work
Order
Last Status of Work Order
Numbers
No.
No.
Manufacturing Work Crder Record Format
The second data set is a part numter cross-reference data set.
relates a part number to all open manufacturing erders for that
particular part. Pigure 11-3 shews a typical part number
cross-reference record, which illustrates a multiple number of
manufacturing work orders which USE that part.
This
Part Number
pigure 11-3.
Part Number Crcss-Eeference Record Format
The third data set is the manufacturing planning data set, which
contains a record for each manufacturing order that has teen planned
and that will be released to the shop floor for werk. Figure 11-4
shovs a typical record format fer this manufacturing planning data set.
This data set is required for audit trail and control functions.
Program
Project
Figure 11-4.
Part
No.
Model
Unit
Release
Number
Work
Order
No.
Quantity
Date/Time
Sequence
Number
Manufacturing Flanning Record Format
The most suitable data base support for these three data sets will
be discussed shortly. Hcwever, tefore a decision is taken on the
particular data base support, the application design should broadly
define the various programs which are to process the input from
Chapter 11.
CICS/VS Application Design
303
terminals for this applicaticn.
Their function is shown in figure
11-1.
ONLINE PEiOGRAMS
The add program generates a new reccrd in the manufacturing order
data set for each new manufacturing crder. This record contains the
information illustrated in Figure 11-2, less the status fields which
are generated at a later time. In addition, the program places the
manufacturing erder Dumber on the ~art number cress-reference data set.
The change program allows the manufacturing order record to be
corrected er medified as required.
It is often necessary te split a manufacturing crder because of part
quantity change requirements with respect to schedule_ the split number
uniguely identifies each split cf the crder. The split program splits
the manufacturing order; that is, it generates a new manufacturing
order record with a unique split number. It adjusts the quantity in
the two manufacturing order records in accordance with total quantity.
~!aty~ In,gui~~ R!Qg~!~
-
i§R~'!§ R~!~ ~!atu§
The status inquiry prcgra. allows the shcp to report the progressive
status of parts as they flcw to various operations within manufacturing.
The status is interrogated, and the appropriate action is taken. A
status field, which is also used in batch programs to produce status
reForts, is added to the manufacturing order record.
status inquiry FrcgraDs may handle the processing of inquiries in
both online and batch environmentso Requests for batch reporting are
stored in a temporary data set to he used in processing regularly
scheduled reports.
OFFLINE FlROGRAMS
The atove programs enable the cn1ine applicaticn requirements
described earlier to be met. The application also requires a number
of additional prcgrams tc select and format reports in the batch
environmEnt.
i§~Q!!
jrite!
R~2g~!!
The report writer program selects and formats offline reports
periodically. This progra. sequentially processes the manufacturing
order data set, selecting the desired manu£acturing order records for
inclusion in the report. Inclusion is determined either on the basis
of a request submitted by manufacturing or on an exception reporting
tasis.
30Q
CICS/VS System/Application Design Guide
The unload and select program unlcads the manufacturing order data
set periodically and selects the applicable records for input to the
productien order status reFort program. As part of this program, a
data set statistical report for data set reorganization is produced.
The load program reloads the manufacturing order data set, using
the backup created by the unload and select program as input. It
eliminates any overflo~ and deleted records.
Pro~y~ti~~ QIg~I ~!~!y§ R~E21! i,~g~s~
Using data set information prcvided through the unload and select
program, this program prcduces production order status reports. These
reports provide information about all unfilled manufacturing orders in
an effort to give the manufacturing department up-to-date information
regarding work leads and/or tehind-schedule positicn.
The selected report writer program allows manufacturing personnel
to vary the range and sorting se~uence of several types of reports.
For example, manufacturing may request a part number report for a
specific department, and for a specific model and unit, and receive
only those manufacturing order numbers which apply to those criteria.
This program allcws manufacturing to produce many unique reports.
DATA BASE SUPPOR1 SELECTION
The mcst suitable data base support for the online system should be
selected at this time. The facters ~hich can be taken into account in
making this decisicn are described in "Data Ease Selection Criteria"
in Chapter 5.
DBOMP (Data Base Organization and Maintenance Frocessor - Program
Product (DOS) 5736-114) has teen widely used as the main batch data
tase support in the manufacturing industry. However, it is not the
purpose of this publication to discuss the use of tBOMF. DL/I products
offer data base support which surpasses that provided by DBOMP in many
respects, such as improved data independence and device independence.
This data and device independence may result in significantly less
program maintenance and data base maintenance than experienced with
DBCMF.
The support of lcgical relationshiFs and secondary indexing (see Chapter
5) by DL/I ENTRY, DL/I DOS/VS, and I~S/VS DL/I, assists in the
conversion of existing DEOMP data bases to DL/I.
The Chained File - DL/I BIidge Program Product (Program No. 5748-XX3)
can be used fer ccnversicn cf chained file systems, such as DEOMF, to
DL/I DOS/VS or 'IMS/VS DL/I. Eefer to "Related publications" in the
Preface for relevant publications.
The manufacturing order data set may contain a multiple number of
status segments (see Figure 11-2). FUIthermore, the part number
Chapter 11.
CICS/VS Application Design
305
cross-reference data set (see Figure 11-3) contains a segment for each
manufacturin~ order number associated with a particular part numter.
since a vart may be used with many different manufacturing orders,
there may be a very large nURber of these segments associated ~ith each
part numter. These data sets are particularly suited to DL/I. A
typical logical structure for these data sets is shown in Figure 11-5.
Root Segment
Work
Order
Number
l
Root Segment
Part
Number
Details
ManUfacturin]
Work Order
Details
~~]JJ
Number
Status
I
I
Work
Order
Number
----Work Order
Data Base
Figure 11-5.
--
Part Number Cross-Reference
Data Base
Manufacturing Data Base Logical Structures
The manufacturing planning data set (see Figure 11-4) has no
dependent segments associated with it and does net require DL/I support
specifically. However, DL/I can support it as a root-segment-only data
tase.
Since the segments in each data base previously described are fixed
length, a:ny of the DI/I products may be selected.. Addition and deletion
activity may be accumulated cnline in a eleS/VS file control data set,
and applied to the data tuffer offline ..
Befer to '''Sample Applicatiens" in ~lLl ~Q§L.!§ ~§Jlilil lnigDlllion l1iJlY~l
for furth,er discussicn of the use cf DI/I in the manufacturing industry.
ele'§L!'§_l';i:l~ eC!l:U~l ~1l121H2!!
DIll is a suitable data base suvport for this cnline manufacturing
application.. However, if cne cf the DL/I products cannot be used,
eleS/VS file control support should te selected.
The support of multiple dependent segments in the manufacturing
order data set and the part number cross-reference data set can be
provided by using the segmented record feature of eleS/VS file control.
File control requires a specific numter of segments to be defined for
each segmented record. The tasie information for J:oth of these data
sets is placed in the roct segment of the segmented records (see Figure
11-6), and additional segments are defined to allow multiple dependent
segments.
306
eICS/VS system/Application Design Guide
Dependent Segments
Root Segment
Work
Order
No.
Figure 11-6.
Work Order No. Status Segment
Manufacturing Work Order Details
No.
Manufacturing Work Order Segmented Record Pormat
CICS/VS file centrol can be used to provide a segmented record
capability which aFproaches that of DL/I, but which requires more user
programming and subsequent maintenance.
The manufacturing planning data set. which has a root segment but
not multiple segments, dces net require the segmented record feature
for support by file control.
The next decision to be taken regarding the data base support for
this application is the access methcd to be used by CICS/VS file control
for these data sets.
The three data sets may presently be supported by either ISAM or
DAM in a batch environment. However, because of the above need to use
the segmented record feature of file control, the record formats of
the batch data sets will need to be changed for the cnline application.
They may be converted and still be supported by ISAM or DAM if
necessary.
At this stage it is wcrthwhile ccnsidering the effect of adding
manufacturing orders online. changing manufacturing orders and possibly
deleting segments or adding segments, or deleting entire manufacturing
orders. Because this application reflects high activity of additioris,
updates, and deletions tc the online data sets, a more suitable access
method to use is VSAM. This enatles records to be accessed either by
key (key-seguenced VSAM), or by relative byte address within the data
set (entry-sequenced VSAM). and also readily allcws for additicns to
data sets while still maintaining good retrieval performance. Further,
because of the ability of key-sequenced VSAM to physically delete
segments or records from a data set, or increase ~r decrease the length
of records in a data set, this aFFlication is ideally suited to the
use of key-sequenced VSAM. However. if satisfactory performance is to
be achieved, VSAM should nct be used on systems with less than 144K of
real storage.
If either DAM or 1SAM is used. the overflow technique described
later in this chapter for the banking industry can be utilized to
increase the length of segmented ISAM or DAM recerds.
(~his technique
is described in more detail under "Segment Updating (DAM, ISAM, and
Entry-Sequenced VSAM)" in "Segmented Records" in Chapter 5.)
The two principal online applications in the banking industry are:
• Savings Bank and Mortgage Loan System
• customer information system (called customer
information file)
SAVINGS BANK AND MORTGAGE LOAN S1STE!
This online applicaticn enables saving bank deposits and withdrawals,
and mortgage loan transactions, tc be entered frem teller terminals
Chapter 11.
CICS/VS Application Design
307
located in various branches cf a bank. Such transactions are used to
update savings bank and loan accounts immediately. Some of the
advantages which ~esult from this online application are:
• Imprcved customer service, enabling the tank's customers to utilize
any tranch of the bank
• Standardization of procedures across all branches
• Ability to extend all tanking services to every teller terminal if
required
• Timely account informaticn
• Assistance to tellers in maintaining teller tctals
• Possiblity of improved audit and centrol procedures
Figure, 11-7 illustrates such an online savings tank and mortgage
loan application. This apFlicatio:n enables the following transactions
to be entered:
• Savings bank deposits
• Savings bank
withdra~als
• Mortgage loan transactions
• Inquiry transactions
Further, it provides additional facilities for audit purposes in
the areas of online operatio~ and offline operaticn.
INPUl
PROCESSING
I onlin._I______________~--------~
o;J
~~~ho~,i:wal
:
•
,-L---'----..............
[lA~C:::I:;::.::aa~,~.
II
2'
balance
Inquiry
~)(trac~ CUffent balance,
lflnqullY.
3,
Open now accaunl.
4, CloseaccolJnt.
[
5. Change account details
6. Extract required
information
7. Sort into specified
.seleclrel,vanl
~
account records
9. Calculate
jntere~t.
10, Update account
Figure 11-7.
308
records,
Savings Bank aDd Mcrtgage Lcan System
CICS/VS System/ApFlication Design Guide
DATA SETS
Several data sets are used. One is the savings bank account data
set, which contains a record of each savings bank account and
transactions against that account. A typical savings account record
is illustrated in Figure 11-8, which shows the multiple occurrence of
deposit and withdrawal transactions, for example, against that account.
Reference may need to be gade to previous deposit or withdrawal
transactions, particularly if those transactions were "no-book"
transactions (initiated without a Fassbook). When the passbook is next
presented, these "no-book" transactions must be used to physically
update the passbook with the previous "no-book" entries. The record
format shown in Figure 11-8 endeavors to keep the transactions against
a particular account in close proximity to the acccunt details, for
optimum data set accessing time.
,
Transactions
Account
Number
Customer
Number
Figure 11-8.
Account
Names
Current
Balance
Stops·
Flags
Deposit
I
Deposit
1
I
Withdr. ) '
Savings Bank Account Record Format
The mortgage loan data set may be similar in structure
organization to the savingE account data set, and may use
format similar to that illustrated in Figure 11-8. It is
a separate data set mainly to physically separate savings
mortgage loan acceunts fer subsequent batch processing.
and
a record
organized as
bank and
The customer account cress-reference data set is used to open new
savings or loan accounts, or close acccunts from a teller terminal.
Furthermore, changes in custcmer details, such as a change in address,
can be reflected in all the customer's accounts through the use of this
data set.
While this data set is of particular importance for a banking
customer information system (see below), it is also useful in the
savings and loan applicaticn for the above reasons. Figure 11-9
illustrates a typical customer account cross-reference record format,
which illustrates the multiple cccurrence of account numbers for each
customer.
Customer
Name
Figure 11-9.
Customer
j
Accounts
Address
Customer
Number
Details
Line 1
Line 2
Line 3
Acct.
No.
Acct.
No.
Acct.
No.
r
YAcct.
I
No.
Acct.
No.
customer Account Cross-Reference Record Format
A teller journal data set may be used for audit and recovery
purposes. Alternatively, the journaling facility of CICS/VS may be
utilized by the user to direct teller activity information to a journal
data set. If the 3600 system is used, the teller journal should reside
on the 3601 diskette. This makes it available for both online and
offline modes of operaticn.
In an online savings and loan application, each transaction entered
from a terminal must be immediately recorded in the event of system
failure, as the original transaction may no longer be available to be
ChaFter 11.
CICS/VS Application Design
309
reentered. That transaction is represented by the customer at the
teller window. Once he has made his transaction, he will take his
passbook and leave. Apart from a hard-copy log cf all transactions,
which is provided en most savings bank and loan terminals, the teller
may have no other record of the original transaction.
It is not reasonable to require the teller to reenter transactions
from this hard-copy log in the event of a system failure. Instead, on
receiving each banking transaction, the system should log that
transaction to the teller journal data set, which contains a record
for each teller in the bank. If the system goes dcwn before the
transaction is ccmpleted and added to the customer account record, it
is availab~e from the 3601 teller 'journal on restart and can be
retransmitted for reprocessing. The question of how to handle
transactions which could not be precEssed by the system because of
system failure is discussed further under "Transaction Recovery and
Restart" in Chapter 8.
Figure 11-10 illustrates a possible teller journal record format.
As well as containing infermatien relating to the last transaction from
that terminal, this journal indicates the current status of the terminal
which that teller is using, and maintains cumulative totals for that
teller to enable him to balance his cash at the End of the day. This
record fermat may be utilized in a separate teller journal data set on
the 3601 diskette, or it may be written by the user to a journal data
set utilizing CICS/VS journal contrel macro instructions.
Teller
Number
Teller
Status
Teller Totals
Deposits
Figure 11-10.
I I
Withdrawals
Cash
Terminal
Itentification
Terminal
Status
Last Transaction
From Terminal
Teller Journal Record Format
ONLINE PROGRAMS
A numter of online pregra~s may be used in this application
environment. These pregrams may be executed completely in the CPU or
3601, or may be executed partly in the 3601 and partly in the cpu. The
most important of these prcgrams are described in this chapter.
~~viDg§ 1'An§~~!io~ R~g~A~
-
iI2~~§§~§ ~~R2§i! ~D~
~'~Jl§A~:J:i2D§
!i1hg,aw§l
Deposit and withdrawal transactions may be made in many ways.
of the possible transaction types Day be made as follows:
Some
• With or without a passtock
• Ey cash, check, cr cash and check
• By transfer of funds between acccunts
• Against accounts with various stops or holds placed on them
All these transactions generally have the same input format, which
may provide more or less infcrmaticn depending on the function required.
Furthermcre, they generally involve the same logical processing, except
that some transactions may add tc the current balance (deposits), other
transactions may reduce the current balance (withdrawals), while other
transactions may have to carry out certain tests first. Finally, the
310
CICS/VS System/Application Design Guide
output response for each of these transactions is usually the same,
but may require certain fields to be printed in certain columns of the
passbook.
While it is pcssible te write a separate prcgram for each individual
type of transaction described abcve, another solution is to write a
generalized program that uses a cede entered with the transaction to
define the particular transaction type, and then accesses various tables
defined ty the user to detail, fer each transaction type:
• The input format
• Editing and testing to be carried cut on the transaction
• precessing and inforDaticn te be updated on data sets
• The output format to be used
By adopting a tabular approach te the definitien of the requirements
for each transaction type a user-written application program may be
used with generalized logic to examine the information detailed in user
tables for each transaction type and carry out the necessary processing.
~his applicaticn program may be developed as a generalized application
program block (AF) for execution in the 3601 Centreller. A generalized,
user-written CICS/VS savings transacticn program may then be used by
all savings bank terminals fcr all savings bank transactions as
previously described. The use of the 3600 and CICS/VS enables many
teller terminals to use this same frogram concurrently through the use
of the multitasking, dynamic storage allccation, and quasireentrant
capabilities of CICS/VS and the Dultiprogram execution capability of
the 3600. Through these facilities and a tabular processing approach,
most efficient use can be made of the CPU processing capability and
storage availablity, to maintain a satisfactory response time at the
terminal. This technique is discussed further under "Tabular
structures" in Chapter 2.
~QI!gsg~
12lD
~'Qg'~1
- !!~£~~ ~~1!g~g§ ~o~n 1~§D§!~!i2D§
The tabular approach described above may also be used for lean
transactions, if desired. Seme ef the logic used for the savings bank
program ~ay te atle to be used for the mortgage loan program.
Alternatively, by adding te the savings bank tables to describe loan
transactions, and by identifying transactions as relating either to
savings cr loan, one 3600 AP and one Cles/vS program may be used for
both savings bank and mortgage loan transactions.
An advantage in cembining these two applications into the one
program, and using a tabular appreaCh to describe each transaction
type, is that reductions may be made in future program maintenance.
If it is necessary te change either the input or the output format, or
the processing or editing requirements for any transaction type, that
change need cnly be made in the apprcpriate table in the 3601, which
is separately assembled frem the main savings and loan program.
Furthermore, by deleting or adding entries in tables, transaction types
can be easily removed or added te the application. If a generalized
programming approach has been used for the savings and loan program,
no coding changes may need te be made, unless a new application function
is added which requires unique program code.
~hsng~ i~~g~~
- ~h~ng~ ~!!!ng~ JDg 12JD A~9YD!§
This pr~gram is used to open and close accounts by adding or deleting
records from the appropriate acceunt data set (savings or loan) and
Chapter 11.
CICS/VS Application Design
311
adding or deleting account numbers from the customer account
cross-reference data set. The program also may update the customer
account cross-reference data set to reflect changEs in address or name,
for example. A further re9uirement of the change program is to add or
remove stops (holds) to various accounts, or change the customer names
for an account.
Use o:f the 3600 permits a subset of the account data set to be stored
on the 3601 diskette. This normally would only identify account numbers
that require special action, such as a stop on an account. A change
to the accounts data set in the CPU ty the change program should also
te reflected in the subset of the accounts data set in the 3601.
This program enables information such as:
• customer name and address
• Account names
• stops and holds
• Current balance
• Interest
to be obtained from the varicus cnline data sets to satisfy various
inquiries.
This program is executed in the 3600, and utilizes the user-defined
teller journal, which ccntains a reccrd for each teller using the 3601
and logs each savings or loan transaction to this journal on it
immediately after the transaction is received by it. In the event of
system failure, a user AF can retrieve these transactions from the
teller jcurnal, check to determine whether they have in fact updated
the apprcpriatE account (were not in-flight), and, if they were backed
out on emergency restart, the AP can complete the necessary processing
for those transactions. This audit function is part of the AP executed
in the 3601 for savings and loan transactions.
This program records each change in status of the teller, such as
"teller online," and also aaintains current cumUlative totals of all
money handled by the teller during the day, including:
• Total cash withdrawals
• Total cash deposits
• Total check withdrawals
• Total check deposits
• Total balance
In many cases it may te necessary to override certain functions in
the savings and loan application. For example, a stop or a hold may
be placed on an account, or an account may be r~ndered inactive for
312
CICS/VS system/Application Design Guide
various reasons. It may be necessary for an authorized person in the
bank to cverride this security provision of the application. An
override capability is provided ty the supervisor Frogram and may be
implemented either in the CPU or the 3601.
OFFLINE FROGRAMS
several programs select and fermat reports in the batch environment.
These Fregrams are descrited belo~.
The selected report writer prcgram selects and formats regularly
produced reports. This program sequentially processes both the savings
account data set and the lean account data set, selecting the desired
records for inclusion in reports. The inclusjon is determined either
on the basis of a reguest sutmitted ty bank personnel or on an exception
reForting basis.
The unload and select program unloads the savings and loan account
data sets on a periodic basis, and selects the applicable records for
input to the interest calculation pregram. As part of this program,
a data set statistical report for data set reorganization is produced.
The load program reloads the savings and loan account data sets,
using the backup created by the unload and s~lect Frogram as input.
It eliminates any overflow and any deleted records. It may be run
overnight, to reorganize data sets or data bases for the next day's
online oFeration.
A subset load program must extract the necessary subset information
from the data sets and transmit it to each 3600. A similar 3600 AP
will rEload the informaticn en the 3601 diskette account data set if
necessary.
Using record information Frovided by the unload and select Frogram,
this pr09ram calculates interest for various accounts.
~~!~ste~ ~~EQ.~ J~i!~. g!Qg~~.
The selected report writer program allows banking personnel to vary
the range and sorting seguence of many types of reports. For example,
bank personnel may request a repcrt of all loaD accounts in arrears,
or of all savings accounts at a Farticular branch. This program allows
the bank to produce a wide range of unique reports.
Before considering the data base support for the data sets described
above, the custcmer informatien system application is discussed. This
banking application is sometimes referred to as a customer information
file application.
chapter 11.
CICS/VS Application Design
313
A customer of a bank may have several savings accounts, checking
accounts q mortgage lean accounts, and ether accounts (such as tills of
exchange., foreign exchange, stocks, and Christmas Clubs). Figure 11-11
illustrates a typical customer informationn system for banking.
CICS/OS/VS supports the 3e50 !ass storage System which can be ~sed
to maintain massive custemer infermatien system data bases online. It
can be used for applications that have lew transaction volumes and that
can tolerate long response times. A typical 385C application in this
industry is the en line residence cf historical current account
(checking) transactions for suhseguent enquiry.
(See "CICS/OS/VS 3850 Mass storage Operation" in Chapter 7 for additional information
related to the 3850.)
PROCESSING
INPUT
c __
OUTPUT
1. Access customer account
cross· reference data set.
2. Identify accounts held
by customer.
3. Access relevant account
records.
4. Display requested
account details.
5. Determine selection
criteria.
6. Search specified
account records.
7. Extract records which
satisfy criteria.
8. Display information
which meets criteria.
Figure 11-11.
Banking CustoDer Information System
In this applicatien, all a customer's activities with the bank can
be related. By relating all of a customer's acccunts, access to any
one account also makes other acccunts identifiable and available. Thus
a bank is tetter able to determine the involvement of each customer
with the bank. 1wo cf the advantages efferea by such a customer
information system are:
• Improved customer service
• Increased marketing cpportunities for the bank in selling additional
services to customers
314
CICS/VS system/Application Design Guide
By accessing the customer account cross-reference data set,
information relating to the custemer can be obtained, together with
the account numbers of every other type of account held by a customer
at that bank. By accessing the aFFropriate account data set, more
detail may be obtained for each individual account.
Futhermore, by recording ether information in each account record,
such as the names of various FeoFle using a savings account or a
checking account, the individual accounts held by each person can be
identified by further reference tc the customer account cross-reference
data set.
This information, enabling the various banking services used by a
customer to be identified, may be used together ~ith other information
to open new marketing opportunities for the bank. For example,
analyzing information such as the tYFe of services used by customers
in particular geographical areas, may identify those services which
are most popular in a particular lccation. Furthermore, those services
which are less popular can be identified, enabling action to be taken
to improve the service er to reduce costs by remcving the service.
Another marketing opportunity which presents itself is to compare
those customers in a particular location against a separate data base
of all people living in that location, such as from an electoral roll.
This enables the bank to identify people who are net presently
customers, thus allowing selective marketing to te carried out to
attract more customers to the bank.
Another possibility is to identify various companies cr corForations
which are customers of the bank, and then access information which is
generally available in most countries identifying the main executives
of those companies. If these executives are not presently customers
of the bank, the bank may wish tc direct its marketing efforts toward
attracting thea as new customers.
The various approaches described are directed at improving customer
services, reducing costs froE unFrofitable services, or attracting new
customers to the bank. These approaches have always been available to
the banking industry. However, the information which was necessary to
implement them usually has net been readily accessible. The use of an
online customer information system, with all related cus~omer accounts
identified, makes this infcrmaticn available. CICS/VS enables such a
customer informaticn system to be readily iaFlemented.
DATA SETS
The data sets used by a customer information system include the
savings tank acceunt data set, the mortgage loan acccunt data set, the
checking account data set, and other data sets (see Figure 11-11).
The checking account record fermat is illustrated in Figure 11-12.
This would normally be created and updated offline daily by various
check processing and clearing batch Frograms. It can be seen from the
figure that the checking acccunt reccrd format is similar to that used
for savings and loan acceunts. In particular, after the fixed checking
account information in a root segment, there may be a multiple number
of transactions ~hich are associated with each acccunt recorded, each
transaction representing a check written, or a check deposit made.
Cha~ter
11.
CICS/VS Application Design
315
)
Transactions
Account
Number
Customer
Number
Account
Names
Current
Balance
StopsFlags
Deposit
Figure 11-12.
I I I I
Ch"k
Ch"k
Charge
Checking Account Eecord Format
Mortgage loan account data sets use a record format similar to the
savings account data set illustrated in Figure 11-8.
The customer account cress-reference data set is used to contain
customer details such as name and address, together with the account
number of each account used ty that customer as illustrated in Pigure
11-9.
A customer information system is not as critically affected by syste.
downtime as the savings and lcan a~~lication described previously.
Accordingly, a teller journal is not essential for this inquiry system
and has not been included in Figure 11-11. The terminal operator can
reenter his inquiry once the system bas restarted, with little or no
detriment to the applicaticn.
The programs which may be necessary in this application include,
but are not limited to, the follcwing.
ONLINE PEOGRAMS
This program accesses tbe customer account cress-reference data set
for a particular customer and makes available at a terminal all account
numbers used by that customer. As an option, the terminal operator
may examin€ each individual acco~nt in detail.
This ~rcgram particularly benefits from the terminal paging
capability of CICS/VS. As each data set and acceunt is accessed, all
the information relating to that acceunt may be retrieved and formatted
as a separate terminal page for display if necessary. However, the
program itself does not need to centrol the selection and presentation
of pages by the terminal cperator. The program formats each page on
the assumption that it may be required and presents each page to
ClCS/VS. CICS/VS then disFlays each appropriate page as requested by
the terminal operator. Refer to "~erminal Paging" in Chapter 3 for
more detail.
This program enables part or all of the specified data sets to be
searched to locate records which satisfy various selection criteria.
These criteria may be predefined, or defined by the terminal operator
at the time of entering the retrie'val request. Por example, all
checking account customers whose acccunts have been below a specifieQ
minimum talance for a specified ti~e period may te selected from the
checking account data set. These selected records may be presented to
the terminal operator, with records satisfying the selection criteria
most closely presented first, followed by records satisfying the
criteria less clesely. In this way, the most delinquent checking
accounts can be readily identified.
316
CICS/VS System/Application Design Guide
CICS/VS is particularly suited to this search requirement through
the availablity of the built-in weighted retrieval function. This
enables a key-sequenced VSAM data set to be sequentially scanned by
CICS/VS, selecting records based upon user-supplied criteria. CICS/VS
sequences records fer presentaticn based upon the degree to which they
fall between user-defined limits for selection. Befer to "Weighted
Betrieval" in Chapter 5 fer more detail.
DATA BASE SUPPOB1 SELECTION
Since both the savings and lcan application and the customer
information system may nermally be simultaneously supported as online
applicatia.ns by CICS/VS, the selection of the apprcpriate data base
support should satisfy beth applications. The factors which should be
considered in the selection ef this data base sUFPcrt are now discussed.
The criteria that shculd be used in selection of the data base support
are described under "Data EasE Selection criteria" in Chapter 5.
Each of the data sets used by both the savings and loan application
and by tbe customer information system exhibits a fixed amount of
information relating to a Farticular account. This fixed information
may be regarded as a root segment. The root segment may have a multiple
number of dependent segments, such as various transactions for savings
accounts, checking accounts, loan accounts, or ether accounts.
In the case of the customer account cress-reference data set, the
custemer details wculd fcr~ a roct segment, with each of the account
numbers used by that customer being a dependent segment (see Figure
11-13). With the savings and mortgage lean data sets, each account
transaction would be a dependent segment as shown in Figure 11-13.
There may be any number of dependent segments (transactions or
account numbers) fer each roet segment. Because of this, these data
sets are ideally suited to the use of DL/I as the data base support.
DL/I enatles root segmert infermaticn or individual segment information
to be retrieved on request by the Frogram and presented to it for
processing with no ccncern by the Fregram for the physical location of
the segments.
DL/I ENTRY, DI/I DOS/VS, and IMS/VS DL/I readily enable the addition,
replacement, or deletien of segments to be achieved online. The root
and dependent segments are fixed length, and consequently can be
supported by any of the DL/I products. The support of logical
relationships and secondary indexing by DL/I ENTEY, DL/I DOS/VS, and
IMS/VS is particularly useful for the design of the customer information
system data base. Refer tc "Sample Applications" in HL1 12Q~L.!~ ~.Il§ral
In!2~m9!i2n ~~nY91 for further discussion of the use of DL/I data bases
in the banking industry.
ChaFter 11.
CICS/VS Application Design
317
Customer Details
I
I I
Customer Customer Misc.
No.
Name
I
J
I
I
I
J
Address
4
Account
2.1-
Line
Number
11-
2~~
1~
Customer Account Cross-Reference
Account Details
Account
No.
I
Current JStoPsl
Balance
I
I
I
I
Account
Names
lP
I
I
I
Deposit
3
2~
10-
Withdrawal
4
3-
2r-
1~
Account Record
Figure 11-13.
Eanking Data Ease Logical structure
CICS/VS file control should be considered in this industry by
CleS/DOS/VS users with real stcragE size equal to or less than 160K
who do n<)t wish to use DL/I tOS/VS, or by Cles/cs/vs users with real
storage size equal to or less than 2QOK. In this instance, a limited
capability similar tc that provided by Dt/lcan te offered by the
segmentecl record feature of eICS/VS file control.
The dependent segments (transacticn~ are generally saall, typically
no more than 30 tytes in aost casE~. Each 30-tyte seg.ent can be
defined to file control as a separate 30-tyte fixed-length segment. A
largE number of deFendent segments (up to a .aximu. of 99) may be held
as CICS/VS segments. For Example, by defining ten bytes of segment
318
CleS/VS System/Application Design Guide
indicator bit flags, 80 CICS/VS dependent segments can be defined.
Each additional tyte of segment indicator bit flags will allow a further
eight dependent segments to te stored.
Because the segment indicator flags identify the presence or absence
of CICS/VS segments, no disk storage is used (apart from the indicator
flags) for segments which are absent in a particular data set recOrd.
Addition or deletion of dependent segments will cbange the length of
CICS/VS segments. The normal reguirement of this application is to
add dependent segments, thus increasing the length of CICS/VS segments.
However, this capability is not supported by 1518 or D18.
Accordingly, the access method which should be selected is
key-sequenced VSAft, which readily allows for the increase in segment
length, or the deletion of segments with the ability to physical reuse
that deleted storage. However, VSAM should not te used (for performance
reasons) if the user's syste~ has less than 144K of real storage.
If VSA8 cannot te used, a technique may be utilized based on a direct
access data set for additicn or deleticn of transactions through a
backward chain. In this case, the relative location of the most recent
transaction for an account is placed on the root segment of that
account's segmented record (see Figuxe 11-14). ihis is the overflow
technique descrited in Chapter 5 in the section "Segment Updating (DAft,
ISAM, and Entry-Sequenced VSAM.")
Ideally, the teller journal should te a CICS/VS user journal data
set, operated on by CICS/VS journal contrel macro instructions issued
by the user. Alternatively, if this approach is not desired, the teller
journal data set may be a direct access data set supported by DAM, or
an entry-sequenced VSAM data set.
The two main online applications within the insurance industry are:
• Policy inforaation systea
• New-business policy entry system
The advantages of these online applications in the insurance industry
are:
• The availability of policies to all offices cf an insurance company
• The ability to maintain close control of the claims made by a
customer against his policies
• The potential for reduction in cest of entering new-business
policies
• The potential for improvement in accuracy of neW-business policy
entry
POLICY INFORMATICN SYSTEM
A policy infcrmation system is analogous to a customer information
system in the banking industry. This policy information system uses
a policy data base which contains all the policies issued by the
insurance company. All the policies held by each customer are
identified and related to that customer. By identifying the customer,
or a policy owned by that customer, all other policies belonging to
Chapter 11.
CICS/VS Application Design
319
that person may be identified. In this way, the customer's worth to
the insurance company can te more fully assessed.
However, it is not sufficient tc know onlj what policies are held
by a particular customer. It is alsc imFortant to know the claims
which have been made against thos€ pclicies and the current status of
premium Fayments. Figure 11-14 illustrates a policy information system
for insurance companies.
CICS/OS/VS sUFPorts the 3850 ~ass storage System which can be used
to maintain policy infcrmaticn sjstem data bases online. The 3850
supports data bases ranging from 35 to 236 billion bytes. It can be
used for applicaticns that have lew transaction volumes and that can
tolerate long response time.
(See Chapter 7 for additional information
related to the 3850.)
The insurance data base s~own in Figure 11-14 enables information
to te retrieved in a numter cf ways, such as by:
• Policyholder name and address
• Policy number
• Policy claims
• Folicy renewals
• Agent's identification
• line of business (Policy Class)
• Gecgraphic territory
320
CICS/VS System/Application £esign Guide
PROCESSING
OUTPUT
Policies
•
Request Display
Of Policies Held
By Person.
•
Request Claims
Display.
1. Access customer
cross·reference data set
2. Identify policies held by
customer.
3. Access relevant policy
records.
4. Display requested
policy details.
Claims
5. Access specified policy
record.
6. Identify claims against
policy.
7. Access relevant claims
records.
8. Display claims details.
7. Determine policy class
selection criteria.
8. Search specified policy
records.
9. Extract records which
satisfy criteria.
•
10. Display information
which meets criteria.
Policy Selection
Based On Criteria
Figure 11-14.
Insurance Pc1icy Infcrmation System
DATA SETS
The policy data set contains all the informaticn relating to each
current insurance policy. A typical record format for this data set
is illustrated in Figure 11-15.
Policy
Number
Custamer
Code
Agent
Number
Figure 11-15.
Line of
Business
(Policy
Class)
J
Activity
Issue
Date
Premium
Data
Cease
Date
Claim
Claim
Renewal (
Pc1icy Becord Format
The details of the policy are ccntained in a fixed section of the
record, which may be regarded as a root segment. Following these policy
details, there may be multiple claims which have teen made against that
policy. These may be regarded as de~endent segments of the policy root
segment. Depending upon the type of policy, there may be also a
multiple number of renewal segments, which represent the periodic
payment cf premiums -- for esample, monthly premium payments. By
accessing a particular pclicj record, all the details relating to that
policy, including claims and premium payments, are available for
analysis.
Cha~ter
11.
CICS/VS Application Design
321
Alternatively, claims and renewals may
sets, with the root segmEnt of an account
the most recent claim or renewal for that
data set. Each of the claims or renewals
backward through the data set.
be supported as separate data
containing disk ~ointers to
same account in the relevant
for an account is then chained
The customer cross-reference data set contains each customer name
and number, together with a multiple number of segaents of the address,
identification of agents who assist, and identification of the policies
serviced by each agent. The code used to idEntify each customer may
be a numeric COdE, a name code, or a phonetic code that is developed
using the built-in phonetic conversion function cf eICS/VS (see "Record
Identification" in Chapter 5). Figure 11-16 shows a typical record
format for the customer cross-reference data set.
Address
Customer
Code
Name
Policies
t----.-----.r----4 Agent
Line 3 Number
Figure 11-16.
Pol.
No.
Pol.
No.
Agent
Number
Pol.
No.
Customer Cress-Reference Record Fermat
The agEnt data set contains fixed information relating to the
insurance agent, such as his name, employee number, and sales
performance, followed by a multiFle numbEr of segments, one for each
customer serviced by that agent. A ty~ical insurance agEnt record
format is illustrated in Figure 11-17.
,
Sales
Agent
Number
Agent
Name
Figure 11-17.
Customer Numbers
I
J
Current
Year
To
Date
No.
No.
No.
No.
No.
No.
No.
No.
/
Insurance Agent Record Format
The territory and pclicy class data sets contain fixed information
relating to the ~articular geogra~hic territory or class of policy and
may have a multiple numher of segments identifying the customers in
that territory or the policy numbers in that classification. By
accessing this data set for a particular territory, all the customers
in that territcry can be identified. Further information about the
policies owned by those custcmers is available from the customer
cross-reference data set. Similarly, all the policy numbers in a
particular policy classification can be identified and the information
relating to those policies can be obtained from the policy data set.
322
CICS/VS system/Application Design Guide
ONLINE PEOGBAMS
Having identified the various data sets used in a typical policy
information system, the apFlicaticn Frograms should ce defined. Some
of the more commcn programs are described below.
i21i~I ~i§RlsI ~I2g!si
- ~i§1121 i91i£I Inf2!i~i~D
This program displays policy details from the policy data set and
formats these details in a page for display at the terminal. These
pages are presented to the CICS/VS terminal paging routine (see Chapter
3) for subsequent display when requested by the terminal cperator, as
described below. In this way, all the policy details are made available
for inquiry.
This program accesses the customer cross-reference data set, usually
using customer name, and fcraats all the details relating to that
customer (such as name and address) into a page for display at the
terminal. Each policy owned by that customer is then retrieved from
the policy data set by the system automatically initiating a policy
inquiry, and the policy details are formatted into a page for display
at the terminal. The terminal paging facility of CICS/VS (see Chapter
3) relieves the prcgrammer of having tc select and display each
individual page requested by the terminal operator. Instead, CICS/VS
terminal paging selects the appropriate page requested by the terminal
operator froD thcse pages sUFplied by the program and displays it on
the terminal.
~12ii~L]§D~sl§ i!~gl~!
-
Di§Rl~I ~lsi~
iDg
~§D§!sl§
Based on specific policy identification, the details of the policy
may te retrieved and the various claims made against that policy may
be displayed, together with the renewal status of the policy.
This prcgram accesses the representative data set and formats
representative details, such as name and sales performance, for display.
Each client serviced by that representative can then be the subject of
a policyholder inquiry if required.
The territory data set is acce~sed, and territory details are
displayed. The terminal operator shculd ce permitted to display details
relating to each, or alternatively a specific, pclicyholder in the
territory.
i21i£I
~lg§§
!ngYiII -
~i§~iI R~lici~§
21
f~I!i£Yl!I ~lsssifica!ion
This program is similar tc the territory inquiry, except that the
data set is accessed for a sFecific policy classification, and all the
policies in that classification are displayed. A terminal operator
then has the option to examine each of these policies in more detail
with a policy inquiry.
Chapter 11.
CICS/VS APFlication Design
323
NEW-BU~INESS
POLICY ENTRl SYSTEM
This cnline application allows the entry of new-business policies
into a policy data set of the insurancE data basE. Without s~ch a
system, the preparation of new-business policies would require highly
experienced personnel to code the necessary information.
The use of online data entry under CICS/VS for this application
enables the terminal operator to enter policy information in terms he
is familiar with, and allows the computer to carry out much of the
necessary coding and checking. In this way, it may be possible to use
less experienced (and lower ~aid) ~ersonnel to pre~are new business
policies, with the computer handling the coding and checking of
information for accuracy.
The 3790 communication System enatles much of this coding and
checking to be done in a remcte tranch office either online, or offline
for subseguent transmission to CICS/VS. The 3791 Controller contains
27.5 million bytes of disk storage which may be used to store sections
of the data sets requirEd for editing the 3790. Refer to "3790
Sessions" in this manual, and ID!,~~~ti~D ~2 th§ ~~ Jl~Q ~2.~ni£~!i2n
~~§!§~, GA27-2767, for additional information about the 3790.
A typical
new-business policy entry system is illustrated in Figure 11-18.
PROCESSING
OUTPUT
1. Generate policy entry work
record.
2. Write to policy work data set
for this terminal.
3. Access policy work record
4. Store new policy details in
work record.
5. Validate policy and write to
work data set.
6. Access policy work record.
7. Replace error filed with
correction.
8. Validate policy and write to
work data set.
9. Access policy work record.
10. Add to policy data set.
11. Add policy number to
customer cross·re-ference
data set.
Change
12. Change policy record.
Delete
13. Delete policy record.
14. Delete policy number from
customer cross-reference
data set.
Figure 1 11-18.
New-Business
~olicy
Entry System
A considerable amount cf information must be entered for each new
business policy. Typically, the information entered from a terminal
may apprcach, or in some cases eJceed, 1,000 characters. If this
approximately 1,000-character record is entered as one input
32q
CICS/VS System/Application Design Guide
transaction, the extent to which the computer can help in coding and
checking is somewhat limited.
However, if a cenversational approach is taken to the entry of
information, the computer can guide the terminal operator ty requesting
each section of policy inforKaticn as it needs it. By adopting this
conversational aFproach, the computer can request information in much
the same way as it may be requested on a new-business policy form, and
then take that entered infcrmaticn and code it based upon defined rules
for each section of the policy entry.
The advantage a cenversational policy entry approach offers is that
it now becomes pcssible for inexFerieDced operatcrs to transcribe .
information directly from new business policy forms, with the computer
carrying out the necessary ccding and checking of information.
Furthermore, in the event ef an error being detected in the input, only
that errcr field need be reertered.
To achieve this conversational policy entry, the policy information
received from the terminal is used to progressively build up a complete
new-business policy record. The pelicy work data set is used for this
purpose. When the entry of the new-business policy is started, the
policy informatien is written to the pclicy work data set. As
subsequent policy information ~s received frcm the terminal for this
new policy, the record written tc the policy work data set for that
policy is retrieved, updated with the additional information, and
written back. In this way, the new business policy record is gradually
built up with each sectien of policy information being fully edited,
validated, coded, and written to the data set before the next section
is obtained from the terminal operator.
On completion of entry of the pelicy informatien, the new-business
policy record is transferred to the policy data set, and the policy
number is added to the customer crcss-reference data set for the
customer who has taken out the new pelicy.
DATA SETS
The pelicy work data set contains a record for each new-business
policy entry terminal. In the event of system failure, the policy ~ork
data set records all policy information entered by each terminal
operator up to the time when a failure may have occurred. On system
restart, it enables previously entered policy information to be
retrieved from the data set such that the terminal operator can continue
with the policy entry, close to the point he had reached when the system
failure cccurred.
This policy entry recovery facility is made possible through the
use of conversational entry cf pelicy information. If all the policy
information was entered as one large input transaction of approximately
1jOOO characters, and the system went do~n toward the end of entering
policy informaticn, it would be necessary to rekey all that policy
information again when the system is restarted. Hewever, using
conversational entry, only the last conversational section of the policy
may have to be rekeyed on restart.
The customer cress-reference data set and the pelicy data sets are
the same as descrited abcve for the Folicy information system.
Chapter 11.
CICS/VS Application Design
325
ONLINE PROGRAMS
This program accepts policy information from terminals, validates
that information based on Established editing and checking procedures
used by the insurance company, COdES the validated information, and
writes it to the pclicy work data set. The response returned to the
terminal indicates the informaticn to te nExt entered for the policy.
Each subseguent transaction received from the terminal is also validated
and coded, then added to the infermation for that policy in the policy
work data set.
While this program has been identified as a pelicy entry program,
it is in fact a series of pregram modules, each module used ta validate
and code each separate terminal transaction which is used
conversationally to build up the entire policy. Each program may
utilize temporary transaction codes (refer to "Task Initiation" in
Chapter 3) to identify the program to process the next section of the
policy, without reguiring the terminal operator to enter a transaction
code.
This program accepts a terminal transaction which is identified as
the correction of a previously entered error field. It retrieves the
previous error information that was logged to the policy work data set,
inserts the relevant corrected field, and revalidates the policy
information. If the corrEcted field passes the validation procedure,
it is inserted into the new-tusiness policy record and written back to
the policy work data set.
This program accesses policy records either in the policy work data
set, or in the policy data set, to change specified policy infcrmation.
This prcgram accesses the policy data set and customer
cross-reference data set to delete specified policies.
An extention to this new-tusiness policy entry system enables the
entry, validation, and addition ef claims and renewal information to
the policy data set. This uses a similar design approach to that
described abcve, except that the amount of information to he entered
may be supplied in a single input transaction, rather than in a
conversational transaction envircnment as for new-business policies.
A temporary data set such as the policy work data set is not necessary.
Instead, after editing and ceding, the claims or renewal information
may be added directly to the policy data set.
DATA BASE SUPPOR1 SELECTION
The criteria that shculd be ueed in selection of the data base
support are described in "Data Base Selection criteria" in Chapter 5.
326
CICS/VS System/Application Design Guide
The policy data set, agent data set, policy class data set, territory
data set, and the customer cress-reference data set contain fixed
infcrmation, followed by a variable amcunt of related information, such·
as:
• Claims and renewals for a particular policy
• Policy numbers for a particular customer
• custemers for a particular insurance agent
• customers for a particular territory
• Folicy numbers for a particular policy classification
Because of the above considerations, the ideal data base support in
this industry is DL/I. The ~ultiIle occurrence cf related informaticn
described above can be supported as dependent segments, with the fixed
information in the various data sets as root segments (see Figure
11-19). As these segments can be effectively made fixed-length, any
of the DL/I products may be used.
DL/I ENTRY, DL/I DOS/VS, and IMS/VS DL/I support logical
relationships and secondary indexing, which enable indexes to be created
and used by DL/I such that dependent segments may be directly accessed.
An example of the use of such secondar~ indexing is the creation of
DL/I indexes for directly accessing claims based on a claim number.
DL/I has many advantages, particularly in the area of reduced
maintenance, over CICS/VS file centrol. However, if DL/I will not be
used for various reasons, the segmented record feature of CICS/VS file
control may be used to advantage. As previously discussed for the
manufacturing and banking industries, the dependent segments may be
defined as separate file ccntrol segments.
The policy information system is an inquiry application, and does
not involve changes er additions to the data base. However, the
new-business policy entry system will result in additions to the policy
data base and the customer cress-reference data base. In this case,
the length of file centrel segmented records will be increased, or in
the case of deletion of policies, will be decreased. Consequently,
the most suitable access method to provide this capability is
key-sequenced VSAM, provided the user's system has at least 144K of
real storage for satisfactory perfermance. If ISAM or DAM is used,
the overflow technique described in "Segment Updating (DAM, ISAM, and
Entry-Sequenced VSAM)" in Chapter 5 may be utilized to increase the
length of segmented DAM or ISAM records. However, this technique
requires additional prcgramming.
Chapter 11.
CleS/VS Application Design
327
Pol.
No.
I
Policy Details
Customer
Number
I I
I
Detail
r~12
~
I
Agent
No.
I
I
3
Renewal
Claim
2
1t-
.l
'-------Policy Logical Structure
Customer
NO.' Name'
r
r
I
I
Address
Line
Detail
[gent
2t-l
Number
1~
2
1t-
I
Customer Logical Structure
I
I
I
Policy
Number
Figure 11-19.
2~
11'-
~
Pelicy Infermation System Logical Structures
~E~~Al lBDU~I~!
In the medical industry, a typical online application is the control
and maintenance of informaticn relating to all of the patients in a
hospital or clinic, in a patient information system.
328
CICS/VS system/Application Design Guide
PA!IENT INFOBMATION SYSTEM
This application enables all activity such as visits, diagnoses,
and treatments, tetween a patient and a hospital or clinic, to be
recorded as that patient's history. When a patient is first admitted
to a hospital or a clinic, his personal details can be entered from an
online terminal directly intc the patient information system. On each
subsequent visit, informatioL can be added to his history -- all visits
made by the patient, the diagnosis made on each visit, and the medical
or surgical treatment received; a complete history can be developed.
An example of such a patient infcrmaticn system is illustrated in ~igure
11-20.
CICS/CS/VS supports the 3850 ~ass storage System to permit massive
patient information system data tases to be maintained online. The
3850 provides online capacity to large data bases for applications with
low transaction volumes which caD tclerate lcng response times.
(See
"CICS/OS/vs - 3850 Mass Storage System Operation" in Chapter 7.)
A
typical 3850 applicatjon in this industry is the online residence of
medical literature and research data. Use may be made of the STAIBS/VS
Program Froduct (Program No. 57qO-XE1) to retrieve relevant medical
literature based upon a keywcrd criteria search. See the ~!IE'§L!~
~~n~I~l In!2Imgijgn ~gn~gl (GH12-516q) for additional information.
PROCESSING
1. Generate new patient record.
2. Access patient record.
3. Update record with visit or
treatment details.
4. Display updated history.
5. Access patient record.
6. Extract visit and treatment details.
7. Display patient history.
8. Access medication crossreference data set.
9. Access patients with that
medication in patient
history data set.
10. Display patients receiving
specified medication.
11. Search patient history for
specified disease.
12. Display patients with
specified disease.
Figure 11-20.
Patient InfcrmaticD System
The patient history develcped over a period of time using the patient
information system can be made availatle ty means cf the computer to
any authcrized person. ccnsequently:
Chapter 11.
CICS/VS Application Design
329
• Doctors may be made aware of all visits, diagnoses, and treatments
relating to a patient.
• All handling and treatment of a
~atient
can te identified.
• A record of all ~atient activity with the hospital or clinic can
be made available to the acceunting department for billing purposes.
In addition to recording information, relating to a particular
patient, the com~uter can al~o recerd elsewhere the fact that the
patient has received particular medication. It is then ~ossible to
determine which Fatients have received certain medication within a
certain time period, for exaRple.
DA'IA SETS
The patient history data ~et contains information identifying the
patient, such as patient numter, name, address, and personal details.
Associated with this patient may te a multiple numter of segments of
information, each segment relatiI9 te a particular visit er treatment.
A typical patient history record is illustrated in Figure 11-21.
Patient
No.
Name
Patient
Doctor
Details
Number
Figure 11-21.
Patient History
Address
Line 1
Line 2
Visit
Line 3
Treatment
Diagnosis
Treatment
Visit
Patient History Record Format
The medication cress-reference data set ccntains details relating
to each particular medication, with a multiple numter of segments
identifying the patients who received that medication and the dates
administered.
Using this data set, all the patients who received
particular medication at a particular time can be identified. By
accessing the patient histcry data set, further information can be
obtained relating to various patients.
A typical medication
cress-reference record fcr~at is shown in Figure 11-22.
Patients Administered
Medication Identification
Number
Description
Figure 11-22.
Details
Patient
No.
Date
Dose
Patient
No.
Date
Dose
Patient
No.
Date
Dose
Medicaticn Cress-Reference Record Fermat
A diagnosis data set and a doctcr data set, if required, may be used
to identify all patients who contacted a particular disease, or who
were or are treated ty particular doctors. The format of these data
sets is almost identical te that of the medicatien cross-reference data
set.
CNLINE Fl;OGBAMS
~~~ ~gti~nl ~~~~b9! -
Jg£
~!
Rg!jsn! 12 Rg!i§]!
~i§!2~
This program accepts informaticn relating to a new patient and adds
that information to the patient histcry data set.
330
CICS/VS System/Application Design Guide
Rsti§~! y~gs!~ ~~2~~s~ - y~gs!s i9!i§~! ni§!~~l !!1h Vi§i!§,
l~§s!~~!§, s~ ~isgn2~s§
This Frogram is used to add infcrmaticn relating to a Farticu1ar
patient visit, or treatment received by the patient, to the patient
history data set. Over a period of time, a complete historical record
is built up for each patient.
~s!i~n! ni§!2~1 !Dg~i~l i~~g~s~ - ~i~lal ~s!i~n!
ni§!2II lni2Ims!i2D
This inquiry ~rogram accesses the patient history data set and
formats that history intc ~ages to be displayed on request by the
terminal operator. These Fages are presented by the program to the
CICS/VS terminal ~aging routine (see Chapter 3), which saves them and
displays them for the terminal oFerator in the sequence requested.
~§gi£sti2n !Dg~i~l ~!29!sJ -
This
patient
Further
patient
~i§~lsl All is!i~D!§ ~£ei~iD9 ~~~in
~~,g.i~s!j2D
Frogram accesses the medication data set and identifies each
who received specified medication over a sFecified time period.
information relating to those patients may be obtained by a
history inquiry if required.
~is9D2§i§ 1~9~j!1 i!29!s! -
~i§~lsl All Is!i§~!~ !.i!h ~ ~E§£1!~9
~i.§~!!§§
This Frogram accesses the diagncsis data set and identifies all
patients who contracted a specified disease.
Further information can
te ottained about thcse Fatients by means of a patient history inquiry_
~2ct2! ID9~i!1 ~!2~~s~ - ~i§!l~l All ~~!jsD!~ ~~lsting 12 ~ ~E§£i!1~9
~S£!2!
This program accesses the doctor data set and identifies all patients
treated ty that doctor.
further information atout these Fatients may
then be ebtained by a patient histery inquiry.
DATA BASE
SUPPOR~
SELECTION
At this stage of the apF1ication design, the data base sUFPort to
te used can be deter~ined.
Befer te "Data Base Selection Criteria" in
Chapter 5 for a discussicn of the factcrs which shculd be considered
in this selection.
The record formats of the patient history, medication, diagnosis,
and doctor data sets (see Figures 11-21 and 11-22) exhibit multiple
occurrences of infcrmaticn, dependent upon a root segment. These record
formats indicate that DL/1 is the ideal data base sUFPort for this
application.
Generally, the segments may be made fixed-length, which allows DL/I
ENTRY to be used. Variat1e-length segments may te used by DL/I DOS/VS
and IMS/VS DL/I for information such as names and addresses.
Figure 11-23 shews a tYFical tL/I legical structure for the patient
history data base.
Information describing Fatient~s name, address, and physical
characteristics is centained in the Fatient detail root segment.
patient can have many visit and dependent diagnosis segments.
ChaFter 11.
CICS/VS ApFlication Design
Each
331
The support of logical relaticnships and secondary indexing by DL/l
ENTRY, DL/l DOS/VS, and l~S/VS is useful in the design of the patient
information system data tase.
Refer to "Sam~le Applications" in 121Ll 12Q~!.2 g!l!~nl ln2!nli.2!!
l:HU1Y.!!! for further discussicn on -the use of DL/l in the medical
industry.
Patient
Details
Visit
]
Body
Site ]
DiagnOSiS]
Treatment
Surgery
L
I
DiagnOSiS]
[speCime]
,
Figure 11-23.
Patient HistoIY Lcgical structure
~1~~L!~ 1!1~ ~~D!~~l
The segmented record feature cf ClCS/VS file ccntrol may be used to
support the multiple occurrerce ef dependent segments. Because of the
reguirement for increasing the length cf segments as information is
added to a record, the most suitable access methed to be used is
key-seguenced VSA~.
332
CleS/vs System/Application Design Guide
For machines with less than 1q48 bytes of real storage, the use of
VSAM is not advised, for perfcrmance reasons. 151M and DAM may be used
instead as the access methcd support. In this case, the overflow
technique described in the sectien "Segment Updating (DAM, ISAM, and
Entry-Sequenced VSAM)" in Chapter 5 may be used.
A typical online application in the pharmaceutical industry is the
entry of orders from pharmacists for various products, and the filling
of these orders in the Fharmaceutical company's warehouse. This
application is generally referred to as a pharmaceutical crder entry
system.
PHARMACEUTICAL ORDER
EN~FY
SYSTEP.
In this industry, orders fer prcducts are generally made by product
name rather than by product Dumber. Products such as aSFirin may be
supplied by many manufacturers in different strengths and in various
quantities. Thus, an order taker EUst have a very good knowledge of
the company's range ef preducts so that he can readily identify the
PROCESSING
Online
1. Access pharmacist record.
2. Display name and address.
3. Generate order·in·progress
record.
4. Access synonym record.
5. Display product synonyms.
6. Access order·in·progress
data set.
7. Update with new product
, ordered.
8. Access order·in-progress
data set.
9. Prepare packing slip in
warehouse location sequence.
10. Transmit packing slip
11. Extend invoice.
12. Transmit invoice.
13. Write order to accepted·
order data set.
Offline
14. Read accepted orders.
15. Update product in'ventory.
16. Sort products into
alphabetic sequence.
17. Generate synonym
data set.
Figure 11-24.
Pharmaceutical Order Entry System
particular product ordered. Figure 11-24 illustrates a typical
pharmaceutical order entry system. in this aplication, generally,
CICS/VS ApFlication Design
333
orders a]:e placed by pharmacists over the telephone, with the telephone
operator keying into the terminal each product ordered. The name of
the product ordered is entered on the terminal, and the computer
accesses all products similar to that entered (that is, synonyms) and
displays each of the syncnyms at the terminal for selection by the
operatoro
In this industry, a pharmacist's order is normally accepted
regardless of whether or not there is sufficient stock on hand to fill
that order. An cnline inventery status check is normally not carried
out. Hotiever, it is important that Facking slips for such orders be
passed tc the warehouse as quickly as possible. Ideally, the computer
should prepare all the products in each packing slip in warehouse
location sequence for faster picking of Froducts. This packing slip,
together with an extended invoice if preinveicing is to be implemented,
can be tr.ansmitted to a terminal in a warehouse very shortly after
completicn of entry of the order.
DATA SETS
The synonym Froduct data set is a sFecial online version of the
product data set (which is used only in the batch environment). If
the product data set is used online to identify various Froduct
synonyms, a file access gay te needed for each separate slnonym.
Eecause there may be twenty or more synonyms fer each product ordered
from each terminal, accessing the ~rcduct data set online represents
a significant (and unnecessary) file accessing lcad. This online
accessin9 is unnecessary, as the cnly ~urpose is to identify slnonyms
and not to update inventorl levels. In this industry, inventory is
normally updated overnight bl batch programs.
The synonym product data set is created offline from the product
data set (see Figure 11-24), by extracting from each product record
the product number and name into a separate data set.
(A typical
product data set record format and product data base DL/I logical
structure are shcwn in Figures 11-31 and 11-32, respectively, for the
distribution industry. ~hese figures are also relevant to the offline
pharmaceutical product data set.) Information needed for invoice
calculations, such as unit price, unit size, discounts, and warehouse
location, is also extracted from the product data set to make up a
synonym record. Slnonym reccrds are sorted into alphabetical sequence
on the product name and are processed sequentially in a batch
environment to generate display images of synonyms based on the first
four to seven characters of the name (depending upcn installation
requirements). The display images cf synonyms are used to generate
the synonym product data set with the first characters of the product
name (that is, the synoDJa name) as the key. Figure 11-25 shows a
typical synonym product record format and the resultant sJnonym display.
Using the product name entered frem the terminal, the first four to
seven characters of the naDe are used to access the synonym product
data set and to retrieve one or several sjnonym displays, each
containing many synonym products. The operator then identifies the
appropriate product. That product identification can be entered with
the next product to be erdered, together with details of that next
product.
By using the synonym ~rcduct data set, the amcunt of data set
accessing which is necessary is dramatically reduced, with a subsequent
potential improvement in online Ferformance and response time.
334
eICS/VS System/Application Design Guide
Synonym
Key
No.
Unit
Product Ordered:
Aspirin
Oty:
Prod.
No.
Product Name
Unit
100
Price
Disc.
Locn.
1142
Aspirin-Tabs
Box
0.23
5%
A1
1143
Aspirin-Pwdr
Box
0.21
5%
A1
1148
Aspirin-Conc
Box
0.32
8%
A1
1155
Aspirin-Brand A
Box
0.20
4%
A2
1156
Aspirin-Brand C
Box
0.22
4%
A2
Figure 11-25.
Synonym Beccrd Format and Display
The pharmacist data set ccntains information relating to the
pharmacist, as shown in Figure 11-26. This data set is accessed at
the start of each order to identify the pharmacist for credit purposes,
accQunt hi~tory, or disccunt.
Pharmacist
No.
I
Credit
Limit
Name
Figure 11-26.
Postal Address
Line 1
J
Line 2
Ship-To Address
1
Line 3
Line 1
J
Line 2
I
Line 3
Account
History
Pharmacist Data Set
The order-in-progress data set is used as a work data set. Each
product ordered by name, together with its quantity, is entered
conversationally and the ap~ro~riate product name is selected from the
various synonyms. This crdered ~roduct is then written to the
order-in-progress data set (see Figure 11-27).
As further products
Order
Cust.
No.
No.
Locn.
No.
Figure 11-27.
Order In-Frcgress Becord Format
are ordered, the order-in-Frogress record is updated until the complete
order bas been received. This is necessary in the event that the
ChaFter 11.
CICS/VS
Ap~lication
Design
335
pharmacist may wish to change Fart cf his order, or cancel particular
products or the entire order before he has co~pleted the order.
Once the order has been completed, it.is then transferred from the
order-in-progress data set tc the acceFted order data set. This is
effectively a direct access file which will be processed overnight as
a sequential data set to uFdate the Froduct data set inventory. It
has the same record format as the order-In-progress data set (see Figure
11-27) •
CNLINE
Fl:;OGIUMS
Q~9~I stj!.);,1 i~~gI.A!!! -
A££§~! R1H!.!!!!s'£.i§i!.§ 19~n!ilig!ion
This Frogram accesses the pharmacist data set, displays the
pharmacist's name, address, and credit information, if reguired for
confirmation, and writes an crder-in-progress record.
The product name and guantity to be ordered are accepted from the
terminal and used to access the synonym data set.
The highest synonym
key of each cylinder may be held in a table in storage, if required
for faster access, to allow the synonym displays for a product to be
retrieved directly. Details relating to the product, such as unit
price, discounts, and warehouse location, are part of the synonym record
(see Figure 11-25) and may be displayed for the operator, if desired.
This program indicates that the entire order has been completed, at
which tiDe the order-in-~rcgress reccrd is transferred to the accepted
order data set, to be used offline overnight to update the product
inventory in the product data set. This program then initiates the
warehouse location seguencing progIam.
!gI~~~~§§ ~Q~s!i2n ~~gY§~~.in£ ~I~9~gl
- ~§9Y§D£§ iI2duc~§
!AI§h2~§§ lQ~s!iQ»
in!Q
This program is initiated automatically by the system at the
completicn of an order. It sequences the orders into warehouse
location, based upon the product's location extracted from the synonym
data set (see above). On completicn of the warehouse location
sequencing, control is passed to the invoice calculation program.
This program takes the order when it has teen sequenced into
warehouse locaticn. Using the unit ~rice, discount, and size supplied
by the synonym record (see Figure 11-2~, it extends each line item
and then calculates the total invoice.
The order, seqienced into warehouse location, is formatted into the
warehouse packing slip and transDitted to a printer in the warehouse.
Following this, the extended invoice is formatted and transmitted to
the same printer so that the packing slip and invoice may be packed
with the ordered products for preinvoicing.
336
CICS/VS System/Application DEsign Guide
CFFLINE FROGBAMS
As described earlier, this pregram accepts the product data set
sorted into alphabetical sequence and then formats display images of
synonym products based on the first four to seven characters of the
product name, for retrieval cnline from the synonym product data set.
Information such as the unit price, unit size, a~~licable discounts,
and warehouse location is also extracted for inclusion in the synonym
record, as shown in Figure 11-26.
At the same time, a synonym display image can be printed to be used
by terminal operators in the event of system downtime, for manual backup
and identificaticn of products ordered.
The accepted crder data set created online is read sequentially by
this program and used to update the stock levels cn the product data
set. Depending upon the freguency of activity of various products on
this product data set, the accepted. order data set may be sorted into
the same sequence as the Froduct data set before execution of the update
program, for better performance. As a result of the product update,
various inventery reForts may be produced, and back orders may be
recorded on a back-order data set.
DATA BASE SUFPORT SElECTION
The selection of data base sUFPcrt for this application can now be
considered. Refer to "Data Ease Selection Criteria" in Chapter 5 for
a discussion of the varicus factcrs relevant to this selection.
In most cases with this a~plicaticn, the data sets contain simple
record formats which may be equally well supported by either DL/I or
CICS/VS file control. In this irstance, the decision on data base
support will generally be dictated by future installation direction
rather than ether considerations. While this particular application
does not need all the facilities of EL/I, the principal advantage of
data independence with Dl/I, and hence reduced maintenance of the data
base. is an important reason for using it. Refer to "DL/I Products"
for the distribution industry later in this chapter, for a discussion
of the use of DL/I to support the product and custemer data bases. The
techniques described are alsc aFFlicable to the pharmaceutical industry.
If the data base support decisicn is to use file control, either
DAM, ISAM, or VSAM may be selected. The order-in-Frogress data set
would normally be supported as a DAM or entry-sequenced VSAM data set.
The accepted orders data set may be supported as a sequential data set,
or as a direct access data set created sequentially. The pharmacist
data set would·typically be ISAM or key-sequenced VSAM. The synonym
data s~t may also be ISA! or key-sequenced VSAM. The product data set
used in a batch environment may be either a direct access data set or
a keyed data set such as ISA! or key-sequenced VSAM. However, the user
should recognize that VSA! should not be utilized cn systems with less
than 144R bytes of real sterage, for ~erformance reasons.
Chapter 11.
CICS/VS Application Design
337
While the product data set does contain some descriptive information
(such as the product name), this data set need nct use variable-length
records unless disk storage is at a ~remium. In the case of the
pharmacist data set, however, the name, postal address, and possible
separate ship-to address may indicate significant disk storage savings
ty defining the ~harmacist data set as a variable-length segmented
record data set. The pharmacist's name, each address line, and the
ship-to address may be made variable-length segments, and, through the
presence or absence of segme~ts, a variable Dumber of address lines
may te supported if necessary. Refer to the discussion of segmented
records in Chapter 5 for a typical segmented customer record. This
segmented record is useful alsc fer a pharmacist data set.
A typical online application in the distribution industry is order
entry and invoicing. This aFplicatien is similar in many respects to
the pharmaceutical order entry system described abeve, but differs in
the area of stock status checking.
ORDER ENTRY AND INVOICING SYSTEM
In this industry, products are generally erdered by product number.
Orders may be accepted ever the telephone, in perscn, or by mail. A
customer number er account nuuiber :is used to identify the person making
the crder. This customer identificaticn is used to access a customer
data set to obtain informaticn such as customer name and address,
ship-to address, and current credit rating_
The significant differences between this application and the
pharmaceutical order entry application are discussed in the following.
since each item is ordered by product number and quantity, the
computer is able to access the product data set directly tc obtain the
preduct name, unit price, Ielevant discounts, and quantity-on-hand.
The quantity-on-hand may te updated immediately to reflect acceptance
of the order. In the event cf an insufficient quantity-on-hand, the
terminal operator may elect to either:
• Accept the quantity available
• Cancel that crder item
• Cancel the entire crder
depending on the customer's requirements.
On completion of the order, the computer can be used to produce an
extended invoice te be transKitted tc the warehouse, together with a
packing slip listing products in warehouse location sequence.
Furthermore, it is possible to produce an invoice as confirmation of
the acceptance of the order if required, by also transmitting a copy
of the invoice tc the terminal. This order confirmation may result in
improved customer service, and is of particular interest for orders
placed in person by the custcmer. In the case of the orders placed by
telephone or mail, the confirmation invoice may te mailed to the
customer if required, depending uFon the delivery time of the actual
products ordered.
338
CICS/VS System/Application Design Guide
The advantages which result from an online order entry system similar
to the one described above are:
• Improved customer service
• Improved credit control
• up-to-the-minute stock status availability
• Fotential reduction in inventery levels
• Bemoval of the need
clerks
~or
stock clerks, pricing clerks, and checking
• preinvoicing, and efficient warehouse picking
Figure 11-28 shows a tYFical crder entry and invoicing system.
INPUT
PROCESSING
OUTPUT
1. Access Customer Record.
2. Display Name and Address.
3. Generate Order-In-Progress
Data Set.
rL---""'... 1
4. Access Product Record.
5. Update Order-In-Progress
Record.
6. Display Order Quantity
Accepted.
7.
Record Back Order Quantity,
If Necessary.
8. Update Product Inventory
With Accepted Quantity.
9. Access Order-In-Progress
Data Set.
10. Sort To Warehouse Location
Sequence.
11. Transmit Packing Slip.
12. Extend Invoice.
13. Transmit Invoice.
14. Access Product Record.
15. Update Product Inventory
With Received Quantity.
Figure 11-28
Distribution Order Entry and Invoicing System
DATA SETS
The data sets used in this apFlication are analogous to those
described for the pharmaceutical industry. The crder-in-progress data
set is used to temporarily held the erder until coapleticn, in the
event of a change in the order or Fossible cancelation of a particular
item or the entire order. The ccapleted order is then transferred to
the accepted order data set. The record format for the accepted order
data set and the crder-in-Frcgress data set is shown in figure 11-29.
ChaFter 11.
CICS/VS Application Design
339
R ' u s t . t---._ _ _-r-_ _p_ro....d_u_ct_1--._
~NO.
Locn.
No.
Figure 11-29.
Accepted Order and Order-in-Progress Record Formats
The customer data set ccntainE Eimilar information to that described
for the pharmaciEt data set and is illustrated in Figure 11-30.
Customer
Credit
NO., Name·
Limit
Figure 11-30.
Postal Address
Line 1
I
Line
J
2
Line 3
Ship-To Address
Account
1Line 21
History
Line 1
Line 3
Customer Eecord Fermat
In this application, prcducts are generally identified by product
number. The product data set can be placed online, allowing the stock
status to be immediately uFdated on acceptance of each line item
ordered. Figure 11-31 illustrate~ a typical prcduct record format.
r-=T
Item Name
~
j
Date of Last
Change
Figure 11-31.
Reorder
Point
Unit
Size
Supplier
No.
Price
Per Unit
DisCount
No. Of
Items On
Order
WareHouse
No.
No. Of Items
Delivered
Stock
Location
r
No. of Items
In Stock
Date Of
Order
Product Beccrd Format
The reorder data set is used to record crders tc be placed on
when the stock status of a product reaches its reorder point.
It may be a separate data Eet, or part of the prcduct data set (see
"DL/I Products" below, and Figures 11-31 and 11-32).
supplier~:
The back order data set is used tc record back crders placed because
of insufficient Etcck. It may be a Eeparate data Eet, or part of the
product data set (see "DL/I Products" under "Data Base Support
selection", and Figures 11-31 and 11-3~.
340
CICS/VS System/Application DeEiqn Guide
Product
Identification
CONTAINS
CONTAINS
CONTAINS
WAREHOUSE NO.
NO. OF ITEMS IN STOCK
LOCATION IN WAREHOUSE
REORDER POINT
Figure 11-32.
Supplier
Information
Product
Information
Warehouse
Information
•
e
e
e
• Contains
• Product Number
• Product Name
.UNIT SELLING PRICE
e DATE OF LAST CHANGE
eUNIT SIZE
eTURNOVER LAST YEAR
eTURNoVER YTD
eSUPPLIER NO •
eUNIT COST PRICE
eUNIT SIZE
eDELIVERY TIME
eQUALITY INDEX
eDELIVERY INDEX
e PURCHASES YTD
eSUPPLIER INFORMATION
Product Data Ease Lcgical structure
ONLINE PBOGRAMS
This ~rcgram accesses the customer data set based on customer number
and displays the customer name, address, shi~-to address, and credit
rating fer confirmation. An order-in-progress record is then created
for this terminal.
~~de~ Enl~~ i~Qg!~m
!~~~~! i~Q~~~! ~rd~~§
-
This program accepts ~rcducts ordered by product number and quantity,
accesses the product data set, updates stock status, determines whether
the reorder ~oint has been reached, and creates a reorder record if
necessary, then adds to the tack order data set if the complete quantity
ordered could not be satisfied. The line item ordered is then used to
update the order-in-progress record for that terminal.
~!g~~ Fi]ish ~~2~~m
-
~ig]~l ~2!Rl~!i£n
21
Q!g~,
This program indicates the completion and acceptance of the order.
The program tran~fers the erder-in-progress record for this terminal
to the accepted order data set. The warehouse location sequencing
program is then automatically initiated by the system.
Cha~ter
11.
CICS/VS ApFlication Design
3q1
!~~ho]§.§ ~Q£~!i~D ~§gY~I~iD9 RI~g~1 - ~~gY§n£~ i1Q~!§ in12
jjI§b~]§i !2~J!i~D
The products in the accepted c:[der record are sequenced on the
warehouse location field, obtainEd when the product information was
initially retrieved from the product data set. This sequenced record
is then written back to the accepted order data set, and control is
passed to the inveice calculatien {regram.
This program extends each line item of the crder, based on unit
price and product and customer discounts extracted from the relevant
data sets during entry of the order. The seguenced order and calculated
invoice are then transmitted to the warehouse.
!~J;~l!QY§.§ Tra!!§li§§i~!! i.5t.9IR.I!! -
11i!!§mi! Rj~1si!!g SIll illS l.u2i~
ja2 jJnJlQ]§§
The order, in warehouse lecation sequence, is prepared as a warehouse
packing slip and transmitted to a printer in the warehouse. The
calculated invoice is then fcrmatted and transmitted to the same
warehouse printer for preinveicing.
If a confirmatien invcice is to te sent to the terminal operator,
a copy of the warehouse invoice is also transmitted to a printer located
near the terminal operater.
Be£~i~§ R~~~I~J!! -
YB~j!§ ~!~£~ ~!~!]§
!i!h
~~£~iBts
This program accepts transactions from the warehouse indicating the
receipt into inventcry of {rcducts ordered against suppliers. The
program accesses the product recerd, increases the stock status, and
reduces the reerder quantity in the reorder data set based upon the
quantity received.
The increased product quantity may be used online to satisfy back
orders in the back crder data set, if necessary, or these back orders
may te processed offline.
RETAIL
S~OBE
SYSTEM
An extension cf the previcusl] described crder entry and invoicing
application applies to the retail stere environment. Here, purchases
made by customers are entered to directly update inventory levels,
calculate the purchase aDcunt (with discounts and sales tax), print a
receipt, and calculate change. The need to print a warehouse packing
slip and invoice is bypassed. The customer selects the required product
from the store, and the receipt tecoDes the custcmer's and the stores
record of the purchase transacticn.
The 3650 Retail store System is specifically designed for this
environment. The 3650 system comprises a 3651 pregraamatle controller
with 9.3 millien bytes of disk storage, a 3653 Foint of Sale Terminal,
a 3275 Display Station, a 32E4 Printer, and a 3657 Ticket unit. Refer
to the .J§.2.Q Re!i.!l ~!QI~ ~l§!i.m l!LtI.Qg.Y.£!i:~!l, GA27-3075, for further
information.
CICS/VS permits cenversational sessions to be established from 3653
or 3275 terminals, and alsc supperts a pipeline session for rapid
authorization of credit transactions. An apFlication program session
342
CICS/VS System/Application Design Guide
can be established fcr ccmmunication between user application programs
in CICS/VS and in the 3651.
(See "3650 Sessions" in Chapter 3 for
further information.)
DATA BASE SUFPOR1 SElECTION
The most appropriate data base sUFPort for the applications is
discussed in the following. Refer to "Data Base Se1ecticn Criteria"
in Chapter 5 for a discussion of the factcrs relevant to this selection.
The advantage of tL/I in this application perBits information
relating to stock availability for a product (across several warehouses)
to be readily identified. Sales information is included in the logical
structure for the prcduct data base (see Figure 11-32), together with
the stock availability in various warehouses. Back crder information
for each product may be maintained across different suppliers, using
the same logical structure.
DL/I may also be utilized to support the custcmer data base. Refer
to "DL/I Products" in ChaFter 5 for a typical customer data base logical
structure.
The order-in-Frogress and -acceFted order data sets will generally
be direct access DAM or entry-seguenced VSAM data sets. This also
applies to the reorder and back-crder data sets which, together with
the accepted-order data set, are created sequentially online, but maj
be retrieved in randcm fashicn.
The customer data set will generally be ISAM or key-sequenced VSAM,
while the product data set may be either tAM, 15AM, or VSAM.
Depending upon the size of the custcmer data set, disk storage
savings may be achieved by using the segmented record feature of file
control and defining the customer r~cord as variable-length, with a
variable number of variable-length segments for name, postal address,
and ship-to address, for example.
If satisfactory perfcrmance is to be achieved, VSAM is not
recommended for computers with less than 144K bytes of real storage.
In this instance, use DAM and 151M as the access methods.
A common online aplication in this industry is a police information
system. In such a systeD, a data base containing all information
relating to criminals is established and maintained.
FOlICE INFORMA!ICN SYSTEM
This online application is dependent upon the quick availablity of
information and the establishment cf lcgical relationships between
items of information. The data base used to provide this necessary
information includes reccrds of criminals, alias names, personal
characteristics, convictions, and !2g~§ ~£§I~Dgi. Information relating
to various crimes and suspects is also recorded. Fersonnel at online
terminals must be able to access this data when given any of several
Chapter 11.
CICS/VS Application Design
343
items of informaticn, such as nalle, alias, 12g'y§ 9~!f!lld.!, and
convictions. The ability to maintain up-to-date, accurate information
about various crimes, criminals, and suspects is a valuable
record-keeping function. A typical Folice information system is
illustrated in Figure 11-33.
.
INPUT
PROCESSING
M!:I
. Validate input.
•
Crimes
•
Suspects
•
Criminals
•
Modus Operandi
2. Display update
confirmation.
3. Update police
[
Etc.
data base.
9.
Access criminal
data set.
Police Data Base
C.
C
5. Access related
records in other
data sets.
6. Display details.
Access crimes
data set.
B. Access related
records in other
data sets.
9. Display details.
L_
Figure 11-33.
O. Search data sets
C
based on selection
criteria.
11. Display selected
information.
Pelice Infcrmation System
The computer effers its mest significant advantages not only in
establishing and maintaining a law enforcement data base, but also in
the analysis of this infcruation. For example, possible relationships
between particular crimes and the J2g'y§ 2~~g! and characteristics
of various criminals can be identified. Used in such a way, an online
police i:nformation system enables the facts relating to a particular
crime to be used in retrievir.g all information relevant to those facts;
the online system then becomes a powerful law enforcement tool.
The STAIRS/VS Program Eroduct (Frogram No. 57QO-XR1) may be used in
this environment. Refer te "Related Publications" in the Preface for
relevant publications.
Both STAIRS/VS and CICS/OS/VS support the use
Storage System, which can be used to satisfy the
base requirements of this aPFlication. The 3850
ranging from 35 to 236 billicn bytes online. It
of the 3850 Mass
massive online data
supports data bases
can be used for
applications with low transaction volume which can toierate long response
times.
(See Chapter 7 fer fcrther infcrmation on the 3850.)
A related application which can utilize the online storage capability
of the 3850 is the legal profession. The 3850 permits legal reports,
344
CICS/VS System/Application Design Guide
cases, research material, ana legislation to be maintaineo online for
search and retrieval based uFon keyword criteria using STAIRS/VS.
DATA SETS
Either of two comFletely oifferent approaches may be taken toward
this application in the definitien of data sets.
Figure 11-33 shows a criminal oat a set with separate oata sets for
criminal personal characteristics, convictions, aliases, and mody§
QR§Ijn~i.
Similarly, separate data sets are shown fer crimes and
suspects. Figure 11-33 illustrates the logical relationships cetween
these data sets, which are shown schematically by lines (representing
pointers) from one data set to a logically related record in another
data set. This oata base structure is oriented toward the use of
CICS/VS file centrol indirect accessing.
A similar data base capability may be provided through the use of
DL/I. This is illustrated in Figure 11-34, which shows the logical
structure of two data bases, a criminal data base ana a crimes data
base.
Information in the criminal data case includes Fersonal
characteristics, aliases, ~g~§ 2E§Ijngi, and convictions as dependent
segments, of which tbere may be multiple occurrences for each type of
segment.
The crimes data base contains information relating to various crimes.
It contains segments describing !~~y§ QE~Ijng!, suspects, and
descriptions, for example.
The selection of the most appropriate data base support is discussed
following the description of the various online FrC9rams.
ONLINE PEOGRAMS
This Frogram accesses all of the information relating to a specified
criminal, including personal characteristics, aliases, BQg]§ Q~Ijng!,
and convictions, and formats that information for oisplay as a series
of pages. Those pages are presented to the CICS/VS terminal paging
routine, which displays them on the terminal in the sequence, and as
reguesteo, by the terminal oFerator (see "Terminal paging" in Chapter
3) •
ChaFter 11.
CICS/VS ApFlication Design
345
Personal
Characteristics
Name
~nVimion]J
I
I
Alias Name
f-
Modus
Operandi
t-
Criminal Data Base
Crime
Details
,1
I Suspecu
]JJ
Figure 11-34.
I
Witness
Descriptions
-
Modus
Operandi
Police Data Base lcgical structures
Crill§ !!l9.YiII R!.Qg.!:A! - ~i§lisI ~li!§.§ !.D!QIlIIA!i~ll
This program accesses all of the information relating to specific
crimes and suspects and Frepares that infcrmation as a series of pages
for presentation by the eIes/VS terminal paging routine tc the terminal
operatcr, on request.
346
eIeS/VS System/Application Design Guide
This program adds inferaation relating to criminals, crimes, and
suspects to the police data tase, or changes existing infermation, thus
enabling the data base tc be dynamically updated and maintained online.
~l~~!io~
fI2g!!! - ~~~~! !!i2I!sii2D ~!§~ 9D !JIioQS ~~i!~Iii
This program searches the available informaticn relating to
criminals, crimes, and suspects~ selecting records which most closely
meet various criteria supplied by the terminal operator. Por example,
the description and characteristics of a suspect may be used to search
the personal characteristics and alias informaticI, to determine if
suspects are known criminals. Alternatively, the !29Y§ 2perangi of a
particular crime may be used to search the .29Y§ 2Ei~~i of all
criminals to identify likely suspects.
The CICS/VS built-in weighted. retrieval function (see "Weighted
Retrieval" in Chapter 5) is particularly suited for this selection
process. However, it can be utilized only for VSA! data sets.
£ATA BASI SUPPORT SELECTION
As discussed previously, two distinctly different data base
approaches may be used for this application. Refer to "Data Base
Selection criteria" in Chapter 5 for a discussion of the factors
relevant to the most appropriate data base support for this application.
~lL! fI2~~~!§
Because of the volatile Dature of information in this application,
it is particularly suited to DL/I. The continual changes which are
made to this data base, and the possible Deed to change the physical
organization of this data base froa tiae to time, make it best supported
by DL/I, with its data independence and hence reduced program
maintenance. Refer to "Segment Beference Design Factors" and. Pigure
5-34 in Chapter 5, for a discussion cf logical structure design for
this application. Figure 11-34 illustrates a logical structure of a
typical police data base.
If the police data base ccntains a considerable amount of textual
information, advantages may te gained ty the use of variable-length
segments with DL/I DOS/VS and I!S/VS DL/I. However, if disk storage
capacity is not a significant factor, the textual information may be
placed in fixed-length seg.ents.
The secondary indexing capability of DL/I is particularly suited to
this application, enabling indeXES to he created by DL/I for direct
retrieval of dependent segments, instead of by hierarchical retrieval
through a logical structure.
This facility is suppcrted by DL/I -ENTRY, DL/I DOS/VS, and 18S/VS.
The support of logical relaticnships by DL/I ENTRY, DL/I DOS/VS aLd
l!S/VS permits the design of sophisticated data tases for this
application. Refer to "10gical ~elationships" and Pigures 5-35 and
5-36 in Chapter 5, fer further discussion.
Por retrieval of DL/I segments, an important consideration in the
use of the file control indexes described above is the CICS/VS built-in
weighted retrieval function. This pcwerful facility is available only
for searching VSA8 files, tut cannot be used directly on DL/I data
Chapter 11.
eICS/VS Application Design
347
bases, unless the data base is a root-segment-only data tase and of
standard VSAM format. In the case of the police iDfcrmaticn system,
the criminal and crimes data bases have a number of dependent segments.
Consequently the weighted retrieval function cannot be used directly
on these DL/I data bases.
However, through the use cf VSA~ for the file centrol indexes
described above, the built-in weighted retrieval function may be used
for searching these indexes and selecting relevant segment keys. The
segment names related to selected keys may then be used to access the
DL/I data base directly, by means of user-developed code.
Alternatively, if file control indexes are not desired, the search
facilities offered by the weighted retrieval function may be readily
iD~lemented by user coding, searching the DL/I data base directly.
The query and selection facilities cffered by STAIES/VS may be used
with data bases created and maintained by STAIES/VS.
As described above, file centrol indexes may te cr.ated to identify
all the DL/I seg.ent names associated with a Farticular key. File
control can also be used to support a police data base, with separate
data sets created for criminals, personal characteristics, aliases,
'!Q!l.Y.§ .Q.Eg~.9!!gi, convictions, crimes, and suspects.
For example, the criminal data set contains all the information
relating to a criminal, together with Fointers to related records for
the criminal in ether data sets (SEe Figure 11-34).
Chaining techniques with file centrol, discussed in Chapter 5 and
elsewhere in this putlication, may be utilized if required. However,
in many cases they will require extra user coding, and will introduce
additional work for the creation and maintenance of these data bases.
Because of the volatile nature of information in this application, and
the multiple occurrence ef dependent information, the use of DL/I rather
than file control for this applicaticn will result in a significant
reduction in user coding, data basE creation, and Ra~ntenance, and a
similar reduction in program maintenance when it is necessary to modify
the data base. The availability of DL/I data base maintenance and
recovery utilities, and the advantage of data independence with DL/I,
is invaluable to this avplication.
A typical online application in this industry is a customer
information system (CIS) as shewn in Figure 11-35. It contains
information relating to the utility companys customers, for example,
name, address, type of acccunt, current account balance, cash paYlients,
service order history, merchandise installment contract, and meter
histories,.
CUSTCMEE INFORHAiICN SYSTEM
The customer infermatien system (CIS) is designed to improve the
efficiency, quality, and accuracy of information and procedures used
principally by the service departments and customer activities
deFartments and, to scme extent, the gas service, gas sales, electric
service, electric sales, appliance service, and appliance sales
departments where they exist within individual utilities.
348
CICS/VS System/Application Design Guide
The customer information system consists of beth online and offline
programs which are designed te provide:
• An inguiry capability into the customer master data set
• A data entry capacity so that service orders or adjustments to the
data ~ase can be entered online
• Control of data entry activities, including the ability to monitor
service crders frem creaticn comfletien
• A historical record of all inguiry or service order activities for
online display at all times
CICS/OS/VS su~ports the 3850 Mass storage System. This provides
massive online data bases ranging frcm 35 to 236 tillionl bytes.
It
can be used for applications with low transaction volume which can
tolerate leng respense times (see Chapter 7).
DATA SETS
The main data set used by this ap~lication is the custemer data set.
A tYFical customer recerd is illustrated in Figure 11-36.
The primary CIS system data set is the customer master data set.
It is made up of segments of information, each of which is a group of
r~lated fields (see Figure 11-36).
Each record need contain only those
segments that are required by that acccunt. For example, not all
accounts contain a deposit segment, since deposits are not reguired
from all customers. Also, each segment that is present can contain
optional fields.
Fer exam~le, the infermatien in the meter segment
can vary from account te acccunt. These segments can be fixed,
dependent upon the requirements cf each particular utility. There are
tasic segments of information that must exist, but no two companies
will use the identical centent. However, the basic concept and record
format should be the same in mest companies. The control segment is
always in every custcmer master record. Information in this segment
allows CICS and data set maintenance modules to determine the specific
format, contents, and relative lccation of each data segment in a given
customer master record.
lOne billion equals 109.
Chafter 11.
CICS/VS
Ap~lication
Design
349
OUTPUT
PROCESSING'
INPUT
Customer Information
Data Sets
--
Inquiry Subsystem
1. Access customer record.
2. Extract requested information.
3. Display requested details.
Service Order Subsystem
Index
4. Access customer uSing customer
name index.
Customer
Name
Index
5. Process service order.
6. Produce service work order.
7. Update activity daw set.
~
Dispatching
Data Sot.
Field Ordar Dispatching Subsystem
B. Access field order dispatching
data sets.
Order
Execution
Standards
OataSet
Order
Execution
Standards
DataSet
Manpower
Available
DataSet
9. Process field order.
10. Update activity data set.
11. Update field order dispatching
dClta sets.
Manpower
Available
Data Set
Man/Crew
Assignment
DataSet
Trouble Order Subsystf1m
12. Access activity data set.
13. Process trouble order.
14. Update activity data set.
15. Produce trouble work order.
Field Order
Dispatching
Data Sets
!2!!!
Collection
Data Sets
Data Collection Subsystem
16. Edit and process data.
17. Add to data collection data sets ..
Payment
Batch
.Summary
Data Set
Extended Descril,Otion
2. Extract following information, when requested:
-
Billingstatus
Billing history
Merchandise
Payments
Credit status
5. Process following requests:
- Order entry
- Order pringing (same day or future)
- Order completion
Figure 11-35.
9. Field order processing:
- Order schadul ing
- Ord~r assignment
- Order dispatching
- Workload statistics
13. Troublo order processing:
- Trouble calls
- Trouble processing
16. Data collection processing:
- Cash payments
- Meter readings
- Control totals
utilities custcmer Information System
The CIS activity data SEt is used to maintain all information
concErning a customer account that is not yet contained in the customer
master data set. The primary function of thE data set is to maintain
pending serviCE crders. When a service order is taken, it is added to
the data set as a pending crder. WhEn the service order has been
EXEcuted, completicn infcrmation is added. The completed service order
is remOVEd from the data set in a batch maintenanCE operation for
offline programs. These offline programs process the data and update
the customer master data SEt.
350
CICS/VS System/Application Design Guide
Control
Segment
Premises
Segment
Customer
Segment
Meter
Segment
Demand
Segment
Electric
Facilities
Segment
Gas
Facilities
Segment
Payment
And
Miscellaneous
Segment
Budget
Billing
Segment
Merchandise
Installment
Contract
Segment
Nonmetered
Service
Segment
Deposit
Segment
Alpha
Overflow
Segment
Bank
Account
Segment
Credit Information
.r:;
b.
c
ServicE'
Start
Date
Customer Name
<1>
...J
History
~
cI5
Cur,ent Bill
(Continued)
Tax
~
n;
c
&.
Bill
Amount
Segment
'"
iii
(5
~
I
24232221120191817 16 15 14131211 1098765432 1
~
Current
Bill
<1>
()
~
n;
Amount
co
Cash Payment
+-'
c
>'"
oo ...~
M«
'">'"...
Cl ~
o ...
<0«
Figure 11-36.
'">'"...
o ~
0)«
0'"
.r:;
~
co
....c
~
!!l
0
0
«E
<1>
~
"CO
8~
«
~
c
~
utilities customer Record Format
~Y~R~~! ~g!g ~§!§
Additional data sets are normally included in CIS which support
operations, but are not primary operational data sets are the customer
master data set and the CIS activity data set. The primary among these
can be termed manpower inforaatien data sets. These data sets contain
serviceman/crew assignment infor.atien. Their primary functions
include:
(1) to assist in scheduling service order execution dates,
(2) to assist in the assignment cf service orders to a specific
serviceman or crew, and (3) to assist in the dispatching of service
orders.
ONLINE PEOGRAMS
The online programs which are ~sed in this apFlication are described
shortly. The application enline functions are performed ty modules
which are linked to one another randomly, depending upon the processing
required by any given online transaction. The functions performed are
as fellows.
ONLINE PFOGRAMS
• Inquiry programs -- previde the ability to query the CIS data base
for billing, payment, account status, outstanding service work,
and credit status and collectien information.
Chapter 11.
CICS/VS Application Design
351
• service order program~s -- pro_ide the ability for online entry of
such service orders as turn-cn, turn-off, meter order, namE
correction, billing adjustment, the printing of service orders,
and the entry cf order ccmFleticn information.
• Field order dispatching Frograms -- provide the ability (1) to
assign service orders to a service-man/crew cnline, (2) to dispatch
and maintain the status cf service orders online, (3) to inquire
into the data base to obtain workload summary information, and (4)
to cbange basic aanpcwer data in the data base online.
• Trouble order programs -- previde the ability to enter trouble
information online and tc print this informatien on a hard-copy
terminal in the trouble dispatching center.
• Data collection programs -- Frovide the ability to enter cash
payment and meter reading information into tbe system from the
remote locations.
Bgtation
R~2gIg~
-
!~!~ ~E§~121 1~~2lD! lD!9!1!!A!j~D
This program allows special instructions to be entered from the
terminal and added to the customer recerd, for subsequent use in
processing that record •
.§~s!£l!
Rl.QSIs1!! -
~~1§~! !;Y§!S1!!~! j.~£~.YD!§ ~~g SJl ~~eciii.§.g
~~i!~!is
This program searches through all or a specified section of th~
custemer data set, retrieving all records which most closely meet
specified selection criteria. For example, all account records in a
particular street, or building, er with certain appliances may be
selected for display. Alternatively, all records whose accounts are
in arrears by more than a specified amount for a specified period of
time can be selected and dis FlaYEd. This program can also utilize the
CICS/VS built-in weighted retrieval function (see "Weighted Betrieval"
in Chapter 5) for selection cf records meeting sFecified criteria from
key-sequenced VSAM data sets.
DATA BASE SUPPOBT SELECTION
The customer data set contains a variety of infermation which may
be present or absent in different records. Either DL/I or CICS/VS file
control can be used. Befer to the section "Data Ease Selection
criteria" in Chapter 5 for a discussion of the factors relevant to the
most appropriate data base support.
A customer data base may te set uF as illustrated in Figure 11-37,
showing the multiple occurrence of dependent segaents such as address
segments, installment contracts, payments, or gas and electric
facilities.
Furthermore, the addition of sFEcial notation information to the
customer record Day te acbieved by adding special notation segments to
the account history segment, with as many special notation dependent
segments as necessary.
352
CICS/VS System/Application Design Guide
Customer
Number
I
Name
TI
Credit
Information
..------,-----.-----r------,------.----------
Premise
(Address)
Demand
Gas
Facilities
Payments
And
Miscellaneous
Meter
Figure 11-37.
Electric
Facilities
Merchandise
Installment
Contract
Billing
r------.------,
NonMetered
Service
Budget
Billing
Bank
Account
Alpha
Overflow
Deposit
customer Data Base Logical structure
While the use of variable-length segments is advantageous if IMS/VS
01/1 or ILII DOS/VS is used, fixed-length segments with DL/I ENTEY are
also fea sible.
~!~~L!~
Eile
~2in!~n2D~~
The customer information system (CIS) data tase should be built
around the use of VSAM. The high-response nature of CIS and the large
volume of transaction processing that cccurs offline make disk
processing efficiency critical. Offline programs usually process
several cycles daily, representing 15 to 25 percent of the entire
custcmer master record. File maintenance and building runs often take
several hours per day and any small degradations can be multiplied into
performance prcblems. Usually, a seguential or skip sequential file
organization technique built around VSAM can test handle the
reguirements of CIS.
VSAM should also be used to support CIS activities. Usually, little
direct file maintenance of the customer master reccrd is performed
online, tut rather is handled offline. Use of VSAM provides a
compatible data tase organizaticn compromise between online and offline
operation.
Information within each record cf the customer master
organized using the CICS segmented record feature, which
to be grouped by freguency of use, function, and logical
Accordingly, it is possible to retrieve an entire record
segments of a given record as ap~rcpriate.
file is
allows data
relationship.
or selected
To permit the addition of segments online, such as by adding pending
order segments, the access method uSEd should te key-seguenced VSAM,
which allows the record length tc be increased or decreased as reguired.
However, VSAM should not te used (if satisfactory performance is to be
achieved) cn systems with real storage less than 144K.
Chapter 11.
CICS/VS Application Design
353
INDEX
ABEND
abnormal termination
245
dump data set
236
dynamic task backout
233
function of
29
partition/region
229
program control
230
program centrol pregram
222
program-level exits
230
recovery from
222
system recovery table
229
Abnormal termination
245
Abnormal termination exit (see SBTJIT)
29
Abnormally terminate (see ABENt)
29
Access calls
180
Activity keypoints
238
Advanced features, CICS/VS
interval control
198
task centro1
197
VSAM support
215
Alarm indicator
56
Anticipatory paging
211
Application backout code
234
Application control bleck generaticn
177
Application control blecks (ACE)
190
Application design
application functions
21
banking industry
customer information system
314
data sets
309
offline programs
313
online programs
310
savings bank and mortgage loan
system
307
distribution industry
data base support selection
343
data sets
339
cnline programs
341
order entry and invoicing system
338
retail store system
342
insurance industry
data sets
321
data sets, policy entry
325
new-business policy entry system
324
enline programs
323,326
policy information system
319
introduction to
10
law enforcement industry
data base support selection
347
data sets
345
cnline programs
346
police infcrmation system
343
manufacturing industry
data base support selection
305
data sets
303
functions
301
offline programs
304
cnline programs
304
production order
302
status reporting system
302
Application design (Continued)
medical industry (Continued)
data base support selection
331
data sets
330
online prograas
330
patient information system
329
objectives
3
pharmaceutical industry
data .base support selection
337
data sets
334
offline programs
337
online prograas
336
pharmaceutical order entry systea
333
utilities industry
customer information system
348
data base support selection
352
data sets
349
online prograas
351
Application functions
asynchronous transaction processing
24
bit manipulaticn
23
designing
21
extended 3270 support
23
field verify/edit
23
input formatting
23
message routing
22
phonetic conversion
24
table search
23
terminal device independence
22
terminal paging
22
weighted retrieval
24
Application program block (AP)
46
Applicatien program sessions
50
Applicaticn programs
212
Asynchronous journaling
268
Asynchronous transaction processing
advantage of
75
batch applications
73
description of
24
priority processing
105
terminal operator commands
74
ATI (see Automatic task initiation)
27
ATTACH maClO instruction
197
Attention ID character
65
Audit
95
Automatic journaling
167
Automatic logging
before delete completed
263
data set backout
167
data set records
257
DATA IDs
259
DL/I data bases
187
dynamic task backout
234
enqueue interlock
241
file centro1 recovery, CICS/VS
256
journaling
258
lockout
241
recording of CICS/VS data set
modifications
225
EUP processing
253
system prefix
261
Index
355
Automatic logging (Continued)
transient data
259
Automatic paging status
37
Automatic task initiation
description of
27
for 3600
1 C4
function of
27
IN-SERVICE status
102
intrapartition data set recovery
269
intrapartition queues
98
RECEIVE status
102
TRANSCEIVE status
102
Automatic tasks
95
AUTOPAGE status
102
Auxiliary storage
support, of temporary storage
214
temporary storage recovery
224,266
VSAM
214
Backup design
289
Backup procedures
290
Banking industry, application design
applications for
115
savings bank and mortgage loan
system
307
audit program
312
change program
311
customer account cross-reference record
format
309
customer infQrmation system
account reference ~rogra.
316
account search program
316
checking account record format
316
CICS/VS file control
318
data base support selection
317
data sets
315
description
314
DL/I support
317
enline programs
316
data se'ts
309
inquiry ~rogram
312
interest calculation program
313
load program
313
mortgage loan program
311
offline programs
313
online applications
308
online programs
310
savings bank account record format
309
savings transaction program
310
selected report writer program
313,313
supervisor program
312
teller journal record format
310
unload and select program
313
Basic graphics access methed
terminal error recovery
75
terminals
42
Basic mapping support
alarm indicator
56
application program sessions
50
deferred output
243
description cf
31
devices used
32
I/O overlap
56
illustration of
33
356
Basic mapping support (Continued)
input formatting macro instruction
66
input ma~ping
55
input message format
64
input messages
35
map residence in controllers
56
maps
32
output mapping
55
output messages
35
pipeline sessions
49
sequential devices used
34
services
32
techniques for using
58
terminal control
40
terminal paging
243
with VTAM
54
3275 host conversational sessions
47
3600 session
46
3653 host conversational session
48
3790 host inquiry session
52
Basic telecommunications access method
terminal abnormal condition program
75
terminal device independence
56
terminal error program
76
terminal error recovery
75
terminals
41
Batch applications
anticipatory paging
211
asynchronous transaction processing
73
batch data base creation
195
batch partition data transfer
88
batch prcgram access
195
batch transaction processing
88
batched message transmission
88
data base backout (batch)
191
description of
73
design of
74
general batch processing
74
page fixing
211
page pool
209
T/P balancing
211
Batch contention
214
Batch data base creation
195
Batch DL/I data base backout
289
Batch DL/1 data base recovery
285
Batch DL/1 system log
286
Batch environment
14
Batch partition data transfer
88
Batch program access
f95
Batch queues
95
Batch transaction processing
88
Batched message trans.ission
88
Before request analysis
268
Benchmark techniques
219
BGAB (see Easic graphics access
method)
42
Bit manipulation
23
Block paging
212
Blocked records
133
BitS (see Basic mapping support)
31 I
BBS ROUTE macro instruction
37
Browse initiation
135
Browse retrieval
135
Browse termination
135
Browsing (see sequential access)
135
BTAB (see Easic telecommunications access
method)
41
CICS/VS system/Application Design Guide
Buffering
277
Built-in function
61
Built-in function (BIF) phonetic cenversion
macro instruction
143
CANCEL macro instructicn
199
canceled transactions
199
Chain integrity
153
change priority
85
CHAP macro instruction
85,191
Check digit
67
CMSG (see Message switching
transaction)
38
Cold start
92
Cold start of CICS/VS
complete
247
functions
224
initialization, CICS/VS
241
Committed output messages
226,242
Communications controllers
44
Concurrent task access
277
Centrol totals
61
Controlled shutdown of CICS/VS
description
223
example
245
extrapartiticn data set recovery
213
following emergency restart
255
intrapartition data set recovery
269
logical recovery
276
program list table (PLT)
244
temporary storage recovery
266
termination, CICS/VS
244
transaction list table (XLT)
244
warm start
247
Conversational applications
58
Conversational message design
58
CPU console as a CICS/DOS/VS terminal
41
CPU sessions
52
CTYPE=CHECK
40
CTYPE=LOCATE
40
CTYPE=STATUS
40
customer record format, segmented
156
cutover design
290
DAM
adding a record
151
batch program access
195
blocked records
133
browse initiation
135
browse retrieval
135
browse termination
135
data base performance
193
data set record location example
direct access
127
file centrol
127
file centrol accessing, CICS/VS
142
193
DAM (Continued)
153
indirect access chain
keys
141
307
manufacturing industry
multiple browse
136
multiple browsing
136
record deletion
263
record location
141
segment updating
162
sequential access
135
unblocked records
131
variable-length record DAM data
sets
132
180
Data base access calls
Data base backout
264
Data base backout (batch)
191
192
Data base backout (online)
Data base backout utility
286
Data base backup
191
191
Data base change accumulation
Data base description
data base access calls
180
function of
112
generation
190
Data base design
6
Data base design, CICS/VS
113
advantages of data bases
application requirements
112
banking industry
application factors
183
application uses for weighted
retrieval
139
chaining technique
126
checking account data base
116
customer account cross-reference data
basE
116
data base chaining
125
data base requirements
117
mortgage loan data base
116
savings account data base
116
savings account logical structure
example
179
data base support for CICS/VS
126
data redundancy
112
distribution industry
accepted order data base
121
custcmer data base
120
data base requirements
121
order in-progress data base
121
product data base
121
segment intent scheduling
186
124
implementation for applications
insurance industry
application uses for weighted
retrieval
139
customer cross-reference data
base
117
118
data base requirements
indirect access
145
policy data base
117
representative/territory data
base
118
113
interrelated information
law enforcement industry
application uses for weighted
retrieval
139
Index
357
Data base design, C1CS/VS (Continued)
law enforcement industry (Continued)
convictions data base
122
crimes data base
122,188
criminal data base
122,188
data base logical structure
185
data base requirements
123
design factors
184
logical data base
188
logical relationships
187
modus operandi data base
122
personal characteristics data
base
122
phonetic ccnversion function
144
secondary indexing
189
suspects data base
122
logical structures
112
manufacturing industry
application factors
183
data base requirements
11~
data base usage
115
indirect access
145
manufacturing planning data basE
115
part numter cross-reference data
base
114
work order data base
114
medical industry
application factors
183
application uses for weighted
retrieval
139
data base requirements
119
diseases data base
118
medication cross-reference data
base
118
patient history data base
118
multiple occurrence i.plementation
124
online application programs
202
pharmaceutical industry
accepted order data base
120
data base requirements
120
order in-progress data base
120
Fharmacist data base
119
product data base
119
synonym data base
119
physical structure
112
requirements
111
requirements summary
124
savin~s and loan data base chaining
125
structures
112
utilities industry
customer data base
123
data base requirements
124
maintenance technician data base
123
Data base design, DL/1
192
Data base I/O error recovery
191
Data base recovery
backout utility
191
data base backup
191
data basE change accumulation
191
data base selection criteria
192
DL/1 log
191
file centrol recovery, C1CS/VS
256
I/O error recovery
191
in system restart
256
read-only data sets
257
Data base selection criteria
192
358
Data base utilities
190
Data base, definition of (see also Data
base design, C1CS/VS)
112
Data communication design
4
Data communications design, C1CS/VS
aids
31
approaches to
31
basic graphics access method
42
basic mapping support
31
basic telecommunications access
method
41
BftS maFs
32
CPU console as a C1CS/DOS/VS
terminal
41
message routing
37
message switching transaction (CftSG)
session types, C1CS/VS
46
synchronous data link control
43
telecommunications access method
42
terminal control and BftS C1CS/VS
40
terminal device independence
32
terminal pa~ing
35
use of VTAft by C1CS/VS
45
virtual telecommunications access
method
43
Data elements
90
Data identification
89
Data language/1 (see DL/1)
114
Data management design
6
Data management design, C1CS/VS
application requirements
87
batch transaction processing
88
data identification
89
data transfer facility
89
file control
114
interval control
89
message routing
89
queuing capability
88
scratchpad capability
87
scratchpad facility
89
temporary storage management,
C1CS/VS
88
temporary storage recovery
92
temporary storage usage
88
terminal paging
89
use of dynamic storage
91
Data redundancy
112
Data set approach, traditional
170
Data set backout
226,261
Data set check
68
Data set passwords
82
Data sets, DL/1
114
Data sets, extrapartition
94
DBD (see Cata base description)
172
DCT modification program
108
Debugging
293
Deferred output integrity
242
DELETE
28
DELETE macro instruction
132,263
Delimiter characters
62
Dependent segment
180
DEQ macre instruction
153,198
Dequeue
198
Design strategy
3
Destination entry
270
Destination identification
96
CICS/VS System/Application Design Guide
39
Device failure
223
Device recovery
284
DFHUAKP, keypoint program
239
Direct access
addition to fixed-length DAM data set
example
132
blccked records
133
exclusive control during update
130
ISAM variable-length records
134
locate mode processing
133
mass record insertion
134
OPEN/CLOSE of data sets
134
random record addition
131
random record deletion
132
random record retrieval
128
random record retrieval example
129
random record update
129
random record update example
130
record identification
140
Direct accesss method (see DAft)
127
Disk I/O errors
223,285
Disk organization, intrapartition
98
Distribution industry
120
Distribution industry, application design
accepted order data set
339
CICS/VS file control
343
customer record format
340
data base support selection
343
data sets
339
DL/I products
343
invoice calculation program
342
online programs
341
order entry and invoicing system
338
order entry program
341
order finish program
341
order start program
341
product record format
340
receipts program
342
retail store system
342
warehouse location sequencing
program
342
warehouse transmission program
342
DL/I
access calls
180
access from CICS/VS
169
accessing
194
additions
187
advantages of
171,173
application control blocks (ACE)
190
batch data base creation
195
batch DL/I data base backout
289
batch DL/I data base recovery
285
batch DL/I system log
286
CALL functions
206
CALLs
194
CICS/VS-DL/I interfaces
194
customer account logical structure
178
data base access
172
data base access calls
180
data base approach
171
data base capabilities
179
data base description
172
data basE description (DED)
190
Data base design, DL/I
192
data base I/O recovery
287
data base organization access
methods
181
DL/I (Continued)
data basE recovery
190
data base recovery example
288
data basE reorganization unload and
reload
190
data base selection criteria
192
data base utilities
190
data independence
176
deletions
187
design factors
183
distribution industry
343
DL/I data base backout during CleS/VS
emergEncy restart
264
DL/I DOS/VS
169
DL/I ENTRY
168
DL/I logging using CICS/VS system
log
264
DL/I termination activity
264
DOS/VS Ferformance
215
dynamic task backout
235
HDAft
181
HIDAM
181
HISAM
176
HSAM
176
IMS/VS DL/I
169
insurance industry
327
introduction to
169
law enforcement industry
347
log
191
logical data structures
177
logical relationships
187
logical structure design
182
manufacturing industry
305
medical industry
331
multiple occurrence of segments
175
online DL/I data base backout
264
pharmaceutical industry
337
products
168
program specification block
172
program specification block (PSB)
190
record format, customer account
177
recovery utility
287
savings account logical structure
example
179
secondary indexing
189
segment design
174
symbolic prograa linkage
180
sync point record
264
termination record
264
updates
186
utilities industry
352
DL/I data base backout during CICS/VS
emergency restart
264
DL/I DOS/VS
additions
187
application control blocks (ACE)
190
banking. industry
317
data base recovery
190,287
data communications support
170
deletions
187
DL/I accessing
194
DL/I logging using CICS/VS system
log
264
function of
169
insurance industry
327
law enforce.ent industry
347
logical relationships
187
Index
359
DL/I DOS/VS (Continued)
manufacturing industry
305
medical industry
331
multiple occurrence of segments
175
performance
215
program specification table
215
record formats
193·
secondary indexing
189
segment design
174
segment intent scheduling
187
statist:i.cs
206
updates
186
VSAM
:215
3850 mass storage system
218
DL/I ENTB~r
additions
187
banking industry
317
data base backout
286
data base recovery
286
data communications support
17C
deletions
187
DL/I accessing
194
function of
168
insurance industry
327
law enforcement industry
347
logical relationships
187
manufacturing industry
305
medical industry
331
multiple occurrence of segments
175
multithread access
194
online DL/I ENTRY data base backout
265
record formats
193
secondary indexing
189
segment design
174
segment scheduling
265
transaction recovery and restart
279
updates
186
VSAM
215
DL/I ENTE1' segment scheduling
265
Dump data set
236
Dump data set recovery
278
Duplicates data set
device recovery
284
for indirect access
150
function
149
implementation
150
Dynamic operator passwords
83
Dynamic password
82
Dynamic storage
for temporary storage
215
general considerations
213
multitasking
203
online performance
202
short on storage (SOS)
202
storage required
202
temporary storage recovery
267
used by temporary storage
91
Dynamic task backout
233
Editing, transaction
66
Emergency restart of CICS/VS
completion of
254
data set backout
261
DL/I data base backout during CICS/VS
emergency restart
264
360
Emergency restart of CICS/VS (Continued)
function
224
initialization, CICS/VS
248
keypoints
238
logical recovery
271
physical recovery \ 210
post-initializatio~ processing,
CICS/VS
251
procedure
250
protected destinations
271
protected messages
242
restart
255
restart data set
248
system failure during
255
system initialization table (SIT)
251
system log
256
system log data set
251
temporary storage initialization
251
terminal oFerator restart
282
253
transaction backout program (TBP)
transaction restart
282
transient data initialization
251
transient data recovery program
(TDEP)
253
use of journals
259
End-of-file utility program
260
ENQ macro instruction
153,198
Enqueue
198
241
Enqueue interlock
Error correction
error field correction
71
error message contents
70
error message documentation
70
example
71
online program maintenance
237
scratchpad capability
87
use of temporary storage
72
Error field correction
71
Error message contents
70
70
Error message documentation
Error statistics
83
ESETL macro instruction
135
Exit routine, program level ABEND
230
Exit time, interval (ICV)
210
Extended 3270 support
23
Extents
260
Extrapartition data set
accessing example
96
batch data transfer
94
buffer ing
277
concurrent task access
277
destination identification
96
disk outFut data sets
274
I/O overlap
277
I/O wait time
277
input data set user recovery
272
line printer output data set
274
logical recovery
276
output buffer flush
277
output data set user recovery
275
physical recovery
275
record accessing
96
recovery
225,278
recovery of
97
input data sets
272
273
output data sets
94
sequential devices
CICS/VS System/Application Design Guide
Extrapartition data set (Continued)
volume switching
277
work file capability
277
Extrapartition data set recovery
271
Extrapartition device failure
285
Extrapartition transient data
95
Fallback design
290
Field edit
67
Field name start character
59
Field separator character
59
Field verify/edit
23
check digit
contro1 totals
67
data set check
68
field checking
67
hash totals
67
key verification
69
limit range
68
reasonableness check
68
sight verification
69
table search
68
zero proof totals
68
File control accessing, CICS/VS
193
File control program
127
File control table (FCT)
128
File control, CICS/VS
access to online data base
166
accessing
19.3
addition to fixed-length DAft data set
example
132
addition to variable-length tAft data set
example
133
additions to data sets
151
ad~antages of segmented records
165
banking industry
318
batch program access
195
blocked records
133
browse initiation
135
browse retrieval
135
browse termination
135
CICS/VS data set backout
225
customer record for~at, segmented
156
data base selection criteria
192
data integrity
187
DELETE macro instruction
263
design considerations, CICS/VS
166
direct access
127
distribution industry
343
duplicates data set
149
dynamic task backout
235
exclusive control during update
130
file centrol table (leT)
128
file I/O area (FIOA)
128
file work area (FWA)
128
GETAREA macro instruction
131
indirect access
144
indirect access operation example
147
insurance industry
327
ISAft variable-length records
134
law enforcement industry
348
locate mode processing
133
management routine
130
manufacturing industry
306
File control, CICS/VS (Continued)
mass record insertion
134
medical industry
332
multiple browse
136
multiple browsing
136
OPEN/CLOSE of data sets
134
parts data base exa.Fle
147
pharmaceutical industry
337
Prctected resources
240
random record addition
131
random record deletion
132
random record retrieval
128
random record retrieval example
129
random record update
129
random record update example
130
record format, customer
154
record format, savings account
154
record identification
140
recording of CICS/VS data set
modifications
225
recovery
256
recovery considerations
167
segment indicator flags example
158
segmented records
153
sequential access
135
skip sequential browsing
137
specification of logical
relationships
148
updating indirectly accessed
records
149
weighted retrieval example
138
weighted retrieval function
137
File I/O area (FIOA)
128
File work area (FWA)
128
Fill-in-the-blanks format
63
Fixed-format messages
61
FftH (see Function management header)
54
Full-duplex transmission
53
Function management header
54
Function password
82
Function programs (FPs)
47
Generation options, CICS/VS
213
GET macro instruction
92,129
GETAEEA macro instruction
131
GETlftE macro instruction
199
GE~NEXT macro instruction
135
GETQ macro instruction
91
totals
67
HDAft
deletions
187
DL/I accessing
194
function of
181
record format
182
reload
190
unload
190
HIDAft
deletions
187
DL/I accessing
194
function of
181
record format
182
~ash
Index
361
HIDAM (Continued)
reload
190
unload
190
Hierarchical direct access method (see
HDA8)
181
Hierarchical direct organization
182
Hierarchical indexed direct access method
(see HIDAM)
181
Hierarchlcal indexed sequential access
lIethod (see HISA8)
176
Hierarchical sequential access method (see
HSAM)
176
Hierarchical sequential organizaticn
181
High-level languages
15
HISAM
data base organizaticn access
methods
181
DL/I accessing
194
file control accessing, CICS/VS
193
online DL/I ENTRY data base back cut
265
record format
181
reload
190
sequential support
176
unload
190
8SA8
data base crganizaticn access
methods
181
DL/I accessing
194
193
file control accessing, CICS/VS
record format
181
recovery utilities
286
sequential support
176
I/O overlap
56,277
I/O wait time
277
ICV (exit time interval)
210
IDERROB
282
18S/VS DL/I
additions
187
application control blocks (ACE)
190
banking industry
317
data base recovery
190,287
deletions
187
DL/I accessing
194
DL/I logging using CICS/VS system
log
264
function of
169
insurance industry
327
law enforcement industry
347
logical relationships
187
manufacturing industry
305
medical industry
331
multiple occurrence of segments
175
online processing
170
record formats
193
secondary indexing
189
segment design
174
segment intent scheduling
187
statistics
206
updates
186
IN-SEBVICE status
102
Indexed sequential access method (see
ISA8)
"127
Indirect ac:cess
362
Indirect access (Continued)
addition of records
152
additions to data sets
151
application examples
144
batch program access
195
chain integrity
153
149
duplicates data set
implementation
146
147
indirect access operation example
initiation
146
147
parts data base example
pointers
152
policy data set
145
product data set
145
specification of logical
relationships
148
updating indirectly accessed
records
149
Indirect destination§
device independence
107
example
106
terminal backup
107
108
terminal reconfiguration, dynamic
Initialization, CICS/VS
247
INITIATE macro instruction
198
Input data sets
272
Input formatting
23
Input mapping
55
64
Input message format
Input messages
attention ID character
65
CICS/VS
35
committed output messages
242
descri~tion of
35
design techniques
61
examples
62
63
fill-in-the-blanks format
fixed-format messages
61
input message format
64
keyword-format messages
63
message logging
78
message recovery
242
multiple choice format
64
use of temporary storage
72
variable-format messages
61
INPUT status
102
Input transaction design
61
Insurance industry
117
Insurance industry, application design
change program
326
CICS/VS file control
327
326
claims and renewals entry program
claims/renewals program
323
correcticn program
326
customer cross-reference record
forllat
322
customer program
323
data base support selection
326
data sets
321
data sets, policy entry
325
delete program
326
DL/I support
327
insurance agent record format
322
new-business policy entry system
324
online programs
323,326
policy class inquiry
323
CICS/VS System/Application Design Guide
Insurance industry, application design
(continued)
policy display program
323
policy entry program
326
policy information system
319
policy record format
321
representative inquiry
323
territory inquiry
323
Integration, CICS/VS
debugging
293
tracing
293
Intermediate results
87
Interval control
CANCEL macro instruction
199
function of
27
GETIME macro instruction
199
INITIATE macro instruction
198
intrapartition queues
98
program
197
PUT macro instruction
198
task initiation
198
temporary storage usage
88
time event cancel
199
time event wait
199
WAIT macro instruction
199
Intrapartition data set
audit
95
automatic task initiation
99,269
automatic tasks
95
batch queues
95
batch retrieval
98
damage
255
destination identification
99
disk organization
97
emergency restart
255
interval control initiation
99
logical recovery
271
physical recovery
270
protected destinations
271
protected resources
240
queue usage
98
record accessing
97
recovery
99,225
reusable intrapartition queues
105
terminal out~ut
95,99,269
terminal output example
101
te~minal status
101
transaction initiation
99
Intrapartition data set recovery
269
Intrapartition queues
98
Intrapartition transient data
97
ISAft (Continued)
sequential access
135
ISAft variable-length records
134
JCP (see Journal control program)
258
Journal cent~ol for sequential data
sets
276
Journal centrol program
258
Journal centrol table (see JCT)
258
Journal records
258
Journal records, user
268
Journal requests
259
Journaling
buffering
217
concurrent task access
277
data
258
during post-initialization
261
format utility program
260
I/O overlap
277
I/O wait time
277
journal control for sequential da.ta
sets
276
journal requests
259
output buffer flush
277
output message
281
preparation of user journals
260
record fermat
276
recovery
278
specification of. 258
terminal input messages
281
transaction journals
260
use of journals
259
volume switching
271
work file capabiiity
277
Key verification
69
Keypoints
activity
238
destination entry
270
DFHUAKP, keypoint program
239
function of
238
keypointing of CICS/VS
237
TeAs in
252
TCT identification
253
warm
238
Keyword-format messages
63
ISM!
browse initiation
135
browse retrieval
135
browse termination
135
data base performance
193
direct access
127
file control
127
file control accessing, CICS/VS
193
indirect access chain
153
IS Aft variable-length records
134
manufacturing industry
307
multiple browse
136
multiple browsing
136
record deletion
263
segment updating
162
Law enforcement industry, application
design
add program
347
applications
121
CICS/VS file control
348
crimes. inquiry prograa
346
criainalinquiry program
346
data base support selection
347
data sets
346
DL/I products
347
online programs
346
police information system
343
selection prograa
347
Index
363
LDC (see Logical device code)
S4
Limit range
68
Line printer errors
284
LINK
2B
LOAD
28
Locate mc)de processing
133
Lockout
241
Logical connection
4S
Logical data structures
177
Logical device code
function of
S4
in a BMS request
56
uses
55
Logical recovery
271,276
Logical structure design
182
Logical structures
112
Logical task synchronization
239
Logical unit of work (LUW)
239
"aero instructions
ABEND
29
A~TACH
197
EIP
143
EftS ROU~E
37
CANCEL
199
CHAP
85,197
CHECK
54
DELETE
28,132,180,263
DEQ
153,19E
editing
67
ENQ
153,1ge
ESE~L
GE~
135
92,130
GET NEXT
180
GET UNIQUE
180
GETAREA
131
GETI"E
199
GE~I'NEXT
135
GETQ
'91
INPORftA'f
62
INITIAT1!:
198
INSER~
180
LINK
,28,93
LOAD
:28
LOCA~E
54
message routing
PURGE
92
PUT
92,198
PUTQ
~J 1
RELEASE
92
REPLACE
180
EETURN
29
SETL
135
SETXIT
29
SPIE
228
STA~US
S~XIT
40
54
228
system programmer
54
terminal control
40
terminal paging
40
TYPE= (ERASE, iRITE)
40
TYPE=CBUFP
40
TYPE=DISCONNICT
40
TYPE=GE1~
364
40
ftacro instructions (Continued)'
~YPE=IN
~YPE=LAS~
TYPE=BAP
TYPE=OU~
40
40
40
40
40
TYPE=PAGE
40
TYPE=PAG!BLD
40
TYPE=PAGEOUT
40
TYPE=PASSBK
TYPE=PUT
40
TYPE=READ
40
TYPE=R!SET
40
TYFE=BCUTE
40
TYPE=TEX~BLD
~YPE=WAIT
40
40
TYPE=WRITE
40
UPDATE
130
liAI~
198,199
ICTL
27
Banufacturing industry
114
ftanufacturing industry, application design
add program
304
cbange ~rogram
304
306
data base logical structures
data base support selection
305
data sets
303
DL/I support
305
file control support
306
functions
301
load program
305
manufacturing planning record
format
303
offline programs
304
online programs
304
part number record format
303
production order
302
production order status report
program
305
report writer program
304
selected report writer program
305
split prcgram
304
status inquiry program
304
status reporting system
302
unload and select program
305
work order record format
303
3850 mass storage system
302
!ap residence in controllers
56
Bass record insertion
134
!aster terminal operation
207
Baster terminal operator training
298
ftAX~ASKS paraaeter
209
Bedical industry
11~
Bedical industry, application design
add patient program
330
CICS/VS file control
332
data base support selection
331
data sets
330
331
diagnosis inquiry program
DL/I products
331
doctor inquiry program
331
medicatien cross-reference record
format
330
medication. inquiry program
331
online application
328
online programs
330
patient history inquiry program
331
eIeS/VS System/Application Design Guide
Medical industry, application design
(Continued)
patient history record format
330
patient information system
329
patient update program
331
Message cache
279
Message design
201
Message integrity
243
Message logging
78
Message recovery
ETAM terminals
280
deferred output integrity
242
protected messages
242
system restart
226
transaction backoutprogram (TEP)
253
transaction journals
260
transaction restart
280
VTAM terminals
279
Message resynchronization
transaction recovery and restart
219
transaction restart
282
VTAM terminals
254,279
Message routing
description of
22
illustration of
39
message delivery
38
techniques for using
58
temporary storage recovery
266
temporary storage usage
88
using VTAM
57
Message switching transaction (CMSG)
description of
39
program backup
235
using VTAM
57
Messages, fixed format
61
Messages, keyword-format
63
Messages, variable format
61
Modular programming
batch environment
14
online environment, CICS/VS
14
program development, traditional
18
structured programming
17
virtual storage environment
15
Multiple browsing
136
Multiple choice format
64
Multitasking
description of
203
maximum tasks
204
Multithread testing
295
NACP (see Node abnormal condition
program)
77
NCP (see Network ccntrcl program)
NCS
213
NEP (see Node error program)
71
Network control program
44
Network control system (NeS)
213
NLT
211
No record found
262
Node abnormal condition program
function of
77
terminal error recovery
283
Node error program
function of
17
Node error program (Continued)
recovery of
211
terminal error recovery
283
Nonredundant storage
113
Nucleus load table (NLT)
anticipatory paging
211
default NLT
121
design
212
page fixing
211
T/P balancing
211
Online cutover
291
Online DI/l data base backout
264
Online DL/I ENTRY data base backout
Online environment, CICS/VS
14
Online program maintenance
237
OPEN/CLOSE of data sets
134
Operating statistics
205
Operator error statistics
83
Operator identification
80
operator passwords
83
Operator security
79
Operator signon
79
Order entry and invoicing
application data base design
9
flowchart
7
function diagram
5
program design
8
OUT-Of-SERVICE status
102
output buffer flush
277
Output data sets
213
Output formatting
72
terminal paging
Output integrity
242
output mapping
55
Output messages
35
committed output messages
deferred output integrity
242
description of
35
journaling
281
message logging
78
message recovery
242
notification of paged output,
example
104
notification of queued
103
output formatting
72
terminal operator notification
technique
103
trigger level
100
Overflow data set
163
265
44
Page building
36
Page contention, CICS/VS
214
Page fixing
211
Page pool
209
PAGE status
102
Paging
211
Partition/region ABEND
229
Password
82
PCT
210
PCT/PPT disable and enable
233
PEP (see Program error program)
30
Index
365
Performance considerations, CICS/VS
anticipatory paging
211
application design
201
benchmark techniques
219
data base design
202
design
212
DL/I DOS/VS performance
215
dynamic storage
202
general considerations
213
generation options, CICS/VS
213
message design
201
multitasking
203
network control system (NCS)
213
nucleus load table (NLT)
211
page contention, CICS/VS
214
page fixing
211
page pool
209
performance evaluation
219
priority processing
204
program design
201
simulation techniques
219
subset option, CICS/DOS/VS
208
system administration
205
T/P balancing
211
transactions, long-term
210
transactions, short-term
210
virtual storage considerations
208
working set, CICS/VS
209
3850 performance
216
Performance evaluation
219,300
Performance monitoring
206
Permanent transaction code
60
Pharmaceutical industry
119
Pharmaceutical industry, application design
CICS/VS file control
337
data base support selection
337
data sets
334
DL/I products
337
inventory update program
337
invoice calculation program
33E
offline programs
337
online programs
336
order entry program
336
order finish program
336
order in-progress reco~d format
335
order start program
336
pharmaceutical order entry systea
333
pharmacist data set
335
synonym data set creation
337
synonym record format and display
335
warehouse location sequencing
program
336
warehouse transmission program
336
Phonetic conversion
24
Phonetic conversion example
143
Phonetic conversion function
143
Physical recovery
270,275
Physical structure
112
Physical terminal security
82
Pipeline session
CICS/VS service supported
49
function of
48
restrictions
49
police information system
344
Post-initialization processing,
CICS/VS
251
366
CICS/VS System/Application Design Guide
Post-initialization programs, user
254
PPT
233
Prefix
258
Preparation of user journals
260
priority change
197
priority processing
change priority
85
example
84
high priority processing
105
high priority task
204
low priority processing
105
low priority task
204
task priority
83
transient data recovery
269
Production cutover, CICS/VS
accuracy of operation
299
follow up
298
master terminal operator training
298
performance evaluation
300
statistics evaluation
299
system operator training
298
terminal operator training
297
to the online application
297
user satisfaction
299
Program backup
235
Program check
application program
228
CICS/VS system module
228
dump data set
236
program tackup
235
storage control
228
Program control
ABEND
29
ABEND macro
228
ABEND macro instructions
230
ABEND requests
230
CICS/VS facilities
28
DELETE
28
LINK
28
LINK macro instruction
230
LOAD
28
RETURN
29
RETURN macro instruction
230
SETXIT
29
XCTL
27
Program control program
222
Program control table (PCT)
210
Program design
batch environment
14
CICS/VS
13
design facilities
13
dynamic task backout
233
functions
5
high-level languages
15
modular programming
14
online environment, CICS/VS
14
program control
27
program development, traditional
18
program error recovery
29
program modularity
202
quasi-reentrant programming
25
tabular structures
15
task initiation
26
techniques
13
vi~tual storage environment
15
Program development, traditional
18
Program dumps
237
Program error processing
30
Program error program
basic mapping support
40
description
30
processing of abnormal task
termination
231
program backup
235
program control ABEND
231
use of
222
Program error recovery
description
29
error processing
30
error program
30
program error processing
30
program error program
30
system recovery program
222
terminal abnormal condition prcgram
75
terminal error program
76
Program library recovery. CICS/VS
279
program list table (PLT)
244
Program maintenance
237
Program specification block
data base access calls
180
function of
172
generating
173
generation
190
Protected data sets
240
protected destinations
271
protected messages
242
Prctected resources
240
Protected tasks
226
PSE (see Program specification block)
173
PURGE macro instruction
92
POT macro instruction
92.198
PUTQ macro instruction
91
Quasi-reentrant programming
Queuing capability
88
Quiesce stage of termination
25
245
Random record addition
131
Random record retrieval
128
Random record update
129
Read-only data sets
257
Real storage availability
167
Reasonableness check
68
RECEIVE status
102
Record format
276
Record format. customer
154
Record format. customer account
177
Record format. savings account
154
Record identification
phonetic conversion example
143
phonetic conversion function
143
record key
140
record location
141
Record key
140
Record location
141
Recovery and restart
ABENDs
222
backup design
289
Recovery and restart (Continued)
backup procedures
290
batch DL/I data base recovery
285
BTAM terminals
~80
CICS/VS facilities
221
cold start
247
cold start of CICS/VS
224
conditions considered
221
controlled shutdown of CICS/VS
223
data base recovery
256
design of
222
device failure
223
device recovery
284
disk I/O errors
223
dump data set
236
dump data set recovery
278
dynamic task backout
233
emergency restart of CICS/VS
224
exit routine. program level ABEND
230
extrapartition data set recovery
271
extrapartition device failure
285
file control recovery, CICS/VS
256
in system design
10
initialization, CICS/VS
247
intrapartition data set recovery
269
journal control for sequential data
sets
276
keypointing of CICS/VS
237
logical task synchronization
239
online DL/I data base backout
264
online DL/I ENTRY data base backout
265
online program maintenance
237
overview
221
partition/region AEEND
229
PCT/PP'l disable and enable
233
program backup
235
program error program (PEP)
231
program errors
222
program-level ABEND exit processing
example
232
program library recovery, CICS/VS
279
prctected resources
240
read-only data sets
257
recovery utilities
287
reestablishment of CICS/VS system
223
SETXIT program processing
231
summary of CICS/VS procedures
227
system recovery program
228
system recovery table
229
temporary storage recovery
266
terminal error recovery
283
terminal I/O errors
223
terminal operator restart
282
termination of CICS/VS system
223
transaction
279
transaction backout program
226
transaction restart
226.282
transient data recovery
269
transient data recovery program
('IDRP)
253
uncontrolled shutdown of CICS/VS
223
warm start
247
warm start of CICS/VS
224
Recovery utilities
287
Recovery utility program (see ROP)
233
Relative byte address
141
Index
367
RELEASE macro instruction
92
Request paging status
37
Resident CICS/VS application programs
Resource utilization
2
Response. time
2
Restart data set
emergency restart
248
terminal input messages
281
Resynchronization (see "essage
recovery)
226
Retail store system
342
RETURN
29
Root segment
156~180
RUP
activity keypoint data
239
ETA" terminals
281
DCT status
253
dynamic task backout
233
emergency restart
239,251
intrapartition destinatiens
252
VTA" terminals
279
212
Scratchpad capability
87
SDlC (see Synchronous data link
control)
43
Secondary indexing
189
Security class
80
Security code
82
Security codes
80
security design
data set passwords
82
dynamic operatcr passwords
83
dynamic password
82
example
81
function password
82
operator identification
80
operator security
79
operator signon
79
physical terminal security
82
reasons for
78
security class
80
security code
82
security codes
80
security enhancements
81
signen program
80
techniques
82
Segment deletion
164
Segment design
154
Segment design, DL/I
174
Segment indicator flags
156
segment indicator flags example
158
Segment retrieval
161
Segment scheduling
265
Segment updating
162
Segmented records
address line segment
155
tit indicators
156
creation of
165
customer record format, segmented
156
dependent segment
180
description
153
design considerations, CICS/VS
166
design factors
183
disk storage utilization
165
368
CICS/VS System/Application Design Guide
Segmented records (Continued)
disk utilization
164
165
dynamic storage efficiency
fixed~length
164
165
limited data independence
maintenance of
165
multiple occurrence of segments
167
overflow data set
163
156
presence or absence of segments
real storage availability
167
record format, customer
154
record format, savings account
154
root segment
156,180
segment definition in PCT
157
segment definition in PCT example
159
segment deletion
164
segment design
154
segment indicator flags
156
segment indicator flags example
158
segment retrieval
161
seg.ent updating
162
variable-l~ngth
164
Sequence numbers
242
Sequential access
browse initiation
135
browse retrieval
135
browse termination
135
multiple browse
136
multiple browsing
136
record identification
140
skip sequential browsing
137
weighted retrieval example
138
weighted retrieval function
137
Sequential data sets
276
Session tYFes, CICS/VS
application program sessions
50
CPU sessions
52
52
establishing CICS/VS sessions
function programs
51
logical units
53
pipeline
48
3275 host conversational
47
3600
46
3650
47
3653 hest conversational
48
3790 host inquiry
51
3790 sessions
50
SETL macro instruction
135
SETXIT
29
SETXIT exit routine
230
SETXIT program processing
231
Shared resources
45
Short on storage (SOS)
202
Shutdown, controlled (see also Controlled
Shutdown ef CICS/VS
244
Shutdown, uncontrolled (see Uncontrolled
shutdown of CICS/VS)
246
Sight verification
69
Signon
operator error statistics
83
signon Frogram
80
Simulation techniques
219
Single-thread testing
294
SIP (see System initialization
program)
249
SIT (see System initialization table)
251
Skip seguential browsing
137
SOS
203,210
SPI! macro instructicn
228
SRP (see System recovery program)
222
SRT (see System recovery table)
222
STAE macro instruction
228
Stages of termination
245
Starter system, CICS/DOS/VS
14
Statistics
205
statistics evaluation
299
storage considerations
208
storage control recovery program
228
Structured programming
advantages of
19
chief programmer operation
19
description
17
evaluation of testing progress
20
module development independence
19
module testing independence
20
resource flexibility
21
top-down programming
19
with CICS/VS
21
Structured systems design
4
STXIT macro instruction
228
Subset option, CICS/DOS/VS
automatic logging
225
data set backout
226
data set recovery
225
emergency restart
248
emergency restart of CICS/VS
224
features sUPForted
208
generation options, CICS/VS
213
installation and use
14
introduction
13
recovery considerations
167
starter system
14
subset option, CICS/DOS/VS
13
terminal errcr program
76
terminals su~ported by
42
Synchronization
239
Synchronization point
239
CICS/VS uses
240
definition of
239
enqueue interlock
241
records
246
Synchronous data link control
43
Synchronous journaling
268
System administration
functions
205
operating statistics
205
performance monitoring
206
system control changes
207
System control changes
207
System design
application design
3,10,201
application design, CICS/VS
301
application functions
21
backup design
289
conversational applicaticns
58
conversational message design
58
cutover design
290
data base design
6,202
data base design, CICS/VS
111
data base requirements
6
data base su~port for CICS/VS
126
data communication design
4
data management design
6
data management design, CICS/VS
87
system design (Continued)
defining program modules
6
design strategy
3
error correction
70
fallback design
290
file control, CICS/VS
127
implementation for applications
124
implementation phase
1
initialization, CICS/VS
247
installation data base support
direction
196
message design
201
multitasking
203
need for
2
order entry and invoicing
5
performance considerations
9
performance considerations, CICS/VS
201
priority processing
83,204
production cutover and followup
10
production cutover, CICS/VS
297
products
168
program tackup technique
236
program control
27
program design
5,201
program development, traditional
18
program error recovery
29
quasi-reentrant programming
25
recovery and restart
10
recovery and restart, CICS/VS
221
resource utilization
2
response time
2
security design
78
security procedures
4
structured
3
structured programming
17
system administration
205
temporary storage management
6
temporary storage recovery
92
terminal error recovery
75
testing and integration
10
testing and integration, CICS/VS
293
top-down programming
19
transaction editing
66
transient data, CICS/VS
94
user acceptance
2
System failure
255
System initialization program
emergency restart
249
system initialization table (SIT)
251
terminal control activation
254
System initialization table (SIT)
251
System log
286
System log data set
251
System operator training
298
system prefix
258
System recovery program
ABENDs
222
abnormal termination
246
program check interception in
228
program errors
222
System recovery table
229
System test
295
T/P balancing
211
Table search
23,68
Tabular structures
Index
369
Tabular structures (Continued)
advantages of
16
banking application
16
description of
15
with 3600 system
17
TACP (see Terminal abnorDal condition
program)
75
Task
239
Task backout
233
Task control
CHAP
197
DEQ macro instruction
198
ENQ macro instruction
198
function of
27
priority change
197
program
197
WAIT macro instruction
198
Task initiation
achieving transaction ID
59
automatic task initiation
27
future
198
interval control
27
methods utilized
26
permanent transaction code
60
task control
27
techniques for using
58
temporary transaction code
60
transaction code
59
transac:tion codes
27
3270 attention ID transaction
initiation
60
Task priority
83
Task sequence number
90
TCA! (se4~ Telecommunications access
method)
42
Telecommunications access method
description of
42
terminal error recovery
75
terminals
42
Temporary storage initialization
251
Temporary storage management, CICS/'S
accessing records
91
data identification
89
data transfer facility
89
GET
92
GETQ macro instruction
91
interval control
89
message routing
89
PURGE macro instruction
92
PUT
92
PUTQ mncro instruction
91
queuing capability
88
RELEAS]~
92
scratchpad capability
87
scratchpad facility
89
selection of temporary storage
93
tempornry storage recovery
92
temporary storage usage
88
terminal paging
89
transaction work area data transfer
TWA size
93
use of dynamic storage
91
VSAft
214
work file capability
92
Temporary storage message cache
281
Temporary storage program
214
370
93
CICS/VS System/Application Design Guide
Temporary storage recovery
after ccntrolled shutdown
266
after uncontrolled shutdown
267
auxiliary storage
224
auxiliary storage residence
266
cold start
92
data set damage
255,255
emergency restart
92
main storage residence
266
messagE cache
279
message routing availability
266
technique
268
terminal paging availability
266
use maF
224
user recovery
267
user-written program
269
using dynamic storage
267
warm start
92
Temporary storage update
259
Temporary storage usage
88
Temporary transaction code
60
TEP (see Terminal error prog~aD)
76
Terminal abnormal condition program
function of
75
terminal error recovery
283
Terminal backup
283
Terminal backup and reconfiguration
108
Terminal control and BftS CICS/VS
40
Terminal control communication
example
76
full-duplex transmission
53
function management header
54
macro instructions
54
terminal I/O overlap
53
Terminal device independence
advantage of
35
basic mapping support
32
descriFtion of
22
dynamic reconfiguration
109
illustration of
34
indirect destinations
107
simulated terminal messages
294
techniquEs for using
58
with VTA! and BTA!
56
Terminal error program
function
76
terminal error recovery
283
user-written
77
Terminal error recovery
BTl!
2S3
data baSE back out
264
device recovery
284
message logging
78
node abnormal condition program
77
node error program
77
terminal abnormal condition program
75
terminal backup
283
terminal error program
76
terminal I/O errors
223
terminal oFerator restart
282
terminal reconfiguration
283
VTAB
283
Terminal I/O errors
223
Terminal I/O overlap
53
Terminal oFerator restart
282
Terminal operator training
297
Terminal paging
advantage of
36
advantagEs of
37
automatic paging status
37
BMS
243
description of
22
illustration of
36
output formatting
72
page.building
36
request paging status
37
status
37
techniques for using
58
temporary storage recovery
266
temporary storage usage
88
terminal device independence
35
using VTAM
57
work file ,capability
87
Terminal reconfiguraticn
283
108
Terminal reconfiguration, dynamic
Terminal sEcurity
82
Terminal status
102
Termination
245
Termination of CICS/VS system
223
Termination, CICS/VS
244
Testing and integration, CICS/VS
293
Testing. CICS/VS
debugging
293
multithread testing
295
simulated terminal messages
294
single-thread testing
294
system test
295
terminal transactions
294
topdown testing
295
tracing
293
Thrashing
214
Time event cancel
199
Time event wait
199
Top-down programming
advantages of
19
chief prograsmer operation
19
evaluation of testing progress
20
module development independence
19
module testing independence
20
resource flexibility
21
topdown testing
295
with CICS/VS
21
Topdown testing
295
Trace entries
293
Trace tape
293
Tracing
293
Training
297,298
Transaction backout program
data set backout
261
description of
262
emergency restart
252
error exit
254
file control recovery, CICS/VS
256
initializaticn exit
253
logged information
258
restart of emergency restart
263
BUP processing
253
system restart
226
Transaction codes
description
27
disabling of
233
59
field name start character
Transaction codes (Continued)
field seFarator character
59
function of
27
information inguiry
80
message recovery
242
permanent transaction code
60
recovery/restart
233
signon program
80
system prefix
258
task pricrity
83
temporary transaction code
60
Transaction editing
check digit
67
control totals
67
data set check
68
description of
59
field verify/edit
67
hash totals
67
key v,rification
69
limit range
68
permanent
60
reasonahleness check
68
sight verification
69
table search
68
techniquEs
66
temporary
60
zero proof totals
68
Transaction journal program
281
Transaction journals
260
Transaction list table (ILT)
244
Transaction recovery and restart
279
Transaction restart
226,280,282
TBANSACTION status
102
Transaction work area
for data transfer
93
Short-term data transfer
93
size
93
variable size requirements
94
Transactions, long-term
210
Transacticns, short-term
210
TBANSCEIVF status
102
Transient data program
270
Transient data recovery
269
Transient data recovery program
(TDBP)
253
Transient data, CICS/VS
extrapartition
95
extrapartition data set
94
GET macre instructions
272
indirect destinations
106,278
initialization
251
intrapartition
97
intrapartition data set
94
program
270
Prctected resources
240
recovery
225
recovery of intrapartition
destinations
269
usage
94
Trigger level
100
TWA (see Transaction work area)
93
TYPE=(EB1SE,WBITE)
40
TYPE=CBUFP
40
TYPE=DISCCNNECT
40
TYPE=GET
40
TYPE=IN
40
Index
371
TYPE=LAS~
40
TYPE=MAP
40
TYPE=OUT
40
TYPE=PAGE
40
40
TYFE=PAGEBtD
TYPE=PAGEOUT
40
TYPE=PASSBK
40
TYJ?E=PUT
40
TYPE=READ
40
TYPE=RESET
40
TYPE=ROUTE
40
TYPE=TEXTBtD
40
TYPE=WAIT
40
TYFE=WRITE
40
uncontrolled shutdown of CICS/VS
before delete completed
263
causes of
246
description
223
extrapartition data set recovery
273
intrapartition data set recovery
270
logical recovery
271,276
message recovery
242
physical recovery
270
protected destinations
271
tem,porary storage recovery
267
u~ of journals
259
UF~TE macro instruction
130
U~er journ al record
268
~ser journals
260
User prefix
258
utilities industry
123
utilities industry, application design
CICS/VS file maintenance
353
CIS activity data set
350
customer information system
348
customer master data set
349
data collection programs
352
data sets
349
DL/I products
352
field order dispatching programs
352
inquiry Frograms
351
notation program
352
search program
352
service order programs
352
support data sets
351
trouble or~~r programs
352
utilities, recovery
285
Variable-format messages
61
Virtual partition size, optimum
203
Virtual storage access method (see
VSAM)
127
Virtual storage considerations
208
Virtual storage environment
15
Virtual telecommunications access
method
43
basic mapping support communication
alarm indicator
56
I/O overlap
56
input mapping
55
logical device code
55
372
54
Virtual telecommunications access
method (Continued)
basic mapping support communication
(Continued)
56
map residence in controllers
output mapping
55
44
communications controllers
CPU program
44
description of
43
52
establishing CICS/VS sessions
full-duplex transmission
53
function management header
54
function program
44
message routing
57
message switching
57
network components
44
network control program
44
77
node abnormal condition program
node error program
77
session types, CICS/VS
46
sh~redresources
45
synchronous data link control
43
techniques for using
58
terminal control communication
53
56
terminal device independence
terminal error recovery
75
terminal I/O overlap
53
terminal paging
57
terminals supported by
44
use of VTAM by CICS/VS
45
Volume switching
277
VSAM
addition of records
152
application uses for weighted
retrieval
139
135
browse initiation
135
browse retrieval
135
browse termination
193
data base performance
direct access
127
132
entry-sequenced data sets
file control
127
193
file centrol acceSSing, CICS/VS
generic key equal
141
141
generic key greater or equal
indirect access chain
153
key equal
140
key greater or equal
140
key-sequenced data sets
131
locate mode processing
133
manufacturing industry
307
mass record insertion
134
multiple browse
136
multiple browsing
136
265
online Dt/I ENTRY data base backout
random record deleticn
132
record deletion
263
record location
141
segment updating
162
sequential access
135
skip sequential browsing
137
support of temporary storage
214
weighted retrieval example
138
weighted retrieval function
137
VTAM (see Virtual telecommunications access
method
Lt3
CICS/VS System/Application Design Guide
WAIT macro instruction
198,199
Warm keypoint
238
Warm start
92
Warm start of CICS/VS
complete
247
description
224
initialization, CICS/VS
247
partial
247
procedure
248
temporary storage recovery
266
use of journals
259
Weighted retrieval
description of
24
law enforcement industry
347
VSAM data sets
215.
Weighted retrieval function
137
Work file capability
87,277
Working set, CICS/VS
209
XCTL
3600 finance communication system
27
Zero proof totals
68
2740 communications terminal
284
2780 data transmission terminal
284
3270
fill-in-the-tlanks format
63
multiple choice format
64
3270 attention ID transaction
initiation
60
3275 host conversational sessions
47
3275 terminal
CICS/VS services supported
47
device recovery
284
3600 finance communication system
automatic task initiation
102
CICS/VS serv~ces supported
46
committed output message
243
committed output messages
226
controller functions
45
data entry application availability
delimiter characters
62
description of
16
device reassignment
109
editing rechniques
69
error correction
70
error field correcticn
71
fill-in-the-tlanks format
63
input transaction design
61
keyword-format messages
63
list of 3600 terminals
46
logical connection
45
message delivery
38
message recovery
242
message resynchronization
254
protected messages
242
session types, CICS/VS
46
67
(Continued)
tabular structure concept
17
terminal ID
38
terminal reconfiguration, dynamic
108
with V~AM and SDLC
44
3614 consumer transaction facility
46
3650 retail store system
application program sessions
50
CICS/VS services supported
47
controller functions
45
data entry application availability
67
distribution industry
342
editing techniques
69
fill-in-the-blanks format
63
input transaction design
61
keyword-format messages
63
list of 3650 terminals
47
logical connection
45
pipeline sessions
49
session types, CICS/VS
46
sessions
47
transaction recovery and restart
279
with VTAM and SDLC
44
3653 host conversational session
48
3653 point of sale terminal
CICS/VS services supported
48
terminals attached to
47
3735 programmable buffered terminal
284
3790 communications system
CICS/VS services supported
52
controller functions
45
data entry application availability
67
description of
51
editing techniques
69
fill-in-the-blanks format
63
functicn programs
51
input transaction design
61
insurance industry
324
keyword-format messages
63
list of 3790 terminals
50
logical connection
45
session restrictions
52
session types, CICS/VS
46
transaction recovery and restart
279
with VTAM and SDLC
44
3790 sessions
50
3790 host inquiry session
52
3850 mass storage system
application profile
218
batch partition activity
217
customer information system
314
data binding
217
description of
215
frequency of data reference
217
insurance industry
320
law enforcement industry
344
locality of data reference
217
medical industry
329
operation
216
performance considerations
216
storage size
216
transaction volume
217
utilities industry
349
3851 mass storage facility
216
Index
373
SH20-9002-2
International EJusiness Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, New York 10604
(U.S.A. only)
IBM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
(I nternational)
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2013:03:25 14:08:28-08:00 Modify Date : 2013:03:25 15:51:46-08:00 Metadata Date : 2013:03:25 15:51:46-08:00 Producer : Adobe Acrobat 9.52 Paper Capture Plug-in Format : application/pdf Document ID : uuid:1d365d71-5367-4882-9d95-b59a7e0f6aab Instance ID : uuid:7a017501-ac22-4c85-ae0d-f249a843187b Page Layout : SinglePage Page Mode : UseOutlines Page Count : 394EXIF Metadata provided by EXIF.tools