SH20 9145 0_IMS_VS_Version_1_Primer_Sep78 0 IMS VS Version 1 Primer Sep78
SH20-9145-0_IMS_VS_Version_1_Primer_Sep78 SH20-9145-0_IMS_VS_Version_1_Primer_Sep78
User Manual: SH20-9145-0_IMS_VS_Version_1_Primer_Sep78
Open the PDF directly: View PDF 
.
Page Count: 494
| Download | |
| Open PDF In Browser | View PDF |
SH20-9145-0
Program Product
IMS/VS Version 1 Primer
Program Number 5740-XX2
Release 1.5
This edition is a revised edition of the I~S/VS Primer World Trade
System Center Bulletin (5320-5767-2) dated September 1977.
This edition addresses I~S/VS Data Base Facilities and IMS/VS Data
Communication Facilities. This edition applies to IMS/VS Version 1
Release 1.5, program number 5740-XX2, under OS/VS1 or OS/VS2 Release 2
(MVS), using BTAM or VTAM and the IBM 3270 Information Display System.
Information in this publication is subject to significant change.
Any
such changes will be published in new editions or technical n~wsletters.
Before using this publication, consult the latest I~n §I§1~!ll!Q
~ieiiQg£~Ea!. GC20-0001, and the technical newsletters that amend the
bibliography, to learn which editions and technical newsletters are
applicable and current.
Requests for copies of IBM publications should be made to the IBM branch
office that serves you.
Forms for readers' comments are provided at the back of this
publication. If the forms have been removed, comments may be addressed
to IBM Corporation, P.O. Box 50020, Programming Publishing, San Jose,
California 95150. All comments and suggestions become the property of
IBM.
© Copyright
International Business Machines Corporation 1978
This publica tion is intended for first -t ime users of the Informa tion
Management System/Virtual Storage (I~S/VS). It provides system
analysts, data base specialists, system programmers, and application
programmers with the information nec~ssary for the design, installation
and operation cf their initial applications, using a subset of the data
base or data basE/data communication facilities of IMS/VS.
The IMS/VS Primer Function comprises five separately orderable
documents. One is this document (SH20-9145). The second is the I~~LY~
f~!!~~ ~g!E!~ ~i§~iD9~ (SH20-9149), containing a complete IMS/VS sample
application including generaticn input, source program examples, data
base sample data and executicn out~ut. ~he third is the I]~L!~ f~!m§£
~~~I~I I~~!iD~l ~E~IsI2I!§ §Yig~ _. ]lA~ (SH20-9146), containing a
sample operating guide for the master terminal operator of IMS/VS using
the Basic Telecommunication Access Method (ETAM). The fourth is the
l~§L!~ E£i!~I ~s§I~I l§ImiDgl Q!~I~12I~§ ~y~~~ -- !!!~ (SH20-9147),
containing a sam~le operating guide for the master terminal operator of
IMS/VS using the Virtual Telecommunication Access Method (VTAM). The
fifth is the !~§LY§ ~!im~I R~!21~ I~I!iD~l Q~~~sIQI~§ ~Yi[~ (SH20-9148),
containing a sample operating guide for the IMS/VS end-user/terminal
operator. The manuals are designed to be used together, i.e., the !MS/VS
Primer and the Operating Guides extensively reference the samples in the
IMS/VS Primer SamFle Listir.gs.
The primary objective of the IMS/VS Primer Function is to provide the
first-time user cf IMS/VS a single document containing all of the
information the user would ordinarily need to:
•
Plan for IHS/VS use
•
Design Dl/I data bases
•
Design, writE, and test IHS/VS programs
•
Install the ISS/VS program Froduct (5740-XX2)
•
Operate IMS/VS
•
Maintain IMS/VS
The only other I~S/VS publications the user of the subset would normally
have to refer to arE the l~~LY~ ~~D~Ial IDIQIm~!1Qn ~!nY~l and the
I~~L!~ ~~§§g~~§ ~Dg ~Qg~§ ~~~~t~n£~ ~~n~~l·
Whil~ the IMS/VS Primer is oEsignEd
ap~licable to other customers, such
for the new IHS/VS user, it is
as:
•
The currently installed lMS/VS user who has a continuing training
requirement, and
•
The currently installed IMS/VS user who is implementing new
applications for departments having no experience using IHS/VS.
By using the apprcach
sugg~sted in the IMS/VS Primer, users can avoid
much of the complexity usually associated with IMS/VS. Many of the
steps required to install I~S/VS can be shortened, simplified, and/cr
accomplished in a mcre crd~rly manner.
About This Manual
iii
The IM5/V5 Primer !! B2l intended to eliminate the need on the part of
the user for carEful Flanning, close coordination, dnd guidance by
experienced systems perscnnel, detailed study of the application
requirements, rigorous program testing, proper operating procedures,
etc. It l~ intEnded to be a learning guide, a source of field-proven
techniques and advice, a tested sample system, a subset reference
manual, and an operator's guide. By following this manual, users should
progress quickly and ccnfidently through the steps required for
implementation of a simple, initial IMS/VS application.
~S2E!_2~_~b!_~~DY!!
Each user has the responsibility to assess the applicability of the
1M5/V5 Primer Functicn tc his requirements. If desired, users can ask
for guidance and counsel from an IBM representative or system engineer.
The assessment must be made with a full understanding of the scope and
intention of the IeS/VS Primer Function.
Only a subset of the full facilities of IMS/VS is addressed. Although
the subset is rich in function, a custemer's application might require
additional IMS/VS functions.
If a user requires facilities not included in the subset, he should
reconsider, if necessary, any recommendations given here.
agID!!~ 2~ ~2D~§nl§
This manual is organized inte nine
chaFt~rs.
•
Chapter 1, "Introduction." introduces the If!5/V5 data base and data
base communication facilities and a sample application used
throughout the manual. The chapter is divided into a DE facilities
section and a DC facilities section. It also provides a brief
overview of our IMS/VS subset.
•
Chapter 2, "Data Base Design," provid~s the data base specialist and
system analyst with information and guidelines for data base design.
This chapt~r is applicable to both the DB-only user and the DB/DC
user.
•
Chapter 3, "Data Communication Design," contains a detailed
description of the IMS/VS data communication facility. It provides
guidelines for the design and implementation of data communication
applications using these facilities. This chapter can be
disr~9arded by the tf-only user.
•
ChaptEr 4, "Data Base Processing." guides the application programmer
i~ the design. codi~g and testing of DL/I batch and If!S/V5 message
proc@~sing programs.
Only the first part of the chapter is
applicablE to the DB-only user.
•
Chapter 5, "Data Base Reorganization/load Frocessing." describes
when and how data bases should be reorganized.
•
Chapter 6, "Data BaSE Recovery," guides the data base specialist and
operations staff in the ilplementaticn of data base recovery
proced ures.
•
Chapter 1, "Installing IMS/VS," guides the system programmer througb
the installaticn of a subset of IMS/VS data base and data baSE/data
communication system. It also addresses the installaticn of IMS/VS
in the Systems Netwcrk Architecture (SNA) environment.
iv
IMS/VS Primer
•
Chapter S, "Operations," contains guidelines for the design of
operating procedures for the I"5/V5 online system. It shows how to
adapt the sample master terminal and remote terminal operator guides
to your own environment. This chapter can be disregarded by the
DB-only user.
•
Chapter 9. "Optimization," describes how to monitor and optimize a
running application.
Every chapter except the seccnd, third and eighth is divided into two
parts. The first part of each chapter deals with the data base
management pcrtion of 1"5/V5. The second addresses 1MS/V5 data
communication. For your convenience, the fcllowing table defines those
parts of this manual of interest to each functional area in your
organization.
CHAPTER
MI\NAGEMENT
1. INTRODUCTION
2. DB DESIGN
J. DC DESIGN
4. DB PROCESSING
5, DB REORGANIZATION
6. DB RECOVERY
7. INSTALLATION
8. OPERATION
9. OPTIMIZATION
•
DB/DC
ADMINISTRATOR
DATA
DATA BASE COMMUNICATION
SPECIALIST
SPECIALIST
•••
• ••
.-••
•••
• ••
••
•
• ••
•••
••
••
••
••
* ••
.-
..1,
••
• ••
••
••.
...
'
SYSTEM
ANALYST
SYSTEM
PROGRAMMER
APPLICATION
PROGRAMMER
•••
• ••
••
_.-••••
••
*
• ••
.*
-
•
•
•
*.
• ••
• ••
•••
OPERATION
*
--•
-
• ••
•
•••
••
••
LEGEND:
• Reader should be familiar with contents.
• • Reader should know specific parts in detail.
••• Reader should have complete detailed knowledge,
Eefore using this manual, you should be familiar with the IB~ Cperating
System for Virtual Storage (OS/VS1 or OS/VS2). This manual's design is
such that the new IMS/V5 user will need to make few, if any, references
to other IMS/VS publications, except for the ~!n!~!l Int2I~!!Qn ~!nygl
~H20-1260) and ~!§§!g!~ !n~ £Qg~~ B!t!~!n£! ~!ng!l (5H20-9030).
The
more advanced us~., however, will find additional information in the
listed associated publications.
The reader should be familiar with the information presented in: !~aL!~
Ge~Ig! In!2I!s!i2D ~~~Y~l (GH20-1260) (especially Chapter 1,
"Introduction to IMS/VS," and Chapter 4, "System Configuration").
About This Manual
v
The following I~S/VS Publications should be used if you have a nEed for
more IMS/VS information beyond the scope of our subset:
•
!~~L!~_§I§~~!LAE£!i£~!i~~_~~§igD_§Big!,
•
I~~L!~_!EE1!£~~iQn_f~Qg~~!!ing_l~~~~!~£~_tt~Dygl,
•
1~~L!~_~l§!!~_fIQ9Ig!!lDg_~st~I!D£!_~~nY~1, 5H20-9027
•
l~§L!~_Q]§IgIQI!§_R!t!Isn£!_~~D~~l,
•
1~~L!~_~S11i11s§_R§~§I~n£!_~~~~~1,
•
I~§L!~_~Q~_~!!!!_~Q~!l~2!t!nYiiI fh!£~_!n_]~~g_L!D9Y!9!L!_~!29!!!
•
I~~LY§~~!Qq~s!_!Qqi~_~~nY~!L LY20-8069
vi
5H20-9025
SH20-9028
SH20-9029
R~~!~~n£~_~n2_f£~!~~i2]_~~]~~!L 5H20-9047
IMS/V5 Primer
5H20-9026
CHAPTER'. INT~CDUCTICN.
What Is IPIS/VS? • • ••
Why Data Bases? • .. • • • • • •
Our Sample Environment •
Our Sample Company's Requirements ••
The Phase , Environment • • • •
The PARTS Data BasE • • • •
!he PARts Inventory Reports.
PurchasE Order Processing. • •
The Phase 2 EnvironmEnt • • • • •
!he Customer Crders Data Base.
Customer Order Processing. •
The Phase ~ Environment ••
The IMS/VS Data Ease System.
System Definition • • • •
Data Lanquage/I Facility.
DL/I ConcEpts.
Environm~nt Definitions • • • • • •
Data Independence • • • •
Applicat ion Data Structure •
• • • • •
Hierarchical Data Structure. • •
• •
Basic Segment Types in a Hierarchical Data Structure •
Sequence Fields and ACCESS Paths •
Logical Relationships.
Secondary Indexing ••
Data Base Definition • • • •
Data BaSE Description ••
Program Specification Block.
~pplication Program Interface • •
Logging and Checkpoint/Restart Facility.
Data Security • • • • • •
Utility Programs • • ~ ••
IMS/VS Batch SystEm Flow • •
Data Base Administrator ..
DEA Characteristics.
• •••••
Naming Conventions •
•• • •
Naming Conventions for Entities ...
Sample Job Names.
• •••••
Sample Distribution and listings
~he Project Approach • • • • .. •
The Project Cycle • • • • • • • • • • • •
Sample Project Plan for I~S/VS DE. •
Gross PERT Chart . . . . . ..
The IMS/VS Data Communication Feature.
Scme Basic SNA concepts. • •
.,
Separation of Functions into Logical Layers ••
Th~ Transmission Subsystem Layer
'Ihe Function Management layer..•
The Application Layer • • • •
End Users, Nodes and Sessions.
VTAM Role in SNA • • • • • • • • •
• •••
Starting and Stopping the Network • • • • • •
Changing the Configuraticn Dynamically
Allocation • • • • • • • • • • • • • • •
I/O Process ing •
Reliability. Availability. S~rviceability ••
Nep/VS and the 3705 Communications Controller • • •
. ..
·..
·. .
0
•
•
•
• •
1. 3
1.4
1.4
1. 4
1.4
1. 4
1. 5
'.5
,. 5
1. 5
1.5
1.6
1.6
1.6
1. 7
·...
•
..
'.9
'.9
,. 10
u
, .. '2
1. 13
,. '3
,. 13
n
...·.....·.
·....
·.
Q
·.
q
•
•
•
..
•
..
•
•
..
•
1. 14
1. 1 "
1. 14
'.15
,. 15
,. 17
,. '7
1. '7
,. 1 8
1. 18
1. 19
1. 19
,. '9
1. 20
, .20
1. 24
1.24
1.25
Q
io
1. 1
,. 1
· . . '.2
·.
· . . . . . · . ·· .. ..
·...
,. "
1.5
Q
0
1. ,
,. 25
1.25
...
•
Contents
1.25
'.25
1.26
1. 26
1.26
1. 26
'.26
1. 26
1.26
vii
I"S/VS Data Communicaticn Ccncepts •
Physical 1erminals
• • • • •
•
3270 Device Compatibility_ •
Logical TErminals.
Ma ste r Te rmina 1 •
Input "essages •
Output Messages.
Message Format Service • •
MessagE Queueing •
Conversational Processing.
Security •
Terminal Command Language.
•
Transaction Response ~ode.
•
MessagE SChEduling •
Logging and Checkpoint/Restart
•• •
Logging.
Checkpoints.
Festart.
Utility Programs •
IMS/VS Data Communicaticn System Flow.
Batch Processing of Online Data Bases.
Data Communication Administration.
DCA Characteristics.
Sample IMS/VS Project Flan ••
I~S/VS Primer Functicn Subset Overvi~w •
Data Base Subset ••
Data Communication Subset.
CHAPTER 2. tATA BASE DESIGN.
About This Chapter •
Sample Data Base Requirements.
Phase 1 Sample Reguirements •
PAR~S Data Ease Contents.
Inventory Report Precessing.
Purchase Order Processing.
phase 2 Sample Requirements.
Sample Data BasEs fer Phase 2.
Sample Application for Fhase 2 •
Phase 3 Sample Requirements.
The DL/1 Data Ease Facili~y.
Physical Data Ease and Storage Organizations •
The DL/I tata Bas~ Record.
Segment Format
!he Concatenatp.d Key •
Calls and Data Ease Positicning.
Get Uni gue •
Get Next •
Hold Form of Get calls •
Insert •
Delete
Replace.
SSA.
OS/VS Access Methods Used by DL/!.
HDAM and HIDAM StoragE Crganizations •
HDAM and HIDA~ Access Characteristics.
HDAM •
HIDAM.
Inserts and Deletes in HDAK and HIDAM.
Pointers in HDA~ and HIDAM •
Physical Child/Physical ~win Pointers.
SHISAM Storage Organi2ation.
Functions and Use of GSAM.
When to Use GSA!'!
Supported rata Sets.
viii
IKS/VS Primer
•
•
•
•
•
1.26
1.26
1.27
1.. 27
1. 27
1.27
1.28
1.28
1.28
1.29
1.29
1.29
1.30
1.30
1.30
1.31
1.3'
1. 31
1.32
1. 32
1.34
'.34
1.34
1.35
1.35
1.36
1 .. 38
2. 1
2. 1
2.2
2.2
2.2
2.2
2. 3
2.3
2.3
2.4
2.5
2.5
2.5
2.6
2.7
2.8
2.9
2. 10
2.10
2. 10
2.10
2.10
2. 10
2.10
2. 10
2. 11
2. 1 1
2. 1 1
2.12
2. 13
2.14
2.14
2. 15
2.16
2. 16
2. 16
D1/I Logical Relationships • ..
0
•
.. .
..
Why Logical Relationships • • •
Building Logical Relationships .. .. .. • •
Segment Types Involved in Logical RelationshiFs ••
Logical Child Segment. •
• •••
Logical Parent Segment.. .. • • • •
Physical Parent Segment • • • • • • • • • • • • • • • • • •
The Virtual Logical Child Segment • • • • • •
!he Destination Farp.nt .. .. • • •
logical and Physical Data Bases.
lhe Concatenated Segment
Logical Relationship Desigfl Eules • •
Rules for Defining Logical,RelationshiFs in Physical
Da ta Ba sese • ..
.. • • ..
Logical Child • •
Logical Parent • •
Physical Parent. • •
Rules for Defining Logical Data Bases. • • • •
Processing Logically Related Segmentsq ..
Deleting Logically Related Segments ..
Logical Child.
Logical Parent • .. • .. • ~ • .. • • • • • • •
Physical Parent • • • • • • • • • • •
Inserting Logically Related Segments • ~
Log i c a lIP h Y sic alP d r e n t. • • • • • •
Logical Child • • • • • • • • • • • •
Replacing Logically Felated Segments •
Logical RelaticnshiFs IIFlementation -!echnique in
HDAM/HIDAM. .. •
Pointers Used for Logical Relationships in HtAM/HIDAM
Logical Parent Pointer (lP) • • • • • • • •
logical Child First 'Pointer (LCF). • .. • ..
Logical Child Last Pcinter (LCL)
Logical Twin Forward Fainter (LTF) • • • •
Logical Twin Backward Fointer (LTE) ...
Ph ysi cal Parent Po in ter (PP) • • • •
DL/l Sec onda ry I nde Xe s .. • • •
When to Use Seccndary Indexes • • • • • •
Segment 'IYFes Involved in Secondary Indexes ••
Design Rules for Secondary Indexing.
Implementation technique • • •
Index Pointer Segment Format •
Creating a Seccndary Ind€x •
Data Ease Description Generation •
DBDGEN Coding Conventions. •
Easic £BDGEN Control Statement Format ••
DBD Statement.
DA~ASE! Statement.
SEGM Statement •
F1:ELD Statemento
LCHIL D St at ement
DBDGEN Statement • • • • • • • • • • •
FINISH Statement
END Statement. •
• •••
Execution of DEDGEN (Jel) • •
Examples of Physical DBDs.
DBDGEN for GSAM • • • • • • •
DBDGEN for Logical Relationships •
Coding a logical Relaticnship in a Physical DBD ••
Logical Child. • • • • • • • ~ •
• • • • • •
Physical and Logical Farent..
• •••••
Exampl~s of Physical DBDs with Logical Relationships •
Ceding a Logical DED •
DED St atement. • • •
DA~ASE! Statement.
q
Q
If
..
••
·..
·..
••
0
u
•
•
•
...
U
Q
0
•
•
Q
..
..
•
..
•
•
•
••
•
2. 17
2. 17
2.17
2.17
2. 18
2.18
2. 18
2. 18
2.'9
2. '9
2. 20
2.21
2.22
2.22
2. 22
2.22
2.22
2.2~
2.24
2. 24
2.24
2. 24
2.24
2.24
2.24
2.24
2.24
2.25
2.25
2.25
2.25
2.
2~
2.25
2.25
2.25
2.26
2. 26
2.27
2.28
2. 28
0
2.29
Q
2.29
2.30
2.3'
·..
••
0
......
Con ten-+:s
2.31
2.33
2.35
2.37
2.38
2. 39
2.39
2. 39
2.39
2.40
2.42
2.43
2. 43
2.44
2.45
2.46
2.47
2 .. ~7
2.48
ix
SEGM statement • • • • .. .. • .. • •
Cl3DGEN, FINISfJ and END statements •• • • • • • • • • • • •
Example of Logical DBDs . . . .
tSDGENs for Secondary Indexes. • • ..
Coding an Index Target Data Base • • •
Coding the Index Target Segment. •
SEGK statement • • •
LCHILD Stat~ment • • • • • • • •
XDPtD Statement. • • • • • • • •
Coding the Index Source Segment.
SEGM sta tement •
FIELD Statement ..
Coding a Secondary Index DBD
DBD Statement. • •
DATASET Statement • • • • •
SEGM Statement ••
lCHILD Statement ....
FIELD statement. • • • •
• •••••••
Program Specification l3lock Generation (PSBGEN) • • • • • •
Easic PSB Coding • • • • • •
• •••
PCB statement. • • • •
• • • • • •
• ••••
GSAM. PCB • • • • •
• • • • • •••
SENSEG Statement •
• • • •
• •••••••••
PSl3GEN Statement
• • • •
• •••
END Statement • •
Sample Basic P SSs. •
• •••
Execution of PSBGEN (JCt) • •
Coding PSBs fer Lcgical Data Bases •
Coding PSBs for Secondary Indexes ...
The PCB Statement. .. • • • •
The Data Base Design Process ...
Concepts of Cata Ease Design
Entities . . . . .
Data Elements • •
The Tra nsac tion.
Access Paths ••
The Transaction/Data Element Matrix ••
The Data Ease Design Tasks •
.. .. • •
Gathering Requirements. •
• • •
• •••
Phase 1 Transaction/tata Element Matrix • • • • •
Phase 2 Transaction/Data Element Matrix • •
Phase 3 Transaction/Data Element Matrix ...
Design the Application Data Structure.
Phase 1 Application Data Structure •
Access Paths • • • • .. ...
• .. •
!he Root SegmEnt SE1PABT • • • •
The Stock Segment SE1PSlOK • • •
The Purchase Crder Segment r SE1PPUR ••
Phase 2 Applicaticn Data Structure •
Phase 3 Application Data Structure . . . . . . . . . . .
Design the Fhysical Data Structures.
Phase 1 Physical Data Base Design.
Selectinq Data Eas~ Crganization •
When to Choose HDA[IJ. •
• .. •
When to Choose H!DAM • •
• •••••
When to Choose SHISAM ••
Which OS/VS ACCESS ~ethod.
Physical Segment Design. •
Performance Aspects. • •
•• • • • • ....
Physical Data Base Structure fo= Phase
Coding the Phase 1 FARTS OED, HD~M •
Considerations for Pcinter Selections. • • • •
Selecting CI/Block si 'Zes. • • • • • •
ANCH, REN, BYTES and SIZE Parameters for HDAM.
Example r Our PARTS Data Base • • •
...
.... ·......
·· .. .. . . . . . .
·......
............ ..
·..
·...
·...
..
...
·..
... .
0
·...
0
x
IMS/VS Primer
..
·...
·...
• • • • •
..
2.q8
2.tJ9
2.49
2.50
2. 51
2.51
2.51
2.51
2.52
2.53
2.53
2.53
2.54
2.5q
2.5tJ
2.5q
2.55
2.55
2.57
2.58
2.58
2.59
2.59
2.60
2.61
2.61
2.62
2.62
2.63
2.63
2.6q
2.64
2.65
2.65
2.66
2.66
2.67
2.68
2.69
2.70
2.70
2.70
2.74
2.74
2.74
2.75
2.75
2.75
2.75
2.76
2.77
2.78
2.78
2.79
2.79
2.80
2.80
2.80
2.80
2.81
2.82
2.82
2.83
2.84
2.84
Defining VSA~ Data Spaces • • • • •
OSA~ tata Set Allocatien • • • • •
Phase 2 Physical Data Ease Design • • • • •
Phase 3 Physical Data Base Design.
Design Evaluation • • • • • • • • • • •
2.85
2.85
2.85
2.86
2.87
CHAP!ER 3. DATA CC~MUNICATICN DESIGN.
The Phase 4 SamFle Requir€E€nt •
Phase 4 Sample Data Eases.
Phase 4 Batch Programs • • •
Phase 4 Online Programs.
· .
IMS/VS Data Communication Facilities •
The Message. • • • • • • • • • • • •
Multiple and Single Segment Messages •
IMS/VS Online Operation Cverview
The CTL Region •
• • • •
The MPP Fegion
!he EMP Region
~
Relationship of DB/DC to DB System • • • • • • • • • • •
The DL/I BegionG • • •
Terminal Input Data Processing •
• • • •
Input Message Types. • • • • • • • • • • • •
Input Message Origin • • • •
Terminal Input Destinaticn •
Message Queueing
Queue Size, Perfor!ance Consideration.
Message Sc~eduling • • • •
Scheduling Conditions.
Scheduling a B~P • • • • • •
Data Base Processing Intent. • • • •
Application Program Processing • • •
MPP Processing •
Role of the FSE.. • • • • .. •
DL/I Message Calls • • • • •
Program Isolation and Dynamic Logging ••
Application Prograro Abnermal Termination
Conversational Processing. •
• •••
output Message Processing. •
Logging and CheckpOint/Restart
Logging ••
Checkpcinting.
Cold Start • • • • •
Emergency Restart
Normal Restart
Security • • • • • • •
• •••
The Master Terminal.
Using the CS/VS Console as a Master !erminal •
3270 Remote Copy Function. • •
~essage SwitchingQ • • v u •
Message Format Service Overview • • • • • •
MFS and the 3270 • • ••
Relationship between MFS Centrel Blocks ••
MFS Control Block Chaininq • • • •
Linkage between DFLD and ~FLD. • • • • •
Linkage between LPAGE and DPAGE • • • •
Optional Message Description Linkage ~ •
3210 Device Considerations Relative to Control Block
Linkage • • • •
MFS Functions • • •
Input Message formatting • • • • •
Input Data Formatting Using MFS.
Input Message Field Attribute Data
IMS/VS Pass~ords • • • • • • • • • • • • • •
3. 1
3.1
I· .
3. 1
3.1
3. 1
...
3.3
3.4
3. 5
3.5
3.6
Q
0
Q
•
•
•
d
•
•
•
Q
•
•
•
•
q
•
•
q
u
3. 2
•
3.7
3.8
3.8
3.9
3. 10
3. '0
3.10
3. 10
••
Q
...
3 .. 1 1
3.12
3. 12
3.'4
3. 14
3. 14
a
Q
•
0
••
u
•
•
..
Q
0
3.15
•
·...
0
•
0
•
•
•
•
'J
•
0
3. 15
3.15
3. '5
3. 16
3.16
3. 16
3.17
3. 18
3. 18
3.18
3. 18
3.20
3.20
·.
Q
3.6
3.6
3.7
3.7
3. 7
••••••
u
3.2
3.2
3.20
3.22
3.22
3.23
3. 24
3.24
......
3.24
....
3.24
3.25
3.25
Contents
xi
Qutput Message Formatting.
Output Data Formatting Using MFS •
"ulti~le Segment Out~ut ~essages •
Logical Paging of Cutput Messages.
Operator Paging of Cutput Messag~s •
Output Message Literal Fields.
Output Device Field Attributes •
Cursor Positioning.
••
•
System Message Field (3210 Display Devices).
Printer Page Format CentIol ••
MFS Formats Supplied by 1M5/VS •
MFS Control Statements •
Relations between Source Statements and Control Blocks.
Naming COD,entions •
Utility Syntax •
MFS Definition Statements.
MSG Statement.
LPAGE Statement.
PASSWCED Statement •
5IG Statement ...
DO Statement •
HFLD Statement •
"
EN DDO Statement.
HSGEND Statement •
FMT Statement.
tEV Statement.
DIV Statement.
tPAGE Statement ••
DO Sta temen t •
DFLD Statement ••
ENDDO Statement.
,
FM!END Statement •
Compilation Statements •
TI~LE Statement.
PBIN! Statementw
SPACE Statement.
EJEC! StatementQ
EttD Statement.
Sample Formats •
MFS Control Blcck Generation •
Step 1
•
Preprocessor •
Phase 1.
Step 2 •
Phase 2.
Step 3 •
Sample MFS Generation Job.
MFS Library Maintenance.
FSEGEN for MPPs and BMPs •
Additional PSB Coding Conventions.
The Data Communicaticn PCB •
The PCB Statement.
~he Data Base PCE.
Additional PrOCEssing Intent Options.
Example of an Online FSE • •
Application Control Blcck Generation (ACBGEN).
JCL Requirements •
Required Control Statements.
ACBG!N Executicn •
The Data Communication Design Process.
concepts of Cnline Transaction Processing.
Application Characteristics.
Terminal User Characteristics.
IMS/VS Characteristics •
xii
IMS/VS Primer
3.25
3.25
3.27
3.27
3.27
3.28
3.28
3 .. 29
3.29
3.29
3.29
3.30
3. 31
3. 31
3.32
3.32
3.32
3.33
3.34
3 .. 34
3. 34
3.35
3 .. 38
3. 38
3.38
3. 39
3.40
3.40
3.41
3.42
3.4U
3.44
3 .. 44
3.4U
3.45
3.45
3.45
3.45
3.46
3 .• 47
3.48
3.48
3.48
3.48
3 .. 48
3.48
3.49
3 .. 49
3.49
3.49
3.50
3.50
3.50
3.51
3.51
3.52
3.52
3.52
3.53
3.53
3.54
3.54
3.54
3.54
Transaction Response Time Considerations
Choosinq th~ Right Characteristics •
Online Program Design.
Single Versus Multiple Passes.
Cne Fass Update.
Two Pass Update.
Multi-Pass Update.
Conversational Versus Ncn-Ccnversational
General MPP Structure/Flow •
Transaction/Program Grouping • •
MessagE Format Service Design.
Basic Screen Design.
MFS Subset Restriction
General Screen Layout Guidelines •
Including the Transaction Code in the Format •
Design of a SamFle Inquiry Transaction •
Design of a Sample Update Transaction.
Al t er nat iv e '
Sing Ie Fass Upda tee
Alternativ~ 2 -- Two Pass Update •
Alternative 3 -- Multi-Fass Update.
Which One to Choos€.
• ••••
Our Sample Conversational Program.
Miscellaneous Design Ccnsiderationsq
Online Data Base Design.
Using Secondary Indexes.
Preferable Data Ease Crganization.
Online Limitation of SHISAM.
Using an Intermediate tata Ease.
3.55
3.55
3.56
3.56
3.56
3. S6
3.57
3.57
3.57
3.59
3.59
3.59
..
3.60
0
4. DATA EASE FRCCESSING • • •
Structure of ThiE Chapter.
Introduction to Data Ease Frocessing •
Program St.ructure and Interface to DLII •..
langu~ge and Compilation
Interface Components.
Entry to Applicaticn Program •
PCB-Mask. •
Calls to DI/I.
Function Argument.
PCB-Name A'I'gum~nt.
I/O Work Area Arqument •
Segment Search Arguments •
'Iermination.
status Code Handling •
• •
SamFle Presentation of a Call..
• •
Basic Data Base Processing.
DL/I Positioning Concept •
sample Environment. • a
Fetrieving Segments.
The Get Unique Call -- GU.
The Get Next Call -- GN • •
The Unqualified Get Next Call.
!he Qualified Get ~ext Call.
Get Hold Calls •
Updati~g Segmentso
Deleting Segments.
Inserting Segm~nts
Calls with Command Cedes • •
D Command Code •
N Ccmmano Code ..
F Command Code •
L Command Code •
- Command Code
••••
Data Bas~ Positioning After a DL/! Call ••
Using Multiple FCrs for Cne rata Ease • •
3.60
3.60
3.61
3.6'
3.62
3.62
3.62
3.62
3.63
3.63
3.63
3.64
3.64
3.64
3.64
4.1
4. 1
4. 1
4.2
CHAP~F.R
4.2
4.2
4.4
4.5
Q
.....
4.1
4.8
4.8
4.8
4.9
4.11
4. , ,
4. 12
4.13
4. '3
4 .. '3
4. '4
4. 14
4.15
4. 16
4.16
Q
4. '8
4. 18
4.19
4.20
4.21
4.21
4.23
4.23
4.23
4.23
4.23
4.24
Contents
xiii
·..
.......· ..
4 .. 25
· ..·..
4.31
4. 31
·..
4.33
4.34
system service Calls • • • •
The STAT Call. • • • • • •
Processing GSA! Data Bases • • • • •
Loading a Basic tata Ease ••
Sample Data Base Load Program. • • • • • •
Loading a HID1M Data Base. • • • • • • •
• • • •
Sorting Segments in Hierarchical Sequence. • •
• •••
Loading a HDAM Data Base • • • • • •
• • • •
•• • •
Loading a SHISA~ Data Base .. • • •
• • • • • • •
Status Codes for Data Base Loading
Status Code Error Routine • • • • • •
Assembler Programming Consideration. •
Using the SamplE Rcutines • • • • • • • •
JCL for Assembly and linkage Editing •
Cobol Programming Considerations .. • ..
JCL fOL Compile and Linkage Editing.
JCL fcr Program Execution • • • •
PLII Programming Considerations.
ether PL/I considerations.
Using the SamplE Rcutines. • ..
Link-Editing PLII Prcgrams for DL/I • • • • • • • • • • • • •
SamFle phase 1 Programs . . . . . . . . . .
Processing with Lcgical RElationships • • •
Accessing a Logical Child in a Physical DBD. • • • •
ACCEssing Segments in a Logical OED.
Retrieve Calls • •
• ••••••
Replace Calls.
.. • • •
• • • • • •
Delete Calls ..
Insert Calls •
• • • •
..
Loading Data Eases with lcgical Relationships.
Loading thE Phase 2 Data Bases.
• •••••••••••
Sam~le Phase 2 Programs. • • • ..
Processing with Seccndary Indexes••
Accessing Segments Via a Secondary Index • • • • • • • •
Retrieving Segments. ..
• .....
REplacing Segments
Deleting Segments. • • • . . . .
Inserting Segments .. •
Sample phase 3 Programs.
Secondary Index Creation ...
Batch Checkpoint/Restart.
Using the XRST and CH~F Calls.
The Restart Call • • • • • • •
The Checkpoint Call. • • • •
Using GSAM with Checkpoint/Festart . . . . . . .
Sequential Input FilES • • • • • • • • • • • • •
Sequential Output Files. • • • • •
Sample Eatch Checkpoint/Restart Programs.
Data Communication Apflicaticn Programming • • •
Application Programming and MFS
Applicaticn Prcgram TYFES . . . . . . . . . . . . . . . . .
General MPP Considerations • .. •
General BMP Considerations • • •
Additional CHKP Status Code in a BMP •
MPP Structure and IMS/VS Interface . . . . . .
DC PCBs • • • • •
I/O PCE • • • •
Al terna te PCE.
The DC-PCB Ma sk.
COBOL Example of a DC-PCB Mask
PL/I Example of a DC-PCB Mask ••
Entry to the MPP • • • .. • • • •
Q
••
'. . . .
..·..
·..
·.
...
...
.·..
·..
..
xiv
IMS/VS Prim€r
4.24
4.25
4.26
4.27
4.28
4.28
4.29
4.29
4.29
4.30
4.32
4.32
4.33
4. 35
4 .. 36
4.36
4.36
4.37
4.37
4 .. 37
4.37
4.37
4.38
4.38
4 .. 38
4.39
4.39
4.39
4. 39
4.39
4.40
4.41
4.41
4.41
4.41
4.41
4. 41
4.42
4.44
4.45
4.45
4.45
4.45
4.46
4.46
4.46
4.46
4.47
4.47
4.47
4 .. 48
4.48
4 .. 48
4.49
4.50
4.50
4.50
The DC Calls • • • • •
• •••
Get Calls (GU, GN) • • • • •
I nse rt Call (1 SRT)
change Call (CHNG) •
Basic Message Formats. •
• •••
Input Message Forma t •
• • • •
• •••
Output Message Format. • • • • • • • • •
Fie Id Forma t • • • •
• • • •
Dynamic Attribute Modification and Cursor Control • • • • • •
!'!ultiple Page Output Messages. •
• •••
Wr it i ng a si mpIe MPP • • • • • • • •
• • • •
Sample COBOL Inquiry Program • • •
COBOL Compile Options for MPPs • •
• • ••
Sample PL/I Inquiry Program. •
Handling Error Status Codes. • • •
•• • • • • • • • • • •
Conversational Processing. • • • •
• •••••
Retrieving the SPA and Terminal Input. • • • •
Layout of SPA User Work Area • • • • • • • •
I npu t Me ssage Form at. • • • • • • •
Data Base Processing in Conversational Mode • • •
Inserting the SPA and Terminal Output ••
Output Message Format. • • •
• • • •
Terminating the Conversation
••••
Writing a Conversational MPP •
• •••
Sample Conversational MPPs
• • ••
Testing Your MPP • • • • • • • •
4.51
4.52
4.53
4.54
4.55
4.55
4.56
4.57
4.57
4.58
4.58
4.60
4.60
4.62
4.63
4.63
4.64
4.65
4.66
4.66
4.66
4.66
4.67
4.68
4.70
4.70
CHAPTER 5. DATA BASE REORGANIZATION/LOAD PROCESSING ••
About This Chapter • • •
• • • • • • • •
What is Reorganization • • • • • • •
• •••
When to Reorganize. • • • • • • • •
• •••
The Frequency of Reorganization. •
• •••
Steps in Reorganization. • • • • • •
• •••
Ov~rview of the Reorganization/Load Utilities ••
Physical Reorganization Utility Programs
The INDEX. Reorganization Utilities • • • • •
The HD Reorganization Utilities. • • • • • •
Logical Relationship Resolution Utility Progr:tms •
Data Base Prereorganization Utility.
Data Base Prefix Resolution Utility • • • • •
Data Base Prefix Update Utility. • • • • • •
INDEX Reorganization Unload Utility {DFSUFULO)
JCt Statements • • • • • •
Utility Control Statement • • •
Return Codes • • • • • • • • • • • • • • • • •
Output Messages and Statistics
Example • • • • • • • • • • • •
INDEX Feorganiz ation Reload Utili ty (DF SUFRLO)
JCL Statements • • • • • • • •
• •••
Return Codes • • • • • • • • •
Output Messages and Statistics ••
~xample • • • • • • • • • • •
HD Reorganization Unload Utility (DFSURGUO).
JCL Sta te ments • • • • • • • •
Return Codes • • • • • • • • •
Out put Me ssagp. sand St atisti cs
Example • • • • • • • • • • • • • •
HD Reorganization Reload Utility lDFSURGLO).
JC L Sta te me n t s • • • • • • • •
• • • •
Ret urn Codes • • • • • • • • •
Out put Message sand St atisti cs
Example • • • • • • • • • • • •
5. 1
5.1
5. 1
5. 1
5.2
5.2
5.2
5.3
5.3
5.3
5.3
5.3
5.3
....
......
....
5.4
5.4
...
5.4
5.5
5.6
5.6
5.6
5.6
5.7
5.8
5.8
5.8
5.8
5.9
5.'0
5. 10
5.10
5.10
5. 1 ,
5.12
5. 12
5. 12
Contents
xv
Data Base Prereorganization Utility (DFSURPRO)
JCL Statements •
Utility Control Statements •
Return Code s ••
Output Messages.
Data Base Prefix Resolution Utility (DFSURG10)
Restrictions ••
JCL Statements •
Return Code s • •
Output Messages and Statistics.
Data Base Prefix Update Utility (DFSURGPO)
JCt Statements.
Ret urn Codes •
Output Messages.
Physica 1 Fe organiza tion.
Reorganizing an INDEX Data Base.
Reorganizing a HIDAM or HDAM Data Base •
Indications that Databases May Need Reorganization ..
OSAM Data Bases -- (HDAM only)
VSAM Da ta Bases.
Initial Data Base Load Processing.
Loading Data Bases with Logical Relationships.
Loading Data Bases with Secondary Indexes.
Work Data Set Allocation
Size of Workfile 1 •
Reorganizing Data Bases with Logical Relationships/Secondary
Indexes.
Applying Structural Changes.
Cha nging a Ph ysical DBD.
Adding Logical Relationships/Secondary Indexes.
Examples •
Reorganizing in an Online Environment.
5. 13
5.13
5. 14
5. 15
5. 15
5. 15
5. 15
5. 16
5. 18
5.19
5. 19
5. 19
5.20
5. 20
5.20
5.20
5. 21
5.22
5. 22
5.22
5.23
5.23
5.25
5. 25
CHAPTER 6. DATA BASE RECOVERY
~hat is Recovery?
Two Approaches ••
Basic Recovery.
DL/I R'?covery.
Which One to Choose.
The DL/I Logging Facility.
The DL/! Recovery Utilities.
Data Base Image Copy Utility (DFSUDMPO).
J CL Statements •
Utility Control Statement.
Return Codes.
Exa mple s •
Data Base Change Accumulation Utility (DFSUCUMO)
JCt Statements •
Utility Control Statement.
Return Codes •
Exa mple •
Data Base Fecovery Utility (DFSURDBO).
J CL Stat em en t s •
Utility Control Statement.
Return Codes •
Fxamples •
Data Base Packout Utility (DFSBBOOO)
J CL S tat em e n t s •
Utility Control Statement.
Ret urn Codes •
Exa mple.
System log ~ecovery Utility (DFSUtrRO)
Step 1: DUP Mode.
Step 2: REP Mode.
JeL Statements.
6 .. 1
6. 1
6.2
6.2
xvi
IMS/VS Frimer
5.25
5. 26
5.27
5.27
5.27
5. 28
5. 28
6. 3
6.4
6.5
6. 5
6.7
6.7
6.8
6.8
6.9
6.9
6. '0
6. 11
6. 11
6. 1 1
6 .. , 2
6. 12
E. 13
6.14
6. 14
6. 14
6. 16
6. 17
6.17
6.
6.
6.
6.
6.
17
18
18
19
19
..
....
Utility Control Statements •
Catalog Considerations •
Examples .. • • • • • • •
Basic Recovery Procedures.
Examples • .. • • • .. • • •
DL/I Recovery Procedures .. • .. • • .. • • •
Assumptions and Restrictions •
Possible Failures. • • • • • •
Correcting the Cause of the Failure.
Recovery Tasks • • .. • • .. .. • .. • • • • • • ..
Image COPY/Log Administration . . . . . . . . . . . . . . . . . .
Examples . . . . . . . . . . . . . . . . . . . . .
Frequency of Image Copies and Change Accumulations.
F.etention Period of Image Copies and Log Data sets • • • • •
VSAM Cat alog Consideration • .. .. • .. .. • • • • •
Data Base Recovery in an Online I'-'S/VS System ••
System Log Terminator Utility (DFSFLOTO)
J CL St at ements .. • • • •
Examples • • • • • • • • • •
Online Recovery Procedures • • •
Assumptions and Restrictions ••
Possib Ie Fai lure s.. • • • • .. • • •
Correcting the Cause of the Failure.
Fecovery Tasks • • • • • • • • • • • • • • • •
Log Tape Administration in an Online Environment ..
Log Tape Data Set Names. • • • • • • •
Log Ta pe Se ria I Numbe r s .. • • • • .. • .. • • • •
Log Tape Con trol For ms .. • .. • • • • • • • • •
Frequency of Image Copies and Change Accumulation.
Retention Period of Online Log Tapes •
• ....
6. 19
6.20
6.20
6.20
6.21
6.21
6.21
6.21
6.22
6.22
6.23
6.25
6.25
6.26
6.26
6.26
6.27
6.27
6.28
6.28
6.28
6.28
6.29
6.29
6.31
6. 31
6.32
6.32
6.32
6.32
CHAPTER 7. INSTALLING IMS/VS.
The Installation Process • • • •
OS/VS1 Preparation . . . . . . .
OS/VS1 VSAM Considerations
OS/VS1 VTAM Considerations (DC only)
IMS/VS Supervisor Call Routine
Optional Program Products. • •
Installing a DB System or a DB/DC Sys~em •
Installing IMS/VS-DB • • • • • • • • • •
Creating the IMS/VS-DB Libraries • • • • • • •
..
The IMS/VS-DB Distribution Libraries ••
The IMS/VS-DB System Libraries • • •
The IMS/VS-DB Application Libraries.
The IMS/VS-DB Primer Function Sample Libraries.
Restoring the IMS/VS-DB Distribution Libraries • • • • • •
!MS/VS-DB Stage 1 System Definition . . . . . . . . . ' • • •
Coding t he 1M S/VS- DB System Defini tion Mac rose •
IMS/VS-DB Stage 2 System Definition • • • •
OS/VS1 Final Preparation . . . . . . . . . . . . ..
Relink the OS/VS Nucleus with the I~S/VS Type 2 SVC • • • • •
Copy IMSRDR Procedure to SYS1.PFOCLIB.
• •••
1M S/V S-DB lnst allation Jobs.
• • • •
• .. • •
Installing IMS/VS DB/DC. • • • • • • •
• • •
Creating the IMS/VS Librariesv • • • •
The IMS/VS Distribution Libraries.
The IMS/VS Sample Libraries • • • • • • • • •
The IMS/VS System Libraries. . . . . . . . . . . . . . . . . .
The IMS/VS Application Libraries • • • • • •
The IMS/VS Online Libraries and Data Sets • • • • • •
Restoring the IMS/VS Distribution Libraries ....
IMS/VS DB/DC Stage 1 Definition • • • • • • • •
System Environment Macro Statements • • • • • • • • •
Data Base and Application Macro Statements.
Data Communications Macro Statements • • • •
7 .. 1
7. 1
..
.
Contents
7.2
7.3
7.3
7.3
7.4
7.4
7 .. 4
7.4
7.4
7.5
'7.5
7.5
7.5
7.5
7.6
7.8
7 .. 8
7. 8
7.9
7.9
7. 1 1
7 .. 1 1
7. 1 1
7 .. , 2
7.12
7. 12
7.13
7.13
7 .. 13
7.14
7. 14
7. '5
xvii
Resource Naming R ul9s • • • • • • • • • • • •
Coding the 1MS/VS System Definition Macros • •
1M S CTFL [II acro. •
I MSCTF Macro • •
IMSGEN Macro ••
MSGQUEUE Macro.
SPAREA Macro ••
BUFPOOL S Macro • • • • • • •
DATABASE Macro •
APPLCTN Macro.. •
TFANSACT Macro •
Coding the Data Communication Statements -- VTAM •
COMM Statement • • • • • • •
TYPE statement • • • • • • •
TERMINAL Statement • • • • •
NAM E St atement • • •
• •
Coding the Data Communication Statements -- BTAr! •
COMM Macro ••
LINEGRP Macro. •
L1 NE Macro • • •
• • • •
CTLUNIT Macro. •
• ••••••••
TEFMINAL Macro.
• ••••
NAME Macro.
• ••••••••••••
Structure of the Stage
Input Deck.
• ••
IMS/VS Stage 2 System Definition
••••••••••
as/vs 1 Final Preparation • • • •
• • • •
Copy IMSRDR and IMS Procedures to SYS1.PRaCLIB •
Relink the OS/VS Nucleus • • • • • • • •
Customize IMS Control Region Procedure ••
Update DFSVSMOO Member in IMSVS. PRaCLIB • • • • • • • • • • •
Create DFSPIXOO Member in IMSVS.PROCLIB • •
Update Initial System Security Tables.
Update IMSMSG Procedure ••
PL/I Optimizer Considerations. •
Preparing VTAM • • • • • • • • • • • • • • • • • •
Creating the VTAM Libraries ••
Defining VTAM Start Options ••
Def ini nq IM S/VS to VTA!'!. • • •
Defining the local Network to VTAM
Defining the Remote Network to VTAM ••
Creating the VTAM Start Cataloged Procedure • • •
Generating the Network Control Program (NCP)
overview • • • • • • • • • • • • • • • •
Restoring the NCP Distribution Libraries
Creating the NCP Data Sets • • • • • • •
Defining the Remote Net work to VTAM. • • ••
File NCP Source Deck into SYS1.VTAMLST •
Stage 1 of NCP Generation.
Stage 2 of NCP Generation • • • • • • • • • • • •
IMS/VS DB/DC Installation Jobs • •
Executing the IMS/VS Primer Sample Jobs.
Initializing the Sample Environment.
Phas e 0 Jobs
••
Phase 1 Job s
Phase 2 Jobs
Phase 3 Jobs
phase 4 Job s • •
Recommended Test Sequence ••
RDAM Randomizinq Modules •
General Randomizing Module.
Writing a Randomizing Module
Randomizing Module Interfaces.
A Simple Key-Sequential Randomizing Module
DL/I Data Base Buffering Pacilities.
Log Tape Write Ahead • • • • • •
......
..·..
...
...
.....
·..
.. .. ..
....
·..
·..
....
...
xviii
IMS/VS Primer
7. 16
7.18
7. 19
7. 20
7.21
7.23
7.23
7.23
7.24
7.25
7.26
7.27
7.27
7.28
7.29
7.30
7.31
7.31
7.31
7.32
7. 32
7. 33
7.35
7. 35
7.36
7.36
7.36
7.37
7. 37
7. 37
7.37
7. 37
7. 37
7.37
7.38
7.38
7.38
7. 39
7.39
7.39
7. 39
7.39
7.39
7.40
7.40
7.40
7.40
7. 41
7.41
7.41
7.48
7.48
7.49
7.49
7.52
7.54
7.55
7.56
7.57
7.58
7.58
7.58
7.59
7.59
7.60
The DL/l Buffer Handler Pool
• • • •
The VSA M Buffe r Pool • •
• • • •
The OSA" Buffer Pool • • • _
••••
Defining the IMS/VS Data Base Buffer Subpools.
VSAM Sub pool Definition Statements ••
Guidelines for Selecting Number of Buffers
Per VSA" Sub pool. • • • • • • • • • • • •
OSAK Subpool Definition Statements. • • • •
Guidelines for Selecting Number of Buffers
Sub pool • • • • • • • • •
• •••
Options Statement • • • • • •
I"S/VS System Security Utility
Executing the Security Utility •
Security status Report
Types of System Security.
Command Security • • • •
Transaction and Terminal Security.
lMS/VS catalogued Procedures
ACBGEN Procedure •
••• •
DBDGEN Procedure •
DL1BATCH Procedure
1M S Proced ure. • •
IMSBATCH Procedure
IMSKSG Procedure •
IMSRDR Procedure ••
PSBGEN Procedure •
• •••
SFCURITY Procedure
• • • • • • • • • • ••
MF SF VC Proced ure •
• • • •
MFSUTL Procedure •
• • • •
• • • •
Growing from DB to DB/DC •
• • • •
Installing IMS/VS under OS/VS2-MVS •
• •••
~rhe lnst alla tion Jobs. • • • •
• • • • •
The Sample Jobs. • • • • • • • •
• •••
Executing the Sample Jobs with OS/VS2-MVS. •
Ma.i nte na nce Considera tion s •
• • • •
System Modification Program ~MP) • • • • •
Regression Testing of New 1MS/VS Releases.
• • • • • • • •
• • • • • •
• •••
Per OSAM
....
...
..
....
....
•
• • • •
•
4
CH APTER 8. OPER ATION S • • • • • • •
What's Needed to Operate Online 1MS/VS • • • • • •
The Master Terminal operator function.
The Network Control Function • • • • •
The Application Supervisor Function ••
The User Liaison Function. • • • • • • • • • • •
The Master Terminal Operator • • • • • • • • • • • •
The Master Term~nal Operator's Guide • • • • •
Modifications to the Sample MTO Guide ••
Functional Titles. •
• •••
OS/VS1 Installations.
MVS Installa tions. • •
• •••••••
Subset Limitations • • • • • • • • •
Forms a nd Tables •
• • • •
• • • • • • • •
Restart and Pecovery JCt
••••••••
Log Tape Administration.
• ••
Application Operating Procedures ••
Testing the MTO Guide • • • • • • • • • • • • •
Ma inta ining the MTO Guide. • • • •
Planning for IMS/VS Disk Restart
User Liaison Group • • • • • • • • • • • • • • • • • • •
Remote Terminal Operators • • • • • •
Training Remote Terminal Operators.
The RTO Guide. • • • • • • • • • •
• ••
Modifica ti on s to the Sam ple RT 0 Guide. • • • • • • • •
Functional Titles. • • • • • • • • • • • • •
Use of the Subset. • • • • • • • • • • •
7.60
7.60
7.6'
7.61
7.6'
7.62
7.62
7.63
7.63
7.64
7.64
7.64
7.65
7.65
7.65
7.66
7.67
7.68
7.68
7.71
7.74
7.75
7.76
7.76
7.77
7.77
7.78
7.78
7.78
7.78
7.80
7.80
7.80
7.8'
7.81
8. 1
8. 1
8. 1
8. 1
8.2
8.2
....
....
8.2
8.2
8.3
8.3
8. 3
8.3
8.3
8. 3
8.3
8.4
8.4
8.4
8.'5
B.6
8.6
8.6
B.6
8.7
B.7
...
8.7
B.7
contents
xix
Conversational Processing • • • •
Terminal Operating Procedures. • • • •
Application Operating Procedures.
Problem Reporting Procedures •
Maintaining the RTO Guide • • • • • • • •
VTAM and IMS/VS Operation.
........· ..
...
CHAPTER 9. OPTIMIZATION • • • • •
IMS/VS Batch Performance Monitoring.
The DL/I Buffer Pool Statistics••
The VSAM Buffer Pool statistics • • • • • • • • • •
The OSAM Buffer Pool statistics.
The IMS/VS DB Monitor • • • • •
Using the IMS/VS DB Monitor.
Activation and Control ••
..
DB Monitor Data Recording.
MODIF Y Command Errors. • •
• • • • •
DB Monitor Report Print Program, DFSUTR30 ••
Definition of Terms used in the Reports • • •
How to Exec ute the DB Monitor Report Pr in t Pr ogram
Statistics from the VSAM and OSAM Buffer Pools • • • • • • •
Program I/O Report • • • •
• • • • • •
DL/I Call Summary Report •
• • • •
VSAM Statistics Report. •
• ••••••••••••••
Monitor Overhead Report.
• • •
Data Base Design Optimization.
Data Base Load Factors Per Transaction •
Transaction Load Factor Units.
Example. • • • • • • • • • • • • • • •
Data Base Design Checklist • • • • • • •
Optimization of Physical Implementation.
Optimization of Application Programs • • •
Optimization of the !MS/VS Online System • • • • • •
Online Performance Monitoring • • •
The Online Buffer Pool Statistics • • • • • •
Messa ge Que ue Pool • • • • • • • •
Message Format Pool. • • • • • • •
Adjusting MFS Buffer Pool Specifications • • • •
Oat a Base Buffer Pools • • • • •
DMBP Buffer Pool ••
• ••••
Adjusting the DMBP pool Size.
PSBP Pool. •
• •••
ClOP Buffer Pool
Main Bu ffer Pool
CWAP Buffer Pool • •
PSBW Buffer Pool
DBWP Pool. •
• •
Statistical Analysis Utility •
Jet Considerations
••••••••••••••••
Report Output and Interpretation • • • • •
Messages Queued but Not Sent (by destinatio~ • • • • •
Line and Terminal R aport ••
• • • • • •
Messages Queued but not Sent (by transaction code) • • • • •
Transaction Report • • • • • •
Transaction Response Report.
Application Accounting Report.
The DC Monitor • • • • • • • ••
Using the DC Monitor • • • • • • • • • • • • • •
Starting and Stopping the DC Monitor • • • • • • • • • • • •
DC Monitor Report Print Program DFSUTR20 ••
How to Execute the DC Monitor Report Print Program.
Statistics from Buffer Pools Report • • • • • • • • • • • • • •
·..
....
.....
·. .
....
....
......
..
·..
...
xx
IMS/VS Primer
...
8.1
8.7
8.1
8.8
8.8
8.8
9.1
9. 1
9. 1
9. 2
9.3
9.3
q.~
9. u
9.5
9.5
9.5
9.6
9.7
9.7
9.7
9.8
9.9
9.9
9.10
9. 10
9. 10
9. 11
9. 1 1
9.12
9. 13
9. 13
9.1 U
9. 1U
9. 16
9. 16
9. 17
9. 11
9. 18
9.18
9. 18
9. 19
9.19
9. 19
9.19
9. 19
9. 19
9.20
9. 20
9.20
9.20
9.20
9.20
9.20
9. 21
9.21
9. 21
9.21
9.22
9.22
9.23
Using the VTA~ Storage Pool Trace • • • • •
Operating the !race • • • • • • • • • • •
Optimizing VTAM Storage Peel Parameters • • • •
Storage Pool (SMS) Trac~ Description •
Adjusting the VTAM Storage Pools • • • • • •
tata Communication Design OFtisizaticn •
• •
Net~ork Fesponse Time Factors. • • • • •
IMS/VS Response Time Factcrs • • • • • •
Sample IMS/VS.Response !ime Estimate • • •
...
9.27
9.27
9.27
9.27
9.29
9. 30
9.30
9.30
9. 31
APFENDIX A.
IMS/VS STATUS CeDES QUICK FEFEFENCE •
A. 1
APPENDIX B.
IMS/VS STATUS CODES AND POSSIELE CAUSES •
B.'
............
Contents
I. 1
xxi
Fiqure 1- 1.
-..
··· ····
Application Data Integration
Data
Base Concepts
•
Traditicnal Record Layout
Bier ar chi c a1 Data Structure
• •
• • •
'Ihe Parent/Child Felationship of DL/I
The P.elaticn tetween Segment, Data Base Fecord
and Data Base
..
Segment Types and Their Rela tions in a
flierarchical Data Structure
Two Logically Related Data Bases, PARTS
and ORDER S.
The Logical tata Bases after Relating PARTS
and CRDER tata Bases.
A Data Ease and Its Secondary Index
I~S/VS Eatch processing Fegion Systc;m Flow.
Th€ Project Cycle
II'IS/VS-rB Installat ion Plan FERT Chart.
Sam~le Gantt Chart.
Ilfl s/VS in the SNA Environment
II15/VS Data Ease/Data Communications System
Flow.
I!'JS/Vs-tB/tC Inst allat ion Plan PEnT Chart
· ···
·
·
·
·
·
·
·
'-3.
·· ·· ··•
'-5.
··· ····
···
Figure 1-6.
··· ···
Figure , -7.
· · · · · · · · ..· · · · · ·
Figure '-8.
··· ·· ··
Figure ,- 9.
·
Figure , -'0.
Figure ,- ,,.
··· · · ······ ·· ··
Figure ,- 12.
Figure '-13.
· · · · · ·· · ·· ·· · ·· ·· · · ·
Figure 1-14.
· ·
·
Figure 1-15.
.
· · · · · · · · · · · · · · · · · ·· · · ·
Figure '-16.
Figure 2-'.
Dl/I ta'ta Ease Eecord
· ·Physical
· · · · ·Storage
···
Figure 2-2.
A DL/I tata Ease Fecord in
Figure 2-3.
Segment Format.
· ······
· · · ·in· Hierarchical
Figure 2-U.
Se,]men t Types Numbered
Seguence.
· · ·· ·· · ·· ·· · ·· · ·· · · · ·· ·· ·· ··
·I, _____
legend:
PTF:
PTB:
PCF:
PCl:
Physical
Physical
Physical
Physical
twin forward pointer
twin backward pointer
child first pointer
child last pointer
Note that PTB and PC L are optional.
Figure 2-8.
Di~ect
SEISAM S10BAGE
Address Fointers in EDAM and HIDAM
CEGA~I2ATIC~
The data structure of a SHISA~ data base consists ef only Oile segme~t
tYfe, the root segment, with a unique sequence. field. E€:cause of this,
there is no segment prefix needed. The physical storagE organizaticn is
a single VSA~ KSDS ,Key Seguenced tata Set). This makes it possiblE tc
procEss a non tt/l KSVS as a DL/I data base with full DI/l function.
The main use of the SHlSA~ organization is as a migration teol te D1/1
for existing KSD3 or 151M files. It is net r~commended for new data
bases. (See also the phase 2 sample environeent earlier in this
chapter Q)
!Q!~:
the logical record lengtb of the KSVS must be an even numler for
SHISAM.
Lata Base Design
2.15
FUNCTIONS AND OS! OF GSAH
An as/vs se~uential file can be defined to tL/I as a GSA~ data base.
However, the nermal concEFts of hierarchical structures do not apFly to
GS AM.
When using GSAM for sequential input and output files, DIll will centrol
the physical access and Fcsitien of those files. This is necessary for
th€ repositioning of such files in case cf program restart. When using
GSAM, Dl/1 will, at restart time, reposition the GSAM files in
synchronizaticn with the data base contents and your application
Frogram's workin~ storage. To control this, the application Frogram
should use the restart IXRSt) and checkpcint (CHKF) calls. these calls
will be discussed in Chapter 4, "Data Ease Processing."
Whenever you want your program to be restartable, you should use GSAM
for its sequential input and output files. There are two reasons why
you should want to do this. The first is to save time if a Frogram
rerun is required in case ef pregram or system failure. This is
normally enly done for long-running update programs (one or mere hours).
The other reason stems frem a Flanned online usage of the data bases.
Te be able to run a batch Frogram in parallel with the online system,
using the same data bases, that program must be executed as a batch
message processing ~MF) Frcgram. A BMF runs as a batch jot, but uses
the cnline centrol regicn of IM5/VS fer the access of DI/l data tases.
In that way, IMS/VS will provide complete data integrity acrcss the
batch and cnline use cf the data. to do so, however, the IfS/VS data
base/data communication system will isolate th~ data ~ase updat~s of a
particular program until ~rc9raro termination. By using the checkpoint
call, the batch program can free t~ose uFdated data base segments for
imlediate access b~ other batch and/or online programs.
GSkM supports data sets organized according to the follewing as/vs
access methods:
•
Sequential Access Methos
•
Virtual Storage Access
(~A~)
~ethod
(VSAM)
GSAM supports the Easic Sequential ACCeSS M~thoa (BSAM), on DASD, unit
record t and taFE devices and ESDS en DASD devices. In ou~ subsetr we
will cnly consider ESAf fixed and variable length record forr-ats.
lhe terms segment, segment type, hierarchical, parent, child, atc., are
not applicable to GSA~ data sets, ncr do the concepts of either key or
field apply.
~hen program restart is required, yeu sheuld not use temporary files,
that is, for SISIN/SYSOUT sFooling. !hey may be deleted by CS/VS after
fIcgram or system failure.
A GSAM data base may ~lsc ~e a data set ~reviously craated ty USE cf
OS/VS ESAM, or QSAM. Ccnversely, a GSAM data bas~ may be accessed later
by ether programs using these CS/VS access methods.
~.
16
1MS/VS Frimer
WHY tCGICAL
EELA~IONSHIPS
We have sc far addressed only single hierarchical data structures.
Quite often, Especially with different aF~lications, several Dt/I data
bases are needed. In acditicn, there is often a reguirement to access
the same data in different hierarchical structures and different data
bases:--1hiz-can
create-prctlems-cf:--- ----------
•
Consistency -- if data is stcred more than once,
cccurrences at the same time.
to update all
•
Data Fedundancy -- if large data elements are stored many times,
this way consume excessive External stcrage.
•
Access of Data -- if data is stored more than once, which access
path should be used to access the appropriate cOFY of the data.
ho~
The atove Frctlels car. te sclved by stcring the data only once and
Froviding a linkage mechanism tetween hierarchical structures. With
this linkage a ne~ access path is provided to data in data base A, based
on data in data base B, and, if desired, vice versa.
DL/I's logical relationships provide this function. The basic linkage
is always between t~o segments. However, the linkage can extend to
several data tases. On the ether hand. the resulting compound data
structure ~ill always be presented as a hierarchical structure to a
particular application. !he tasic mechanisn of the DL/l logical
relaticnshir is the connection of a segment to two parents in t~o
different hierarchical structures. Normally, any segment has only one
parent. By giving a segment two parents, that segment (and its
dependents) telong to t~c different hierarchical structures. This
enables the definition of a new hierarchical structure which ccntains
segments froro both related structures. Such a definition is called a
!Qgl~~l ~~1~ !~~~.
BUILDING lOGICAl BEIA1.ICNSHIES
The following segment types are needed tc establish a logical
relaticnshiF- All three must be present for any logical relaticnshiF.
You should refer to Figure 2-9 when reading the following discussion.
PHYSICAL DATA BASES
PHYSICAL"B
PARENT~
ORDER.
t
LOGICAL DATA BASE
G~LOGICAL
~PARENT
PART
ORDER
I
"
~. LOGICAL CHILD
L::J
Figure 2-9.
DETAIL
PART
I·
CONCATENATED
SEGMENT
~--------~--------~
segment Types Invclved in Lcgical Relationships
tata Base Desigl1
2. 17
1£gi~!1
~hi!~_~~g!!D!:
and a ]hl§!£~l ~~~!n~.
this segment has two parents. I iQgi£!! 2~~~n~
1he logical child segment and its dependents. if
any. are accessable via toth parents. !he access path via its physical
parent is called E!!§!~2! ~££§~2 2~t~. The access path via its logical
parent is callEd thE !~~i~!l !£f~!§ ~!~h. Ey definition. a logical
child segment contains the concatenat~d key of the logical parent
fellc~ed cy user data. if any.
!he remainder of the user data in the
logical child is called !B!~~§§£!i2n g!!~. It is present at the
intersection of the t~c ~arEnts. The l£g!£~! ~~f~n! £Q~£~!~~~!§2 !~I
{LPCK) is always presented together with the intersection data. whenever
the lcgical child is accessed via its physical path (see Figure 2-10).
r- -
-
1
I
-
,
PREPIX
L- -
-
-
-
-
-
- --------------------------------------------------,
I
I
I
I
-
Figure 2-10.
LPCR
I
INtERSEctION DATA
,
"
I
I
,
1<---------TC/IROM USER'S I/C AREA--------------->I
logical Child Segment Format
Whenever you insert a logical child segment in its physical data case.
yeu must present the IFeR. It identifies the logical parent.
This Eegm€nt mal reside in the same cr a
different data base as the lcgical child.
12g!£~!_i~~§n~_§!9!i~!:
fhI§i£gl_is!!~!_~!9!!D!:
This is the nCImal ~arent segment of the
1cgical child in its physical data base as defined earlier.
1he most common method for implementing logical relationsips retween
BCAM and EItA~ data tases is based on direct address pointers. which are
all 4-byte relative byte address pointers similar to other ~cintErs in
EDAM and BIDAK.
Ih!_!i'!~~1_L2gi£~!_£hi!A_~~g!§ni_j!~~1:
To be able to define thE view
of the logical parent on its logical children and their occurrence
sequencing, DI/! introduces a special segment tyP€. It is ram Ed the
!i~!~2! 12gis~! f~i!~ and is defined as a dependent of the logical
parent segment. It does not exist in physical storage itself. Its only
role is tc provide a m~chanism to define the 1cgical parent's viE~ cf
the data in the 109ical child. It controls the access from the logical
parent to the logical child. It is used to define the sequ€ncing of the
logical child SEgment ~hEn that logical child segment is accessed via
its lcgical parent. Th@ virtual logical child is said tc te £~i!~~ with
the real logical child. See Figure 2-11.
2.18
IMS/VS Frimer
LOGICAL DATA BASES
PHYSICAL DATA BASES
LP
LCF
r-
I
DETAIL
PART
ORDER
PART
ORDER
~an d /or~
I
L
-,
I
DETAIL
L __ --1 ~
/
/
REAL LOGICAL CHILD VIRTUAL LOGICAL CHILD
DETAIL
I
I
DETAIL
PART
I
ORDER
I
~
CONCATENATED SEGMENTS
(Represents DETAIL when
accessed from PA RT)
Key:
PP-Physical parent pointer
LP- Logical parent pointer
LCF-Logical c~ild first pointer
Figure 2-11.
Virtual Paired Bidirectional logical Relationship
When accessed, the virtual lcgical child cODtains the concatenated key
of the physical ~arent of the real logical child, plus the intersection
data of the real, lcgical child. So the virtual logical child tETAIl'
in Figure 2-11 contains the key of the OFDEE segment plus the user data
of the real DETAIl segle~t.
The Destination Ig~~n!: With bidirectional pairing, DL/I refers to the
parent-which-Is ether than the ene used to access the logical child as
the destination ]!I§D!. As a censeguence, the logical child always
starts-1iith-'the g~§1in~:t!QD 12!~~!!1 £Qn~~I€ng!~~ lit! (DPCI<) .•
The EhY2if~1 ~!!~ ~!§j~ used te i~Flement a logical relationship must be
HDAM o~ HIDAM data bases. Figure 2-12 shows the physical data bases of
our Phase 2 sample environment. The order line segment in the Customer
Crders data basi is the legicnI child of the part s~gment in the Parts
data base. Notice that the virtual logical child is not shcwn, alttough
it will appear in the DBD as discussed later.
CUSTOMER
ORDER
PART
LP
./
I
./
~
/'
/'
PURCHASE
ORDER
STOCK
Figure 2-12.
Th~
.
/'
LC
'/
I
I~
ORDER
LINE
DESCRIPTION
1/
l/
/'
l/
"
I,
/
/'
SHIPMENT
1/
Phase 2 Fhysical Data Eases
tata Base DesigI
2.19
A discussion cn ho~ this structure is derived can be found in the last
part of this chapter. A !Qgi£~!_gg1~_Bg§~ is a redefinition of one or
more physical data tasEs which ccntain lcgical relationships. It yields
a new hierarchical structure which is ceqposed of structures from both
related structures. The new structure can ce processed ty a~plication
programs as if it ~Ere ~hysically present. The logical data base can
only be defined if th~ proper logical relationships are defined in the
phy~ical data tasEs.
Ih!~~D£!l!n!l!g_~!g!~n~:
All segments in the logical data base stem
frcm ene segment in one of the physical data bases. except when the
logical child is accessed. Whenever the logical child is aCCESSEd in a
logical data tasE, it is epticnallI £2D~~!~n!!~~ with the destination
~arent segment.
See Figure 2-13. ~he destination parent is the parent
of the lCEILD ether than the ene frcm which you came.
r----·-----------------------------------------------~-----------,
1
LOGICAL CHILD
1
1-----------------------------1
I
tPCK
I IN'IERSEC'IION ,
,
I
D~TA
I
tESTINAT!ON PARENT
,
,
I
,
\----------------------------------------------------------------~
Figure 2-13.
Concatenated Segment Format
Notice that the concatenated segment is different for the two paths:
•
When accessing th~ real logical child below its physical
concatenated s~gment will ccnsist cf:
1.
2.
•
~arEnt,
the
The real logical child, which consists of:
a.
!he concatenated key of the logical parent
t.
thE data cf the real logical child segment, if any
Optionally. thE logical
~atent
segment itself.
When aCCEssing the virtual logical child below the logical parent of
the real logical child, the concatenated s~gment will ccnsist of:
1.
2.
Mg!~:
!he virtual lcgical child, which consists of:
a.
the concatenat€'"d key of the physical parent
b.
the data of the real logical child segment, if any
Cptionally, the physical parent segment itself.
!he
concatenat~d
segment only exists in a logical data tase.
Because of the bidirectional virtual pairing, you can always define two
logical data bases with one logical r€lationship~
Figure 2-14 shows the twc lcgical data bases which can te defined using
the related p~ysical data bases of Figure 2-12.
2 .. 20
IM~/VS
Erimer
LOGICAL PARTS
DATA BASE
PART
1
J
"
./
I
I
I
./'
"
PURCHASE
STOCK
1,
/
DESCRIPTION
ORDER
./
./
I
~
"
.L
"
ORDER
CUSTOMER
LINE
ORDER
./
./
I,
-"
"
SHIPMENT
./
LOGICAL
CUSTOME R ORDERS
CUSTOMER
DATA BASE
ORDER
1
"
-"
ORDER
LINE
I
"
SHIPMENT
PART
~
I
,
"
STOCK
,.
-"
PURCHASE
Figure 2-14.
"
,/
I
-"
DESCRIPTION
ORDER
./
"
./
./
Phase 2 Logical Data Bases
The atov€ logical data caSES will be used by our sample Fhase 2
applicatien Frograms.
The exact rules for defining and processing logical data bases will be
discussed in the £ollc~if;9 secticn.
LOGICAL RELAtIONSHIP f,ESIGN PULES
In constructing legical relationships with tl/I. two sets of rules lUSt
ce otservEOu One set fer cc~structing the physical data bases and the
second se~ for ccnstructing lcgical data bases. It should be clear that
a lcgical data bas~ can be defin~d only if the underlying physical data
bases are properly defined.
tata Base Design
2.21
If uecessary, multiFle lcgical data bases can be defined for a given set
cf logically related physical data bases. However, good practicE is to
generatE one logical data tase for each ~hysical root segment which
contains only the segmen~s needed in your applications.
,"
A logical child segment must have one and only one physical
sEgment an~ one and cnly one logical parent segment.
2.
A logical child segment is defined as a physical child segment in
the physical da~a tase of its physical parent.
3.
In its physical data baSE, a logical child segment cannot haVE
another logical child as its immediate dependent.
,~
A logical parent segm~nt can be defined at any level of a physical
data tas~ including thE rcct level.
2.
A logical parent segment can have one or multiple logical child
segment types.
3..
A segment in a Fbysical ~ata base cannot be defined as both a
logical parent and 3 l09ical child.
4.
A logical parent segm~nt can be defined in the Same Ot a different
physical data base as its logical child segment.
1.
A physical parent sEgrEnt of a logical child cannot also be a
logical child. This is the same as rule 3 for the logical child.
~arEnt
Multiple lcgical relationships can be established within a single data
base or tetwEen two OI ICIe data bases, as long as the above rules are
obeyed.
~~!!~_~2~_~~'~EiB9_!29i~~!_f!l!_I!!!!
1.
!he logical data base
structure.
2.
It must start ~ith tho. root of a physical data base and can contain
coly Eegments defined in physical data bases.
3q
In following' a hieIaIchical path, no segments may te
4.
The logical child plus the destination parent is always presented as
ene ccn~atenated s~gment.
5.
~he
its~lf
is always a single hierarchical
ski~ped.
dependents of a concatenated segment are:
•
!he dependEnts cf the logical child
•
The lcgical or physical
depen~ents
of the destination parent
!he above dependents should not he int€rmixed, nor should their
relative order te changed. But you can start with either of them.
•
!he physical parents up to the root of the destination parent
in dSEtination parent to root order
6.
If Fhysical parents of a destination parent are included, then you
can alEo include their logical or physical depen~ents in their
normal order.
1.
Any number of logical relationships can be used in a single
hierarchical path in the logical data base up to the maximum of 15
segment levels.
1.
E~caUSE of th~ vi~tual lcgical child CCDcept, paths are
bidirectional and can be ~ntermixed and/or repeated in a single
logical data base.
2.
All segments of related data bases are available as long as you
follow the above rules. The same physical segment type could appear
in several different Faths if needed.
Figure 2-15 shows some examples of logically related physical data bases
and their associated logical data bases. It illustrates most cf the
above rules. This ~xalple is net representative for a typical DIll
application: it merely shows the different possible combinations.
PHYSICAL DATA BASES
DBD1
DBD2
DBD3
POSSIBLE LOGICAL DATA BASES
Figure
~-15.
Using Multiple Logical Relationships
tata Base Design
2.23
PBOCiSSING LOGICALLY RELATED SEGMEN1S
Q£1~!i~_lgg!£~11I_£!!2S~g_~!g~!n~~
7he l 0 9 ica l child can h~ deleted via its physical parent
Fath or its logical parent path. If ~ logical child is deleted in
either way, trren all its dependents in the physical data basE arE
deleted. If a ccncatEnatEd se9ment is deleted in a logical data tase,
then cnly the logical child segment is deleted with its physical
children. The destination pa~~nt is not deleted. In our suts~t, the
logical child will be automatically deleted if eith~r its physical cr
logical parent is deleted.
~2siS31_~]11~:
~~g!£~!_f~I!n~:
The logical parent can only be deleted via its physical
parent path. If the logical parent is deleted then all its children
will be deleted including logical children.
ih!§!s~!_i~~!~~:
The physical Farent can cnly be deleted via its
physical Farent patt. If the physical FaLent is deleted, then all its
children are dEleted including logical children.
1Q£i£~lL£hI!lS~1_fg~~D!:
its physical
EithEt patent type can only be inserted via
path.
~arent
~~gi£~l_~hil~:
The logical child can be inserted via either path, but
the destination patent must already exist.
Ef.E1.!£1:Dg_1:2g:i£~!!Y_11~!~~~g_.§~g!!~nt§.
After a get hold call of the ccncatena~ed segment, fields in toth the
lcgical child and the destination parent can be changed before the
replace call, except sEguenca fields, see Figure 2-16.
DESTINATION PARENT
LOGICAL CHILD
DE~~~:~~ON
SEQUENCE
CON CATENATED
KEY
IELD
F
THESE FIELDS CANNOT
BE CHANGED BY REPLACE
Figure 2-16.
REMAINING
IINTERSECTION
DATA
THESE FIELDS
MAY OVERLAP
PARENT'S
KEY
REMAINING
PARENT'S
THESE FIELDS CAN
BE CHANGED BY REPLACE
Replacing Fields in a Concatenated Segment
LOGICAL R EL ATION SHIP S I
~PtEME
NIJ:A IJ:ION 'tECH NI QUE
!he following pointers are used by DL/I, in our subset, to ig~lement
logical relationshifs. These fointers are maintained in the segment
prefix in the same vay as the previously discussed physical child and
physical twin Fointers. Again, a detailed comprebension of those
pointers is net required at the moment, as we will give detail~d
guidelines for their selection in the implementation part of this
chapter.
2.24
IMS/VS
~rimer
g£i]!~I§_2§~g_I2!_bQ9!~!1_R~!~~!QB~biE§ !B_H~!~LH!~A~
~2gi~Al_fsI~D~_g~1~1!!_j~fl:
~be lcgical parent pointer is within the
prefix cf the logical child segment and pOints to the logical parent
occurrence of that logical child. This ~ointer is always present and is
never ZEro. Each logical chilo ~~st have one and only one logical
parent just as it has only one physical parent.
~~gi£2!_fhi!2_!!~~~_fQ!B!§!_J!~!1:
The logical child first pointer is
withir. the prefix of the logical parent and points to the first
occurrence of its logical child segment. If a segment has several
logical segment types, it contains one LCF pointer for each seglent
type. If a logical parent ~as no lcgical child occurrences. the
corresponding LCF pointer is zero. The logical child first pointer is
reguired.
~291£gJ_~bilg_~~§!_fQiD!~~_j1~~l:
~he logical child last pointer is
within the prefix of the logical parent and points to the last
occurr~nce of its logical childq
There is one LeL for each defined
logical child segment type. 7he teL pointer is optional. Its only use
is to im~rove the performance of the logical child insert if nc sequence
field is defined for the lcgical chain. See "Role of the Virtual
Logical Child" eaIlier in this chapter.
LQgif~l_l~~~_!Q~~~!~_gfi£!§!_j!!!l:
The lcgical t~in forward pcinter is
within the prefix of the lc~ical child segment and links all lcgical
child occurrences of a particular logical parent. This pointer is
Iequir~d if any logical parent occurrenCE bas more than one logical
child occurrence.
Logi£~l_l~iD_~g£t~~xg_fQin!~~_j~l~l:
~he loqical twin backward pointer
links lcgical t~ins but in the reverse order of the lTF. This pointer
serves a complementary performance role as the physical twin backward
pointer in deleting logical children. It shculd always be used
together with the LCL -- if there are multiple occurrences of a logical
child for any logical ~arent cccurrence.
ghl§i£~l_E~I~D!_£f~n!~I_jfRl:
DL/I uses a physical parent pointer in
the ~refix of the logical child to locate that physical parent if the
acces, was via the logical parent. This PP pointer is repeated up
through the hierarchy tc the rcct. A physical parent pointer is also
Fresent in the lcgical parent if this is not a root segment. It then
points to the physical farent of the logical parent, etc. You never
need tc specify the inclusion of this pOinter ill the DED. Dl/1 will
include it automatically if needed.
The ~eccDdary indexing capability of DL/l allows additional aCCESS Faths
to a data tasE rEcord. SEccndaIY indexes Frcvide:
•
•
A §~£~D£~!l ~I2£~§§!Bg §~gY!Q~§, enabling direct and/or sequential
Frocessing of data base records on non-root-key field values. The~e
search fields can be located in the root segment or a dependent
SEgment.
Autcmatic updating of the secondary index is always done, even if
the frog ram causing the change is not sensitive to the seccndary
index.
tat a Base Design
2.25
WHEN TC USE
SECCacA~Y
lNtEXES
Seccndary indexes should be mainly used when frequent, direct access to
thE data base record is required en non-reot-key fields. It should be
realiz~d that a secondary index incurs additional system cost in CPU and
l/C timeo
If the infoLmaticn cn which the secondary index is
established is cbanged, then Dt/I has to change the index entry.
Especially for batch processing, you should compar~ the costs of full or
partial data base scan plus a subsequent sort of the cut put VErsus the
cost of using seccndary irdexes. For cnline data base processing, the
chcice is easier. Terminal user's response requirements norrally dc not
allow for full data tasE scans.
SEGMENT TYPES INVOLVED IN SECONDARY INDEXES
!he segment types and associated terms involved in secondary indexes are
(see Figure 2-17):
•
Secondary Index
A secondary index is cor.prised of an index ~ointer segment type
defined in a seco~dary index data base that provides an alternate
entry intc a data ta$e.
•
Index Pointer Segment
A segment d€fined in a secondary index data base that ccntains the
data and pcinters us~d to index the "index target segment." It
controls the secondary processing sequence.
•
Index !arget Segment
!hE segment that is Feinted to by an index pointer segment. In cur
subset, it will always te a root segment. In that case, it is as if
the search field "replaces" the original root segment sequence
field.
•
Index Source Segment !ype
A segment that is
created.
•
th~
Seccndary Processing
sourc~
from which a secondary index is
Seguenc~
lhe sequential order in which occurrences of an index target segment
type are access~d tbrcugh a seccndary index. It is the order of the
index Fointer segment.
2.26
IMS/VS rrimer
SECONDARY
PHYSICAL OR LOGICAL DATA BASE
A root
segment in
our
subset
INDEX DATA BASE
INDEX TARGET
SEGMENT
Can lJe the
same segment
as index
target segment,
or as shown,
a dependent
of the index
target segment.
The content of the specified
search field in each index
source segment is dl,.lplicated
in the respective index pointer
segment generated from each
index source segment.
INDEX SOURCE
SEGMENT
Figure 2-17.
segment 1ypes Asscciated with a Secondary Index
Although a sEconcary index can bE used in Frcgrams which use only
logical data bases, their implemEntation is strictly on the physical
data basE level. FigurE ~-1e sbo~s the physical data bases of our phase
3 samFle environment. The only difference from phase 2 is the PurchasE
Crder Numter sEccndary index data base. By utilizing this secondary
indEx data b~se, an application program can process the physical and/or
logical Farts data baSE directly ty purchase order numter.
PURCHASE
ORDER
NUMBER
~
I
..
CUSTOMER
ORDER
PART
po
LP
"""- "~
L"
~LC,,,,
"
"-
PURCHASE
ORDER
STOCK
~
ligure 2-18.
./
",./
PhaSE
~
ORDER
LINE
DESCRIPTION
./
./
I,
",
L
1
",
SHIPMENT
l.....-
./
Physical Data Bases
DES1GN RULES FOR SECONDARY INDEXING
Several rules should be
obse~ved
when designing hasic secondary indexes:
1.
!he index target segment should be a root segment in our sutset.
2.
The index source segment and the index target segment must te
defined in thE samE physical DBD. They can be the same segment.
Data Ease Design
2.27
3.
A logical child segment cannot be used as an index source sEgment.
HOWEVEr, a dependent cf a lcgical child can be used as an index
source segment.
~o
A s€condary indEx can bE used with a logical DBD, but the index
sEgment should be the root segment. Nothing additional need
be specified in the logical DBD.
targ~t
T!CHNICUI
r~PLEMENtAIICN
In discussing seccndary indexes ~e have to distinguish between two
different data baSE types. 7he first is th~ !nq~!~q g~1s ~g§s. Th~s
data base contains the index source and index target segment~. It 1s ar.
EDAM or EIDAK data tase. The second is the ~~~SB~!fl !ng~! g~!! ~!§~,
This data base contains the ing~! R2i~l~! §~gm~n~§ which contain
Fcinters in their p~efix to the index target segments. An I~DEX data
base ~onsists of a single KSDS. Figure ~-19 shows the physical format
of the KStS logical record feL the INDEX data base.
....
SEGMENT = VSAM logical record
.~...
,......
----PREFIX
-~·I
DATA=KSDSKEY~
Direct
address
index
Delete
flag
target
Search
Subsequence
field
field
segment
(Optional)
pointer
4
1
Figure 2-19.
4
N
Logical Reccrd Fermat for the Index Pointer Segment
ln~~~_f~i~tj~_~§g~~n!_I~!!!l
ThE index pointEr SEgment cCDtains:
•
Delete flag
segme nt.
•
Point€r to the indEX taIget segment
•
Search field IN bytes) ccntains a duplication of one to five index
(1
byte) controls the delete status of the index pointer
(ij
bytes).
scutce segment fields which together define the secondary sequence.
•
2.28
Subsequence field lij bytes), optional. It is required in our subset
if the SEarch fields ir. the index pcinter segments are non·uni~ue.
If specified, it contains th€ relative byte address of the index
source SEgment. It is never used to access the index source
segment. Its sole use is to provide a unique key for the KSDS
logical record. In the- DBDs, its field name must start with the
three characters.
IMS/VS Primer
CFFATING A SECONIARY INDEX
Secondary indexes are created with the standard DL/I data base
recrganization utilities, see Chapter 5. They can be created at initial
data base load time or later. Nc user programming is needed to creatp. a
secondary index. Also existing programs neEd not .be changEd unless they
want to use the seccndary indEx.
rATA EAS!
GENERA1ICN
tESCBIP~ION
you finish the des~gn of your data bases you must specify them tc
DL/I. ~his sectien gives the guidelines for the use of the DL/I data
basE definition languagE: thE data base descripticn generation (DBDGEN).
Agair. this section is divided into three subjects in concurrence with
the thlce phases:
Af~Er
~hysical
1.
Easic DBDGEN for
data bases
2.
[EDGEN for logical
3.
DBDGEN fOI secondary indexes
relaticnsbi~s
For each data base to be used with DL/I, a data base descrip~ion (DBD)
must te generated. A IBD ccrsists of a set of DL/I-supplied macro
instructions, coded by you to specify th~ data base characteristics you
need. The DED is procEssed by an OS/VS assembler and the generated load
~odule is ~tored by the linkage editor in the I!SVS.DBDLIB litrary for
subsEquent processing cf the data base. See Figure 2-20.
IMSVS.MACLIB
IMSVS.DBDLIB
MACROS
~I
DBDGEN
~I> EJ
,.....---.---.,~
INPUT
DECK
Fi9ure 2-20.
Cata BaSE
DEscri~tion
Generation
(DBDGEN)
Figure 2-21 shows the sequence cf tbe ~acrc statements in the DBD input
deck. The DEtGEN is EXEcuted by invoking a JCl cataloged procedure
na~ed DBDGEN, which is available in IMSVS.EF~CLIE.
Data
~ase
Desiqn
2.29
Assembler
END Macro
DBDGEN
Required: 1
•
••
Repeat for each segment
type in the data base.
The order is the heirarchical sequence.
Maximum: 255
Required for index
and/or logical relationships.
~epeated
Required:
for each defined
field for this segment.
Maximum: 255 per segment type.
lOOO per data base.
Required: 1
Figure 2-21.
tBDGEN
In~ut
Deck Structure
tEtGEN CODING CONVENTIONS
DBDGEN statem~nts are Assembler language macro instructions and
therefore, are subject to the rules contained in the publication
~~L!~~]Q~L!~:!~L~l~
!§§s!fl§;
1~~3~~~~, GC33-4010.
In the generalized format shown in the following description~ of the
control state~ents. thesE syntax ccnventicns apply:
a.
Words ~ritten in all capital letters must appear exactly as
wri t tflno
b.
iords written ir. lcwercase letters are to be replaced by a
user-specified value. Valid user-specified values are numeric
values or one- to eight-character alphameric names.
c.
7be centrel card~ are free form. O~eration codes must tegin
after coluln CD~. Operands must fellc~ an operation code or
Frior operand. The first operand must be separated from the
operation code by at least one blank column. Each operand
should be separated from the previous operand by a ccmma.
Operands may te centinued on subsequent cards, but must start
in card column sixteen on th~ continuation card. A nonblank
character must he ceded in column 72 if a continuation card
follo~s.
r
,
I.
..
, I
I I
{ }
( )
{ }
,...
2.30
indicates cFticnal 0Ferands. The operand enclcsed in
the trackets (fer exam~le, [V1)) mayor may not be
present, depending on whether or not the asscciat€d
cpticn is desired. If more than one item is enclosed
in brackets one or none may be coded.
indicates that a choice of an op~rand parameter must
be mad~. OnE cf the operand parameters from the
vertical stack within braCES must be coded.
indicatES that IoOIe than one set of parameters may be
designated in the same operand.
IHS/VS Erimer
1!!!J:.l~:
,<-
,
I
I
/
1<-
Column 1
- Column 16
O~Erands
1<- Cperation - Column 4
1
Column 72 ->1
/---------------_._------------------------------------------~
1
IDEt
I
i
EASle tEtGEN
I
INAME=BE1PABTS,
IAeCESS=HItAM
I
51A!EMEN7S
~ON1ROL
•
I
I
I
I
FOR~A7S
This statement naSES tbe data base being described and specifies the
organization used. There is only one in the input to DBDGEN. The
format of thE DBt Eacrc instruction is:
/------ ------------------------------------_
.. _---------------,
I
,
,
:
I!
,
'HIVA~
I
I
I
,
,
I
,
I[ ,R"NAI1E= (lIod,anch,rbn.bytes) ]
I
I { , PAS SliD lE S} ]
II
'l~
I
I
/
tEE
INAME=dtnamE1
I
SHI SA r!
I
IHVAr:
:,ACCESS=
r, CS AM]))
L!~!~
INDEX
={
,
L----------------------------------------------------------------~
tat
identifies this statement as the DED control statement
NAME=dl:namE1
dtname1 is the namE of the DBD for this data base. This name can be
frem cne to eight alphameric characters. lhe first one should be an
alphabetic character. It should be unique for each DBD in your
installation's DL/l Et¥ircnIEnt.
ACCESS=
sFecifies the tl/I access method and the operating system access
mEthod to bE used fer this data base. the value of the operand has
the following meanings.
SH!SA~
specifiES a SEISAI1 data base with only a root segment with no
Frefix. It is a single VSAM KSDS.
Data Base Design
2.31
HtAK
specifies a HtA! data base. OSAM or VS!" can be sElEcted as
the eperating system access method. VSA! is thE dEfault.
HItA!
specifies the HIDA! main data base. VSAM ESDS is used as the
cpErating system access method in our subset.
INtII
specifies the INtEl data base of a HIDA!! data base. iSAM KSDS
is uSEd as the c~erating system access method in our sutsetq
li2i.§:
•
Guidelines for selEcting the best access methods for a
particular data base are pr~vided under the topic "Selecting
tata Base Organizatien and as/vs Access Methods" later in this
chapter ..
•
When iSAK is used, guidelines for the VSAM Access Method
Serviqes DEFINE command is produced in the DBDGEN output
listing. These guidelines should be taken into account when
defining the VSAM data set cluster.
FMNAKE=(mod,anch,rtn,tytES)
should bE specified cnly if ACCESS=(HDAM, ••• )
DIed
specifiES thE lcad lodule name ef the randomizing mcdule to be
u£ed for this data basE. For mere details on randomizing
modules see "HtA~ Iiandomizing Modules" in Chapt€r 7.
anch
specifies the number of root anchor points desired in each
control interval or block in the root addressatle area et an
EDAM dat~ case. The default value of this parameter is one.
"anch" must be an unsigned decimal integer and must not exceed
255.
~hen a user randomizing routine produces an anchor feint r.umber
in EXCESS ef thE r.umber specified for this parameter, the
anchor point used is the highest numb6t' in the contrel interv~l
or block. When a randemizing routine ftoduces an anchor point
number of 2ero, tIll uses anchor point one in the central
interval eI cleck.
rbn
specifiES the laximum relative block number value that the user
~ishes to allcv a randomizing medule to produce for this data
base. !his yalue determines the number of control intervals or
blocks in the rcet ad~ressable area of an HtA~ data base.
"rhn" must be an unsigned decimal integer whose value dces not
exceed 224 -1. If the randomizing module p-I.oduces an rbn
greater than this parameter, the highest control interval or
block in the reet addressable area is used by DL/I. If the
randomizing module produces a block number of zero, control
interval or bleck cne is used by DL/I.
2.32
IMS/VS Primer
bytes
specifies the maximum number of bytes of a data base record
that car, be sto~Ed inte the root addressable area in a series
of inserts unbroken by a call to another data case reco~d. If
this paramEte~ is cr.itted, no limit is Flaced On the maximum
number of bytes of a data base record that can be inserted into
this data basE's roct segment addressable are~. "bytes" must
be an unsigned decimal integer whose valUE dOES not ExceEd
224-1.
PASSW 1=Y IS
causes DIll (Fen to use th~ ~AME=operand for this DED as thE VSA~
password when opening any data set for this data base. This
paramEter is only valid fc~ DEDs that use VSAM as the Cperating
System access methed. ThE default is NO~
WhEn thE user dEfinEs the VSA~ data set(s) for this data base using thE
tEFINE statement of CS/VS Access MEthod Services, the control level
(CON!RCLPW) or master level (MASTEFPW) password must be the same as the
NAMI for this tED. All data SEts associated with this DBD must use the
same Fass~ord. For a description of the USE and format of Fasswcrds for
VSAM, SEe Q~L!~ Aff~~§ ~§l~~~ §!I!i£~~·
For the
n~s/vs
DB/DC (cnline) system, all VSAM CFENs will bypass
checking and thus avoid operator password promFting. For
the lMS/VS DE lbatch) system, VSAM password checking is performed.
In the batch environment, operator passworc prompting will occur if
PASS~D=NC is specified and the data set is passvord·~rotectEd with
passwords not egual tc DBDNAME.
Fass~ord
The intended use of this facility is to allow you to prevent
accidental access of IlS/VS data bases ty non-lMS/~S programs.
£!l!E~~_E!~!!m~B!:
Thjs statement provides the link with the OS/VS data set and defines
additional physical data set attributes. !here is one for each DED.
The fermat of the DA~ASET macro instruction is:
/
,
1
I
1
,I
1
,
I
,,I
,
I
1
,
I
/-_._----.----------------------------------------------_._---,
I
,
tDATASE!
IDt1=ddn~me1
I
t
~314
,
2305
"tEVICF=
~31S
,
3330
,
334C
,
3350
t
I,.I
HODEL= {
~}
,,
I
I,SIZE=size
I
f
, [ • F Ii SF (= (f b f f , f s Pf)
,
I
L----------------------------------------------------------------~
Data Base Design
2.33
DA 'lA SE 'I
identifies this statement as the DATASET control statement.
tC1=ddname1
identifies the ddname used in the JCL to execute DL/I application
programs ,sing the data base. It should be unique throughout the
tL/I Environ.ent ef your installatien.
DEVICE=
specifies the device type used for
storag~
of this data set.
MODEL=
specifies the model ef the above device type.
cembinaticns arE:
For 2305:
For 3330:
The valid
or 2 (2 is the default)
,
cr l' (1 is the default)
SIZE=
specifies control interval size for VSA~ data sets or blccksize for
OSAM data sets. Fcr VSA! data sets the size must be:
1.
A multiple of 512 bytes
2.
If largEr than E192, a multiple of 2048
3.
Not larger than 3Ci2C
Fer C5AM data sets the sizE must be an even number, not Exceeding
32K bytes, and lust nct EXCEed the maximum non-keyed blocksize per
track ef the direct access storage dEvice used.
1.
2~
3.
2.34
As part of the Cl/blocksize you specify, DL/I and VSAM allocate
spaCE for syster fields. 'lhese are:
•
•
Free space anchor point
Anchor points (HEAM only)
•
VSAM control fields (ESDS)
'lhere is a
spaCE of e
Guidelines
paramEters
IMS/VS Erimer
4 bytes
4 bytes for each anchor
point
7 bytes
ftEe space element of eight bytes for each free
bytes cr mere.
for selecting CI/blocksize , the bytes, anch and rbn
atE ~rcvided later in this chapter.
FRSPC=(fbff,f~pf)
specifies how free space is to be distributed in an HDA~ or BIDAM
data base. !be fbff is the free ~lock frequency factor, and it
sp~cifiEs that every nth centrol interval or block in this data set
will be left as free space during data base load or reorganizatien
(wherE ftff=n). 7he ra~9E of fbff includes all integer values from
o to 100 excluding fbff=1. 7he fspf is the free space percentagE
factorQ It ~pecifies the minimum percentage of each contrel
interval er tlcck that is tc be left as f~ee space in this data set.
!he range of fspf is from C to 99. !he default valu€ for ftff and
fspf is o.
1.
1f thE total of tbE pErCEntagE cf free space specified and any
segment si2e exce&d the control interval or block size, a warning
message is iSSUEd by tBDGEN that flags oversized segments. When
loading oversized segments, the "fspf" specification is iqnoIEd a.nd
one control interval eI kleck is used te load each oversized
seg ment ..
2.
In gEneral, it is net advantagEOUS to USE the FRSPC=parametEI for
ECA~. In most caSES, yeu can betteI centrol the free space in HCAM
wi th the si ze of --the root addressable area (r tn in thE
EMNAME=parameter of thE DBD statement). This will be addressed
la te.r in thi s chapt€c under the- topic II resign the Physical Data
StructurES."
This statement is USEd cnCE for each segment to be defined in the DED.
Its basic format is:
,,I
,I
/----------------------------.--------------------------------,
I
I
,
I
,
I
I SEG r.
I
,
I
I
I
,
I
, NUH=segnaDlp. 1
I( ,PAREN!=i (sEgname2 ['.§!~~J»)
I
tBlE
, , E lTES= bytes
]
: , F'I R= {~ E}
,
I
};T
L-~~-~-~~-~--·-----~-~~-~-~--~~--~------~-~·------------~--------~
SEGM
ider.tifies this statement as a SEGM contrni statement
NA f1E:zsegnaUle 1
specifiEs the namE ef thE sE9mEnt as used by DL/I and the
a~plication Frogral.
It is ene to eight alphameric characters and
each segment name should be unique in the tL/I environment of your
installation.
Iata Base Design
(2.35
PARER!=
specifies the name of the physical parent of this segment. This
keyword should tE emitted for the roct segment. The second
parameter controls the physical child pointer(s) in th@ Fhysical
parent of this segment.
SNGL specifies enly a physical child first pointer is used in this
segments parent.
DELE specifies koth a physical child first and physical child last
pointEr are used in this segment's parent.
Reccmmendation:
DBL! shoula be specified if:
1Q
Average twin chain is more than 3 to 5 and
rEtriEVE lasts, and/or
~.
segment has no sequenCE field and frequent inserts are
expected.
fre~uEnt
EY!ES=
specifiES the lEngth cf the data portion of th~ segment in bytes.
~his length does not include the prefix, which is estatlished sclely
by eL/I. This length cannot exceed the maximum logical record
length or centrol interval/blcck size of the data set minus the
space occupied by system fields. SEe the SIZE parameter of tb~
DATASET statement. It should be an even Dumber.
PTB=
controls the physical twin pointer options.
Specify:
PtB=Nt (no twin pointer) if never more than one occurrence of this
segment under its FarEnt.
No sequence field may be defined for
the segment if P~R=NT is specified.
PtR=tE (twin forward and backward pointers) if:
•
No sequence field is defined and frequent inserts are
expected.
•
Retrieve last plus subsequent delete is frequently used.
•
The segment is a logical child.
•
It is the root segment of a HIDAM data base.
P!R=T (only twin ferward
2.36
IftS/VS Primer
~cinter)
See phasE 2.
in all ether cases.
This statement is used once for each field to te defined in thE DBD.
The FIELt statements fcllr.w the SEGM statement of the segment in which
these fields belong. This statement is required for all sequence fields
and fields which are tc be used in SSAs. lhe basic format is:
I
/-------------------------------------------------------------,
,
I
I
I
I
,
I
,
I
I
IFIELD
,
I
I
I,EY!E5=bytes
~
:::::::={;t}artPos
!
,
I
,
I
I
I
£
,
lNA"E=(fldr.amel["S~EEQJ)
I
L----------------------------------------------------------------~
FIFlt
identifies this statement as a FIELD control statement.
NAME=
fldname1
specifies the name cf thE field being defined within a segment
type. 1he name specified can be referred to by an application
program in a tL/I call SSA. Duplicate field names must not be
defined for the same segment type. fldname1 must be a one to
Eight character alphameric value.
SEQ
the presence of the keyword SEQ as a parameter of this cperand
identifiEs this field as a sequence field in the segment tyP€.
FIELD statements ccntaining the keyword SEQ must be the first
FIELD statements following a SEGM statement in a DBD generation
input dECk. As a general rule, a segment can have only one
sequence field. If a sequence field is specified, then its
value must te uniqUE in cur subset for all segment occurrences
under a given parent.
A uniqUE sequence fiEld is optional for all dependent SEgment
types. It lust te frcvided for the root segment of SHISA~,
HIDAM, and primary HItAM INDEX data bases.
When no sequencE fiEld is defined fo~ a segment, new occurrences of
th~ S€9m€nt ~ill be inserted at the end cf the physical twin chain.
It is re~uired, in our subset, that all parent segme~ts which
participate in I09ical Ielaticnships have unique sequence fields
(except if P!E=N1 is specified). This includEs the physical and the
logical Farent and their FaIent segments up to their roots.
EYTES=
specifies th~ length of the field being defined in tytes.
maximum allowed is 255.
The
Data Base Design
2.37
S'IAR'I=
specifies the starting ~csition of the field being defi~ed in terms
of bytes relative to the beginning of the segment. !axi.um allowed
value is 3C1~C. startpcs for the first byte of a segment is one.
Overla~ping fields are permitted.
!YEE=
specifiES the type ef data that is to be contained in this field.
The value of the parameter specified for this operand indicatEs that
cne of the following types of data viII be contained in this ~ield:
x = hExadecimal data
P = packEd deci.al data
C = alphameric data or a combination of types of data.
It should be noted that allOt/I calls perform field
comparisons on a kyte-by-byte binary basis. No check is made
ty Dt/1 to ensurE that the data contained within a field is of
the type specified by this operand, except when thE defined
field is ir.oexEd.
This statement is used cnee for each index or logical relation a segment
haF. It immediately follows the SEGM statement or FIELD statements of
the sEgmEnt involvEd. At this point we will only discuss i~~ use in
defining the primary index of a BIDftM data base. The basic fermat is:
,,
I
I
INA!E= (segname,dtname)
I tCHILD
I
I[ , PT R= I i OX J
I
I
I
I
I( ,I~DEX=fldnamE]
I
I
I
I
I
L----------------------------------------------------------------~
I
,
,
lCfI1D statement is coded both in the INDEX data basE and in the
HIDAM main data base. Pcr the INDEX data base, code:
~he
NAME=(segr.ame,dbname)
segname is the name of the HIDAM root segment and dtnamE is the name
of the HItAM data tasE as ceded in the DBD statement.
INDEI=fldllame
fldname is the name of the sequence field of
For the
BIDA~
~hE
HIDA~
rcot segfent.
main data base, code:
NAME; (segname,ctnamE)
segname is the name cf the cnly segment in the primary INDEX data
base for this data bAse, and dtname is the name of that IND!X data
base.
2.38
IMS/VS
~rim€r
PTR=INDX
must be coded as
data base.
show~.
It
~rovides
for the linkage with the INDEX
Qn!H~~!_~12~!!!!l1l~
This statement must bE included.
control cards to define the DED.
I
It indicates the end of DED generation
The format is:
1-------------------------------------------------------------,
I
,
I
I
I
IDEDGEN'
I
I
I
,
L----------------------------------------------------------------~
This statement m~st be included. It sets a non-zero condition eede for
link-edit if therE arE DBDGEN Etrers. ~he for~t is:
I
,
I
/-------------------------------------------------------------,
I
I
I
,
,F1N ISE
,
,I
I
L----------------------------------------------------------------~
This statEment must tE includEd. It indicates the end of the input
statements to th€ OS/VS assembler.
/
I-------------------~--------------------------------- --------,
,
,END
I
,
I
I
I
I
I
1
I
DBDG'EN must be run as a normal operating system jot after IMS/VS System
definition. System definition causes the DBDGEN procedure to be placed
in the IMSVS.FROClIB library. To process a re~uest for a DBDGEN, the
DFt gEneration centrol carcrs must be created and appended to the
follc~iDg Jel t~hich invokes the DEDGEN prOCEdure):
//DEDGEN JCE r.SGIEVEl= 1
EXEC DEDGEN,"ER=
1/
//C.SYSIN OD
*
DED
DA~
AS ET
SEGM
FIELD
LCEILD
DBD generation
control cards
DEtGEN
FINISH
ENt
1*
tata Base Design
2.39
where keyword operand
~BR=
is the name of the tED to te generated. This name should be tb.
sam~ as tt.E first r.alE SfEcified fc~ the NAME= keyword on the OED
statement. When a data base PCB (see PSBGEN later in this chapter)
~elates to this DED generation, this operand value must tE thE nale
used in the DBDNA~E= cfE~and on the data base PCB statement within a
PSE generation.
Note:
If the defined tft is for the primary INDEX data base of an HIDA~
hase, only one each of the SEGM, FIELD and LCBllD statements is
allowed.
data
Figure 2-22 shows a sample HDAM data baSE which uses OSA~. This is our
sample, E!1PARTS. included in l~SVS.PRIMESRC, Phase 1 PARTS data tase.
Job IISAMF110 in lMSVS.FFI~IJCE can be used for its DEDGEN.
Figure 2-23 shows the HIDAM version of the same PARTS data tase.
As
ca~
be seen, two tEts axe re9uixed, one for the index data base and one for
the main data base.
NotiCE that the HIDAM data cases use cnly VSAM. The tBDs of Figure 2-23
are not provided in IM5V5.PRIME5RC. Hc~ever, they can be easily
established if you were interested in using BltAM for the PARTS data
base.
2.40
IMS/VS Primer
PART
(SE1PART)
I
J'
"
STOCK
(SE1PSTOK)
l,,"
~
J'
PURCHASE
ORDER
(SE1PPUR)
DBD
PRH~E~
..,.,
DESCRIPTION
(SE1PGDSC)
l,,"
./
OF
DES~PIPT!O~
FC~
I,
"
P~~TS
SA~Ii'LE
DATAr~S~
POJECT
FH!'~E
NAME=BEIPARTS,ACCESS=(HDAM,OSAM),
RMNAME=(DFSHDC40,4,80,500)
DATASET DDl=DElPARTS,DEVICE=3330,MODEL=1,SIZE=2048
PARTS- GENERAL INFORMATION (ROOT)
SEGM
FIELD
FIELD
FIELD
FIELD
FIELD
FIELD
FIEL D
FIELD
NAME=SEIPART,BYTES=80,PTR=T
START=Ol,BYTES=OB.TYPE=C,NAME=(FEIPGPNR.SEQ)
START=09,BYTES=13,TYPE=C,NAM~=(FEIFGSNM)
ST'RT=22,BYTES=OS,TYPE=C,NAME=(FEIPGNEW)
START=30,BYTES=OS,TYPE=C,NAME=(rEIPGOLD)
START=38,BYTES=08,TYPE=C,N~ME=(FEl?GEQV)
START=46,BYTES=08,TYPE=C,N~ME=(FEIPGUNT)
START=54,BVTES=08,TYPE=C,N~ME=(FEIPGPRI)
START=62,BYTES=08,TYPE=C,NAME=(FEIPGDIM)
PARTS- STOCK
SEGM
FIELD
FIELD
FI ELD
FIELD
FIELD
INrOR~ATICN
NAME=SEIPSTOK,BYTES=40,PARENT=CCSEIPART,SNGL»,PTR=T
START=Ol.BYTES=12.TYPt=C.NAME=(FEIPSLOC.SEQ)
START=13,BYTES=06,TVPE=C,NAr.E=(FEIPSDAT)
START=19,DYTES=06,TYPE=C,NAME=(FE1PSCNT)
START=2~,3YTES=06,TYPE=C,NAME=(FEIPSISS)
START=31,BVTES=06.TVPE=C,NAME=(FEIPS~EC)
PARTS- PURCHASE ORDER INFORMATION
SEGM
FIELD
FI ELD
FIELD
FIELD
FIEL D
FIELD
NAME=SEIPPUR,BYTES=60,PARENT=«SE!P~RT,SNGL»,PTR=T
START·Ol.BYTES=OB.TYPE=C.NAME=(FEIPPONR,SEQ)
ST~~T=09,BVTES=06,TY?E=C,NAME=(FEIPPODT)
START=15,BVTES=20,TVPE=C,NAME=(FEIPPOSU)
START=35,BVTES=06.TVPE=C,NAME=(FEIPPQOO)
START=41,BYTES=06,TVPE=C,NAME=(FEIPPQRD)
START=47,BYTES=06,TVPE=C,NAME=(FEIPprOT)
PARTS- GENERAL DESCRIPTION
SEGM
FIELD
NAME=SEIPGDSC,BYTES=80,PARENT=CCSEIPART,SNGL»,PTR=NT
ST~RT=Ol,BYTES=50,TVPE=C,NAME=(FEIPGLNM)
DBDGEN
FINISH
EtW
Figure 2-22.
Phase 1 EDA" PARTS DBD,
BE'PA~TS
tata Base Design
HIDAM PARTS DBDs
HDAM MAIN MTA BAIlE
HlDAM PRIMARY INlEX MTA BAIlE
PART
(SE1PAR1l
I PART Nl.M!ER
(SE1P1I'CQ
I
I
./
I
I
./
./
STCX:K
(SE1PS1OK1
./
NAME-BEIPINDX.ACCESS-( INDEX.VSAM)
DA lASET DOl-DE 1 P INDX. DEVICE - 3330. MODE L -1. S I ZE-2048
SEGM
LCH ILD
FIELD
NAME -SE 1 PINDX. BYTES-a
NAME- (SE IPART, BE lPUTS). INDEX- (FE 1 PGPNR)
NAME - (FE 1 INDX. SEQ). BYTES-8. STAAT-l
DBDGEN
FINISH
END
PURCHASE
CRleR
(SE1PP1JR)
./'
l/
./
DBD
NAME .eE lPARTS. AcceSS=HI DAM
DA lASET DOl-DE 1 PARTS. DEV ICE- 3330. MODEL -I. SI ZE -2048
PARTS- GENERAL
SEGM
LeHI LD
FIELD
INFORMAT I ON (ROOT)
NAME -SE 1 PART. BYTE S -80. PTA - TB
NAME'( SE 1 P INDX. BE 1 P INDX) • PTR - INDX
START=O 1. eYTE S=08. TYPE=C • NAME= (FE IPGPNR. SEQ)
Sample DBDs for a HIDAM Data Base
DBDGEN FOR GSAM
contains the following statements:
A GSAM DBD
,
I
I
I
,
,
I
I
,
1
I
,
I
I
IDBD
IDA'IASET
I
I
IDBDGEN
IFINISH
I END
I
1N A~E=dbname ,ACCE Ss=
(G SAM, BSA M)
,DD1=ddname,FECFM=recfm
H ,RECORD=lrecl]
'[ ,SIZE=blksize ]
,,,
,
NAME=dbna me
specifies thE name of this data base.
DD1=ddname
specifies the name of the DD statement used in the JCL when
accessing this data base.
2.42
IM~/VS
Frimer
./
DESCRIPTlC»l
(SE1PaJ61:1
DBDGEN
FINISH
END
Figure 2-23.
I
DESCRIPTION OF PARTS DATABASE
FOR FRIMER SAMPLE FROJECT FHASE 1
DESCRIPTION OF PRIMUY INDEX
INTO THE PARTS HIDAM DATABASE
DBD
./
RECFM=recfm
specifies the format of the records in the dataset. The record
format is specified using the characters defined below:
F
the records are
FB
thE records are of fixed length and are blocked.
v
the lecords are of variable length.
VB
the records are variable length and are blocked.
~f
fixEd length.
RECORD=lrecl
specifies the size of a 1cgical record for a fixed length record and
the maximum lcgical reccrd length fOl a variable length record.
SIZE=blksize
spe~ifies the blocksize of the GSAM dataset for fixed length reccrds
or the maximul tlccksize fCl variable length records.
The record and si2e parameters can also be specified via the Jel. Two
sample GSAM DBDs, BOOI~P01 and eOOOUT01 are included in IftSVS.PRIMESRC.
Their DBtGENs can te eXEcuted ~ith job IISAMP010 in IMSVS.PRIMEJOB.
Furthermore, these DBDs can be used by your own application programs if
the file attributes arE the samE.
IBnGEN FOB LOGICAL RELATIONSHIPS
To sUFPort the logical relationship function, DBDGEN is extended in two
ways:
•
Additional contrel statements and parameters can be specified in the
physical DBD.
•
A different type of DED is created for the definition ot the logical
da~a base.
HcwEver, this is done with an extension of the existing
centrol statementsu
The DBDGEN process itself is unchanged.
~he
following control statements are unchanged:
DBD
fIELD
DBDGEN
PIN1SH
END
Additional restrictions exist for the length of a sequence field
of a segment invclved in a logical relationship. See the section
"Restrictions" for the Data Ease Erefix Fesolution Utility in Chapter 5,
"Data Ease Reorganizaticn/Lcad Processing."
!Q~~:
Data Base Design
2.43
The following statements arE extended:
SEG!!
lCHIlt
lor each dEfined logical child, you need to code two
SEGM statements. Cne within its physical parent's DaD and one within
its lcgical parent's DBD. ~he format under the physical parent tED,
that is, fer the real logical child is:
~~i~!l_~b!lg:
,
I
SEGM
,,
,,
,
I
I
t
I
I NAP.I=segname1
I,PAR'F.N'I=
I
l{segname2, §]~1), (segname3,P,dtnale2»
,
DBLE
, ,Bl1:ES=bytes
,
,
\ ,PTB= (LP
,
,{h} ~ {gBijl
I,B OLES=VVV
I
NAME=segname1
segname1 is the name of the logical child segment.
PABEN'l.::
segname2 is the name cf the physical Farent segment of this logical
child.
SN'GL and tELE have the same meaning as before.
segname3 is the name cf the lcgical Farent of this logical childu P
should ~e specified as shown in our subset, it defines the logical
Fa~en~ concatenated key to he stored with the SEgment in Fhysical
storage. dtname2 is the DBD name of the logical parent"s data base ..
E'Y'IES=bytes
has the same meaning as before. Notice however that the lcgical
child always ccntains the logical parent's concatenat~d key in the
first n kytes, and its length must be included here.
PTE=
2.44
LP
must be specified as shown in our subset. !t provides
fer a Fcinter tc the lcgical parent in the prefix
of the lCHIlt.
'I
the samE ccnsiderations as tefore afply.
TE
it is highly ~eccmmended that you specify TE
if there are, on the average, more than 3 to 5 logical
child occurrences Eer physical parent.
tIT
should te s~ecified if never more than one occurrence
of this segment per parent
!~S/VS
Pr~mer
BULES
L1
if specified, only a logical twin forward pointEr
is used fCl the lcgical twin chain.
LTB
if specified, both a logical twin forward and backward
pointer are used for the logical twin chain.
This should te sel~ctEd whenever there are, on the
average, more than 2 to 3 logical child occurrences
for a logical Farent.
= VVV
should be specified as shown fcr our subset.
The fermat under the lcgical parent, that is, for the virtual logical
child is:
I
I----------------------------------------~------------ --------,
t
I
,
1
,SEGM
J~lME=viltchild
",PARENI=segname2
,
1 ,SOOECE=I{segname3,D,dtname1»
1
1,PT~=PAIRED
1
I
I
,
,
1
I
I
t
1
I
t~9~ng:
NA~E=virtchild
virtchild is the name cf the virtual logical child. RememtEr that
the virtual logical child dces not actually exist. Its only purpose
is to defin~ the logical child as seen from the logical path. It
can be followed by a s~gU€nCE field which controls the sequence of
the logical child segmAnt when accessed via its logical path, that
is, the logical twin chain sE~uence.
PARENT=segname2
segname2 is the name of the logical parent. that is, the physical
parent of the virtual lcgical child.
SOUFCE=«segnam~~,t,d~namE1»
segname3 is the name of the real logical child and dbnamel is the
DBD name of the data base which contains that logical child. D
should bE specifiEd ir. cur sutset, it defines that both key and data
of the segment are accessitle by the PSE.
PTB=PAIRIt
Should be specified as
logical child.
shc~nQ
It defines this segment as a virtual
eng additional paramet@r must ~E s~ecified
in the SEGM statement of both the physical ana the logical parent:
~hl~i£~1_ang_!2gi~gl_f!~~nt:
tata Base DESigr.
2.45
For each logical child segment type w an lCHltD statement must be added
immediately following the SEGM and/or FIELD statement of the lQ~j~~l
parent. Its tasic format is:
,,
,,
,
/
/-------------------------------------------------------------,
,
I
I
I L CF! IL DIN Al! E=(s e g n am e 1 , db na lie)
I
f
]
,
I [,
{.§!Hi!:}
I
,
I
I
,
P'IR =
tElE
I
II
I
I
I
I,PAIR=virtchild
I
,
I
I
L----------------------------------------------------------------~
I
NAME=(sEgnamE1,dtnaIE)
segnamel i~ the segment name of the logical child in the DED whose
name is dbname.
P'IB=
~~~t
DELE
SNGL specifiEs that there viII be only a logical child first point~r
in the prefix of the logical parent. DEL! specifies that both a
logical child first and last pointer will appear in the logical
Farent ..
Recommendations:
Specify SNGL if a sequence fi€ld is defined for the virtual
logical child and command code L (retrieve last) is rarely or
neVEr used to access the logical child.
Specify DELE if nc sequence field is defined for the virtual
logical child and/or command code t is heavily used and there
are, on the average, mor~ than three occurrences of virtual
childrED within a lcgical parent.
PAIR=virtchild
virtchili specifies the name of the virtual logical child which must
te dEfined in the salE DaD (see previous SEGM statement).
Figure 2-24 shews the twc lcgically related physical DEDs of our Fhase 2
~amFle environment.
Only those DBD statements are shown which are
essential to the logical relationship function. Compare these DEDs with
the ones cf Figure 2-22 and 2-23. The ~Ets of Figure 2-24 are also
included in I~SVS.PRI~ESRC. Their DEDGENs can be perfoLmed with jot
//SAMP210 in IM5VS.PRIMEJOE.
2.46
IMS/VS PrimEr
DBD=BE2PARTS
DBD=BE20RDER
CUSTOMER
ORDER
(SE20RDER) "PHYSICAL
PARENT
PART
(SE1PART)
LOGICAL"
PARENT
.....___- ......I~
r,,:-.L - ,.--ORDER LINE
I (SE2PAROR) I
VIRTUAL"
LOGICAL CHILD
L ___
(SE20DETL) . . (REAL)
LOGICAL CHJLD
J
DESCRIPTION OF PAI1TS OAT ABASE
FOR PRIMER SAMPLE PI/OJECT PHASE 2
DBD
NAME=BE2PARTS. ACCESS= (HDAM. VSAM).
RMNAME=(DFSHDC40.4.80.500)
•
DESCRIPTION OF OIlDER DATABASE
FOR PRIMER S"HPLE PPOJECT PHASE 2
060
NA!1E =BE20RDEP.. ACCESS=HIDAM
DA lASET DDI =DE20RDER. DEVICE=3330 .MODEl =1. SIZE:2048
OAT ASET DOl :DE~PARTS. DEVICE=3330. MODEL =1. SIZE=2048
CUSTOMER-ORDER GENERAL INFORMAT ION
PARTS- GENERAL INFORMATION (ROOT)
SEGM
.
"lCHIlD
FI El 0
NAME=SEIPART. BYTES=80. PTR=T. RUlE5=Pl V
SE~OOETL.BE20110ER
NAtIE:!
I.PAIP=SE2PAIIC;> .PTP=OBLE
SHPT=OI.B'fTES=08. TYPE =C .N.\tIE =! FE IPGn:;>. SEQ I
SEGM
lCHIlD
·
NAME=SEZOPOEII,BYTES=t>O .PTP=TB.IIULES=PLV
NAME=! SE20110PX.6E20~O"X) .PTI'1=1I:::IX
FIEl 0
STAP.T=Ol.BYTES=06, TYPE=C .NAME=! FE20GPEF • SEQ I
FI!lD
NAME=SE20DETL. BYTES=30.
PARENT:( (SE20RDER. DBl E l. (SEIPART ,P, 8E2PARTS».
PTR=(TB. L TB.lP) .RUlES=VIiV
STAIH= Oil .6YTES=03, T(P[:C .!lAME=! FEZOOLHP, SEQ I
VIRTUAL lOGICAL CHILD
(CONNECTION FRCM CUS TOMER-ORDER 08)
"SEGM
FIELD
NAME=SE2PAROR. PARENT =SE I PART. PTR=PAIR ED.
SOURCE = ( (SE20DETl • D. BE~ORDER II
STA"T=Ol • E,YTES=06 .N',HE:( FE 200lalR .SEQ I
DEF INES SEQUENCE OF L l.. CH.lIII
.
CUSTOMER-ORDER DETAIL INFORMATION
·•
D8DGEN
FINISH
END
DBDGEN
FINISH
END
Figure 2-2U.
Phase
~
Physical DBDs
A logical tBtw tasEO o~ existi~9 Fhysical DBDsw defines a new view of
logically related data bases. This view is alway& a hierarchical data
structure. Follcwing are the contrel statEments used and their formats:
I
,
I
/----------------------------------------------------- -------~
I
,tED
I
,
I
I NAME=dtdname 1 wACCE 5S=lCGI CAL
f
,
I
L--------------------------------------------------------------__ ~
NA MF=dbd nil me 1
dbdname1 is the na~e of this lcgical DEt.
It must te unique in yeur
i~stallation and the same name as specified in the MER operand of
DBDGEN ..
ACCESS=LOGICAL
defines this tEn as a logical DED
Da ta Base Design
2.41
,
I
/
/-------------------------------------------------------------~
I
IDA'ASET
,
I
fleGICAl
,
I
,
r
l------------------------------------------------------.--------.~
statement must be coded as shown.
~his
!he segments in a logical tED must be coded in hierarchical sequence
following the rules for defining logical data bases as presented earlier
in this chapter.
/ /----------~--------------------------------------------------,
I
,
,
,
fSEG~
INA~!=segname1
,
I
'1(,PARENt=segnams2]
,
,
I
, ,seUEC E= I (segname3, t, d tname 1)
r
,
I
' ( , ls€gna me4,n ,dbna me 2) j)
,
I
,
I
I
NAME=segname1
segname1 is the name ef this segment.
PARENT=segname~
segname2 specifies the name of the parent of this segmsnt. segname2
must be defined previously in this DEt. This parameter should be
omitted fer the rcct segment.
SOURCE= ( (segname 3, D,dbname 1) [ , (segname4, D,dbna me2) ])
!his parameter specifies the source(s) of the defined SEgment.
long form is only applicable to concatenated segments.
The
Non-concatenated sesaents:
segname3 defines the sourc~ segment. !he source segment must
be defined in a physical DeD whose name is dtname1.
Concatenateo
se~ments:
•
segname3 defines the lcgical child as ~efined in the physical
DED. If the preceding parent segment is the physical par~nt,
then the name cf the lcgical child must be coded. ! f the
preceding parent is the logical parent, then the name of the
virtual logical child must be ceded.
•
dbname1 defines the physical DBD in which segname3 is defined.
•
segnameq defines the destination parent.
•
dbname2 defines the
parent.
p~ysical
tEt name of the destinatien
The destination parent (segname4) should be included in the
concatenated segment only if your application has a real need for it.
If it is not specified, tl/I does not DEEd to access the d~stination
parent except for insert and delete calls.
!Q~!:
2.48
IMS/VS Primer
~~~§~~~_I!]!E~_!n4_£!~_§!!~!!!B~§_
!hese should be coded as before.
Note that no lCHIID or flElt statements arE allowed in a logical DBD.
E!~!El!-Qt-tQg~~~!_t~~§
Figure 2-25 !hows the logical tED for our Phase 2 P1BTS data basE,
BE2LFART.
PART
(SE1PART)
I
./
-""
L
I
J
./
PURCHASE
ORDER
(SE1PPUR)
STOCK
(SE1PSTOK)
./
;-
I
./
DESCRIPTION
(SE1PGDSC;
'/
./
1
I
;-
;-
-'
ORDER
CUSTOMER
LINE
ORDER
(SE20RDRS)
I
:/
/:
I
./
SHIPMENT
(SE20SHIP)
./
DATABASE DESCRIPTION OF THE COMBINED
PARTS/ORDER DATABASE (LOGICAL)
DBD
NAME=BE2LPART,ACCESS=LOGICAL
DATASET LOGICAL
SEGM
SEGM
SEGM
SEGM
SEGM
SEGM
NAME=SEIPART,SQURCE=CCSEIPART,D,BE2PARTS»
NAME=SEIPSTOK,SOURCE=«SEIPSTOK,D,BE2PARTS»,
PARENT=SEIPART
NAME=SEIPPUR,SOURCE=(CSEIPPUR,D,BE2PARTS»,
PARENT=SEIPART
NAME=SEIPGDSC,SOURCE=«SEIPGDSC,D,BE2PARTS»,
PARENT=SEIPART
NAME=SE20RDRS,
SOURCE=(CSE2PAROR,D,BE2PARTS),CSE20RDER,D,BE20RDER»,
PARENT=SEIPART
NAME=SE20SHIP,SOURCE=C(SE20SHIP,D,BE20RDER»,
PARENT=SE20RDRS
*
*
*
DBDGEN
FINISH
END
Figure 2-25.
Phase 2 logical tED for the PARTS tata Base
tata Base Design
2.49
Figure 2-26 Ehc~s the logical DBD for Qur Phase 2 CUSTOMER CEtEBS data
base, BE21CFDE.
CUSTOMER
ORDER
(SE2ORDER)
I
~
./
ORDER
PART
LINE
(SE2OtART)
I
-'
./
STOCK
(SE1PSTOK)
/
,
~
PURCHASE
ORDER
(SE1PPUR)
./
I
/'
~
SHIPMENT
(SE2OSHIP)
l/
..-
1
DESCRIPTION
(SE1PGDSC)
~
~
./
DATABASE DESCRIPTION OF THE COMBINED
ORDER/PARTS DATABASE (LOGICAL)
DBD
NAME=BE2LORDR,ACCESS=LOGICAL
DATASET LOGICAL
SEGM
SEGM
SEGM
SEGM
SEGM
SEGM
NAME=SE20RDER,SOURCE=«SE20RDER,D,BE20RDER»
NAME=SE20PART,
SOURCE=«SE20DETL,D,BE20RDER),(SEIPART,D,BE2PARTS»,
PARENT=SE20RDER
NAME=SEIPSTOK,SOURCE=«SEIPSTOK,D,BE2PARTS»,
PARENT=SE20PART
NAME=SEIPPUR,SOURCE=«SEIPPUR,D,BE2PARTS»,
PARENT=SE20PART
NAME=SEIPGDSC,SOURCE=«SEIPGDSC,D,BE2PARTS»,
PARENT=SE20PART
NAME=SE20SHIP,SOURCE=«SE20SHIP,D,BE20RDER»,
PARENT=SE20RDER
*
*
*
*
*
*
DBDGEN
FINISH
END
Figure 2-26.
Phase 2 Logical DBD for the CUSTOMER ORDERS Data Base
The logical tEDs of Figure 2-25 and 2-26 are included in IMSVS.PRIMESRC.
Their DEtGINs can te pErformed with job //SAMP210 in IMSVS.PRI~EJCE.
To support the sEcondary indEX function, the DBDGEN process is extended.
We differentiate between the index target DED and the index pointer DBr.
2.50
IMS/VS Primer
CODI~G
AN INDE1
~ARGI~
rATA EASE
The control statements extended fCI the seccndary index function are:
SIGH
FIElD
LCtllL D
A new ccntIol statement is added:
XDFlD
The following control state.ents ara unchanged:
DBD
tA7ASE'I
SEG~
tED(;EN
F'I NI SH
ENt
LCHILD NAME= , ,,'
•
SEGM
•
•
NAME=".
Figure 2-27.
DBt Stat€ments for Index Target Segment
SEG~
is a star.aard SEGM state lent fer the root segment. It has no
additional FaIameteI for sEcondary indexes. It is recognized as an
index target segment because of the following LCEILt and XDFLD
statements.
I
,
/
/---------------------------~---------------------------------,
I
I
I
'l(HIlt
INA~E=(se9name1,dbnamE),PTR=INIX
I
t
,
,
L--------------~-------------------------------------------------~
LC~ILt
~his
state~ent
pro~ides
the link to the index data tase.
Data Base Design
2.51
NAME=(segname1,dbname)
segname1 is the Da~e cf the index ~cinter s~qment as defined in the
INDEX data tase. dtnam€ is the name of the CEO for the I~DEX data
base.
P!B=INtx
identifies the lCHIID statement as an index type.
!Qj!: There are three types cf lCHIlD statements; one for the primary
index of an HltA" data tase, one for the definition of a logical child
under its logical parent, and one for the definition of the index target
segment. All three ty~es eculd occur below tha root segment of a HIDAM
data base. There could be multiple occurrences of LCHILO statements for
both logical rElaticnshi~s and secondary indexes. The relative ordEr of
the LeHIID statements should be as describ~d abcve.
If mUltifle
secondary indexes are tc te defined for cne segment, the XDFtD statement
must immediately follow its corresponding LCH£L~ statement.
,
I
I
,
,
1
1-------------------------------------------------------------,
I
I
I
IXDFIC
'NA~E=fldname
,
1 ,SEG~E~r=segname
",SRCH=list1
I
IC.SUESEC=/SXname]
I
I
,
,
,
I
I
L~---~-~----~-~-------------~-.-----------~---------~_---~-------J
XDFLD
This statement defines the index source fields, that is, the f~elds
used for the secondary index access. It defines the source data for
the index search field in the INDEX data base.
NAME=fldname
specifies thE name cf the secondary index field. fldname ic a
ncrwal field name which can be used in the SSA for the call which
requEsts seccndary irdex access. It must te unique among all field
names specified f~r the abcve index target segment.
SEGMENT=segname
specifies the index source ~egment for this SEcondary index
rElationsbi~.
seg~aae must be the name of a subseque~tly defined
segment type, which is hierarchically below 'the index tar~et segment
type or it can te the name of the index target segment type itself.
lhe segment name specified must not te a logical child SEgment. If
this operand fs omitted, the index target segment type is assumed to
be the index source segment.
SRCH=list1
specifies which field cr fields cf the index source segment are to
te used as the search field cf a seccndary index. list1 must be a
list of one to five field names defined in the ind~x source sEg~ent
type ty FlfLD statelEnts. I i two or more names ar~ included. th~y
must be separated by commas and enclosed in parenthes~s. The
sequence of names in the list is the s9guenc~ in which the field
values will be ccncatanated in the index pointer segment search
2.52
IMS/VS FrLmer
field. ~he sum of the lEDgths of the participating fields forms the
length of this ItFlt as used in SSAs.
SOB SEQ=! Sltnilme
This parametEr must te ceded if duplicate index pointer segments may
occur. /SXname must te the same as coded in the corre~ponding field
statement of the index source segment.
(See the next secticn,
"Coding the lnd€x Source SEgment.")
I
/
-------------------------------------------,
f
I
J
tFIELD
INAME=/SXname,...
---1-------------------1-------------------,
,
I
/
I
I
I
,
I
,FIELD
,NAME=...
,----~
--------------------------------------------,
I
/
I '
I
I
,tlAr-I=...
1----.1
,
tSIGM
I
Figure 2-2e.
I
I
1
tEt Statements fer Index SCUIce Segment
SEGM
This is a standard SEGM statement with no additional parameters. It
is reccgnized as an index source segment because it is defined in a
preceding IDFID statement under the index target segment. It must
no~ te a logical c~ild.
I
I
I
/------------------------------------------------------------~
I
I
,
IF1~LD
,NAME=/SXname,BYlES=4,START=1
,
I
,
I
L-~~-----~----.~------~----~---~------------------------~-------~~
FIELD
In addition tc the ncrlal FIELD statements for the segment, aCE
extra FIELD statement can te added. Its name must start with /SX.
'Ihi:.::; field is Ieq Ilired whenever duplicatE X nIL ns lRay occ~!:' in thE
data tase.
Althoo9h thE values of BYTES and START are disregarded,
they must be coded. Ncte that the /SXname field is call~d a "system
related field." It provides control information to DL/1 and it is
completely transparEnt tc the application program. Example: In our
purchase order, secondary index, there may well cccur. multiple index
pointer segments with thE same furchase crder number (that is, for
the different farts order~d in one purchase ord~r). Therefcre, this
function is required in that data base, otherwise ~uplicftt~ KSDS
keys ~ould ~ccur.
tata Base Desi9r
2.53
CODING A SECONDARY INDEX DBD
!he following statements are us€d in a secondary index
DBO~
DEt
DA'IASE'I
S!Gf!
LCHltD
FIELD
DBDGEN
fINISH
END
,
IDBD
I
t
I
I
, tiA!I=dtname1
1 ,ACCESS= (INDEXr, DCSCCMP))
J
,
,
~
L--------------------------.-------------------------------------~
NAHE=dbname1
specifies the name cf the seccnda~y index data base.
the name specified ty the f!BR keywcrd of D8DGEN.
It should be
ACCESS=(INDEX[,DCSC~ftPJ)
INDEX identifies this as an index data base.
DOSCOMP is an cptional
parametEr and sbculd be specified if this data base was created with
tOS D1/I.
1
1------------·------------------------------------------------,
,
,
I
I
,
I
lDA!ASET
I
I
IDD1=ddname1,DEV!CE=device,~CDEL=model
, .. SI7!=size
,
,
,
,
l-~----·-.-~-----~-~------~-------------·-~·--------~----.-------~
The values spEcifiEd for thE DD1, DEVICE and MODEL parameters are
exactly the same as discussed under "Easic [BDGEN Control Stat~mEnts
Formats. I'
SIZE=si2e
specifies the control interval size of the KSDS for the INDEX data
base. !his value must ccnf~rm to the rules specified under "Basic
DEDGEN Control Statements Fcrmats." See also Selecting Cllblock
sizes later in this chapter.
,I
'SEG~
I
!
I
I
,
'NA~E=segnamel,EYTES;tytes
~----------------------------------------------------------------~
2.:4
I~S/VS
PrimE~
Only one SEGM statement with its associated LCHILD and FIELD statemEnts
is required for thE s€ccndaty itdex data ba£e.
NAME=segname 1
specifies the name of the segment being defined. Although net used
ty applicaticn ~rogtalS in the subset, it should be unique among the
segment names in your installation.
BY'IES=bytes
specifies the length cf the data pOItion of the index pointer
s~gm€nt. If a /SXname field is defined in the SUESEQ parameter of
the CCIt43SFonding XDFLD statement, then its length (4 bytes) must t:e
included here.
I
I
,
,
I
1----------------------------------------------------- -----~--,
I
ILCHILt
I
I
I
t
'
I
, , ~ T 11= 5 t:G I l
t,INDEX=fldname
I
I
f
'NAME=(Segn~me1,dbname)
NAME=(segname1,dtname)
specifies the segmen~ name of the index target segment and the name
of th~ DBD in which it is defined.
PTR=SNGL
specifiES that a ~-tytE direct byte address Fointer in the prefix of
the index Fointer segment will be used. It will point to the index
targEt SEgmEnt.
INDEX=fldname
specifies the fieldname of the indexed field. This fldname must be
specified as the name cf an XDFlD below the index target SEgment.
,
,
I
I
I
1----------------------------------------------------------.--,
I
I
I
'FIELD
I
,
I
INAME=(fldname1,SEC)
I .E~TES=tytes
t. S'IAR '1= t
,
l----- -.. -_ ....... -_ .. _- --- ...... -- .. _-~-
-~
~~--
----- -- ---
-~-
-- .... -- --- .. ---- -- ..
I
I
I
I
--~
Cnly CDe !lILt statement shculd bE coded for each SEGM statement.
NAME= (fldname 1, SEQ)
fldname1 is the name of this field. It is not used by the
applic4tion progral it cur subset.
However, it should be specifisd
following thE rulES of ethEr fiEldnames. SEQ defines this as a
urique sequence field and must be specified as shown in our SuDset.
Data Ease Design
2.55
BY1ES=bytes
specifies the lEngth of the field. This is the length of the search
fiEld as aEtinEa in the XDi'lD statement, pIllS four if t~e ISX fiEld
is included. It also is the length of the key for the KSDS. In our
subset, it is Equal tc the length of the preceding segment.
The tBDGEN, FINISH and END statEm~nts shculd be coded as before. FigurE
2-29 shovs the physical EABTS DED (EE3FABTS) and its associated PURCHASE
C~DEB secondary index DEn {BE3PSID1) for ou~ Phase 3 sample environment"
~hese DBDs, toge~her with the Phase 3 CCStOMER ORDERS tEt (BE3CFtEE) are
included in I!SVS.EFI~!S~C. Their tEDGENs can te performed with job
I/SAftP310 in IMSVS.PRI"EJOB.
INDEX
POINTER
SEGMENT
DBD=BE3PSID1
DBD=BE3PARTS
SE3PSIDI
SE1PART
~
---
--_
--............
INDEX
TARGET
SEGMENT
L.. _ _ --.l
r-
,
--- .....-_...&.._-...
INDEX
SE1PPUR
SOURCE.
SEGMENT
r-.._ _ _.....
DESCRIPTION OF SECONDARY INDEX
INTO THE PARTS DATABASE
FOR PRIMER SAMPLE PROJECT PHASE 3
0110
DESCRIPTION OF PARTS DATABASE
FOR PRIMER SAMPLE PROJECT PHASE
NAME-BE3PSID1. ACCE S5=INDEX
D8D
DATASET 001 =DElPSI01. DEVICE=31JO .MODEL '1. SIZE=2048
..... SEGM
.....,..lCHHD
FIELD
3
NAME=8E3PARTS. ACCESS= (HDAM. VSAMI.
RMNAf1E' CDFSHDC40. 4.80.500 1
DATASET D01=DE3PARTS. DEVICE=JJ30 .MODEL '1. SIZE=2048
HAME=SEJPSIDI. BYTES=12
NAME' (SE1PART. 8E3PARTS 1 • INDEX= FElPS I Dl • PTR =SNGL
NAfIIE& (FE 3PSXD1. SEQ) • BYTE S-12. START=Ol
PARTS- GENERAL INFORrlATIOH (ROOT)
SEGM
DBOGEH
FINISH
END
·•
FI ELO
LCHILO
•
_LCHILD
"XDFLD
NAME=SEIPART. BYTEs=ao. PTR=T. RULES=PLV
5TART=0 1. eYTE S= 08. TYPE=C. NAME = C FE lPGPNR • SEQ)
CONNECTION TO CUSTOMER-ORDER DB.:
NAME' (S E20DETL. BE30ROER 1 • PA I R =S E2PAROR. PTR =OB L E
CONNECTION WITH 2ND INDEX ,
NAME'! SE!PSI 01. BE3PSIDI ) • PTR'INDX
NAME=FElPSI01. SEGMENT =SEIPPUR. SRCH=FEIPPONR.
SUBSEQ=/SXPPUR
PARTS- PURCHASE ORDER INFORMATION
SEGM
FI!LD
·
" F I i LD
•
OROGEN
FINISH
END
Figure 2-29.
IMS/VS
Ehase 3 Physical tEDs
Primer
NAME'SEIPPUR. 8YTES=6 O. PAREHT=( (SEIPART. SHGLl). PTR=r
5 TART=Ol • BYTES=08. TYPE =C. NAME =(FE lPPONR • SEQ)
START=01.BYTES=04. TYPE=C.NAME=/SXPPUR
For each program ~hich uses a rIll data baRe, a program specification
block (PSE) is nEedEd. Although cnE PSB can serve different batch
application progtams. it is reccmmended, for integrity vurposes, that
each FIcgram have its c~n FSE. ~n the online IMS/VS system, a Separate
PSB is required fcr each cnline program. Each PSE consists of cne or
more program communication klccks (PCBs), CDe for each data base the
Frcgram ~ses.
!he PSE is generated, as shewn in FIgure 2-30, in a similar m~nnEr to
the tEl using the OS/VS asse~bler and linkage editor. The generated
lead mcdule is stored in I~SVS.FSElIB.
IMSVS. MACLIB
IMSVS. PSBLIB
MACROS
~B~
~
------.
INPUT
DECK
Figure 2-30.
Figure 2-31
input deck.
Program Specification Block Generation (PSBGEN)
show~
the sequence of the macro
(
END
statem~nts
in the FSEGEN
REQUIRED: 1
PSBGEN
~
"-_ _ _ _ REQUIRED: 1
••
•
SENSEG
~
PCB
/-----------
REQUIRED: ONE FOR
•
•
EACH DATA BASE (DBD)
•
THIS PROGRAM USES.
"'-S--E-N~S""'E""'G""'"
SENSEG
4 - - - REQUIRED: ONE FOR EACH
SEGMENT IN THE DATA
~
BASE THIS PROGRAM ACCESSES.
PCB
Figure 2-31y
PS~GEN
Input Ieck Structure
tata Base Desigr.
2.57
The PSBGEN is executed by invoking a JeL cataloged procedure named
FSBGEN, which is available in the IMSVS.EROCLIE~
1he coding CODvEDticns
fc~
the ESB are exactly the same as fer the DBD.
BASIC I?SB CGDING
Following are the basic PSB control statement formats.
!his statement is coded once for each data base the program intends to
ase. The format is:
/
/-------------------------------------------------------------,
I
,
,
,
,PeE
1
17YPE=DB
l,tEttiA!E=dbdname
,
,
I.PROCOP'I= [G][I](R]{D)
,
I
1
I
I
I
,
I
"
{A
I
I
}[PJ
(P]
,
,I
I
I
I
I
I ,~EYIE~=value
I
I
I
I
I
L----------------------------------------------------------------~
1
1
I
L
(S]
~.§.9.sJl.Q:
TYPE==tE
is a requited keyword parameter for all data base PCBs.
DBDNA~E=
specifies the name cf thE DBD which is accessed via this PCB.
can be a physical or logical DBD.
It
FPCCCP'I==
specifies thE ~IOCEssiDg c~tions on sensitive segments declar~d in
this ~CB that may be used in an associated application ~~cgram.
Specifying superflucus ~recessing options is undesirable from a data
base security point of view and can result in unnecessary additional
data tase ~~ocEssin9. T~is operand allcws a maximum of four
characters. The letters in the operand have +.he following meanings:
G - Get functicr..
I
-
Insert fUDeticn.
B - Feplace function.
D - Delete functionq
Note:
~hr~E;
The fur.ctions ahove can be coded in any comtinatioD of
if all feur ar-e required, code "A".
A - All, includes the above four functions.
P - Bequired if command code D (path call) is to DE used on get
type calls Ot ins€tt calls. Determines maximum length of the
I/O area. P cannot be coded with L.
2.5S
IMS/VS Primer
L - Load function fer data base loading
(exc~pt
L5- Segments loaded in ascending sequence only
This load option is required for HIDAM.
HIDAM).
(HIDA~,
EtAM}u
KE YLl!: N=va 1 ue
is the value specified in bytes of the lcngest concatenated key for
a hierarchical patb of sensitive segments used by the application
~tcqIam in the hierarchical data structur~.
~§!~_ff~:
/
,,
,
!he format fer the G5AM data base peE statement is:
,
1-------------------------------------------------------------,
I
IPCE
I
J
,
I
III I YPE=GS Al'l
,
,tBD~AP.E=name, IROCOPT={G[ S
l}
L( S]
l------~---------~--------------------~--~------~·-----~---------~
where:
TYPE=GSAM
is a required keyword parameter for all GSAM data base PCBs.
DBDNAME=name
is a required keywcrd ~ara~eter for the name that specifies the GSAM
tEt to be used as the primary source of data set description.
SENSEG statements must not follow this PCB statement.
FROCOP'l=
is a required paraleter fer the processing o~tions on the data set
in this peE that can re used in an associated applicaticn
program
The operand is sFecifi~d u~ing the characters defined
below:
declare~
G L S -
Get function
Load functio~
Large scale seguential activity. If specified, GSAM will use
multiple-tuffEringQ This is reccmmended for heavy sequential
processing.
!2!~:
The GSA" FeE statements must follow the PCB statements with
TYPE=TP or DB if any exist in the PSB generation. 7he convention is:
7F P~Bs
- first
DE peEs
- seccnd
GSAM PCBs - last
This statement is coded once for each segment the Frogram is sensitiVE
to in the tEt defined in thE ~Ieceding PCB. The SENSEG statements
should appear in the same hierarchical sequence as in the DBD.
However
only those s~gments shculd te included to which th~ program needs
access. All segments should be specified in the hierarchical Fath to
any required SEgmEnt. Ne SENSEG statement~ should be coded for a GSAM
PCB. 7he basic format of the SENSEG statement is:
Da ta Base Design
2.59
I
I
/
I-------------------------~--------------------------- --------,
I
ISENSEG
I
,
,,
,
I
I
1
,
!
'NA~E=seqDame1
,
I
, ,FAFENT=segname2
I
I
I,
h,PROCOPT={(G][I]tR][D]}
L
~~l]
I
I
l----------------------------------------------------------------~
NAME=segname1
is the name of the sEgment ty~e as defined through a SEGM statement
during DEt generaticD. The field is from 1 to B alphameric
characters.
PAREN't=segname2
is the name of the seg!ent type that is the parent of the sEgment
type WhOSE name is sFEcified in the NAME operand. If this SENSEG
statement defines a root segment type, this operand must equal zero.
For all d~p~DdEnt sEgment tYFes, this operand must specify the name
of the dependent's parent~
PFOCCE'I=
specifies thE processing cFtions allcwable on this sensitive segment
by an as~ociated application program.
This operand has the samE
meaning as the PROCOP'I c~erand on the PCB sta~ement. If this
PROeCE! oFerand is not specified, the PCE fRO COPT operand is used as
default.
If there is a difference in the processing options
specified on the PCB and SENSEG statements, SENSEG FRCCCFT overrides
the PCE FECCCFT. When loading a data base, you should s~Ecify ?
PROCOPT only in the PCB statement.
This statement specifies the end of the PSB and providss interface
parameters for the application program. It is the la~t statement bEfore
the ENC statEmEnt. 'the kasic fcr~at is:
/
1-------------------------------------------------------------,
I
,
1
I
,
I
,
IPSEGEN
J
'IA~G~
'{COBOl}
FIll
I
,A S SE M
,
I
,
1
I ,C~EAT=YES
I
,
I
"PSENll'1E=psbname
I
,
I , Ie l! F CE ~= (45 1 , WTeE)
,
,
LI _____________________________________________________
,
I
!
,
-----------J
LANG:
specifies thE language in which the application program is written.
It must be either CeEel. PlII, or ASSEM, with no trailing tlanks.
CMJ:A'l=YES
should be SElected, Exc~Ft fer initial load programs. It provides
an extra dummy PCE in the PSB. !his benefits migratioL to online
Frocessing at negligi~le cost.
2.60
IM~/VS
Primer
FSENAME=~stnamE
is the parameter keyword for the alphameric name of this FSE. The
name valuE fer t~e PSi~A'E must be eight characters or less in
length. This na;~ beccl€s the lead module name for the FSP. in the
library IMSVS.PSELIB. This name must bE the same as the progral
load module name i~ the Frcgram library. No special characters may
be used in the name.
It must be the namE in the MBR= operand of
PSEGEN.
Should be codad as shown to concur with the recovery procedures of
our subset. ~henevEr a rea~ c~ write data base IIC error would
cccur during batch processing, the CS/VS system consolE operator
will be notifiec (lliessage DFSC451A) •
The reply sheuld bE 'ABEND'; DL/I vill then abend with a U451 aD€nd
cede. !he data set in error should thEn te recovered. See Chapter
6, "Data Base Recovery," fer details.
~his pirameter can be omitted
vhen initially loading the data basE.
!2~!:
Bsfore abovE rEFly is given, the operator should take proper
actions to prevent the Execution of any other DL/I jobs against the
affected data tasEs. See Cha~ter 6. "Data Base Fecovery," ~cr
details.
END Statement
---~---------
!his statement is required at the end of the PSB deck.
end ot the input for the OS/VS asse~bler.
/
,t
I
I END
,
It indicates the
,
,t
§~!!l~_~!!i£_f~~~
Figure 2-32 shows two PSBs fcr thE Phase 1 samEle environment. The top
cne (PEl PARTS) is the FSE for loading the Phase 1 PARTS data baSE. This
FSE can te generated with jch //SAMF100 in IMSVS.PRIMEJOB. The second
one (FE1CPFUR) is the one for the purchase order program. It also
contains GSAM PCEs and it can be generated with job /ISAMP101 (COBOL) or
//SAMP1C2 (PL/I) in IMSVS.PRIMEJOB.
tata Base Design
2~61
PROGRAM SPECIFICATION FOR LOADING
*
*
*
THE PHASE 1 PARTS DATABASE
PCB
TVPE=DB,PROCOPT=L,
oeoNAME=BElPARTS.KEYLEN=ZO
SENSEG
SWSEG
SEHSEG
SENSEG
PSBGEN
EtlD
NAHE=SEIPART
NAHE=SElPSTOK,PAFI'ENT=SElPART
NAHE=SElPPUR,Pf.RENT=SEIPART
NAHE=SEIPGDSC.PAPENT=SEIPART
LAHG=ASSEH,PSBNAHE=PElPARTS
PROGRAM SPECIFICATIm~ FOR
PURCHASE-ORDER UPDATING OF
THE PHASE 1 PARTS OATABASE
*
*
*
*
PCB
TYPE:DB,P~OCOPT:AP,
DBOtlAH!::=BElPARTS.KEYLEN=20
SENSEG NAHE=SEIPART,PROCOPT=GP
SENSEG NAME=SEIPPUR,PROCOPT=AP,PARENT=SEIPART
-If
pce
TYPE=GSAH,PROCOPT=G.
DBDNAHE=BOOINPOl
PCB
TYPE=GS~.H. PPOCOPT=L,
oeONAHE=600CUTOl
PSBGEN LAtlG=COBOL ,CHPAT=YES ,PS6t~AHE=PElCPPU~, IOEROPN=( 451,WTOR)
END
Figure 2-32.
EXECUTION
SampiE PSBs for Phase 1
or PSBGEN -- Jet
PSEGEN is run as a norlal 0Fsrating System job after IMS/VS system
definition. IMS/VS system definition causes the procedure named PSBGEN
to £e placed in the IMSVS.PROClIB procedure library. The following JCL
cards are used to invoke the PSBGEN procedure.
//PSEG!N
JOB
MSGlEVE1:1
EXEC ESEGE~,MEB=
//C.SYSIN DD
•
II
PCE
SEN SEG
ESBGEN
!hE ccntrel cards
for ESE generation.
INt
*
where keyword cperand
~EF=
is the name of the PSB tc be generated. This nam~ must re th~ same
as the name specified cn the PSENAME= operand of the PSEGEN
statement.
CeDING PSEs FOR lOGICAL DA!A BASES
When a physical DBD contains logical relationships, the PCB and the
applicaticn prcgram can still refer tc the physical DBD. However, this
shCuld te restricted tc initial data base lcad ~rograms. Pemember also,
the logical child always contains the logical parentis concatenated key.
This should nct be fcrgctten when inserting a logical child in a
physi~al DBDQ
You can never access a virtual logical child in a
physical data base, since it dces not exist.
2 .• 62
To use a logical data base, the program needs a separate PCB. This PCE
is coded in the same manner as a PCB for a physical DBD. The cnly
difference is that it refers to the DBD name and SEG~ENT names of a
logical DBD. You should only code SENSEG statements for the segments
the program actually needs and the segments in the hierarchical path to
thos,= segments.
All of this is based on the logical DBD, so the
hi~rar~hical pa~h may well include physical and logical paths.
Figure
2-33 shows the PSB for the Phase 2 processing program PE2CORDR,
containing a PCB for beth the logical data bases in addition to a PCB
for the SHISAM data base. ihis PSB is listed in IMSV5.PRIMESRC, its
PSBGEN can be performed with job IISAMP201 (COBOL) or IISAMP202 (PL/I)
in IMSVS.PRIMEJOB.
PROGRAM SPECIFICATION BLOCK FOR PHASE 2
ORDER UPDATE PPOGPAH PE2CORDR.
*
*
.*
*
CUSTOMER DATABASE VIEW
PCB
Sn~SEG
TYPE=DB,DBDNAHE=BE2PCUST,PROCOPT=G,KEYLEN=6
NAtlE=SE2PCUST
*
ORDER DATABASE VIEW
'*
*
PCB
TYPE=OB,D8DNAHE=BE2LO~OR,KEYLEN=14
SHISEG RAHE=SE20PD[R, F'ROCOPT=AP'
Sn~SEG NA~IE=SE 20PAIH ,PAREtlT=SE20PDER, PROCOPT=A
SEHSEG NAHE=SE20SHIP,PARENT=SE20PDER,PROCOPT=GI
*
*
*
PARTS DATABASE
VIE~
PCB
TYPE=DB, DBDtI,~HE =BE aPART, KEHEN= 20
SENSEG NAHE=SEIPAPT,PPCCOPT=GPP
SEt~SEG NAHE=SElPSTOK, Pt.PEtH =SElPART ,PROCOPT=GR
*
PSBGEN LANG=COBOL,CHPAT=YES,PSBNAHE=PE2CORDR,IOEROPN=(451,WTOPl
HID
Figure 2-33.
Sample PSB for Phase 2
CODING PSBs FOF
SECCND~RY
INDEXES
To use a secondary index, an application program should use a PCB with
the following additional parameter in the PCE statement.
The PCB --------Statement
----~
/
I
I
I---------------------------------------------~------- -------,
,
IPCB
I
I
I TYPE=DB,...
,
,PROCSEQ=inuxdbname
I
1
,
L--~~~-~---~---~---~~-~----~-~.-~~-~------------------ -----------J
PROCSEQ=indxdtname
specifies the name of the secondary index used to process the data
base named in the DBDNAME operand through a secondary processing
sequence. The o~erand is invalid if PROCOPT=L or L5.
1.
The DBD specified in the PCB for the secondary processing sequence
can be a logical DED.
No provisions are necessary in the logical
~BD, but its root segment must be the target segmGnt of the physical
DED.
Da ta Base Design
2 .. 63
2_
If non-unjgue ind~x fields are used, you must specify of the ISX
field in our sutset. As a ccnsequence, the sequence of root
segments ~ith the same index field value, when sequentially
retrieved via the seccndary index, will be unpredictable. ~is
sequence ~ill also vary across reorganization of the tarqet data
base ..
Figure 2-34 shows the PSB feL the Phase 3 processing program, fE3CFFUE~
This PSB contains a FCE for the normal processing sequences and a peE
for the secendary processing sequence.
PROGPAM SPECIFICATION FOR
PURCHASE-ORDER UPDATING OF
THE PHASE 3 PARTS DATABASE
*
*
*
'*
*
*
*
*
'*
PRIMARY INDEX VIEW OF DATABASES
TYPE=DB,PROCOPT=AP,
DBOtIAHE=8E3PARTS, KEYLEN=20
PCB
*
SEtlSEG NAHE=SEIPART, PROCOPT=GP
SENSEG NAHE=SEIPPUR,PROCOPT=AP,PARENT=SEIPART
SECmmARY WDEX VIEW OF DATABASES
TYPE=DB,PROCOPT=GP,CBDNAHE=BE3PARTS,KEYLEN=16,
PROCSEQ=BE3PSIDI
PCB
*
SENSEG tIAHE=SEIPART
SEHSEG NAtlE:SElPPU~, PARENT=SEIPART
PCB
TYPE=GSAM.PROCOPT=G.
*
DBDtlAHE =60 0 HIPOI
PCB
TYPE=GSAM.PROCOPT=l.
*
OBDNAHE=BOOCUTOI
PS!':',GEN LMlS=C060L, CHPAT=YES, PSB~IAHE=PE 3CPPUR, IOEROP~l= (451, WTOR I
Etm
Figure 2-34.
Sample Phase 3 PSE
The
as:
~recess
•
Each data element is readily available by the
new and in the foreseeable future.
•
~he
•
Controlled access is enfcrced for those data elements with specific
security requirements.
of data base design in its simplest form can be desc~ibed
!he structuring of the data elements for the various applications
in such an order that:
va~ious
applications.
data elements are efficiently stored on secondary storage.
In practice, one is often ferced to ccmfromise, based on available
resources in r.anpewEr, bardware and soft~are.
CCNCIP1S OF tAlA EASE
DESIG~
EecausE data tase aesign is an area where there has been little formal
standardization, there has been no consistent vocabulary for describing
the concepts involved. ~his section presents the concepts and terms
used in the following introductory data base design discussion.
IM~/VS
~rimer
A data case contains infor.aticn about entities.
tha t:
An
~n!i!I
is something
•
Can te unlqnely idEntified.
•
We may now or in the future collect substantial information aboutQ
In practice this definiticn is limited to the context of the
applicaticns under consideration. Examples of entities are:
~arts,
projects, orders, custcmers, trucks, etc. It should be clear that
defining entities is a major step in the data base design procEss. The
information we store in data bases about entities is described ty data
elemeD'ts.
~~!~_~!i!iD!§
A g!l!
!!!!!~l
entity.
Fo~
~olor=Green,
is a unit of information that specifies a fact atout an
example. suppose the entity is a part.
Name=Washer,
and ieight=143 are three facts about that part~ Thus these
are three data ElEmE~ts. A data element has a name and a value. A d~ta
element D~!~ tells the kind of fact being recorded; the !!lY~ is the
fact itself. In the atovE ExamFle, Name, Cclcr, and Weight ar€' data
elellent names; Washer, GreEn «and 143 are values. A value must be
asscciated ~ith' a name to have a meaning.
An occurrenCE is the value cf a data element for a particular entity.
Figure-2;3S-illustrates thE ccr.cepts of data element! and their
occurrences in recording the facts about t~c entities, parts (Entity A)
and crders (lntity E).
r-----------------------------------------------------------,
,
!BIIII_1i__
,
£AR1~
1---------------------------------------------------------~-1
DA1A EIE~EN~
I
CCCUFFENCES
I
,
,t---------------------------------------------------~-------1
Name
t
Value
I
Value
,
1-------------------------------------------------·---------!
PaIt Number
I
0200311C
I
03003720
I
,
Name
'ScrEw
I
Washer
I
Unit Price
,S;.CC
I
$1.00
I
I Unit Quantity
1
100 pieces
,
100 pieces
I
Stock Quantity
,2CCO
,3000
L-----------------------------------------------------------~
1
,
1
1
!EIJII_ll__ Q~~!li~
,
DA'!A
ELE~EN'I
i
I
CCCUFEENCES
,------------------------------------------------.----------1
Name
Value
Value
I
I
~
1-----------------------------------------------------------1
Crder Number
I
,gOFfe
,'90F60
,
Fart Nalile
Screw
t
I
Fart Number
J
1 03003730
,
,
,
t
I
I
,~ol
C~CC311C
Quantity
, 5 0 0 units
1
300 units
I
Supplier Name
I
Allied Screw
I
Allied Screw
I
I C r de r Cod e
I
A
,X
I
L-----------------------------------------------------------~
Figure 2-35. Concepts ~f Data Elements
L~ta
Base Design
2.€5
Quite often, data elements which add information to an entity arE called
2!~~!~Y~~§.
An attIibute is always de~endent on an ~ntity. It has no
meaning by itself. Dep€r.ding on its usage, an entity can bE described
by cne Single data Element cr mere. Ideally, an entity should be
uniquely ,defined by one single data element, for example, the order
number of an crdEr. Such a data element is called !h~ !~I of the
entity. 7he key serves as the identification of a particular entity
occurrence, and is a special attribute of the entity. Keys are not
al~ays unique.
In such cases, entities with equal key values are called
§!n2BI!§- For instance, the full name of a person is generally not a
uniquE identificaticn. In such cases we have to rely on other
attributes such as full address. birthday or an arbitrary sequence
number. A mote common method is to define a new attribute, wbich serves
as the unique Key, fcr exam~le, employee number.
lh!_lI~~§~s~i.Qn
Data in itself is net t~e ultimate goal cf a data base management
systemq It is the application function performed on the data which is
important. !he test way to re~resent that function is the ~~!~§!f1~Qn,
which is the smallest ap~lication unit representing a user interacting
with the data base. For example, ong single order, one part inventcry
status ..
",,-
"'-
• ---.
INPUT
USER
TRANSACTION
-
_ OUTPUT
Figure 2-36.
PROGRAM
-.----
!he !ransacticn
0
l
/
I
.A
....
"(
y
K
)
""""""'
-
J?o
"'"
~
are precessed by aFplicaticn programs. In a batch system,
large nu~ber5 of transactions are accumulated ~hat is, all c~de~s cf a
day), then precessed against the data base with a single scheduling of
the de£ired application program. Although transactions are always
distinguishable, even in batch, some people prefer to talk about
programs rather than transacticns. But, especially in a rBltC
envircnment, a clear understanding of transactions is mandato~y for gcod
design. The transacticn is in some way the individual usage of the
application by a particular user. As such, it is the focal ~oint of the
rE/tC system.
Transaetion~
In this chapter ~e ~ill utilize the transaction for the data base
designQ A similar role is set aside for the transaction in ~rogram
design by adding detailed inFut. processing and output descriptio~s to
the data element usage.
Each transaction bears in its input some kind of identification with
respect to the entities used (for example. the pa~t number when
accessing a Parts data base). These are referred to as the ~£~§§§ f!!h~
of that transaction. In general, transactions requi~e random access,
although for Ferfe~[ancE reasons sequential access is sometimes usedQ
This is pa~ticularly true if the transactions are batched and they are
2.66
IMS/VS Primer
numerous, relative to the data base
from most data raSE records.
or if information is
siz~,
need~d
For efficient random access, each access path should utilize the
entity's key. ~ith pr~per data base design, DL/I generally provides
fast physical access VIa a key. Therefore, identification of the
transaction access path is essential for a design to yield good
performance.
A convenient wa, to specify the transactions, the data element and their
interaction is the !~g~s2~11£~/~2!~ ~l~!~~! !~!~!!, Figure 2-37.
CUSTOMER
ORDERS
$:
~
~
Z
w
0::
w
:IE
0
I-
~
~
A..
$
~
DATA
ELEMENTS
Q,<::r
~
PART NAME
R
R
I0::
~
0..
$:
$>
>
II-
#
~
U
0::
wo::
:lEw
00
1-0::
~o
U
~
0
$:
~
&
0
&
0
$
#
~
~
R
R
R
PART NUMBER
R
~
®
®
R
R
STOCK LOCATION
R
R
U
U
R
R
CUSTOMER NAME
R
~
CUSTOMER NUMBER
eI)
::>
$:
~
0
ORDER NUMBER
PART NUMBER
U
D
CUSTOMER NUMBER
R
D
PART QUANTITY
U
D
[]]
~
OJ
ORDER NUMBER
Legend:
Figure 2-37.
o
o
DIRECT ACCESS PATH (KEY)
SEQUENTIAL ACCESS PATH
The 'Iransaction/l>ata Element Matrix
The transaction/data element matrix specifies, in its simpl~st form, the
precessing intent of the application transactions against the data base
elements:
..
P,4?trie ve ; read only R
•
UFdate in place
U
•
Add, insert
I
•
telete
D
•
•
All cf above
A
Null. not sensi ti ve - or hlank
{lata Ease Design
The data elements wbich are dirEct access paths for a transacticn are
denoted by a bexed latrix item. These should be keys. Sequential
access is indicated by a circle around the matrix itemG
!he Frccess of designing a data base (Figure 2-38) can te generally
divided into the follcwi~g ~asks:
•
Gathering reqairemEtts
•
Designing applicat10n data structures
•
Designing physical data structures
•
tesign €valuaticn
..-.-----DESIGN PHASE-------I...
1-oI1
...
I
AI'
if
GATHERING
REQUIREMENTS
r.
OATA ELEMENTS
T
R
A
N
f
...
f
...
f
S
A
~
f ...
f
I
DESIGNING
DESIGNING
DESIGN
APPLICATION
PHYSICAL ~
~
DATA
EVALUATION
STRUCTURES
STRUCTURES
~
TION
,,-
~/~
OPERATION&
EVALUATION
MONITORING
........
....
"'-
DBDLIB
~
0
N
S
PHYSICAL
r. IMPLEMENTA- r.
'--
~
,,-
........
~
§
~
DATA
BASE
'-
t
Figure 2-38.
.-'
'r
lhe Steps in Data Base Design
Usually the atove stEPS are reFeated until the design satisfies the
requirements. After this design process, the actual developaent,
implementdticn ,data caSE lead) and prcduction begins. During
production, the system is subject to monitoring which can 9i98 feedback
for the design phase. !bis will be di~cussed in Chapter 9,
"C pti mi za tion ".
2.68
I~S/VS
Primer
GA~HEFING
BECUI~E~ENTS
The first step of the data baSE de~iqn roses many questions:
What do
the aFflicaticnE needi ~hat inputs are required to drive them? What
data outputs will they produce? Eow are the data elements related to
one another? Which elements are identifiers and which elements 00 they
identify? Hc~ frequently are they used? Have input sources been
specified for all data elements?
During the Frccess of gathering requirements, thase and related
questions are anE~ered primarily during conversations tetween a oata
base designer and an analYEt irem the deFa~tment that regup.sts an
application. In some organizations, a set of forms appropriately filled
in marks the end ot the requirEfents gathering step; in other
organizations, less formality is involved. In any case, this fir~t steF
in data base design ends when the design9r collects the data needs of
the individu~l aPFlications that ~ill U~~ the data base being designed.
The
requirem~nts
for a data base should contain:
•
The data being managed, that is, the entities and associated data
elements
•
!he relations betwEen the
the various users
•
~he functions being
transactions
•
!he aCCESS path as required by the transactions
en~ities
~eriormed
and data elements as needed ty
against the data, that is,
~he
The first step in gathering ~be requirementE is tc determine the
entitieso ihis is not a trivial task, because the choice of €nt~ties is
dependent on the envirenment.
A data elemeDt which, initially, is considered an attribute, could
beco~e an entity itself when n~v applications are added.
For ir.stance,
the data, element colcr is normally seen as an attribute. But in a paint
factory frccess it might very well be an e~tity itself. It should b~
clear that the change cf a givEn data eler.ent from attribute to entity
cculd have a significant impact on the data structur~. To avoid thiE as
much as possible, one should be v~ry careful in the choice of entities.
To Iegister the functicns ~erfc:~€d against the data elemen~s, first
construct the ~~~n~~~!~Qn/gg!g ~!~~§n! !~!I~!. Optionally wh€n the
matrix becomes tee lar9€, ene can ccnstruct a s~parate matrix fer each
major apflication. dncther useful approach is to make a large drawing
for display en the wall. This process is most effective if th€ mat~ix
not only contains the ~pplica~ion~ of the immediate future, but also as
much as fossible about future applications and data elements.
Additional columns could be added for miscellaneous information such as:
•
Occ~rrence
frequencies cf transactions and data elements
•
Size and format of data elements
•
Priorities and response/turnaround time criteria
•
Availability (how long can the function be suspended)
•
5ec~rity (who may have access to the information mad€ available by
this transaction)
tata Base Design
2.69
•
I~put/output
descri~tions
per transaction, for application program
design
!he transaction/data ~lement matrix, tcgether with a detailed
description of the data tase and its use, constitutes the requirements
fOL the design step.
For the detailed description of the data base, its
segments and fields, a dccumentation scheme should be established. As a
minimum, forms should be uS9d for a manual registration of the data
tase, the segment layout, the fields and their attributes. It is very
imfortant to register which program uses which data elements. The next
step would be to use the Assembler DSECT, COBOL COPY, or PL/I %INCLUDE
facility for centralized management of segment descriptions.
Ultimately, a data dictionary system might be utilized.
For each phase of cur sal~le environment, we can now construct a
transaction/data element matrix.
The phase 1 transactict/data element matrix is shown in Figure 2-39. It
is clear the main entity is parts. Othar possible entities ceuld be
purchase order, supflier and stock location. Ho~ever, we assume no need
to gather mere informaticn cn these in our Phase 1 sample environment.
Netice, the following information is added to the transaction data
element matrix:
•
For each data element, we li~t its size and its occurrence per
entity. C - 4 means that this data element occurs a minimum of zero
times, and a maximum of four.
•
For each transacticn,
days (C).
w€
list its average frequency in weeks (W) or
In tha phase 2 environment, we add the Customer Order Processing
application. !bis extends the phase 1 transaction/data elament matrix of
Figure 2-39 to the one shown in Figure 2-40. Essential here is that,
besides adding new data elements for the customer order processin~. this
ni~ applicaticn also requires the existing PARTS data elements.
Also notice that the part number data element appears beneath bot~ the
PARTS and the CUSTOMER ORDERS entities. !his constitutes the basic
re~uirement fer a linkag~ or relation between these entities as ~e ~ill
see lat er.
In the phase ~ environment, we added the purchase order inquiry
transacticn, lE3FQI~C. This transaction requires a direct and a
sEquential access path tc the purchase crder information based on the
purchase order number. This is because we want to be able to list an
individual purchase erder, er a range
purchase orders in their order
number seguenceo See Figure 2-41. In practice, this access Fath ceuld
also be used fer the pUIchasE crder change (TE1FOCNG) and delete
('IE 'PODEL) transactions.
0=
2.70
IMS/VS Primer
PURCHASE
ORDER
§>
~
>
t:
~
w
~
FE1PGDSC
R
13
FE1PGSNM
®
R
R
R
8
FE1PGPNR
R
~
~
~
[ill
8
FE1PGUNT
R
R
R
R
R
8
FE1PGPRI
R
R
R
R
R
R
R
R
8
FE1PGDIM
R
R
1-6
12
FE1PSLOC
R
R
1-6
6
FE1PSCNT
R
R
1-6
6
FE1PSDAT
R
R
"
~
~
d'~" ~§
~
w
N
iii
Z
~
o
D
DIRECT ACCESS PATH (KEY)
SEQUENTIAL ACCESS PATH
1ransaction/tata !lemant Matrix for Phase 1
Da ta Ease Design
2.71
PURCHASE
CUSTOMER
ORDER
~
~
>
I-
~
zw
~
u
z
w
u
?l
0.3
o~
~
w
N
;....~
~
50
~
~
~
~"
~
§
0<.1
;....~
~
~
@
....
~
$
~
~
:;)
ORDER
C<.l
S
~
;....~
,,~
~
[E) [E).
R
·13
FE1PGSNM
®
8
FE1PGPNR
R
0
8
FE1PGUNT
R
R
R
R
R
R
R
8
FE1PGPRI
R
R
R
R
R
R
R
8
FE1PGDIM
R
R
R
R
R
R
R
R
R
0 0
R
1-6
12
FE1PSlOC
R
R
R
R
1-6
6
FE1PSCNT
R
R
R
R
1-6
6
FE1PSDAT
R
R
I-
1-6
6
FE1PSISS
R
R
«Q.
1-6
6
FE1PSREC
R
R
(I)
c:c
0-4
20
FE1PPOSU
R
R
U
0
0-4
6
FE1PPQOD
R
R
U
0
0-4
6
FE1PPQRD
R
R
U
0
0-4
6
FE1PPODT
R
R
U
0
0-4
6
FE1PPDDl
R
R
U
0
0-4
8
FE1PPONR
R
R
R
0
8
FE lPGNEW
R
R
ex:
w
~
(,:)
I-
(I)
::::>
U
(I)
c:c
UJ
Cl
0.1
0:::
0
8
FE1PGOLD
R
R
8
FE1PGEQV
R
R
6
FE2PCNUM
A
R
R
FE2PCNAM
R
R
FE2PCADR
R
R
20
FE2PCCTY
R
R
6
FE2PCPCD
R
R
6
FE20GREF
QJ [E] @]
2
FE20GSTA
U
0
6
FE20GODT
U
0
6
FE20GDDT
U
0
2
FE20GDWK
U
0
20
FE20GSPC
U
0
2
FE20GORI
U
0
FE20DQTV
U
0
'-8
6
1-8
8
I-
1-8
='
U
0.1
(I)
J
R
20
~
0
U
20
0:::
w
U
FE20DPRI
U
0
FE20DTAX
U
0
8
FE20SNR
U
0
0.1
6
FE20SDAT
U
0
0.1
20
FE20SMET
U
0
FE20DBOR
U
0
6
FE20GCNR
R
0
8
FE20DPNR
U
0
'-8
1-8
Legend:
DD'RECT ACCESS PATH (KEY)
OSEQUENTIAl ACCESS PATH
Figur~
2-~O.
2.72
IMS/VS PrimEr
lransaction/Data Element Matr ix for Phase 2
CUSTOMER
ORDER
PURCHASE
ORDER
>
~
~
Z
w
en
~
cr:
«
Q.
Z
w
u
~
OV
~
~
0.3
50
FE1PGOSC
R
13
FE1PGSNM
®
8
FE1PGPNR
R
~
8
FE1PGUNT
R
R
R
R
R
R
R
8
FE1PGPRI
R
R
R
R
R
R
R
8
FE1PGOIM
R
R
R
R
R
1·6
12
FE1PSlOC
R
R
R
R
1-6
6
FE1PSCNT
R
R
R
R
1-6
6
FE1PSDAT
R
R
1-6
6
FE1PSISS
R
R
1-6
6
FE1PSREC
R
R
0-4
20
FE1PPOSU
R
R
U
0
R
0-4
6
FE1PPQOD
R
R
U
D
R
6
FE1PPQRO
R
R
U
0
R
FE1PPODT
R
R
U
0
R
6
R
,,1<1
,,1<1
,,41
R
R
R
R
[E] [E] [E]
R
~
[E]
R
U
U
U
R
R
0-4
6
FE1PPDDT
R
R
U
0
R
0-4
8
FE1PPONR
R
R
R
0
[§]
8
FE1PGNEW
R
R
8
FE1PGOLD
R
R
8
FE1PGEQV
R
R
R
R
6
FE2PCNUM
~
~
0
20
FE2PCNAM
R
R
0
20
FE2PCADR
R
R
0
20
FE2PCCTY
R
R
0
6
FE2PCPCD
R
6
FE2PGREF
2
FE20GSTA
U
6
FE20GODT
U
0
6
FE20GDDT
U
0
2
FE20GOWK
U
0
20
FE20GSPC
U
0
0
cr:
w
~
0
~
en
::>
u
en
C
~
,,1<1
N
~
~
0-
iii
0-4
w
~
§
eV
w
~
g
0-4
cr:
~
a:
a:
::l
§J
....@
w
U
0.1
0
0
0
cr:
2
FE20GORT
U
cr:
6
FE200QTY
U
0
~
8
FE20DPRI
U
D
0
w
0
~
en
::>
U
1
FE20DTAX
U
0
0.1
8
FE20SNR
U
0
0.1
6
FE20S0AT
IJ
0
0.1
20
FE20SMET
U
D
1
FE200BOR
U
0
6
FE20GCNR
R
0
U
D
1-8
1-8
8
FE20DPNR
legend:
Figure 2-41.
o
o
I
DIRECT ACCESS PATH (KEY)
SEQUENTIAL ACCESS PATH
Transaction/tata Element "atr iJC tor Fhase 3
Cata Base Design
2.73
DESIGN THE
AFPLICA~ION
tA~A
StRUCtURE
~he data elements ca~ nov be arranged in an application data structure,
which consists cf cne cr mcre hierarchical data structures. We always
censtruct hierarchical data structures based on the transaction/data
element matriI: that is, the way the application program views it •
.§~g!~!!!_~!i2YRi!!g
For each transaction, we start with the access path of that transaction
to the entity, and censtruct a desired hierarchical view for that
transaction. If more than one entity is accessed in one transaction,
multiple hierarchical structures are required for that transaction. For
each hierarchical structure, we try to group the needed data elements in
the same type of segments. Each root segment of such a basic structure
contains the key field which is used in the access path. If multiple
key fields (fer exa~ple, ~art number and stock number) are used in one
access path, these may become the sequence fields of a parent/child
cembinaticn.
!he first field in the rcct segment is the key: the sequence field. To
the r~ot segment are added these data elements which are of a general
nature, freguently used and/or compact, and occur once (or Kaximu~,
perhaps 3 times) pEr Entity.
Next WE group those data elements together in segments which belong
lcgically to each other, based on their nature and use. Likely
candidates for SEparate segments are those data elements which have
multiple cccurrences for a given root. The final result of the legical
structurE desisn step is a set ef hierarchical data structurES. !h~se
represent the ¥ie~ of the data by the different application programs,
the a~plication data structure.
Based en the transaction/data element matrix of Figure 2-39 and above
guidelines for desi~ning aFFlication data structures, we construct the
fcllcwing strtcture for the phase 1 Parts data base (Figure 2-42}.
PART
(SE1PART)
I
./
I
-
./
/'
I,
./
PURCHASE
STOCK
ORDER
(SE1PPUR)
(SE1PSTOK)
V
l/
Figure 2-42.
Phase 1 Application Data structure
Sequential access is needed via the ~art short name, FE1PGSNP. and direct
access is needed via the pa~t number FE1PGPNR. We can, however, Frocess
the !E1INVRP transactien in Fart number sequence and then sort the
2.74
IMS/VS
~rimer
output in part short name sequence if needed. Direct
number is very important for later online processing.
~ccess
via part
~b~ ~2Q! §~gm~n!. §I!fA~l
The rootkey is the part numter lE1FGFNF field. The next step is to add
the follcwin9 fiElds to the reet sEgment because they are of general use
and cccur for each part only once:
!t.§DB!j;
FE1PGFNE
fE1PGSNM
FE1PGNEli
FE1 PGOL t
FE 1PGEQV
FE1PGUN'I
FE1PGPRI
FE1PGDIM
FEl PGLNf.
g
13
8
Part Number Code
Part Descri~ticn - Short Name
Ne~ (Superseding) Part No.
Old ISuperseded) Part Ne.
Equivalent part No.
Unit of ~easure
PriCE
Dimensions
Part Name (long Description)
SEG ME NT LENG~H
e
8
8
8
8
~o
1''9
We define separatE se9ments for steck and purchase order data elements
because each can have multiple occurrences for each part and they are
used separately.
Ib~_a~g~5_~~~~§D!,_~~jf~lQ~
This segment bas 1-6 cccurrEnCES fer each part:
Name
---.,.
l~ng~h
fE1PSLOC
FE1PSDA'I
FE1PSCN'I
FE1PSISS
FE1fSREC
Steck
Stock
Steck
Steck
Stock
Physical location Code
Physical Count tate (MMDDYY)
Fhysical Count Quantity (TALLY)
'Ictal Issues Current Period
Total Beceipts Curr~nt Period
SEGl!EN'I LENGTH
36
FE1EPCNB
lE1PPOtT
FEliPCSU
FE1PPQOI
FE1PPQRD
FE1FPDD'I
Furchase Crder Number
PurchasE Order Date ~eDDYY
Supplier's liame
Quantity Ordered
Quantity Received
Delivery Date ~MDDYY
SEGMENT LENGTH
6
20
6
6
6
~2
12
6
6
6
6
e
The above application data structure of the Phase 1 Parts data base,
will be input for the ph}sical data base design in the next design step.
ih!!!_~_AR]li~~liQn_~~!~_~!IYf!YI§
To support the PhaSE ~ transacticn/data ele.ent matrix of Figure 2-40 1
we need two hierarchical structures in addition to the one shown in
Figure 2-42. The result is shewn in Figure 2-4J~ The design of the
segments in the new hierarchical structures is done similar to tt.e
design of the PhaSE 1 Parts data structure.
Data Base Design
2.75
CUSTOMER
ORDER
r
./
.;-
""
""
~
1/
I,
./
""
CUSTOMER
ADDRESS
SHIPMENT
DETAIL
I,
./
l/
./
STOCK
~
PART
I,
""
--'
JIll'
""
l./
Figure 2-43.
I,
""
CUSTOMER
ORDER
PURCHASE
ORDER
STOCK
JIll'
./
Phase 2 Applicaticn Data Structure
The following consideraticns aFFly:
•
The hierarchical data structure PAR!S is extended with a CUSTCMER
CEDER segment. This provides the customer crder per part relation.
•
Sev€ral s~9ments a~pEar in different structures. They also vary in
their data element ccntent. !his is essentially data redundancy,
which will be addressed in th~ physical design step. At this time,
hpwever, WE are mainly interested in the data structure as needed by
the transactions.
EQ~§:
In your situaticn, tbF.s~ structures could be far more ccm~lex.
For instanCE, the CustCHEI da1a structure could have separate segments
for accounts rEceivablf, lark~ting statistics, etc. The PAFTS structure
cculd have a ccm~onent and assembly structure. This is not addressed in
our samplE bat can te easily ilplemented with OL/I.
!he essential additional requirement of Phase 3 (see its transactionl
data el~mEnt matrix cn Figure 2-41) is the need for access to the part
2.76
I~~/VS
;rimeI
and purchase orde£ ~ata elements iia the purchase crder number. This is
reflected j.n the Phase 3 application data, structure in Figure 2-44.
I
CUSTOMER
ORDER
I
/
:7
/
/
1/
I
,
./
I
/
CUSTOMER
ADDRESS
SHIPMENT
DETAIL
I,
/
CUSTOMER
~
~
/
STOCK
1/
PART
;
PURCHASE
ORDER
I,
./
7'"
./
PURCHASE
ORDER
STOCK
./
./
J,
./
CUSTOMER
ORDER
l/
2-44~
DESIG~
!HE PHYSICAl DA!A STFUCTUEES
1•
~
PART
./
Figure
-"
~
Phase 3 Application Data Structure
In this step, the logical structures are matched against the functions
and characteristics of DL/I. Physical data base structures are defined
and sFecified in tEDGEN control statements. TLe tL/I storage
organization and OS/VS aCCESS methcd are selected.
Additional
considerations may yield changes in the segment design. SEe
Figure 2-45.
.
Data Base Design
2.77
r------------------------------------------~----------------,
GBCOF IN CtiE SEGMENT <------>
,
SEFAFATE SEGMENTS
,
,-----------------------------------------------------------,
Few occurrences
«~}
Multiple occarrences (>10)
Small 1<20 tytes)
La r 9 e (> '00 byte s)
Higb use (every access
to record)
Bead-only
Lo~
Update, Insert, telete
GeneIal use
Secured use
only dependent upon a
single data element
Dependent upon relation
of data elements
Fig~re
2-45.
use (once a month)
Grouping Data Elements into Physical Segments
The numters shewn in Figure 2-~~ are not fixed. They merely provide a
basis feI YOUI o~n estimates. Additional considerations:
•
Single versus aulti~le CCCUIrences. If a data element has a high
numker of cccurIenCES, it is likely te be a segment itself,
especially if it is large. If it is small and highly used, then all
its occurrences could be stered in the same segment. However, the
occurrence control ~ould then be the responsibility cf the
applicatien program, as Dl/I itself dees net provide for multiple
eccurrences of the name field in a segment.
•
A very large segment can haye a negative impact on DL/I's management
of space on direct aCCESS aevices. So the basic rule is: "Try to
keep them more or less the same size".
•
If a data element needs special security (that is, only ~articular
applications may have access to it), it can be stored in a separate
segment together with other data elements with the same security
requirements.
The final result of the physical structure design steps is the data base
descriptions (DEDs) and program specification blocks (PSBs) for the data
bases and their processing ftegrams.
We ~ill now match our requirements as specified in the applicaticn data
structure of Figure 2-42 and the transaction/data element matrix of
Figure 2-39 with the available tt/I functions as presented earlier in
this chapter. 'Ihe cutccme of this ma tching is the ph ysical data tase
design reflected in the ten and the physical data set attritutes.
Access methods can, in general, be changed during reorganization without
affecting applicaticn ~Icgrams. Still, because the access method is one
of the most critical performance factors, it should be carefully
selected. First we will discuss selection of the DL/I access method,
HDAM, HIDA~, Ot SHISI~.
2.78
I~S/VS
Primer
!hiD_~f_~h2Q!!_tl~I~:
EDAf is recognized in practice to te the mest
efficient stv~ag~ c.rgarizatien cf tl/I. It should be your first choice,
at least in th€ cnline envircr.ment. HDAM's pri~e advantages ar€:
1.
Fast direct acceBS (no index accesses) with few I/O operations
2.
Single data set and associated control blocks
3.
Small werking SEt io lair stcIage for tt/I
4.
Good
phy~ical
sequential access
Disadvantages of HLA" arp.:
1.
You need a randomi2inq module.
2.
Sequp.ntial access in root key order is not possitle if th€ Fhysical
sequence of data base records in stoIage is not the same as the root
key s€quence. This is dependent on the randomizing module and root
key characteristics.
In many cases, the dis'advantages for HDAM dc not apply or can be
circumvented. The effort needed to circumvent should be weigb€d against
the savings in terms of main stcrage and CPU usage. There is DC doubt,
however, that an applicaticn with enly HDAM data bases is the most
comFact one. Scme possible solutions for the above EDAM disadvantages
are:
1.
The IMS/VS system provides a general randomizing module, tF5HDC40,
which can be used for any key range.
Furthermore, the secticn "HDAM
Bandomizing Modules" in Chapter 7, "Installing IMS/VS," will previde
you ~ith guidelines on how to write your own ranaomizing medul~.
2.
If heavy sequential processing is required and a randomIzing module
which maintains key seguEnce cannot be design~d, then sort
techniques can be used:
a.
tf the progra~ is ncn-input driven, as is the case with many
repcrt prograls, siD1~le Get Next Frccessing presents all the
data base records in physical sequential order. The output
could thEn b€ sorted in the desired order. Also, in many
instances, only certain selected segments are required. 50 the
output file cf the extract can be a fairly small file.
b.
If there are input transactions which would normally be sorted
in root key sequence they should inst~ad be sorted in Fhysical
sequence. This can te readily dcne with an E61 sort exit
routine ~hich passes each root key to the randomizing module
for address calculaticD and then sorts on the generated
addresses plus root key instead of the root key itself. An
example of such a reutine, DFSOASR1 is provided in
IMSVS.PEI~ESIiC.
3.
A secondary index cculd te built with the root key as index search
argument. The cost of this should be weighed against the cost of
sorting as in 2 aboveo The secondary index provides full geIeric
key SEarch ca~atility, hewsveI.
We will select HtAM as the OL/I access method for our initial Farts data
base, and vill use Technique E above in loading it.
(Fer details see
"Loading a BtAM tata Base" in Chapter 5.)
~h§~_tQ_~hQQ§~_~l~A~:
If ycu cannct use HDAM fot serue reason, then use
HIDAM (see above discussion).
Data Base Desigr
2.79
Hh~~_~~_~h~g~!_~fiI~!~:
~igraticn tool.
That
~his access method should only be used as a
is, if your organization currently has files based
on ISAM or KSDS access methodsy It is not recommended for new da~a
bases. With SEISAM, new Fregrams can use the DI/I interface with full
recevexy function.
Existing VSAM prograls can access the data tass as a
regular KSDS and elder ISAM-basEd programs can use the ISAM-VSAM
interface.
We will utilize a SEISA! data base in eur phase 2 environment.
~hi£h_9~L~§_!££~§§_~~~hQg
Fer HDAM you could choose either ESDS or OSAM as the physical access
method. There is net much difference as far as DL/I is concerned,
although CSAM requirp.s less main storage for code and contrel blccks.
In general you should select ESDS if your installation already uses VSAM
er Flans to use it for other data bases.
~he real benefits from CSA~ are gained when you hav~ an application
which uses HtAM/OSAM s!fly~jl§lY. In ~ny Cdse, conversion from
HDAM/CSA~ to HDAM/VSAM is relatively simple once you have gained
experience with VSAM itself.
For the phase 1 data base we
method.
w~ll
select
OSA~
as the physical aCCESS
In the final steps ef segm€nt design we must leok at the physical
parameters more closely:
•
!he segment lEn9th
•
The number cf cccurrEnCES F8r
•
Location of segments in the hierarchy
•
Average data base record
segre~nt
Fer Farent
s~ze
fsf{Q~m~nS~_~§E~~~§:
The main ~easure of access performance is the
number of I/C requests nE~~ssar1 to satisfy the calls an ap~lication
Frogram issues. These are mainly dependent upon the physicaJ data base
design and the data base tuffer pool size; th~ latter will be discussed
in Chapter 9, "Optimizatien." Second, the number of required rIll calls
shculd be ~eighted.
Basic reccmmendations (EDAM and HID AM) :
•
7ry te locate the segments most often used together with the roet
segment into one centrol interval/bleck. The segments ar.e initially
physically stored in hierarchical sequence so the most frequently
used segments should be en the left of the structure (lOW segment
codes).
•
to avoid long twin chains, that is, many occurrences of a
particular segment under cne parent. Chain length should be
estimated in terms of blOCKS needed to store such segments. For
example, 100 segments ef 20 bytes (including prefix) cause lGSS
performance problems th~n lC SEgments of 1500 bytes each if the
block was 3000 bytes. See also the discussion of the "tytes"
parameter under Basic Feccmmendaticns (HDAM) below.
2080
~ry
IM~/VS
trimer
•
Inserts after initial lead will first check the block of the
hierarchically preceding segment for available space. If nc space
is found,' nearby blocks in the buffer ~ool are examined. If still
nc sFace is found, a ~i~ !~E B!2£! is used to search for space
within !3 cylinders in cur SUbsEt. The bit map block contains one
tit for each tlock in the data set. Eit map blocks are repeated
each N blocks; N is nUlber of bits in a block. The bit is set to
one if the corresponding hlock contains enough consecutive free
space to hold the largest ~eg~ent (including prefix) of the DBt. If
nc space is fcund, the segment is stored at the end of the data set
for HIDA~ and in the overflow area for HDAM.
Basic recommendation
•
(HDA~):
During consecutive inserts (no intervening calls) of segments of a
particular data base record, the bytES parameter in the RM~A~E
keyword in the DBD statelent will limit the amoont of data stored in
the· rcot addressablE area. If the limi t is reached (bytes incl udes
prefix) consecutive inserts are placed in the overflow area. Using
this parameter, especially doring initial load and reload, can
benefit an equal distribution in the case of a large variation in
data hase record size. See also, HDAM space calculation later in
this chaFter.
fhI§if!!_Q2!~_~~2~_~~fY£~Yf~_!£!_Iha§~_1
Applying above guidelines to the phase 1 Parts data case giVES the final
physical data baSE structuIE cf Figure 2-46.
HDAM,OSAM
SE1PART 10,000
10,000
80, 18,98
FE1PGPNR
I.
,
,.
SE1PSTOK 40,000
0,6,20
40, 6, 46
FE1PSLOC
./
Figure 2-46.
./
../
SE1PPUR 2000
0,1.,4
60,6,66
FE1PPONR
,.
I
/
SE1PGDSC 3000
0,0.3,1
80,2,82
l/
./
physical Data BaSE Structure for phase 1
Data BaSE
PAR~S
As you will notice, we created a fourth segment, SE1PGDSC which contains
the full EaIts descriptive name, FE1PGLNM, since:
•
~his
information is rarely needed, especially in the foresEEn
onli~e
procEssing
•
By bringing back the root segment from 148 b1t~s to 98 bytes
(including prefix) we improve the s~gment insert processing cf th~
stock and eSfEcially the FUIchase order segment. This results
because the f~ee space bit map is based on the largest physical
segment size.
Data Base Design
2.81
Fu=thermore, we added a dummy field to the segments. This could be done
in practicE if you EXPEct the segment to be expanded in the near future.
At least you should make all segments an even number of bytes.
We also added to the data base structu~e in Figure 2-46 the main
physical segment attritutEs which are cf most importance for performance
considerations. It is recomm@nded that you maintain such structural
figures for your data tases. 1hey have ~roven to be very valuable for
performance monitoring and design reviews. A description of those
attritutes follows in Fiqure 2-4i.
rrJ
./
./'
SEGMENT NAME, OCCURRENCE
FREQUENCIES (MIN, AVERAGE, MAX)
LENGTH (DATA, PRE FIX, TOTAL)
SEQUENCE FIELD NAME
1
V
•
Segment name, occurrence specifies the segment name and the total
number of this segment occurrence in the data base.
•
Frequencies specifies the minimum, average and maximum number of
occurrences for this segment per parent occurrence.
•
Length specifies the segment data length, the segment prefix length
and the total (=sum of data + prefix) length of the segment.
•
Sequence field specifies the name of this segments sequence field,
if any.
Figure
2-~7.
Specification of Physical Segment Attributes
£Qg!~g_~h~_fh~§!_l_!A]!~_&]~~]~A]
We can now code the DBt and discuss the final parameters such as pointer
options and Cl/blocksizE t:arallleters. Some iteration with the preceding
secticn is normally necessary because thE pointer options selectEd
influencE the size cf thE segment prefix and, as such, can have an
imt:act on physical segment design. The final DED of our Phase 1 Parts
data ~asE is listed in Figure 2·22 earlier in this chapter under the
topic "Basic tEDGIN".
BecaUSE there is no use ex~ected of the physical child last pointer in
any segment, code ~AEENT = CCsegname, SNGL)) in all dependents. Because
of this (no deletes after retrieve last), only physical twin forward
pointers are needed. Code P~R=~ in all segments. Because there is
never more than one occurrence of the SE1PGDSC segment for any part, the
physical twin forward FcintEI for this segment should be suppressed;
c od·e P 'IE= N'I.
2.82
IMS/VS Frimer
~~1§£!ing_&IL]!2£!§!!~~
In choosing the Cl/blccksize the fellowing
ccn~ideraticns
apply:
•
Try to fit all highly Deeded segments of a data base record into one
tor more consecutive) Cl/tlocks.
•
One tlocksize for all cata base OSAM data sets (if any) will limit
the amount of sub~eols. However, usir.g a unique size for a highly
used data base allows a dedicated subpool specification for that
data tase.
•
Large blocksizes favor sequential processing and DASD space
utilizatien. Cn the other hand, if you are primarily precessing
directl1, you should determine the segments needed per data base
racord ~er transaction.
Easic recommendations fer the ~ractical .inimum CI/tlocksize for ESDS
and OSAM data set~ are given fcr each device type in Figure 2-48. The
underlined numbers would be a general "best fit" for as/VS1. the
numbers tetwEen ~arEnthesis veuld be the general "best fit" for OS/VS2.
r-----------------------------------------------------------,
']~~i£~_Ilf~
I
Q~A~_§12~~§i!~_QI_!~!~_~§Q~_~!§!~~
I
1
,
(blocks/track)
1-----------------------------------------------------------1
1 2314/231 S
t
15::6
,
~
(~~~~)
,
t
('4)
,
1
(7)
1
'(~)
I
(3)
t-----------------------------------------------------------1
I
3330
I
15::6
(U096)
1
~~~.§
(6)
(3)
1
(2)
t
t-----------------------------------------------------------,
,
3340
I
1526
(4096)
,
~2§~
(3)
t-----------------------------------------------------------1
,
3350
,
I
(~Q2§J
I '
4
I
1---------------------------------------------------------I
,
OS/VS1 REccmlEndatien
,
RR~~:
I (nnnn): OS/VS2 Recommendation
,
I Blocksizes 1536 and 2560 are only applieatle to OSAM
,
1
,
L---------------------------·---·-------~-------------------~
FigurE 2-48. F€cemlended CI/Elocksize Parameters
Additienal considerations:
•
In caSE of lar9E data tasE recerds (greater than 500 bytes) and/or
~equential precessing .and/or large data bases, you should
censider increasing the sizes shown in figure 2-48, especially fer
~Eavy
OS/VS1.
•
For OSA~, the blocksize is limited to the maximum non-keyed
tlocksize of a track.
POI KSDS, for INtEX data tas~s, you should select a control interval
size of 2048 or 4096 for the data component and 1024 for thE index
component.
Data Base Design
2.83
The following tasic guidElines apply tc above
base:
1.
SIZE
2.
EYTES
3.
RBN
q.
ANCH
=
for a HtAM data
5) AVBI
=
=
parameter~
SIZE
,.~~
=
J
NBOO'IS
1.25 J
X
AVEL/SIZE
JFCCTS/FEN
Where:
----~
•
AVEL is the average data tase record length, including
prefixes.
•
SIzt is the net CI/blocksize.
Remember that DL/I will allocate some
centrel fields \ithin your selected CI/block. These are~
Free space ancher
~cint:
For Each ancbcr pcint:
area)
"SAM
control fields
segm~nt
4 bJtes
4
bytes (only in the root addressable
(ESDS):
7
kytes
In additicn, thete will be a free space element of 8 bytes for each
consecutive tree space of E bytes cr more in the CI/block.
•
BYTES is the maximum number of bytes of a single data base record,
to be inserted by consecutive insert calls ag~inst the same PCB.
•
ANCH is the numker ef rcct anchor peints per CI/block (round to next
highe r) •
•
RBN is the number of eI/blocks in the root addressatle area.
Ideally, 4 to 5 data base records should fit in one CI/block. However,
for very largE data basE records -- one average record per N CI/blocks
-- you should consider a randomizing algorithm, which skips Every N
CI/tlocks. The BY'IES FarametEr should then be no less than the average
data base record size and the number of anchor points per CI/tlock
should be onE.
For our PARTS data tase, we calculate (assume 10,000 records):
AVEL
=
(10,000X98+40,000146+2,000166+3,000X82)/10, 000
= 320 tytEs
The maximum data base record length is:
Se+20t46+4X66+82 = 1364 bytes.
And the minimum data baSE
98 bytes.
2.84
IMS/VS Primer
reco~d
length is:
The data and prefix length of each segment can be found in the DBDGEN
macrc expansion output listing_ !he field "SEG"EN~ LENGTH" contains the
data length of the segment in bytes. The field "LENGTH OF SEGMEdT
PREFIX" contaitis thE length in ~Jtes of the segment prefix.
SIZE
5 X 320
E!Y!ES
=
1600, rcunded to 2048
= 2048
Because our aaximom data base record size is 1364 bytes, this could be
specified as the BY~ES limit.
BBN
=
1.25 X 10,COO X
=
3~C/~C4e
1954
For 3330, this vocld require 326 tracks or 18 cylinders. An initial
space allocation of 20 cJlir.de~s ('O~ for the ovsrflow area) will ce
appropr iat e.
ANCH
=
1.25 X
1C,OOO/19~q
=
6
We nov check our net CI/block size in the root addressable area, which
is:
2048
4
- 4 X 6
=
~c~c
~his is large enough to hold, generally, more than five data baSE
records.
I!!ining_l~!~_~!!!_~~!~
VSAM data spacEs arE dEfinEd with its Access Method Services. Job
/ISAMP270 in IMSVS.PBIP!EJOB shows hcw to do this for a HDAM IPABTS) data
base and a HIDAP! (Customer Order) data base. Note that the DATA and
INDEX components are separately named.
WheneVEr defining a KStS, ycu should check the DBDGEN output listing.,
It gives the proFer access method service control statements for the
definition of the KSDS (that is, the location of the key in the 'KSDS
record) •
!21i:
Job IISAMP~7C dEfines the VSAM data sets in the
defined with job IISAKPOOi.
VSA~
data space
OSAP! space can hE allocatEd via normal Jel as an OS/VS sequential data
set. No DeB information should be provided in the JCL. OSAM space can
be reused but only if the tlc~ksize (SIZE Farameter in DBt) has not tEEn
changed, that is, the same as indicated in the DSCB on DASD.
Job IISAMP170 in I~SiSdFBIr.!JCE, which loads the Pbase 1 PARTS data tase
shows how to allccate the s~acE fel the OSAM d~tasp.t.
ih~§~_~_R~I§i~~1_~!!s_~!§§_~§si3~
The Phase 2 application data structure in Figure 2-43 can be easily
implemented with the use of the logical relationship function of DL/I.
Merely define the crderline seglEnt as a logical child of the part
Data Base Design
2.85
segment as shcwn in Figure 2-43.
considerations aEFly:
In addition the following
•
The physical data base design for the Parts and Customer Crders data
bases is dcne in much the same way as for phase 1.
•
ThE accESS methed fcr the CUSTOMER CEDER data base is HIDAM/VSAM.
This is done tc'sbew an examEle of a HIDAM data base.
•
The access method for the PARTS data base is changed to HDAM/VSAM to
provide a V3AM cnly environment.
•
As discussed prEviously, we viII use a separate SHISAM data base for
the customer name and address instead of duplicating that data in
the Customer Order data base. The key (customer number) of this
SHISAM data baSE will be stered in the root segment of the Customer
Order data base.
Notes:
-.--~
,.
the real logical child can, in reality, be located either in thE
Parts or the CustclEr CIders data base. Their is no difference for
the application Ercgram as to where it is located (except for the
initial lcad program~. Which implementation to choose is purely a
performance matter. This viII be discussed in Chapter 9,
"Optimization," under the topic "Optimizing Physical and logical
7vin Cbains."
2.
Whenever the accounts receivable application is converted to DL/I,
the SHISA~ data base could be converted to a ~ull HDA~ cr HltAM data
baSE. Additional segments can then te added with minimal impact on
the Existing DL/I a~~licaticn programs. Also, if necessary, a
logical relationship could be implemented between this Customer data
base and the CustcmEr Orders data base, much in the same way as
between the Parts and the Customer Orders data case.
Two sets cf tEDs arE DEEded for the phase 2 applications:
•
Physical tBDs with lcgical relationships, and
•
Logical tEts for the
ap~lication
~rograms.
The DBDGE~ process of these DBDs is described under the topic "DEDGEN
for Logical Data Bases" earlier in this chapter. The physical DBDs for
the Parts and Custcler Orders data b~ses are shewn in Figure 2-24.
Due to expected high activity against the logical child s~gment all
associated pointers are specified forward and backward~ This shculd he
done in all cases where there is considerable activity expected with a
logical child.
!he corresponding lcgical
Pa~ts
DBD (EE2LPART) is listed in Figure 2-25.
The logical customer Orders data base is listed in Figure 2-26.
All above DBDs, together with the SHISAM DBD (BE2PCUST) are also
included in IeSVS.PEI~ESEC. Their tBDGINs can .te executed with jcb
IISAftP210 in IMSVS.PBIMEJOB.
~h~j!_~ fh~ji£~l ~~l! ~!§! ~!§!gn
In our Phase 3 sample data tasE design, we will use the secondary index
fUDction cf Dt/I.
Analvzing our Phase 3 requirements as reflected in its transaction/ data
element matrix (Figure ~-4') and aFFlicaticn data structure {Figure
2-44), we see the need for the access of the parts data via purchaSE
order number.
Actually, the best ~aJ, from a pure data base design point of view~ is
to ilplement this via a logical relationship. This logical IelationshiF
should then be established tetween a new Purchase Orders data base and
the Parts data base. Eowever, we choose to use the secondary index
function for this with the fcllcwing ccnsiderations:
•
ExemFlify the difference between the logical relationship and
seccndary index functions.
•
Adding of the s~ccndary index to the PARTS data base has the least
impact on the existing PhasE 1 and Phase 2 application programs.
•
If there is no expected €1tension of the purchase order application,
it might also, in a real live situation, be the mo~t econoroical(
solution.
Furthermere, ~e ~ill select the parts segment as the index target
segment. ~his is according to the limitations of our sutset as set
before (that is, target=rect segment). In this way, the Phase ~
requirements can ce very easily implemented, especially by the
application programs.
Above discussions are reflected in our Phase 3 DBDS:
EE3PAE~S
•
!he physical Farts data base
•
!he physical Customer Crders data base EE20RDER and its primary
index BE30RtRX
•
The secondary index DBD
BE~PSID1
These DBDs are all included in IMSVS.PEIMESBC. Their DBDGENs can he
performed with jct //SAMF310 in IMSV5.PRIMEJOB. The DEts for BE3PAR~S
and EE3PSlt1 are shown in FigurE 2-29 under the topic "DEDGEN For
Seccnda~y
Indexes".
~Q1~:
!he phase 3 apFlicaticD program PE3CFPUR
references the Fhase 3 physical DEts. Ideally,
PhaSE 3 la9ical PARTS data basE BE3LPAR~. ~his
for Phase 2. It is suggested that you exercise
uses a PSB which
this PSB should use a
DBD is much the same as
this change yourself.
DESIGN EVALOA!ION
Following th~ physical data hasE design, a design evaluation should be
Ferformed. The t~o main questions for this evaluation are:
•
Does the data base design support the applications functional
requirements?
•
Does the data base design provide for a satisfactory performance?
The first question is not considered here, tecause it is toe aFFlicatien
and installation dEpendent. the second question's answer is also
largely installation dependent. Hcwever, Chapter 9. "Cptimization.~
Frovid~s yc~ ~ith a simple hand calculation technique to compare
alternatiVE designs. In addition, a checklist is included which
addresses the most important performance factors for Dt/1 data tases.
Data Base Design
2.S7
This chapter is complementary to the previous chapter on data base
desigr. It provides the data communication designer and systp.m analyst
with a detailed description of the IMS/VS data communication functicns,
and guidelines on how to use these functions.
The three main parts in this chapter are:
•
description of a~
application is used
online system_ ~he
in the remainder of
•
A more formal description cf the IMS/VS data communication
including the specification of IMS/VS message format
service usage.
A
online application sample. The sample
to demcDstrate the general requirements of an
sample application is used also in the examples
the chapter.
fun~tions,
•
An extension of the data base design process of the previous cha~ter
into the data communlcaticn area. Besides consideratio,ns for online
data base design, this part provides guidelines for online
application program design and message format design.
The basic requirement of phase 4 of our sample environment is to run the
phase 3 (see Chapter 2) sample applications in an online environment.
PHASE
4
SAMPLE
DA!A
BASES
The phase 4 sample data base requirements aIe in general the same as for
~hase 3.
The only added requirement is that they should be accessible
online. As we will see, this usually will not require any changE in the
data base design. In the sample online system we will use the phase 3
data bases.
PHASE 4 BA!CH tRCGEAMS
In phase 4 of our sample system, both the Inventory Report Processing
apd the Purchase Order Processing vill remain batch applications. We
will show in the sample system how the pre-phase 4 programs of tbese
applications can be executed with the online data bases without any
modifications to the programs.
PHASE 4 ONLINE PROGRAMS
!he essential re~uirement for phase 4 is to perform the Customer Order
Processing as an cnline a~Flication, using IMS/VS data base/data
communication facilities. All the transactions defined in phase 2 (see
"Sample Application for Phase 2" in Chapter 2) should te availatle via
the 3270 InforIDation Display System. In addition a simple online
customer name and address inquiry application will be implemented.
Data Communication Design
3.1
I§~L!~_Q!I!_£Q§~Q~I~!!I£!_!!£111!1~2
In the. following sections, we will discuss the I!S/VS data communication
facilities within our subset. It is assumed that you have a clear
understanding of the concepts and terminology as presented in Cha~ters
and 2.
To explain toe I65/V5 data communication facilities, we will follow a
message through the system.
~HE
MESSAGE
The goal of 165/VS is tc Ferfors online transaction processing.
consists of:
This
1.
Receiving a request
a remote tErminal.
which identifies to
which·is to be used
for work to be done. The request is entered at
It is usually made up of a transaction code
IMS/VS the kind of work to be done and some data
in doing the work~
2.
Initiating and controlling a specific program which will use the
data in the request' to do the work the remcte operato~ asked to be
dnne, and to prepare some data for the remote operator in resp~nse
to the request for work (for example, acknowledgment of work done,
answer to a guery, etc.).
3~
Transmissicn of the data prepared by the program back to the
terminal originally requesting the work.
The above sequence is the sim~lest form of a ~~!n§!£~!2~. It involves
two ~~§§§g~§: an input message from the remote operator requesting that
work be done, and an output message to the remote operator containing
results or acknowledgement of the work done.
A !~§§!g!, in the most general sense, is a sequence of transmitted
symbols~
In the context of IMS/VS, this is called a transmission.
transmission may have one or mere ~~§§!g!§, and a message may have
or more §~g!!nl§. A segment is defined by an end-of-segment (ECS)
A
one
symbol. a message is defined by an end-of-message (ECM) symbol and a
is defined by an end-of-data {EOD) symbol. The valid
combinations of the conditicns Lepresented by EOS, EC~, and ~CD are:
~ransmission
lOS
EOK
rot
EOS
ECS/ECM
EOS/EOM/EOD
relations between transmission, message and segment is shewn in
Figure 3-1.
~he
3.2
IMS/VS Primer
e e e
8
\0",
#,
'V'
#~
V"
SEGMENT
,1\
va
SEGMENT
SEGMENT
SEGMENT
'=
8
MESSAGE
va
MESSAGE
A
SEGMENT
V-
¢I
MESSAGE
.I
"
V"
TRANSMISSION
Figure 3-1.
Tra nEmi ssion. Message, and segment Relations
The character values or conditions that represent the end of segment
and/or me~sage are dependent cn the terminal type.
In cur subset, 321C terminals only, the physical terminal input will
always be a single segment message and transmission. The EOS, EOM and
Eor condition will all be set after the enter or program function key is
~ressed and the data is transmitted.
On the output side, a message can be divided into
lulti~le SEgments.
Also an applicaticn ~rogral caD send different messages to different
terminals, that is, a message to a printer terminal and a message to the
input display terminal. Each segment requires a separate insert call ty
the afflicaticn ~rogram.
The format of a message seg~ent as Fresented to or received from an
application ~rogram is shown ir. Figure 3-2.
2
2
LL
zz
LL
ZZ
:
DA'1A :
total length of segment in bytes including
the LL + 2Z fields.
IMS/VS syste~ fields
application data
Figure 3-2.
A Message Segment.
IMS/VS ONLINE OPIEATICN:
CVE~VIEW
As introduced in Chapter 1, IMS/VS online proc~~sing is done with three
different types of regions, address spaces, or partitions under CS/VS:
•
~he £2~!12! (£I1) ,~gi2n contains the IMS/VS centrol program.
controls the terminals and data bases.
•
!he !~§§~g~ E~2£~2§i~g (~!£) £~i2~ contains a user program fot
message-driven processing of the data bases. The MPP region is
ccntrolled tJ and telies uFcn the C~L tegion. The application
Ftcgram ~hich execute in the MPF region is called a ~§§!g§
EI2£!§§in9 E~29I~! 2! ~f!. Different KPPs can be subsequently
loadEd and activatEd in a single ~pp region.
Data Communication Design
It
3.3
•
The
~!I~~ !§§~!£! ~~2~j§§~ng
~IogIam
r~gion.
(§~R) .igi2n contains an application
fot batch process1ng of the data bases managed by the CTL
Application programs executing in a BMP region are called
~!!~h ~§§§!S! RI~&!~§jD9 RIS9;~!§ Ot ~~f§·
Figure 3-3 giVES an overview of these 3 region types and the control and
data flow within them.
MPP
CTL
.f - - - - - - - - - - - - - - -- - -- • - - -OSIVS- ,...-
t
"""
..... -",,~
LOG
TAPE
CONTROL
t
LOGGING
~~ - - - -LOG
CHECKPi
RESTART
DYNAMII..
LOG
-
•
I:
SCHEDULING
I
I
DB C H A N G E S -
BUFFERS
§
¥
/'00'":""
I
I
PROGRAM
BUF
~-----:-
ISOLATION
-----
A
f-----------'
DATA
COMMUNICATION
~
- - ---
I
I
-
DL/I
I
"."..
MFS
/
I
- - •
- - - - - - - -
I I
CON!ROL
-1
,
'-
--.
e-
.
DC
PCB
MESSAGE
APPLICATION
PROGRAM
BATCH
APPLICATION
PROGRAM
MSG CALL
I--DB
PCB
r;. - ---~
QUEUE
MANAGEMENT
DB CALL
-+
DB CALL
DBD
·I.I.TRAN~~
GSAMCALL
DC
BUFFER
MFS
Pj)OL
+
DB
POOL
QPOOL
GSAM
~
...
"""-""
FORMAT
LIBRARY
.....
Figure 3-3.
-
I
CON;ROL
t
I
. . CHECK
/
--
,
t
H
RESTART
DATA SET
- -.- - - - - -
BMP
+
I
i..
--'--
~
~
MSG
QUEUE
DATA
BASES
OSIVS
FILES
-
-
....
-
,
D
lbe IMS/VS Regions and Their Control/Data Flow.
the CtL region is initiated through an OS/VS start command. The
terminals, data bases, and the leg tape are all attached to this region.
A type 2 supervisor call routine is used for switching control
information, messagE and data base data to the MPP/BMP region and back.
The CTL regi~n normally runs as a system task and uses CS/VS access
methods fer terminal and data base access.
Once the CtL rEgion is started, its general data flow is as follows.
See F·igure 3- 3.
1.
The input data from the terminal is read by the data communication
modules. After editing by message format service (HF51, this input
data is put in the iD~ut queue (tRAN). which is sequenced by
transactien code.
2.
~he
3.4
scheduling modules will start the processing of a transaction in
an MPP if an HPP is free and other conditions are met.
IMS/VS Frimer
3.
UFon Iequest from an MPP/BMP. the DL/I modules pass a message or
data base segmgnt to or from the KPP/EKF.
"'5,
!Qi~:
In
the DL/I modules, control blocks, ~nd pools reside in
the common storage area (CsA) and the CTL region is not needed for
most tE processing.
4.
The message output from the MPP is put in the output message queue
Il~F.RM), whi~h is sequenced by logical terminal name.
S.
The communication modulES retrieve the message from the output queue
and send it to the output terminal. MFS is used to edit the screen
and printer output.
6.
All changES tc the message queues and the data bases are recorded on
the log tape. ~n aodition, checkpoints for system (emergency)
restart and statistical information are logged.
1.
,.
lhe physical logging modules run as a separate task and use
Os/Vs ESTAE for maximum integrity.
2.
The checkpoint id~ntification and the log tape volume serial
numbers are recorded in the restart data set.
Program Isolation assures
"PPs/E~Ps update the same
dat~ base changes made by
maintaining a short-terl,
data base integrity when two or more
data base. It also backs out (undoes)
failing programs~ This is done by
dynamic log of the old data base element
images~
8.
The control module provides multi-tasking for the abOVe activities.
These separate functions, that is, input processing, queueing, ~FF
processing, data base call processing, output processing, etc., can
be executed asynchronously for multiple transactions. Ho~ever, they
~ill be executed in sequence for a unique transaction occurrence.
The OS/iS EVENT facility is used for 'the control of the
multi-taskin9 and input/output operations.
An MPP region is started with an IMs/VS co.mand. ~he CTL region in turn
issues an Cs/Vs command to initiate a region via Cs/Vs job aanagement.
Message prOCEssing applicaticD FIograms (MEFs) are loaded/activated in
this region as required. ~hey are scheduled by the control region. If
the application issues DL/I calls to access data bases or terminals,
these calls are processed in cr under supervision of the control region.
An MPP region must not use Cs/VS data sets because these cannot be
repositioned during emergency restart. Also, OPEN/CLOSE processing of
these data sets might cause (performance) problems.
lh!_!!~.f_~!gi2n
region may contain an application program for processing against
data baSES in the batch manner. The application Froqram in the batch
regioJ] is sche'duled by CS/VS job management, but may utiliZE the DL/J:
facility for data baSE reference. An application Frogram executed in
the BMP region can access only IMS/Vs data bases that are defined in the
IMS/VS control region.
A BMP,
Data Communication Design
3.S
BMPs can access OS/VS data sets. However, if the BMP uses the extended
checkpoint/restart facility, thes~ dat~ sets should ce defined as GSAM
data bases.
RELATIONSHIP OF DB/DC 10 DB ~STE~
In general. all the DL/I data base facilties as presented in Cha~ter 2
are ~vailatle in the IMS/VS DB/DC system. The only ex~eption is that
GSAM data raSES (and qtber OS/VS files) cannot be used by a message
processing prcgram (MPP). They can be used in a hatch message
processing program ~~P), however.
Even with an IMS/VS C!L reg10n and related MPF/BMP regions active, a
batch-only DL/I region can be executed~ This tL/l regicn prcvides ~he
same functions as the batch-only system. However, this Dl/1 region
cannot have access to data bases cor.nected to the CTl region.
It should
tberefor~ only he used fcr batch processing when ~he CTL region is not
activE, or for processing data bases that are not used by thp. online
syste m.
In our subs~t, ve viII assume that all batch processiBg while thE
region is active is done by BMPs.
C~L
TEFMINAL INPU! tA!A PROCESSING
Figure 3-4 shculd be referred to for the
follo~ing
discussicn.
DATA COMMUNICATION MODULES
TRANSACTION
RECEIVE
CODE
QUEUE
LOG
DETERMINE DESTINATION
LOGICAL
FORMAT MESSAGE
t--........... TERMINAL
/COMMAND
Figure 3-4.
Input MessagE Processing
When IMS/VS rEad~ data frcm a terminal via the telecommunication access
method, it first checks the type of input data.
3.6
IMS/VS Primer
I~Ry!_§!§§!gi_~IB~§
As
discu~~ed
in Chapter 1, the three basic types of terminal input are:
•
A £2!!!Dg, which starts with a slash (I).
•
An i~RY! !~§§!g!, to be routed to an application program fer
processing. The program destination is defined by the 1- to 8- byte
11~~§~s!i2D S~g~ included as the first part of the input.
•
A !~§§!~~ §!i!~h, to be routed to ancthet terminal. The terminal
destination is defined by the 1 to e byte .!2gi£!l: !~!:!~ng! !!.2!:E
included as the first part of the input.
I"S/VS maintains thE origin of an input-me~sage. inen a message is made
available to an application proqram, this origin is ~lso mad€ available
to that program, via its proqram communication block (PCB). This origin
is the l~g!~!l !~~!~n!l n!!~ (lTERM), which is associated with tbe
inputting physical terminal at·the time the input is received.
If more than one lTERM is defined or assigned to a physical termi~al,
they are .aintained in a historical chain; the oldest defined/assigned
first. Any input from the pbysical terminal is considered to have
originated at the first logical terminal of the chain. If, fer some
reason (such as sEcurity or a sto~~ed L!EF"), the first logical terminal
is net allowed to ~nter the message, all logical terminals on the input
chain are interrogated in chait sequence fo~ their ability to enter the
message. ~he first appropriate LTEEM found i~ used as message origin.
If no LTE}(M can tE used, the' lIessage is rejected with an error message.
The destination of the terminal input is
inFut ..
d~pendent
upon the
typ~
of
An input command goes directly to the I!S/VS co.mand processol Ecdules.
Both the messagE switch and the transaction input are stored in the
message que.ues. 7he transaction input from the 3270 displays is first
processed by !!!§~.9! ~2!!!~l !!1!.1:£! (r1FS), except when input is from a
previously cleared or unformatted screen.
Mrs provides an Extensive format service for both inpat and output
messages. It is discussed in detail later in this chapter.
Once the input i~ enqueued to its destination in the message queue, the
input processin9 is coa~l~td.
"ESSIG! QUEUEING
All input and output messagEs in I"5/YS (except command input; are
queued in message gueues. See Figure 3-5.
With thi~ approach, in~ut ~rocessing, outp~t processing, command
processing, and applicati"cn ~rcgram processing can, to a large extent,
be performed asynchronously. This means, for example, that th~ input
processing Of messa~e A can be done in parallel with the data base
processing for message E and the output processing for lessage C. A, B,
and C can be uifferent occurrences of the same ot different message
types and/or transaction codes.
Data Communicatiun Design
3.7
QUEUE MANAGEMENT MODULES
QPOOL
DATA
COMMUNICATION
TRANSACTION
CODES
OSAM
DATA SETS
LTERMS
Figure 3-5.
Message Queueing.
The message queues are sEquenced by destination.
A destination can be:
•
A message processing program (MPY), that is, for transaction inFut.
Ordering is by transaction code.
•
A logical terminal (LTEBK), that is, for a message switch, command
responses, and output generated by application programs.
~he message queues are maintained in main storage (QfOOl), with cverflow
data sets cn direct access storage, the queue data sets. The queue
blccks in main storage and on direct access storage are reusable. This
helps to minimize the number of 110s op@.rations required during
processing.
Eecause we will consider only 327C terminals in a mostly interactive
envircnment, message queueing will be primarily in main storage.
Chapter 7 contain~ detailed guidelines for selecting messagE queue
parameters such as tlcck sizes, QPCOl size, queue data set allocation,
etc.
Once an input message is available in the message queue, it is eligible
for scheduling. Scheduling is the routing of a message in the input
queue to its corresponding application program in the message frccessing
partition/regicn. See Figure 3-6.
3u8
IMS/VS Frimer
IF: INPUT MESSAGE
+ FREE MPP REGION
~----~----------------~
LINKAGE
DEFINED
AT SYSTEM
GENERATION
DBD
+ AVAILABLE
DATA BASE RESOURCES
DBD
DBD
THEN: SCHEDULE MPP
NOTE: MULTIPLE TRANS·CODES PER PROGRAM ARE POSSIBLE
Figure 3-6.
MessagE Scheduling.
The linkage t~tween an input message (defined by its transaction code)
and an applicaticn program (defined by its name) is estatlished at
systEm definition time. Multifle transacticn codes can be linked to a
single applicatien program, but only one applicat{on program can bE
linked to a transacticn cede.
In o~r subset we will limit outselves to a simple, straightforward
scheduling algorithm. In principle, it will be FIFO (first in, first
out) scheduling with DC FaIticular priority mechanism.
Note:
This scheduling mechanism is a general "best-fit" for an initial
installation. ~his will no~ prohibit the introduction of more
sophisticated algorithms later. To do so would require changES cnly tc
IHS/VS parameters and would te transparent tc the application programs.
IMsjvs
~£~~~yling_~2n£i!igD§
ThE following conditions must te met for a successful scheduling:
1.
An MPP region must be available. Actually, the termination of an
MPP triggers the scheduling process.
2.
There must be a transaction input message in the queue.
3.
The transaction and its program are not in a stopped state.
4.
Enough tuffer pool stcIage is available to load the program
sfecification block (PSB) and the referenced data base control
blocks if not already in .ain storage.
5.
~h€
data baSE prccessing intEnt does not conflict with an alrEady
actiVE application ptogr~m (a BMP for instancp.). Processing intent
is diecussed in more detail in the following section on data baSE
procEssing intent.
tata Communication Design
3.9
If the first transaction code with ~ ready input message does not meet
all the above conditions, the next available input transacticn is
interrogated, and sc fcr~h. If no message can be scheduled, the
scheduling process is stopped until another input messagE is enqueued.
If the scheduling is successful, the I~S/VS routines in the dependent
region load the corresponding MPP and pass control to it.
A EMF is initiat.ed in an as/,s partiticn/region via regular CS/VS job
management. However, during its initialization the IMS/VS schedul~r in
the control region is invcked to assore the availability of the data
base resources for the ~P.fq
A factor that significantly influences the scheduling proc~ss is the
intent of an apFlicaticn Frcgram toward the data bases it uses. Intent
is determined by examining the intent list associated with the ESE to be
scheduled. At initial selection, this Frocess involves bringing the
intent list into thE centrcl region. ~he location of the intent list is
maintained in the FSB directory. If the analysis of the intEnt list
indicates a conflict in data base usage ~ith a currently active program
in a MPP or B~P region, the scheduling process will select another
tr~nsaction and try again.
The data base intent of a program at scheduling time is determined via
the PEOCCP!= ~arameters in the ESB.
With the program isclaticn feature (see the next section),
minimizes possitle conflicts during scheduling.
I~S/VS
A ccnflicting situatiJD during scheduling will only occur if a $egment
type is decl::t red 1!!£!1.§~!~ .!!§~ (FROCOPT=E) by the program being
scheduled and an ~IIeady active Fregram references the segment in its
PSE (any PROCOPT) or ViCE VErsa.
~Jg~Rl~:
If a EMF is executing with a defined PROCOPT=E for the CUSTOMER
CRDERS root segment (see Figure 2-12), then no MEP that references the
same segment will be sch~duled_ That is, if the MPP to te scbeduled may
reference the logical PARTS data base (Figure 2-14) and its ESB contains
a SENSEG statement for the concatenated segment, it will not be
scheduled befere the above mentioned BMP has ended. Note: A ESE that
contains a peE for a SHISAM segment that has delete sensItivity will be
scheduled exclusively. This is because the method used by IMS/VS to
ensure program isolation cannot be used for SHISA~ deletes. Since there
is no delete flag, a VSI~ erase must be d~ne to delete the segm~nt, and
since IM~/VS uses relative byte addresses as th~ identification of a
segmen~, there is no way to prevent anotber ussr from inserting a
segment with the sare key Frier to the time the program which did the
delete reaches a sync point.
APPLICA1ICN EECGRAM PBCC!SSING
Once an application progIam is scheduled in a dependent region, it is
lcaded into that region by IMS/VS.
~RLR;:2£!~.§ing
After the load of the MPP, it is given control. The normal processing
of an "fE are described belOW and in Figure 3-7.
ste~s
3. 10
I~S/VS
Primer
MSG/BMP
CTL
PROGRAM
".
DL/I
...
DC
PCB
,
,
-'--
T
R
A
N
i-
DBD
T
,~
---
~
ISRT DC-PCB
SEND REPLY
1
GO BACK
GU DB PCB
ISRT DB PCB
-
DATA
BASES
MSG
QUEUE
Figure 3-1.
~
ACCESS DB
GU DC-PCB
GN DC-PCB
........
-""
fI""
,...",
~
"-
~
GET MESSAGE
JI'
.....
to...
...
....
DB
POOL
QPOOL
,
--
DB
PCB
,w
-LT
E
R
-..
"-
-'
-'
Easic MFP Flew
1"
Retrieve the input message via a DL/I message call.
2"
Check the input message for syntax errors.
3.
Process the input
accesses.
4u
Send output to the originating and/or other (for example, printer)
logical terminals via DL/I messagE calls.
s.
Petrieve the
~ex~
~essage.
£equesting necessary DL/I data base
input message or terminate.
The program specification tlcck (PSB) for an MFP or a E~F contains,
besides data base PCBs, one or more PCB(s) for logical terminal linkage.
The very first PCB always identifies the originating logical te~minal.
This PCB must be referenced in the get nnigue and get next messagE
calls. It must also be used when inserting output messages to that
LTEBM. In additicn, one or more alternatE output PCBs can be defined.
Their LTER!! destinations can be defined in the PCBs or set dynamically
with change destination calls.
Data Communication Design
3.11
~~Ll_~~§2~g§_£2!!2
~he
same DL/I language interface which is used
bases is used to access the ~essage queues.
to~
the access of data
The principal DL/l message call function codes are:
•
GU, get unique. This call must be used to retrieve the
only, segmEnt of the input message.
•
GN, get next. ~his call must be used to retrieve second and
subsequent message segments.
•
ISR!, insert.
s€gment into
~his
call must be used to
messagE q~eue.
inser~
£ir~t,
er
ar. output m~scagE
tbe·out~ut
Note: These output m~ssage(s) will not be sent until the MII
terminates or requests another input message via a get unique.
•
change destination. This call can be used to S€t the output
destinaticL for suhsequent insert calls.
CHNG~
For a detailed description.of the DL/! message calls and guidelines for
their use, see Chapter 4, "Data Ease Processing."
fI2g'~!_!~Q!~!~Qn_~n~_Qln~!!£-1Qgg!ng
When processing DL/I data base calls, the IMS/VS program isclaticn
function will ensure data base integrity.
With Frogram isolation, all activity (data base modifications and
message creation) of an application program is isolated from any ether
applicaticn program,s) running in the system until that application
program commits, by reaching a ~Iu£hrQni!2ti2~ E2in1, that the data it
has modified e~ created is valid. A synchronization point in our subset
is established with a get uni~ue for a new input message and/or a
checkpoint call (BMP only), cr program normal termination (GCEACK or
EE'IURN) ..
Program isolation allows two or ~ore application Frograms to
concurrently execute with common data segment types even when Frocessing
intent is segment u~date, add, or delete.
This is done ty a dynamic er.queue/dequeue routine which enqueues the
affected data base elements (segments, pointers, free spac~ elements,
etc.) tetween synchronizaticn peints.
At the same time, the dynamic leg modules log the prior data base record
iaages bet~een those synchronization points.
~his makes it possible te dynamically back out the effects of an
application program that teIlinates abnormally, without affecting the
integrity of the data bases controlled by IMS/VS. It does not affect
the activity of other applicatien program(s) running concurrently in the
system.
With program isolation and dynamic backout, it is possible tc pcovide
data base segment occurrence level contrel to application programs. A
means is provided for r~solying possible deadlock situations in a manner
transparent tc the applicaticn ~roqIam.
3. 12
IMS/VS Primer
~e
example of a deadlock occurs in thE following sequence of events:
1a
Program A updates data tasE element
2.
Program E updates data baSE element Y.
3.
Prog~am A requests Y and aust wait for the synchronization point of
program B.
4q
Program E in tarn ~eguests X and must wait for the synchronization
Feint of prooral A.
x.
A deadlocK has now occurred: both programs are waiting for each other's
synchronization point. The dynamic enqueue/dequeue routines of IMS/VS
intercept possible deadlocks during enqueue processing (in above example
during enqueue FIocessing of event 4).
Upon detecting a dead1cck situation, one of the application Frog~ams
involved in the deadlock is abnc~mally terlinated (pseudo abend). The
activity of the terminated program viII be dynamically tacked out to a
previous synchronization Feint. Its held resour~es are freed. ~his
allows the othe~ program(s) to process to completi~n. The transaction
tbat was being processed by the abnormal terminated program will be
saved. The ~pplicaticb ~rogram is rescheduled if it was an "FF. For a
BMP region, the job must be restarted. This prQcess is transpar~nt to
application Frqg~ams and terminal 0Ferators.
There arq two situations where th~ enqaeue/dequeue routines of program
isolaticn are not used ir processing a data base call:
1.
If PROCOE~=GC tread only) is sFecified for the referenced segment(s)
of the call.
2.
If PROCCPT=E (exclusive) is specified for the referenced segment(s)
in the call.
NotiCE that possitle ccnflicts with exclusive extent are resolved during
sch~dulin9 time and as sucb cannot occur at call time.
1.
With th~ GO option, a program can retrieve data which has teen
altered or modified ty anct~er program still active in another
regicn, and data base chanqes made by that program are subject to
teing tacked out.
2.
Exclus~ve
3.
Even when PROCOP!=I is specified, dynamic logging will be done for
data base changes. The ultimate way to limit the length of the
dynamic log chain in a B~P is by using the XRST/CHKP calls. The
chain is deleted at each CH~E call because it constitutes a
syncbronizati~n peint.
4.
If, as can occu~ in our subset, one MPP and one ~ME g9t involved in
a deadlock situation, the tEE vill be subj~ct to the atnorlal
termination, tack cut a~d reschedule frccess.
intent may be required for long-running EMP progIams that
do not issue checkpoint calls. Otherwise, an Excessively large
enqueue/dequeue tatle in main storage may result.
Data Communication Design
3.13
Upon abnormal t~rminaticn of a message or batch-message precEssing
applicatien prcgram for cther reasons than deadlock resolution, internal
commands are issued to prevent rescheduling. These commands are the
equivalent of a ISTOP ccmmand. they p~event continued use of the
~rogram and the transaction cods in process at the time of atnor!al
termination. the master teIminal opexater can restart either or hoth
stopped Iesources. At the time abnormal termination oc~urs, a message
is issued to the master terminal and to the input terminal that
identifies the application program, transaction cod~, and input
terminal. It also contains the system and user completion codes. In
addition~ the first segment of the input transaction, in precess by the
a?plica~ion at abnormal termination, is displayed on the master
terminal. The data basE changes of a failing program are dynamically
backed-out. Also, its output messagEs inserted in the messagE queue
since the last syncbroni2aticn Faint are cancelled.
~2n!!Iis!.i2l!s.!_fI£~!§§!].9
transaction code can te defined as belonging to a conversational
transaction during IMS/VS system definition. If so, an application
program that processes that transaction, can interrelate messages from a
given terminal. The vehicle to accomplish this is the §~~!!~}E!~ ~'!~
(SPA). A unique scratch~ad area is created for each physical terminal
which starts a conversational transaction. Each time an input message
is entered from a physical terminal in conversational mode, its SPA is
presented to the ap~licaticn ~rcgram as the first message segment (the
actual input being the second segment)Q Eefore terminating or
retrieving another message (frcm another terminal), the program m~st
return the SPA 'to the control region with a message ISRT call. The
first time a SPA is presented to the application program when a
conversational transaction is started from a terminal, IMS/VS will
format the SPA ~ith binary zero's (X'OO'). If the program wishes to
termi.nate the conversation, it can indicate this by inserting the SPA
vith a blank transacticn code.
~
OUTPUT MESSAGE PROCESSING
As soon as an application reaches a synchronization ~oint, its output
messages in the message queue become eligible for output processing. A
synchronization point is reached whenever the application program
terminates or requ~sts a new message/SPA from the input queue via a GU
call.
In general, output messages are processed by message format service
before they are transmitted via the telecommunications access m~thodo
Different outpot queues can exist for a given LTERM, dependin9 on the
message origin. ~hey are, in transmissicn priority:
1.
Response messages, that is, messages generated as a direct response
(same PCe) to an input message from this terminal.
2.
Command responses.
3.
Alternate outpot messa9.es, that is, messages generated via an
alternate Fee.
The printi n 9 of "DFS059 TERMINAL STARTED" messages on the 3~70
printer terminals viII te sUFpressed in cur subset. This is done to
Frotect preprinted forms.
!2~§:
3.14
IMS/VS Primer
LOGGING AND CHECRECIN7/RES1ABT
To ensure the integrity of its data bases ~nd message processing, I~S/VS
uses l09ging and ChEck~oint/restart. In case of system failure, either
software or hard~are, IKS/VS can te restarted. this restart includes
the repositioning of ~sers' terminals, transactions, and data tases~
During IMS/VS execution all information n~cessary to restart thE system
in the event of harawaIe cr scftvare failure~ is recorded on a system
log data set. !n our suhset, this log data set must be on a magnetic
t ap..e unit.
The following critical systEm infcrmation is recorded on the log tape
(see Figure 3-8):
•
!he receipt of an input message in the input queue
•
Ibe start of an
•
The receipt of a mEssagE by tne MPP fer processing
•
Before and after images of data base updates by the MPP/BMI
•
!he insert of a message into the queue by the MPP
•
~he
•
The successful reCEipt of an output message by the terminal
~PE/Bef
terminaticn of an
~PF/EMF
In addition to the abovp. togging, all previous data base record images
written to a separate dynamic lqg. This log information is only
used for dynamic tack-cut frccessing of a failing ~PP/B~P. As soon as
the MPP/BMP reaches a synchronization point, the dynamic log infcrmaticn
of this program is discarded.
~re
At regular intervals .during IMS/VS execution, checkpoints are written to
the log tape. this is to limit the amount of reprocessing required in
the case of Emergency restart. ! checkpoint is taken after a specified
number of log records are written to the log tape or after a checkp~int
command. A special CbEck~cint cc~mand is a1ailable to stop IMS/VS in an
orderly ma nner.
A special disk restart data set is used to record thE! checkpoint
identification and log ta~E volume serial numbers. This restart data
set (IMSVS.RDS) is used during restart for the selection of the correct
restart checkpoint and restart log tape(s).
Note:
Although IMS/VS its~lf Frovides for full disk logging/restart
the IMSVS.RDS data set, this function is not included in our
subset.
vith
£21g
.§!!~!
An IMS/VS C~L region cold start is done at the first time you start the
system. During cold start, we format (initialize) the message queue,
dynamic log and restart data sets.
Data Communication Dp.sign
3.15
'MPP'
'BMP'
PERMANENT
OLD
SEG
OLD
SEG
OLD
SEG
OLD
SEG
OLD
SEG
DYNAMIC LOG
RETAINED UNTIL SYCHRONIZATION POINT
USED FOR DYNAMIC BACKOUT IF PGM ABENDS
DB UPDATE
MSG
0'0
FigurE 3-S.
PGM
START
MSG
GU
OLD I NEW
MSG
ISRT
PGM
END
IMS
CHKPT
MSG
DEQ'D
IM5/VS Logging
l!§Igjn~l_B~§!~~!
In case of failure, IMS/VS is restarted ~ith the log tape active at the
time of f~ilure. Festart processing will back-out the data base changes
of incomplete MPPs and BMPs. ~he output messages inserted by these
incompl~te MPFs ~ill be deleted.
After back-out, the input messages are re-enqueued, the MPPs restarted
and the pending output ~essa9Es are (re) transmitted. If a,Ep.F vas
active at the time of failure, it must be resubmitted via as/vs job
management. If the ~MP uses the XRS!/CHKP calls, it must be restarted
frem its last successful checkpoint. In this way missing or
inconsistent output is avoided. For more details, see Chapter 8,
"0 pe ra ti 0 noS. tt
Normal restart or warm start is done from a previous normal
termination. the message queues are preserved in this vay.
I~S/VS
SECURITY
In our subset we will only consider password and terminal security. For
a description of these security provisions, see the "IMS/VS security
~aintenance Utility" descripticn in Chapter 7, "Installing I~S/VS."
IMS/VS itself has ~cre extensive security features for user signoD and
support of user exits and the FACF program product (OS/V52 MVS only).
for morE dEtails cn thesE additional security features, see the l~§L!§
g~n~~~l !g!Q~m~~iQ~ manual and the I]~L!§ ~~~~~~ AEB!i£~!!QU ~~§ig~
gg1:g~.
3. 16
IHS/VS Primer
The
I~S/VS
master terminal in our subset consists cf two components:
•
The primary components, d 327C Qisplay terminal of 1920 characters
(24 lines by 80 columns).
•
The secondary comFcnent, a 3270 printer terminal.
All mEssages are routed to tcth the primary and secondary components.
Special MFS support is used for the master terminal. The display screen
of the master terminal is di~ided into fOUI areas. See Figure 3-9.
MESSAGE AREA (10 lines)
~/////. BLANK ~////////////////////////////////////////////////~
COMMAND OUTPUT DISPLAY AREA (10 lines)
21
22
1'////
WARNING MESSAGE AREA (1
23 ////~USER INPUT AREA (2
lines)
line),//////////////////////
;'//////////////////////.
I'
PASSWORD
~h
24
Figure 3-9.
3270 Master Terminal Format
the message area is for I~S/VS command output (except /DISPLAY and
/RtISFLAY), messagE switch cut~ut, application program output that uses
a message output descriptor name beginning with DfSMO (see MFS), and
lMS/VS system messages.
The display area is for /DISPLAY and /RDISPlAY command output.
The varning, message arEa is for the following warning messages: ~ASTEE
LINES jilTING, MASTEB P.ESSAGE WIlTING, DISPLAY LINES WAITING, and USER
~ESSAGE WAITING.
to display these messages or lines, press PA1. An
lMS/VS password may also be entered in this area after the "PASSiCFDn
literal.
The user input arEa is for CFEratcr input •
.f~2g~!!!_!!!!!£~~2!!_!iI
11 or PA2 teguests the next output messaqe 'and
proqram function key 12 requests the Copy function if it is a rEmote
terminal.
For more details on the use of the master terminal refer to Chapter 8,
"Operations. II
Data Communication Design
3.17
IMS/VS alvays has a communication path vith the OS/VS system console.
The vrite-to-o~erator liTO) and vrite-to-operator-vith-reply (WTCE)
facilities are used for this. Whenever the l8S/1S CTL region is active,
there is an outstanding message requesting reply on the OS/VS system
console. This can be used to Enter commands for the CTl region. All
functions available to the 1"S/V5 master terminal are available to the
system console. The system console and ~aster terminal can be used
concurrentlJ, to control the system. Usually, however, the system
cohsolets primary Furpos, is as a backup to the master terminal. The
system console is defined as leS/VS line number one during syst~m
definition.
327C
RE80~E
CCE! PONCT1Cti
For remote 321' display terminals I~S/V5 provides a cupy function. By
pressing PPK1~ (PA2 orr data entry keyboard), the operator can cause the
contents of the screen to be copied to a printsr attached to the same
control unit. Whicb printer is selected is determined by terminal
status and system definition sequence. In general the first ready
terminal on the cOlltrol unit is selected. This func~ion should only be
used for occasional hard copies. For production applications it is
generally tettEr to perform Frinting unde~ application program control.
MESSAGE SWITCHING
~he basic format of a messag~ switch is the destination ITER~ name
followed by a tlanx and the lessage text. In our subset, using 3270s
an~ messagE fermat service. ve viII include a sample message switch
fcrmat. !he advantage of using the sample format, is that it
automatically provides the originating L1ERM name and location. ~hE use
of this format is discussed in detail in the I~§L!~ j~i!!~ ~!!2t~
li~!!~~l gE!I~!QI!§ ~y!gi·
!hrough the ~essage Format Service (MrS), a comprehensive facility is
pruvided for IMS/VS use~s of 3270 and other terminals/devices. MFS
allows application ~rogrammers to deal with simple logical messagES
instEad of device dependent data. This simplifies applicaticn
development. 1h~ samE aFFlicaticn Frcgram may deal with different
device types using a single set of editing logic while deviCE input and
output ar~ varied tc suit a specific device. the presentation of data
on the device or operator input may be changed without changing the
application program. Full Faging capability is ~rovided for display
devices. Ihis allo~s the application prograa to write a large amcunt of
data that viII he divided into multiple screens for display on the
terminal. The capability to page forward and backvard to differEnt
s~rEens within thE lessage is provided for the terminal operator.
7he
conceptual viev of tha formatting operations for messages ori9in~ting
from or going to an MFS-suPForted device is shown in Figure 3-10.
3.18
IMS/VS Frimer
APPLICATION
PROGRAM
MFS
DEVICE
INPUT
Figure 3-10.
jNPUT
MESSAGE
MFS
OUTPUT
MESSAGE
DEVICE
OUTPUT
~~
Message Formatting Using MFS
MFS has three major cOIoFcnents:
•
MFS language utility
•
MFE fool manager
•
Message editor
The MFS languagE utility is EXEcuted offline to generate control blocks
and place them in a fcr~at centrol block data set named IMSVS.fCFMAT.
The centrol blocks de5cribe the message formatting that is to take place
during message input or outFut cpErations. ~hey are generated according
to a set of utility control statements. There are four types of for~at
control blocks:
'.
Me.c;sage input descriptcr (MID)
•
Message output descriptor
•
Device input format
•
DEvice output format
(~Ct)
(tIl)
lDCF)
The MID and MOt tlocks relate to a~plication program input and output
message segment formats, and the tIF and DOF blocks relate to terminal
I/O formats. The MID and DIF blocks centrol the formatting of input
messages. while the MCC and DC, blocks control output message
formatting.
1.
The DIl and the DO! centrol blecks are generated as the result of
the fermat (FM!) statement.
2.
1he MIt and the MOt are generated as a
(MSG) statements.
3.
The initial formatting of a 321C display is done via the "/FCEMAT
modname" command. Th1s will format the screen with the sFEcified
MOD, as if a naIl message was sent.
Figure 3-11 Frovides an overview of the
~FS
r~sult
of different ressag€
operations.
tata Communication Design
3.19
PROVIDED
BYMFS
APPLICATION
DESIGNER
OFFLINE
EXECUTION
MESSAGE AND
FORMAT
ONLINE
EXECUTION
IMSVS.
FORMAT
MESSAGE/
FORMAT
LANGUAGE
UTILITY
CONTROL
STATEMENTS
MFS
TERMINAL
MFS
BUFFER
POOL
r
~
MFS
POOL MANAGER
MFS
MESSAGE
EDITOR
..
MESSAGE
QUEUE
Figure 3-11.
MFS AND THE
Cverview of !essage Format service
3~7C
res/vs Message Format Sarvice (MFS), descrihed in the previous section,
is always used tc format data transmitted between IMS/VS and thE devic3s
of the 327C i·nformaticn display system. MFS provides a high level of
device independence for the application programmers and a means for the
application system designer to make full usa of the 3270 device
capabilities in terminal operations. Although our sutset only censiders
the 3270, its USE of ~FS is such that it is open-ended to the use of
ether MFS supported terminals when required. See the !~§L!~ ~in!~3!
!]fo!!~l!Sn ~~nY!! for a list of these terminals.
RELATIONSHIP E!tWEEN "PS
CON1RO~
BLOCKS
Several levels of linkage exist between elS control blocks, as described
in thE following secticDs.
~l~_~QntIQ!_~!2~!_~!!!Di~~
Figure 3-12 shows the highest-level linkage, that of chained control
tlocks.
3.20
IriS/VS Primer
...
--
MESSAGE
OUTPUT
(MOD)
DEVICE
OUTPUT
(OOF)
rx
[A
0
"
CREATED WITH
ONE FMT NAME
...
DEVICE
INPUT
(DIF)
MESSAGE
INPUT
(MID)
fa
"
,f
o
Ix
0
MESSAGE
OUTPUT
(MOD)
-...
rc
DEVICE
OUTPUT
(OOF)
rv
1.
This linkage must exist.
2.
If the linkage does not exist, device i~put data from 3270 devicEs
is not procEssed by MFS. It is always used in our subset.
3.
This linkage is previded fer application program convenience. It
~rcvides a Met name to te us~d by IMS/VS if the applicatien ~rogram
does not provide a name via the format name option of the insert
call. ~he default MOD. DFS!02, vill he used if none is specified at
all, or if the input is a message switch to an MFS-supported
terminal.
4..
user-provided ~ames fer the DOl and DIl used in one output/input
sequence are normally the same. The MFS language utility alters the
internal name for the DIF to allow the MPS pool manager to
distinguish betweED thE DOP and DIF.
~hE
The direction of the linkage allows many massage descriptions to use
the same device format if desired. One common device f.ormat can be
used for several applicaticn programs whose output and input message
fcrDat~, as seen at the application program interfacE, are qUitE
different.
Figure 3-12.
Chained Control Block linkage
pata Communication Design
3.21
~!~!!g!_h!~!~~n_~f~~_~n~_]!!~
FiguE~
3-13 sho~s the second level of linkage, that tetween message
fields and devicE fi,elds. The arrows show the direction of reference in
the MFS language utility ~ontrol statements, not the direction of data
flow.
Feferences to device fields by message fields need not be in any
particular sequence.
An MFID need not refer to any DFLD, in which case
it simpl, defines sFace in the applicat~on program segment to be ignored
if the MFlD is tor output, and padded if theMFLD is for input. Device
fields n6ed net te ref~rEnced by message fields, in which cas€ th~y are
established qn thE device, but no output data from the output message is
transmitted to them_
ra.ic~ input data is ~gnored if the DFLD is nQt
referEnced by an input MFtD.
MESSAGE OUTPUT~--__... DEVICE OUTPUT"
(DOF)
(MOD)
MFLb --~~------~~~
MFLD
MFLD
MFLD
MESSAGE INPUT
(MID)
DEVICE INPUT
(DIF)
MFLD -~~----+--~ DFLD
MFLD
DFLD
MFLD
DFLD
MFLD
DFLD
x
Figur~
3-13.
Linkage between
~essage
Fields and Device Fields
1i~k~gs_!s!j!!n_tf!~~_!~g_~fA~~
Figure 3-14 shows a third level of linkage, one which exists between the
LPAGE and the DFAGE.
MESSAGE OUTPUT
(MOD)
DEVICE OUTPUT
(OOF)
LPAG E ---+--------+---~ DPAG E
LPAGE,
OPAGE
LPAGE--~~~~--r-~
LPAGE
Figure 3-14.
DPAGE
LPAG! -- DPAGE Linkage
The LPAGE in the MOD must refer to a DPAGE in the Del.
DPAGEs need not be referred to from a given MOt.
However, all
Because WE will always have sin91e segment input in our subset, the
defined MFLDs in thE MID may r.efer to DFLDs in any DPAGE.
Eut input
data for any qiven input message from the device is limited tc fields
defined in a single DPAGE.
IMS/VS Primer
Q21~Q~S!_rl~§§sq~_~~~£f~E!!Qn_1i!!!.!g~
Figure 3-15 shows a fourth level of linkage. It is optionally alailable
to allow selEcticn of the MID tased on which MOD LPAGE is displayed when
inFut data is received from the device.
r-----------IMESSAGE OUTPUTt----....~ DEVICE OUTPUT
'-',.
(MOD)_
(DOF)
LPAGE
\..:.J
~
_--I
~LPAGE
LPAGE
....
0~--
x
A
MESSAGE INPUT ~----~
(MID)
DEVICE INPUT
(DIF)
x
MESSAGE INPUT
(MID)
MESSAGE INPUT
('MIDl
D
Figure 3-15.
OFtional
~ess~ge
Description Linkage
1.
Th~
next ~ID name Frovided with the MSG statement is used if
is fIo,ided ~ith the current LFAGE.
2v
If a nExt ~Ir name is Frcvided with the curr£nt LPAGE, input will be
PIoc€ssed using tbis nalE.
3.
FCI 327C devices, all MIDs must refer to the same DIF. This is the
same user-prcvided name used to refer to the tOF when the MOD waE
defined.
Data Communication Desigr
~o ~ame
3.23
~~lQ_~~!!~~_£Qg§ig§~~~!£~§_~!l~!!!~_!g_£g~!!g!_]!2£!_~~n~~g~
Since out~ut to 3270 display devices establishes fields on the device
using harcwarE capatilities, and fi€ld locations cannot be changed by
the oFerator, special linkage restrictions exist. Because fcrmatted
input can only occur fr~m a screen formatted by output, the IFAGE and
Fh~sical Fage description used for formatting input is always the same
as that used tc fOLaat the ~revious output. The Mrs language utility
enforces thiE restriction by ensuring that the format name used for
input editing is the sa~~ as the format name used for the previous
output editing_ Furthermore, if the DIF corresponding to the previous
DCF cannot te fetched during online processing, an error ~€~~a9~ is sent
to the 327C display.
The following secticns ccntain a description of the basic MFS
functions~
INFUT MESSAGE FORMA1!ING
All device input data received by IMS/VS is edited before being Fassed
to an application program. 7he editing is performed by either IMS/VS
basic edit or MFS~ This section describes the input "message editing
performed by MFS. It tells hew the use of MFS is determined and how,
when MFS is used, the desired message format is established based on the
contents of twe MFS centrcl blccks -- the device input format {DIF) and
the message inFct descriptor (MID) ..
All 3270 devices included in an IMS/VS system use MFS. The 3270s always
operate in fcrmattea recd€ eXCEpt when first po~ered "on, after the CLEAR
key has been Fressed, or when the MOD used to process an outFut message
does not name a MID to be used for the next input data.. While in
unfermatted mode, you can still enter commands and transacticns, but
they will Dot be formatted by ~FS.
InFut data from terminals in formatted mode is formatted based on the
contents of twc MFS cont~ol blocks, "the MID and the DIF. The ~ID
defines how the data should be formatted for presentation to the
application program ~Dd ~cints to the DIF associated with the input
device. See Figure 3-16.
MID
DIF
OFL01
OFL02
OFL03
OFL04
OFL05
Figure 3-16.
3.24
PROGRAM
MFS
DEVICE
..-----,,
,
MFlO3
-*-' .
MFL05
~
,-"
MFS Input Formatting
IMS/VS Primer
MFlO1
MFlO2
MFlO4
The MID contains a list of !~§§!g!_~~§£!jf~E! f!~lg§ (MFLDs) which
define the layout of the in~ut segment as is to be seen by an
apFlication Frogram. ~h€ DIF contains a list of ~~!i~~ ~~§~[~EIQr
!i~lg§ (DFLDs) which define what data is to be expEcted from which part
of the device (that is, the location on the screen). MFS maps the data
of the DFIDs inte the corrasFonding MFLDs. The application Frogram is
largely devic~ independent because different physical inputs can be
mapped into the same input segment.
MFLt statements are to define:
•
The device fiElds IDFLDs) defined in the DIY which contents will be
included in the message presented to the application program.
•
Constants, defined as literals to be included in the messagE; a
common use of literals is to s~ecify the transuction code.
In additicn, the MFLD
•
•
statemen~
defines:
lhe length of the field expected by
th~
applicaticn program.
Left or right justific~tion and the fill character to be used for
the aata received frem the devic~.
paddi~g
•
A 'nodata' literal for the MFLD if
contain any input data.
th~
corresponding DFID does not
It should bE noted that all message fields as defined ty MFLD statements
will be Fresented to the aFFlicaticn program in our subset.
Furthermcre, there will always be only one input message s~9m~nt, except
for a conversational trdnsactieD, in which case the first segment
presented to the ~rogrQ~ is ths SFA. The SPA is never processed by MFS,
however.
sometimes input messagES arE simFly ~pdated by an application program
and returned to the device. In such a case, i~ may sim~lify message
definition layouts in the MPP if the attribute data bytes are defined in
the message input d~sc~iptor as well as in the message output
descriptor.
Non-literal input message £ield~ can be defined to allow for 2 bytes of
attribute data.
ihen a field is so defined, MFS will reserve the first
2 byteS of the fiEld fer ~ttributE data to be filled in by the
applicatic~ Frogram when p~epdring an output message.
In this way, the
same pro9ram area can be ccnveniently used fer both input and ou~put
messages. When attribute s~ace is specified, the specified field length
must include the 2 attribute bytes.
If the input data is for a password protected transaction, a device
field should be designated fer the password. The device field in which
the operator keys in the password will not bt displayed on the scre~n.
OUTPUl MESSAGE
FCF~ATTING
A~l output messagES fot 3270 dEvices are
sililar tc input.
pr~essed
by MrS in a way
Data Communication Desigr
3.25
All MFS output fcrmatting is based on the contents of two MFS control
-- the m~ssage output descriptor (MOD) and the device cutput
format ,OOF). See Figure 3- 17. 'Ihe MCD d.efines output message content
and c~tlonally, literal data to be considered part of the output
message. Message fields (MFLDs) refer to device field locations via
device field (DFID) definitions in the DCP. The DOF sp€cifies the use
of hardware featurss,. device field locations and a"ttritutes, and
constant da"ta considered part of the fermat.
blc~ks
4
PROGRAM
MFS
DEVICE
MOD
DOF
DPAGE
-...-
LPAGE
SEG
DFLD1
- - --
MFLD1
DFLD2
-- --
MFLD2
DFLD3
' ....
MFLD3
DFLD4
,,~
".,,')1(, ....
MFLD4
DFLD5
Figure 3-17.
~FS
Cutput Formatting
The laycut of the output message segment to be received by ~FS from the
program is defined by a list of MFLDs in the MOD. The DOF in turn
contains a list of tFLDs which define where the data is to be
displayed/printed on the output device. MFS maps the data ef the MFLOs
into the corresponding DFLDs.
All fields in an ootput message segment must be defined by ~FlD
statements. Fields can be truncated or omitted by two methods. The
first method is to insert a short segment. The secene method is to
Flace a NULL character (X'3F') in the field. Fields are scanned left
(including the attribute bytes, if any) to right for a NULL character.
The ~irst NULL character encountered terminates the field.
If the first
character of a field is a NULL character, no data is sent to the screen
tor this field. !his means that if the field is protected and the same
device format is used, the old data remains on the screen. To erase the
old data of a ~rotected field the application program must send X'403Ft
to that field. Positioning of all fields in the se9m~nt r~mains the
same regardless of NULL characters. Truncated fields are padded wi~h a
program tab charactEr in cur subset. Furthermore, we always specify
erase-unFrotected-all in the display ae~ice format. This erases all old
data in unprotected fields·cD the screen.
1.
Device control characters are invalid in output message fields und.er
Mrs. The control characters HT, CR,LF, NL, and ES will be cbanged
to null charact~rs (x·ee'). All other nongraphic characters are
changed to blanks before transmission. Graphic characters are X'40'
through X'fE'.
2.
With MFS, the same cutfut message can be mapped on different device
types with one set of formats. This will not be covered in our
subset. !he formatting discussed will cover one device type per
device format, not a mixture. However, the mixture cap te
im~lemEntEd lat~r ky. changing the formats.
3.26
IMS/VS Primer
In addition to MFlD data, constants can be mapped into DFLDs.
constants are defined as literal~ in DFLD or MFLD statements.
TheSE
MFS allows mapping of cne cr mere output segroen~ of the same message
onto a single or multiple output screens. In our subset, we will li~~t
ourselves to a one-to-one relation~bip between output mebSag€ s~cm€nts
and logical output pages. Alsc, cne logical output page is one physical
output page lone screen).
!ggi£~1_f~qinq_gt-~~~EY!_!~§§2g!§
Logical paging is the way cutput message segments are grouped for
~hen logical paging is used; an output ~essag€ descriptor
is defined with one er mere LPAGE statements. Each lPAGE statement
relates a segment produced by an application program to a corresponding
device page.
for~attiDg.
Using logical paging, the simplest message definition consists of one
LPAGE and one segment description.
As shown in Figure 3-18, each
segment produced ty thE applicaticn program is formatted in the same
manner using the c~rresponding device page.
MSG
~~!l.Di!l.Q.D
Device
__
f.2.9~
LPAGE1-------------)DPAGE1
SEG1
Application
fI2g1~J!_Q.Y!EY~
Segment
or
segment 1
Segment ,
Segment 1
Figure 3-18.
!n Cutput Message Definition with one lPAGE
With the definiticn sho~n in Figure 3-18, each output segment inserted
by the MFF will be displayed with the same and only defined MO~/DOF
comkination.
If different fcrmats are required for different output segments, one
LPAGE and SEG statement combination is required for each diffe~ent
format.
Each LPAGE car. link tc a different DPAGE if desired.
(This
would not b~ required if only defined constartts and MFLDs differ in the
MOt. )
The selection of the LP1GE tc be used for fcrmatting is based on the
value cf a special MFLt in the output segment. This value is set by the
MPP. If the LPAGE to te USEd cannot be determined from the segment, the
last defined LPAGE is used. See also the description of the C(Nt
parameter of the lPAGE statement.
Each LFAGE can refer to a
corresponding DPAGE vith unique DFLDs for its own device layout. See
Figure 3-19.
Data Communication Design
3.27
MSG
~ef1:llili2.!!
Device
__
f!~!
LPAGE1-------->tP~~!'
Application
!!I2gI~! _Q!lln!~
Segment 1* (tPAGEl condition specified)
SEGl
Figure 3-19.
An O'utput f!2ssage Definition with Multiple PagEs
If an outFut message contains multiple
next one with the !1~9~~! s££§§§ !~I !
the last page is received« IMS/VS will
subset. If PA1 is then pressed again,
of the current cutput messa~e again.
pages, the o~eratcr reguests the
(PAl,. If PAt is pressed after
send a warning message in our
IMS/VS will send the first page
operator can al~ays request the next output message by pressing the
PA2 key. Also, in our sutset, when the operator enters data, t~E
current output ~essage is dequeued.
T~e
Outpu~ messagE fields can te defined to contain literal data specified
by the user during definition of the MOt. MFS will include the
specified li'teral data in t~e cutput message before sending the message
to the device.
MF-S users may define their cwn literal field an~/or select a litera 1
from a number cf literals Frovided by MFS. The MFS-provided literals
are referred to as system literals and include various date formats, a
time stamf, the output message sequence number, the logical terminal
name, and the number of the lcgical page.
Device field attributes are defined in DFLD statements. For 3270
display devices, specific attrit~tes may be defined in the ATTF.= keyword
of the tflt statement. If nct, default attributes will ~e assumed. The
message field definition (MFLD) corresponding to th& device field (tFLt)
may sFecify that the application program can dynamically modify the
device field attritutes.
When a field is so defined, the first 2 data bytes of the field are
reserved for attribute data. Any error in the 2-tyte specificaticn
caUSES the entire sFecification to be ignored, and the attributes
defined or defaulted for the device field are used.
Ngl~:
~he two attritute tytes should not be included in the length
specification cf the device field (DFLD) in the DOF.
The default attributes fcr ncn-literal 3270 display device fields are
alFhabetic, nct-protected, normal display intensity, and not-modified.
Literal device fields have forced attributes of protected and
not-modified and default attributes of numeric and normal display
intensity. Numeric protected fields provide an automatic skip function
on display terminals.
3.2E
I~S/VS
Primer
The pcsitio~ing of the cursor on the 3210 display device is done in
either of twc ways:
1.
The DP!GE statement defines the default cursor position.
2.
~he
program can dynamically set the cursor to the beginning of a
field vid its attIitut€ by tea
EI§!~!_~~~§gg~_~i~!~_J~~12_~i§£!!I_~§!i£&§)
Output formats fer 3270 display devices may be defined to include a
system message field. If sc defined, all I~S/VS messages except DFS057
REQUES!ED FOEMAT SlOCK NC! AVAILAELE are sent to the system message
field whenever tbE devicE is in formatted mode. Providing a system
message field avoids the display cf an IM~/YS message elsewhere on the
screen, thereby cverlaying thE screen data.
When MFS sends a message tc the system message field, it activates the
device alarm (if any) tut dces net reSf't modified data tags (MDTs) or
move the cursor. Since an IMS/VS error message is an -immediate respcnse
to lnput, MDTs remain as they were at entry and the operator merely has
to correct the pcrtion of the input in error.
In our subset we will always reserve the bottom line of the screen fer
the system messagE field. This field can also be used to enter
cewmands, for example, /FCE~~Tu
~Ii~~~g_E!g~_IQI!~!_~QD~-~Q!
The 327C printer devices are also supported via MFS. Three tasic
options can be specified in the DEV statement (PAGE: operand) :
•
A defined fixed numbEr of lines should always be printed for each
page (SPACE). This is the recommended option because it prEserves
forms positicning.
•
Only lines containing data should be printed.
deleted (FLCA'l).
•
All lines defined ty DFIDs shculd be printed, whether or not the
DFLDs contain data (DEFN).
MIS
FCBMA~S
Blank lines are
SOPPLIED BY IMS/VS
Several formats are included in the I~SVS.FCRMAT library during IMS/VS
system definition. They are used mainly for the master terminal, and
for systEm commands and mEssages. All these formats start with the
characters DFS. Cne of the most interesting in our subset is the
default output message format. This format is used fat broadcast
messages from the master terminal and application program output
messages with no ~OD name specified. It permits two segments of input,
each teing a line on the screen. DFSDF2 is the fo~mat name, DFSM02 the
MOD and DFSMI2 the ~ID name.
When the master terminal format is used, any m~ssag~ whose KOD name
begins with tFSMO (except DFSM03) is displayed in the message area. Any
message whose MOD name is DFSDStC1 is displayed in the display area.
Messages with other MOt names cause the warning message USER MESSAGE
WAITING tC' bE displayed at the- lower portion of th~ di!=play screen.
Data Communication Design
3.29
This section describes the centrel statements used by the ~FS langttage
utility. !here are two major categories of control statements:
•
Definition statements are used to
formats.
•
Compiler statements are used to control the compilation an4 listings
of the definition statements.
defi~e
message format$ and device
!hE definition of messagE fcrmats and device formats is accosFlished
wit~ sefarate hierarchical sets of definition statements.
The statement
set used to define message formats consists of the follcwing statem~nts:
Identifies
definition.
MSG
t~e
beginning of a message
Identifies a related grouF of
segment/field definitions.
lPAGE
to te used as an
FASSiiCBD
Identifies a field
IMS/VS password.
SEG
Identifies a message segment.
a messa~e field. IteratiVE
processing of MFLD statements can be
invoked by specifying DC and ~~DDC
statements. !o accomplish interative
processing, the DO statement is placed
.before the MFLD statem~nt(~) and the
D~fines
MFLD
ENDDO after the MFLD statemEnt(s).
See following discussion on
compilation statements.
Identifies the end of. a messa9E
def ini tion.
MSGEND
The statement set used to define device formats consists of tbe
following statements:
Identifies the beginning of a format
definition.
FMT
Identifies the device type and
operational cptions.
DEV
Identifies the format as inFut,
output, or both.
DIV
Identifies a group of device fields
corresponding to an LPAGE group of
message fields.
DPAGE
I1FID
3 .. 30
IMS/VS friml?r
Defines a device field. lterative
processing of DFLD statements can be
invoked by specifying DC and ENDDO
statements. To accomplish iterative
processing, the DO~statement is placed
before the DfLD statement (s) and the
ENDDC after th~ DFID statement(s).
See the following discussien on
compilation statements.
Identifies the end of a format
definition.
!MTENt
Compilation statements have
fUDctions.
va~iable
The most common ones
a~e:
DO
Eequests iterative proc~ssiug of
defi~iticn statements.
l:JECT
Ejects SYSPRINT listing to the next page.
!ND
Defines the end of data for SYSIN
ENDDO
!erminates iterative pcocsssing of P.Flt or tiLt
definiticn statemer.ts.
PRIN!
Ccntrcls SYSPRINT cptions.
SPACE
SkiFs lines on the SYSFBINT listing.
TITLE
Provides a title for the SYSPBINT listirg.
~Fln
or DFlt
proces~ing.
Compilaticn statem€nts are to be inserted at logical points in t~e
sequence of control state~ents. Fer example, TITLE could be placed
first. and EJECT could be placed before ~acb MSG or FMT statement.
BELA~ICNS
BE1WEE~
SCUBeE STATEr.EN!S ANt
In general, the following relations
statements and centrol blcck~:
CCN~FOL
~xists
ELOCKS
tetween the MFS
sourc~
stat~m~nts
•
One MSG statement and its associated LPAGE. SEG. and MFID
generate one ~I~ or ~Ct~
•
Ons EM! statement and its asscciated DEV, CIV, DPAGE and DFLD
statemEnts gEneratE onE DIF and/or DOF. For dis~lays, both the DIF
and DCF are generat~d, tecause the output scre~n is used fer input
too.
In addition the MFS utilities vill establish the linkages between the
MID, ~OD, DIP, and DOF. These are the result of the symtolic Iam~
linkages defined in the SOU~CE statemeDt~.
Th€ names of format blocks must be unique. the MID and ~CD names,
specified as the label of the ~SG statement must be 1 to 8 alpbanumeric
characters. ~he tIF and DOF names 'are de~ived from the 1 to 6
alphanumeric character label ~f the FM! statement.
With reference to our naming convention in Chapter 1, we will use in the
samples:
•
OE4aaa
for the
•
OE4aaaln
for tbe MID
•
OE4aaaOn
for tile MOD.
F~!
(DIP/DOF)
Data Communication DesigI
3.31
wherE:
aaa identifies the application
n
isa sequence number
0'11LI1:Y SYNTAJ
The ~PS languagE utility uses the syntax common to
In additicn, it shoula te noted:
Assembl~r
language.
•
there is no limit to the number of continuation cards.
•
there is no limit to the total nuaber of characters in the operand
field. Inci.idual cperand items cannot exceed 256 characters.
•
Literal length restrictions do Dot¥include leading, trailing, and
imbe~ded second quote characters.
•
If a nonstandard cbaracter. such as a multipunch, is detected in a
literal, a severity q warning message is issued.
•
Positional parameters. if specified, must precede keyword
para mete rs.
~FS
DEFINItICN
STAT!~ENTS
Following is a detailed ~escription of Each of the MFS languagE
definition statements. This description should be used as a reference
when you are coding your own formats. You can skip this section at
initial study. A coding sample is provided in Figure 3-21 at the End of
this section.
~~2 .§!!!!!~n~
ftSG statement initiates and names a message input or
description.
~he
/
I
,
1
out~ut
1-------------------------------------------------------------,
I
,
I
label
1
,
,,
I
,
,
,
,
I
MSG
t
I
t·
,
,,
t
t
I
,1
1
I
,
1
['IYPE={ll!f.Yl}]
,I
,SoR=(formatname,IGNORE),CPT=2
,
f
I
I
OO~PO'I
[ ,NI7=msgdescriptionname]
,1--------------------------------------------1,
,
,
I
FOR MSG
I
,PAGE=YES
~YPE~OO~POT
ONLY
I
I
lat4l
a 1- to a-character alphameric name ~ust be specified. This label
may be referred to in the Nxt operand of another message
description. It is the name of the MID or MOD wbich are stored in
the IKSVS.FORKA~ likrary.
. 3.32
IMS/VS Frimer
TYPE=
defines this description as message INPUT or OUTPUX.
is INPUT.
Default value
SOR=
fcrmatname is the name of the FMT statement which, with thE DEV and
D1LD statEments, defines the terminal data fields processed by this
message description. IGNCEE should he specified as shown in our
subset.
CPT=2
should be specified as shown in our subset.
NX'!=
specifies a mEssa~e descri~ticD to be used to map the next expected
message as a result of processing a message using this lessag~
description. If llPE=INP07, NX!= specifies a message output
d~scriptionu
In that case, the HOD can be-overridden by thE
applicaticn ~re9ral. If TYFE=OUTPUT, NIT= specifies a message input
description.
If TYFE=CUTPUT and the formatname specified in the SOR= operand
contains forlats fer 3270 and/or 3270P device types, the
msgdescription namE refErred tc by NX1=, (the message input
description) must use the same formatname. This parameter should be
('oded if TYP!=OOTPUT.
PAGE=YES
should be specified as shown in our subset fo= all output message
descriptions.
The LFAGE statement d~fines a 9rou~ of segments cemprl.el.ng a lo-gical
page. 'the ~FAGE statement is optional and in our subset only apFlicable
to output messages.
/
/-------------------------------------------------.-----------,
,
,
I
I
,
I
I
,
I
I LPAGE
I
I
,
1
I
I
,
I
1
I
I
[,COND=(mfldname,=,'value')]
I
I
I
( ,NX'I=msgdescriptionname]
,
SOR=dpagename
J
J
SOp=
specifies the namE of the DPAGE statement that defines the display
fermat fer this logical page.
ceND:
this parameter controls the selection of the message output formats
to be used for each logical page occurrEnce. Mfldname must te th~
name of an MFLD defined in this LPAGE. 'Ihe length of this P.F1D must
be equal to the length of the value literal. This parameter wo~ks
as follows: If the content of the mfldname is equal to the specified
value, then this IFAGE and its associated segment, field, and forlat
description are used for fcrmattin9 of the output message. A one
character field with values A, E, C, ••• , etc., is recommended.
ExamEle: CCNt=(FAGETYFE,=,'A'), where PAGETYPE is a defined MFLD cf
one character in this IPAGE. If the conditional tests for all
LPAG!s fail, the last defined LPAGE is used for focmatting of the
foessage.
tata Communication Desi9n
3.33
NXT=
specif1es the name of the mes~age d~scription to ce used to map the
UE~t m~ssage if this logical paqe is proc~ssed.
This name will
override any NXi; name specified on the previous MSG statEment.
~!E~~~B~ ~!~t~!~S~
!he PASSiCFn statement identifies a fiEld to be used as an I~S/VS
passwo~d. When used, the PASSWORD statement an1 its associated MiLD must
precede the first SIG statement in a MSG definition. The total password
length may not exc€Ed e charactErs. !he first 8 charact~rs of da~a
after editing will be used for the IMS/VS password.
I
/
,
I FASS.eRD ,
I
,
I
I
flanks or comments
!he SEG statement delineates message segments and is requirEd only if
multisegmEnt IEssagE precessing ~s used by the application program.
Output message segments p=ocessed by MFS cannot exceed the logical
record length cf the lcnq message queue data set. This maximum is in
cur SUbSEt 13e8 bytES. Only one segment should be d~fined for
TIPE=INPUl MSGs, and each IFAGE statement.
/
,
--------------------------------------------------------------,
,
t
I
,
'
SEG
J
I
,
I
I
L-------~----~~-----~~---~--·-~-----------~-----------~-.-~~-~~-~~
The DO statement caUSES reF~titive generation of MFtD statements
the DC and ENDDC statem9nts.
/
,,
,,,
te~veen
-------------~-------------------------~----------------------,
I
,,
,
I
,I
DO
I
I
,
I
I
cOlln t
r,S UI={ Q..1
}]
number
L
count
specifiES bow ~any times to generate the following ~FID
statement(s). The maximum count that may be specified is 99.
SOF:
specifies tbE ~-di9it suffix to be a~pended to the eFl~ latel and
dfldname of the first group of generated MFLD statements. Default
value is 01. Mrs increases the sdffix by 1 on each subsequ€nt
generation of statements.
If the specified suffix exceeds 2 digits, MIS uses the rightmost 2
digits.
3.34
IMS/VS Primer
If the specified count is such that the generated suffix eventually
exceeds 2 digits, ~FS reduces the count to the largest legitimatE
maximum valuE. Po~ ~xaIFlE, if count aguals a and SUF=95, invalid
s~ffixes of 100.101, and 102 would re3ult.
In this instance, MFS
reduces the ccunt to 5, Frccesses the statement, and issues an error
message.
lhe MFLD statement defines a message field as it will be presented to an
application Frogram as part of a message inFut segment or received from
an application program as part of a message outpu~ segment. At least
one MFLD statem€nt must be specified for each ~SG description.
--------------------------------------------------------------,
I
I
I
I
I( label] I
I
,
,
I
t
I
I
I
I
,
I
I
I
1
I
I
I
I
,
t
,
f
1
I
1
I
,
MfLt
I
I
?OR
"I
I
,
I
~SG
TYPE=INPD!
[{~i1~~;:~ , } ]
[ .(dfldllamta,'literal')
[,LTH=nn]
J
I
I
I
r
JUH
I
I
1,
,
I
,
(
={~}]
I
J
,
I
[,ATTP.=5]~ }
,tYES
I
1
[ {~.!.-~}]
:
FOE
f
,FILL= NULL
C' c'
,
,
--------------------------------------------f!
~SG
TYFE=QUTPUT
dfldname
}]
(dfldname,'literal')
[{ (dfldnam€,system-literal)
( ,L'IH=nn)
,
t
label
a 1- to e-charact~r alphameric name may be specified. This label is
required if it is referred to in the CONt operand of the prEvious
LfAGE statement. It may bE used sim~ly to uniquely identify this
statement. If the MFlt is between the to and ERDDO statements, this
label shculd tE rEstricted tc 6 characters or less. DC statement
fIocessing appends a 2-digit suffix to the lab~l and prints the
label as part of the g€DErated "FLO statement.
Data Co•• unication Design
3.35
dfldname specifies the device field name (defined via the DEVor DFlD
statement) freK which inFut data i~ e~tracted or into which output data
is placed. If t~js para~e~er is omitted when defining a m9ssage output
descriptor, the data sUF~lied by the application ~rogram is not
eisplayed nn th@ output device. If the repetitiie generaticn function
of MPS is usea ,DO and ENDDO statements) , this dfldname should be
restricted to 6 bytes maximum length. ihen each repetition cf the
statement is gen~rated, a 2-character sequence number (01 to 99) is
apF~nded to thE dfldname.
I£ the dfldna~e specified here is greater
than 6 bites and repetitive generation is used, the dtldnau~ is
truncated at 6 characters and a 2-character sequence number is appended
to form an 8-character name.
No error message is ~rovided if this
occurs. !his parameter ~ay be specified in one of the following
forma ts:
dfldnamE
identifies the device field name from which input data is extracted
or inte which cutput data is placed.
'literal'
may be specified if a literal value is to be inserted in an input
message.
(dfldnamE,'literal')
If TYPE:OU1PUt, this describes th~ literal data to be placed in the
named DPlt. When this form is specified, space for the literal must
not be allocated in the output message segment supplied by the
application program.
Normally, such a literal should te definEd
with a DFLD statement. SFecifying it in the Met allows differ~nt
literal values (in differeni MODs) to be displayed with the same
dEvice format.
TYPE=INPO~, this describes the literal data to be placea in the
message field when no data for this field is received frcm the
dEV iCE.
If
In both cases, if the LTH: operand is specified, the length of the
literal will be truncated or padded as necessary to the length of
the LTM= specificaticn. If the literal length is less thari the
defined field len9th, the literal is padded with tlanks if
TYPE~OUTPO! and with tnE s~ecified fill characteI (FIIL=) if
!YPE=INPO!. If no fill character is specified for input, thE
literal is padded with hlanks (the default value). The literal
length may not exceed 256 characters.
(dfldname,system-literal)
specifies, a r.amE fIC~ a list of system
lit~~als.
~
system
lite~al
functions like a normal literal except that the literal value is
created during forr.atting prior to transmission to the device. The
and ATTB: operands may not be specified. Wh~n this form is
specified, spaCE fcr tb~ literal must not Le allocated in the output
messagE segment sUFplied by the application progra~.
L~H=
3.36
IMS/VS
frimer
The
syste~
SYSTEM
L1 IJ:EBAL
NAME
literals and their associated length and format are:
I
I
PROtOCES LITERAL PF
I
I-----------------~-~---,
I
LENGTH
I
I
8
I
FORMAT
I
CC~MENTS
---------9-+-----·---·-+-----------+-----------1
I
I
I'INAME
TIME
,,
DA~E1
,
tATE2
I
DA'IE3
nATE4
LFAGENO
,
II
I
I
e
6
e
e
J3
4
aaaaaaaa ,See note 1
HH:MM:SS I
II.DDD
~
MM/DD/YY I
D~/i-H1/YI
,
,
YY/MPJ/DD I
,See note 2
nnnn
L------------------------~----------------~-----~
1.
Messages generat€d by the 1MS/V~ centrol region in response to
terminal input (error messages, most command responses) will
use DFSM01 ana haVE aD LTNAPJE of blanks.
2.
LPAGENO specifiEs that the current logical ~age number of the
message be provided as a system literal. The literal ft:oduced
will be a 4-digit numter with leading zero~ convert~d to
blanks.,
L'INAtH is the logical terminal (LTEBl'1)
this message i~ being fcrmatted.
Dame of the
LTER~
for which
!B!~:
In our subset, the first MFID in the MID must define the system
message field used fer command input. this complies with our 1~~L!~
Prim~I ~~!Q!§ lsI~i~El QI!~~!2~!~ QYig~.
the following ~FID(s) in the
MID must define the transaction code. Ihis can be a literal, tFID(s),
or a ccmbination. The total length in the MID must be 9 charactErs, 8
for th~ transacticn code, and ene blank as delimit€~. If necessary, the
transaction code must be padded with blanks_
ITH=
the length ef thE field to be ~resented to an application
prcgram on in~ut or received from an application progra~on cutput.
Default or minimum valUE is 1 if it is not a literal. Maximum value
is 8000. The maximum message length must not exceed 32767. In our
subset, th9 laximum output segment length is 1388.
s~~cifies
JUS~=
SF~cifiES that the inFut data field is to be left-justified (1) or
right-justified IF) and right or left truncated as required,
depending upen the ameunt cf data expecte~ by the device format
d~scriptor.
tefault value is L. R is recommended for numeric
fields and L fer ether fields.
ATTR=
specifies whether IYES) or not (NO) the first 2 bytes of this field
should te res'erved fer attribute da ta te be filled in by the
application ~rogram (TYFE=CUTEUT). Default value is NO. Requests
that can te EadE in thE field attribute data are described in
Chapter 4 under the topic "Dynamic Attribute Modification and Cursor
Control. II These twc tytEs must be included in the LTH= operand
value. A~!E=lES is invalid if a literal value bas teen spEcified
through the pesitienal ~aramEter in an cutput message.
Data Communication Desigl
3.37
FILL=
specifi~s a charactar to be used to pad this field when the length
of the data r6ceivEd f~c. the device is less than the length of this
fi~ld.
This character is also used to pad when no data is received
for this field. This o~erand is only valid if T!FE=INPUT. Default
value is tlank.
C
'e'
character 'c' will be used to fill fields. Reccmm@nded: Zero
for numEric fiElds that ar~ ~ight justified, and blank for all
ethers.
NUll
aust te specified in cur subset for the first MFLD, the system
message field used for command input. ~his will ccmpletely
suppress the field if no command input is received.
ENDDO statement terminates the group of MiTt statements that are to
te r~petively generated. The generated MFLD statements are printed
immediately following the ENDDC statement.
~he
,
,
I
,
I
I
ENDDO
Elanks or comments
~~~-~~-----.~-.-~----~--
.. -----~--~------------------------------~
the ~SGEN~ statement terminates a message input or output descripticn
and is re'1~ired as the last statement in the description.
,
,
I
I
I
I
MSGEN D I
Blanks or comments
1
L~------.--~----------~----~-------------------------- -----------J
I
This statement deli~eates atd names a device fc~mat which defines data
fc~roats as they are received fLJm or displayed on specific devices.
A
device format is referred to by message descriptions to format input or
output messages for an application program.
I
I
,
label
I
FM~
Blanks or comments
l---------------___________________________
I
I
~---------------------~
label
a 1- to 6-character alphameric name must be specified. This name is
referred tc ty ttESsagE descriptions in the SO~= operand of MSG
sta te mant s.
3.38
IMS/VS Primer
!his n~mE bECCmeS Fart cf the member name used for the resulting
device cutput fOT-Kat and device input format blocks that are stored
in the IM5VS.FCEMAT litrary.
The DEV statement defines d~vice and data characteristics for a specific
device type. The tFLD statements following this DEV statement are
mapFed using these characteristics until the next DEVor FMTlND
statement is enccuntered. In cur subset, we viII not consider mixing of
device types, so cnly one DEV statement per PM! should be coded.
I
----------------------------------------.---------------------,
1
I
I
I
/
,
1
,,
I
I
,
,I
DEV
I
I
I
I
I
I
I
,,
,I
,
I
I
I
I
TYPE=32;C-An
,FEA!=IGNORE,DSCA=X'OOAO'
[ , SYSMSG=dfldlabel]
~FINTEFS
TY~E= (3270~,
~
1
i
,,
FOR 32,C DISPLAY5
FCF 3270
I
I
I
I
I
I
I
I
I
I
I
1
I
1
,FEAT=IGl'CFE
,,
I
L-------------------
--------------------------------------------~
TYPE=
specifies the 32;C display screen size or printer model.
Ba£ed on the display screen size or printer modal used, specify:
for
~J!:~=
327C-At
3270-A2
327C-A3
3210-A4
3210-A5
3270-A6
3270~,
1
321cP,2
12x80
~tlxEC
32][8-0
~3xeC
"2x40
ExLle
32 € ~- 1
3264-3
E ~ EE- 1
3284-2
32EQ-3
attached to a 3275-1
attached tc a 3275-2
328-6-2
32E1
3288
3~eS
Data Communication Design
3.39
EQ!~§:
,.
!h@ IEM 3270 Information tisplay SY$tem provides a hardware
compatibility fer dis~layin9 a small sc~en size format on a large
screen display. A 24x80 screen format will be display~d en the top
part of a ;~x8C or ~2xEC display, whether or not that display
station was defined as a 24x80, a 32x80, or a 43x80 display type to
IMS/VS. Also, a 12xqO screen fermat will be displayed on the top
left part of a 12xeC display unit.
2.
If yeu are an existing I~S/VS user, using TYPE=(3270,1) or
TYPE=(327C,2). you de net neEd to change your existing formats.
1hsy are still valid and are equally subject to note 1 a~ove.
FEA~=IGNO~E
should be specified as shown in oux subset.
DSCA=X'OOAC'
should be specified as shown in our subset.
unprotectEd all epticn.
It forces the erase
SYSMSG=
specifies the label of the tFLD statement(s) that defines thE dEvice
fiEld in which IMS/VS system messages are to be displayed. A DFLD
with this label must te defined for each DPAGE. DFLDs fo~ SYSMS~
should norsal1y be at least 1TH=19 to prevent message truncation.
We will aliays reser1e the last line of each scraen for this
purpose. As we vill also use this field for command input, it
should net bE protected (see the DFLD statement).
PAGE=
number
definES the tUlter ef print lines on a printed page. This
value is used for validity checking. The number specified must
te greater than er equal to 1. Default value is 55.
tEEN
specifies that lines are to be printed as defined ty DFLD
statEments (no lines are tQ be removed or added to the outpuT.
~age).
SPACE
specifies that Each output page will ccntain the exact number
of lines specified in the 'number' parameter. This is the
recomlended o~tien.
FLOAT
specifies that lines with no data (all blank or NULL) after
formatting are te te dEleted, that is, vill not be printed.
~l! ~~!~s~!»!
The DIV statement definES dEvice formats within a device format
description. !he for.ats are identified as input, output, or toth input
and output. Only ene DIV statement per DEV is allowed.
,
/
,
,,
,,
---~--------------------------.---------------------.-~-.-----,
/
I
3.40
I
tIV
IMS/VS Primer
,,
!lPE={INOOt }
CUT PUT
TYPE:
in ou= subStt, I~Ot~ shculd be specified f~r display (DEY
lYPE=327C-An) and CUTfUT for printers (IEV TYP~=3270P).
The nFAGE statement defines a physical pagew This statement can bE
omitted if none ct the'~~ssage descri~tc:s referring to this d~vice
format (F~T) contain If AGE statements, and cursor position is urder
program control ..
I
--------------------------------------------------------------,
j
,
I
/ [label]f [PAGE,
[CtlFSOR=I(ll,cc»]
1
t
I
L------~----------------~--.-----~--~-----~------~---------------~
label
a 1- to E-tyte alpt~meric name may be s~~cified. This name can be
c~itted if there are no message de~criptions for this device forrrat
that contain LPAGE SOB= rEferences. or if only one DPAGE statement
is defined feL the device.
CORseR=
specifies
tb~
position cf the cursor cn the screen. The value 11
line numb@r and cc specifiers column. Both 11 and cc must
te grEdtEr than cr egeal t c ' . The default ll,cc value for
DEV=327·:-An is 1,~. Value 1, 1 i~ invalid for sC'r~ens.
sFecifi~s
!ypically, the curser position would be controlled ty the
program via thE attritute byte in the reguired field. The cursor
pcsition via the DPAGE is used for initial formats, requested via
the /FCF~AT ccmmandn
!~~~:
The DC statement causes repetitive generation of tFLD statements between
the to and ENDDO state~ents. ihen DO is used, there ar~ restrictions in
the ~aming of DFIDs (refer to "DFlt Statement").
/
I
t
,
:
--------------------------------------------------------------,
,
I
I
, D0
,
,
I
I
;
I
,[-
,
,
I
f
1
t
,
:
!
:
,
~
I
1
c c un t
{li~e-increment}J
[,SUF={~~mber}]
,
:
,
,
~
I
L----------------------------------------------------------------~
count
specifies how many times to generate the statement(s).
line-increment
spec1fies bow sucb to incrEase the line position after the first
cycle. 7he first cycle uses the 111 value specified in the POS=
Data Communication Design
3.41
of the DFLD· statement. Default value is 1.
pO$ition is D2~ incremented in this way.
keJwo~d
The column
sop=
specifies the ~-digit suffix tO',be appended to the dfldname of the
first generated DFlt statement_ Default value is 01. MFS
increments the suffix ty CDe on each subsequent DFLD statement
generation.
If the specified suffix esceeds 2 digits,
digits.
~FS
uses thE rightlcst 2
If the specified count is such that the generated suffix eve~tua~ly
exceeds 2 digits1 !lS reduces the count to the large~t lEqitimatE
maxi.um value. Fct ExamplE, if count equals A and, SUF=9~. invalid
suffixes of 100, 10f, and 1C2 would result. In this instancE, MFS
rEdUCEs tbE ccu~t t~ 5, ~~ccesses the statement, and iSSUES an error
mE ssa~ge.
~!.J2 ~1.!1.i'!!J!!
The DFLD ~~atE.ent defines a field within a device format descriptor
which is ~ead ftom or written to the terminal. Only tho~e a~Eas which
are of interest to the aF~lication ~rogram should be defined~ Null
space in the format need not and should not be defin4d.
/
t
,,
label
tltD
J
,,
,,
,,
,,
f
I
I
I
DEV TYPE=3270-An
1
('literal',
FCS=
!
,,
,
,,
,
,,
,,
J
,,
, [.1 UR= ([{~!)] {].QR!~} HN~~!~~}] ,,
,
,,,
[. {l!~~Et}])]
,
,
t------------------·-------------------------t,
1,
,
,
,
,,,
,
1,
P~B
I
/
I
,
,,
(lll,ccc)
I
( , ITH=nnn]
I
PROT
1
I
I
I
t
,
,,
I
I
FOR DEV !YPE=327CP
I
I
I
[ 'literal',]
POS=(lll.ccc)
I
,,
I
[ ,L'IH=nnn]
I
- _______________________
IL- ____________________________
I
I
I
I
1
-----------~
latel
a 1- to 8-character alphameric name may be specified. This labEl
(dfldname) can te Ieferred tc by a message descriptor in
transferring data to and from a terminal. If the repetitive
generation function of Mrs is used (DO and ENDDO statements). this
dfldname should be restricted to 6 characters maximul lEngth. When
each repetition of the state.ent is generated, a 2-character
3.42
IM~/VS
Frimer
sequence.number (01-99) is appended to the dfldname. If the
dfldname specified here is ~reater than 6 characters and repetitive
generation is used, tbE dfldname is truncated to € characters, and a
2-character seguence ~umber is appended to form the 8-charaeter
name. No error message is provided if this occurs. The lacEl
should ce omitted fcr literals.
'literal'
specifies a liter~l chaxacter string to be presented to the device.
!he literal: length cannot exceed 256 characters for 3270 dis~lay
devices and the liDS width -, fer 3270 printer devices.
For DEV TYPE=3~1C-An, literal fields will have the PBCT attribute
whether sFecified er not •. The NUM attribute will be assumeo if
ALPHA is not specified. 1 literal field cannot be referred to by a
message descriptor.
defines the first data pesitien of this field in terms of line (Ill)
and column (ccc). III and ccc mu&t be greater than or equal to ,.
For a 7YFE=3270-An dEvice, POS= (1,1) cannot be specified. Fields
cannot tE .defin~d such that they wrap from the bottom to the top of
the display screen.
A 3270 display scrEen cannot be copied when a field starting on line
1, column 2, bas beth alphabEtic and pretect attributes.
LTH=
specifies the length of the field. ThE specified LTH= cannet exceed
the physical pagE SiZE ef thE dEvice.
POS= and L1L= do not include the attribute character position
reserved for a 3:iO display device. The inclusion of this byte in the
design ef display formats is -necessary since it occupies the scrEen page
position preceding each dis~laYEd field even though it is not
necessaril~ accessible by an application program.
!2!~:
When defining DFIDs fo~ 3270 printers, a hardware AT~RIEUTE charactEI is
not used. Therefcre. fields may be defined with a juxtaposition that
does not alle~ for .the attribute character. However, the l~st column of
a print line cannot be used. It is reserved for carriage control
eFeratiens performed by IMS/VS.
ATTB=
defines the display attritute of this field. This parameter is only
applicable tc displays in our subset. Attribute keywords may be
specified in any crder and only those desired need be specifi~dft
The underlined keyweIds ~eed net be s~ecified since they are
defaults. Cnly one value in each vertical list may be specified.
specifies whether cr not the field should have the numeric
attribute. It is only relevant to input dat3. The Dumeric
attritute specifies that the numeric lock feature and/or
auto-skip features will be used. For a discussion of numetic
lock and auto-skip, rEfer to QR~I!~~~~§ ~B!g~ IQI !~~ J~l~
IB!~~!~!!~n ~l§£l~I ~l~!!~~, GA27-2742o
specifiES whether or net the field is protected from operator
modification. For literal fields, FROT is used and
speCification of NOPR07 is ignored.
Data Communication Design
3.43
!£~~
NODiSP
HI
specifies the field's display intensity as normal (NORM), high
intensity 181). cr ncndisplayable (NODtS~.
defines whether or not the field modified attribute
assumeo for this field. MOD causes the terminal to
field has been modified by the operator even though
This shoulo net be confused with the fROT attribute
prevents operator modification. MeD is ignored for
fields.
sbould be
assume the
ii was not.
which
literal
1.
In general, device fields which should not be changed by the
cperator should have the PRC~ attribute. This avoids
accidental change of suc~ a field by the operator. Remember,
the attritute tytes can be set by the MPP. Preper use of this
can significantly reduce the number of different fClmats
otherwise required tc meet application needs.
2.
The recommend~d attribute specification for the system message
field (see DEV statement) is ATTR=HI. This will dis Flay these
critical messages with high intensity and allow this field to
be used for command input.
~.!H2Qf §!~.!~ID~n!
ENDDO statement terminates the group of DEtt stat~ments that are to
be repetitivEly genErat~d. ThE generated DFLD statements are printed
immediately fcllowing the !NnnC statement.
~he
/
--------------------------------------------------------------,
,
I
,
I
ENDDO
~
I
I
,
I
I
,
f~l~!Q §~s!~l!~!!~
~he FM7END statement t~rminates a devi(e format description and is
required as the last statement in the device format desctiption.
-~~--~~-~~---~~~--~-~~-~-.~-~--------~~--~-----~~----~~~---~--,
I
,
/
t
,FM'!END
,
COMPILATION
J
I
I
S'!A'!IMEN~S
following compilation statements are the most frequently used ones
and are included ir the ~al~les.
~he
The TITLE statement is used to specify the heading to appear on the
SYSPBINT listing.
3.44
I~S/VS
Primer
I
I
,
-----------------------------------------------------------.--,I
!I TIE
'cha racter sequ ens:;e '
L~--~~-----~~--~---~~------~---~~-~-_~
______ ______ ____________
~-
~
,
I
~
'character sequence'
specifies the beading tc be printed on the output listing.
The PFINT statemEnt can he used to suppress the detailed output listing
of the ~FS language processor. It is recommended to include this
statement at the beginning.
I
----------------------------.------------.-----~---~-- --------,
,
I
NOGEN
L------____________ --____________________________________
I
. _______
,
I
PRIN!
~
The SPACE statement s~EcifiES the number of lines to skip when output is
printedo The SPACE statement is printed before the skip occurs.
,
I
I
SPACE
I
,
,,
,
Dumber
,tL------------------_- __. ____________________________
t
~-----
_______
~
.1
number
specifies how lany lines tc ski~ after this statement is
encc~ntered. Default number is 1.
E~~~.'! E~g!§!!~nl
The EJEC! statement is used to eject a page in an output listing.
EJECT statement is printed tefcte the actual eject.
I
!he
--------------------------------------------------------------,
,
I
,
I
I IJEC~
I
,
I
I~
I
I
L-----------------------------------~----------------------------~
The ENt statement must be used to define the end of the
statements. It must be the last statement.
Mrs
input
Data Communication Design
3.45
,
I
/
I
END
,,
I
I
I
L----------------------------------------------------------------~.
Figure 3-20 shows the sample formats for the Customer Name Inquiry and
Address program. !he lines illustrate the symbolic linkages between the
differ~nt format blocks and fields.
Figure 3-21 shows the screen layout
of this format as printed by the MFS language utility. The complete set
of these MFS ~ource statements is included as member DE4CNI01 in
I MSVS. PBI MESSe.
MOD
OE~CNIOl
MGS
,---------
TYPE=OUTPUT,
SOR= (OE~CN r. IGNORE) , - . -..: OE ~CN I
NXT=OE~CNIIl,
OPT=2
LPAGE SOR=A1200
SEG
MFLU CNUM,LTH=b
MFLD CNAM,LTH=20
MFLD CADR,LTH=20
MFLD CCTY,LTH=20
MFLD CPCD,LTH=b
MFLD ERROR,LTH=35
MSGEND
TYPE=INPUT,
SOR=(OE~CNI,IGNORE)
CNUM
CNAt~
CADR
,
•• ~ eCTY
•
OTP=2
LPAGE SOR=A1200
SEG
TRANSACTION MFLD
SYSMSG,LTH=7Q,FILL=NULL
------~
... MFLD
'TE~CNINQ',LTH=Q
MFLD
CUSID,L
TH=b ..._______~
CODE
MSGE'ND
NXT=OE~CNIOl,
TYPE=3270-A2,
DSCA=X'OOAO' ,
SYSMSG=SYSMSG, - - - - - - - - - - . . . ,
FEAT=IG~IORE
A1200
MID
onCNI Il MSG
DIF/DOF
FMT
DEV
CPCD
ERROR
DIV
TYPE=INOUT
DPAGE CURSOR=«23,20l)
Dt=LD
'CUSTOMER INQUIRY', POS= (2, 2b)
DFLD
'NUMBER' ,POS=(~,211
DFLD POS=(~,33),LTH=b,ATTR=(HI,PROT,NUM)
DFLD
'NAME' ,POS=(b,211
DFLD POS=(b,33),LTH=20,ATTR=(HI,PROT,NUM)
DFLD
'ADDRESS',POS=(9,211
DFLD POS=(S,33),LTH=20,ATTR=(HI,PROT,NUM)
DFLD
'CITY',POS=(10,21)
DFLD POS=(lO,33),LTH=20,ATTR=(HI,PROT,NUM)
DFLD
'POSTAL CODE',POS=(12,211
DFLD POS=(~2,33),L~H=b,ATTR=(HI,PROT,NUM)
DFLD POS=(22,21',LTH=35,ATTR=(HI,PROT,NUM)
DFLD
' ENTER CUSTOMER NO ,POS= (23,2)
DFLD POS= (23,20) ,L TH=b, ATTR=HI
DFLD POS=(2~,2),LTH=7Q,ATTR=(HI)~---~
FMTEND
END
t
CUSID
SYSMSG
Figure 3-20.
format language Statement Sample
3.46
PrimEr
1M 5/VS
CUST,OHER INQUIRY
NUMBER
NAME
..... ......
. .... ......
..". ......
ADDRESS
" .." ..
"."""".,,
.... ........
"." ... ,," .
"
." ..
CITY
""
""
""
""
""
, ,"""""".F."""""""""
"""""""""" "
"
"
" "
"
""" "
"
POSTAL CODE
:::::::::::::::::::::::::::::::::: :
ENTER CUSTOMER NO
Figure 3-21.
Sa mple Displa y .Form at
~fa_£g!I~~~_].Q~!_~!B~E!llQ!
Mrs control blccks are generated by executicn cf the MFS languagE
utility ~ro9ra.. This is a tvo-stage process. See Figure 3-22.
STEP 1
STEP 2
STEP 3
DFSUNUBO
DFSUTSAO
BUILD
INDEX
COMPRESS
DATA SET
PHASE 1
PROCESSOR
Figure 3-22.
Creation of
~f5
IMSVS.
FORMAT
Control flocks
Data Commu&ication DeSign
3.47
The MfS control blcek generatier. can be executed by an leS/YS supplied
catalcged- procedure: MFSUTL. lor a description of this precEdurE, see
Chapter 7, "Installing I~S/VS." Multiple formats can be generated with
one execution. In general yeu would precess a co.plete format set, i.e,
the related message and format descriptions, in one execution of MFSUTL.
Sample jot //SAMP42~ in IMSVS.PRIMEJOB shows the use of this procedure
for our sample applications. Three executions of MFSUTL are involved to
process the tbr,e salplE felmat sets.
STEP 1
The MFS languagE utility FrE~rccessor generates intermediate text blocks
(l!~s), based on the MFS language source statements.
Definition~ of the
MFS language utility source in~ut are,contained in this chapter under
the tepic flMFS Control Statements." The primary function of the
preprocessor is tc Fet£el. syntax and relational validity checks on user
specifications and generate ITBs. The ITEs are tben processed by phase
1 of the utility to generate message (MSG) and format (FMT) dpscriptors.
An I!B generated for each ~SG and FMt source definition processed and is
stored i~ tbe bisterical leference libxary, IMSYS.REFERAL. An I~B for a
particular MSG or F!T ~escription can be re-used by the same or another
fermat set, once it has been successfully added to th~ IMSYS.REFERAL
data set. Each such deEeri~tion must start with a MSG or F~T statement
and end with a MSGEND or F~T!Jt statement.
~hg~!_l
!h@ p~eprocessor invokes phase 1 if the highest ~eturn cede gen~rated by
the preprocesscr is less than 16. Phase 1 places the newly constructed
descriFtors on ~he SEQEIKS data set. Each memcer processed bas a
control r~cord FlacEd on the SEQBLKS data set identifying the member.
its size, and thg date and time of creation. This control record is
followed by the ima~e of the descriptor as constructed by phase 1.
Alternatively, if an error is detected during descriptor buildi~g, an
error control reccrd is ~laeEd on the SECaLKS data set for the
descripticn in error, idEntifying the member in error, and the date and
time the error control record was created. In addition, phase 1 returns
a cemFletion code of 12 to CS/VS. If execution of step 2 is forced,
phase 2 will del~te descriFtcrs with build errors.
STEP 2
Fhase 2 receives centrel as a job step follcwing phase 1. After final
Frccessing, it will place the new descriptors into the IMSYS.FCB~AT
litra~y.
phase 2 passes a ccmpletion code to JS/VS -for step 2 cased on
all the descriFtor maintenance to IMSVS.FCRMAT for a given execution of
the Mrs language utility.
S~EP
3
In our subset, ~e will always execute the MPS service utility after MFS
control block gene~ation. ~bis utility ~ill build a new index directory
block which will eliminate the need for directory search operations
during the IMS/VS cnline cperation.
3.48
IMS/VS Primer
SA~PLE
MFS GENEBATION JOE
Job //SAMP425 in IMSVS.PRIMEJOB shows the JCt for the complete MFS
control block generation p~ocess. ~his job uses the MFSUTl and ~FSFVC
procedur~s which are placed in IMSVS.PBOCLlf during StagE 2 of IM5/VS
system definition. the outFut 9cne~ated by the sec~nd execution of the
MFSUTl Frocedure and the MFSiVC procedure are listed in Chapter 3 of the
l~~L!~ E~!!!. ~!!£l! ~i~!l~g§.
!his is the output of the pro~essing of
the custcmer order entry formats.
Mrs LlfEARY
MAIN~ENANC£
The lM~VS.FOE~AT and I~SVS.P!FEEAL libraries, are standard OS/VS
partitioned data sets. BackuF and restore operations can be done with
the proper 05/V5 utility (lEBCOPY). Heweve~, care must be taken that
both the IMSVS.FCBMAT and the I!SVS.REFERAL data sets a~e dumped and
restored s1_!h~_§sij_!iJ!.
PSBGEN FCR MiFs INt EMFs
.-----------~--~--------
As for each Dl/l batch program, a iSB is ceeded for each KPP or BMP. In
addition to data tase PCBs (see Chapter 2). a PSB fot 'a MPP/BMi contains
cne or more data comllunica-tion FCBs. 'the overall generation of the FSE
remains as descriced in Chapter 2. However, there are a few additicns
to the data tase PC~ statements, and a new statement for the data
communication PCE. In addition, you must perform an .!E.El.!£~~i.Qn .£gl!!~2.!
12!Q~t§ g!n!~!t~~Hl .'ACBGEN) fer all DBDs and PSBs to be 1l'Sed by the C'IL
region. ~his is d1scussed at the end of this section.
ADDI'IIONAL FSB CCtING
CC~VEJTICtiS
In addition to the PSB ceding ccnventions stated in Chapter 2, the
rules must te otserved.
follc~ing
•
'Ihe name of the PSE as specified in the PSENA"E= keyword of the
PSEGiN and tt.E MBR= key~crd in the PSBGEN procedure must be exactly
the samE as the progral lead module name in case of an MPP. This
name is defined during l~S/VS system definition, via the PSB= key~ord
of the APPLC!N statement.
•
ThE order of the PCBs in tbe PSB must be:
•
1.
Data com.unication PCBs,
2
Data base peEs,
3.
GSAM PCEs (not allcwed for MPPs).
One data communication PCB is always automatically ir-c1uded by
I~S/VS at the beginning of each pse of an KPP or BMP.
This default
data communication PSB is used to insert eutput messages back to the
originating l'IEBM~
Sy use of the C!~AT~YES keyword cn the ~atch PSBGEN
statement, we already IIcvided this PCB to the batch progra..
this way, a batch prog~a. caD be ron as a B"F without change.
relative positions of the data base PCEs remain the samE.
!2!!:
Data Communication Design
In
The
3.49
!HE DA!A
COM~UNICATICN
FeE
Eesides the default data cClmunication PCB, which does not require a PCB
statement, additional PCBs can be coded. These FCBs are used to insert
cutput messages to ITFF~s other than the LTE~M which originatEd the
input message. A typical use cf an !!!!I~~!~ PCE is to send Qutput to a
3270 printer terminal.
!he destinaticn of the output lTERM can ce
in two ways:
•
During
•
Dynamically by the MPP durin9 ex~cution, by using a change call
against a modifiable alternate PCB.
PSBGEN
ty
s~t
s~ecifyin9
the LTERM name in an alternat€ PCB.
!he method used depends on the FeE statement.
!his is the only statement required to generate an alternate PCB
(multiple occurrenCES are allcwed). Its format is:
I
I
I
I
,,
/
I
PCB
I
I
TYFE=TF,{LTERM=name}
MODIFY=YES
L----------------------------------------------------------------~
Where:
TYFE=TP
is required for all alternate PCEs.
L7ER~=name
MODIPY=!ES
specifies this is a modifiable alternate PCB (MODIFY=YES) or a
preset destination alternate pee, whers name specifies the output
LTERM. MOtIIY=YES is th~ basic recommendation.
If MCCIFY=YES is specified, the MPP most specify a valid
alternate ootput lTEB~ with a change call before insertir.g any
message via this PCB.
~g~~:
THE tATA EASE
P~B
data base PCE for an P.FF or EMP is basically the same as discussed
in Chapter 2. Two additicnal Frocessing intent options can t~ specified
with the PROcopt=keyword of the PCB and/or SEN5EG statement.
~he
The FEOCOPT= keyword is extended with
cpticns, "0" and "En.
~wo
additional processing intent
!heir meanings are:
C - Read only; DC dynaric E~~ueu~ is dene by program isolation for calls
against this data base. Can be specified with only the G intent
option, as GO or GQP. 'Ihis option is or.ly valid for the peE
statement.
E - Forces Exclusive use ef this data base cr segment by the MPP/BMP.
No other program which references this data base/segment will be
scheduled in parallel.
No dynamic enqueue by program isolation is
done, tut dynamic logging e£ data base updates will be done. E can
be specifi~d with G. I, D, B, and A.
If the ICI 0Ftion (read-only) is used for a PCB, thE data that
is read should net be used as a basis for updating reccrds in
any data base. iith this eption, I~S/VS does not check thp.
ewnershiF of ~he segments returned. This means that the
read-only user might get a segment that had been updated by
another user. If the updating user should then abnormal
terminate, and te tacked out, the read-only user would have a
segment that did not (and never did) exist in the data base.
Therefore, the '0' eption user should not perform updates based
on data read with that option. An ABEND can occur vitb
FROCOPT=GC if ancther program updates peinters when this
program is fcllewing the pointe~s. Pointers are updated during
insert, delete and backout functions.
THE PSBGEN
S~A!E~ENT
This is tasically the salE as fer a data base PCB. The IOEPOPN=
parameteI must te omittea,' the C~PA~=YES Farameter is ignored.
EXAMPLE CF AN ONL1NE PSB
Figure 3-23 shews aD Exam~le of a online PSB. This PSB, PE4CORDR is to
be used with the online custemer order MPP. Its PSBGEN can be performed
with job I/SA~P40' (COEel) or job IISAMP402 (PL/I) in If!SVS.PFIMEJOB.
You should ccmFare this PSB with the Phase 2 batch PSB, PE2CORDR, in
Chapter 2.
Data Coamunication Desi9D
3.51
*
*
**
*
PROGRAM SPECIFICATION BLOCK FOR PHASE 4
ORDER UPDATE PROGRAH PE4CORDR.
ALTERNATE MESSAGE OUTPUT TERMINAL
PCB
TYPE=TP.MODIFY=YES
It
CUSTOMER DATABASE VIEW
*
*
PCB
TYPE=DB,DBDNAME=BE2PCUST,PROCOPT=GO,KEYLEN=6
SEHSEG NAME=SE2PCUST
*
*
*
ORDER DATABASE VIEW·
PCB
TYPE=DB .DBmIAME=BE4LORDR ,I=
or
GE
must bE greater than or equal to
<=
or
LE
must be less than or equal to
b>
or
GT
must be greater than
b<
or
L'I
must be less than
=
or
NE
must be not equal to
Note: As used atove, the lowercase b represents a I:lank
charactEr.
Comparative-value
is the value against which the contents of the field, rEferred
to t1 the field nalE, is to be tested. The length of this
field must be equal to the length of the named field in thE
SEgment of the data base. That is, it includes leading or
trailing blanks (for alphameric) or ~eros (usually needed for
numeric fiElds) as required. A collating sequence, not an
arithmetic, compare is performed.
End Qualification Character
The right ~arenthesis, ")" , indicates the end of the
qualification statement.
Qualification
Just as calls are "qualified" by the presence of an 55A, 55As are
categorized as either "gualified" or "unqualified," depending on the
presence or absence of a qualification statement. Command codes may be
included in or omitted frem either qualified or unqualified S5As.
In its simplest form, the 55A is unqualified and consists only of the
nale cf a sFecific segment type as defined in the Data Base Description
(DBt). In this form, the 5Sl Frovides Dlll with enough information to
define the segment type desired by the call.
ExamplE:
5EGNA~Ett
last character blank to unqualify
Qualified 55As (optional) contain a qualification statement composed of
three parts: A field name defined in the DED, a relational operator, and
a comparative valuEu 01/1 uses the information in the qualification
statement to test the value of the segment's key or data fields within
the data base, and thus to determine whether thE segment meEts the
user's specifications. UsiDg this approach, Dt/I performs the data base
segment searching. The program need process only those segmEnts which
precisely meet seme lcgical criteria.
Example:
4.10
SEGNAMEb(lIELDXXX>=value)
lK5/VS Primer
The qualification statement test is terminated either when the test is
satisfied ty an cccurrence cf the sEgment type, or when it is determined
that the reguest cannot be satisfied.
Command Codes
Eoth unqualified and qualified SSAs may ccntain one or more optional
command codes ~hich specify functional variaticns applicable to the call
functicn or the segment qualification. The command codes are discussed
in detail later in this cha~ter.
General Characteristics of segment search arguments
•
An 55A may ccnsist of the segment name only (unqualified).
optionally alsc include cnE or more ccmmand codes and a
qualification statement.
It may
•
S5As following the first 55A must prOCEEd down a hierarchical path.
Not all 55As in the hierarchical path nEed be specified. Tbat is,
there may be lissi~g levels in the path. DL/l will provide,
internally, S5As for missing levels according to the rules given
later in this chapter. However, it is strongly recommended to
always include SSAs for every segment level.
Examples of 55As viII be given with the sample calls at each DI/l call
discussion in the follcwifJg sectien.
At the end of precessing of the a~~lication program, control must be
returned to the DIll control program.
fQ~Qb
~!Ll
GOBACK.
BE~OBN;
BETUBN(14,12),FC=O
~~~~!~g: Since DIll links to your application program, return to DL/!
causes storagE occupied by ycur pregram to be released. Therefore you
should clOSE all non-DL/~ data sets for CCBCL and Assembler before
return, to prevent abnormal termination during close processing by
OS/VS. PL/l automatically causes all files to be closed upon return.
STATUS CODE EANtLING
After each DIll call, a tvo-byte status code is returned in the FeB
which is USEd for that call. We distinguish between three categoriES cf
status codes:
•
The blank status code, indicating a successful call
•
Exceptional conditions and warning status codes, that is, valid
status codes from an ap~licaticn point of view
•
Error status codes, specifying an error condition in the application
prcgxam and/ox tI/I4
The grouping of status CCdES in the above categories is somewhat
installation dependent. iE will, however, give a basic recommendation
after each specific call function discussion. It is also recom~EndEd
that you use a standard prOCEdure for status code checking and the
handling of error status codes. The first two categories should bE
Data Base Processing
4~
11
handled by the ap~licaticn
gives an example.
~regram
after each single call.
Figure 4-4
r------------------------------------------------------------------~
, CALL 'CBI!DII' USING •• ~.
,
,
, IF PCE-STATUS EQ 'GE' PERFORM PRIN!-NC!-FCUND.
,
, IF PCB-STA!US NE 'bb' FEEFOEM STA~US-EBROR.
, everything ekay, Freceed
~-------------------------------------------------------------------~
Figure 4-4. !esting status Codes
0
•
•
•
•
,
Notice that it is more convenient to directly test the regular
exceptions in-line instead of branching to a status code check reutine.
In this vay, yeu clearly see the processing of conditions that you wish
to handle frcm an application point of view, leaving ~he real errer
situations to a central status cede errer reutine. A detailed
discussion of the error status codes and their handling will te
presented later in this chaEter.
SA~PLE
PRESEN!A!ION OF A CALL
DL/! calls will be introduced in the following sections. Fer each call
we will give sam~les. These samples will be in a standard format as
shown in Figure 4-~.
,
,
r------------------------------------------------------------------~
,
I 77
GO-FUNC PICTURE XXXX VALUE 'GUbb'.
t 01 SSACC1-GU-SE'PAR~.
,
02 SSA001-EEGIN PICTURE
I
02
I
02
,
I 01
IOAEEA
PICTURE J (256).
,
,
I
I
I
,
,
,
1
1
,
I
,t-------------------------------------------------------------------1,
,
t-------------------------------------------------------------------,
,
,
,
, CALL 'CBLTDLI' USING GU-FUNC,PCB-NA"E,ICAREA,SSA001-GU-SE1FAET.
,
I
~IA1~~_~Q~!~:
bb:
I
--:
1 other:
successful call
exceptional tut cerrect condition
errer situaticn
1
Figure 4-5.
I
1
1
,
,
I
Sample Call Presentation
All the calls in the samples are presented in COBOL format. The coding
ef a call in FIll or Assembler vill be presented later. Each call
example contains three secticns. The first secticn presents the
essential elements of working storage as needed for the call. ThE
second part, thE precEssing sectien, contains the call itself. Note
that the PCB-NAME parameter should refer to the selected peE defined in
the Linkage Section. Sometimes ve will add some processing function
4.12
IMS/VS Primer
teforE and/or after the call, in order to show the call in
its right context. the third section contains the status codes and
their interpretation, which can be expected after the call. The last
category of status code, labeled "other: error situation," would
normally te handlEd ty a status code error routine. We ~ill discuss
thcse error status codes with the ~resentaticn of such a routine later
in this chapter.
descri~tion
DL/l PCSITIONING CONCEPT
To satify a call, DL/I relies on two sources of segment identification:
•
~he established position in the data base as set by the previous
call against the FCE
•
The segment sEarch arguments as prcvided with the call.
The data base position is the knowledge of DL/I of the location of the
last segment retrieved and all segments above it in the hierarchy. This
position is maintained ty tL/I as an extension of, and reflected in, the
PCB. When an ap~lication program has multiple PCBs for a single data
base, these positions are laintained independently. For each fCB, the
positicn is represented by the concatenated key of the hierarchical ~ath
from the root SEgment dcwn tc the lcwest level segment accessed. It
also includes the positions of non-keyed segments.
If no current position exists in the data case, then the assumed current
position is the start cf the data base. ~his is the first physical data
base record in the data base. With HDAM this is not necessarily the
root-segment with the lowest key value.
SA~FLE
ENVIRONMENT
The ~hase 1 sample environment is used to exemplify the basic tIll calls
presented in the following sections. The data base used is the PARTS
data baSE as shown in Figure 4-6.
r-- ----- --,
I
,
I SF 1PAR'! ,
I
,
L---------.J
,r-----------~--,--------------,
,
I
r---------,,
I
ISE1PS!OK
I
t
I
L---------~
Figure 4-6.
r---------,I
,
I
I
SE lPPUR
,
,
L---------.J
r---------,
I
ISE1PGDSC
I
I
I
I
L- --------.J
The Fhase 1 FP.ETS Data Base
Dat a Ease Processing
4 .• 13
The following Frograms are Eart of the I"S/VS Primer phase 1 sample
apFlication and are included in IMSVS.PBIMESRC:
•
DFSOAIEl, a data base lcad program
•
FE1CPINV Imember DfS1CINV in IMSVS.PRIMESRC), a COBOL program which
gives a parts inventery report for some (transaction TE1INV,) or all
,transactioti TE1INVfF) of the parts in the PARTS data base,
•
PE1CPPUR {memter DFS1CPUB in IKSVS.PBIMESRC), a COBOL program ~hich
FrocEsses the purchase crders (transactions: TE1FONEW, TE1ECCNG,
TE1PCDEL). This program utilizes GSAM and the batch
checkpoint/restart functicn of DL/I.
~ritten
in Assembler,
For more details on these programs, you are referred to "Phase 2 Sample
Requirements" in Chapter 2, "Designing Data Bases."
RE!RIEVING SEGMENTS
There are
t~o
tasic functions in retrieving a segment:
•
RetrieVE a specific SEgment:
GO
•
Retrieve the next segment in the hierarchy:
GN
The basic get unique (GO) call, function code 'GObb', retrieves one
segment in a hierarchical path. The segment retrieved is identified by
an S5A for each level in thE hierarchical path down to and including the
re~uested segment.
Each should contain at least the segment name. The
5SA for the root-segment should provide the root-key value. Figure 4-7
shows an example of thE get unique call.
The main use of thE GU call is to positicn yourself to a data base
reccrd and obtain (a path of) segment (s). Typically, the GU call is
used only onCE for each data base record you wish to access. Additional
segments ~ithin the data base record would then be retrieved by means of
get next calls (See the following section.) The GU call can also bE
used for retrieving a de~Endent segment, by adding additional SSAs to
the call. For example, if you add a second SSA which specifies the
stock lccation, you would retrieve a STeCK segment bElow the identified
part. If the SSA did nct ~rcvide a stock location number, this would be
the first S~OCK segment for this part.
4. 14
IM5/VS Primer
r---~~--~-~~-----~-----------------------------------------~--------,
77
GO-FUNC PIC70EE Jill VAlUE IGObb l
01
02
02
02
01
SSA001-GU-~E1FAB~.
SSAOC1-E~GIN PICTURE
1(15)
•
VALUE ISE1PAETb (FE1PGFNBb=l.
SSAOC1-FE1EGFNF PIC'IDEE 1(8).
SSA001-ENt PIC'IURF X VALUE I)
I.
ICAEEA PIC'ItBE 1(256).
MOVE FAR'I-NUMBEE 'IO SSA001-FE1fGFNR.
CALI ICELTILII USING GO-FUNC,FCE-NAME,ICAFEA,SSA001-GU-SE1PART.
bt:
GE:
other:
requested PART sEglent has been mcved to IOAREA
segment not foond; supplied part number not in data tase
error situaticn
Figure 4-7.
Eiasic GO Call
The get next (GN) call, functicn code 'GNbb', retrieves the next segment
in the hierarchy as defined in the PCB. To determine this next segment,
tt/1 relies on the previously Established pcsition.
Data Base Processing
4.15
r-------------------------------------------------------------------,
t
,
, 77
1
1 01
,
GN-FUNC PICTDFE XXXX VAlUE ·GNbb·.
1
lOAFEA
,
,
,
EIC!tEE 1(256).
,-------------------------------------------------------------------1I
I
, CALL 'CELTDLI' USING
I
GN-FUNC,PCB-NA~E,ICAREA.
I
I
,--------------------------------~----------------------------------,
,
,
,
,
~1A1Y~_CO]!~:
,
,
,
,
,
,
,
,
,
tb:
GK:
GA:
if previous call retrieved a PART, then a STOCK sEgment
~ill te retrieved
a segment is returned in IeAFEA, but it is a different
type at the ~!!§ level, fer instance, a PURCHASE
ORtER segment aftEr the last stock segment
segment returned in IOAREl, but it is of a higher level
than the last one, that is, a new PART segment
end ef data tase reached, no segment retrieved
errer situation
GE:
1 ether:
LI _____________________________________________________
Figure 4-8.
cl
,
I
,
,
I
I
,
1
I
I
--------------~
Unqualified Get Next Call
The abeve get next call with no SSAs at all will, if repeated, return
the segments in the data tase in hierarchical sequence. Only those
segments are returned to which the program is defined sensitive in its
PCE. If this call was issued after the get unique call of Figure 4-7,
then it weuld retrieve the first STeCK segment for this part (if ene
existed). Subsequent calls wculd retrieve all other STOCK segments,
EUECEASE ORDER, and DESCRIP~ION segments for this part. After this, the
next Fart ~ould be retrieved and its dependent segments, etc., until the
end of the data base is reached. Special status codes will be returned
whenever a different segment type at the same level or a higher level is
returned. No special status cede is returned when a different segment
at a lower level is returned. You can check for reaching a lower level
segment type in the segment level indicator in the PCB. Remember, only
thdse segments to which the program is sensitive via its PCB are
available to you.
Altheugh the above unqualified GN call may be efficient, especially for
report programs, you should use a qualified GN call whenever possible.
lh!
gY!!!'!~4 q~l !!!~ f!!!: This qualified GN call should at least
identify the segment yeu want to retrieve. In doing so, you will
achieve a greater independence toward possible data base structure
changes in the future. If you supply only the segment name in tbe SSA,
then you will retrieve all segments of that type from all data base
records with subsequent get next calls (see Figure 4-9).
4. 16
IMS/VS Primer
,
I 77
I
,01
GN-FUNC PICiOEE XXXX VAlUE 'GNbb'.
,
SSA002-GN-SE1FPUF PlCTUEE 1(9) VALUE 'SE1PPUBtt'.
I 01 IOABEA PIC!URE X(256).
I
,
I------------------------~------------------------------------------1
I
I
, CALL 'CELlILI' USING GN-FU~C,ECE-NAME,ICAEEA,SSA002-GN-SE1PPUR.
,
,
I
1-------------------------------------------------------------------1
,
I
,
,
~lA1~~_~Q~!~:
I
,
bb: next PURCHASE ORDER segment has been moved to IOAREA
I
I
GB: end of data base reached, no more EUBCHASE ORtER segments ,
,other: error situatien
,
I
I
l------------------------------------------------------------------~
Figure 4-9. Qualified Get Next Call
1
Repetition of the above GN
ORDER segments of the data
reached. To limit this to
qualified 5SA for the FAPT
in Figure 4-7.
call viII retrieve all subsequent FUFCHASE
base, until the end of the data base is
a specific part, you could add a fully
segment. This vould be the same SSA as used
An example of a qualified get next call with a qualified SSA is shown in
Figure 4-10. 'his fully qualified get next call should be primarily
used. It always clearly identifies the hierarchical path and the
segment yeu want to retrieve.
r-------------------------------------------------------------------,,
GN-FUNC PlC1VRE
77
01
02
02
02
01
01
J)))
VALUE 'GNbb'q
,
,
I
S5A001-GU-SE1FAR7.
SSA001-BEGIN PIC!URE X,'S) VALUE 'SE1PARTb(FE1PGFNRb='.
SSAOC1-FE1FGFNE PICTURE X(e).
SSA001-END PlClURE X VALUE ') '.
SSA002-GN-SE1PPUR PIClURE X(5) VAIOE 'SE1PPUEb'.
leAREA PIC!VEE X~56).
I
I
I,
I
J
1
,
,,
--------------------------------------------------------------~----,
CALL 'CBLTDLI' USING GN-FUNC,FCE-NAME,IOAFEA,SSA001-GU-SE1PART,
I
SSA002-GN-SE1FFUR.
-------------------------------------------------------------------,I
bb:
GE:
ether:
next PURCHASE ORDER segment is in lOAREA
segment not found; no more purchase orders for this part,
or part DumbEr in SSAC01 does not exist
error situation
Figure 4-10.
GN Call
~ith
,
,,,
,
1
I
Cualified 5SA
Data Ease Processing
4. 17
To change the contents of a segment in a data base through a replace or
delete call, the program must first obtain the segment. It then changes
the segment's contents and ~equ9sts DL/I to replace the segment in the
data base or to delete it from the data base.
This is done ty using the gEt hold calls. These function ccdes are like
the standard get functicn, exce~t the letter 'H' immediately follows the
letter 'G' in the code (that is, GHU, GHN). The get hold calls function
exactly as the corrEspcnding gEt calls fer the user. For DL/I they
indicate a possible subsequent replace or delete call.
After Dl/I has provided the requested segment to the user, one or mcre
fiElds, but not the seqUEncE fiEld, in the segment may be changed.
After thE USEr has changEd the segment contents, he can call tIll to
return the segment to, or delete it from the data base. If, after
issuing a get hold call, the ~rogram determines that it is not necessary
to change or delete the retrieved segment, the program may ~roceEd with
other processing, and the "hold" will be released by the next Dl/I call
against the same peE.
UPDATING SEG!ENTS
Segments can be updated by application programs and returned to 01/1 for
restoring in the data tase, with the re~lace call, function code 'REPL'~
Two conditions must be met:
•
The segment must first ke retrieved with a get hold call,
GHN; no intervening calls
•
a~e
allowed
~efe~encing
Gau
o~
the samE PCB.
The sequence field of the segment cannot be changed; this can only
be done with combinations of delete and insert calls for the segment
and all its dependents.
Figure 4-1' shows an exal~le of a combination of a GHU and REPL call.
Notice tbat the replace call must not specify a SSA for the segment to
be replaced. If, after retrieving a segment with a get hold call, the
program decidES not to updatE the segment, it need not issue a replace
call. Instead the program can proceed as if it were a normal get call.
there is only a very small performance difference bEtween the
get· and the gEt holo call, you should use the get hold call whenever
there is a reasonable chance (about 5~ or more) that you will changE the
Becaus~
se9ment.
77
77
01
GBO-FONC PICTURE XXXX VALOE IGHUb l •
REPL-FONC FICTURE JXXX VALUE 'REPL'.
SSA001-GU-SE1~ART.
02
02
02
0'
SSA001-BEGIN PICTURE 1(19) VILUE 'SE1PARTb(PE1PGPNRt:'.
SSA001-FE1PGPNR PICTURE XIS).
SSAOC1-ENt P~C1URE J VALUE I) ' .
SSA002-GN-SE1FPOE PICTURE X(9) VALUI ISE'PPDRtt'.
01
10lREA PICTURE X(256).
MOVE PART-NUMBER
~C
SSA001-FE1FGFNB.
CALL 'CBLTDLI' OSING GHU-fONC,PCB-NAME,IOAIEA,SSA001-GU-SE1PABT,
SSI002-GN-SE1FFOE.
The rEtrieVEd PORCHASE CBtER segment can now te changed by the
program in thE 10l1EA.
CALL 'CELTtLI' OSING REPL-FUNC,PCB-NAME,ICAREA.
bb:
other:
segment is replaced with contents in IOAEEI
error situation
L-------------------------------------------------------------------~
FigurE 4-11. Basic EEFl Call
DELETING SEGMENTS
To delete the occurrence of a ~e9ment from a data base, the segment must
first be obtained by issuing a get hold (GHt, GHN) call through tt/l.
Once the segment has been acquired, the DLET call may be issued.
No DL/I calls which USE the sale FCB must intervene between thE get hold
call and the DLET call, or the DLE~ call is rejected. Quite often a
Frograa lay want ·to process a segment prior to deleting it. This is.
permitted as long as the Frocessing does nct involve a D1/1 call which
refers to the same data base FCE used for the get hold/delete calls.
However, othEr PCEs may tE IEfeIred to between the get hold and DLE!
calls.
DL/I is advised that a segment is to be deleted when the user issues a
call that has thE function DLET. The deletion of a parent, in effect,
deletes all the segment occurrences beneath that parent, whether or not
the application Frogram is SEnsitive to those segments. If the segment
being deleted is a root segment, that whole data base record is oeleted.
The segment to £E delEted must still be in the IOAREA of the delete call
(with which no 55A is used), and its sequence field must not have tEEn
chan9Ed. figurE 4-12 9ives an exalFle of a DLET call.
Data Base Processing
4. 19
17
11
C1
GHU-FUNC PICXURE XXXX VALUE 'GHUt'.
tLET-FUNC PIC~ORE XXXX VALUE IDLE~'.
SSA001-GU-SE1EART.
02 SSA001-BEGIN PIC'ItJBE X(19) VALUE 'SE1PARTb(FE1PGPNRb='.
02 S5AOO 1-FE 1EGENF EIC'IURE X (8) •
02 SSA001-END fICTUFE X VALUE .) I .
01 SSA002-GN-SE1PPOR PIC'IURE X(9) VALtE 'SE1FPURbb'.
01
lOAREA PIC'IURE X (~~E).
I
,
,
I
,
1
I
,
,
,
,
,~-.-~.~~-.-~~--~~---.~-~----------------------------------------~--,
,
t CALL 'CELTDLII OSING GHO-FUNC,PCB-NAME,IOAREA,SSA001-GU-SE1EAET,
'SSAOO~-GN-SE1PPUR.
I
,
I
The retrieved PORCHASE ORDER segment can ncw be processed by
the Frogram in the ICABEA
,
,
,
, CALL 'CBL'IDLI' OSING tlET-PUNC,fCB-NAME,IOAEEA.
I
t
t
I
t
,
I
,
I
,
,-----------~-------------------------------~-----------------------1
,
,
I
1
~IAIY~_~Q]I~-js!~j'_~~~I_~jlll:
tt:
,
I cther:
I
t
requested purchasE crder segment is deleted from the data,
basE; all its depEndents, if any, are deleted also.
I
error situation
I
,
L-------------------------------------------~-----------------------~
Figure 4-12. Easic DIET Call
1NSER'IING
SEG~EN'IS
Adding new segment cccurrences to a data base is done with the insert
call, function code 'ISR'l'.
'lhe OL/1 insert call is used for two distinct purposes: It is used
initially to lead the SEgments during creation of a data base. It is
also used to add nEW eccurrEnces of an existing segment type into an
established data base. The processing options field in the PCB
indicates whether the data baSE is being added to or loaded. The format
of the insert call is identical for either use.
When loading or inserting, the last 55A must specify only thE name of
the segment bEing inserted. It should specify only the segment name,
not the sequence field. Thus an unqualified 5SA is always required.
Up to the level to be inserted, the S5A evaluation and positicnin9 for
an insert call is exactly the same as for a GU call. For the level to
be inserted, the value of the sequence field in the segment in the user
I/O area is USEd to estaklish the insert position. If no sequence field
was defined, then the segment is inserted at the end of the physical
twin chain. If multiple ncn-unique keys are allowed, then the segment
is inserted after existing segments with the same key value.
Figure 4-13 shows an example of an 15BT call. The status cedes in this
examplE arE applicatle ctly tc non-initial load inserts. The status
codes at initial load time will be discussed under the topic "Loading A
Easic Data Ease" later in this chapter.
4.20
IMS/VS Primer
r-------------------------------------------------------------------,I
77
01
ISR~-FONC
FIC~ORE
XXXI VAlUE '15FT'.
SSA001-GU-S!1PAR~.
02
02
02
01
SSA001-BEGIN FICTOE! X(19) VALUE 'SE1PABTb(FE1PGPNRt='.
SSAOC 1-F! 1PGPNR PIC'IURE I Ie) •
SSA001-END PICTURE X VAlUE ')'.
S5A002-GN-SE1PPUR FleTCRE X(9) VALUE '5E1PPURtb'.
01
leAREA FIC'IORE J(256).
,,
,,
,,
1
,I
----------------------------------------------~--------------------1
I
folOVE FAB'l-NUMBEB 'Ie S5A001-FE1PGFNR.
,
I
~OVE PURCEASE-CEDER ~C lCAF!A.
I
t
CALL 'CEL'1tLI' USING ISRT-FUNC,FCB-NAME,ICAREA,SSA001-GU-SE1PART, ,
SSAOC~-GN-SE1PPUR.
,
I
1-------------------------------------------------------------------1
I
I
I ~!!ly~_~OD~~:
,
I
bb: new PURCHASE CEDEF sEgment is inserted in data base
1
II: SEgmEnt to insert alrEady exists in data base
,
GE: segment not found; the requested part number (that is,
I
a parent of the segment to be inserted) is not in the
,
data base
,other: Error ccndition
I
Figure 4-13.
I
I
I
I
,
1
1
,
I
Easic ISR'1 Call
!21!: TherE is no need to check the existence of a segment in the data
base with a preceding retrieve call. DL/I will do that at insert time,
and will notify you with an II cr GE status code. Checking previous
existence is cnly rele~ant if the segment has no sequence field4
CALLS iI'IH CCMMANt CeDES
Eoth unqualified and qualifiEd SSAs may contain one or Ilore optional. t
codes which specify functional variations applicable to either
the call function or the segment qualification. Command codes in aD 5SA
are always prefixed by an asterisk (*), which immediately follows the e
byte segment name. Figure q-1~ illustrates this. Pollowing arE some
important commane codes.
com~and
The 't' commane COdE is tbe ene mcst widely used. It requests nlll to
issue £~!h ~~!!§. A "path call" enables a hierarchical path of segments
to be inSErted or retrieved with one call.
(A "path" was defined
earlier as the hierarchical seguence of segments, one per level, leading
freE a segment at one level to a particular segment at a lower level.)
The meaning of the 'D' cOBland code is as follows:
Por retrieval calls, multiple segaents in a hierarchical path will
be moved to the IIC area with a single call. ~he first through the
last segment retrieved are cencatenated in the user's lIe area.
Intermediate SSAs may be present with or without the 'D' cOlmand
Data Ease Processing
4.21
code. If without, thEse segments are not moved to the user's IIC
area. The segment named in the PCB "segment name £eedtack area" is
the lowest~level seg~Ent ~et~ieved. cr the last level satisfied in
the call in case of a non~found condition. Higher-level segments
associated witb SSAs having the 'D' command code will have teen
plaCEd in the user's I/O area even in the not-found case. The 'D'
is not necessary for the last SSA in the call, since the segment
which satisfies the last level is always moved to the user's IIC
area. A processing option of 'F' must be specified in the fSEGEN
for any se~ment tY~E fc~ which a ccmmand code 'D' will te used.
For insert calls, the 'D' ccmmand code designates the first segment
type in the path to be inserted. The SSAs for lower-levEl sEgments
in the path neEd net have the D ccmmand code set, that is, the t
command code is propagated to all specified lower level segments.
Figure 4-14 shows an example of a path call.
r-------------------------------------------------------------------,
1
,
,
GO-FUNe PICTUEE XXXX VALUE 'GUbb'.
, 77
t 01
,
I
SSAC04-GtD-SE1PART..
SSA004-BEGIN PIC'IURE X(21) VALUE 'SE1PABTb*D(FE1PGFNFb='.
SSACC4-FE 1EGENIi FIC'IDBE X (8) •
02 SSA004-END FICTUFE X VALUE ')'.
02
02
,
,
1 01
01
SSA005-GN-SE1FGDSC FICTUEE X(9) VALUE ·SE1PGDSCt'.
IOAFEA FIC'IUIiE 1(256).
,1
,
,
,
,
,
,
,
,
1
-------------------------------------------------------------------1,
CALL 'CEL'Itll' USING GU-FUNC,ECB-NAME,lCABEA,
SSA004-GUD-SE1PAR'I.SSAOC5-GN-SE1FGDSC.
,
,
!
---------------~---------------------------------------------------1
1
I
1
tt: both segments (PART and DESCEIPTION) have been placed
1
in IOAREA
I
GE:
ether:
segment not found; PAET segment may be retrieved in
IOAREAi check sEgment name and level indicator in FCB.
errCI: condition
Figure 4-14.
Sam~le
,
,,
I
Path Betrieve Call
The above exam~le sho~s a common usage of the path call. Although we
don't know if the requested part has a separate DESCBIPTION segment
(SE1PGtSC). we retrieve it at almost no additional cost if there is one.
The ce~rect usage of path calls can have a significant performance
advantage. You should use it whenever possible, even if the chance of
the existence or thE nEed fc~ thE dependent segment(s) is relatively
small. Fo~ instance, if you would need, in 10~ or more of the
occurrences, the first de~Endent segment after you inspect the parent,
then it is generally advantageous to use a path call to retriEVE them
toth initially.
4.22
IMS/VS Primer
l!_~Q!!!.!!gn.9_~Q.9j
When a replace call fellows a ~ath retrieve call, it is assumed that all
seg~ents previously retrieved with the path call are being replaced.
If
any of the segments have nct been changed, and, therefore, need not be
reFlaced, the 'N' command code may be set at those levels, telling Dl/I
not to replace the segment at this level of the path. The status codes
returned are the same as fer a regular re~lace call.
This command code allows yeu tc back up to the first occurrence of a
segsent under its parent. It has meaning only for a get next call. A
get unique call always starts ~ith the first occurrence. Command code F
is disregarded fcr the root segment.
This cemmand code allows yeu to retrieve the last occurrence of a
segment under its parent. This command cods should be used whenever
applicable.
=_~Q!Q!Q'!Jl.2_~2.9§
The hyphen is a null ccmmand cede. Its purpose is to simplify the
maintenance of S~As using command codes.
DA!A BASE POSITICNING AFTEF A tl/1 CAll
As stated before, tbe data tase ~csition is used by DL/I to satisfy the
next call against the PCB. !he segment level, segment name and the key
feedback areas of the FeE are used to present the data tase positier. tc
the application Frogral.
The following basic rules apply:
1.
If a get call is ccmpletely satisfied, current position in the data
base is reflected in the FCE key feedback area.
2.
A replace call does not change current position in the data base.
3.
Data base position after a successful insert call is immediately
after the inserted segment.
4.
tata base position after return of an II status code is immediately
prior to the duplicate segment. This pcsitioning allows the
dUFlicate segment to be retrieved with a GN call.
54
tata base position after a successful delete call is immediately
after all depEndents cf the deleted seglent. If no dependents
existed, data bas's position is immediately after the deleted
segment.
6.
Data base position is unchanged by an unsuccessful delete call.
1.
After an (partial) unsuccessful retrieve call, the PCB reflects the
lowest level segment which satisfied the call. The segment name or
the key fEEO tack lED9tb shculd be used to determine the length of
the relevant data in the key feedback area. Contents of the key
feedback area beyoDd thE lEngth value must not be used, as the
feedback area is never cleared out after previous calls. If the
Data Ease Processing
".23
level-one (root) 55A cannot be satisfied, the segment name is
cleared to blank, and the level and key feedback length are set
to O.
In considering 'current position in the data base', it must be
remembered that DL/l must first establish a starting position to be used
in satisfying the call. !his starting position is the current position
in the data base for get next calls, and is a unique position normally
established by the root 55A for get unique calls.
The following are clarifications of 'current position in the data base'
for special situations:
•
If no current pcsiticn exists in the data tase, then the assumed
current positicn is the staxt of the data base.
•
If the end of the data base is encountered, then the assumed current
position to be used by the next call is the start 6£ the data base.
•
If a get unique call is unsatisfied at the xoot level, then the
current position is such that the next segment retrieved would be
the first Ioot segment ~ith a key value higher than the CDe of the
unsuccessful call, EXcEFt when end of the data base was reached (see
above) or for HDAM, where it would be the next segment in physical
seqUEnce.
You can always reestablish your data base positioning with a GU call
specifying all the segment key values in the hierarchical path. It is
recommended that you use a get unique call after each not found
condition4
USING MUL!IFLE FCEs FCF eNE DATA SASE
Whenever there is a need to maintain two or more independent positions
in one data base, you shculd use differert PCBs. This avoids the
reissue of get unique calls to switch forward and backward from ODe data
base record or hierarchical Fath to another. TheIe are no restrictions
as to the call functions available in these multiple PCBs. Eowever, to
avoid "position. confusion" in the application program, you should not
apply changes via tliO peEs to the same hierarchical path. ; For
simplicity reasons you should limit the updates to one PCB unless this
would cause additional calls.
SYSTEM
SE~VICE
CALLS
Besides call functions for manipulating data base segments, tL/I
provides special system service calls. The most common ones are:
•
STATISTICS lStA!) -- This call is used to obtain various statistics
f Icm DL/l.
•
CHECKFCIN! (CH~~ -- CH~F informs tt/1 that the user has
"checkpointed" his ~rc9ram and that it thus may be restarted at this
pcint. The current position is maintained in GSA! data bases. For
all other data bases, you must reposition yourself after each
checkpoint call with a get unique call.
•
RESTART (XR5~) -- XRSt requests D1/1 to restore checkpointed user
areas and reposition GSA! data bases for sequential precessing if a
checkpoint ID fcr restarting has been supplied by the call or in the
JCL.
4.24
IMS/VS Primer
the XESt and CHKF calls viII be discussed under the topic "Batch
Checkpoint/Restart" later i~ this chapter.
The STAT call retriEves the statistics information of the data base
buffer Fool(s). A discussion of those pools and their statistics can be
found in Chapter 5: "Optimizaticn." We will not include a detailed
discussien of the S~A! call. Instead we provide a general subroutine,
DFSOAst in I~SVS.FR1MESBC, which performs the STAT call, formats and
prints the statistics. This subreutine can be called from any tL/I
batch program. to obtain the print of the statistics you must include a
SYSOUT card in the JCL with ddname of I/DCCS~A~. If you don't want the
statistics, just leave out this tt statement.
!he tasic format of the call statement to call this subroutine in COBOL
is:
r-------------------------------------------------------------------,
(SING pcb-name.
,
L-----------------------------------------------------------.-------J
I CALL
'DFSOAS~'
can be any data tase PCB in yeur program.
pcb-na~e:
No status code checking should be done after return. Typically, the
statistics viII te requested at the end of each batch program.
PROCESSING GSAM DA7A EASES
All accessing to GSAM data tases is done via OL/1 calls. A check is
made by DL/I to determine whether a user request is for a GSA~ data
base. If so, control is passed to GSAM, vhich viII te resident in the
user region. If not, centrel is passed te DL/I, and standard
hierarchical processing will result.
Calls to be USEd for GSA! accEssing are:
r-~--------~---·---------------~--------------------·------~-~~~~~~-,
I CALL 'CBLTDLI' OSING call-func,pcb-name,ioarea.
where:
call-func
is the name of the field vhich contains the call functicn:
•
•
OPEN
Cpen
CLSE
Clese
•
GN
Retrieve next sequential record
•
ISli'I
Insert a new logical record (at end of data
base only)
GSA~
GSA~
data base
data base
!he open and clesE call are optienal calls to be used to
explicitly initiate or terminate data base operations. The
data base will automatically be opened by the issuanCE ef the
first processing call used and autcmatically closed at
"end-of-data" or at program termination.
Data Base Processing
4.25
Eecords may net bE randomly added to GSA" data sets. ThE data
set may be extended by cpening in the load mode, with tIS~=MCt,
and using the IS~T function code.
•
pcb-name
is the name of the GSAM PCB
•
ioarea
is thE namE of the I/O area for GN/ISRT calls, or the optional
address of the C~!~-option for an OPEN call. The OPEN cFtion
is Either IMP, OOT, er, in the case of SYSOUT type data sets,
OUTI or CUT! to include the standard print or punch control
characters (A fer ASA, M for Machine).
STATUS COtES:
•
bb:
CR, proceed
•
GB:
end of data (get next only)
•
other:
EECCRD
error situation
FO~M17S:
Records may be fixed or variable length, blocked or unblocked. Records
Kust be unkeyed. 7he inclusion of carriage control characters may also
be indicated in the Jet RECF! subparameter {for example, RECFM=FBA) for
all record forlats. ThE record in the ICAREA includes a halfword record
length for variable length records.
Sample GSAM processing is shewn in programs PE1epPUR and PE3CPPUR
(members tFSICPOR and DfS3CPOR, respectively) in IKSVS.PRIMESEC.
The uee of GSI! data sets in a checkpointtrEstart environment is further
discussed later in this chapter.
LOADING A BASIC DATA BISE
After generating tbE Fhysical DBD~ you can load your data base using a
load program. Basically the load prograa reads a sequential file with
the data base record contents; it builds the segments and inserts them
in the data tase in hierarchical order. Quite eften the data to be
stored in the data base already exists in one or more files, tut merge
and sort operations lay te required to present the data in the correct
seguence. Sometimes even clean-up and correction activities are
required, especially when multiple files with redundant data are merged
into one data base (see ligure 4-15).
4.26
IMS/VS Frimer
CLEAN-UP &
FORMAT
PROGRAM
DB lOAD
PROGRAM
lOAD
REPORT
DATA BASE
Figure 4-15.
Basic Data Ease lead Frocess
~!!El~_Q!t!_~!§!_!2!g_!~Qg;!!
The samFle data base load program DFSOAtEL in IMSVS.PRIMEJOE may te USEd
to load the samplE data basEs. It may also be used as a general data
base lead program to load your own data basEs. Furthermore, you will
find this program, dUE to its medular structure, easy to modify should
you wish to do so. to use the program as it is, use the following
guidElines:
•
The input data can te any OS/VS sequential file supported by QSAM.
Each seg.ent must be stored in one record with the follewing format:
positions 1 through 3: segaent code (see Figure 2-4), zoned
dEciaal, 001 is thE rcct segment, raximum 255
Data Ease Processing
4.21
Positions 4 to N: not used by the load program; can be used to
store additional sequence fields for sort purposes. N is
defined for each segment in the contrel input.
position N and beyond: the segment data in exactly the format
you wish it stored in the data base.
•
~he input contrel file eentains one card for each segment type to be
loaded, ~ith the follcwing format:
Positions 1-3:
segment code, 001-255
Posi tion 4:
blank or cOlBma
I=ositions 5-12:
segment name
Position 13:
blank or cemma
Positions 14-1i:
pesition of first byte of input data in the
input record: default is 0004 (this is N as
defined for input data above)
Positions 1e-2E:
blanks
Fositions
not used
~7-eC:
!his load program does not manipulate the actual data tase data:
however, it dces previde the hecks to add such functions easily. The
pregram listing sheuld te censulted for guidance.
~Q!~:
When loading a BIDAM data tase initially, you must specify ~BeCCET=LS in
the PCB. Also, the data base records must be inserted in ascending root
key sequence, and the segments must be inserted in their hierarchical
seguence ..
~Q~t~g9_§~9!~D~§_!n_b!§~~!£~!£~1_§~g~~~~§:
If there is a need te sort on
a segment level, you must provide the following sort control fields ~ith
each segment (figure 4- 16) :
I lEVEL 2 I lEVEL 2 , lEVEL 3 I LEVEL 3 ,
etc .•
I S!t:f!EN'I I
I:1 20 I .
0(+ FE2F'crCD
PIC X(6J.
PIC XI 35 ) .
02 OUT-F..PPOP
oon<::o
000300
ooo:n 0
000320 01 SE2PCUST.
04 FE2F'OIUH
PIC X(6) .
000330
FEZPOU,H
O~
000340
PIC XI 20).
PIC X(201.
04 FE2PUDo
000350
04 FE2rC':H
PIC XIZOI.
0003:'0
PIC X161.
04 FE.:rcrCD
000370
PIC XI 40 I.
04 fILLER
OC0380
0003"0
000400 01 CUSTO~fP-SSA.
04 FILLEP PIC XI191 VALUE 'SE2PCUSTIFE2PCNUM
OOOUO
04 SSI'.-O:UM PIC X( 6 I.
000420
0:'
F ILLF.:P
PIC X VALUE ' I ' .
000430
000/;40
000'~50 LINKAGE SECTICtl.
000460~
PCB FOR H1PUT OUTPUT LOGICAL TERHINAL
000470 01 CHC.
000480
02 FILLEP
PIC Xll0).
000490
02 CIPCSTAT
PIC X(2).
000500*
PCB FCP CUSTOMER DATABASE
000510 01 DIPC.
PIC Xll01.
000520
02 FILLER
PIC X( Z ) .
000530
02 DIPCSTAT
0005'+0
EJECT
000550
000560 PPOCEDURE DIVISION.
000570
ENTRY 'DLITCBL' USING C1PC, D1PC.
000580
OOOO~,OO
0000700
0000[,00
0000900
0001000
0001100
0001200
0001300
00014(;0
0001500
0001600
0001700
00012.00
0001<;GO
000;:000
00C2100
000::::00
0002300
000,400
01'0;:500
000::600
00027CO
OOO:::COO
eoo:'l~o
00('3')00
0003100
000320')
COO3:~O
e003400
00035CO
000::600
0003700
00')3:)00
0003<::00
OOOt.ooo
-
ooe '.100
000(.2CO
000(+300
OOO.c; JO
0,)0l,50:l
00 C';.;, C0
000(+700
000 1.. 800
000(.'100
0005000
0005100
0005200
0005300
0005:;00
0005500
0005600
OenSiOO
0005800
00059:10
0006000
Data Ease Processir.g
4.61
000590
000600
000610
000620
000630
000640
0006100
PE~FORH
READ-MESSAGE.
PERFORM PROCESS-MESSAGES U}ITIL NO-MORE-INPUT.
GOBACK.
COO~50
READ-MESSAGE.
CALL 'C6LTOLI' USING GU. CIPe. INPUT-MESSAGE.
IF ClPCSTAT = 'GC'
THW ttO'lE '1' TO EIID-S:.IITCH
ELSE IF CIPCSTAT tlOT = SPACES
TliEN C/,LL 'OFSO/,ER' USItlG
ocon 0
C1 PC. BAD -CA LL. IIlPUT -MESSAGE. ERROPT.
000730
000740 PROCESS-MESSAGES.
000750
HQVE FE'.ICGCllR TO SSA-CNUM.
000760
PEHOPI1 PEAD-CUSTC~1H~-DB
000770
IF DIPCSTAT = SPACES
000780
THEil r.O'JE CORR SEZPCUST TO OUT-DETAILS
000790
MOVE SPACES TO OUT-ERROR
OOOuCO
ELSE tl0VE t~QT-FOtJ~:o-tlS~ TO OUT-ERROR
000810
MOVE SPACES TO OUT-DETAILS.
000820
PERFORM ISRT-HESS~GE.
000·330
0006~0
000670
000680
000690
000700
000710
00~S40
PERFORM READ-MESSAGE.
000850
000060
000870 READ-CUSTOMER-DB.
CALL 'CBLTOlI' USING GU. OlFC. SEZPCUST. CUSTOMER-SSA.
000e.':0
IF DIPCSTAT = SPACES OR 'GE'
00C890
THEU tlEXT SEtHEtlCE
000900
US: CALL 'DFSOAER' USING DIPC. BAD-CALL,
000910
000920
SE2PCUST, EPFOPT.
000930
000940 ISRT-MESSAGE.
000950
CAll 'COLlDLI' USWG ISRT, CIPe. OUT-MESSAGE, HOONAHE.
000960
IF CIPCSTAT NOT = SPACES
000970
THEN CALL 'DFSOAER' USING ClPC. BAD-CALL,
000980
OUT-MESSJ.GE. ERPOPT.
SA~FLE
0006~00
0006300
0006400
0006500
0006600
0006700
0006800
0006900
0007000
0007100
0001200
0007300
0007400
0007500
0007600
00077CO
0007800
0007900
0008000
0008100
0008:00
0008300
0008400
0003500
OC08600
0008700
0008800
0~oe900
0009000
0009100
0009200
0009300
0009400
000<:;500
0009600
0009700
0009800
0009900
0010000
PL/I INQUIRY MFF
listed belov is a samFle Pl/I MPP, PE4FNINQ (member DFSqPNAM in
IMSVS.PBIMESBC). ~his program expects a terminal to input the customer
number. It viII display the customer name and address. It uses the
sample formats cf mEmbEr OE4CNIC1 in IMSVS.PRIMESRC. Job //SAMi4S1 can
be used fer its compilatioDft
4 .. 62
IMS/VS Primer
PE4NINQ:
**
1*
P~OCEDU~E
(CIFC_FT~,DIFC_PT~)
0 E C L A RAT ION S
**
OPTIONS (MAIN);
*1
OCL 1 CIPC BASED (CIPC PTR),
2 FILL CHAR (10):
, STAT CHA~ (2),
1 DIPC BASED (DIPC_PTR) LIKE CIPC;
DCL
1
INPUT_MESSAGE,
2 FILLI CHA~ (6),
2 TRANS CODE CHA~ (9),
2 FEOOGCU~ CHA~ (6),
2 FILL2 CHA~ (601,
lOUT MESSAGE,
2 O~T_LL INIT (111) FIXED BINARY (31),
2 OUT_ZZ INIT (01 FIXED BWARY (15),
2 OUT_DETAILS,
3 FE2FCNUH CHAR (6),
3 (FE'FCNA.H,
FE,FCADR,
FE,FCCTY) CHA~ (20),
3 FE2PCFCO CHAR (6),
OUT_ERROR CHA~ (35),
SE2PCUST,
2 CUST_DETAILS LIKE OUT_DETAILS,
, FILL CHAR (40),
CUSTCMER_SSA,
2 FILLl CHIR (19) IN IT ('SE2PCUST(FE2PCNUH :'),
2 SSA CNUH CHA~ (6),
2 FILL2 CHAR (11 nUT (')');
DC L
(( GU
INIT (' GU' ) ,
ISRT !NIT (' IS~T' ),
ERROPT HUT (' 1 ' )) CHAR (4),
(t'O~tJAnE HaT (' OE4c~nOl • J •
8AD_CALL UHT ('BAD C.ALL'») CHAR (8),
!THREE INIT (31,
fOUR INIT (4» FIXED BINARY (31)) STATIC.
(ClPC_PTR,DIPC_PTR) POINTER.
(PLITDLI, DFSOAER OPTIOtIS (ASSEMBLER J) EN1~Y j
* * PRO C E S S
1*
M E S SAG E S
**
*1
CALL PLITDLI (THPEE.GU.CIPC PTP.INPUT MESSAGE);
IF CIPC.STAT : 'QC' THEN RE~URN;
IF CH'C . STAT .. = ' ,
THW CALL DFSOAEP. (CIPC,BAD_CALL.WPUT_MESSAGE,ERROPTli
SSA_CtlUH
FEOOGCtlt;l;
**
1*
REA 0
C U S TOM E R
D A TAB A S E
* *
*1
CALL FLITDLI (FOUR,GU,DIPC PTR.SE2PCUST,CUSTOHER SSA);
IF DlRC.STAT 'THEIl DO;
OUT DETAILS = CUST DETAILS;
OUT=ERROR = ' ' i Elm;
ELSE IF DIPC.STAT = 'GE' THEN DO;
OUT ERROR: 'INVALID NUMBER - PLEASE RE-ENTE~';
OUT=DETAILS = ' ';
Elm;
ELSE CALL DFSOAER (DlPC,BAD_CALL.SE2PCUST,ERROPT)j
1*
**
1 NS E
~
T
MESS AGE
**
*1
CALL PLITDLI (FOUR,ISRT.CIPC_P1R,OUT_MESSAGE,MODNAME);
IF CIFC.STAT .. : ' ,
THEN CALL DFSOAER (CIPC,BAD_CALL,OUT_MESSAGE.E~ROPTI;
GO TO READ_MESSAGE;
END PE4tUNQ;
0000010
0000020
0000030
0000040
0000050
0000060
0000070
0000050
0000090
0000100
0000110
0000120
0000130
0000140
0000150
0000160
0000170
0000150
0000190
0000200
0000210
0000220
0000230
0000240
0000250
0000260
0000270
0000280
0000290
0000300
0000310
0000320
0000330
0000340
0000350
0000360
0000370
00003M
0000390
0000400
0000410
0000420
0000430
0000440
0000450
0000460
0000470
0000480
0000490
0000500
0000510
0000520
0000530
0000540
0000550
0000560
0000570
0000560
0000590
0000600
0000610
0000620
0000630
0000640
0000650
0000660
0000670
0000680
0000690
0000700
0000710
0000720
0000730
0000740
0000750
0000760
Data Ease Processing
4.63
HA~DIING
EFRCR stAteS CetES
The handling ef errer status cedes in an ~PP is the same as previously
discussed for a DL/1 batch program. the same status code error routine
can be used. See the section "Status Code Error Routine" earlier in
this chapter.
For an introduction to ecnversational precessing, see Chapter 3, "Data
Cemmunication Design," in the section entitled "Conversational
procEssing."
RETRIEVING THE SPA AND 1ERM1NAl INPUt
When an MPP that precesses a conversational transaction code receiVES
control, the GO call against the I/O PCE retrieves the scratch pad area
(SPA). The sucsequent GN call will retrieve the actual input message.
Data saved in the SFA can be in any form. The GU call for retrieving
the SPA in COEOL is:
,------------------------------------------------------,,
I CALL 'CBLtDlI' USING GU-FUNe,IC-PCB,SFA-ABEA.
In PL/I:
r------------------------------------------------------,
I CALL PLITtLI ItHREE,GO_FONC,IO_PCBP'IR,SPA_AREA):
,
l------------------------------------------------------J
tb:
SPA retriEVEd in werking stoIagE field SFA-ABEA.
QC:
No mere input transactions: return control to IMS/VS.
ether:
Error situation
SCBATCHPAD AREA
FOB~AT
The SPA format is:
'lEAl: CeDE
LL I XXXX
U SEE WORK AEEA
L---------------------------__________________________
-J
where:
LL
is a halfword binary field containing the total numcer of
characters in the SPA, including LL, XXXX, TRAN CeDE, and USER
iOFK AREA. This field must not be modified by the user. 'Ihe
size of all SPAs in cur subset is fixed at 1300 bytes. When
PIlI is used, the 11 field must be declared FIXED BINARY (31),
a binary fullwerd. The two extra bytes must not be included in
the LL value.
xxxx
is a 4-tyte area ~eserved for IMS/VS.
modified by the userQ
XXXX must not be
!EAN CODE
is an 8-tyte field ccrtaining the trarsaction code that caused
the progIam to be scheduled. The transaction code can te frem
1 to 8 tytES, left-justified, ano Fadded with blanks.
If the MPP processes both conversational and
Den-conwersational transactions, the !RANCODE should be checked
after the GU to d~termine if a GN is required.
~Q!§:
USER WOEK AREA
This area is for retaining user informaticn (for example,
intErmediate calculations, data retrieved from the data base,
or previous input data) required by the MPP for processing of
sutsequEnt inFut data frem the same terminal. This area is
cleared to binary zeros on the initial entry of the
convErsation.
After the input scratchpad area and input message have been
obtained, one or more data base calls may be made and one
output mEssagE may te built. ~he applicaticn program may wish
to Ietain data entered from the terminal or obtained from data
tasEs. !his data is saved in the user work area portion of the
scratchpadu
In general, three ditferent categories of data can be stored in the SPA:
•
Conversaticn ccntrcl data, used to interrelate the successive input
messages of a terfinal.
•
InFut data sawed from previous input messages, not yet stored in the
data base.
•
tata tase information already IEtrieved in the processing of
Frevious input frol the tEIminal.
!he cenversational control data is used to keep track of the
conversation. You should IeccId which inFut fields were in error, what
the next expected input would te, etc.
You must also saVE data base pcsition information (for example, root-key
values) as IMS/VS vill have cleared the data base position during
synchrcnization point processing. This will occur between terminal
intEractions.
InFut data must be saved in thE SPA if you don't vant to update the data
base until all input is received and succEssfully processed.
Saving data tase data in the SFA should only be done if doing sc would
save IL/l data base calls during ~Iocessing of subsequent input messages
of this terminal.
Data Base Frocessing
4.65
From a terminal operator's viewpoint, the format of the input data at
the terminal is the sa~e as any nonccnversationaL transactionetype
messageQ IMS/VS removes the transaction code from the message segment
and places it in thE scratch pad area. lhe message segment is left
justified to remove the transaction cods. It is retrieved ty the GN
call issued after the GU call that retrieved the scratchpad. The layout
of the input message segment data processed by MFS is as defined in the
MIt.
~~S~:
If the transacticn cede is defined in the MID (as we do), IMS/VS
w11l only remove this trar.saction code at the !j£§! pass. If the same
MID is used for sutseguEnt FassEs the 9 byte TRANCODE field defined in
the MID will be present. See sample program PE4CORDR (member DfS4CNEW
for COBOL, or DFS4F~EW for FIll) in IMSVS.PRIMESRC for more details.
DAlA BASE PROCESSING IN CCNVEESATIONAL MetE
The actual DL/1 data baSE calls fcr a conversational program are exactly
the same as before.
Bemember, the !FF's data base position is cleared by 1HS/VS
synchronizaticn peint Frceessing between successive terminal input
messages (interactions).
INSERlING
~HE
SFA
A~t
TEE~l~AI
CUTFUl
If the application program modifies or initializes any SPA fields, it
mus~ return the SPA to IMS/VS before issuing anether GU or terminating.
A SPA is returned to I~S/VS by inserting it to the I/C PCB.
lhe insert IISEt} call for ceECl is coded as follows:
r------------------------------------------------------,
I CALL 'CELTDLI' USING
IO-PCB, SPA-AREA.
I
ISB~,
l~--~~--~~----~-~----~-----~----------------~---~~~----~
cr, in FI/I:
r------------------------------------------------------,
, CALL PLITtLl
,
(TEREE,IS~T_PUNC,IO_PCBP1B,SPA_ABFA);
L------------------------------------------------------~
bb:
Call successful,
other:
Error situatien.
SEA
accepted ty IMS/VS.
A response to thE cri9inating terminal is required to allow the
ccnversation to continucQ The terminal operator is prevented frcm
entering more data to te FrccEssed (except IMS/VS commands) until he has
received this I~spcnse.
!he output messa9E se9ment fermat fer a conversational application
program is the same as fcr any nonccnversational output message.
4.66
IMS/VS Frimer
A conversation may tE tErminatEd by the ccn,ersaticnal ~rogram, terminal
master terminal operator, or IMS/VS. A conversational ~rcgram
terminates a conversation ty:
c~eratcr,
•
Blanking the transaction code in the SPA and returning the SF! to
IMS/VS through an ISET call. This terminates the conversation as
soon as the terminal has rEceived the message response. This is the
recommended frocedure.
The terminal OpErator terlinatEs a conversation by:
•
Entering a IEII1 ccmmand frOm the terminal participating in the
ccnversation.
The mastEr tErminal operatcr tErminates a ccnversation ty:
•
Entering a IEXl' ccmmand which specifies the terminal in
ccnversa tion.
•
Entering a 1~1AE~ lINE (no
terminal in ccnversaticr..
PTIE~
specified) for the line of a
IMS/VS terminates a conversation if, after a successful GU or insertion
of the SEA, a conversational application program fails to insert a
message. WhEn this situaticn cccurs, IMS/VS sends the message DFS32721
NO RESPONSE, CONVEHSATION TER~INATED to the terminal, ends the
conversation, an6 complEtES synchronizaticn point ~rocessing4
When terminating the ccnversaticn, IMS/VS deletes the current SFA. If
the next terminal input message is for a conversational transacti~n, a
fresh SPA is made availatle tc the Frogram. It is recommended that you
terminate the conversaticn at each legical end (for example, when an
crder is stored in the data base) of an interactive session. This can
best bE done by the ~PP. Because the transaction code is defined in the
MID, no special terminal operator action is required to restart thE same
conversation (for Examfle, Ent~y of next order). A transaction code
Fassword is required for each first pass of the conversation if it is a
password protEcted tratsacticn.
1.
You should im~lemEDt a standard subfuncticr. cede (for exam~lE, END)
in a Fredefined input fermat field to allow the terminal operator to
request the ~EE to terminate the conversation.
2.
A hElp function (fcr ExalFle, HELP) is recommended for complex
con,ersations. The MPP could resend the latest message based on SFA
ccntent together with advice about the next possible action.
ROLES FeR
iRI~ING
CCNV!ESA!IC~Al
IECGEAMS
The following rulES shculd tE cbsErved when writing conversational
Fro9rams within cur sutset.
•
first 6 bytes of the SF) cannot be modified in any way ty the
application Fro9ral.
(IMS/VS uses these 6 bytes to identify the
SPA. )
•
~c
~he
terminate a conversation, the transaction code (beginning in
position 7) should te changEd tc blanks.
Data Base Processing
4.67
•
If modified by an aFElicaticn program, the SPA must te returned to
IMS/VS through an ISR~ call in order to make the updated SFA
available during the next interaction of the conversaticn.
•
~he SFA cannot te IEturned te IMS/VS more than once (that is, fer
Every GU call fer tbe SPA, there is only one ISRT call for the SPA).
•
One and only one response output message must be inserted to the
I/C-PCB for each S~AIr.SG input. This message can consist of as many
segments as required.
•
Cenversational programs must be designed to handle the condition in
which the fiIst GU call to the I/O-FCE produces no message to
process. this cendition can occur if the oEerator cancels the
ccnversation through an /EXIT command, prior to the program issuing
a GU call, and this was tbe only message in the queue to be
EIccessed.
WRllING A CCNVEESA!ICNAI !FF
ThE basic flow of a cenvErsaticnal MPP and the message calls used are
shewn in Figure ~-~~ and described in the following.
4.68
IMS/VS Primer
START
INTIALIZE WORKING STORAGE
2
GU CALL FOR SPA
3
GN CALL FOR INPUT MSG
4
INPUT VALIDATION
DATA BASE PROCESSING
5
+
6
ISRT CALL FOR SPA
t
7
ISRT CALL(S) FOR OUTPUT MSG
8
Figure 4-24.
Conversational MEE flew and Calls.
ThE following notes relate tc the numbers in Figure 4.24:
1.
After receiving ccntrel, the MPP must initialize its vorking storage
as this may contain leftover data from a previously processed
messagE (likEly frcm accther terminal).
2.
The MPP retriEVEs thE SPA with a GU call, referencing the Ie-FeE. A
blank status code means the SFA is placed by IRS/VS in the SPA-ABEA
specified in thE call. A OC status code means, there are no more
messages in the input queue. The !FF must then return control to
Data Ease Processing
4.69
IMS/VS. Any other status code is an error condition and should be
handled by an error code status routine (see "handling Error Status
Codes" earlier in this chaFter).
3.
The actual terminal input is retrieved by a GN call, referencing the
same Ie-FeE. A blank status code means the one input messagE
segment is placed by IMS/VS in the MSG-AREA specified in the call~
Any other status code is an error condition.
4~
lhe input is validated.
This should include:
•
Checking the Sf A fcr status cf conversation; what was the
expected itput
•
Checking the length of input message
•
Checking the format, value and consistency of input field using
conversaticn eentrel informaticn in the SPA.
This validation should be as complete as possible and be done before
any data base accesses.
5.
lhe data base processing is done as before. Data base elements and
their updatE status required for subsequent input message processing
can be sa~ed in the SFA.
6.
lhe updated SFA is returned to IMS/VS with a ISRT call. Only a
blank status ccde is acceptable. If the SPA content is of no use in
the processing of the next terminal input, the conversation should
be terminated ty blanking the transaction code in the Sf A before the
ISR! call.
7.
~he
Eq
lhe processing cf the current input message is now completed. 1he
Frogram shculd ncw gc back to the initialization of its working
storage and the retrieval of the next SPA + input message (if any).
response output message is inserted to the originating LlERM via
the I/O-peE. One ISR~ call is required for each output message
segment. Any non-blank status code is an error conditior.
SA~FLE
CCNVEBSAIICNAl
P.~Is
Two CCEOL and PL/I ccnvErsaticral MPPs are included in IMSVS.PRIMESRC:
•
PE4CORDR
(member
DF~qCNE.
fOI COBOl and DFS4FNEW for FI/I), which
frocesses transaction TE4COFtR for the insertion of new custcmer
orders intc the data base.
•
PE4COCDEL for COBOL and DFS4PDEL fCI PL/I (member DFS4DEL), which
Frccesses transactions lE4CODEL and ~E4CCCNG for the deletion and
change, respectively, of customer orders in the data tase.
You should study tbese FIcgrams, eSFecially the way they handle the
inFut message, output messages, and the ~PA.
Testing of a MPP can most efficiently be done in batch mode using a
terminal simulatcr Frogram, such as the FDP, ~~!£h I~~minsl ~i!Yl~!~~
I!, 5196-PG1.
Fcr mere information see SH20-1S44, "ETS II Program Descripticn And
Cperation Manualu"
4.70
IMS/VS Frimer
This chapter consists cf thrEe farts:
1.
IntIcduces the function of data base reorganization in a DIll
environment. It is a first-time in~roduction into the requirements
for, and the ~Ioces~ ~f, data base recrganization. It gives an
cvervie~ of the DIll u~ilities for ~eorgdnizaticn to be used in the
sutset.
2.
Gives a for.mal description of the available DL/I utilities for data
base reorgani2ation.
As such, it is the main source of referencE
for the actual use of the utilities.
3.
IntIoduces the use of the utilities for a particular environment.
It froceeds along the three phases of our subset sample environment
from the reoIganizaticn cf ene data base up to the transition of one
Fhase into another~ Samples are provided for each function. It
contains guidelines fcr the d~sign of yeur own reorganization
Frcced~res.
ReoIganization is the process o.f changing the physical storage and/or
structure of a data base tc tetter achieve the applicatioL's pcriocmance
requirements. ie distinguish tetween the following two types:
•
Physical reorganizaticr:, tc optimizg the physical storage of the
data base.
•
Logical rgorganization, to optimize the data base structure.
Physical reorganizaticn is
ner~ally
required by one of the following:
•
Degradation in proc~ssin9 program performance due to degraded data
base storage, that is, the segments belonging to onE data tase
r~cord are sterEd eVEr eXCEssive CI/blcCKS.
This is normally shown
by an increase in the number of physical 1IOs per transaction.
Chapter 9, "Optimizatien," Frovides guidelines for monitoring this.
Additionally, the VSAP. catalog contains the number of centrol
interval Ie!) and ccntrcl area (CA) splits. This information can be
printed ~ith access method ser~ices.
•
lack of free space in the data base, caused by (foreseen) largE
quantities of s~gmEnt inSErts. Again, for VSAM, the catalog will
previde information on this. For HDAM/CSAM the VTOC can be checked
for the use of seccndaIY extents. Alse, for HDAM, an increase in
the number of I/Os per transaction could indicate ap BAA (rc~t
addres3able area) which is tee small.
Should an acnorlal termina~icn due tc lack of disk space occur
during ncrlal Frccessing, ~he standard recovery procedures of Cha~~~r 6,
"Data Base Recovery," should be used. The allocated space to the
affected data base must cf CCUIse be increased.
]E!~:
tata EaSe
Eeorganiza~ion/Load
Processing
5.1
logical recrganization is normally caused bj design chanqes in the data
base. In our subset we will address some changes under the topic
"Applying Structural Changes" later in this cha~ter.
THE fREQUENCY O!
REORGANIZA~ION
~he freguency cf reorgani2ing is largely dependent on the a~~licaticn
environment. HCWEVEr beth VSAM and DL/I contain special facilities to
minimize the nEed fer reorganization. If the initial allocation of
sFace includes suffici~nt (distribut~d) free space, the need for
physical reorganization weuld ncrmally be quite low (typically once or
twice a year).
~l~g§_I~_~~Q~~A~!~~IIQ]
!here are three major LtEPS in reorganization:
1.
2.
Unlcad the data
tasE~.
Delete the old space, redefine the new space, and optionally change
parameters (tEtG!~).
DBD
3.
Restore the data bases.
Eecaus@ step 2 atevE deletes the existing data base, it is recommended
that you make an image cc~y (SEe Chapter 6, "Data Base Recovery") just
before you do ~he unload. Another method would be to rename the old
data spacE and define ~ew data s~ace. !he old data space can then be
deleted after reorgani2ation and subsequent imag~ copies arE made.
You should also make image dumps of all your data bases immediately
after the relcad and tefcre any a~plicaticn program is executed.
The tL/I reorganizaticn utilities provide three basic functions:
1.
The reorganization of 0111 data bases.
2.
Establishing logical relationship connections when initially loading
data tasES havjng lcgical relaticnships.
3.
Creation of secondary INDEX data base(s) when you load data bases or
when ycu reorganize ~hem.
!he seven basic utility
reorganizaticn/load
~ro9rams involved
~rccEssin9 are:
1.
INDEX Beorgani2ation Unload
2.
INDEX Reorganization Peload (DFSU BELO)
3 ...
HD Beorganization {lnload (DFSU BGUO)
4 ..
flD
5.
Data EaSE
Prerecrgari2aticn (DFSORPRO)
6.
Data EaSE
Pr~fix
7.
tata Ease PrefiJ Update
5.2
(DF SUR
OLO)
Beorganizaticn EElcad (DiSU EGLO)
IMS/VS Primer
REsoluticn
(DF SURG 1 C)
(DF SURGPO)
in data bas€
Of these utilities, the~e are two types: physical reorganizaticn
utilities ano logical IelaticnsbiF resoluticn utilities.
PHYSICAL REORGANIZA1ION
U1ILI!~
There are twc sets each
~f
PROGRA~S
two physical reorganization utilities.
Ih~_!BQ~!_~!2I~!n!!~!~Qn_~!~!!~!~§
The INDEX Reorganizaticn Unlcad utility (DFSURULO) and the corresponding
INDEX Reload utility (IFSORRLO) can be used to:
•
~ecrganize
the primary index data base of a HIDAM data base.
•
Create a seccndary index data base.
•
Reorganize a secondary index data base.
!he HD Reorganization Unload utility (DFSUBGUO) and the corrEspcnding
Reload utility (r}SURGLO) can be used to:
•
Reorganize a EDAM, HIDAM, cr EHISAM data base.
•
Create ~ork data sets if the data base being relcaded includes
logical Ielationships and/or secondary ind~xes.
•
The HI: utilities should be used for the unload/reload of a SHISAM
data base only if this data base is to be converted to a HDAM or
BItAM data tase.
•
Use of the HD Unload/Reload utilities in making structural changes
to a data base is discussed later in this chapter under "Applying
Structural Changes."
LCGICAL RELATIONSEIP RIS01U110N U!ILI!Y PRCGRAMS
The fcllewing three logical relationship resolution utilities ~rcgIams
are required wben initial leading or reorganizing data tasEs with
logical relationships: (1) Data Base PrerecIganizaticn, (2) Data Base
Prefix Resolution, and (3) rata Base Prefix Update.
This utility creates a control data s~t that is used by other utilities.
This contIol data set is ~eeded when iuitially loading or reorganizing
data base(s) with logical relationships and/or secondary index~s.
~~!s_~~~§_iI~!i!_]~~Q!~!!Qn_TI!i!~tl
This utility comtines and serts all work data sets generated by the ~D
Reload utility o~ by the initial data base load process. This utility
generates an output work data set that contains the prefix information
needed to complete the loading and/or reorganization of data bases which
contain logical relaticnshiFs. If secondary indexes are present, a
s€parate output data SEt is alsc generated, used to build these indexes.
Data Base Reorganization/Load Processing
5.3
£~!~_~!§!_!~!'!!_QEg~~!_~~!li~I
!his utility uses the output data set generated by the Data Base Prefix
Resolution utility to u~datE the prefix of each segment whose prefix
information is affected by a data base load and/or reorganization.
A flow diagram of the INDEX ReoIganization Unload utility is shown in
Figure
5·'.
DBD
LIBRARY
VSAM
KSDS
INDEX REORGANIZATION
.....----~
UNLOAD
DFSURULO
INPUT
CONTROL
STATEMENTS
Figure 5-1.
OUTPUT MESSAGES AND
STATISTICS
INDEX Reorganizaticn Unload Utility
Jet STATEMEN'IS
~he
jet.
INDEX Beorganization Unload utility is executed as a standard OS/VS
ihe follcwing Jet statements are required:
EXEC
This statement must be in the form:
PGM=DFSRRCOO,~AF.M='ULU,tFSURULO·
IMS
DD
tefines thE likrary containing the DBD that descrites
the data base to te reorganized (that is,
DSN=IMSVS.DBDLIB,DISP=SHR). ihis data set must reside on a
direct access device.
SY5PRIN'I
IefinES the
cut~ut
message and statistics data set.
CD
SYSIN
tD
5.4
refines the input control statement data set.
IMS/VS Frimer
,samin
DD
DefinES tbe ~SAM KSDS data set to be reorganized.
The ddname must te the sa~e as the name in the DBD that
descrites this data set. It lust also appear on the
utility control statement in the SYS!N data set of this
jet steF.
dataout
DD
Defines the reorganized output data set. It can be
any nam~, but the name must appear in the associatEd
utility ccntIcl statement. ~he data set must reside on
eith~r tape or a direct access device.
This sequential data set is tlccked to the tlocksize of
the outFut device, uF to a maximum of 16~. Since the
blocking factor is determined at execution time, standard
labEls must te used on all output volumes.
indeIw~k
DD
DFSVSAMP
tt
DeSCIibes the output data set (DFSURlDX) from the
Prefix ~esolution program which contains secondary index
infcImation. ihis statement is required if the utility
contIol statement is type "I"; otherwise, it is optional.
ThE ddname must be the same as the name starting in
position 40 of the control statement.
tesc~ites thE data set that contains the buffer
informaticn rEquired by the DIll Buffer Handler. Thi£ Dr
statement is required.
(For additional informaticn, see
."Defining the IMS/VS Data Base Buffer Subpools" in
~hapter 1.)
UTILITY CONTEOL S!A7EM!NT
,
, B , dbdname vsalin
1 X
ddnamE
datacut
aanalE
indexvrk
ddname
[comments]
I
~his must be either 'F' or 'X'.
An 'R' sbould tE coded if
this is a S€~aIate reoIgani%aticn of an existing INDEX
data base. An
should be coded if this is the creaticn
of an INDEX data base, that is. if the VSAM KSDS is
"emfty."
·x·
2
!his must bE a 1. There is nc default, and if this field
is left tlank an eIror message is generat~d.
4
This must be the name of the DBD that includes the KSDS to
be reorganized.
13
!his must bE thE ddname of the KSDS to be reorgani2ed. It
must apPEar in the referenced DBD, and a corr~sponding DI
statemsnt must have been provided.
22
~his must bE the ddname of the output data set.
A
corresponding DD statement must have been provided.
Data Ease
~eorganization/Load
Processing
5.5
lhis lUSt te the ddname of the secondary index work eata
set if ~his control stat~ment is type "XU.
Comments can be
50
]21§:
All other
~laced
in
~csitions
50 through
eo.
must be blank.
~csitic[s
RE!UBN CODES
This program returns cedes ~r€cedad (in the cas~ of ereors) by numbered
messages to the SY£FRINT data set which more fully explain the results
of program eXEcuticn. The return codes are as follows:
o
All requested
One or more
c~erations
o~erations
have successfully completed.
have not successfully completed.
8
Severe errors have occurred causing job termination.
12
A
06!PD! MESSAGES
combination of error codes 4 and 8 has occurred.
A~D
STAT!S!lCS
~he !NDEX Eeorganiza~ion Unload utility provides messages and statistics
on data tass ccntent fcr each data set. In addition, it provides an
audit trail capability.
EXAMFIE
A discussion cf the use cf t~is utility, together with an example, can
be found under the topics "Reorganizing an INDEX D~ta Ease" and fllnitial
Data Base Load Erocessing" later in this chapter.
A flew diagram of the
Figure 5-2.
5.6
IMS/VS Primer
I~rEX
ieorganization Reload utility is shown in
DBD
LIBRARY
~----------~
OUTPUT MESSAGES AND
STATISTICS
INPUT
CONTROL
STATEMENTS
Figure 5-2.
INDEX REORRELOADED
GANIZATION ~_ _......~
RELOAD
~
INDEX
DFSURRLO
~~~~
IND!l Eeorganization Feload Utility
Jet S'IAiEMEN'lS
The INtEX Reogranizaticn Relcad utility is executed as a standard OS/V5
job. A JOB statement (defined by the using installaticn). an EXEC
statement, ~nd Dt statements that define inputs and outputs are
required.
EXEC
This statemeTlt must be in the form:
PGM=tFSRRCCO,PARM~'ULV.DFSURRI0'
IMS
DC
Defines the litrary containing the tED which describes
The data tase t~ing reorganized. This data set must
reside on a direct accass d€vice.
SYSPRIN'I
tt
rEfinES the
DFSUIN01
tD
Defines the unloaJed input data set.
must be created by D1SUBULO.
vsamout
tefines the KSDS cut~ut data set to be reloaded. The
ddname must be the same as the name in the DED that was
referenced when this data set vas unloaded.
DD
DFSVSAMF
DD
cut~ut
mEssage and
stati~tics
data set.
This data SEt
tescribes thE data set that contains the tuffer
informaticn required by the Dl/I Buffer Handler. This Dt
statement is required..
(For addit ional informaticn, see
"Defining thE IMS/VS Pata Base Buffer Subpools" in
Chapter '. "Installing IM~/VS.")
Data BasE Reorganizaticn/Load Processing
5.7
Note: No SYSIN DD statement or utility control statements are required
for-this utility_
COIES
EE~ORN
The following return codes are Flovided at program termination:
~!!n!ng
o
All OFeraticns have successfully ccmpleted.
4
ene or more warning messagES issued.
8
ene or more operations haVE not completed succEssfully_
16
Severe errors have occurred causing program termination.
OU~PU~
ME~SAGES
ANC STATISTICS
INDEX Reorganization Beload utility provides messages, statistics
and an audit trail for thE data set being reloaded.
!h~
EXAMPLE
A disc~ssion of the use of this utility, together with an example can be
found under tbe topics "Recrganizing an INDEX Data Ease" and "Initial
tata Ease Loaa ProcEssing" later in this chapter.
The Et Reorganizaticn Unlcad utility can be used to unload an HDAM,
HIDAM, or SH!SAM data base to a QSAM formatted data set. There are no
utility contrel statements for this utility.
A flow diagram of the ED Reorganization Unload utility is shown in
Figure 5-3.
5.8
IMS/VS
Frim~r
DBD
LIBRARY
DATA
BASE
DATA
SET
DATA
BASE
DATA
SET
-
-
HD
REORGANIZA·
... TION UNLOADt-----~
DFSURGUO
OUTPUT MESSAGES AND
STATISTICS
Figure 5-3.
fiD Reorganization Unload Otility
JeL
STATEMEN~S
~he
HD Reorganization Unload utility is executed as a standard CS/VS
~he following Jel statEments are required.
jot.
EXEC
~his
statement must te in the following form:
PG~=DFSRFCOO.FA!~='UIU,DFSUEGOO,dbdname'
where the FalaleteIs ULU and tFSURGUO describe the utility
region, and dtdname is the na~e of the DED which describes
the data base to te reorgani7ed.
1115
DD
Defines the litraty (IMSVS.tEtLIB) containing the DBD
which desclitEs tbe data base to be reorganized. This
data set must reside on a direct access device.
SYSPR1N'I
tD
refines the less8gE and statistics output data SEt.
DF5URGU1
Defines the sequential, variatle blockEd output data set.
This DD statelent must be supplied.
ThE data set can reside on either taFe or a direct aCCESS
device. Since output is blocked to the maximum size the
output dEvice can handle. up to SK, standard labels must
be used on output volumes. Standard labels must tE used
on cutput velumEs.
tD
da ta base
DD
Defines the data base data set to be reorganized.
~he ddname must match thE ddname in the DED.
Data Base Reorganizaticn/Load Processing
5.9
If this is a HIDAM data base, you must also includE a DD
statement fer the primary index. That DO name must be the
same as specified in the primary INtEX DBD. Ne 00
statE Dents are required fOI any secondary indexes
associated with this data base. JCL must be included for
all lC9ically related data bases, even though thesE data
bases are not unloaded.
Ihis data set Gust reside en a direct access device.
DFSVSAMP
DD
tescrices the data set that contains the buffer pool
information required by th~ OL/I Buffer HandleI. This DD
statefent is required.
(Fer additional information, see
"Defining the IMS/VS Data Ease Buffer subpools" in
ChaptEr 7, "Installing IMS/VS.")
FETURN CODES
!he following return codes are provided at program terminaticn:
o
tata base unload successful.
4
Cne er morE warning messages issued.
e
SeVEre errer bas cccurred.
12
Multi~le
16
tata base unload not
OUTPUT MESSAGES AND
warning and/or error messages issued.
s~ccessful.
S~A~ISTICS
The HD Becrganization Unload ut~lity provides eut~ut messages and
statistics. An exa~Fle cf the messages and statistics obtained from this
utility, accompanied by eXFlanatory infcrmation, is provided in Chapter
3 cf the I~~L1§ ~~!ID~~ ~2!E!! !i§i!llg§ manual.
EXAMPLE
A discussion of thE use cf this utility, together with an example, can
be fcund under the topic "Reor9anizin9 a HDAM or
HZDA~
Data Ease" later
in this chapter.
T~e HD Fecrganization Eeload utility can te used to:
(a) relead an HDA~
or HIDAM data caSE frcm a data set created by the HD Unload utility, and
(b) create work data sets (if the data base to be reloaded includes
logical relationshi{s cr sEccndary indexes) which are to be used as
input to the logical relationship resolution utilities.
A flew diagram of the Ht Reorganization Feloan utility is shewn in
Figure :-4.
5.10
IMS/VS
~rimer
DATA
BASE
DATA
SET
HD
DATA
BASE
DATA
SET
REORGANIZATION RELOAD
DFSURGLO
/
DBD
LIBRARY
/
/
/
"
~-...-.
---1
/
INPUT
CONTROL
STATMENTS
Figure 5-4.
INDEX
DATA
SETS
/
/
,-_ ......
HD Eeorganization Feload Utility
Jel SlA'IEMEN'IS
The Et Reorganization Reload qtility is executed as a standard OS/VS
jeb. The follc~in9 JCL statements are required.
EXEC
This statement must bE in the form:
PG~=DPSBFCOO,FABl='UIU,DFSOBGlO,dbdname'
where dbdname is the name of the DEt which includEs
data baSE tc te rElcaded.
DD
SYSFIUN~
t~e
Describes the litrary containing the DED referencAd
in the E~EC statement FAFM fiEld (nermally this is
IMSVS.DBDLIB). ~bis data set must reside on a direct
access device ..
Defines the IESS8gE cutput data set.
DD
DFSU1NP!
tD
Describes the input data set £ontaining the data to
tE rEloaded. This is the data set created by the ED
Recrganizaticn Unload utility. 7he data set must reside
either on tape or a direct access device.
tFSORfliF1
tD
tescribes thE data set to be created during reload
that will bE used as input by the Prefix Eesolution
utility IDFSUEG10) to resolve logical or secondary index
relationshiEs. ~his DD statement must always be present.
It can specify Dt DUMMY if the data base is net involved
in logical r~laticn~hips or secondary indexes.
tata Ease Beorganization/Load Processing
5.11
~CB paramEters for the DD statement must include
lRECL=300, REC1M=VE, and ELKSIzr; specified 1:0 1:e tl,E salt€
as that s~ecifi€d for the work data S€t of the user's
initial load program.
A full track blocksize or 8-16~ for
taFe iE reccmmEnded.
~be
~hE data set must reside either on tape or a direct access
device.
database
ED
tefinEs the data base data ~et to be reorgani,ed.
One statement of this tYFe must be present for each data
set that app~ars in the tnc which d~scribEs this aata
tase. ~he ddname must match the ddname in the tEte
If this is a ElDAM data tase, a DD statement must also be
included for the KSDS of the primary index. This ddnaree
is sFEcified in the DBD f cr the inde x da ta base.
No tD
statements are required for any secondary indexes
associated witb this data base.
lhis data set must reside on a direct access devic€.
DFSORCDS
tt
refines the control data set for this frogram. This
data set Must be created by the Pre reorganization utility
(tFSURPRO). ~his DD statement must be included if logical
relationships exist.
Ibis data set must reside cn either tape or a direct
device.
acces~
DFSVSAMP
DD
tescribes the data set that contains th~ buffer pool
information required by the DL/I Euffer Handler. ~his DD
staterent is required.
(For additional information, see
"Defining the lMS/VS Data Ease Buffer SuhFools" in
Chapter 7, "Installing ItJS/VS. tI)
BElDiN cotES
The following return codes are Frovided at program termination:
o
Data tase relcad successful.
16
Cata base reload unsuccessful.
OUTPUT MESSAGES AND
S~A!IS~ICS
The HD Reorganization Reload utility provides output messages and
statistics. An example of the messages and statistics ottained frcm this
utility, is ~rovided in Cha~ter 3 of the !~~L!~ ~;~m!I ~~m~~! li§Iing§.
EX AMPLE
A discussion of the use of this utility, together with an example can be
found undEr tte topic "Becrganizing a HDAM or BIDAM Data Base," later in
t his chapter.
5.12
IMS/VS Primer
The tata EasE PrEreorganizaticn utility creates a control data set that
is used by the ether logical relationship resolution utilities. This
utility must be executed before you initially load or reorganize any
data base which contains logical relationships and/or secondary indexes.
The input to this utility is a data set which consists of the utility
control statements that namE the data base Is) being loaded and/or
reerganized. !he DEDs that are used for the data bases named on these
statements must define each data base as it is to exist after the
logical relationships and/or secondary indexes are established. These
DEts must not be modified ~Dtilthe Prefix Update utility has been
successfully executed.
The output is a control data set that is used by the HD Recrganizatich
Reload and by the tata BaSE Prefix Fescluticn utilities. It is also
used during the initial load of data bases with logical relationshiFs
and/or seconcary indexes.
A flew diagram of the Data Base Prereorganization utility is shown in
Figure 5-5.
CONTROL
DATA
SET
DBD
LIBRARY
DATA BASE
PREREORGANIZATION
UTILITY
DFSURPRO
INPUT
CONTROL
STATEMENTS
Figure 5-5.
OUTPUT
MESSAGES
tata BaSE Prerecrganizaticn Utility
JCL S'lA'lEMEN'lS
The tata Base Prereorganizaticn utility is executed as a standard as/vs
job. A JOB statement (defined by the using installation), an EXEC
statement, and Dr statements that define inputs and outputs arE
required.
EX EC
This statement must be in the form:
FGM=tFSRP.COC,PARM='ULU,DFSUBPRO'
IHS
CD
Defines the litrary containing the tBDs which describE
thE data tasES Damed on the input control statements.
This DD statement must always be included. The data set
must reside cn a direct access device.
Data BasE Reorgani7ation/load Processing
5. 13
Ihis data set viII contain input control state~ents.
DCB paraleters SFEcified within this program are B!CFM=FE
and IFECI=804 EIKSIZE must be provided on this DD
statement. If BLKSIZE is nct specified, there is no
default and the results are unpredictatle.
SY~!N
DD
SYSPRIN~
tt
tFSUFCDS
Dt
tefine the ~essa~e output data set.
7he DCB parameters specified within this program are
RECF~:FE and IBECL=120.
ELKSIZE must be provided cn this
CD statement. If BLKSIZE is not specified, there is no
default and the re~ults are unpredictatle.
te£inEs the cutfut data set fer this program. This
data set is the control data set used by subsequent
utilities. This DD statem~nt must always be included.
DCB paral€ters specified within this program are RECFM=FB
and LRECl=1ECC. SLKSIZE must be provided on this tt
statement.
01ILI!Y
CON~BCI
STA~!~E~TS
80
r-~----~----~---~----·-~---~~~---------~--~-~--------- -------------,
I
, tEIl=database name1,database Dame2,4 ••
,
(comments]
1his utility control statement names data bases to be !niI!sllY l~!g~g.
One or more of these statements can be ~rovided. Each OED name must be
left-justified to provide a total length of a characters. If the DED
name is less than 8 characters, sufficient trailing tlank characters
must be provided to make a tctal of 8 characters. A blank must follow
the last entry on each statement. If a HIDAM data base is to be
initially loaded, only its DBD name should be listed on a DEll control
statement. Neither the HIDA~ primary index nor any secondary index DBD
names should tE listed.
~o
,
, DBR=database name1,database name2, •••
[comments]
Il - - ___________________________________________________
-------------~
This utility centrol statement names data bases to be ~!Q~g!qil~g. Cne
or mere of these statements can be provided. Each DBD name must be
left-justified to provide a tctal length ef 8 characters. If the DBD
name is less than e characters, sufficiett trailing blank characters
must be Frcvided to make a total of 8 cha~acters. A t1ank must fellow
the last entry on Each ~tatelent.
If a HIDAM data base is to te reorganized, only its DeD name should be
listed on a DEB control statement.
(Neither the HIDAM primary indEX nor
secondary indEX DBE DalES should be listed.)
5.14
IMS/VS Erimer
,
,
,
80
CPTICN~='NCPUNCt,STA!,SUP.r.)
~------------------------------------------------------------------~
This utility contrel statEIEnt lust be coded as shewn above in our
subset. It directs the prefix resolution utility to provide statistics
on the number ef sEgments teing uFdated and the number of logical
Farents without lcgical childrenu
RE'IURN
coors
The following return codes are Frovided at Frogram
t~rmination:
o
No errors detected.
8
One or more error messages have been issued.
CUTPUT M!SSAGES
The outpu~ messages issued by this utility indicate the data bas.
operations that must te ferfcrlEd ~rior· to execution of the Prefix
Reseluticn and tha ~refix Update utilities. For instance:
•
Data cases listed aftEr the characters tEIL= in message DFSe611 must
initially lcadec.
be
•
Data bases listed after the characters DER= in message DFS8611 must
be reorganized using- the Ht Eeorganization Unload/Reload a'tilities.
•
rata tas€s listed aft~r the characters tES= in message DFSe€21 ~ust
be specified cn a tBR = ccnt Icl card, a nd the uti Ii ty III ust be
re-executed. If this occurs, you may have omitted a data tass tc be
reorganized.
'the Data Base Prefix Eesolution utility accumulates the infcrmation
generated on wor~ data sets during the lead and/or reorganization of one
or more data bases. It produces an output data set that contains the
prefix information needed to complete the logical relationships defined
for the data base(s) and, optionally, an output data set containing
information needed to lre)create secondary index data bases. There art
no utility contrel statements for this utility.
BES'IRIC'IICNS
The Data Ease Prefix Resolution utility uses the OS/VS Sort/Merge
Frograms. Since the maximum sort field permitted by Sort/Merge is 256
characters, certain limits must te observed. The following restrictions
apply in our subset:
1.
For any given logical parent/logical child pair, the sum of items a
and b below must not exceed 200 characters (the balance of 56
characters is used by IMS/VS for control purposes) :
a.
The length of the logical parent's concatenated key.
Data BaSE ReorgaDization/load Processing
5. 15
b.
1he length of the sequence fiEld of the logical child as seen
ty its lcgical ~arEnt.
The sum must be computed once for the logical parent and once for
the lcgical child. These summations are treat~d separately.
2.
the Data EasE PrerEcrgarizatien utility ~erforms the above limit check
fer lcgical parent/logical child combinations affected by an intended
data base initial lead or reload.
It should be noted that the limit
check is a worst-case check. If the limit check fails for a logical
parent/logical Child combina~ion, message DFS885 will te issued. Refer
to the l~~l!~ ~§§§2S§§ 2~~ ~fg!§ g~!~I§]~~ ~~~B~l for an explanation of
the message.
A flow diagram of the Data Base Prefix Resolution utility is shown in
Figure 5-E.
CONTROL
DATA
SET
DATA BASE
PREFIX
RESOLUTION
UTILITY
DFSURG10
I \
~----
SORT
WORK
DATA SETS
Figure 5-6.
tata BaSE Prefix Resoluticn Utility
Jet STATIMENTS
!he Data Ease ~refix Resolution ut~lity is executed as a standard OS/VS
jot~
A JOE statement ~defined by the using installation), an EXEC
statement, and CD statE~ents that define inputs and outputs are
required.
EXEC
7his statement must he of the form:
PG~=DFSUEG10,EABM='opticns'
Since this ~rcgram invckes the operating system Sort,
program efficiency can be improved ty incrEasing the
~artiticn/regicn size.
The PARM field can be used to specify options for the
SCF!/MEF.GE program. A recommended option is
PARM='SI2E=En'
n is the estimated number of records to be sorted.
Specification of this parameter improves significantly the
SOR!/MERGE Ferformance. Guidelines for calculating the
number of SCET/MEBGE input records are provided under the
tOFic "~crk Data SEt Allccaticn" later in this chapter.
SYSPRINT
DD
Defines the IEssage output data set for this program.
tCE para;EtEI~ sFecified within this program are RECFM=PB
and LRECl=12C. BLKSIZE must be provided on the SYStEI~T
DD statement and must be a multiple of 120.
SYSOG1
Defines the message output data set for Sort/MergE.
tt
SOR!LIB
DD
SOR~WKnn
DD
SOR!IN
tD
Defines a data set containing load modules for the
opErating system SOIt/Merge Frogram. This DD statement
must always be included.
iDe fines intErmEdiatE storagE data sets fOI tbe
opErating system Sort/Merge Frogram. Fefer ~o the
aFFropriate operating system Sort/Merge manual regarding
specificaticn cf Dumber and size of intermediate storage
data sets. These DD statement(s) must be includEd.
Defines the in~ut data set for this program. This DD
statement must always be included. It is referenced by
the operating system Sort/Merge program and must ccnform
to its Jet requirements. ~he data set(s) referenced by
this DD statement must be the output vork data SEt(S)
procuced during a data base initial load or reload
operation; those vork data sets must be concatenated to
form the SORtIN data set.
DeE parameters specified within this program are EECF~=VE
and LEEel=300. The ELKSIZE must be the same as that
spEcified for the werk data sets (iF's) written daring
initial data tase load, or data base reload.
DFSVRWF2
DD
Defines an intermediate sort work data set. This DD
statement must always be included. The data set can
reside on a tape or direct access device. The size ~f the
data set vill te ap~roximately the same as that of the
input data set defined by the SORTIN DD statement.
DeE paralete~s s~Ecified within this program are RECFM=VB
and LRECl=~CO. BLKSIZE must be provided on this ! t
statement. If EIKSIZE is not specified, there is no
default and the IEsults are unpredictable.
DPSUBWF3
DD
The output data set defined by this statemant will
be supplied as input to the Prefix Update utilitY4 This
statement must always be includedQ The data set can
rEside on ta~E OI direct access device. Its size will be
appro2imatel, the same as that of the input data SEt
defined ty thE SORTIN DD statement.
tata EaSE BeorganizationlLoad Processing
5.'1
DCB para.ete~s specified within this program are BECFM=VE
and IE!CI=300. EIKSIZ! must be provided on the Dl50RWF3
DD statement. If BLK5IZE is not specified, there is no
default and the results are unpredictable.
Defines the control data set for'this program. It
.ust te thE cut~ut centrol data sets generated by the
Prereor1anization utility. This DD statement must al~ays
be included.
DF~ORCD5
Ct
Defines an output york data set which will be used if
secondary indexes are present in the naDs bein~
reorganiz~d/lcaded. All notes on DFSURWF3, above, apply to
this data set also. This data set must te USEO as inFut
to the INDEX Unlcad program (DF5URUlv) for (re)creatinq
secondary indexes. This DC statement is required only if
seccndary indeXES are present.
OFSURIDX
OD
EETUBN CODES
~he
following return codes are provided at program terminaticn:
~~!B!ng
o
No errors detected.
4
Retnrned when either one or both of the follo~ing mEssages
bav£ teen issued during ~rogram execution:
tF5E1e, DFsee5
Eeturned when one or morE of the following messages bas
teen issued during ~rcgram execution:
8
tF5e~~, DF5E55. OF5857, DF5876. DF5877. tF5879,
t5F880, tPS881
or if no data is written te the WF3 data set.
12
Returned when either one or both of the messages listed
und€r return code 4 ~~~ anyone or more of the ressages
listed under return code 8 have been issued.
16
Returned ty OS/VS Sort/Merge ~rogIam. This return code
takes ~recedence over the above return codes.
!Q~~:
For
for r~turn
return cedes larger than 16, the same meaning stated above
code 16 apFliEs.
If either an e, 12, or 1E return code is returned by the Frefix
Resolution utility (DF50FG10), the Prefix Update utility (DP5URGPO)
should not be EXEcuted Sir:CE the input ~crk data set required by
DF5URGPO will not have been generated by DFSURG10. The errors indicated
by the diagnostic messages shculd be corrected, and the data basE
operations should be redone before the Prefix Resclution utility is
again attempted. Generally, execution is satisfactory if a return code
of 4 is set. HoweVEr the SYSFRIN! list should be checked. Fefer to thE
!~~~!~ H~~§~g~§ !ng ~Qg~§ ]~;~~~n£~ ~~nY~l for an explanation of the
DFS878 and DFS885 cauticnary messages.
5018
I~S/V5
~rimer
OUTFUT MESSAGES ANt
S~A~IS~ICS
If nc errors are detected by this program, statistics and a norlal
program tErminaticn mEssage will be printed.
The Data Base Prefix Update utility uses the output generated ty the
Prefix Resolution utility tc uFdate the prefix of each segment WhOSE
prefix infcrmation was affected by a data base load and/or
reorganization.
The output of the Prefix Resclution utility consists of ~ne or more
upda te record.! tc ~e applied to each segment tha t contail1s logical
relaticnship prefix information. The update records have teen sorted
into data case ano se91ent ~bysical location order by the Prefix
Resclution utility.
A flow diagram of the Iata Ease Frefix Update utility is shewn in
Figure 5-7.
DBD
LIBRARY
DATA BASE
PREFIX UP·
DATE UTI L1TY
DFSURGPO
OUTPUT
MESSAGES
DATA
BASES
TO BE
UPDATED
Figure 5-7.
JCL
Data Ease Prefix
U~date
Utility
S'IA~EMEN~S
The Data Ease Prefix Update utility is executed as a standard OS/VS job.
A JOB statement, an EXEC statement, and DD statements that define inputs
and outputs are required.
EXEC
!his statement must te in the form:
PG~=tfSRFCOO,FABM='ULU,DFSUEGFO'
Data Base Reorganization/load Processing
5.19
Defines the library containing the DBDs which dEscribe
the data tase(s) that were loadad and/or reorganized.
Ihis ID statement must always be included. The data set
must reside on a direct access device.
IMS
tD
SYSPRIN!
DD
tefines the eutput message data set.
rCB ~arameters supplied
LR!CL=1~C. BLKSIZE must
by the ~regram are RECFM=FB and
be specified on this I I statement
and must be a multiple of 120. If ELKSIZE is not
specified, there is no default and the results are
unpredictable.
DFSURiF3
II
database
to
Defines the input work data set for this program.
It must te thE cut~ut data set generated by the Frefix
Eesolution utility. The data set can reside on a tape or
direct access device. ~his DO statement must always be
included.
References the data base(s) that were initially leaded
and/or reerganized. One DD statement must be present for
each data set of a data base that has logical
relationshiFs. !he ddname must match the DtNAP.E indicated
in the DEt. If an HIDAM data base is operated upon with
this utility, a DD statement must also be supplied for the
KSDS of its primary index data base.
This data set must reside on a direct access dEViCE.
tFSVSAMP
DD
rescrites the data set that contains the buffer
information required by the DL/I Buffer Handler. This DD
statement is required.
(Fer additional information, see
"Defining the IMS/VS Data Ease E~ffer SutFcols" in Chapter
7, "IDstalling I~S/VS.")
BE!UEN cetEs
The following return cedes are Frovided at program termination.
o
Ne errers detected.
8
Cne or more error messages issued. The messages contain
details of the error(s) and are printed as part of the
systEm outFut.
OUTPUT MESSAGES
If ne errers are detected by this program, the only output message
issued will be a nermal ~rcgram termination message that indicatES the
numtEr of r~cerds precEssF.d.
BECFGANIZING AN INtEl DATA EASE
!he steps to tE taken fer the physical reorgani2aticn of a primary or a
secondary index data base are the same.
a!~f_j1-_Y~l~!g_lh!_~!l!_]!§!_
Job IISAMP2e; in I"SVS.PRI~EJOB shows an example cf how to do this.
!his jcb will unload the primary index of the sample CUSTOMER ORDER data
basE.
Using acc~ss method SErviCEs, the KSDS cluster must be deleted and
redefined. ~nly the following physical attritutes can te changed befere
the reload:
•
The amount of CASD spaCE:
•
~he C1 si~e:
services tIlINE.
via access method services
tlf1~1.
via the SIZE parameter in the CEt and access IEthcd
If the Cl SIZE is changed, a DBDGEN cf the altered data tase must
be executed here.
]Q1!:
~!!E_]~
__ !!l£!g_lh!_~!!!_~!§!_
Job IISAMP28e in 1MSVS.PF1~EJOB shows an example. This job will reloaa
thE primary index of the samplE Customer Order data basE. ThE jet alsc
includes the necEssary aCCESS lethcd services delete and define
commandsQ
REORGANIZING A HtlM OE HItlr. tATA EASE
The 3 basic steps in rEorganizing a
~~!2_1i
HDA~
cr HIDAM data base are:
__ YB!9!9_!B§_~!!!_E!§!_
Job /ISAMP1S5 in I~SVS.PEIr.!JCE shows an example of bow to de this.
This jot will unlcad the FhasE 1 Parts data base. BE1PAR~S.
at!~-1l
__ ~b!D~_g!I§is!l_f!I!!!l!!§_
The following physical parameters can be changed before the relcad:
•
the amount of DASC space:
•
The C1 size:
DEFINE.
•
Size of the root addressable area and/or number of root anchcr
points (HDAM cnly).
~t~I_~l
SIZE
access method services or JCt.
pa~aEEtE~
in DBD and access aethod services
__ ~!ls~g_~!~_~!l!_l!§!-
Job I/SAMP1S6 in I!SVS.PRI!EJCE shows the reload of the phase 1 Parts
data tasE.
Note:
made.
In additi~n, several structural changes in the data base can be
See "Applying Structural Changes" later in this chapter.
Data
BaSE
Reorganization/Load Processing
5.21
INDICA7IONS tHAt DATABASES f.AY NEED FECBGANIZATION
To determine thE nEed fer data base reorganization, certain indicators
sheuld be mcnitored. !hese indicators are different for CSA~ data tases
and for VSAM data bases.
In our sutset, HIDAM. SRISAM and INDEX data bases will always be VSAM.
HDAM data caSES may be VSAM cr OSAM. As GSAM data bases are neve~
recrganized, .e are not concerned about them bere.
For each access method lVSAP-, CSAM) there are two sources of information
which can sigDal thE nEed tc reerganize:
•
The DASD voluma table ot contents or VSAM catalog data, which does
not r~late to a specific execution of a job, and
•
7he tuffer peol statistics that do relate to execution of a
jeb.
specifi~
Tha VTOC of the DASD velume on which an C~AM data base resides may te
retrieved by the CS/VS utility IEHLIST, with a control record as in the
following exam~le fcr the phase 1 PARTS data base:
LISTVTOC
fORMAt,VOl=~33C=IMSPRM,DSNAr.F=IMSfFIME.DElfARTS.[EASE
g~Q!~h in the number cf extents
indicate that a reorganizaticn is
has only one eJtent. the message
and t~acks in this dataset is not
so it should tE igncred.
A
(the field identified by uNO EX!") may
needed. Ty~ically an OSAM data set
about the number of empty cylinders
necessarily accurate for a data base,
The buffer pool statistics Obtained by the use of sample routine tFSOAST
and ~rinted on tt statement //tOOASTA, also provides indicatcrs if
monitored. Chapter 9, "OFtilization," Frovides more guidelines for
this.
~ell
Statistical data about VSA~ clusters is maintained in the VSAM catalog
and is availatle by runni~g VSAM's Access Method Services with a control
card such as the following for the phase 2 Customer Orders data base:
LIS7CAT CltSTER All Et\TEIES (Ir!S1:FIME.DE2PCDS'I.tDASE)
The major indicatoIs can be found in the DATA portion of the cluster,
under the STATISTICS heading. The RECCRDS DELETED and INSEETEt fields
~ontain ceunts of this activity from the last creation (initial lead or
reorganizaticn) of this data base. A large number, relative to data
base size, in either or both fi~lds may indicate a need for
reorganization.
Mere impoItant are the SPLITS counts for CA and CI. Control Area «(A)
splits indicate that significant space is being claimEd and that it is
reorganizatien time. Ccntrel Interval (CI) s~lits indicate the same,
but to a somewhat lesser extent. The NUHEER of EXTENTS should net grow.
If they do, reor~anize.
There is one ether field, a~plicable te both the DATA and INtEX portions
of a cluster, that ~ill vary with the number of EXTENTS. This field,
called TOTAL BYTES IN DA~ASEt, indicates the number of free bytes left
5.22
IMS/VS Primer
in the DA~A or INtEX portion~ As this freespace approaches ~ere, you
are approaching the reguirelent fer a new extent and you should consider
recrganizing.
The buffer pool for VSAM is ergani~ed into subpools, with one sutFcel
for each control interval si2e. In our exalples, Me have used 1024 byte
and 2046 byte CI sizes, thus we have tvo subpools. These ver6 defined
in each job by the /IDFSVSAMP DD statement.
These statistics are ottained during the execution of a job by calling
the sample routine DFSOAST, and are listed on the DOOAS~A DD statement.
Two sets of statistics will be listed in our sample -- one for each
subFoel. A detailed discussion of these statistics and their
interpretation can be found in ChaFter 9, "Optimi2ation.~
In the HIDAM organizatien, the primary INDEX data base can be
recrganized separately from the main HIDAM data base.
(See jobs
//SAMP281 and /ISA~p2ee in IMSVS.PRIMEJOB.) Because this is normally a
small data space, you can do this weekly or even daily.
The initial load of a Fbysical data base which dces not contain logical
relaticnships cr secondary indexes is discussed ~n Chapter 4 under the
topic "Loading a Data Base." Ncne ef the utilities of this chapter is
required to lcad a single physical data base, which does not contain any
logical relationships er secondary index~s.
LOADING
DA~A
EASES iITE leGIe!l EEIATICNSEIPS
Whenever you are leading cne ex merE data bases which contain logical
xelaticnshi~s, yeu must use the logical relationship resolution
utilities. 'his is necessary becaUSE, when loading a logical cbild
segment, the logical parent sE9ment may net have been loaded, and vice
versa. So 01/1 cannot make the pointer connection at that timE.
Therefore, when loading a le9ical child er legical parent, DL/I will
(automatically) "rite a control record to a workfile (DFSURWF1). This
workfile is later sorted and used in a prefix update utility. Exactly
which control records need te ce generated is established beforehand by
the prereergani2ation ~tility. Figure 5-8 gives an overview of this
process ..
1.
The job for loading the data base must contain DD statements with
the ddnames of DFSOBWF1 and tlSUBCDS. The DFSURWFl DD statement
descr.ibes a cata SEt wbich is automatically created by IMS as the
result of the user's ISR1 calls to D1/I at initial load. The tCE
paramet~rs fer this statement must include LRECL=300, RECFM=VB, and
BLKSiZ-i specified to be the sall!e as that specified for any other
WF1. A basic recommendation is full track blocksize or 8-16K for
tape.
2.
When loading 2 or more logically related data bases, the DFSURWF1
files must be concatenated. This concatenated data set (including
all created Wl1's) must be spEcifed to the Prefix Resolution utility
as input.
3.
1he tFSURCtS DC statement must reference the control data set
created by thE prerecr9ani2atien utility.
Data Ease Reorganization/Load processing
5.23
r
CONTROL
CARD
--
PREREORG
(DFSURPRO)
--
...- _________ 1:
I REPEAT FOR EACH DATA BASE
I
,
I
I
I
I
I
I
DATA
BASE
I
DFSURWFl
I
I
L.---t------I
I
I
I
INDEX
UNLOAD
(DFSURULO)
I
I
I
UNLOADED
INDEX
DATA
BASE
I
.--.------I
I
ONLY IF LOGICAL
RELATIONSHIPS
I
I
I
----PREFIX
UPDATE
(DFSURGPO)
INDEX
RELOAD
(DFSURRLO)
I
I
I
I
IL _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Figure 5-8.
~L
_________ J
Initial Data Base load with Logical Relationships
and/or Secondary Indexes
Job IISAMF270 in IMSVS.FRIMEJCE can be used for loading the Level 2
Parts and CustcEeI OrdeIE data bases.
5.24
IMS/VS Primer
LCAtING DJTA
EASf~
~I~E
~ECCNDARY
INDEXES
When initially leading a data tase with one or more secondary indexes,
you must use the lcgical relatienship resolution utilities. ThE tasic
proc~ss is the same as the ene fet loadin9 data bases with logical
relatieDEhips (s~e Pigure 5-8).
However, scme additions are required:
1.
The prefix reseluticn utility (DFSURG10) creates an index workfile.
Its ddname is CFSCFIDX.
2.
The above workfile must be ,used as input for the index unload
utility, DFSUEOlO.
!Q~~:
3.
~h~
unload must te dcne from a newly allccated, empty KSDS.
The secondary index data base must t€ reloaded using the Index
Reload utility.
Job //SAMP37C in IM5VS.PRIMEJOB can b~ used for the initial load of the
sarFle Fhase 3 data bases, including both logical relationships and
secondary indexes.
WOEK tATA SIT ALLOCATION
The fellewing guidelines should be observed for a good performance of
the data bas€ load process, eSfecially fer large data bases:
1.
For th~ initial data case load job, the input file. the data base
data set, and the ~orkfile 1 should be on separa~e volumes.
2q
For the Frefix rescluticn:
•
and 3 can be located at the same device since
they dcnlt interfere with each other. But they should be
separated frer the index workfil~ (tFSURltX) if one exists.
•
The SOR1/~ERGE wcrkfiles, SQRTWKnn, should be kept on a
separate device from ~orkfiles " 2, and 3. The normal
SCF1/~!FGE goidelines for the placement of SOR1WKnn afFly.
Typically thrEe SORT/MERGE workfiles on separate direct access
devices give good performance.
Workfiles'.~,
3.
Fer the prefix update execution, workfile 3 should te on a different
volume from the data base data set(s).
4.
The location of the control d'ta set DFSURCDS is not important for
performance; it is used only at the beginning of the utilities.
The records. and their size, which will be written to vorkfile 1 by ttl!
during initial load or reload are:
~ype
00. Cne reccrd will be written for each logical parent occurrence.
If the lcgical ~arEDt has multiple logical child segment types,
the ~ecord is written once for each logical segment type.
Data BaSE Reorganization/load Frocessing
5.25
The size viII be 48 bytes + the length of the logical par@nt
concatenated key if the data base is being initially loaded.
Ty~e
10. One rEcord will be written fer each legical child occurrence.
!he size will be 43 bytes plus the length ot the lcgical parent
concatEnatEd key ,cnIy initial load) plus the length of the
virtual child sequence field if one is defined!
!ype 20. ene record will be wriXten for each logical child eccurrence
which has a ttF ~cinter and nc virtual child sequence field
defined. The si2~ is 43 bytes plus the length of the lcgical
parent concatenated k~y if in initial load.
TYf~
~ill te written for each logicAl child occur~ence
which has a ITE pointer and no virtual child sequenc~ field
defined. the size is 43 bytes flUS the length of the logical
Farent concatenated key if initial load.
30. One record
Type 408 Cne record will te written for Each indeX source segment
cccurrEnCE. 7ce size is 42 bytas, plus the length of the index
search field(s), including the four bytes for the /SXname field
if any. 1his is the enly record which viII te written to the
index worle file.
Note: The actual size of work file 1 can be found in the tape trailer
label or the VIoe if it is on a direct access ievice.
The following stEps shculd te €xEcut~d .hen reerganizing Qata bases vith
logical relatien£hiFs and/or secondary in1exes:
1.
Start with the Frerecrganization utility, tfSORPRO. Specify all the
related tED names in a DBR centrol statement(s). Howevar, no
Frimary or secondary indax tED names should be specified.
2 ..
Unload all related EtAP./HIDAM data base(s), using the HD
Reorganization Unlcad utility, DF£URGUO. This should be done at the
same time, that is, no data base processing between the unload and
the prefix update of all ccnnected data bases. The primary (HltA~)
and secondary index data bases need not and should not te unloaded
separatEly.
.....
Change any physical attributes as needed. Befer to the section
"Reorganizing a HtAl or HltAM Data Ease" earlier in this cha~ter for
thE allovEc changes.
4.
Belo~d the HDAM/HIDAM data base(s), using the HD reorganization
reload utility, DFSUFGIO. Each reload of a data tase will create a
DF5UBWFl worktil~.
5.
The other steps are exactly the same as for the initial load proces~
(see Figure 5-8), that is, prefix resolution, prefix update, index
unload and index rElcad.
When ul.loading the ~xisting secondary index data tase, it
must be a newly defined "empty" KSDS. So you should first delete
the KSDS and redefine its space ~~!2~! the execution of the index
unload utility ,DFSURULO).
!!2!~:
5.26
IMS/VS PrimEr
!he HD reorganization utilities can be used to ilplement many different
design changEs to yeur data tases. !he most common changes are
discussed in the follo~ing s~ctions.
CHANGING A FH1SICAL rEI
The following rules and restricticns sheuld
structural changes to a physical data base:
b~
observed when applying
A.
lhe HD unlcad utility must have been executed against the tED
describing tbe CUIIent structure, and nc data base updates should
have occurred since tr.€ unlcad.
B.
An existing segment type can te deleted from the DBD provided all
occurrences of this segment were deleted prior to execution of the
HI unload utility.
C.
New segment types can be added ~o the new DBD provided they do not
change either the hierarchic relationship among Existing segment
types or the concatenated keys cf lcgically related segments.
(You
cannot add a parent to existing ~egments.)
D.
Names of Existing seg~er.ts must not be changed during
reorganizatien, that is, between unlead and reload. Segment names
can be changed before or after the reorganization.
E.
Any field statement except the sequence field (key field) can be
added, or deleted. However, Dl/l will not change any
segment data except as in (F) telow.
~har.ged,
F.
Existing segment lengths can be altered. If the segment is made
smaller, tL/l simply truncates the s€gment. If the segment is
extended, it will te filled with whatever exists in main storage
beycnd the end of the SEgment. The user should replace this via ar.
update progral.
G.
The access method may te changed. SHISA~/HIDAM may be changed to
HDAMq HDAM can be changed to either indexed IEthod only if the
randomizing module maintains root key sequence.
AttING LOGICAL REIA!IONSHIPS/SECCNDARY INDEJES
The fcllcwing rules and guidelines s~ould be observed when adding a
logical relationship an~/cr a secondary index to an existing data tase:
A.
Eefore unlcacing tte data ba~e which certains the logical child, all
the logical children must already exist in that data base. This
segment, which at unload time is still a regular dependent segment,
must start with the cctcatenated key of the "would be" logical
parent. Femember, the Ht reorganization utilities process only the
segment prefix, never the segment data.
If a logically related data base is to be added, its initial load
process will generate a ~FSUFWFl file. No additional unload/reload
of that data tase is reQuired.
B.
The HD unload utility must have been executed against the DEn
describing the current structure, and no data base updates stould
have occurred since the unlcad.
tata Ease Feorgani2ation/Load Processing
5.27
c.
the Ht unload. the DBD(s) are changed. And the
prereorganization utility (DFSORPRO) must be run with the new DED(s)
before the reload/initial load. This could also be done initially
if thE new tBD(s) have different names. Notice, the BD unload
utility dces not nEed the control data set created ty the
prereorganiz8tien utility.
D.
Prefix resolution (DFSaBG1C), prefix update (DFSOBGPO). and index
creation roptional: CFSOBUIO/DFSUBBLO) should then tE pErforKEd as
in figure 5-8.
!!l!~
l!sJ!.el!§
1.
Job I/SAKP~89 in I"SlS.PRlftEJOB shows how to add a logical
relationship to the ~arts data base together with the initial lead
of thE rElated CusteEEr Orders data baseo
2.
Job I/SAMP~89 in IMS1S.PRIMEJOB shows hew to convert the phase 2
Parts and Custoaer Crders data bases to their phase 3 vErsions by
adding a sEccndary index t~ ~he Parts data base. Notice that no
application program is required to add a secondary index.
In our sutset, ve viII net consider the reorganization of a data base
while it is allocated to the online IMS/VS control region. Ther~fore,
the reorganizaticn {rocEdurEs in the IMS/VS-DB/DC environment arE
exactly the same as for the IMS/1S-DB only envircnment.
5.28
IKS/VS Primer
Data tase recovery is, in its simplest form, the restoration of a data
base after its (partial) destruction due to some failure. The preceding
sentence defines the three basic elements in recovery:
•
~he
•
The failure
•
The restcration
data base
~heir relationshi~ is: "The restoration eliminates the effect of the
failure on the data tase."
The basic principle of almost any data base recovery mechanism is
maintaining duplicate data. Feriodically, a copy of the data in the
data base is saved. ~his cCfY is normally referred to as a Q~~~=ge or
i!~g! ~~Il.
~hese image copies normally reside on magnetic tapes.
In
additicn to this, the changes made to the data in the data base are
saved, at least until the ne%t image copy. See Figure 6-1 for an
overview.
•
FAILURE
DATA BASE
DATA BASE
..
---TIME
I
,/
,/
.,/
.,/
./"
..
RECOVERY
Figure 6-1.
+
ECK'
concepts of Data Ease Recovery
Data Base RecovEry
6.1
The recovery process then includes the following four steps:
14
Determine the cause of the failure.
2.
Correct the cause of the failure.
3.
Reconstruct the data tase using the image copy and the saved
changes.
4.
Resume processing at the point of failure.
Each of the above steps can cause, in practice, a variety of activities.
!he intention cf this cha~ter is to provide you with guidelines for, and
examples of, ~rocedures tc handle these activities.
With tL/I, twc apprcaches are, in general, available to protect the
ictegrity of your data bases: basic recovery and DL/I recovery.
BASIC EECCVERl
After each tack-u~ co~y is made, all input data to the data tase update
prcgrams are saved until the next back-u~ copy is made. In case of
failure, the data base is restored, using the back-up copy. Next, all
update programs executed during that peried are re-executed, with
exactly the same input data and in exactly the same sequence. The
regenerated output replaces the criginal cutput. DL/I provides
utilities to create the tack-up copy and to restore the data base. This
approach is referred to in the following discussion as ~!§iS I~S~!!!I.
See Figure 6-2.
6.2
I85/V5 Primer
FAILURE
\
\
PROGRAM
/
\
/
PROGRAM
DATA BASE
..
TIME
RESTORE
RERUN
Figure 6-2.
Basic Data Ease Becovery
DL/I EICOVIRY
The second aFproach uses the tL/I log facility. During processing of
the data baSES by applicaticn ~Iograms, all changes made to the data
basE are automatically lOggEd CD the DL/I leg data set. A DL/I utility
is ~rovided ~hich allo~s you to accumulate all changes made to the data
base by all processing programs in a single £h!ng! !££Y;Yl!Si2U g~SA
Hi- Only the last copy of a data base change is kept. in tl1is data set,
thus reducing the volume of tape required. When a failure occurs, you
restore the latest back-up copy of the data base, using a DL/1 utility,
which at the same time mergES the change accumulation data set into the
restored data base. ~his brings the data base up to the point of the
failure. In addition, a se~aratE utility is available to 2!gl QYI
(undo) the data base changes of a failing program. This approach is
referred to in the following discussion as ~~l! I!~Q!~Il. See
figure 6-3.
Data Base Recovery
6.3
•
FAILURE
I
/
\
\
PROGRAM
-
-
- -
/
PROGRAM
..
---
--
TIME
RECOVERY
Figure 6-3.
DIll Eecovery
WHICH ONE !O CHeeSE
tL/l recovery bas several acvantages over the basic recovery:
in~ut
•
No need to retain the
•
No rerun cf update
•
Only the affected data sets need to be recovered
•
No time synchronization problems if the programs are date dependent
or have been mooified in the interim
•
SimFler administration: only the back-up copies and log data sets
are required
•
No duplicate output
•
lor the IMS/VS oata communication facility, a log data set for the
cnline data bases is mandatory. There is normally no retained input
from terminal transacticns. It is recommended that you establish
Dt/l recovery procedures before going online.
6.4
lMS/VS Frimer
data sets
~rccessing
programs
Eased on the abovE advantagEs, the
recovery unless you have:
~ecemmendation
•
Only one or
•
Low data tase update rate, and,
•
VEry frequent (daily) tack-ups, and,
•
No plans for enline precessing.
t~o
is to implement DL/I
data bases, and,
Befere describing the two recovery approaches, we will first discuss the
DL/! logging facility and associated recovery utilities.
lH~_~*Ll_~~~21!~_fA~!!lIl
The DL/! logging facility is the cornerstone of thE recovery utilities
of tL/I. This facility, CfErating as an integral part of DL/I,
autematically writes all before and after images of updated data base
segments to a cEntral log data SEt. Each log data set, created with a
DL/I batch program execution, is one sequential data set. It must
reside on magnetic tape in cur subset. You must Epecify
DISP=(,KEEP,KEEP) or DISP=(,CA1LG,CATLG) for the log data set, that is,
DISP=MCD is not allowed.
In our subset, we will assume the use of the log tape write ahEad
function (specify: OP110NS LTiA=YES in the DFSVSAMF control data set).
For mOIe details, see "Defining the IMS/VS Data Base Buffer Sutpools" in
Chapter 7, "Installing IMS/VS."
The log tape write ahead (L~iA) function will assure that no data base
change will be written to physical data base storage before the
correspondin9 log records are physically written to the log data set.
With this prevision and the log close function of the log recovery
utility, there is DO risk cf lest data base changes, even in the case of
an abrupt system breakdown.
A log data SEt is creatEd by adding a //IEFEDEF tt ••• statement to the
JCl of the tatch eXEcutior. jet.
1.
A log data set is not created when a data base is initially loaded
(that is, when the frecEssing option "L" or "LS" is selected in the
PCB).
2.
IMS/VS uses thE OS/VS ESTAE facility to flush the log buffers and
clcse the log data set in the event of an abnormal termination. In
addition, for batch jobs only, the data base log buffers will te
written to tASte
I~!_~~Ll_~!~QI!BI_~11~111I~
DL/I provides four utilities fOI recovering a data base. The diagram in
Figure 6-4 illustrates the relationship between these utilities.
Data Base Recov€ry
6.5
DL/I
PROGRAM
(IMAGE OF
ALL DATA BASE
CHANGES)
DATA
BASE
~______~IMAGECOPY
PERIODIC
COPY
CREATED
UTILITY
PERIODIC
CHANGE
ACCUMULATION
CHANGE
ACCUMULATION
UTILITY
RECOVERY
UTILITY
Figure 6-4.
Iata BaSE REccvery Utilities
A description of these utilities and their basic functions follows:
1.
Data Ease Image Copy utility for creation of image copies of data
bases.
2.
Lata Ease ChangE Accululatien utility for accumulation of data base
changes frem DL/1 log tapes since the last complete image copy.
3.
Data Base Eecovery utility for restoration of the data tasE, using a
prior data base ilage co~y and the accumulated changes from DL/1 log
tapes.
4.
Data Ease Backout utility for removal of changes made to data bases
by a specific application program.
A fifth utility program, the rL/I System Log Recovery Utility
(CFSULTRO), is used to close the DL/I Log in the event of an operating
system or hardware failure, thus enabling use of the log by the four
principal prosrams ef the rEcovery systeK.
For those data bases which consist of multiple data sets, r€covery is
done ~y individual data set. To recover a complete data baSE com~osed
of multiple data sets, data base recovery must be performed for each of
its component data sets.
6.6
IMS/VS Primer
DATA BASE IMAGE CCFY U'IIIITY
(tfSUt~FO)
The Data Ease ImagE Co~y utility c~eates a copy of the data sets within
the data bases. Is illustrated previously (see Figure 6-4), this output
is used as input to the Data Base Recovery utility.
Multiple data sets can be CCfied with one execution of the Image Copy
utilitYq All data sets of a data base should be copied at the same time.
In our sutset, we presume that all data base data sets are dumped at the
same time, that is, no intervening data base processing-
A flow diagram of the Data Ease Image COFY utility is shown in
Figure 6-5.
DBD
LIBRARY
DATA BASE
DATA
SET
/
I
/
/
/
Figure 6-5.
Data Base Image Copy Utility
~~~_~!.'§!.§J!!§1l:t§
The Data Base Image Copy utility is executed as a standard CS/VS job.
The fcllcwing JCl statements are required:
EXEC
This statement must te in the following form:
PGP.=tISEECOO,tAE!='ULU,DFSUDMPO·
IMS
DD
tefines the litrary containing the DBD that describes
the data base to be dumped. This is usually
DSNAME=I~SVS.DBDtIB.
SYSPRINT
tD
Defines the output message data set.
Data Base Recovery
6.7
datain
tt
tefines the inFut data set to be dumped. The ddname
on this statement must be the same as the name in the
DED that describes this data set; the ddname must alsc
appear on the utility cont~ol statement. One DD statement
of this type must be present for each data set to ce
dumped. !be data set must reside on a direct access
volume.
dataout
tC
tefines the ilage copy out~ut data set. One DD
statement is required for each data set to be dumped.
!he ddname may be any 1- to a-character string, but the
ddname must a~~ear in the associated utility control
statement. The output device must be eith€r direct access
or ta~e. Standard labels must be used. LBECL and BLKSIZE
are calculated by the utility and should not be provided
in the Jet.
SYSIN
DD
tefines the inFut control statement data set.
One control statement is required for each data set to be dumped.
,
,
I Il EE1PAETS IE1PAFTS DFSUIUMF
~------------------------------------------------------------------J
lhis must be the characters '£1'.
4
~his !ust te the name of the physical tED that includes
the dcname of the data set to be dum~ed.
13
Ihis must be the ddname of the input data set to be
dumped. It must appsar in the referenced DED, and a
ccrres~cnding DD statement must have been provided.
22
This must be the ddname of the output data set. A
corresponding It statement must have been provided.
All other fields lust be blank in cur subset.
]Q!i:
The Data Ease Image Copy utility provides the following return codes:
6.S
o
Successful cClpletion of all operations.
4
Warning message issued.
8
Cne or more operations not successful.
16
Severe errors have caused the job to terminate
without cCI~leting all o~erations.
IMS/VS trimer
These return codes can be tested by the COND= parameter on the EXEC
statement of a subsequent job step.
Job IISAMP180 in IMSVS.FEI~EJCE shows the JCL for the image copy jot of
the phase 1 Parts data case. Jct //SAMP380 shows the image copy of all
our sample phase 3 data bases.
DAtA BASE CHANGE
ACCU!UlATIC~
UTIlITY (DFSUCUMO)
The function of the data base change accumulation utility is to create a
sequential data set that ccntains only that information from the log
ta~Es ~hich is necessary for recovery.
This accumulation log data set
is to be used by the data base recovery utility. This accumulation is
done by sorting only the required log records (latest version) in
physical record within data set sequence. ~his provides efficient data
base recovery ~henever needed. The number of log tapes will be
significantly reduced. This utility invokes the Sort/!erge Program in
your CS/VS installation.
The cbange accumolatic[ utility can be run independently of DL/l
application programs. The new output data set created by Change
Accumulaticn is used bj the data base recovery utility. Figure 6-6
depicts the sources of inFut tc the data base change accumulation
utility and the output created by this utility.
0
NEW CHANGE
ACCUMU LATION
DATA SET
CHANGE
ACCUMULA·
~~TION---,.---.-.
.~TILlTV
DBD
LIBRARY
Figure 6-6.
Data Ease Change Accumulation Utility
The
i~put
to the data base change accumulation utility consists of:
1.
All log tapes creatEd since either the last image copy utility
execution or the last execution of this utility.
Data Base Recovery
6.9
2.
The previous change accululation data set. This would be the output
from the last executicn of this utility. The first change
accumulation run after a nEW image dump !g§1 D2! include any old
change accumulatio~ data set, that is, tkose created during the
previous ~eriod.
3.
7he DBD library which is normally called IMSVS.DBDLIB.
4n
An optional control statEment (10).
Output from thE data base cbange accumulation utility consists of a new
changE accumulation data set. This is a sequential data set containing
the combined data tasE records for all data base data sets.
The data base changE accumulation utility is executed as a standard
OS/VS job. 1he following Jet statements are re9uired:
EXEC
this statement must be in the following form:
PGM=DFSUCO~C
SYSPRIN~
Defines the output messagE data set.
tD
IMS
ID
Defines the library containing the DBDs that describe
all data bases tc be accumulated4 This is usually
DSNAM!=IMSVS.DBDLIB.
SYSOUt
ID
Defines the output messagE data set for the Scrt/Merge
FIogram. The Sort/MergE Erogram specifies AP (all
messages tc printer).
SCRTLIB
Defines a data set containing load modules for the
execution cf Sort/~erge. This is usually
tSNAM!=SYS1.S0RTLIB.
DD
SORTWKnn
DD
these DD statements define the intermediate storage
data sets for the Sort/Merge program. The data sets
ncrmally reside en a direct access volume; ho~ever, tape
can be used.
(For specification of number and size of
intermediate storage data sets, refer to the applicable
Sort/lerge manual.
CFSUCUMN
DO
refinES the r.EV accumulated change output data set.
the data set can ~eside cn a tape or a direct access
volume. The output is blocked to maximum device capacity,
up tc a laximum of 8K. Standard labels must be USed.
IFSUCUMO
DD
tefinEs the old accumulated change input data set that
is to be merged with the new accumulated change data set.
If no old changes are to be merged, the following ED
statement must be used:
IltFSOCU~O
CD DUMMY,DCE=ELKSIZE=100
~his is requi~ed in the first change accumulation
execution after each new image dump of the data baSES.
data set can reside cn tape or a direct access
volume.
~his
DFSULCG
DD
DefinES the lcg input data set containing the change
records to be accumulated. This data set can reside on
tapE or a direct aCCESS volume.
SYSIN
00
Defines the control statement data set.
An optional control statement can be used to describe additional tatle
requirements for this changE accumulation execution. If it is not
included, default values are assigned as described below.
80
31-33
1
r------------------------------------------------------------------,
,
,
I It
I
I
,
Max Seq Length
L------------------------------------------------------------------~
1
Positions
31
Positions 31-33 contain the maximum length root sequence
fiEld ccr.tained within the log records to be processed.
This value is used to pad the sequence field with tinary
ZEros for sorting purposes. If there are no VSAM KSDS
records to be processed, this value should be spEcified as
4. the length cf the Relative Bleck Number field.
This
value must be in the range 1-236 and must be
left-justified or supplied with leading zeros. The
dsfault value for this entry is 10. In our sutset yeu
must specify the laximum root sequence field of any HIDAM
and/or
and 2 must contain the characters "10".
SEISA~
data base.
All other columns must te blank in our subset.
!2t~:
The data base change accumulation utility provides the follcwing return
COdES:
o
SUCCEssful corpletien.
16
Onsuccessful completion.
~hese return cedes can be t~sted by the CONt= parameter on the EXEC
statement of a sutseguent jct step.
!!~J!!Elj
Jobs IISA~P181 and //SAMP3e1 in IMSVS.PRI~EJOE show the JCl to
accumulate a log data set, with a previous accumulated log data set,
into a new accu.ulated leg data SEt.
Data EaSE Recovery
6.11
~Qli:
The change accumulation utility
as input. These log data sets must be
sets in the D~SOlCG Dr statement. The
should be in the ccrrect date and time
first.
can accept multiple lcg data sets.
specified as concatenated data
sequence of these data sets
sequence, that is, the oldest
DA!A BASE FECCVEEY UTILITY (DFSUBDBO)
!hE data base recovery utility program will restore a physically damaged
data SEt which is part cf a DL/I data base. This utility does not
previde a means of recovery from application logic errors; it is the
user's responsibility to ensure the integrity of ~a~ q~~~ in the data
base.
The data base recovery utility achieves a high rate of throughput by
manipulating data sets individually in a physical sequential manner.
~he basic input consists of an image copy data set and, optionally, an
accumulated cbangE data set.
The data base recovery utility prcgram is executed in a DIll batch
region. Its flc~ diagram is shown in figure 6-7.
DBD
LIBRARY
OUTPUT
MESSAGES
Figure 6-7.
tata Base Fecovery Utility
The data base recovery utility is executed as a standard OS/VS jot.
Cnly one data set recovery is allowed for each execution. The following
JCt statements are required: A JOB statement (defined by the using
installation), an EXEC statement, and DD statements that define inputs
and cutputs are required.
6.12
IMS/VS Frimer
This statelent must be
IXle
i~
the following form:
fG~=DFSFFCOO,PARM='UDR,DFSURDBO,dbdname'
where dbdname is the name of the DED that includes
the data S€t tc te recovered.
IMS
DD
Defines the library containin9 the DBD that describes
the data base data set to te recovered. This is usually
tSNAME=IMSVS.DBDLIB.
SY SPRI N'I
tD
Defines the output message data set.
If tlocked it lust be a multiple of 121.
tFSUr:UMf
DD
tefines the ilage copy input data set. It must be a
data set created by the Data Ease Image Copy utility. The
data set can reside on tape OI on a direct access volume.
Standard labels must be used.
DF SUC UM
ID
Defines the accumulated change input data set. If no
accululatEd cbange input is supplied, this statement must
be coded DD tUMMY. This data set can reside on tape Or a
direct access volume. Standard labels must be used.
DFSULOG
DD
This statement should be coded as DD DUMMY in our
subset.
dataset 1
DD
Defines the data set to be recovered. The ddname must
be the same as the ddname in the DBD that describes this
data set. It must also appear on the utility control
statement. 'Ihis data set must reside on a direct access
volume.
SYSIN
tD
tefines the inFut centrol data set.
80
13
r------------------------------------------------------------------,,
I
I 5
,
,,
BE1PARTS DE1PARTS
L------------------------------------------------------------------~
This must te the character '5'. The '5' defines this
statement as a data base recovery utility control
statement.
4
This must be the name of the DBD that describes the data
base containing the data set to be recovered. This name
must also appear in the PARM field of the EXEC statement.
13
This must be the ddname of the data set to be recovered.
It must be the same as the ddname in the DBD and dataset1
It statElent.
!gl~:
All other positions must be blank in our subset.
Data Base Recovery
6. 13
The data tase recovery utility
~rovides
the following return codes:
o
ReguEsteo reccvery successful.
"
Warning message issued
8
Serious error occurred, recovery terminated
16
catastrophic Errer occurred; recovery unsuccessful
These return codes can te tested by the COND: parameter on the EXEC
statement of a subsequent job step.
~!!!.El!§
/IS1KE182 in IMSVS.FEIMEJOB gives the JCt to recover the phase 1
Parts data base. Job IISAKP383 gives the JCt to recover all the phase 3
data bases using a change accumulation log data set.
~ob
DATA BASE EACKOUT U11L111 (DFSBBOOO)
The data base backout utility removes changes in the data base wbicb
were made by a specific failing Frogra.. The following limitations
apply:
•
The log data set of the failing program must be on magnetic tape;
the taFe is read backwardsq
•
No other u~date programs should have been executed against thE same
data base(s) between thE time of the failure and the backout.
The Fregram operates as a normal DL/I batch job. It uses the PSE used
by the program whose effects are to be backed out. All data baSES
updated ty the Fregram lust be available to the bacxout utility.
A lcg tape is created during the backout process. This log tape,
preceded by the log tape produced for the failing job, must tE included
in the next changE accumulaticn run, as any other log tape. This tape
must not be used as input to any subsequent backout attempt.
]S1~:
For a mc1tiple volume data set, the VOL parameter of the JCL
statement specifies the vclumes in ascending sequence.
Figure 6-E presents a summary of conditions that terminate the
frccessing of the data base backout utility.
IKS/VS Primer
r-------------------------------------------------------------------,
I
Summary of ConditicDs Terminating the Processing of the
,
I
tata Ease Backout Utility
,
1-------------------------------------------------------------------1
t CHKF-ID not specified.
I
,-------------------------------------------------------------------,
11. CHKP record requested.
11. First CHKE record encountered..
I
1-------------------------------------------------------------------,
12.
Accounting record
opening the log data set.
1
1-------------------------------------------------------------------1I
I*Note: 7he ordex of occurrence is referenced as from the end of
1 CHKF-ID specified.
~he
fc~
Ithe Log tape toward the start of the Log tape.
Iprocessing-)
Figure 6-8.
(Eead-backward
I
1
Conditions 7hat 7ermit.ate the Data Base Backout Utility
!i21!§l
•
If checkpoint/restart is nct used, then backout always backs out all
the data base changes of the program.
•
If checkpoint/restart is used (program uses IRST and CHKP calls),
then kackout will cnly dc tackout if the specified CHKP-ID is found
on the lcg tape during read forward. If no CHKP-ID is specified
then the last one on the leg taFe is used (the first one encountered
durin9 read back~ard).
•
If, when using checkpoint/restart, you want to be able to completely
back out a jet (steps), yeu must issue a CHKP call immediately after
the XES! call, that is, before any real data base activity. The
CEKP-ID of this call can then be used for a full backout operation.
Figure 6-9 depicts the data set
utility.
~eguirement!
for the data base backout
Data EaSE Recovery
6.15
DATA
BASE
DATA
BASE
PSB
LIBRARY
DBD
LIBRARY
DATA BASE
BACKOUT
t-.......;~I
OUTPUT
MESSAGES
L _ _ _ _ _ _ _ ...J
r------,
I CONTROL
INPUT
I
I STATEMENTS I
L _ _ _ _ -.J
IMSLOGR
Figure 6-9.
IEFRDER
tata SEt REquirements for the Data Base Backout Utility
~~1t ~1s1iljll~§
ThE data baSE tackout utility is executed as a standard DIll batch job.
!he follc~ing Jet statements are required:
EXEC
!his statE lent must be in the
follo~ing
form:
PGM=tfSRRCOO,P1RM='DLI,DFSBBOOO,psbname'
whErE pstname is the name cf the PSE used by the program
to be backed out.
lou can alsc use the DLIEATeH procedure to eXEcute this
utility. SEe Chapter 1, "Installing IMS/VS," for
additional information on using the DL1BATCH procEdure.
IMS
tt
ConcatEnatEs the IMSVS.PSELIE and IMSVS.DEOLIB
litrar iES.
I
f1SLCGB
DO
Describes the input log file.
read-backwards is used.
It must be a tape file;
IEFRDER
DD
DEscribEs thE system log tape created during tackout.
The data set usually resides OD tape. However, a dirEct
access volume can be used.
dataset
Dt
Tbese arE thE data base tD statements required by thE
PSB rEferEnced in the EXEC statement. This data set must
reside on a direct access volume. One DO statEment is
rEquired for each data set of the referenced data bases.
SYSIN
tt
Beguired only if a CHKPT control statement is supplied.
tFSVSAl!P
DD
IescrihEs the data set that contains the buffer
information required hy the DL/I buffer handler. ~his DD
statement is reguired if the data bases descrited by the
dataset It statements are YSAM data sets. For additional
information, SEe thE discussion on "Defining the IeS/VS
Data Base Buffer 5uhpools" in Chapter 7, "Installing
IrIS/YS."
Cne optional control statElent can be used if the
batch checkFcint/restart facility.
~rogram
uses the rIll
eo
7
I
, CHKPT PPURC010
I
l----------~-------------------------------------------------------~
~j_i5a:iEl~~tll
Positions 1-~ must he the characters 'CHKPT'.
characters define the control statement.
These
~his is the a-character checkpoint II supplied to DL/I
with the 'CHKP' call. The ID is displayed as part of
message tF5681I at the time the 'CHKP' call is made.
7
If DO ID is SFECifiEd, the last checkpoint on thE log tape
will bE used.
~Q!~:
All other
.E!!l.YIll
~.2g!!§
~ositions
should contain tlanks •
The Data EasE Eackout utility
~rovides
the following return codes:
o
Eackcut succEssful.
4
PSE incorrect.
8
Unahle to open data base.
12 and
Severe error condition: processing terminated.
above
(DPS39S.I)
(DPS3S6I)
(DFS397I)
These return codes can be tested by the COND= parameter on the !XFoC
statement of a subsequent job step. Each return code, however, caUSES a
message to he printed.
Jobs //SAMP177 and //SAftP3eQ in IMSVS.PRIMEJOB show the JCl for the
backcut of the FE1CFPUE program executions for phase 1 and phaSE 3,
respectively.
Data Base Recovery
6.17
SYSTEM LOG RECOVERY U!ILI!Y (DFSOLTRO)
This utility can be used to clcse a log data set when DI/! or CS/VS
fails tc do so. ihis will typically be required after an OS/VS, ta~e
unit. CPU, or power failure. Note that when DL/I abends, the log data
set will usually be closed by CS/VS. The as/vs message IEF2851 (data
set KEPT) indicates that this has been done. Two steps are required to
clcse a log data set with DFSOL!RO. See Figure 6-10. Each step requires
a separate executicn cf tFSUITRO.
DFSULTRO
DUP MODE
Figure 6-10.
DFSULTRO
REP MODE
Closing the System Log with DFSUL!RO
In the DUP mode, DFSUL!RC reads the log data set and copies it to a new
interim log data set. A listing is produced of the error hlccks. In
the situation cf the unclcsed lcg tape, only the first error block is
generally of interest. !he sequence number of this error block (A00001)
shculd be specified in the control statement of the second execution of
DFSULTBO.
1.
6.18
If the log tape contains read errors before the end of the 1cg data
set, these would alsc be listed. In our subset we will not cover
the correction of these errors. In that case, we will disregard
that log tape data set aDd recover the data bases to the point of
the start of the failing program. Following that, a full rerun of
that program would ce required.
IHS/VS Erimer
2.
fEcaUSE the DISUL~RO cnly checks the lcg record sequence number, old
data from a previous (log) data set viII be regarded as valid lcg
data. This old data will therefore be copied to the interim log
tape after signaling its initial sequence number break as an error
block. Witheut chEcking the actual contents (that is, timestamps)
iD the leg records YGU might not be able to distinguish this
situatien from rEad errers befere the end of the current data set as
discussed in note 1 above. To avoid this ambiguity you can use
"clean" ~hat is, no data at all) lcg tapes cr pre write the log
tapes with tape marks.
3.
If the DUP mode of DFSOITRO did not find an error block at the end
of the current log data set, it will terminate normally, or abend.
In that case. the log tape produced by the DUP mode is a valid log
tape, and the REP mode is not necessary.
4.
For more dEtails on the IMS/VS log records, you should refer to the
sections entitled "System log Records" in Chapter 2, "System
Maintenance/Tuning Facilities" of the 1~~L!~ ~l§!im E~Qg{~!m1ug
~!!!I!~~ ~!~~!!.
The REP mode of DFSOLTFO copies the correct hlocks from the interim log
data set, produced by the DUP medE execution, to a new log data set. At
the end it will close that log data set, omitting the block in error as
specified by thE contre} statEment.
//SYSPEINT
//lEFBDEB
//N!WEDER
JOE
EXEC
tt
nD
tI
I/NEiFDEB2
//SYSIN
Dr
tt
//F!COYEF
IIS~EF
(ACC!GINFOBMA!ION)
PG~=tFSUlTEO
SYSOD!=A,DCB=(RECFM=FBA,lRECL=133)
UNIT=3400,VCl=SEB=lOG01,DSN=IMSLOG,DISP=OLD
UNIT=3400,VOl=5ER=NEWLCG,DSN=IMSLOG,
DISP=(NEi,KEEP),DCB=DSCBG=PS
DU~MY,DCE=EIKSIZE='460
*
DUE Mode
The following control statEIEDt is required in our subset:
Beginning in
___ ~Qlgl~___
!Qlis!
DOP
5
ERRC=nnnnn
Indicates DDP mode.
Indicates the maximum number of input
l/C errors or sequence errors accEFtEd
tEfore job termination. nnnnn must be a
5-digit numeric with leading zeros.
BEcommEnded value: EBRC=00010.
Data Ease ReCOVEry
6. 19
REP Mode
The following control statement is required in our subset:
Beginning in
___ ~21g!a___
19£J!1
REP
Indicates ElP mode.
5
SEQ=!!X!X!
Indicates the identification number of
the block in error. The identification
consists of the letter "A" followed by a
5 digit integer, the error block sequence
number (A00001 for the first error block).
The number is provided in the listing
output of the DUP step.
16
CLeSE
Close the output tape right
error block.
q~f~Ii
this
£~!~!2g_~QB§!g~~~1!2~§
In general, log recovery is only required in case of hardware or OS/VS
failure; that is, when the log tape is not closed. This normally
imFlies that the jobstep termination processing did not occur. As a
consequence the new leg data set vas not cataloged. Therefore we
catalog the recovered log tape in the second phase of the log recovery
process. However, this should be verified by comparing a list catalog
with the manual lcg tape registraticn by the operator. Under no
circumstance should the input tape for log recovery be used together
with the !"duplicate") output tape for backout and data base recovery
Frocessing. SFecial care must be used if multi-volume log data sets are
written and only the last vclume is used for log tape recovery.
~!~!E~~§
Jobs //SAMP190 and I/SA,.t191 in IMSVS.PRIMEJOB show the DUP and REP
modes. respectively. ef DFSULTRC.
The following guidelines shculd be observed when designing basic
recovery ~rocedures:
•
~he imagE copies of all data baSE data sets should be made at tbe
same time. No intervening (update) Frograms should be executed
against the data bases.
•
A rigcrcus registration scheme should be established fer the image
copies and all Frogra. inFut and, optionally, output.
•
All Frogram input should be saved until the next image copies are
made.
•
In case correction cf the error requires program changes, the old
versions should te kept until the next image copies are made.
reruns, if necessary, could produce different results.
Other~ise
6.20
IMS/VS Frimer
•
The data tases must be restcred immediately after any failing update
job. The failure could be an applicaticn program, Dl/I, CS/VS, or
hardware error. Next, all data bases should be restored. Then, the
applicaticn ~rograas executed since that image copy was made should
te reexecuted in the original sequence.
As stated in the first part of this chapter under "Which One 10
Cheese," you should realizE the limitations cf the above basic recovery
prccedures. In most cases the 01/1 recoveIY proc~dures as outlined in
the fcllewing secticn are far more cesirable.
!2!~:
EXA~PIES
Job //SAMP180 in IMSVS.PRIMEJOB can be used to make an image copy of the
FhaEE 1 PaIts data base. Job I/SAMP182 can be used to restore this data
base. Ihese jobs shew how the image copy and restore utilities are used
in a tasic recovery Envirctlent.
The following procedures can be used as a basis for the recovery
procedures at your own installation. It is strongly recommended that
you exercise and EnfoIce such FIccedures befere geing into a production
phase with YCUI data bases.
AS~UMFIICNS
1.
AND
FES~EICTI(~S
Image copies of all data sets of all data bases are made at the same
time, that is, no intEIvEning data base processing.
The above restriction is based solely en the subset approach;
it is net a DL/I requirement.
!~li:
2.
Ne ether update program may have been executed after the failure
involving the data tase in error. If that should occur, you must
restore all affected data bases and rerun the programs in FIoper
sequence.
3.
After each new image copy of your data bases, you must run the first
change accumulation with a dummy old change accumulation data set;
that is, nEver use a lcg tape cr change accumulation data set of the
previous period.
POSSIBLE FAILURES
The table in Figure 6-11 lists the most ccmmcn failures, together with
their symfto~s, which can occur in the batch processing of DI/I data
bases. For each failure, an error class is given. This error class
determines the requirEd reccvery actions. See Figure 6-12.
Data Base Recovery
6.21
,
,,
,12.
FAILURE/~I!UA!ION
DESCRIFTICN
I
ISYMPTCMS
I!EECFI
1CLASS I
,~~~-~~~~-~--~~~~-~--~-----.~---------~-----~--------- --------
I 1.
I
,
I
I 3.
I
I
I
14.
I
I
I
15.
I
,
I
I
OPERA'IING ERRCt;
I
1.1 Jot cancellaticn
I X22 ABEND
1.2 irong input cr wrong data base ,INCONSISTENT RESULTS
APPLICATION PP.OGR1M ERBOR
2.1 Wrong logic/output
2.2 Abend
tL/I ERROR
3. 1 Abend
3.2 loo~ or wait state
CS/VS ERRCE
4.1
Abend
4.2 LooF or non-dispatchable
I
I
,INCONSISTENT RESULTS
I USER ABEND
I
I
IDL/I ABEND
ICANCELLED (X22)
,
I
IRE-1FL
IRE-IPl
I
HARDiARE
I
5.1 Read I/O error on a data base lAO status code +
data set
IDl/I message DFS45'11
,
5Q2 Write IIC error on a data base I
data set
IDL/I message DFS45111
5.3 Power failure. machine check
I
IRE-1PL
-----,1
A
A
,
,,
,
I
A I
A ,
I
A
A
C
C
,
It
,,
,
,
,
,
I
E
I
I
I
I
B
I
C
t
I
I
,
I
~-------------------------------------------------------------------~
Figure 6-11. Fossible Failures during Data BasE Processing
,
!2~~:
Upon receipt of message DPS4S1A, the OS/VS system console
aperator sbould la) takE action to stor the execution of sutsequent DL/1
jebs and (t) reply "ABEND".
COEEECTING THE CAOSE OF tHE F1ILURE
!his activity is completely dependent on the type of failure. eften.
the action to te taken is befend the DL/1 environment, for examFle,
system/pover failure. If the error is il: DL/I, the !~U!~_~~§§9g~§_9'Qg
~2~~§_E!f!~!ng~_~!Q~!~ must ba consulted.
If it is a severe error
condition, the IB! Field Engineering Program System Representative
should be notified. Appendix A in the 1~2L!~_~~§~!5~2_!~g_£29!§
~§ij~§Q~j_~!DY!l prcvides guidelines for doing this.
EECOVERY 'tASKS
The subsequent recevery tasks to be performed for each defined error
class (Figure 6-11) are listed in Figure 6-12.
6.22
1MS/VS Primer
RECOVERY TASKS
LOG CLOSE
(DFSUL TRO)
ERROR
CLASS
CHANGE
ACCUMULATION
(DFSUCUMO)
DB RECOVERY
(DFSURDBO)
ALL
EXCLUDE INCLUDE
ONLY
DATA
CURRENT CURRENT AFFECTED
SETS
LOG
DATA
LOG
USED BY
SETS
PROGRAM
NOTES
ALWAYS
CURRENT
LOG
(must be
a tape)
A
RESTART
*
*
*
C
D
*
*
*
1. see A1
2. if program
was successfully
completed, no
restart required
*
*
1. see A1
SAMPLE
JOB
190
+
191
Figure 6-12.
*
*
*
181,381
182,382
382+383
RERUN
1. current log +
output log of
back-out must both
be included in
next change
accumulation run
*
B
#
RESUME PROCESSING
(APPLICATION
PROGRAM)
BACKOUT
(DFSBBOOO)
177,384
178
1. the current,
bad, log must not
be used in any
further back-out
or change
accumulation
initial
program
executions
Data Ease Recovery Actions
ThE data basE bacKout utility is net required for a retrieve-only
Frcgram. ~he additional error class "D" would occur if for any reason
the current 109 data set is unusable. !he current log data set is the
one heing created when the failure occurred.
PossitlE caUSES for this cculd be:
•
Log data set close (DF5ULTRO) failed,
•
Lost log data SEt dUE tc oFerational error,
•
I/O errors on the log data set during change accumulation.
!he recovery tasks in Figure 6-12 must be executed in sequence frem left
to right. Ahenever an Errer cccurs during an A, E, or C error
correctien, yeu can fall tack u~cn the errel class D procedure.
If an error cccurs during the recovery of a class D error, you have to
fall hack to previous image copies and log change accumulation data
sets.
IMAGE COPY/LOG AtMINIS!RA!ION
A rigcrous administration of data tase image copies, log data sets, and
log accumulation data sets is a necessity for data base integrity. We
will now discuss an aOlinistraticn scheme fer this. In this scheme, WE
will use the generaticn data group facility of OS/VS. It would form the
basis of your own scheme, adaFted to your installation standards and
reC3uirements.
Data Base Recovery
6.23
At a minimum you should set up a manual registration scheme fer the leg
data sets, changE accumulations, and image dumps.
Two sets of fcrms could be used.
One form, Figure 6-13, is used to
register all the DIll jobs which produce log data sets.
DATE:
ItIll LOG TAP! POR!
PERleD:
III PAILURE
I
I
,liST
fEEtJlRKS INt
ITl!E I VOL Uft E (S) IJO E/S'I!P ICHECKPOINTID I ERROR DESCRIPTION
I
,,
,
,,
,,
,,
,
I
I
L------------------------------------------------------~
Figure 6-13. Sample DL/I Log !ape Form
1.
III DL/l jots should be listed, also the backout and recovery jobs.
2.
If multiple log volumes are created in one job (step), they should
be listed in time sequence.
3.
A new period starts after each image copy.
4.
Optionally, the data set Ilalle of the log da ta set should be
registered. Normally this would always be the same or a generation
data group, in which caSE only the generaticn number would be
registered.
The SEcond form is used tc IEgister the image copy and change
accuaulation jobs durillg each period (Figure 6-14).
6.24
I"S/V5 Primer
IDl/I Change Accumulation Form
,PERIOD:
DATE:
I
1===============================================================1
I
INFUT
,OUTPUT,
1---------------------------------------------------------------1
I
I
1I
DED
, D A T A SET
,DATA SETIVOLUME(S),
1--------------------------------------------------------I
I
I
I
I
,
I
, CCEY I
I
I
I
,1M AGE
' "
,
I
" I
' I '
===============================================================,
I CID
ACCO!OIA~ICN
I
leG tATA
SETS
I NEW
A~COMULATION
I
1--------------------------------------------------------I
IDA'lA SET 1VOLUME (5) IDA'll
VOLUME (5), CA7A SETI VOLUME (5),
1--------------------------------------------------------I
I
,
,
,
,
,
,
SE~I
1
I
,
,
CIiANGE,
ACCUM. ,
,
I
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
I
I
,
I
,
I
I
,
I
,
,
1
,
I
,
I
,
I
I
I
,
,
I
Figure 6-14u
Registration of Image Copies and Change
,
,
I
Accumul~tiens
~2~~§:
1.
2n
Each period starts with an image copy of all data base data sets.
When generaticn data greuFs are used, only the generation number
te registered.
~eed
3.
The first change accumulation run after the image copy should not
have any old log tape or change accumulation tape as input (that is,
//DFSOCOMO
tr
DUMMY.DCB=BLKSIZE=100).
In our phase 3 sample jebs. we use generaticn data groups for the data
set image cOFies, the log data sets. and the accumulation data sets.
FREQUENCY
OF IMAGE CCFIES
ANt CHANGE ACCUMULATIONS
'lbe frequency of image copies is dependent on your installation
environment. It is a trade-eff betW€eD the necessary recovery costs in
case ef failure and the cost of taking the image copies.
'Ihe basic recemmendation for taking
i~age
copies is:
•
Immediately after initial lead of the data bases.
•
Immediately tefore data base reorganization, if the old space is
deleted during reorganization.
•
Immediately after data base reorganization.
•
Once each WEEk.
Data Base Recovery
6.25
The basic recommendaticn fer the change accumulation is once a day.
Another approach would be tc FEIform change accumulation as a second
step, centrolled via condition codes, in every tL/I update jeb.
n!!~D!i2n_i~~i2g_Q~_!!29!_£2~I_~ng_12g_~~!~_~!!§
protect yourself against unusable image copies, logs, and change
accumulation tafes, you siould retain those tapes for at least two or
three periods (a period is defined as the interval between two
subsequent i;age COEies). A suggested retention ~heme, assuming a one
week Feriod, ~euld be:
~c
•
Log tapes are retained tvo weeks or until the time the next image
copy is made.
•
Change accumulation tapes are made at least daily.
the Feried is retained two extra periodsq
•
Image copies are retained three periods.
The last one of
VSAM CA!A1CG CCNSltEEATICNS
~-----~--------------------
It is strongly recommended that you use a separate VSAM user catalog for
your data tase data sets. ihen yeur installaticn grows, you should
consider a user catalog for each application or project.
In case of an error in the user catalog, you should first try to correct
the protlem with the OS/VS Access Method Services VERIFY function. If
this fails, the following procedure can be fOllowed (VSAM 2 only):
1.
Perform Access
~ethod
Services:
ALTER BEMOVEVOLUMES
This will delete all the data spaces owned by the user catalog and
the user catale9 itself. Yeu should specify all the volumes owned
by that user catalog.
2.
Perform Access
~ethod
Services:
DEFINE
A new user catalog and new data base data space.
3.
DL/I
Recover
~ll
the affEcted data base data sets.
The abOVE procedure completely erases (that is, overwrites
with binary zeros) all VSAM data space, including the user catalog on
the specified volumes. You should use this only if the VSAM USEr
catalog has tecome inaccessible. For more details see also Ferform
Access Method Services: "VSA! Volume Cleanup."
!~~ning:
Additional factors should be considered when setting up recovery
procedures for data tases used by an online IMS/VS system.
As discussed in Chapter 3, "Data Communication Design," a dynamic log
data set is used by the online system for recording data base changes,
as well as the leg tape. Atending online programs are automatically
backed out by the online system using the dynamic log records. In
addition, if the system should fail while an application program is
active, any updates made by that program vill be automatically backEd
out when the system is restarted. In our subset, if the program vas a
6.26
IMS/VS Primer
BMP the updates are automatically tacked out to its most recent
checkpoint. Eecause of this automatic backout, the operator will
usually need to run the recovery utilities only when there bas teeD a
major system failure, generally one which entails a re-IFt of CS/VS, or
when there are I/C errors on a data base.
The recovery proeedures outlined later in this chapter make use of the
DL/I recovery procedurEs and utilities described earlier in this chapter
as vell as an additional log tape maintenance utiiity, the SystEm Log
Terminator utility_
SYSTEM LOG TEBMINA70B
O~ILITY
(DFSFtOTO)
At the time of a system failurE, the System Log Terminator utility can
bE ~sed to reCOVEr any log data that may have been lost as a result of
the failure. A storage dump t~ken at the time of failure is required.
This storage dUMF can te tbE SYS1.DUMP data set, or a stand-alone dump
outFut tapeo the log terminator program:
•
LocatES the log work area, buffers, and control blocks in the
storage dump.
•
positions the log tape and writes the remaining buffers.
•
Cleses the log data set.
Detailed instructions on running the utility, and the possitlE Error
messages that may cccur are described in the !~~L]§ ~.~m§~ ~!§!~~
~!I!i~!l g£~~!lg~!~ ~~ii§-
Figure 6-15 shows the data set requirements for running the System Log
Terlinator utilit)_
DFSFLOTO
OUTPUT
MESSAGES
SYSTEM LOG
TERMINATOR
Figure 6-15.
Running the System log Terminator Utility
~~!_.§!!j;!!!!nj;!
the System log Terminator utility is executed as a standard OS/VS jeb.
The following JCL stat~ments are required:
EXEC
This statement must tE in the following form:
PG !'l=DF SF1C~O
SYSPRINT
DD
Defines the cutput messagE data set.
Data Ease Recovery
6.2·7
LCGTAPE
DD
Defines tbe log tapE tc be terminated. This data set
must have had a disposition of (NEW,KEEP) at execution
time.
rUMF
Defines tbe SYS1.DUMP data set, or the stand-alone dump
data set. !he DCB information for this data set should be
obtained from the CS/VS system programmer in ycur
installaticn.
DD
//TERKIN
IlstEP
//SYSPRINT
//LCGtAPE
//DUKP
II
JOE (ACCTINGINFO)
EXEC PG~=DFSFICTO
DC 5Y5007=A
DD
tt
DSN=IMSICG,VCL=SER=LCG001,UNIT=3400-4,DISP=(,KEEP)
nSN=SlS'.DUMP,VOL=SER=SYSD~P,UNIT=3400-4,DISI=CLt.
lAEEl=(,~l)
Job SAMP492 in
utility.
,tCE=(EECFM=O,ElKSIZE=2056)
IMSVS.PEI~EJCE
also shows an example of the Jet for this
The following recovery prccedures can be used as a basis for the
reccvery procedures in your installation. It is strongly recommended
that you exercise aId enforce such procedures before going into a
prcQuction phase with your online system.
ASSUftP~ICNS
AND EfS!RIC!ICNS
1.
The same assumptions and restrictions described for the DL/I
recovery Frocedures earlier in this chapter apply here as well.
2.
The reccveIY procedures outlined here for handling I/O errors on
data bases involve clcsing dcwn the online sy~tem, running batch
recovery procedures, and then restarting the online system.
]s!!:
The above restriction is based solely on the subset approach.
It is not an IMS/VS requirement that the online system be closed
down to perform data base recovery.
3~
lhese procedures are desi9ned to be used in conjunction with the
If you alter these
prccedures, you should ensure that the operating guide is changed
accordingly.
l~~L!~_R~~!§;_~!§!!~_~!I!i~sl_QI!lS!~I!§_~y!g~.
POSSIBLE FAILOEES
The table in Figure 6-16 lists the most common failures, t0gether with
their symptoms, which can cccur in the online system. For each failure
an error class is given. this error class determines the reguired
recovery procedures, which are outlined in Fi9ure 6-17.
6.28
I!S/V5 Erimer
1
FAIlORE/SI!~A!ICN
tESCEITICl
SY~FTOMS
IIRRORI
-----------------------------1
1------------------------------------I'.OPERA!ING ERBCE
1
122 cr 00020 abend
122 of E~P
,E
,
A
2.APPlICA!ICN FECGB1~ EEECF
2.1 MPP AbEnd
2.2 EMf AbEnd
tFS555,tFS554,DFS980
DFS555,DF5554,DP5980
I
I
I
I
A
3.1"S/VS EBROR
~. 1 Abend
3.2 lOOP or wait statE
IMS Abend code
,
Cancelled (I ~2 or U0020),
B
I
C
, 1.1 Cancel IMS centrel region
,
I 1.2 Cancel
B~P
4.0S/VS ERBCR
4.1 Abend,loop or non-dis~atchable
(storage dump taken)
q.3 Abend,loop or nOD-disFatcbable
(NO storage dump taken)
5.HAEDWARE ERROR
5.1 Machine check, power failure
5.2 I/O Error on data basE
~.3 I/O Error on data base during
tackout
Re-1Fl
,,
,,
t
Be-lit
,,,
,,
DFS451
,
Re-IFl
,
IDFSge1,DFS983
,
,
B
D
D
E
F
L~-~---~---------~------~----~---~------~~--~----------------------~~
!he IMS/VS control region may be canceled, either by
aa CS/VS ~!n~~! ~2!!!D~ if it is running as a problem task,
or by an 05/15 !29!!I ~2!!!I~ if it is running as a system task.
!2!~:
Figure 6-16.
CORRECTING
~HE
Possible failures During An Online Session
CADSE OF THE fAllUEE
This activity is completely dEpEndent on the type of failure. The
action, tc be taken by the .aster terainal operator '"TO) is outlined in
the 1ftS/VS Priaer !~Os Guice.
RECOVERY 'llSIR BUFFER POOLS ( l=YES. O=NO)
EXVR
X
11*
PREFETCH OPTION (Y = YES, N = NO)
PRF
X
11*
MODULE SEARCH INDICATOR FOR DIRECTED LOAD
X
SRCH
11*
o = STANDA~D SE~PCH
11*
1 = SEARCH JPA AND LPA BEFORE PDS
11*
1 CHARACTER SYSOUT CLASS
X
SOD
11*
NUHBER OF OSAH 1/0 REQUESTS
XXX
lOB
11*
VTAM t.UTH PATH OPTIml Cl=YES. O=NO)
X
VAUT
11*
BSAH FOR LOGGING (DEFAULT)
0
LOGA
X
11*
OSAM FOR LOGGWG
1
11*
T FORMATTED DUMP WITH
X
FMTO
11*
STOPAGE IMAGE DELETIONS
II+<
P = FULL FORMATTED DUI-IP
11*
N NO FORMATTED DUMP
11*
Y AUTOHATIC RESTART DESIRED
X
AUTO
11*
~~ = ~c AUTOMATIC RESTART
11*
RDB~~
XXXXX NUMBER OF RESTART DATA SET BUFFERS
11*
TR~NSACTION AUTHORIZATION CHECKING
X
TRN
11*
F = FORCED. Y = YES. N = NO
11*
SIGNON AUTHORIZATION CHECKING
X
SGN
11*
F
= FORCED. Y = YES, N = tlO
11*
RACF USED FOR TRANS. AND SIGNON
X
RCF
11*
Y = YES. N = NO
11*
IHSID XXXX IMS/VS SUBSYSTEM IDENTIFIER
11*
NO RESOURCE ACCESS SECU~ITY
X
0
ISIS
11*
RACF RESOURCE ACCESS SECURITY
1
11*
2 = USER RESOURCE ACCESS SECURITY
11*
0 = NO LOG VOLUME DEQUEUE (DEFAULT)
X
LOGO
11*
1 = DEQUEUE LOG VOLS AT EOV (MVS)
11*
I
0000001
0000002
0000003
0000004
0000005
00000C6
0000007
0000008
0000009
0000010
0000011
0000012
0000013
0000014
0000015
0000016
0000017
0000018
0000019
0000020
0000021
0000022
0000023
0000024
0000025
0000C26
0000027
0000028
0000029
0000030
0000031
0000032
0000033
0000034
0000035
0000036
0000037
000C038
0000039
00000(10
0000041
0000042
0000043
00000t.4
0000045
0000C(+6
OOOOC47
0000048
0000049
0000050
0000051
0000052
0000053
0000054
0000055
0000056
0000057
0000058
0000059
0000060
0000061
Installing
I~S/VS
11*
11********
11*
FBP
11*
PSB
11*
OHB.
11*
08B
11*
TPOP
11*
~KAP
11*
PSSW
11*
CWAP
11*
OBWP
11*
MFS
11*
11*
0000062
0000063
0000064
XXX
MESSAGE BUFFER POOL
0000065
XXX
PSB POOL
0000066
XXX
OMS POOL
0000067
XXX
DATA BASE BUFFER POOL
0000068
XXX
TP DEVICE 1/0 POOL
0000069
XXX
WORKING STORAGE BUFFER POOL
0000070
XXX PSB ~ORK POOL
0000071
XXX
SPA POOL
0000072
XXX
DATABASE WO~K POOL
0000073
XXX
MAXIMUM MFSTEST SPACE
0000074
0000075
0000076
11******** MEMBER SUFFIXES **********************
11*
0000077
11*
SUF
X
LAST CHARACTER OF CTL PROGRAM LOAD MODULE MEMBER NAHEOOOOOiS
11* FIX
XX
2 CHARACTER FIX PROCEDURE MODULE SUFFIX
0000079
11* PRLO XX
2 CHARACTER FROCLIB HE~aER SCFFIX FOR PRELOAD
0000080
11* YSPEC XX
2 CHARACTER BUFFER POOL SPEC MODULE SUFFIX
0000081
0000082
II*****~***************·*************************
11*
0000083
IIDFSPESLB 00 OSN=IMSVS.RESLIB,OISP=SHR
0000084
IIF~GCLIB
00 DSN=IMSVS.PPOCLIB,DISP=SHR
0000085
II!EFROER DO DS:l=U1SVS.IMSLOG,DISP=( ,KEEP),
0000086
II VOL=C ",99).UHIT=C&LCGT"DEFER),
0000087
I I OCB= (RECFH=V6, BLK S1 ZE=3992, L~ECL=3988. 6UF~lO=2 )
0000088
II1HSL03R 00 OSN=IMSVS.IMSLOG.
0000059
II0ISP=(MOO,KEEP),UmT=AFF=IEFRDER
0000090
IIIH~HJ~l
00 OSN=IMSVS.nIS~fO~l,OISP=( ,KEEP).
0000091
II VOL=(,.,99I,UNIT=(&LCGT"DEFER;SEP=IEFROER)
000009~
00 OS~;=IH5'.JS.Q6LKS,DISP=OLD
IIQSLKS
0000093
IISHMSG
00 OSN=IHSV5.SHHSG,OISP=OLO
0000C94
I ILG~fSG
00 DSN=IMSV5 .lGHSG ,OISP=OLD
0000095
IIIHSACB
00 DStl=H1SY5.ACBLIB,OISP=SHR
00000'76
IIWSDIlIB DO OSN=!HSV5.FORMAl.DISP=OLD
0000097
IISYSUDUHP 00 SYSOUT=&SOUT.
0000098
II DC8=(LPECL=125.RECFH=FBA,BLKSIZE=3129),
0000C99
II SPACE=t6050,3DO,.,ROUSO)
0000100
DO OSN=IMSVS.ROS,OISP=OLO
IIIHSROS
0000101
II0U~lP
DO &DUHFOS,
0000102
II DISP=OLO,LA8EL=( ,NL)&DV&OU
0000103
IIIMSUDU~iP 00
SYSOUT=t.SOUT,
0000104
IIOC8=(LRECL=125.RECFH=FBA,BLKSIZE=3129).
OC00105
II SP~CE=(6050,300, •• ROUND)
0000106
IIH.~TRIX
00 OS~l=!HSVS.tlATRIX,OISP=SHR
0000107
IIFRINTOD 00 SYSOUT=&SOUT
0000108
IIIMSDBL
DO OSN=IMSVS.OBLLOG,OISP=SHR
0000109
11*
0000110
11* USER HUST SUPPLY THE 00 STATEHENTS
0000111
11* FOR THE ON-LINE DATA 8~SES TO BE
0000112
11* WSERTEO HERE FRIeR TO ATTEMPTING
0000113
I I~ AN m~- LHiE SYSTEM EXECUTION USING
0000114
11* THIS PROCEDURE.
0000115
STO~AGE
POOL SIZES IN lK BLOCKS
******
1.
The program name specified on the EXEC statement is DFSRRCOO for
OS/VSl and DFSMVRCO for MVS.
2.
The BLKSIZE and LRECL valu~s shown in the IEFRDER dd statement are
the default values.
If the DCB parameters are changed, log
initialization calculates the smallest value necessary for logical
record length.
If the JCL logical record length value is larger
than the calculated value, the JCt value is used; otherwise log
initialization uses the calculated value for logical record length
and adds 4 for the block size.
3.
The DD statement called IMSMON describes the recording device to be
used by the DC Monitor and is required only if you wish to invoke
the monitor during an online session.
4.
The above listed IMS procedure is produced for the VTAM only system.
The procedure for the BTAM only system is the same, but will contain
DD statements for the communication lines.
7.72
IMS/VS Primer
5.
In our suhset. you must add the DD statements for the data base data
sets to be used by the control region to this procedure. See job
IISAMPI4C in IMSVS.PRIMEJOB.
EXEC Statement sutset Parameters for IMS Procedure
RGN=
specifies the si2e of the region in which the control program
is to run, and has meaning only in an MVS system.
SOUT=
specifies the class to be assigned to SYSOUT DD statements.
DPlY=
specifies the OS/VS dispatching priority at which the IMS/VS
centrol region should operate. See the as/vs JCL documentation
for details of DPTY. !he IMS/VS ccntrol region must not be
executed at priority zero, or be scheduled into an OS/VS1
partition whose priority falls within JES1 DDG, or into an MVS
region whose priority falls within a JES2 APG. A general rule
to follcw is that the IMS control region dispatching priority
must always bE higher than the dis~atching priority of an
IMS/V~ dependent region.
CTL=
specifies whether IMS/VS should operate as a system task.
Cll=C!l indicates that it should run as a system task; CTl=CTX
indicates that it should run as a ~roblem program. C!L=CTL is
recommended.
VSPEC=
specifies the two-digit suffix of the DFSVSMnn member of
IMSVS.PPOC1IB that contains the
specifications to tE used.
VSA~
and OSAM tuffer pool
FIX=
specifies the two-digit suffix of the DFSFIXnn member of
IM5VS.PROCLIB which centrols the fixing in real storage of
selected Farts of the CTl region.
VAU~=
specifies whether (1) cr not (0) IMS/VS is to use the VTAM
authorized path facility. The recommended option is 1.
LOG!=
specifies which lcgging facility, ESAM or OSAM, IMS/VS is to
use. Specify 1 for OSAM, the recommended option.
The other symbolic parameters need not be specified because thE default
values calculated durin9 syster definition should be sufficient for our
entry environment.
LOGT=
specifies the tape device type.
~he
default is device type
2400.
Installin9 IMS/VS
7.73
LooD=
specifies whether (1) or not (0) IMS/VS output log volumes are
to be degueued at EOV. This parameter is valid for MVS only.
The recommended value is 1 especially if you consider restarts
of BMP, which use the X~ST call.
IMSBATCH PROCEDURE
II
II
II
PROC
IIG
EXEC
II
II
II
IISTEPLIB
DO
DO
IIFROCLIB DO
IISYSUOUHP 00
II
II
MBR=TEHPNt.ME,SOUT=A,OPT=N.SPIE=O.TEST='O.
PSB=.PRLO=.STIHER=.CKPTIO=.IN=.OUT=,OIRCA=OOO.
PAROLI=,CPUTIHE=,NBA=.06A=,IHSID=.AGN=
PGH=OFSRP.COO,REGION=128K.
PAP.H=(8HP,&H6Q,&PSB.&IN.&OUT,
&OPT&SPIE&TEST&OIP.CA.&FRLO.&STIMER.&CKPTIO.
&PAROLI.&CPUTJHE,&NBA.&OBA.&IHSID.&AGN)
DSN=IHSVS.RESLIB.DISP=SHR
DSN=IHSVS.PGHLIB.DISP=SHR
OSN=IHSYS.PPOCLIB.OISP=SHR
SYSOUT=&SOUT.DCS=(LRECL=121.RECFM=YBA,BLKSIZE=3129).
SPACE=( 125 d 2500.100) ,R LSE •• ROUtlO )
0000001
0000002
0000003
0000004
OC00005
0000006
0000007
0000008
0000009
0000010
0000011
0000012
Note: You must add a DO statement for the log tape containing the
checkpoint data when you are restarting a BMP which uses the X~ST call.
This 00 statement has the DDname IMSLOGR.
EXEC Statement Parameters for IMSBATCH
MBR=
specifies the application program name.
SOUT=
specifies the class assigned to SYSOUT DD statements.
PSB=
is an optional parameter specifying a PSB name when the PSB name and
application program name are different. The PSB name must be
defined as PGMTYPE=BATCH with an APPLCTN macro in your IMS/VS system
definition.
SPIE=
specifies the SPIE option: 0= allow
use~
SPIE, if any, to remain in
This option
effect while processing the application program call.
is recommended.
1= negate the user's SPIE while processing the application program
call. Negated SPIEs are reinstated before returning to the
application program.
TEST=
specifies whether (1) or not (0) the addresses in th~ user's call
list should be checked for validity. Zero (0) is the recommended
vallle.
1.74
IMS/VS Primer
PRlD=
should be omitted in our subset.
CKF!ID=
specifies the check~oiDt at which the ~ro9ram is to be restarted,
specified as a 1-to S-character extended checkpoint ID. If this is
not a restart run, this parameter should be omitted.
CPT=
specifies the action to be taken if the batch message region starts
and there is no centrel ~regram active.
N
ask operator for decision. !his is the default.
W
wait fer a centrol regionQ
C
cancel the batch message region automatically.
N is the recommended value.
IN=
should be omitted in cur subset.
CUT=
should be omitted in our subset.
DIBel=
should hE omitted in eur subset..
IMSMSG PROCEDUR E
IIHESSAGE JOB 1,IHS,HSGLEVEL=1,PRTY=11,CLASS=A,HSGCLASS=A,REGION=128K
IIREGION EXEC
0000001
0000002
IISTEPLIB
PGH=OFSRRCOO,REGION=128K,
TIHE=1440,OPRTY=112,O),
PARM='HSG.0010000000CO'
OSN=IHSVS.RESLIB,OISP=SHR
OSN=~HSVS.PGHLIB,OISP=SHR
0000006
OC00007
II
OSN=IHSVS.PROCLIB,OISP=SHR
SYSQUT=A,OCB=ILRECL=121,BLKSIZE=3129,RECFH=VBA),
SPACE=(125,(2500,100),RLSE"ROUNO)
II
II
00
1/
00
IIPROCLIB 00
IISYSUDUHP 00
This ~rocedure must be copied to IMSVS.JOES.
IMSVS. PBIMEJOE.
0000003
OOOCOO~
0000005
0000008
0000009
See job //SAMPI42 in
Installing IMS/VS
7.75
IMSRDR PROCEDUi E
PROC MBR=IMSMSG
II
READER FIRST LOAD
IIIEFPROC EXEC PGH=IEFVHA.
PARH='00100300005210EOOOIIAXX' DEFAULT OPTIONS
II
BPPTTTTSSCCCRLAAAAEFHXX
PARM FIELD
11*
B
PROGRAM~IER NAHE AND ACCOUNT NUHSER NOT NEEDED
11*
PP
PRIORITY=Ol
11*
TTTTSS JOB StEP INTERVAL=30 HIUUTES
1/*
CCC JOB STEP DEFAULT REGION=52K
11*
R
DISPLAY AND EXECUTE COl1HAllDS=l
11*
L
BYPASS LABEL=O
11*
AAAA COHHMlO AUTHORITY FOR HCS=EOOO
11*
- ALL COHHAtmS HUST BE AUTHORIZED
11*
E
JCL MESSAGE LEVEL DEFAULT=l -ALL HESSAGES
11*
F
ALLOC/TERH HESSAGE LEVEL DEFAULT=l -ALL HESSAGES
11*
H
DEFAULT HSGCLASS=A
11*
XX
PARTITION,ROR WILL HAVE DISPATCHING
11*
PRIORITY 1 LO~ER THAN PARTITION
11*
SPECIFIED. XX=SYSTEH TASK PRIORITY
11*
IIIEFRDER DO DSN=IHSVS.JOBS(&HBR).OISP=SHR,OCB=BUFNO=l
IIIEFPOSI DO DSN=IHSVS.P~OCLIB,DISP=SHR
00 DSN=SYSl.PROCLIB,DISP=SHR
II
0000001
0000002
0000003
0000004
0000005
0000006
0000007
0000008
0000009
0000010
0000011
0000012
0000013
0000014
0000015
0000016
0000017
0000018
0000019
0000020
0000021
This procedure must be copied to SYS1.PROCLIB.
IMSVS. PRIMEJOB.
See job //SAMPI24 in
PSBGEN PROCEDURE
II
PROC HBR=TEHPNAHE,SOUT=A
IIC
EXEC PGN=IFOXOO,REGION=200K.PARH='OBJ,NODECK'
IISYSLIB
DO D$N=IHSVS.HACLIB,OISP=SHR
IISYSGO
00 UNIT=SYSDA,OISP=( ,PASS).
SPACE=(80,(100,lOO),RLSE).
II
DCB=(BLKSIZE=400,RECFH=FB,LRECL=80)
II
IISYSPRINT 00 SYSQUT=&~~UT,OC6=BLKSIZE=1089,
II
SPACE=(121,(300,300).RLSE"ROUNO)
IISYSUTl
0') UNIT=SYSOA,DISP=( .DELETE),
SPACE=(l700.(100,50))
II
IISYSUT2
CO UNIT=S~SDA,DISP=( ,DELETE).
SPACE=(l700,(100.50))
II
IISYSUn 00 UNIT=(SYSOA,SEP=(SYSLIB.SYSUTl,SYSUT2)),
SPACE=(1700,(100,50))
II
IlL
EXEC PGH=DFSILNKO,PARH='XREF,LIST',COND=(0,LT,C),REGION=120K
IISTEPLIB DO OSN=IHSVS.RESLIB,OISP=SHR
IISYSLIN
00 OSN=*.C.SYSGO,DISP=(OLO,OELETE)
IISYSPRINT 00 SYSOUT=&SOUT,DCB=BLKSIZE=l089,
SPACE=(121,(90,90),RLSEI
II
IISYSLHOD 00 OSN=INSVS.PSBLIB(&MBR).OISP=SHR
IISYSUTl
00 UNIT=(SYSDA,SEP=(SYSLHOO,SYSLIN)),
SPACE= ( 1024, ( 100,10) ,RLSE ) ,DISP=( ,DELETE)
II
7.76
IMS/VS Primer
0000001
0000002
0000003
0000004
0000005
0000006
0000007
0000008
0000009
0000010
0000011
0000012
0000013
0000014
0000015
0000016
0000017
0000018
0000019
0000020
0000021
0000022
SECURITY PROCEDURE
PROC
II
EXEC
liS
IISTEPLIB 00
IISYSPRWT 00
IISYSPU~KH DO
II
II
IISYSLIN
00
II
II
IISYSUTl
DO
II
IISYSUT2
DO
II
IISYSIN
DO
EXEC
IIC
IISYSF"RINT 00
IISYSGO
00
II
II
IISYSUTl
00
00
IISYSUT2
I/SYSUT3
DO
/1
IISYSIN
DO
EXEC
/IL
I/STEPLIB 00
IISYSPRINT DO
IISYSLMOD DO
/IH~PUT
//SYSUTl
/ISYSLIN
00
DO
DO
OPTH=UPOATE,IHS=' ,O',SOUT=A
PGM=OFSISMPO,PARH='&OPTN.&IHS. '
OSN=IHSVS.RESLIB.OISP=SHR
SYSOUT=SSOUT,DCB=IRECFH=VBA.BLKSIZE=129,LRECL=12S1
U~IIT=SYSDA, SPACE= (80. (800,400), , .RCUHO ) ,
OC6=IRECFH=FB,LRECL=80,6LKSIZE=400),
OISP=(NEW,PASS)
UNIT=SYSDA.SPACE=(TRK,(1,1»),
OCB=(PECFH=F,BLKSIZE=801,
OISP=( t~EI.I. PASS I
UNIT=SYSDA,oCB=(BLKSIZE=500.RECFH=FB).
SPACE= (100. (400.400), •• ROUtm)
UNIT=(SYSDA,SEP=SYSUTl).oCB=*.S.SYSUT1.
SPACE=(100,(400,400)".ROUNO)
OSN=ND.SYSIN.OD.LSTERISK
PGH=IFOXOO,PARH='OBJ,NODECK' ,CONo=(12,LT,S),REGION=128K
SYSQUT=&SOUT,OC6=6LKSIZE=1089
U~IIT= (SYSOA, SEP=SYSPRINT ), OISP= ( ,PASS) ,
0000001
0000002
0000003
0000004
0000005
0000006
0000007
0000008
0000009
0000010
0000011
0000012
0000013
0000014
0000015
0000016
0000017
0000018
0000019
SPACE=(80,(4CC.4001",ROUN~).
0000020
DCB=-.S.SYSPUNCH
UtUT=SYSDA. SPACE= (Cn, (5.1) I
0000021
0000022
UtHT=SYSOA. SPACE= (CYL. (5.1) I
0000023
Ut~IT= ( SYSDA. SEP= (SYSUTl. SYSUT2 II,
0000024
SPACE=(CYL.(5.1)1
0000025
DStl=*. S. SYSPL't~CH. OISP= (OLD, DE LETE )
PG~I=OFS!L~~KO, PARH=' LIST .llE ,OL' ,REGION=llOK ,CONO=( 4, LT ,5 I 0000026
0000027
05N=IHSVS.HATRIX.OISP=SHR
0000028
SYSDUT=&SDUT,OCB=(RECFH=F6A,LRECL=1Z1,BLKSIZE=605)
0000029
DSN=IHSVS.HATRIX,DISP=SHR
0000030
DStl=*. C. S (SGO, Drsp= (OLD ,DELETE)
0000031
UNIT=(SYSDA,SEP=IHPUTI,SPACE=(CYL,(S,1))
0000032
DStl=*. S. Sl'SLIN, OISP= (OLD, DE LETE )
MFSRVC PROCEDURE
II
//NFSRVC
1/*
//*
PROC DEVCHAR=O
EXEC PGH=oFSUTSAO,REGION=250K,PARH='DEVCHAR=&DEVCHAR'
PRINT FILES
//*
I/SYSPRINT DO
//*
IISYSSNAP DO
//*
IISYSUoUHP DO
SYSOUT=A
OCB=(RECFN=VBA.LRECL=137)
Sl'SOUT=A
DCB=(RECFN=VBA.LRECL=125,BLKSrZE=1632)
SYSOUT=A
11*
//*
//*
REFERAL LIBRARY
IIREFIN
DO
DSN=INSVS.REFERAL,DISP=OLD
11*
1/*
ON-LINE FORHAT LIBRARY
11*
//FORHAT
DO
DSN=INSVS.FORHAT,DISP=OLO
1/*
11*
/1*
1/*
//SYSIN DO * HUST BE SUPPLIED BY
USER WITH INPUT CONTROL CARD STREAM
1/*
11*
11*
11*
11*
ALL DISP=OLD SPECIFIr.ATIOUS OF THIS
PROCEDURE ARE REQUIRED ••..•..
0000001
0000002
0000003
0000004
0000005
0000006
0000007
0000008
0000009
0000010
0000011
000001Z
0000013
0000014
0000015
0000016
OCOC017
0000018
0000019
0000020
0000021
0000022
0000023
0000024
0000025
0000026
0000027
Installing
I~S/VS
7.'7'7
MFSUTL PROCEDURE
II
II
II
II
II
1151
PRoe RGN=360K,SOUT=A,SNOOE=IHSVS,
SCR=UOLIB .HBR=NOt1BR ,PXREF=NOXREF,
PCOHP=NOCOHP, PSUBS=tIOSUSS, POIAG=NODIAG,
COMPR=NOCCHFFE55.COHPR2=COHFRESS,
LN=55,SN=S,OEVCHAR=O
EXEC PGH=OFSUPAAO.REGION=aRGH,
II PARH="PXREF,'PCOHP,&PSUBS,&FOIAG,&CO~PR,
II LINECNT=&LN,STOFRC=&SH,OEVCHAR=&OEVCHAR'
II*SYSLIB - USER OPTION
IISYSIN
00
DSN=&SNOOE .. &SOR.(&MBR),OISP=SHR
IIREFIN
00
OSN=IHSVS.REFERAL,OISP=OLO
IIREFOUT
00
OSU=IHSVS.REFERAL,OISP=OLO
IIREFRO
DO
OSN=IHSVS.REFERAL,OISP=OLO
IISYSTEXT DO
OSN=&&TXTPASS,UNIT=SYSOA,
II
SPACE=(CYL,(l,l»,OCB=8LKSIZE=eoo
IISYSUT3
00
UNIT=SYSoA,SPACE=(CYL,(1.1»
IISYSUT4
00
UNIT=SYSOA,SPACE=(CYL,(1,l))
110L!t~MY
00
OSH=IHSVS. PROCLIS( REFCPy) ,OISP=SHR
IIUTPRINT 00
SYSOUT=&SOUT
IISYSPRINT 00
SYSOUT=&SOUT,DCB=(RECFH=FBA.LPECL=133,BLKSIZE=1330)
IISYSUOUH~ DO
SYSOUT=&SOUT
IISEQ6LKS 00
DSN=&&6LKS,oISP=(NEW,PASS),
II
UNIT=SYSOA,SPACE=(CYL,(l,l)
1152
EXEC FGH=OFSUNUSO,REGION=gPGN,
II
PARH='&CCHPR2,OEVCHAR=&OEYCHAR',
II
cmI0=(S,LT,S1)
IISEQSLKS 00
OSN=&gSLKS,OISP=(OLD,OELETE)
IIUTPRINT 00
SYSOUT=&SOUT,oC6=(RECFH=F8A,LRECL=133,BLKSIZE=1330)
IISYSUOUHP DO
SYSOUT=&SOUT
IIFORHAT
00
OSN=IHSVS.FCPHAT,OISP=OLO
I10Ut:m
DO
OSN=IHSVS.PPOCLI6(FHTCPY),OISP=SHR
IISYSFRINT 00
SYSOUT=&SOUT
IISYSUn
00
UIIIT=SYSOA, SPACE=( cn, (1,11 )
IISYSUT4
00
UNIT=SYSOA,SPACE=(CYL,(l,l)
11*
11*
0000001
0000002
0000003
0000004
0000005
0000006
0000007
OOOOOOS
0000009
0000010
0000011
0000012
0000013
0000014
0000015
0000016
0000017
000001S
0000019
0000020
0000021
0000022
0000023
0000024
0000025
000C026
0000027
0000028
0000029
0000030
0000031
0000032
0000033
0000034
0000026
0000027
Although this is not an IMS/VS req~irement we recommend that DB-only
users wishing to upgrade to a DB/DC system re-do the ~ntir~ IMS/VS
installation, following the steps outlined in the section "INSTALLING
I~S/VS DB/DC." The only step that should be omitted is the allocation
and construction of the application libraries DBDLIB, PSBLIB and PGMLIB.
The sample job stream in IMSVS.PRIMEJOB is constructed in such a way
that the scratching and allocatinq of these libraries is done in a
separate job (SAMPI15) which can be omitted wh9n doing the inst~llation.
The installation of IMS/VS under OS/VS2-MVS is much the same as
described for OS/VS1 in the first part of this chapter.
THE INSTALLATION JOBS
The jobs necessary to install IMS/VS under OS/VS2 MVS are, in general,
the same as for OS/VS1. The differences. are listed below and/or
included in IMSVS.PRIMEJOB with a prefix of SMVS.
The following exceptions/additions apply:
1.
The IMSCTRL macro of the
Stag~
definition should specify:
SYSTEM=(VS/2,BATCH,3.7) for a DB installation (I/SAMP!2')
or
SYSTEM=(VS/2,ALL,3.7) for a DB/DC installation (//SAMPI22,
//SAt1PI23)
7.78
IMS/VS Primer
2.
Both VTA~ and the 1MS/VS online control region run as authorized
subsystems under MVS. You must include the libraries from which
IMS/VS, V1AM and NeF/VS are loaded and executed in the appropriate
authorization tahles. Note that you should not concatenate
1MSVS.RESLIB with unauthorized libraries such as PGMLIB on the
STEPLIE or JOELIB DO statement of the IMS online control region
~rocedure, as this will cause the joh step to become unauthorized.
The Dt/I, MPP, and BMP regions do not require IMS/VS to run as an
authorized subsystem.
3.
If you choosE to concatEnate IMSVS.RESLIE to SYS1.LINKLIB in
LNKLSTOO, the node IMSVS may not be used as a CVOL pointer. If you
wish to use it as a eVCI pointer you should consider renaming the
RESLIE. In our exam~IE the equivalent cf job //SAMFI01 in the
OS/VS1 installation, job //SMV5101 builds an IMSVS CVOI pointer
using Access Method Services. This job requires selectable unit e
(5U8) to be installed in yeur OS/VS2(MVS) system. If you don't ·have
sue installed, you cannot build an index structure for node IMSVS in
the CVOL on 1MSFRM. Instead you should catalog the IMSVS data sets
in a VSAM catalog.
4.
The resource clean-up module DFSMRCtO must be link-edited into
5YS1.LPALIB, and the IEAVTR~t CSECT of module IGC0001C in
SYS1.LPALIB must tE updated. Jobs //SMVSI27 and I/SMVSI33 show an
examFle of the JCl to do this. The actual CSECT offset is in
general 00. For mcre details see "Clean-up Routines" in the "CS/VS2
System Programming library: Supervisor." After this job has been
executed the system must be re-IPLed with the CLPA option.
5.
The abend formatting module OF5AFMDO must be link-edited into
SYS1.lPAIIE under the name IGC090SA. See job //5MV5127.
6.
If your MV5 system uses JES2, you must add IMSVS.PROCLIE to the
concatenation f£r PROCOO in the JES2 reader procedure. A job for
this update is not provided in our samFle jobs because of the
critical nature of the JES2 procedure. A JCL error in this
procedure leaves MVS without any readers. printers, or initiators.
Another system must be used to correct the error. Therefore, it is
recommended that this update be performed by the MV5 system
programmer.
Certain considerations are involved when concatenating the
IMSVS.PRCCL1E to the FReCOO OD statement in the JES2 procedure:
the volume with the named data set must be available at every
1PL.
the data set referenced first must have the largest block size
or a 'DCE=BLKSIZE=' cverride parameter on the DD statement.
Some procedures generated by IMS/VS system definition reference
IMSV5.PFCCLIE members as input to the linkage editor, which
might have a tlocksizE restriction in your installation.
the named PROCLIB data set must be cataloged on the master
catalog or must be referenced by the 'UNIT=' and 'VOL=SER='
keyword paramEt~rs in its DD statement. If cataloged in the
master catalog, you cannot use the node name as a CVOL pointer.
the most elegant solution is to copy the 1M5/V5 procedures to
SY51.PROCL1B, or tc copy the I"SVS.PFOCLIE under a different
name to one of the system resident volumes and catalog it in
the master catalog.
Installing I"5/V5
7.79
1.
The VTAM storage pool specification on //SAMPI54 should be adapted
to your installation and VTA~ level. Notice that the recommended
lOBUF and PPBUF buffersize of 336 must be the same as the UNITSZ=
value on the HOST macro of the NCP (job //SAMPI61).
8.
The program name on the execution statement of the VTAM start
procedure should be changed from ISTINA01 to ISTINMOl (job
//SAMPIS5) •
9.
The program name on the execution statement of the GTF procedure
should be changed from HHLGTF to AHLGTF (job //SAMPI56).
10. The UNITSZ value on the HOST macro in job //SAMPI6' must be equal to
the buffer size of the IOBUY and PPBUF storage pools in job
//SAMPI54. See also note 1 above.
1'.
Whether or not the IMS/VS CTL region is executed as a system task or
a problem task is dependent upon its starting as a system task via
the OS/VS console or its starting as a problem task via JES.
THE SAMPLE JOBS
The sample job~ are the same as for OS/VS1. If you don't have SUS
installed, you must build the generation data groups in the VSAM user
catalog (job //SAMP009). In addition, all data set names of the
generation data groups (log and image copy data sets) in the sample jobs
should use the node IMSPRIME instead of IMSVS. This is due to the
difference in the VSAM catalog mechanism for ganeration data groups for
OS/VS1 and OS/VS2 without SU8.
Executing of the OS/VS 2 MiS sample jobs can be best done by submitting
them from IMSVS.PRIMEJOB. The following job can be used to read those
jobs from their job library and submit them to an internal reader:
JOB
PROe
EXEC
DD
DD
DD
A,'IMS/VS-PRIMER'
J08=TEMPNAME
PGM=IEBGENER
SYSOUT=A
DUMMY
DSN=IMSVS.PRIMEJOB(&JOB),DISP=SHR
//SYSUT2
DD
SYSQUT=(A,INTRDR) ,DCB=BLKSIZE=80
V
PEND
EXEC.
SUBMIT,JOB=jobname
//SUBMIT
//SUEM1T
/ISTEPl
//SYSPRINT
I/SYSIN
/ISYSUT1
//SUBMIT
To provide for th~ continuing exapansion of hardware and software
functions, IBM provides at regular intervals new releases of IMS/VS.
Befor~ using a new release and/or function, you might want to test them
in your environment, but isolated from your existing (production)
system.
It is recommended ~hat you maintain separate production and test vdrsion
of the following system libraries: LOAD, GENLIE, DBSOUPCE, OBJDSET,
PROCLIB, MACLIB, MATRIX, JOBS, and RESLIB. From an application
development point of view, you might want to maintain s~parat~ versions
of DBDLIB, PSBLIB, FO~MAT, REFERAL, AND PGMLIB.
7.80
I~S/VS
Primer
The OS/VS System Modification Program (SMP) is available to IMS/VS users
as an option.
SMP is a facility that allows you to apply program
temporary fixes (PTFs) or user modifications either selectively or as a
group to VS, or VS2 or the distribution libraries (DLIBs) associated
with them.
See the Q§L!2 2Y2t~m ~Qgifi£~iiQn f~2g~!m (~~f) ~I~i~m
f~Qg~!mms~~§ ~Yi~~ for a detailed description of SMP.
A sample SMP job
stream is provided to demonstrate what must be done to maintain your
IMS/VS libraries using SMP.
This sample SMP job stream is on file 4 of your Data Base System tape.
It may require minor changes depending on your system configuration.
A
detailed description of this job stream and its use is included in the
f£Qg£~m ~~~~£!Q£Y which accompanies the IMS/VS distribution tape.
When you are installinq a new IMS/VS release, it is recommend~d to
perform some kind of regression test before you use this new IMS/VS
release as you production system.
The IMS/VS Primer function sample
jobs, although not explicitly designed for this purpose, can be used as
an initial test vehicle.
When your installation grows, you might
complement this with a subset of your production jobs and procedures.
Quite often, initial test cases used during development are also very
useful for regression testing.
Therefore they should be maintained even
after the application goes into production.
Installing I"S/VS
1.81
This chapter discusses the factcrs involved in operating I~S/VS online.
It shculd be read in conjunction with the IMS/VS Primer operator's
guides:
These guides are examples cf a Master !erminal 0Ferator's guide (MTC
guide) and a Remote Terminal Operator's guide CRTO guide) in either a
VTAM or ETAM environment. 1be M~O Guide also has a detailed discussion
of the IMS/VS (and V!APo) commands used in our subset.
An online system Futs a greateI demand on an oFerations staff than a
Fure batch system. ie have categorized the extra work into four grcups,
called !YD~112D!' which are described below. Because each
crganization's policies and structure will determine how the functions
will be implemented, we have limited ourselves to a discussion cf the
characteristics of each. Ecwever, it is im~ortant that these functions
be recognized and the responsibilities assigned to specific individuals
in the organizaticn.
Two of these functions, the Master !erminal Operator and the User
Liaiscn GrouF, are also discussed in greater detail later in this
chapter.
TEE MASTER TERMINAL OPERA!CR FONC!ION
This fUDction has the responsibility for the operation of the IP.S/VS
online system, including:
•
Starting and stoPFing thE system and its resources.
•
Displaying system informaticn.
•
Carrying out emergEncy reccvery procedures as outlined by tE and/or
DC Administration.
!HE
NE!iCR~
CCN!ECI
FU~C!IC~
This function has the respcDsibilty for the physical maintenance of the
terminals and associated equipler-t in the netwcrk including:
•
Interfacing with the suppliers of the communication lines and any
other equiplEnt in the netwcrk.
•
Co-ordinating the installaticn of new terminals and associated
eguiFlent.
operations
8.1
!H! APPLICA!ICN SUPERVISCF FUNCTION
This function has the res~onsibility fer maintenance of all programs and
transactions in specific applications. Persons performing this function
should have a detailed kncwledge of ap~lications, and ideally should be
involved in the original design and analysis phases for them. This
responsitility includes:
4
Handling all ~ueries relating to that application which are routed
to them by the ~aster Terminal Cperatoror the User Liaison group
(see telow) •
•
Handling ~roblems such as an application program abend, or a request
by a remote terminal operator for clarification of a user procedure.
~HE
OSEE lIAISeN
FO~CTICN
This function ~rovides the first pcint of contact for all remote
terminal operators .ho experience problems with, or who have queries
about, the online systemft As such, they:
•
•
Provide assistance in the analysis cf such problems, whether they
are related to hardware, software, cr a specific application.
Route problems or queries which they cannot resolve to the
function: Network Control, Master Terminal O~erator, cr
Applicaticn Su~erviscI.
a~propriate
We recommend that the Master ~erminal Operator never be contacted
directly by remote terminal operators, but that all queries be routed
through the liaison function.
]Q!~:
As stated earlier, the person assigned to this function is responsible
for the operation cf the cnline IMS/VS system. We recommend that,
during anyone shift, one specific operator be designated as the MTO,
and that he te the cnly ene whe uses the master terminal during that
period. However you should ensure that more than one person in your
installation is trained as an M~O te provide backup.
It is impcrtant that the MTO be familiar with all the operating
procedures he may be called upon to useu It is also important that
formal reporting precedures are established, so that he can document any
problems he encounters. Examples of forms to be used for this purpcse
are shown in the sample M~O Guide.
The interface between the M!O and the other functions in the
crganization must be clearly defined. He should be given a list shewing
whom he is to ccntact in DC Administraticn, Network Control, User
Liaisen, and the Application Supervisor groupo
~HE
MAS~EB
~EEMINAI
CFEFATCE'S GUIDE
sample guide caD te used easily by an operator. It is also a
learning tool. It includes only those ~Iocedures used by an ~TC, and
does net cover Frocedures for error situations to be bandIed ty a
support group such as DC Administration. The sample guide is designed
in such a way that it can be easily maintained and extended with
additional precedures as the network is increased and new applications
are added. ~his document is not meant to replace the l~~L!~_~~§§gg§§
2n~_~Qg!§_~§!~~~£g~_~~]yg!, but it is to be used in conjunction with it.
~his
8.2
IMS/VS Primer
MODIFICATIONS TO !HE SAMEtE MTO GUItE
If you wish to use the sample guide in your installation you will nEed
to make some modificaticns te tailer it to your own needs.
The functions described abeve are referenced in the guide with the
names: DC Administration, Application Supervisor, Network Control, and
User Liaison. If you do net use these titles in your organization you
should reFlace them with the appropriate titles. You should alsc file
with the guidE a list cf the names and telephone numbers of the people
respcnsible for each function.
The sample guide is designed for use in an CS/VS1 installation. It
assumes that yeu are running the IMS/VS centrol region in partition Fl.
If this is not correct for your installation, you should modify Chart
E-2, "Initializing the IMS/VS Centrol Eegion."
~!§_In§~2!1~~~Qn§
If you use MlS'in your installation, you will have to modify the chart
described atove in thE OS/VSl secticn, and also Chart E-7 (OS/VS
abends). In addition, you have to use bypass label processing (ELF) in
the IMSLCGE tt statement of the EME restart JCL (//SAMP474) if the EMP
restart is across a Cll regien restart. !his is because 05/V52 MV5
restores its volume serial enqueue on the input log tape in the CTl
region. This can also he avcided by stopping and restarting the CTl
regicn immediately after the emergency restart, and before the EMF
restart ..
!he M!C guide is designed upon the IM5/V5 Primer Function subset as
defined in Chapter 1, "Intrcduction." As a result, certain IM5/VS
functions are not included in our MlO guide. This is particularly true
fer the enhar.ced disk restart. The rationale behind this is that we
feel that you should first gain experience with leg tape restart before
using disk r~start. However, once you are familiar with log tape
restart, we encourage you tc switch to disk restart and adapt your MTC
guide te that res~ect.
The sample MTO Guide includes in Chapter 4 tables ~hich describe the
net~ork in cur sam~le system, and details of the sample Froqra~s,
transactions and data bases. !hese tables should be changed to reflect
the configuration of your installation.
In the sample M!C guide, the operator is told to run certain tatch
recovery/restart jobs. Figure S-l shovs a table of these jobs, where
they are referenced, and the corresponding sample jobs in
IMSVS. PRIMFJOE.
Operations
B.3
r------------------------------------------------------,
, JCE
, CHABT I SlePt! ,
t!SC~IPTION
,~-~~~~~~~~.-~.~~~-~~.-~~-~----~----~---~--.~-------~-~,
1 EMF Restart
A-1,E-S
SAMP474
, System log ~erminator
H-2
SAMP492
f Log Tape Recovery -- Part 1
H-3
SAMP490
, Leg Tape Recovery -- Part 2
H-3
SAMP491
, Change Accumulation
1-1
SAMP481
I tata Ease Recovery
1-1
SAMP382
I Batch Backout
1-1
SAMP384
L------------------------------------------------------~
fi9ure B-1. Jcts requirin9 Jet modification
These charts should be updated to reflect the actual job names used in
ycur installation, and sbculd include descriptions of any Jct changes
the operator has to make before running them; for example, bow he
specifies the log tape serial number.
We recommend that all these jots be set up and tested before you go into
production mode. This setup would include preparing restart JeL for ~11
BMPs, and data base recevery jebs for !11 online data sets.
~2g_1~~!_Ag!~n!~1~~!!2D
The sample M!C guide assumes that the method of online lcg tape
administration described in ChaFter 6: "Recovery," is used in the
installation. If you use a different scheme, you should modify the
guide accordingly.
Chart J-1 of the sample guide is an index to operating procedures for
applicaticn programs. lou should extend this section to include
operating procedures for all applicatien programs.
TESTING THE M!O GUIIE
Once you have ~repared the eTC guide for your installation, all the
operators who ~ill be ~aster terminal operators should be given an
opportunity to faliliarize themselves with it. After that, all the
Ftccedures in the guide should be thoroughly tested. Even if you use
the sample guide, yeu sheuld catty out the tests, to ensure that the
Frocedures ar~ accurate for your environment, and the operatcrs kncw how
to use them.
These tests shculd be carried out in a controlled fashion. rc
Administration in conjunction with the Operations Department should
prepare a detailed schedule, shewing what tests are to be done, how they
are to be done, and what procedures in the guide they test. The tests
should be designed in such a way that all, the operating procedures are
checked out. All operators should have an op~ortunity to perform all
tests. In crder to test some of the rEcovery procedures, certain types
of system failures tave tc te simulated. Figure 8-2 shows a table of
possible failures, and how they may be simulatEd.
During the tests, the operators should write down which procedures they
USE, any deviations tbEY were fcrced to make frcm the standard
procedures, and any error messages they received that were not
documented. AftEr the tests have been run, a meeting should be held to
8.4
I8S/VS Frimer
discuss the results. Any corrections should be made, and the Frocedures
re-tested if necessary~
After the initial testing ef the guide, the recovery procedures should
be re-tested en a regular basis, say once a month. This is to ensure
that the operators remain familiar with the procedures, and that no
changes need to tE madE.
MAINTAINING THE K!O GOlDE
It is vitally important to the successful running of the online system
that the M!O guide be keFt up to date, and that any errors or oaissions
in it are correctEd.
AftEr the initial tests ha,e been completed, a procedure should be set
up whereby an operator ~ho finds an error can document it to alErt DC
Administration. !he pregrEss cf the errer correction should be followed
up on a regular basis.
As new applications, data bases, or terminals are added to the system,
the configuration tables in the guide sheuld be updated. The procedures
should be re-tested and the guide updated if necessary, after a new
release of IMS/V5 or OS/VS is installed.
r------------------------------------------------------------,
PAIIVEE
EY:
SYS!E~
SI~UIATED
USE MIO command
1. EMF abended or
cancelled in error
ISTOP REGION n ABDUMF
2. CTL region abended or
cancelled in error
USE OS/VS modify or cancel
command
3. MfP abended
Fun TE4CCNEW in test mode*
rEply 'ABEND' to D1S3125A
message
4.
~pp looping er in
wait state
!E4CONEW in test mode*
reply 'LCCF' to tFS3125A
RUD
~Essage
a log tape that has
previously been mutilated
5. I/O error on log tape
USE
6. OS/VS error (loof or
abend)
Unplug/switch off as/iS system
residence drive
Ha~dware error, no
loss of main storage
Unplug/Switch off OS/iS system
residence drive
7.
80 Power failure, or
Fress System Feset, and re-IPL
hardware error with
less of main storage
l------------------------------------------------------------~
*
Transaction TEUCONEW in the samFle system includes a testing
cFtion which can be invoked by entering 'T' in the eNG-FUNe
field. MessagE DFS~12~A will be issued by the MFP. See the
IMS/VS Messages and Codes Feference Manual for more details
on this message and its allcwed replies.
Figure 8-2.
Simulating System Failures.
Operations
8.5
E~!sniDg '2~ !~~Ll~ ~!§~ ~!§~!~!
Once yeu are familiar with the I~S/VS log tape restart operation, you
should consider iaplementin9 IMS/VS disk restart. The reason we did not
include it in our subset is that even with disk restart, proper handling
of log tapes and 109 ta~e restart is essential to a problem-free IMS/VS
operation. the benefit of disk restart is that it reduces significantly
restart time ano operatcr tape handling. For more information on disk
restart, you should refer to the base IMS/VS publications.
If you implement disk restart, you should at least:
•
Update your MlC procedures
•
IncreasE tbe spaCE allccaticn of the disk restart data set IMSY5.B[S
Depending on the number of users of the system, and the organization,
the user liaison group say consist of cnly one Ferson acting as a buffer
bet~een the remote terminal operators and the MTO or it may consist of a
number of people, who resolve most user queries themselves.
People performin9 this function should have a good knowledge of terminal
operating procedures, and a broad overview of all the applicaticns.
They should normally be able te dia9nose a user's problem to the extent
of knewing whether to route the/ query to the MTO, Network Centrol, cr
the appropriatE Applicaticn SUFervisor. In a large installation,
members of this group mi9ht bave their own terminals, and be authorized
to use a subset of the master terminal commands, such as START, SlOP,
£ISPLAY, and ASSIGN.
The success of an online system depends largely on its acceptance by the
users. 70 make it acceptable to these people, you must provide good
training and documentaticn, sc that their interface to the system is as
smcoth as possible. The term "Remote Terminal Operator" or "RTO" is
used to describe users of the online system, who may be ope~atin9 lccal
or remote terminals. ThE wcrd "remote" is used to distinguish them from
the ~aster Terminal Operator.
TRAINING EEM01E
TIE~INAI
CEIEATCES
Generally, an RtO Guide, no latter how ccmprehensive, is not sufficient
tc train Dew terminal operators who may not be familiar with computer
concepts, and, in some cases, may not know the application either. We
recommend that, as terminals are installed in de~artments for the first
time, a training team be sent to provide initial user education.
!his team shculd consist of a person, or persons, who can give an
introductory talk en ccm~utels, who know how to operate the terminals,
and who understand the applications and the transactions that will ce
used in that department. 1his team should remain in close contact with
these users until their initial problems have been overcome.
A training program should also CE set up within the department, so that
new users can te trainEe ty those already familiar with the system.
This training Erogram should be formalized to ensure that the education
is done thorou9hly. It may be possible to set up dummy data base
records on which terminal operators can practise. If this is the case,
8.6
IMS/VS Primer
the procedures for them tc
a training g~ide.
aCCESS
these reccrds sheuld be documented in
THE BTO GUIIE
This document
sho~ld
be supplied to all terminal users.
The manual
entitled ~~~L!~_f'i!!!_E!~~~!_!!~~i~!!_~E~~~!2~!§_§yig~ is a sa.ple of
such a guide. ~he aim of this document is to provide a guide to using
the online I~S/VS s~stE. fer a terminal user who is unfamiliar with
computers. However. it is not intended to be a self-sufficient
education document for such a user, although it could be used as part of
a training Frogram.
MODIFIC11IONS
~o
~HE
SA~~lE
FTC GUIDE
If you wish to use this saD~le guide in your installation, you viII
Frobably need to make some modifications to suit your environment.
l~~~!j9~gl_Ii~1~~
The guidE refers to the function HOser Liaison" as the contact point for
any freblems. If you de not use this title in your organizatien you
should replace the references with the apFropriate name. 1 list of the
names and telephcne numbers of people in the Oser Liais~n group should
be filed with the guidee
Y§~_Q!_i~~_~~~§~t
The guide refers to the fact that a subset of IMS/VS is being used. It
is assumed that the standards we have reccmmended for screen design have
been adopted. If you do not follow these standards, the guide should be
changed accordingly.
If you do not USE convErsatienal transactions in ycur system, you may
wish to delete the references in the sample guide. This includes the
description of conversaticnal transactions in Chapter 1 and the
operating proced~res for conversational processing in Chapter 3.
I!.mln!1_Q~iI~1i~g_f~2~§gy.§§
In Chapter 2 of the salFle R~O guide, the operator is told to ask the
sUFerviscr fer a copy of the IE! manual, ~E!~!~2~~§_gq~g!_~2'_1~H_i~1Q
Int2!!!!i2n_~i!R~!1_~1§!!m§, GA21-2i42.
You may wish tQ select froa
this manual the apprepriate sections for the type of terminal and
keyboard being used, and include them in the guide itself.
!~£~i£~!iQn_~E~~~!ing_!'2~~gy~!~
ChaFter 5 of the guide describes the operating procedures for the sal:Fle
programs. You should extend this section tc include the operating
Frocedures fer the transactions used in your installation. We suggest
that each terminal user be given cnly the procedures for the
transactions that she/he is,autborized to use. If possible, you should
include ~ith the operating procedures samples of the screen layouts.
These can be proouced ty using the copy feature on a remote 3211 screen
Operations
E.1
if you have one in your installation, or by using the output of the MFS
generation.
fIf~1~!_~§E2I!~ng_fI2£§gYI~§
In Chapter 4 of the sample BTC guide, the operator is told to ask the
supervisor for a copy ef the IBM manual, i~~_J~1Q_!Q~_~~_f~Q~!~~
~~~~~!!Ug~!Qn_~gig§£ GA27-27S0, if the operator susp,cts that there is a
hardware problem on the terminal. You may wish to select the
appropriate sections of this manual for the type of terminal in use, and
include them in the guide.
Chapter 4 alse descrites the procedure to be used if the user bas a
problem. GenErally they are told te ask the supervisor to contact the
user liaisen group if they cannot overcome the problem themselves.
Depending on ycur oIganization, you may ~ish to redefine the problem
reporting procedure. However where many users are physically lecated
close to each ether, one peIscn should be designated as the interface to
the user liaisen group. This is to avoid the possibility of all users
of the system trying to contact user liaison simultaneously after a
total system failure.
A supervisor requires additional information that is not in the sample
RTC guide. All superviscrs should be given operating instructions for
any additional equipment, such as datasets or modems. Depending on
their location, and the organization of the company, they may need to
kno~ how to call for IBM Custcmer Engineering support and any other
suppliers invelved in case of hardware errors.
MAIN!AINING !HE B!C GUltE
In order to achieve and maintain an acceptance of the online system by
the users, the R!O Guide must be accurate and up to date. This implies
that any errors in the guide reported by the users should be carEfully
investigated aDO corrected in gll ccpies of the guide. If a new release
of 185/VS is installed, the guide should be thoroughly checked,
especially the secticn en IHS/VS error messages.
V!AM AND IMS/VS CFEEATICN
In our subset we consider the VTAM operation as an integral part of the
IMS/VS cperations. This implies that the M~O is also responsible for
the V~AM cperation. This assumption might not be valid for your cv~
installation. Especially if multiple subsystems are using VTAM, you may
prefer to assign the V!AM operation to the CS/VS system console
operation or tc a s~ecial VTAM operaticn group. In that caSE, you
should adapt this c~aFter and the operating guides to your o~n
environment. In any case, proper communication procedures tetween VTAM
and IMS/VS operations must ce Established.
S.8
IMS/VS Frimer
In this chapter VE viII ~rEsent basic guidelines for the monitoring and
optimizing of leS/VS applications. The optimization we are concerned
about is the performance o~timization, that is, the optimal use of
ccmFuter resources.
This chapter consists cf tvc Farts. Part 1 deals ~ith the optimization
of IMS/VS batch applicatiens.Part 2 covers the optimization of the
cnline I!S/VS system.
There are numerous areas fer optiaization of batch applications using
185/VS. 1he most impo~tant areas are:
•
Data case structurE, that is, data base design optimization.
•
Physical data SEt attritutEs, that is, data set location and
internal storage utili2ation.
•
Data base usage by the application programs, that is, DL/I call
seqUEnCES.
The first part of this chapter briefly addresses the above three areas.
But before dcing so, we ~ill take a closer look at the available tools
for performancE mcnitoriDq.
The ultimate measure of performance is cost. !his includes manpower and
system cost. ie will consider only the system cost. The most important
performance factors for DL/I aFFlications are the number of physical
IIOs and number of DL/I calls per transaction. tL/I provides t~o
facilities to mODitor theSE:
•
The DL/I buffer pool statistics
•
!he DB monitor
In accition, the stancard CS/VS facilities such as SMF, GTF, etc., are
eften very useful.
DL/I maintains statistics cr. the use of its VSl! and OSA~ buffer pools.
!hese statistics can be obtained by your application program via the
STAT call, as is aone ty sutrcutine DFSOAS! in I!SVS.PRlftESRC. This is
normally done at the end of each ttlI application program. Fer mOre
details on tPS01S7 and its use, see "The Stat Call" in Chapter 4~ For a
description of the VSAM and OSA8 buffer Fools, see "DL/I Data Ease
Buffering Facilities" in Chapter 7.
Optimization
9. 1
THE VSAM EOFFES POOl STATISTICS
For each VSAM subpocl. DFSOAST prints 4 lines:
statistics. ihe format of the data is:
3 heading lines and the
S ~ A TIS TIC S
B 0 F FER
H A ti D lEE
ESIZ NEUl RET REA RET REY ISBT ES IS RT KS BlB ALT EGWRT SYN PTS
Illink nnn. nnnnnnn nnnnnnn nnnnnnn nnnnnnn nnnnnnn nnnnnnn nnnnnnn
V5 A M
S 'I A 'I I S '! I C S
FCU!t
EEADS USR WTS NUR WTS
nnnnnnIl nnnIlnnn nnnnllnn nnnnnnn
GE'IS
nnnnnnn
SCHEFR
nnnnnnn
ERRORS
nn/nn
BSIZ
=
the size of the buffers in this sub pool.
In final total, this is the total size of all
NBUF
=
RET REA
=
RET KEY
=
the number of buffers in this subpool.
In final total this is the tctal number of buffers
in all sub pools.
the numter cf retrieve by RBA calls received by the
buffer handler
the numter cf retrieve by key calls received by the
buffer handler
the numl::er cf lcgical records inserted into ESDSs
the number of logical records inserted into KSDSs
the numl::er cf lC9ical records altered in this
subpool
the numter cf times the Background ~rite function was
invoked by the tuffer handler
the numter cf synchrcnizaticn calls received by the
buffer handler
thE numter cf VSAM GE'I calls issued by the
buffer handler
the numl::er cf VSAM SCHBFR calls issued by the
buffer handler
thE numter cf times VSAM found the control interval
requested already in the subpool
the numter of times VSAM read a control interval from
external storage
the numter cf VSAM writes initiated by IMS/VS
the number of VSAM writes initiated in order to make
space in the subpccl
the number of write error tuffers currently in the
sutpocl/the lar9Est number cf write errors in the
subpool during this execution
sUl::~CClE.
ISET ES
ISR'! KS
EFR ALT
=
=
=
EGW BT
=
SYN PTS
=
GETS
SCHEIB
=
=
FOUND
=
BEAtS
=
USR WTS
NUB W'IS
=
ERRORS
=
=
Following are guidelines to the interpretation of the most
fiElds:
i«~ortant
•
Normally. :C~ - 90' of the buffer handler requests (EET FEA + EET
KEY) would be satisfied from the pool (FOUND). This parameter can
be used to initially cptimize the ~col size.
•
The number of 1105 (READS + USR W1S + NOR iiS) should be related to
the number cf t~ansactions processed by the job. An increase in
this during producticn could be a signal for reorganization.
•
EERORS should be zero. If not, insure the data base is recovered.
See Chapter 6, "Data Ease Eecovery."
9.2
IMS/VS Primer
THE OSAM EUfFER POOL S1'11S'lCS
If an
OSA~
CS'~ data base used by the program, tiSOAST will also print the
tuffer pool statisticso
The format of the data is as fcllows:
BLOCK
FOUND
REO IN FOCl
nnnnnnn nnnnnnn
WRITTEN LOGICAL
AS NEW Cll pr.,
nnnnnDD nnnnnnn
BLOCK REQ
FCUND I~ FCCI
BEADS ISSUED
EUIl ALTS
OSAM ~FI1ES
BLOCKS WR~T!EN
NEW BlCCKS
CHAIN WRI1ES
WRITTEN AS NEW
lCGICAI Cll F~T
FURGE REQ.
RELEASE REQ.
RET EY KEY
ISAM G' NXT
ISA~
SE1LS
ERBORS
READS
ISSOEt
~DnnD
BUFF
OSAM
AITS WRITES
DnnnnDn nnnnnnn
PURGE RE1EA SE
BE 1
EY KEY
nnDnnntl nnnnnnn nnnnn
EEC.
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
FEe.
BLOCKS
WRITTEN
nnnnnnn
ISA~
GT NIT
nnnnn
NEW
CHAIN
BLOCKS WBI!ES
nnnnn nnnnn
lSI!!
SETLS
nnnnn
ERRORS
nn/nn
number of block requests received
numter of times the block requested was
fcund in the buffer pool
number of eSAM reads issued
DUlter of buffers altered in the pool
number of CSAM writes issued
numter of blocks written from the pool
number of new blocks created in the pocl
number of chained CSAM writes issued
numter of blocks ~ritten on OSA!! chains
number of logical cylinder formats
nurter cf buffer purge requests
number of buffer release requests
nUlter of ISAM recoIds retrieved by key
number of IS1M get next calls received ty
the tuffer handler
number of ISAM SITLs issued by the tuffer
hanalEr
number of write error buffers currently
in the Fool/the largest Dumber of errors
in the pool during this execution
!2i§: Eecause I5AM is nEver used in our subset, its corresponding
statistics should all te zero.
Following are guidelines tc iDterFreting the most important fields:
•
Normally, 5C~ - 901 of the blcck requests received (EICCR FEe) would
be served frem the pool (FCUND ~N FOOL)~ Also notice that, cn tbe
average, multiple tlcck IEquests are required for a single DL/I
call. This parameter can be used to optimize the buffer pool size
for the job.
•
The number of OSAM reads !READ5 ISSUED) and 05AM WRlTES should be
related to the Dumker of transacticns Frocessed by the job. An
increase in these during production could be a signal "for
reorganizaticn.
•
ERRORS should be zero. If not, insure that the data base is
recovered. See Chapter 6, "Data Base Recovery."
The IMS/VS DB monitor is a tool for collecting performance data to
investigate specific a~plicaticn designs. data base designs, and
rescurce allccations. It consists of a monitor module and a mcnitor
report print program. ihen activated, it analyzes and records the
internal activities of the IHS/VS-DB system. the monitor report print
Optimization
9.3
program is processed offline tc Froduce reports that summarize and
categorize, at various lEvels of detail, the information recorded by the
mcnitcI mcdule.
!he monitor module collects data from IMS/VS control blocks during
cFeration of the batch syste. (with minimum interference to the system)
and records the data either on an independent data set or on the IMS
log. The monitor remains resident in the partition/region, and is
activated and deactivated through the system console.
!he following are reccmmEndaticns for use of the DB monitor:
•
collecting data -- the DB Monitor enables an IMS/VS user to collect
performance data to assist in ana112in9 an existing IP.S/VS batch
system. Eeports produced from profiles of a hatch execution
considered as ncrlal can be us~d as a profile and compared with
IeFoIts pIoduced during a batch execution with unusual performance
characteristics.
•
Tuning system -- the DB Monitor can be used to quantify the effect
of actual changes to data base structures, program ct.aracteristics,
data set place.ent and Fool sizes.
•
Testing a~plication -- in the final testing of new or revised
aFFlications, the tE ~onitor can be useful in validating the
internal operation of the programs and data bases. For example,
assume the prcgrammer thought a specific Dt/I call could be
satisfied with a single I/O retrieval, yet the 01/1 call report
indicated a large data base scan as shown by many IWAITs.
Investigaticn of such items could assist in determining whether a
new or revised application meets the performance objectives. Data
contained in the reports may also assist in defining the resources
required by an applicaticn Frogram.
OSING THE IMS/VS DB MONItOR
The DE monitor formats and records performance-related data during the
execution of the IHS/VS batch system. The DB monitor can be active
during the entire execution cf the IMS/VS batch job or it can be started
and stoFped from the system console. Typically, activating the DB
Monitor for 15 to ~c minutes is sufficient to collect representative
data.
!£!i!!!!2~_~~g_~2n!~Q!
Including the parameter P.CN=Y in the PAEM parameter of the JCt execute
statement in the tatch Erccedure makes the DB monitor active when batch
system execution begins..
(See "The DLIBATCH Procedure" in Chapter 7,
"Installing IMS/VS.")
"DF52216A MONI'IOR AC'IIVE, MODIFY 'IO S'ICP MCNITOE" prints on the system
console whenever the tE monitor is initialized or started. To stop and
restart the DB monitor, the system console operator can, at any time,
enter~
HCDIFY jotname,STCP
(cr F jobname,STOP)
"DF522151 MONITOR INACtIVE, MODIFY TO STAET MONITOR" prints on the
system console ~hen the I~S/VS DB monitor receives and acts upon the
modify command.
To reactivate the DE monitor, the console operator enters:
MCOIFY jobname,STAET
(or F jotname,START)
"OFS2216A KONI10R ACTIVE, ~CDIFY TC 5TCP MONITOR" prints on the console
and indicates that the modify ccmmand was accepted.
i~ ~2~!lQ~_]!1!_E!SQ~~jng
The data produced by the DB Icnitor is reccrded on either the I~5/V5
systeu lcg or on a separate DE .onitor log. The presence or absence of
a tt card named //IM5MON in the batch procedure determines which log is
used. If a //IMSMCN Dt card is included (and does not specify DUMMY),
it specifies a sE~arate DB .cDitcr log on which the DB monitor records
are to be written. If there is no /IIMSMCN DD card (or if the //IMSMCN
OD card specifies DUMMY), the DE monitor records are written on the
IM5/V5 system log.
When a separate IE monitor log is used, the system console operator may
want tc force an end-of-volume when stopping the monitcr from the
console. The modify ccmmand can be used tc accomplish this.
MODIFY jcbname,STOPEOV
(or F jobname,STOPEOV)
If, fcr any reason, the tE monitor log data set specified on the
//IMSMON Dt card cannot be c{ened, the message "DF52217I UNABLE TC CFEN
MONLOG, MONITeR UNAVAIlAElE" is displayed on the system console. The
tatch execution ccntin~es, tut the DB monitcr is inactive.
If I/O errors are encountered on the DB monitor log device, the message
"OFS2219I IIC ERECE eN ~ONITCR lCG, MONITOE TERMINATID" is dis~layed on
the systEm consolE. The tatch executicn ccntinues, but the DB monitor
is inactiveo
Note: When STCFFCV is USEd, Execution of the batch region does not
continue until thE succeeding CS/VS mount message is satisfied.
~QQ!rX_~Q!!~Bg_~II2;§
If the jobname is entered incorrectly when entering the MODIFY command,
an OS mEssage infcrms the C{E4atcr cf the err04. If some other error is
made vhile ente4ing the modify command, the message "DF52218I MONITOR
MODIFY SPECIFICA110N INCORRECT" is displayed on the system console,
follcved by either tFS~215A or DFS2216A (described above).
DB MONITOR
REPOR~
PRINT PROGRAM, OFSUTR30
The DB Mcnitc4 Refort Frint program (DFSUTR30) is an offline utility
that organiZES, formats and {rints performance related data collected by
the [ f Monitor during EXEcutic~ cf a IMS/VS batch job. The reports
~4inted by this F40gram are:
•
Statistics from the VSA! and CSAM Fools
•
Program I/O
•
DL/I Call Summary
•
VSAM Statistics
•
DE Mcnitor Overhead
Optimization
9.5
Note:
7he DlSOtB30 program is dependent upon the data records on the
SEt ~roduced ty thE DE Monitor. Records of various events are
ex~ected in pairs -- a start-event record and an end-event record;
events are not counted and reported unless both are received.
data
Q!~i~!~!Q~_Q~_I~!!§_2§~g_!~_~~!_]~E2!t2
1he following arE eJplanations of key terms used in the .reports tc
descrite activities or sub tasks in the IMS/VS partition/region.
!LAPS!t TIME: 7ime reccrded by the time of day clock, from the start of
the activity or subtask until the end of the activity or suttaskq
IWAlt: A wait for an IIC or another resource which occurred during the
procEssing of a tL/l call.
IWAIT TI~E: Elapsed time, during which an IM5/VS subtask was inactive,
waiting for a resource or the completion of an EVEnt. An exception to
this definition occurs when thE IWAI7 time is related to VSAP. activity~
In this case, the I~AIT time is defined as the elapsed time tetween the
entry to and the exit frcm the VSAM routines. During this VSA~ time, an
llC access and wait mayor may not have occurred.
NO~ IWAl7 (ELAPSED TIME -- IWAlT TIME):
Elapsed time minus all lWAlt
time identifiEd for the suttask or activity. It includes any time spent
by OS/VS, or by any other higher priority tasks running in the systems
when the IMS/V5 region was interrupted and dispatchable, and when the
subtask to which the CPU time refers had been eXEcuting at thE time cf
the interrupt. Note that this may approximate total CPU time if the
IM5/VS-DB region is the high priority task and if no low priority tasks
are causing interrupts.
CPUTIKE:
Actual CPU time used by an application program.
SCHEDULE 70 157 DL/I CAll: Elapsed time accumulated for the follcwing
acticns to occur: the region to gain control after teing scheduled,
plus the program either tc te located in the region by contents
supervision of as/vs, or to be brought in by program load, plus the
program to issue the first DL/I call.
ELAPSED EXECU~lON tIME: Elapsed time from IMS/VS dispatch of the first
DIll call by a program until the IMS/VS termination ef that program.
MAXIMUM tIME:
TOTAL TIKE:
LongEst single time duration noted for an event.
Sum of all the time durations noted for a group of events.
MEAN TIME: Quotient of the tctal time (above) divided by the number of
cccurrences of a certain event.
ISR7 KStS: A count cf the roet segments inserted into a SHISAM data
base or index data tase.
(~his count shculd not be confused with the
ISE~ totals in the tl/1 summary report.)
ISB7 ESDS: The number cf times the insertion of a root or dEpEndent
segment rEquired a new lcgical tecord fot the new segment (SHISAM,
HlDAM). (This count should not be confused with the ISRT totals in the
~L/I call summary report.)
]2!§:
9.6
All the abOVE tises are 9iven in microseconds.
IKS/VS Primer
H~!_!~_~1~£!!~_!h!_~]_~2ni~2I_R!22~~_~tini_it29[!!
Job //SIMP293 in IMSVS.PRIMEJOB shcws the Jel to execute the tE P.onitor
Repcrt Print Program, tFSUTB30~ The ANALYSIS CD statement should
specify DUftMY,DCE=BLKSIZE=eC in our subset.
This job prints the monitor output collected during execution of the
customer order processing program with job //SAftP272.
The output, which is listed in Chapter 3 of thel~~L!~ f~i!~~ ~!!]1~
will te referred tc in the follo~ing discussion of the various
generated reFcrts.
Li~1i~g~,
These summary reForts are fcrmattEd disFlays of the contents of selEcted
statistics of the eSAM buffer pool and VSAM buffer subpool(s) that were
collected for batch activity over the entire run of the DE ~onitor.
The Fccl ending valUES and the difference between starting
values cannot be computed for these summary reports unless
pool ending statistics on thE trace tape. The OSA~ buffer
values are recorded only if the DE monitor is endEd before
batch jot is terlinated.
and ending
there arE
pool ending
the IMS/VS
The following messagE is printEd if the summary reports are not printed:
NO DATA EASE EOFFER DATA 11 END 1I~E ON MCNI1CB lOG TAEE:
•••• DATA BASE EVilER ~CCI CA~CELLED ••••
The VSAM Euffer Sutpocl SUI~ary rEport is nct produced if the VSAM
facility is not invoked through the IMS/VS system definition or if the
ending values are not ~ritten on the trace tape. In either instancE,
the following infcrmaticn mEssage is printed:
NO VSAM EUFflR POOL !RACES ON ~ONI!OR leG TAFE:
••• *VSAM fUlFES FCCI FEFCBT CANCELLEt •• *.
For an example of these statistics, see the sample output (pages 1,2 and
3) cf job /ISAMP~S3 in ChaFter 3 of the !]lL]~ R;i!iI ~!~El~ li~!iag2.
For a descriFtion of these statistics, refer to the previous SEction
"DL/I fuffEr Fool Statistics."
This is a summary report of the total and mEan IWAIT intervals rEccrdEd
for I/O IWAITs causEd ty DL/I calls by the Frogram during the trace~
The data is arranged tJ PCB name, ddname, and module identification of
the ~cdule that liAITed. The data under the column heading "IWAITS"
indicates the nUKber cf times that DL/I calls for the associated PCE
were required to wait for IIC activity to complete. The data set for
which thE I/O tock plaCE is i~dicated by the ddname. Entries under the
heading "Module" are atbreviated identifications for IMS/VS-DE modules.
~he crcss-reference is:
DEE
DLE
VEH
DFSDEf.RO
DFSDDLEO
DPSDVSKO
FCB subtotals and a katch tctal arE provided.
Optimization
9.7
For an example of this report, see the sample output (page 4) of job
//SAMP293, in ChaptEr 3 cf the l~~L!~ Rri!!! ~!~R!! bi§li~g§.
~he
two main effects to te noted from this report are:
•
If the nu_ber of IWAITS Eer transaction increases, it may tE
necessary tc recrganizE the data set in question.
•
If two or more data sets with high activity are on the same disk
drive, there may be a contention problem.
Q~L!_£~!!_~Ym!~~1_~~2Q~~
is a comEact till call summary report for the trace. All OL/I
calls issued ty the prcgram during the trace are arranged as follows:
~his
•
PCB name.
•
Fer each FCE, the call function employed.
•
For each call function, the segment accessed and its level number.
•
For each SEgment, the rEturn cede cttained.
For each line in this reFcrt, the number of OL/I calls recorded, the
IWAITs per call, and both the average and maximum elapsed time and
Not-IWAlt times are given. A batch total of DL/I calls is EIovided at
the End of the rEpcrt.
Fer an example of this report, see the sample (page 5) output of job
IISAMP293 in Chapter 3 of the l~§l!§ R~il!~ ~~!El~ QY~EYI Li~!i»~§. the
column entries, from left to right, are:
•
PCB NAME
the 8-character FCE name.
•
•
CALL FUNC.
the 4-character OLl1 call function.
LEV NO.
1he data base level number reached in this call, or
blank¥
•
•
•
SEGMENt
the 8-character segment name accessed by this call.
STAT CODE
1hE status cede returned by this call.
DL/I CALLS
1he number of calls neted having the unique
combination of the atove five attributes.
•
IWAITS
the
•
•
IWAITS/CALL
Quotient of the above two items.
ELAPSEt TIKE
or Not IWIIT
For an Explanation of these terms, see
"Definition of Terms Used in Reports" earlier in this
chaFtEr.
~omber
of I/O WAITs observed for the calls.
The main effects to be noted from this report are:
•
If the number of IWAITs per CL/I call incrEases, this may signal thE
requirement for data base reorganization.
•
1 relatively high number of IWAI!S per DL/I call may indicate a
small data base CI/blocksize, or buffer pools that are too slall.
•
Unnecessary calls issued by the application program can be traced by
checking the report with the Frogram specifications and detailed
flew ..
•
Calls with very high liA1T ccunts may indicate insufficiently
qualified calls, which result in data base scans.
Frequent IiAI~s with a very long elapsed time may be a result
of excessive paging or frequent de-activations. This should be
discussed with the CS/VS system programmer.
B£l~:
!~!~_~1!li§!i~~_!!E2I~
This report (page 6) Frovides statistics on a per call basis for changes
in up to 13 selected subpool statistics between the start and end of
VSAM activity. ~he statistics reForted are:
RET RBA
Number of retrieves by RBA calls received by the
buffer handler ..
KEY
Numcer cf retrieves by key calls received by the
tuffer bandler.
~E~
1SRT ES
Number of logical records inserted into ESDSs.
ISR1 KS
Number of logical records inserted into KSDSs.
BFR
AL~
Number of logical records altered.
EKG
~'1S
NumtEr. cf times backgrcund write function invoked.
SYN PTS
Numter cf synchrcnization calls recei ved by the
buffer handler ..
GE'IS
Numter cf VSAM GET calls issued by the tuffer
handler.
SCHBFR
Number of VSAM SCHFR calls issued by the buffer
handler ..
lCUND
Numter of tiles VSAM found the control interval
requested vas already in the subpool.
READS
Number of times VSAM read a control interval fro;
external stcrage.
USB
iTS
Numter cf VSAM writes initiated by IMS/VS.
NUB
iTS
Numter of VSAM writes initiated in the subpool.
The report contains a set of the above statistics for each combination
of PCB, call function and ddname detected in the trace. An occurrence
count is printed. Each set cf statistics is a summation of the changes
in all subpocls divided by the number of occurrences. Summary lines
show totals for each PCB, fer each ddname under the PCE. and for the
cOII~lete trace.
~~ ~~~i!2~_Q!~Ih~~g_E~EQI!
report ,page 7) provides the total elapsed time during which the DB
Monitor vas active and thE tctal of the time intervals between entry to
and exit from the DE Monitor module. The report also includes the
~his
Optimization
9.9
number of DE ~cDitcr reccrds that vere written and the average DB
Mcnitor time per entry.
Eecause the data base design optimization should be started before the
physical implementation, the previously discussed tools are not
applicatlEe Instead, we will introduce a simple paper and pencil
technique to evaluate alternate designs. This technique viII
concentrate on the number cf ~hysical I/Cs, and the number and
cOK~lexity of DL/I calls per transaction.
This is because, as stated
before, these two facters are the most important performance factors for
data base processing.
DA~A
BASE lOAt FACTCES FEB TEANSACTICN
For all transactions, data base load factors can be established. A
transaction lead factor reprEsents-the-CPU-pover needed for the
~rccessing of that farticular transaction.
It is a relative factor, not
an absolute one. Its sole role is to provide a Bg~~ !2I fB!f~Ij§2D
tetveen alternative designs.
]Qt!: If morE accuratE pErformance prediction in the design phase is
reguired. then design tools such as DBEBC!OTYPE/VS should be considered.
I~A~§!f!1~n_~2ad_l!S~Sl_~~i!§
The tatle in Figure 9-1 gives basic estimates ef transaction load factor
units for DL/l calls or data base I/O.
,
,
,
,
,1-----------------------------------------------,------------1
,
,
1
1
CC~ECNENT
,
,
A G (J CALL
A GN CALL
A R!PL CALL
A I S E 'I C Al't
A DL! 'I C AtL
BE'! BI EVE CFeN! S! G ~ E NT
INSER~ OF ONE SEGMENT
REPlACE OF CNE SEG!ENT
tELE~i OF ONE SEG!EN!
,
,
,
,
I
1
I
I
I
A
Figure 9-1.
DA~A
BASE IIC
UNITS
,
1. 1
.9!
,
1
.5
,
,
1. 7
,
,
1.8
,
,
.. 5
,
,
2.4
,
,'.6,
I
2. 1
,
,5,
,
,
'transacticn Lead Factor Units
'the following consideraticns
a~fly:
A single IL/l call can incur multifle segment accesses, that is, to
•
fcllo~
•
I
a
t~in
chain.
If HDA~, each access of a synonym on the anchor pcint chain is cne
. segment retrieve.
•
9.10
If HIDAM, the access of the primary index data base should be
counted as one additional segment access.
IMS/VS Frimer
•
For replacE, insert and delete each segment occurrence to be
~rocessed must be counted separately.
~!!!£1~
As an exam~le ve use the logical CUSTOMER OEDERS data base (Figure
2-26). A GU call, for instancE, to the third SE20PABT occurrence for a
given custcmer erder would cost:
Segment accesses:
Ynir.l.§
GU call
Eetrieve
REtrieve
Betrieve
SEgment
Retrieve
of index ~ointer segment
of root segment
of first, second + third CEt!E LIN!
1.1
.5
.5
1.5
of logical parent, FAET segment
subtotal
L2
4. 1
I/Os:
KSDS
KStS
ESDS
ESts
index component
data ccm~one~t
for root segment + dependents
of logical parent
5
5
5
2
subtotal
20
gross total
24. 1
AssumFtions:
1.
!he OBtEE LINE seg.ents are in the same CI as their root.
2.
None of the requested CIs is in the buffer pool. Quite often thE
I/O for the index component is not necessary. Also, for the get
next call, lost retrieves are satisfied from the pool.
Cnce again, it shculd tE reali2Ed that the above method gives only a
rough estimate of the ccst cf a particular call. Its main use is to
evaluate Fossible alternative designs.
DATA BASE DESIGN CHECKlIST
The following checklist giVES an cverview cf the mcst important
considerations/guidelines for data base design optimization. These
considerations/guidelines are oriented to~ards performance. SometiDEs,
they will contradict aFFlicaticn requirements. In such cases, a
com~Icmise must be made based on a cost/function analysis.
•
Use a structure no more complex than necessary.
•
Keep freguently accessed segments near the top and to the left cf
the hierarchy.
•
Avoid widely varying segment sizes for volatile segments in the same
data space.
Optimization
9.11
•
Check the requirement fer any segment type whose relative frequency
under its parent is ene, or whose prefix length is greater than or
equal to its data length.
•
Oversegmentaticn results in many Ot/I calls and longer
reorgani2ation times.
•
Undersegmentation results in less security and less data
independence.
•
Avoid movement cf data from one data base to another.
•
Avoid secendary indExing on highly vela tile source segments.
•
Use secondary indexing fer alternate entry, not sequential
processing.
•
If logical relationshiFs exist, place the real logical cbild so that
the ~hysical path is the mcst active path~ Also consider placing
the real logical child on the longest twin chain.
•
SequEncing of the legical twin chain is expensive on insert and
delete prccessir.g.
•
Avoid long twin chains, particularly logical twin chains.
Eecause OL/I data tases are stered in CS/VS data sets and/or VSA~ data
spaces, the ncrmal performance guidelines for these apply. In addition,
the following consideratiens/guidelines should be observed.
•
Keep segments tc he accessed in the same block as the entry segment.
•
Use HDAM
•
Process HtAM data bases sequentially by inserting the randomizing
routine into a scrt Exit and sorting into a root anchor point
seguence.
•
GN processing at the root level in HIAM proceeds in physical roct
anchor pcint sequence with synonyms maintained in logical key
sequence off their root anchor point.
•
If root key sequencE is required in HtAM, consider a seccndary index
(for limited use) or a randomizing routine which assigns root anchor
pcint addresses in key sequence.
•
!he expected lIes required to access a HDAM root with a general
randomizing module, is tetween 1.1 and 1.2 if the number of roots
per block is 5 or more and the block and the RAP densities are less
than eo,.
•
Dc not specify twin tackward pointers for HDAM roots.
•
Specify P!S=TE or none (~T) for the HIDA! root segment. GN
processing at the rcct level in HIDA" proceeds along the physical
twin chain if ~B has teED specified, or via the index if not. Note
that a GN root ~ith key qualification always proceeds via the index
if the call cannot te satisfied at the current position.
•
Specify!E pointers cn segments to be deleted to improve delete
performance for long twin chains (that is, more than 3 to 5). This
is particularly impcrtant for the logical child segment.
9. 12
~henever
IMS/VS PrimEr
possible.
•
Specify LCL in the logical parent and LTE in the logical child if,
on averagE. there arE lere than 2 logical children per logical
Farent.
•
no not define a sequence field for the virtual logical child, unless
really needed.
•
Check reFort from data base unload to identify long twin chains.
•
For insert activity against a HIDAM data base, specify free space in
the tEte
4
The HIDAM primary index should be reorganized frequently to minimize
I/C and regain space from deleted entries.
•
Leave sufficient free sFace for anticipated inserts prier tc
reorganization.
•
Ht free space within the bleck should be large enough for the
largest segment tYFe.
•
When defining KSDS data sets, select the IMBEt and replicate options
and provide freE sFace fcr insert activity.
•
For initial load select speed option in VSIM define. Specify
IN5EE1=SEC in the IFSVSArF tt * data set for initial load or any
mass insert after initial lcad to maintain KSDS free space.
•
To insure that KSDS index control intervals remain in main storage,
provide a unigue control interval size e1K is a good number) and
provide Enough buffers to hold all index set CIs plus at least one
sequence set eI for each KSDS. Eemember that sequence set and index
set CIs contend fer tuffers in the same shared resource subpool on a
demand basis.
•
VSA~ buffer Fools andler centrol blocks can be page fixed in main
storage by sFEcifying YSAMFIX=(BFR,IOB) in DFSYSAMF data set.
In general, the r.umter and ce8Flexity of DL/I calls determine to a large
extent the performance of a Dill application program. The follewing
considerations/guidelines shculd be observed:
•
Reduce the total number of calls to Dl/I by using path calls and
more fully qualified SSAs.
•
Save data in virtual stcrage rather than reissue calls.
4
Do not issue a get call Frier to ISRT to check for prior existence.
•
Use multiple PCBs when referencing data in two parts of the data
base or data base record.
•
Sort batch transactiens to latch the physical order of the data
baSE.
The means to optimize an lMS/VS cnline system are essentially the same
as discussed for the batch-only system in the first part of this
chapter. The tvo key perfcrmance factors introduced in that part, the
number of DL/l data base calls and the number of physical llCs, retain
Optimi2ation
9.
13
their significance. They a~e ex~anded here to include OL/I message
calls and physical l/Os fer the data communication lines, the message
queues, and other data sets used by the online system~
~he online !~S/VS system contains several tools te monitor its
performance. ~hose used lest often are:
•
The enline buffer pool statistics, which can be requested at regular
time intervals by the master terminal operator (MTO).
•
~he
•
The DC monitor and its DC monitor
log data set statistical analysis utility.
re~ert
print program.
In addition, the standard OS/VS facilities such as
cften very useful.
S~F,
GTF, etc., are
ltl~_Q~1I!~_~YI!~~_i~~~_§!~Il~~1~~
~he online buffer pool statistics provide information on thE usagE ef
the IMS/VS data and centrel blcck buffer ~ools. These statistics are
dis~layed as a result of the lOIS peOL ALL command on the master
terminal. See the M!O Guide fer more details cn how to use this
cemmand. All displayed counts are relative to the last (re)start of the
IMS/VS control regien; all ccunters are reset to zero during restart
~recessing.
In general all counts should be related to the numeer cf
messages or transactiens Frecessed.
Nete:
Performance interpretation, especially ef the number of physical
should not be based on a short session. The number of I/Cs will
be relatively high during the beginning of a session because initially
all needed ccntrol blccks must be read in. It is therefore recommended
that you disregard the first half hour of a session.
lies,
!he following sectiens briefly discuss the statistics for each fcel and
give guidance for their initial interpretation. Figure 9-2 shows the
fermat of these statistics as they appear on the 3270 display screen.
5.14
IMS/VS Primer
HESSAGE QUEUE POOL:
ENQ
95
BFRS/SIZE
DEQ
90
MESSAGE FORMAT POOL:
REQ1
193
I/O
13
DIR
o
RRBA
RKEY
12 VRDS
o
BFALT
6 FOUND
DATA BASE BUFFER POOL: BSIZE
RRBA
NMBUFS
WAIT
55
SIZE 20480
DATA BASE BUFFER POOL: BSIZE
NMBUFS
10/1500
CAN
0
I/O
8
ERR
a
FREE
13184
ERR
0
SPACE 17192
5
WAIT
13
1024
o
NREC
a
20 VWTS
0
SYN PTS
11
ERRORS 00/00
2043
988 RKEY
8 BFALT
45 NREC
20 VRDS
171 FOUND
302 VWTS
12 SYN PTS
13
DISPLAY LINES WAITING
11
ERRORS 00/00
PASSWORD:
all
DATA BASE BUFFER POOL: BSIZE
RRBA
NMBUFS
53248
988 RKEY
8 BFALT
45 NREC
32 VRDS
177 FOUND
322 VWTS
12 SYN PTS
13
11
ERRORS 00/00
DMBP BUFFER POOL:
SIZE
8192
FREE
5936
HIGH
2256
9648
HIGH
10832
7568
HIGH
37440
PSBP BUFFER POOL:
SIZE
20480
FREE
ClOP BUFFER POOL:
SIZE
40960
FREE
MAIN BUFFER POOL:
DISPLAY LINES WAITING
PASSWORD:
pool all
SIZE
12288
FREE
7768
HIGH
4616
12048
HIGH
2632
4096
HIGH
1;;76
4096
HIGH
280
CWAP BUFFER POOL:
SIZE
12288
FREE
PSBW BUFFER POOL:
SIZE
4096
FREE
DBWP BUFFE.R POOL:
SIZE
4096
FREE
*78180/213051*
PASSWORD:
Figure 9-2.
Online Pool Statistics Display Pormat
OptiJlli2~tion
9.15
MESSAGE QUEOE
~OCL
ihe message queue pool statistics provide the numker of messages
received and sent. !he fcllewing parameters are displayed:
~f~~L~!~E:
!he first value is the number of buffers. The second value
is the si2e of a single tuffer, as defined in the IMS/VS system
definition.
Is the numter ef messages enqueued in the input/output message
j!~:
queue.
Is the number of messages dequeued from the message queue after
their processing or tratsttission to their destination.
£~~:
CAN: Is the numter of messages cancelled. A message is cancelled if
rejected as an invalid transacticn or during processing of some
commands. ~his figure is typically very low.
Is the number of I/C waits issued. This figure should be low
«10% of ENC). If not, yeu may want to increase the numter of gueue
tuffers.
~!11:
ILg:
Is the number of physical IIOs against the message gueue data
sets. This figure should be typically less than or equal to the EN,
figure. If higher, you may want to increase the numter of gueue
tuffers.
1.
The number of IIOs includes the IICs needed tc format/restore the
queues during I~S/VS (re) start.
2.
the number of queue tuffers as defined at system definition can be
overridden via the QBDF= ~arameter of the I~S online procedure.
Is the number of I/O errors for the message queue data set. This
shculd be zere. If not, it is recommended to do an emergency restart
with BUILDC or a cold start as soon as possible.
~]£:
MESSAGE
FCEP.A~
~CCI
The following parameters for the MFS buffer pool are displayed:
~l~j:
Is the total size in bytes of the
~FS
buffer pool.
Is the available space in the ~FS buffer pool. This is the SIZE
minus the space needed for the directory index, DeBs, pool control
blocks, and the fetch request elements (iREs). One iRE of 40 bytes is
required to store a MFS feraat block in the pool.
~~A~j:
Is the number of tleck requests frem the pool. Such requests are
lade for MIDs, Mots, DIFs, and DOFs needed by MFS processing.
j]~J:
IL£:
Is the number of physical lIaS to the IMSYS.FORMAT data set. If
more than 50% of BE", you should consider increasing the MFS tuffer
pool size.
Is the number of directory I/O operations. This should be very
low in the salfle system because we vill make the directory index
resident during MFS processing. This is done with the MFS serviCE
utility. See "MiS CentIel Bleck Generatic~" in Chapter 3, "Data
Communication Design," and job IISAMP425, last step, in I~SVS.EEI~EJCE.
~I]:
9.16
IMS/YS
Prime~
JAIl:
set.
Is the number of immediate fetch I/Os for the IKSVS.FORMA! data
If more than 50~ cf i!~1, yeu sheuld:
1.
Check if your MIDs refer to their corresponding MODs (NXT=parameter
in the MSG statement) ~henever possible.
2.
Consider increasing the size of the MIS tuffer pool.
I!!!:
Is the amcunt of free sFace in the Fccl. If this amount is
constantly above, say 2R, in your production system, you may want to
decrease the MIS tuffer pccl size. However, a constant high value may
also indicate too few fREs, which means the available space cannot be
used.
EBB: Is the number of I/O errors for the I!SVS.FCBMAT data set.
shculd be zero. If not, you should restore the MFS library.
This
Note:
Because the IKSVS.fCEr.AT and IMSVS.F!fERAL data sets are standard
partitioned data sets, normal library back-up and restore
procedures can be used. Hcwever, they must be dumped and restored at
the same time. ~~c sample procedures, MFSEACK and MFSRIST, are provided
in IMSVS.PROCLIE.
as/is
Agjg§ling_~!~]Y11§I_f~~1_~f§~lilfg!i2~§
turing IMS/VS system defiliticn, we specified a MFS pool si2e of 18R and
a n~mber of PREs of 40. You can change these values in the IMS/VS
control region prccedure. SEe the IMS procedure in Chapter 7,
"Installing IMS/VS." ~he parameter FRE specifies the number of fetch
reguest elements. The parameter FBF specifies the number of 1K tlccks
in sutpool 0 to te allocated tc the MFS buffer pool.
tATA EASE EUiFER POOLS
Separate statistics are dis Flayed for:
•
The OSAM buffer pool (not shown in Figure 9-2)
•
Each VSAM subFool
•
~he
combined VSAM pool, that is, the total of the VSAM subIccls
SI~~:
Is the total pocl size in bytes for the OSAM buffer pool.
]j~j:
Is the numter of internal DIll requests to the pool.
Is the numtEr of atcve rEguests satisfied from the pool, plus
Dumber of new blccks created.
l]~~:
E~A~:
~~!~:
~~!l~~:
Is the number of CSAr. reads.
Should be zero, because we are not using ISAM.
Is the number of
CSA~
writes.
!~!£:
Should be zero, because we are not using 15AM.
~£!!:
Is the number of
f~BQ:
Is the number of synchronization calls received.
~~BB£:
eSAp.
logical cylinder formats.
Is the number of release ownership requests.
Optimi2ation
9.17
~R~2~~:
Number of permanent errors (that is, blocks suhject to a write
error) now in the pool/total of these since last IMS/VS start-up. 1his
should tE zero. If nct, shut the system down as scon as possible and
recover the affected data base~
BEEA: Is the numtEr cf retrieve by EfA calls (direct retrieves)
received ty tbE tuffer bandler.
]K1X:
~lA1I:
]]!~:
Same as atovE fer rEtriEVE by key.
Is the numbEr cf logical records altered.
Is thE number of lcgical records inserted into
ESDS/~SDS.
SYN PTS: Is the numbEr cf synchronizaticn points that involved this
(subficol.
~~~Yf~:
yg~~:
~~]]~:
y~l~:
~B~£~~:
Is the total number of buffers in this (suh)Fool.
Is the number of VSA! reads.
In the number of requests (EEEA+BKEY) satisfied from the pool.
lotal number of
VSA~
writes.
Same as before.
DMEP EUFFEE POOL
!his pool contains the DP.Es, which are the expanded DB Os of thE data
bases used by the centrel region. DMBs are loaded from the I~SVS.ACELIE
during elL region initialization when defined as resident during IMS/VS
systEm definiticn or duting data base cFen ~rocessing. Data tases are
opened during the processing of the first DL/I call against a FCE which
references the data baseq
~l~j:
Is the size in tytes of the pocl.
f~~~:
Is the available free space in the pool.
HIGH:
Is the maximum amount of space used in the pool sinCE the last
start-up.
C~l-rEgion
!gjY2~!~g_!h!_~~]f_12g!_~i~~
The need to increaSE this pocl can best be interpreted from the tC
Monitor report. See its description later in this chapter. If the HIGH
value in your Froducticn system is constantly 2K or more below the SIZE
value, consider decreasing the tMBP pool size. This pool size is
specifiEd in 1K tlocks Ircunded to the OS/VS page size) in the DME
Farameter of the IMS/VS control region ~rccedure. See the IP.S/VS
~rocedure in Chapter 7, "Installing IMS/VS."
PSBP BUFFEB FeCl
This pool plays the same rolE fer the PSEs as the DMEP pool does for the
DMBs. The same considerations regarding its size apply. However,
because PSBs are typically between 2 and 8K you should te careful in
adjusting the size downwards based on the difference between the SIZE
and HIGH ,alues. For instance, if this difference is 4K, you might
still be swapping twc 6K PSBs.
9.18
IMS/VS Frimer
The size of the PSBs is listed by the ACBGEN utility in message
OFS940I. See the output of job //SAMP420 in Chapter 3 of the 1~2LI~
~!i!~! E!!!~~ !!§!~~g§ manual.
~!~:
!he OC Monitor REGION IWAIT report lists the number of PSB loads. the
corresponding parameter in the IMS/VS control region procedure is PSE.
See the IMS/VS procedure in Chapter 7. "Installing IMS/VS."
ClOP EUFFER FOOL
!his is the communication line buffer pool. The SIZE, fREE, and HIGH
numters have the same leaning as for the tMEP pool. Also, the same
consideraticns r€garding adjusting its size apply. The corresponding
IMS/VS centrol region procedure parameter is TPDP. See the IMS/VS
procedure in Chapter 7, "Installing IMS/VS."
MAIN fUffER POOL
This is the working storage pool. defined as WKA~ in the IMS/VS
procedure. Menitoring and adjusting its size is as previously discussed
for the IMEP.
CWAP fUffER POOL
this peol is used to buffer the SFAs of !f1i!~ conversations.
Monitoring and adjusting its size is as previously discussed for the
DMEP. Its size can be changed via the CWAP parameter in the IMS/VS
precedure.
the system definiticn value of the GENERAL parameter in the
EUFPOOlS statement is used as the default value for both the MAIN and
the CWAP tuffer pool.
~Q!~:
FSEW fUfFER POOL
this pool is used mainly to process segments between the CTI and
dependent regions. Mcnitcring and adjusting its size is as previously
discussed for the tMEP. Its size can be changed via the PSEW parameter
in the IMS procedure.
OB~P
EUFFER FCCI
This pool is used for data tase OPEN/CLOSE processing. Monitoring and
adjusting its si2e is as previously discussed for the DMEP. Its size
can be changed via the DEWt parameter in the IMS procedure.
The IMS/VS Statistical Analysis Utility provides statistical informaticn
about online IMS/VS operaticn. Its information is obtained from the
online IM5/VS log data set. The utility consists of three tasic
modules, IFSISTSC, DFSlSt2C, and DFSIS~30, and two intermediate sort
ste~s.
A sample job stream is listed as jot I/SAMP495 in
IMSVS.PRIM~OE.
the saaple cut~ut is listed in Chapter 3 of the IH~Ll~
j~im~~ ~!~~li 1i§!i~~§ and is oiscussed later in this section.
Optimization
9.19
JCL CONSltERAtlONS
~he following should be observed when using the Jet of //SA~E495.
numbers refer to the JCI statement numbers in the jot listing.
8.
~he
12.
lCGIJ defines the I!S/VS system log.
sets caD tE CCtcateDated if desired.
14.
The space parameter of this data set may need to be increased
if the log data set reflects a large number of transacticns.
32,50.
the estimated r.umber of sort records in the SIZE parameter may
need to te increased, depending cn the number of actual input
log records.
50.
the lINECNT parameter can be used to adjust the numter cf print
linEs per cutEut EagE.
SORt/MERGE
Feint of SOR~.
~rc9ram
The
is used in all three steps with an entry
Multiple voluses and data
FEPORT OU7POT AND INtERPRETAtION
Six types of reports are printed by the statistical analysis utility.
Refer to the cutput cf jct /ISAMP495 as listed in Chapter 3 of the
I~~L!~ R!i!!I ~!!R!! .~§I!ngi when reading the following sections.
~!§§!g!§_gg~y!g_~Y~_!2~_~§~!_jBl_g!§!i~~!~2Bl
1he number of net-yet-sent output messages per logical terminal (if
known) is listed.
~iD§_An~_1!!!j~Al_li!R2'!
This report lists the message traffic received (R) or sent (S) by I~S/VS
for each line, physical terminal, and logical terminal. An hourly
distritution is giVEn.
~!§§!g§§_gy~y!g_~!~_~g~_~!~~_jBl_!f!B§~£!i~D-f~g~l
The number of not-yet-sent output messagES per transacticn code is
listed. A transacticn ccde of IMSSYS is listed if the output vas
generated by IMS/VS itself.
lI~D§!~ti2n_~!~2I!
This report lists the nUlter and distribution of messages per
transacticn codeq
This report lists the response distribution per transaction code. 7wo
response times are measured. 1he first line is the response time from
ccmplete receipt of the input message until the response mEssage to the
terminal is completely received by the terminal. The second line is the
response time from complete receipt of the input message until the
sending of the respcnse lessage to the terminal is started. nl response
means that n~ of the messages had a response time less than er equal to
thE listEd nUlter.
9.20
IftS/VS Frimer
!2!!:
The actual figures of the sample output in Chapter 3 of the
~!!R!! ti§!!gg! should not be used for performance
analysis and prediction. 1his is because the sample output was
collected during a test run under V!/370.
!~~L!~
iii!!!
!EE!i£!li2~_A~~2~n!igg_~!ES~~
This report lists for each program and transaction code the nurtEr of
messagEs and the average flulbEr of DL/I calls pe.r message. The lice or
BC" eolumD li~ts the number of times an application program terminated
abnormally, or rEturned with ether than zerc in register 15.
The two last columns list thE total and average CPO task time of thE
region/Fartition. This includes the majority of the data base call
processing.
~FF
The IMS/VS DC Monitor formats and records Ferformance related data
during the execution of the IMS/VS DB/DC system.
The DC Monitor can be available but inactive and cause no increase in
CPU utilization. Including a DD card, described below, in the procedure
makes the DC Monitor available. ~he Monitor remains inactive, however,
until started from the master terminal by a ITRACE command.
The DC Monitcr reguirEs its cwr. recording data set. Therefore a DD card
(DtNAME=IMSMON) must be inclUded in the IMS procedure to describe and
specify the monitor log data set. If this card is not included, the
Monitor will be unavailatle.
USING THE DC
MONI~OR
It is, in general, not necessary to have the DC monitor active all day.
A useful monitoring technique is to obtain "snapshots" on the KonitoI:
log. Normally one to threE heurs c£ mcnitcring collects sufficient
informaticn for an entry system.
!LQ_E~~2~:
If a permanent lIe error occurs on the tC Monitor lcg data
set, the Moniter stops and the message "DFS2202 UNCORBECTABLE I/O ERROR
eN IMSMON" is disFlayed at the laster terminal. In this situation the
Menitor cannot be restart@d until IMS/VS is restarted, and the DC
Monitor log data set is only clesed when IMS/VS is shut down.
If the problEm that causeo the errer has not been corrected when IMS/VS
is tc be restarted, a different volume and/or unit should be specified.
~!!~~i~g_!ng_~lQRE!ng_!h~_!~_~Qni1Q~
Once the IMS/VS CTL region is started, the tC Monitor can be activated
with the following command frc~ the master terminal:
ITRACE SET ON
To stoF the
/~RACE
MON1~OR
~cnitcr,
SEl
O~f
All
enter:
MCNITeR III
Optimizaticn
9.21
DC MONITOR
REPOR~ PRIN~
PROGRAM, DFSOtR20
The DC Monitor Report Frint program (tF50TR20) is a batch program that
takes the data collEcted ty the DC Monitcr (DP5MNTRO) and prints summary
reports and distrituticn dis~lays of the data. The report formats, and
the nature ef information in the reports are identical or similar te
those printed by DF5UTR;C, the Monitor report program. The values shown
in the report samples are not intended to reflect actual values that are
received ty a user's executicn cf this utility.
The following types of reports produced by DFSUTR20 are of interest to
the first-time user:
•
4
•
System configuraticn (data about as/vs and IM5/VS systems used)
Statistics frcm buffer
trace)
~ools
(data collected at beginning and end of
Region {data on timing, IWAITs, and tLIl calls presented ty regicn)
Regicn Sumlary -Regicn IWAIT
•
Program (data on timing, I~AITs, DI/l calls, scheduling and
degueueing that is presented by an application ~rogram)
Frograms by Region -Program Summary -Program I/O
•
Communication ldata on communication subtask timing, IWAITs,
tEansmitted and received blocKsizes, intersystem traffic and
queueing)
Communication Summary -Line Functions -Communication IWAIT
•
transaction queueing (data cn queue lengths and scheduling
occurrenCES presented by transacticn type)
•
DL/I call summary (statistics on all DL/I calls issued by every
program)
•
Run profile, an over-all
mcnitcr traCE interval
~icture
of IMS/V5
~erformancE
during the DC
For a description of the terms used in the report, SEE "Definition ef
Terms Osed in thE RE~crts" earlier in this chapter.
The reports contain a rich variety of data, much of which can be
intErpretEd only with detailed lMS/VS kncwledge.
!21~:
Therefore, we will cnly discuss those of immediate importance to the
first-time user of our subset.
H2!_!2_~~~£Y!~_~~~_~~_~Qn!tQ~_i§~2~t f~in1_~~Qg~gm
Job I/SAMP4S4 in IMSVS.PRIMEJOB shows the·JeL to execute the tc Monitor
EeEort Print Frogram, tf50TE30Q This job prints the monitor out~ut
collected during the executicn of the IMS/VS CTt region.
The output listed in Chapter 3 of the !~~L!~ ~~!m~~ ~gmE!! l!§!!ng§,
will be referenced in the following discussion of the various gEnErated
reports.
If the tc Monitor does net collect certain ty~es of information usually
found in a ~articular report, that report, or the section ef that report
that would nor.ally contain the information, is not produced. For
9.22
IM5/VS Primer
example, if no checkpoints occur, only the headings for checkpcint are
printed.
The page numbers listed in the heading of the following sections
refer to the page numbers in the sample output of job //SA~P494 in
Chapter 3 of the !§~ll~ j~!!!~ a~!£l! 1isti~g§.
]~!!:
STA~ISTICS
FRC~
EUfl!E
~CCLS
E!POR~
These summar} te~orts are a formatted display of the contents of
selected- items of the liessa9E queue, data base buffer pool, VSA" buffer
~col and message format buffer pool that vere collected at the tEginning
and end of trace. ~bEse rEFcrts are preceded by a system configuration
report (Fage 1), which gives information about 05/V5 and IMS/VS systems
used.
Since the pool ending valUES and the difference between starting and
ending values cannot be computed if no pool ending statistics arE
written on the tracE tapE, this summary is ~roduced only if the ~onitor
is ended before termination of the IMS/VS control region.
In the case where only the ending values of one tuffer pool arE not
written on the trace tape, the cerresponding summary report is not
computed and the following infermation message is printed:
NO QUEUE EUPiER POOL !RACES A! END !IME ON eONITOR leG TAP!
•••• QUEUE "EUfPER FCCI F!FCFT CANCELLED ••••
The VSAft tuffer ~oel summary report and/or the message format tuffer
~eol report will not bE prcduced if the corresponding facility is not
invoked through I~S/VS system definition. In this case, the following
information messa9E is pri~ted:
NO VSAM EUFPER POOl tRACES ON 80NItCR ICG !APE
•••• VSAM EUFFEE PCCI EEFeBT CANCELLED ••••
~~§§!9~_2Y!Y!_~22!~_R!g!_~
7he final number ef this report (CUCTIENT) is the most interesting.
Generally, in an Entry 18S/VS system this number should be less than 1.
If higher than 1.~, you should consider increasing the number of onlinE
queue tuffers via the tBUF ~ara.eter in the IMS control region
~rocedure.
~!1!_1!~s_~Yii!I_J~Y~11S21~~_f!£!i_~~_~ !~g_2
The statistics of thE data tase buffer (sub)~ools and their
interFretation ar~ the same as discussed in the first part of this
chapter for a batch a~~lication.
~!§i~~§_!2.!~!_~Yli§._i921~_f!£J_~
The final number of this rE~ert (QU07IEN7) is the most interesting.
Ideally, in an entry I!S/YS system, this number should tE less than 1.
If higher than 4, yeu ~hould cCDsider increasing the size of the online
MFS peol, via the FBP parameter in the IMS control region procedure.
Optimization
9.23
E!gi2»_~~!!~~l_~!BQ~~~_I~g!_l
Region timing information is printed for every MPP/BMP activE during the
trace. This summary reFctt distinguishes the following activities per
region:
•
•
•
•
•
Idle for intent
•
Checkpoint
•
Region occupancy
Scheduling and termination
Schedule tc first Ot/I call
Elapsed eXEcutien
01./1 call
It should be noted that some of the values shown for region timing
overlap in the timeframe of the trace period. Elapsed time for
scheduling ana terminaticn are included in idle-for-intent time. The
elapsed time for execution includes the elapsed time for OL/I calls. In
general, the trace time Fericd is slightly greater than the sum of
scheduling and termination, schedule to first DL/I call, elapsed
execution time, and idlE-fer-intent time. Differences between this sum
and the trace time can be attributed to transactions active at the
startup and shutdown of the tracing, or idle regions at the start or end
cf a trace.
§£~!gg!ing ~n2 l!~!jD!li~~:
lines under this heading, for each region,
show the number of cccurrences of scheduling and termination in the
region, and both the ela~sed execution time and not IWAIT time
associated ~ith scheduling and termination. The total of all intervals,
the maximum single intEIval, and the aean interval values are shown.
The elapsed tilE duting which the scheduler is internally waiting is not
included in the elaFsed time shown for scheduling and termination.
!his line of the repert dces net include data for a message regien that
was not scheduled tut was executing at the start of the trace.
~A~g~l! !s li!~l ~~LI ~!!1:
!he lines under this subheading show the
elapsed time for the following to occur: the region to gain control
after being scheduled; the program either to be located in the region or
to be brought into the Iegicn; or the program to issue the first tL/I
call requJ.ring dispatching of the 18S/VS Call Analyzer Module.
~his section does not appear for a message region or a batch message
region that was Dot SchEduled during the trace; it does not appear for
cne that ~as scheduled but did not issue a DL/I call following the
scheduling. ~he number cf program loads is one less than the number of
schedulings, if the trace was ended after the scheduling tut before the
first DL/1 call of the last scheduling_
~!!]!!g
!l!£YllQn:
executicns of
execution.
Lines under this subheading give the number of
in each region and the elapsed time for each
~ro9rams
The number of Executions lay be one less than the numker of schedulings
and schedule to first DL/1 calls if the ~rogram that ~as scheduled had
an outstanding DL/I call when the trace was ended.
9.24
1M S/V S Pr iller
lines under this subheading give the total numter of DL/I
calls from each region during the trace, the total, mean and maximum
elapsed execution time inter,als to complete those calls, and the total,
mean and Eaximum non-IWAIT intervals used to complete those calls. The
number of IWAITs per call is cc_puted and displayed for each region
under the heading "IW!/CAllu"
~~L! ~!!A:
19!!
!2~ ln~!~~:
Lines under this subheading give the number of times a
region vas in the idle state bEcause of an intent conflict. An intent
conflict occurs during scheduling when the ~rogram to be scheduled needs
data base resources held by another active program. See the section
"Data Base Processing Intent" in Chapter 3, "Data Communication Design."
Ch!~!I~ill:
~his
trace.
line is
~rcduced
if a checkpoint occurs during the
~he line gives the number of times checkpoint vas dispatched, the total
elapsed time of the cbEck~cints, the mean elapsed time for a checkpoint,
and the maximum of those elapsed times.
line also gives the total non-IWAIT time for the checkpoints, the
average non-lWAI~ time fer a check~cint, and the maximum of those
nen-IWAI~ times.
~he
B!gi2~_~££~i~~~1
Lines under this sub-heading indicate the percentage of time that the
region vas occupied. ~his value is determined frem the formula:
Regicn Occupancy=
scheduling + termination +schedule to 1st 0111 call
____ !_BI2gI!!_!!!E2!~_!_i~1!=!BI=i~l!~! _________ _
trace elapsed time
_~
The value of trace elapsed time is the difference between the time
recorded for the first traced I!S/VS event and the last traced IMS/VS
event.
This report lists the cccurrences and duration of IWAITs for each
dependent region during:
•
Scheduling and terminaticn Frecessing
•
DL/I call processing
•
Checkpoint prccessing
~££Y!~I!~E~:
Lists the number of IWAITs
IQI!L~_~~!B&_~l!!~Y~:
lists the total, mean and laximum elapSEd tile of
IW~I~s.
Lists the cause ef the IiAI!. PSB/D~B defines the FSE/tEt to
be loaded, Dt definES the data set via its DDNA~E ~hich needed an l/C.
If the number of FSE/D!E loads (IWAITs) is high, you might consider
increasing the PSE and DMB Fcol sizes.
!~]~!lQ!:
Defines the module involved in the
for PSBs, DMEs. VBH = VSAM tuffer handler.
~~Y.~:
IWAI~.
QMG
BLB = block loader
manager.
= queue
Optimizaticn
9.25
~his report lists an overviev of the most important factors for each
MEP/EMP activE during the period of monitoring. The time figures are
given in microseconds. The columns and their meaning are:
The number of input message dequeued after their successful
procEssing by the ~rogral.
IE!!~~~~Q:
]1Ll_~j11~:
~he
by the progra~.
Q~L!_~!~~~llE!!:
total numbEr of both message and data base calls issued
Same as atove, but per input message.
!Lg_!~!!l~:
7he number of I/Os required by IMS/VS to process these OL/I
calls. An average telow two is ~referable. Ho~ever, higher values
cccur if the precEssing cf a call involves scans of long physical twin
chains or insert/deletes of segments involved in logical relatienships
and/or secondary indexes.
I~AN_QE2QL~£~:
~he average number of input messages (same transaction
code) processed in one scheduling of a MFP. this number in our subset
is between 1 and 5.
~f~_l!~~L~£~!!:
The average CFU task time for the MPP/BMP region per
schedule. lhis viII te typically very high for EMPs because the full
Frocessing of a BMP censtitutes one scheduling.
~1!R§~~_IIM~L~~~~~:
The average program elapsed executing time per
scheduling. ~his number is largely dependent of the processing
performed by the program, especially its number of DL/I calls and
associatEd I/Os. 1oeally, for a simFle application, it should CE below
500 millisecondsQ
~£~~~~_l~_laI_~~lL§~~~~:
The average elapsed time between the
scheduling of the MFP/E!F and its first tL/1 call. Typically, the lajor
contributing facter in this is Frogram lead time. Typically, this value
shculd be bet,een ~OO and sec milliseconds. Basic steps to improve this
figurE are:
•
Maintain a compact Iccm~ressed) IMSVS.PGMLIE containing only the
MEPs used by the online system.
•
Specify this
region JCL.
•
Use the COBOL options of NORES, NODYNAM and NCENDJCE.
1MSVS.FGP.l~B
as the first step/job litrary in tbE
~pp
~~!~~1~_1~~~l11A!~:
transaction.
Same as EIAFSED TIME/SCHEt, but nov per
If TRAN.tEQ./SCH. is 1, they are the same.
~1L!_~!11_~~!!silL_fsg!§_jj~_~~
This report giVES a sUllary ef the number of OL/1 calls per ESB (that
is, ~roglam), ~er segment returned, and the number of IWAITs for these
calls. For a discussicn refer to the DL/1 Call Summary Report section
of the DB Monitor in the first part of this chapter.
9.26
1M5/VS Primer
~ga f~2'~!~' f!g~ ~~
7his report gives a compact, over-all picture of IM5/VS performancE
during the period of the DC meDitcr trace interval. The headings dnd
ccntents of this Ieport are self-explanatory. Definitions of terms used
are included in tbe discussicn cf previous reports.
This section
optimize the
~his
V~AM
descri~es
VTA~ main
bow tc use the V~Ae storage pool trace to
storage pool in your installation.
trace facility is
de~endent
upon the OS/VS
The V~Ae storage pool trace records the usage of all VTAM storagE pools.
When totb G~F (USB trace epticn) and VTAM storage pool trace are active,
the storage pool trace inferaatien is collected on every 1000th VTAM
request tc obtain a storage pool element.
~he V~AM storage pool trace collects the following infermation fer each
of the VTAM storage peels:
•
Storage pool name
•
!he maximul number of elements allocatEd from
time since tt.e last trace Iecord was written
•
The maximum number of queued requests for buffers at anyone time
since the last trace record vas written
•
Number of currentlY unallccated elements in the pool
•
Date and time, if
!I~E=lES
~he
pool at anyone
vas specified in the GTF START command
OPEEATING THE TFACE
!o be able to activate the VTAM storage pool trace, GTF must be started
first. If you are usiIg cur sample cataloged procedure VTAMGTF as
generated by job IISAMPI~E in IMSVS.PRIMEJCB, you should use the
fcllcwing Erocedureo
e)'ter:
S
responsa:
enter:
V~AMG~F.F1
(This starts GTF)
nn HH1100A
SPECIFY TEACI OPTICNS
nn,~EACE=BNIO,USB
response:
mm
enter:
1m, U
enter:
F
HHL1~5
CP~ICN
OR EEPIY U
PO,!RACE,TYFE=S!S,It=VTAMBUF
This starts the
B2i!:
RESPECIFY 7RACE
V~AM
stcragE
~cel
trace
In the above it is presumed that VTAM runs in PO and GTF in P'.
Optimization
9.27
~!S~E~ng_!h!_l~~~!
enter:
F
PO,NCiEACE,TYEE=S!S,ID=VTAMEUP
enter:
P
V!AMGiF.F1
!~i~!igg
tB!
l~~f~
Job /ISAME496 in
output.
Qy!]y!
I~S'S.EBIMEJCE
can be used to print the VTAM trace
OPTIMIZING VTAM STORAGE POOL PARAMETERS
ViAM has eleven storage poo~s to control the buffering of data. VTAM
dynamically allecates and deallocate~spaoe in these pools fer the VIAM
control blocks, I/O tuffers, and channel programs that control the
transmissicn of this data.
~he basic procedure for tailoring the VTA! stora9E pool valUES is to
initially operate VTAM using the worst-case storage pool values as
described in CS/VS Storage Estimates. Then adjust the storagE pool
values by using the VTAM steragE pool trace facility. To tailor the
VTAM storage tools, determine the following values for each VTAM sterage
pool:
•
bno, the maximum number of elements in the pool
•
bth, a threshold number of elements for a pool
•
bsz, the size ef each element (in bytes) in a pool (specify for
IOED! and PPBO! cnly)
The VTAM storage pocl ISMS) trace records infcrmation on the use and
availability of YTAM's buffer pools. the trace records are written at
regular intervals, after every 1,000 requests for buffers. Each set of
records contains the maximul number ef buffers in use, the maximum
numbex of requests for buffers queued, and the ~urrent number of
availatle tuffers for each ef VT1M's eleven buffer pools. An example of
VTAM storage tool trace output is shown in Figure 9-3.
***
DATE
USRFO FFO
DAY oeo
YEAR 1978
TIHE 20.56.20.407148
VTAH BUFFERS
HAXU HAXQ AVNO
MAXU MAXQ AVNO
MAXU MAXQ AVNO
HAXU HAXQ AVNO
10 0023 0000 0062 PP 0002 0000 002C LP OOOE 0000 0024 WP 0003 0000 0011
TIHE
Figure 9-3.
NP 0007 0000 0025 LF 0008 0000 002A CR 0006 0000 0037 UE 0002 0000 002e
SF 0001 0000 OOlA SP 0000 0000 0005 AP 0005 0000 0028
75380.399270
Sample VTAe Trace Cutput
POClID
IdentifiES which buffEr
~ool
10
Fixed I/O Fool (IOBU!)
FP
PagEable 1/0 peel (PPBOF)
9.28
IMS/VS Frimer
the trace entry is for.
Pool IDs are:
LP
Large pageable pool ILPBOF)
iP
Working set pageatle
NP
Ncnworking set pageatle
LF
large
CR
Copy RPl pool tCRFIEOl)
UE
CECB pool lOECEUl)
SF
Small fixed pool ISFBUl)
SP
Small pageable peol ISPBOr)
AP
ACE
Fi~ed
~col
~ccl
liPBOF)
~ccl
(NPBUF)
pool (llEOl)
(APEU!)
HAXU
Indicates the maximum number of buffers in the pool that were in use
at anyone time in the last interval. A "AXO value of 0, however,
does not mean that all tuffers in the pool were released, tut that
there were no additional Ieguests for buffers during this interval.
HAXe
Indicates the maximum number of requests for buffers that were
queued at anyone time since the last interval.
AVNO
Indicates the average numter of tuffers in the pool that were
availatlE during the intErval.
Eased on a VTAM trace output of several hours of regular production, use
the fellcwing guidelines in adjusting the VTAM storage pool parameters
as specified in jet //SAMPI~4.
For every pool find the following values:
•
•
Average of all HAIUs related to pool
•
Aver age of all AVNOs rElated tc pool
•
Highest MAXU related tc
•
MAXQ
•
AVNC related to highest P.AXU
Average of all HAXes related to pool
~ocl
related to highest MAXO
Decrease bth and bno if:
•
highest MAXO is always at least
'O~
lewer than bth.
Increase bth and tno if:
•
Average and/or highest HAXO value is larger than or equal to bth.
•
Average and/or highest P.AXU value is close to bth and average and/or
highest AVNO is elCSE tc ZEIO.
Optimizaticn
9.29
Notes:
--~~-
1.
The increase sheuld te at least as high as the highest
2.
The relatienshiF between tth ~hresho~ value) and bno ~umbEr of
buffers inpool) is described in g~L!~ §I§1~! ~Igg~~!!iDS 11!~~~I
~AXC
value.
(~!~l: ~~Q~g~! I§!i!~!!~, GC28-0604.
The importance of a goed data base and program design for the
perfermance of an IMS/VS online system is even more apparent than for a
batch system. !he guidelines fer data base design and ~l/I call used by
programs, as given in the first part of this chapter, still fully aFply.
Another important factor of general interest in data communicaticn
design is the transacticn response time.
As discussed in the section "!ransaction Response Time Considerations"
of Chapter 3, "Data Communication Design," the response time consists of
two components:
1.
Network response time.
20
IMS/VS response time.
NETWORK RESPONSE TI"E
FAC~OBS
!he fcllcwing parameters influence the network response time:
•
Length of input data character stream
•
Length of cut put data stream
•
Line mode operation, that is, half or full duplex
•
Line speed and lir.e length
•
Modem turnaround time
•
Number of clusters and number of terminals per cluster
•
Communication controller delay time
•
Number of transacticns Fer terminal, arrival rate, and distributicn
Eased on the atove factcrs, an assessment can be made for the network
response time.
IM5/V5 RESPONSE 7IME FACTCRS
One of the most impcrtant factors which influence the performance of an
cnline I"5/VS system is the ~ff 2i~!i£~ ~im~.
The MPP service tjme is thE elafsed time between scheduling of the
transaction and the completion of its processing by the MPPo
9.30
IM5/V5 Primer
~he
basic components of the
1.
Program loading of thE rtF.
2.
~Etrieval
3.
Data baSE calls ana asscciated l/Os.
4.
AF~licaticn
5.
Insert of output message into the message queue and its associated
physicall/Os lif no frEE queue buffer is available).
6.
CS/VS paging during any ef the above activities.
~Ft
service time are:
of input lessagE and associated physical l/Cs.
~Iogram
processing time.
The twe mcst important components from the above list are usually the
program load time and the data base calls with their associatEd l/Os.
Typically, progral lcaa tilE is bEtween 200 and 500 milliseconds elapsed
time, and a direct llC is between 30 and 50 milliseconds elapsEd timE,
assuming 3330 disk drives.
]QI§: IMS/VS provides fer ~Ielcading of selected application programs
and FL/I modules. ~his preload option is not included in our subset,
but you might consider its use as the next step on improving systems
performance. More infcrlaticn cn the prelcad option is included in
ChaFter 2 of the !~§L!§ In§t~!!!tiQn §~i~~ under the topics "Making
High-Use Program ~odulES FEsident" and "Organizing PL/l Modules for Use
with the PL/I OptimizEr."
We vill nov discuss a very simFle IMS/VS response time estimation, caSEd
solely on MPF service time considerations.
•
Lightly loaded system, that is, ample available CPU time for IMS/VS
activitiES.
•
One MPP region.
•
All MFPs have roughly same service time.
•
MPP is loaded for each transaction; program load time is 300
milliSEconds.
•
Average of 1C DL/l calls with average of 1 I/O per DI/l call of 40
milliseconds average elapsed time.
•
~hE messagE inter-arrival time is 2 seconds (one message every 2
seconds) with an eXFcnEntial distribution.
•
Basic queueing theory is applicable.
Optimization
9.31
Eased on above assumpticns, the follewing parameters can be
deriled/calculated:
MPP Service
~ime:
Arrival Rate:
A
MPf Utilization:
MPP Wait Time:
~S:
= 0.5
0
300+10*40:700 milliseconds.
IEssagEs/second
= 1S*A=C.35
7W = O*lS/(1-0)=380 milliseconds
MPF Besponse lime:
1R = lS+7i=1.C8 seconds
•
The MPP wait tiae is the averagE time a message must wait in the
queue before the !IP region can process it.
•
1he MFP response time is the average interval response time of a
transacticn, that is, tbe time bet~een the enqueue of the input
message in the ~ueue and the enqueue of the output message in the
queue.
1.
The formula for 1W nermaIIy applies enly for utilizations below
(OSO.6).
2.
Many other factors can influence the total IMS/VS response time,
such as:
9.32
•
Loading of DBDs, PSBs and MID/MeDs, DIF/DOFs.
•
Data base open processing (required after DBD (re)lcad).
•
CPO, channel, and disk drive utilizations.
•
tispatching pricrity of CTL and MPP regions.
•
Location of IMS/VS system data sets, noticeably the queue,
fermat, and program litrary data sets.
IMS/VS Primer
60~
~~~:US
DATA BASE CALLS
GU
GN
DLET
GHU GHN REPL
ISRT
ISRT
ILOADI (ADDI
MSG CALLS
SYSTEM CALLS
GN ISRT CHNG
CHKP
GU
XRST
CALL STATUS
DESCR IPT ION
CALL
ERROR 1/0 OR
COMPLETED IN CALL SYST ERROR
SEGMENT 1'0 AREA REOUIRED. NONE SPECIFIED IN CALL
~~-+~4-~+-
__+-~-4~-4__+~~-1~__+-__-1____~------~----+--------+-H-IE-R-A-RC-H-IC_A_L_E_R_RO_R__IN_S_SA_,__________________~
INVALID FUNCTION PARAMETER
CALL REOUIRES SSA, NONE PROVIDED
DATA MANAGEMENT OPEN ERROR
INVALID S5A OU,HIFICATION FORMAT
INVALID FIELD NAME IN CALL
CALL USiNG L T PCB IN BATCH PGM
CALL FUNCTION NOT COMPATIVLE WIPROCESSING
OPTION OR SGMT SENSITIVITY
-t-+__+-__-+-____+-_-+______-4___~.-:..J_X____+I_fO_E_R_R_O_R_OSAM. BSAM. OR VSAM
X
X
MORE THAN 4 CALL PARAMETERS INVALiD FOR DC PCB
USER liO AREA TOO LONG
RESPONSE AL TERNATE PCB REFERENCED BY ISRT CALL
HAS MORE THAN ONE PHYSICAL TERMINAL ASSIGNED FOR
INPUT PURPOSES. NOTIFY MASTER TERMINAL
CALL ATTFMPTED WITH BCHAR LOGICAL TERMINAL
NAME NOT KNOWN TO SYSTEM
CHANGE ATTEMPTED WITH H;VALID PCB
INSERT ATTEMPTED TO A MOD TP PCB WITH NO DESTINATION
SET
FORMAT NAME SPECIFIED ON 2ND OR SUBSEOUENT MSG
ISRT CALL
OUTPUT SEGMENT SIZE LIMIT EXCEEDED ON ISRT CALL
NUMBER OF OUTPUT SEGMENTS INSERTED EXCEEDED THE
LIMIT BY ONE
SEGMENT KEY FIELD HAS BEEN CHANGED
NO PRECEDING SUCCESSFUL GET HOLD CALL
VIOLATED DELETE RULE
CROSSED HIERARCHICAL BOUNDARY INTO HIGHER
LEVEL {RETURNED ON UNOUALIFIED CALLS ONLYI
END O~ DATA SET. LAST SEGMENT REACHED
SEGMENT NOT FOUND
DIFFERENT SEGMENT TYPE AT SAME LEVEL RETURNED
IRETURNED ON UNOUALIFIED CALLS ONLY I
SEGMENT TO INSERT ALREADY EXISTS IN DATA BASE
IX
VIOLATED INSERT RULE
LB
SEGME~IT
LC
KEY FIELD OF SEGMENTS OUT OF SEOUENCE
TO INSERT ALREADY EXISTS IN DATA BASE
LD
NO PARENT FOR THIS SEGMENT HAS BEEN LOADED
LE
SEOUE NCE OF SIBLING SEGMENTS NOT THF SAME AS
DBD SEOUENCE
NE
DL I CALL ISSUED BY INDEX MAINTENANCE CANNOT FIND
SEGMENT
NO
1'0 ERROR OSAM. BSAM OR VSAM
OC
00
NO MORE SEGMENTS FOR THIS MESSAGE
OE
GET NEXT REOUEST BEFORE GET UNIOUE
OF
SEGMENT LESS THAN FIVE CHARACTERS ISEG LENGTH
IS MSG TEXT LENGTH PLUS FOUR CONTROL CHARACTERS I
OH
TERMINAL SYMBOLIC ERROR. OUTPUT DESIGNATION UNKNOWN
TO IMSIVS ILOGICAL TERMINALS OR TRAN CODEI
RX
VIOLATED REPLACE RULE
Xl
LENGTH OF SPA IS INCORRECT (USER MODIFIED FIRST
SIX BYTESI
XC
PGM INSERTED MSG WITH II FLO BITS
SET RESERVED FOR SYSTEM USE
XD
IMS IS TERMINATING FURTHER DLiI CALLS MUST NOT BE
INVALID SPA
~~X~X-+--+--+---+----4---4--+,~I~~---+,----~----~------+---~--------~:~i~~::~G::::~:::TURNED
bb
X
I
Xl
X
X
I
GOOD NO STATUS CODE RETURNED, PROCEED
NOTE' bb Indicated blanks
I~S/VS
Status Codes Quick ReferEnce
1.1
The following listing of IMS/VS status codes and possible causes is
divided intc two Earts. The first part lists the status codes which
are. in general, cause~ by applicaticn Frcgram errors. The second part
lists the status codes which are, in general, caused ~y system errors.
A more detailed discussion of these and other status codes can be
found in ApFendix E of the l~~L!~ AE2!!£~1iQn f~Qq~gm!!nq E~t~;~n£§
B2!~:
~!~~!1·
the fcllowing status codes are the most common ones caused ty
application Fregram errcrs (errer in call) in our subset.
AE:
Segment I/O area is Iequired but was net specified in the call.
AC:
55A(s) contains an error in hierarchical sequence.
Fossitle causes:
AD:
1.
No segment name equal to that specified in 55A found within
sccFe of this PCE.
2.
LevEl at which this 55A aEFears is out ef sequence with that
sFEcified by the PCB.
3.
Twe segments of the same level are specified in the same call.
An invalid function parameter was sUPFlied.
Possible causes:
1~
2.
Invalid function string
A GU or GN vas requested for a terminal FeB other than the
I/C peE.
3.
Invalid rEquest tYFe to a DC-PBe.
4.
A call bas beEn iSSUEd tc the message queues
AH:
No 55A(s) was specified in call.
and none was specified.
AJ:
5SA qualification format vas invalid.
~ith
a tE-FCE.
Call required at least one 55A,
Possible causes:
10
Invalid comland cedes.
2.
Invalid relational oEerators.
3.
Missing right parenthesis of Boolean connector.
IM5/V5 status Codes and Possible Causes
E.l
AK:
4.
DLE'! call has nul tiple 55 As or qualified 55As.
5 ..
REPL call has qualified SS As.
6.
ISB'! call has the last 5SA qualified.
7.
A path insert call into an existing data base involves a
logical child segment.
An invalid field name was supplied in the call.
Possible causes:
1.
Unatle to find thE sFecified field name.
2.
When accessin9 a lcgical child, a field name from the othe
(paired) logical child is used for the destination Farent
concatenated key Fcrtien.
AL:
The call is usin9 a terminal PCB in a DL/1 program.
AM:
Call function not ccmFatible with processing option, segment
sensitivity, or transaction-code definition.
Possitle causes:
1.
Coamand cede D used fer path retrieval call without path
sensitivit'y
2.
Processing opticn cf 1 and call function is not insert
3.
OLE!, REPL, er ISRT call without corresponding segment
sen si ti vi ty
q.
A DIE!, EEFl, or 1SBT call was issued by a program while a
transactien defined as inquiry was being processed.
A GEt call was attempted for a segment with REY sensitivity.
Correct the error by specifying DATA sensitivity.
AT:
5.
!his status ccde cccurs for a checkpoint (not restart) call if
a G~A~/VSAM data set is opened for output.
6.
An invalid request was included in a GSAM call.
7.
Any call to a GSA! dummy data set is invalid.
Errcr in call. The length of the user's I/O area data is greater
than the arEa reserved fer it in the control region. The length
of the area reserved was determined by the Ace utility program,
D1SOACBO, and printed as FaIt of its eutput.
Action:
iI;Ia)
Correct the PSB cr the program (message segment length
in errcr.
AY:
Insert call igncred because the lcgical terminal referenced by the
response alternate PCB currently has more than one physical
terminal assigned to it for input purposes.
E.2
IMS/VS Primer
19112D:
Ask the master terminal operator to determine (use
ItISPLA! ASSIGN!E~T ITEB! X) which physical terminals (2 or .ore)
refer to this logical terminal. Use the /ASSIGN command to
correct the problem.
11:
7he CHNG call ~as attempted with an eight-character logical
terminal name which .as uDkncwD to the system.
!£li~~:
Correct program.
A2:
The CENG call was attempted with an invalid PCE. It was either
net an alternatE PCB, was not defined as modifiable, or had a
message in EIocess but incomplete.
13:
An INSERT call ~as attempted to a modifiable alternate PCE which
had no destination set.
j~1i2g:
ISSUE a CENG call tc set the PCE destination, and reissue
the INSEF'I call.
AS
An invalid call list was supplied. A fourth parameter (KOD name)
was suppliEd, tut thE function was not ISR'I for the first segment
cf an cutput message.
!£~iQn:
A6:
Insert call ignored because output segment exceeded specified
limit.
!S!i~:
A7:
Correct thE ISRT call and retry the application Frogram.
Ccrrect the application program.
Insert call ignered because number of output message segments
inserted excEEded SFECifiEd limit by one. If another attempt is
made to insert too many segments before the program issued another
GU, the program is atended.
!~ii~B:
Correct the application program.
tA:
A segment sequence field bas been changed; no action in data base.
DJ:
No previous successful get hold call; no action in data tase.
DX:
Violated delete rule: tried to delete across a logical
relationshiE. Check ROLES = parameter on DBD.
Gl:
Call is completed.
IJll!M!!i2D: Crossed hierarchical boundary into higher level.
This status code is returned on unqualified calls only.
A~!1~n:
User determined.
I~S/VS
Status Codes and possitle Causes
B.3
GB:
Call is not
comple~ed.
~!E!!n!~!Qn:
reached.
AS1i~D:
GE:
This is the end of the data set; last segment is
If GSA!, the data set will have been closed.
User determined.
Call is not ccmFIEted.
~~Bl!~!!i~~:
A£1!2n:
GK:
Seglent bas not been found.
User deterliDed.
Call is completed.
~'ElsD~!i2R:
Different segment type at same level returned.
status code is returned on unqualified calls only.
A£!i~~:
II:
This
User determined.
Call is net ccmpleted.
!~El!D~!lg~:
!he segment that the user tried to insert already
exists iB the data base.
Possible causes:
1.
Segment with equal Fhysical
for parent.
2.
Segment with equal logical twin sequence already exists for
parent.
3.
Logical parent has logical child pointer, logical child dces
not ha¥e logical twin pointer, and segment being inserted is
second logical child for logical parent.
4.
Segment type dces not have physical twin forward pcinter, and
segment being inserted is second segment of this type for
parent or is second HtAM root for one anchor pOint.
5.
!he segment teiDg inserted is in an inverted structure; that
is, the iamediatE Earent of this segment in the logical
str~cture is actually its physical child in the physical
structure.
!£!i~~:
IX:
t~in
sequence field already exists
User determined.
Violated insert rule.
Possitle causes:
E.4
1.
Insert of logical child and logical or physical parent does
not exist, or wrong rECK.
2.
Insert of lcgical cr Fhysical Earent via its logical path.
3.
ISR! rEquest after Frevious Open, Clese or I/C error status
code.
IMS/VS Primer
4.
A GSAM ISF! call was issued after a previous AI or Ae status
code vas returned.
A~~iQn:
LB:
Ccrrect
~rc9Iam.
Call is not completed.
~!E!!D~~!2n:
The segment user tried to load already exists in tbe
data tase.
fossitle causes are:
1.
A segment with an equal physical-twin-seguence field already
exists for the parentQ
2Q
A segment ty~e dces Dot have a physical-twin-forward pcint€r
(PTR=N1 in SIGM statement in DBD) and the segment being
inserted is either the second segment of this segment type fer
the parEnt cr the seccnd HDAM roct for cne anchor point.
3.
An application program inserted a key of X'FF' •• FF' into a
SHISA~ or HIIA~ data base.
A~~!Q~:
LC:
User determitEd.
Call is net completed.
~!E!!~!~!Qn:
!~!iQn:
LO:
Key field of segments is out of sequence.
Check and correct.
Call is not completed.
No parent has heen loaded for this segment.
~!~l~D~~!Qn:
!~!!Qn:
LE:
Check and correct.
Call is not completed.
~!El~n!~!2n:
seque~ee iD
A~!iQn:
~~:
Sequence of sibling sEgments is not the same as the
the tED.
Cbeck
a~d
ccrrect.
Call is not completed.
Index maintenance issued a DL/l call, and the
segment bas not teen fcu~d.
~!il~n!!i2D:
j~1i2D:
QC:
User deterliDeo.
1here are no more input messages.
successful.
A£5i~D:
If CHKP call, call was
The program should terminate.
IMS/VS Status Codes and Possible Causes
B.5
QD:
~here
are no more segments for this message.
!£!!2S:
QE:
A GET NEXt call vas issued before a GET UNIQUE.
!£!!gn:
QF:
Check
ITEE~
Correct
L~BR",
is unknown to IMS/VS.
name specification in PCB or CHNG call.
Review the RULES= parameter in the tEDs.
program/DED~
Invalid SEA (user modified the first six bytes).
A£!!2n:
17:
cOlrec~
Violated replace rule.
!S!!2n:
13:
Check ano
The eutput designation, the
!£l!Qn:
RX:
Check and correcto
Length of segment is less than five characters. Allowable segment
length is length of message text plus four control characters.)
!~1iQn:
QH:
As appropriate.
Correct the program.
The length of the SPA is incorrect (user-modified first six
bytes).
j~1iQn:
XC:
~ro94am.
Program has inserted a message which has some Zl field bits set
which are reserved for IMS/VS use.
Action:
bits:XD:
Correct the
Correct the pregram to prevent it from setting those
IMS/VS is terminating by a CHECKPOINT FREEZE or DUMPQ.
This code
is returned only frcm a CHKP call issued by a batch-message
application program. The checkpoint itself was successful.
Any subsequent 01/1 call will result in an atend.
EMP should terminatE.
A£~!2n:
The fcllowing status codes represent the most common errors in our
sutset:
~I:
I/O, system, er user Errer
~l~lsD!!iQn:
E.6
IMS/VS Primer
Data management open error.
!he
Possible causes:
1.
Error in DD cards.
2.
The data set was cpEDed for something other than load mode,
but it is not loaded.
3.
Buffer too small to hold record read at opEn time.
Chapter 7 tCI air.iluK but fer ~ocl size.
4.
DD cards for logically related data bases not supplied.
s.
For an CSA~ data set, the DSCEG field of the
or JFCE does nct specify FS or DAo
6.
For an old O~A~ data set, the BOFI or BLKSIZE field in the
DSCE is zero.
7a
~he data set is being opened for load, and the procEssing
option for cnE o[ lere segments iD other than L or LS.
8.
The allocation of the OSAM data set is invalid: allocation is
Frobably ",,1) rather than (', 1), and this caUSES tke DSO~G
OSA~
See
DCB, DSCB,
to bE PO.
9.
Processing options is L, the OSA~ data set is old, and the
DSCE lFECl and/or El~SIZE does not match the tED LRECL and/or
ELKSIZ E.
10. Incorrect or missir.g informaticn Frevented computation of
blccksize or the determination of the logical record IEngth~
" . A catalo9 was not available for accessing a VSle data tasE
that was rEquEsted.
12. OS/VS could not perform an OFEN, but the I/O request is valid.
Information is either missing, or data definition infermation
is inccrrect.
!£li2D:
Check DD cards; ensure ddname is name specified on
DATASET card of IBD. Segment name area in PCB has ddname of data
set which could not be opened.
AO:
ihere is a physical I/C error. When issued from GSA!, this status
COdE means that the error cccurred when:
1.
A data set vas accessed, or
2Q
~he CLCSE StNAt routine was entered.
The error occurred ~hen
the last tleck er reccrds vas written prior to closing of the
data set.
Action:
output,
NO:
tetermine whether the error eccurred during input or
and corrEct the ~rcblem. Recever the data set.
IIC error
There was a BSA!, VSAM, or OSAM physical I/O error
daring a tIll call iSSUEd by indexing maintenance.
~!E!!g!!i2n:
j~~iQD:
Check and CCIIect (recover data base).
I~S/VS
Status Codes and Possible Causes
E.7
II
After initializaticn, the XI status code indicates an IMS/VS
errcr--Frobably GSAM.
An XX status code fro. initialization itself (prior tc the first
DL/I call) may be either a system, IftS/YS, or user error.
1121!n!~!Qn:
WbED thE XX status code is issued from
initialization, the cause may be:
•
•
•
•
•
InsufficiEnt stcragE
Invalid DED
Invalid tlocksizE
Inyalid option
GSA~ error
Any subsEquent GSAM call viII result in an abend.
applicaticn should terminate.
jS1i2~:
s.e
IMS/VS trimEr
The
abend formatting routine, link-edit 7.78
abnormal termination, recovery
aft er 3. 1 4, 6.2 " 6. 28
absence of segment types 2.6, 4.14
ACB (~~~ application control blocks)
ACB library, definition and
us e 0 f
3. 5 2 , 7 • 4 1
ACB maintenance utility program 3.52
ACBGEN
de sc r i pt ion 3 .5 2
procedur e 7.67
access authorization, data 1.14, 1.15
access methods
IMS/VS
GSA M 2.16
HDAM 2.11
HIDAM 2."
as AM 2. 10
overview 2.3
SHISAM 2.15
OS/VS
STAM 1.24
VSAM 1.6, 2.10
VTAr11.26
access paths
hierarchical data structure, in 1.9
logical relationships, with 1.10, 2.19
relationship to sequence
fields 1.9
secondary indexes, with 1.12, 2.26
access to data, limiting 1.14, 1.15
accessing multiple data bases in
one program 4.2
adding type 2 SVC routine 7.3, 7.8, 7.37
admin istr at ion
data base 1. 17
data communication '.34
image copies 6.23
log tapes 6.23, 6.3'
MFS 1.34
algorithms
message sc hed uli ng 3. 8
randomizing 2. 11, 7. 103
allocating and cataloging IMS/VS
d a t a set s
7 • 4 , 7 • 9, 7.4 1
alternate PCB, data'communication
defining 3.50
description 3.12, 3.14
anchor point area, HDAM data base 2."
A NS COBOL (§~§ CO BOL)
APPLCTN macro statement, IMS/VS system
de f i ni ti 0 n 7. 25
application control blocks IACBs)
creation and maintenance 3.52
proced ure 7.67
Application Control Block Generation
( ACBGEN)
description 3.52
procedur e 7.67
ipplication control block maintenance
utility 3.52
!l pplication data structure
concept 1.6
design process, use in 2.74
relationship to physical
data structure 2.77
application program
ba t:::h mess age
processing 1.34, 3.10, 4.47
ba tch processing 1.16
cbeckpoint/restart, use of 4.41
coding conventions
Assembl er 4. 31
COBOL 4. 32
PL/I 4.34
coding DL/I calls in 4.7
conversational 4.68
design for batch 4.2
design for online 3.56, 4.47
GSAM, use of 4.25, 4.45
IMS/VS interface 4.2, 4.47
interactive 3.54
loading data bases, for 4.26
message format service, use of 4.55
message processing 4.46
recovery after abend 6.21
termination 4.11
application program, batch
de sign con si der ations
Assembler considerations 4.31
checkpoint/restart
4.4'
COBOL considerations 4.32
COpy or INCLUDE, use of 2.69
DL/1 calls 4.. 7
DL/I statistics, obtaining 4.25
GSAM, using 4.25, 4.45
perfor~ance considerations
9.32
PL/I considerations 4.34
status code error routine 4.30
application program, online
design considerations
batch message processing program
(BMP), use of 4.47
conversational processing 4.68
input calls, message 4.58
input/output interface 4.48
message processing program
(Mpp) 4.58
message format service,
use of 3.59
output calls, message 4.53
output to alternate
destinations 4.54
environment, IMS/VS 4.47
message segment
description 4.51
format 4.55
Index
I.1
restart, program
3.15
testing, MPP 4.70
application programs, sample
batch
assembler load program 4.27
COBOL
checkpoint/restart,
using
4.45
logica 1 rela tionshi ps,
using
4.39
retrieve only 4.32
secondary indexe s,
using
4.41
PL/I
checkpoint/restart,
using
4.45
logical relationships,
using
4. 39
retrieve only 4.34
secondary indexes,
using
4. 41
error routine, status code 4.30
online
COBOL
checkpoint/restart
BMP' 4. 3 8, 1. 55
conversational MPP 4.70
inquiry MPP 4.60
retrieve only BMP 7.55
PL/I·
checkpoint/restart
B MP
4. 45 , 7. 55
conversational MPP 4.70
inquiry MPP 4.62
retrieve only BMP 7.55
randomizing routine, simple
linear 7.59
statistics print routine 4.25
assellbler language, conventions and use of
batch program structure
call formats (§!! individual calls)
guidelines 4. 31
IMS/VS interface 4~2
online program structure
call formats (see individual calls)
conversational-MPP 4.68
IMS/VS interface
4.47
inquiry MPP 4.58
attribute modification,
dynamic 4.57
attribute data
input message fields
ATTR= operand 3.35
description
3.25
output device fields
ATTR= operand (OFLO) 3.42
ATTR= operand (MFLO)
3.35
description 3~28
cursor position, use for 4.57
ATTR= operand
DFLD statement 3.42
MFLD statement 3.35
automatic page deletion 3.28
1.2
IKS/VS Primer
backout utility (~!! data base backout
utility)
backup, MFS library 3.49
backward pointers, use of 2.14
batch checkpoint/restart, DB/DC
system
batch message programs,
how to use with 4.41
overview 1.31
ba tch checkpoint/restart, DB
system
backout utility 6.14
batch programs,
how to use with 4.41
CHKP/XRST call, use of 4.41
description 4.41
generalized sequential access
method (G SAM), wi th 4.45
operating procedures 7.55, 8.5
overview 1.31
batch data base system
descr ipt ion 1.5
installation 7.4
sample execution 7.48
subset overview 1358
batch message processing program (BMP)
backout 3.12
checkpoint/restart, use of 3.15, 4.41
IMSBATCH procedure 1.14
overview 1.34, 3~ 10
scheduling 3.10
batch processing
backout 6.14
checkpoint/restart, use of 4.41
DLIBATCH procedure 1.68
overview 1.16
system flow 1. 16
BMP (i!! batch message program)
buffer pools, IMS/VS
data base
description 7.59
performan:e considerations 9.12
specification of 7.61
statistics 9.1, 9.1
online
description 1.23, 1.59
performance considerations 9. 14
specification of 7.23, 7.61
sta tistics 9. 14
buffer services, IMS/VS OL/I,
control statements for
OSA! buffer pool 7.62
VSAM buffer pool 1.61
BUPPOOLS macro statement, 1!S/VS system
definition 7.23
calls, OL/1 batch
checkpoint (CHKP)
4.44
comma nd codes, ulrecl 4.21
data base positioning
after 4.23
definition 1.14
delete tDLET) call 4.19
description, general 4.7
forward movement 4.13, 4. 15
function code 4.8
get calls
get next (G N) ". 15
get unique (GU) 4. 14
hoI d form s 4 • 18
insert calls (ISRT) 4.20
overview 2.9
qualified 4.16
replace (R EPt) 4.18
restart (IRST), e~tended 4.81
segment search argument (SSA)
characteristics of 4.1'
command codes for 4. 11
concept and function 4.9
qualification of 4.10
struc ture 4.9
calls, Dt/I online
change destination (CHNG)
4.54
message insert (ISRT) 4.53
message retr ieve (GU, GN)
4.52
scratch pad area (SPA) insert 4.66
scratch pad area (SPA) retrieve 4.66
calls, IMS/VS system service
chec kpoint (CH KP) 4.41
restart (IRST) 4.42
statistics (STAT)
4.25
cataloged procedures {§~~ IMS/VS
cataloged procedures)
change accumulation utility (~~~ data
base change accumulation util~ty)
chained control block linkage, MFS 3.20
chaining MIDs and MODs 3.20
N XT== 0 pe ra nd s
3 • 3 2, 3. 3 3
checkpoint call (§~Sl CHKP call)
checkpoint/restart
batch 4.41
description 3.15 , 4.41
extended 4.41
frequency of checkpoint 4.41
GSAM, with 4.45
introd uc tion
batch 1.15
online 1.31
online 3.15, 4.47
use of 4.41
CHKP call (data base) 4.44
CHNG call (data communication) 4.54
clear key, 3270, impact of 3.41
COBOL, conventions and use of
batch program structure
call formats (§~~ individual calls)
guidelines 4.32
IMS/VS interf ace 4.4- 4.11
online program structure
call formats (§!! individual calls)
qonversational MPP 4.68
guidelines 4.60,4.68
IMS/VS interface 4.50
inquiry MPP ~.60
COHM macro statement, IMS/VS system
defini tion
BTAM, when using 7.31
VTAM, when using 7.27
command language, IMS/VS terminal 1.29
command s, I MS/VS
description (§!i IMS/VS Primer
Master Terminal Operator's Guide)
protection against
una uthori zed us e 7.65
subset, Primer 1.38
:: ommunica tion s network
defining, IMS/VS 7.27, 7.31
defining, NCP/VS 7.38
defining, VTAM
7.38
introduction 1.24
Primer sample 7.44
compilation statements, MFS 3.44
concatenated keys 2.8
concatenated segments, logical
relationship 2.19, 2.24
configurations, sample network 7.44
contention for resources, message
scheduling effects of 3.9, 3.12
control block pools
definition 7.23
optimization 9.14
control blocks, HFS
(§~~ !l§2 DIF, DOF, MID, a nd MOD)
compilation 3.34
crea ti on 3. 34
linkages 3. 20
relationships between 3.20
summary 3.18
control region, IHS/VS
description 3.4
system flow 1.32
structure 3.4
con trol structure, DB s yst em 1. 16
conventions, naming 1. 18
conversational processing
defini tion 1.29
description 3. 14
design considerations 3.51, 3.63
interactive processing,
relation to, use for 3.56, 3.61
program structure for 4.64
scratch pad areas (SPAs),
use of 4.64
scratch pad area layout
4.65
system definition of 7.23, 7.26
termination, how 4.61
converting from batch to online 7.18
copy function, 3270 3.18, 7.30, 1.35
corequisite publications p.S
count parameter (DO statement)
DFtDs 3.41
MFtDs 3.34
crossing a logical relationship 2.21
CTtUNIT macro statement, IMS/VS system
defini tion 7.32
cursor attribute
CURSOR= operand (DPAGE st at ement) 3.41
cursor positioning
default 3.41
program, by 4.57
Index
1.3
data base (§~ ~!§2 data base design)
concepts 1.6-1.13
content
fields 2.7
pointers 2.14
segments 2.7
records 2.6
free space 2. 13, 2.33
anchor points 2~11, 2.31
defining 2.29
GSAM, using 2. 16
HOAM, using 2.11
HIDA" ,using 2.17
index, primary 2.17
index, secondary 2.25
introduction 1.1
logical (~! logical data base)
organization types 2.5
physical (§§! physical data base)
position after a call 4.23
sequence fields and access paths 1.9
simple HISAM. (SHISAM)
2.15
space allocation for 2.83-2.85
data base access methods
introduction 2.5, 2.10
performance considerations 2.80. 9.30
when used 2.78
data base administration 1.17
data base backout utility
(DFSBBOOO) 6.14
data base buffering
defining pool sizes 7.61
overview 7.61
data base change accumulation utility
(DFSUCUMO) 6.9
data base description block (DBO)
purpose of 1.14
requirements, definition of 2.29
Data Base Description Generation (DBDGEN)
definition of 1.14
execution of 2.29
procedure used for 7.68
data base design
checklist 9. 11
concepts and methodology 2.62
intermediate data base, of 3.64
introduction to 2.64
online considerations 3.63
optimization 9.12
performance checklist 9.11
structure rules
basic 1.7
logical relationship, with 1. 10
secondary indexing. with 1.12
structure changes. rules for 5.27
transaction/data element
matrix, use of 2.67
tuning 9.12
data base dump (see data base image
copy)
--data base image copy 6.2, 6.7
data base image copy utility
(DFSUDMPO)
6.7
data base input/output interface
(§!~ Data Language/I
(OL/I»
I.4
IMS/VS Primer
data base integrity 1.15. 1.30
data base load, initial
ba sic data b!. se 4. 26
logical related data bases 4.38, 5.23
secondary index data base 4.41, 5.25
data base logic!. 1 rela tionships
concepts 1.10
description 2.17
defining 2.43
data base logical relationship resolution
utility programs
initially loading a data base
containing logical
relationships 5.23
overview 5.13
pref ix reso lu ti on utili ty
tOFSU RG 10)
5. 15
prefix update utility
(DFSURGPO) 5.19
prereorganiz!.tion utility
(DFSU RPRO)
5. 13
reorganizing a data base containing
logical relationships
5.26
secondary ind.exes,
building 4.41,5.25,5.27
data base logging capability 1. 15, 1.30
(§!! !1§2 log, IMS/VS system)
data base monitor (§~~ DB Monitor)
data base organization, types of 2.5
data base prefix resolution utility
(OFSURG10)
5.15
data base prefix update utility
(OFSURGPO) 5.19
data base prereorganization utility
(OFSU RPRO) 5.13
data base processing intent, message
sched uling
conflicts, how resolved 3.12
scheduling, impact upon 3. 10
data base record 1.6, 2.6
data base recovery
basic 6.2
full OL/I 6.4
introduction 6.1
log tape. IMS/VS, significance 6.5
procedures for 6.20
data base recovery utility
(DFSU ROBO) 6.12
data base reorganization
flowchart 5.24
introduction 5.1
performance considerations 5.25
structural changes, making 5.27
symptoms for 5.22
utilities for
5.3
data base reorganization/load
processing
(~~§ data base reorganization)
data base secondary indexing
concept 1. 12
defining 2.50
description 2.25
data base structure rules
basic 1.7
logica 1 relationships 1.'0
secondary indexing 1. 12
data base system
access met hods 2.5
application program,
relation to 1.16, 4.'
con~rol sequence flow
1.16
facilities provide with 1.5
performance, monitoring 9.1
GSAM 2.16
HDAM 2.11
HIDAM 2. 11
installation of 7.10,7.138
logging 6.5
monitor, DE
9.3
operating environment, batch
scheduling 1. 16
OS/VS considerations 7.2, 7.78
OS AM 2.10
planning for installation 1.21
STAE/ESTAE, use of 6.5
system definition, IMS/VS 7.5
utility programs 1. 15
data base system flow
1. 16
data base/data communications (DB/DC)
system
introduction 1.26
facilities 3.6
relationship to DE system 3.6
system flow 1.32
dat a commun ication
ba sic concepts 1. 24
features, IMS/VS 1.26
system flow, IMS/VS 1.32
system network architecture,
basic concepts 1.24
data communication macro statements,
IMS/VS system definition
ETAM macro set
COMM 7.31
CTLUNIT 7.32
LINE 7.32
LI NEG RP
7.31
NAM E 7.35
TERMINAL
7.33
VTAM macro set
COMM 7.27
NAM E 7.30
T ERMI NA1 7.29
TYPE 7.28
data independence 1.6
Da ta La ng ua ge/I (DL/1)
call requests, functions performed
input/output class
data ba se 4 • 7
message 4.52
language interface 1. 14
dat a, limiting acc ess to 1.'4
data manipulation language 1.14
data security
bat ch 1.15
online 1. 29
extended 1.29
data sets, IMS/VS, allocating and
catalogging 7.9. 1.41
data spaces, defining VSAM, for
da ta bases 2. 8S
data structure, application 1.6, 2.74
aa ta structur es, IMS/VS '.7, 2.77
aa ta structure, changing the 5.27
data structure, secondary indexes 1.12
DATABASE macro statement, IMS/VS
system definition 7.24
DATASET statement
ba sic da ta base, for 2. 33
GSA! data base, for 2.42
logical data base, for 2.48
secondary index data base, for 2.54
DB moni tor
description 9.3
output interpretation and
sam ple 9. 7
report print program
(DFSUTR 30)
9.5
DB PCB
defining a 2.57
de scriptio n 1.14
prog rams view of 4.5
DBA (2!~ data base administration)
DBD (§!~ data base description block)
DED sta tement
basic data base, for 2.31
GSAM data base, for 2.42
logical data base, for 2.41
secondary index data base, for 2.54
DBDGEN statement 2.39, 2.42
(~~~ !l~Q data base description
genera.tion)
DC monitor
de sc ri ption 9.21
output interpretation and
sample 9.23
report print program
(DFSUTR 20)
9.22
DC PCB
defining a 3.49
de sc ri pti 0 n 3. 1 1
program view of 4.49
aefault attributes, MFS 3.35
defining IMS/VS batch system 1.5
defining IMS/VS online system 1.13
defining NCP/VS 7.39
defining physical data bases
ba sic 2.29
logical relationships, with 2.43
secondary indexes, with 2.50
defining VTAM 7.38
definition statements, MFS
device format
DEV
3.39
DFLD 3.42
DIV 3.40
DO 3.41
DPAGE 3.41
EN DDO 3.44
PMT 3. 38
PMTEND 3.44
Index
1.5
message forma t
DO 3.34
ENDDO 3.38
LPAGE 3.33
MFLD 3. 35
MSG 3.32
MSGEND 3.38
PASS WORD 3. 34
SEG 3.34
definition statements, IMS/VS
batch 7.5
online 7.13
delete call (§~~ DLET call)
dependent segments 1.7
destination parent 2.19
device field (DFLD statement) 3.42
device format selection, initial 3.18
device independence 1.26
device input for mat (DIF)
associated MFS functions 3.24
MFS statements used to create
DEV 3.39
DFLD 3. 42
DIV 3.40
DPAGE 3.41
FMT 3.38
FMTEND 3.44
summary 3.24
relationship to other MFS control
blocks 3.22
device output format (ooF)
associated MFS functions 3.25
MFS statements used to create
DEV 3.39
DFLD 3.42
DIV 3.40
DPAGE 3.41
FMT 3.38
FMTEND 3.44
relationship to other MFS control
blocks 3. 22
device page (DPAGE)
3.41
DEV statement 3.39
DFLD statement 3.45
DFS3125A, message
application program invoking
by an 4.30
used for testing recovery
procedures 8.5
DFSBBOOO utility program 6.14
DFSFLOTO utility program 6.27
DFSUCUMO utility program 6.9
DFSUDMPO utility program 6.7
DFSULT RO utili ty program 6. 18
DFSURDBO utility program 6 .. 12
DFSURG10 utility program 5 .. 15
DFSURGLO utility program 5. 10
DFSURGPO utility program 5.19
DFSURGUO utility program 5.8
DFSURPRO utility program 5.13
DFSURRLO utility program 5.6
DFSURULO utility program 5.4
DFSUTR20 utility program 9.. 22
DFSUTR30 utility program 9.5
DFSVSAMP data set 7.61
I.6
IMS/VS Primer
DIF (~!! device input format)
direct access pointers
ba sic da ta ba S9 2. 14
logically related data base 2.25
secondary index data base 2.28
display area (3270 master terminal 3. 17
distributed free space, HDAM or HIDAM
data base 2.33, 2.84
distribution tapes, restoring the
IMS/VS 7.4
NCP/VS 7.40
DIV statement 3.40
DL/I (Data Language/I)
1.1, 1.5
Dt/I call (~~~ calls, Ot/I batch and
calls, DL/I online)
DL/I call functions, batch
checkpoint/restart calls 4.44
delete calls 4.19
get calls 4. 14
insert calls 4.20
replace calls 4.18
DL/I call functions, online
change destination 4.54
message insert call 4.53
message retrieve calls 4.52
OL/I data base (§.~~ data base)
DL/I interface 1.14
OL/I status codes
description (~~~ individual call)
detailed description of B. 1
handling by status code error
rout ine 4.11
quick reference table A.1
DLET (delete) call
basic 4.19
logical relationships, with 2.24, 4.38
secondary indexes, with 4.41
DO statement
DFLD s 3.41
MFLDs 3.34
DOF (§!~ device output forma t)
DPAGE (device page) 3.41
DSCA= operand (OEV statement)
3.39
dynamic attribute modification 4.57
EJECT statement 3.45
emergency restart
description 3.16
testing 8.5
END statement
data base descriptor block, in 2.39
forma t desc ri ptor block, in 3.45
program descriptor block, in 2.61
end-of-data (EOD) 3.2
end-of-message (EOM)
3.2
end-of-segment (EOS) 3.2
ENDDO st atement
DFLDs 3.44
MFLDs 3.38
entities, naming conventions for 1.18
en try point to 3. pplica tion
programs 4.4
erase all unprotected option (fIIFS)
3.39
examples (~!! samples, I~S/VS Primer,
and appli~ation programs, sample)
FEAT= operand (DEV statement)
3.39
feature, If!S/VS ·DC
1.24
fetch request element (FRE)
defining number of 7. 23
performance considerations 9. 16
fie ld format, 11 FS
input message 4.55
ouput message 4.57
field, key
description
1.9
relationship to access
pa th 1.9
FIELD st at ement
basic data base, for 2.37
secondary index data base, for ~55
index target data base, for 2.53
sequence field 2.37
file description, GSAM 2.42
fill characters, ~FS
input message fields 3.24, 3.35
output device fields 3.26
FILL= operand (MFLD statement) 3.35
FINISH statement 2.39
fixed pages, defining in IMS/VS
virtual control region 7.44
floating print lines 3.29
FLOAT parameter (DEY statement)
3.39
FMT st atement 3.38
F ~T EN D st a t em en t
3 • 44
forced attributes (literal device
fields) 3.42
forma t
.(§.~~ !l§'Q device input format,
device output format)
formatting 3270 messages 1.26
forma t, message
input 4.55
output 4.57
format set
definition 3. 18
If!S/VS provided format sets 3.29
forward pointer 2.14
forward recovery 6.21
forward writing of log tape 7.6 8
FRE (§~! fetch request element)
free space anchor point, OSA~ 2.33, 2.84
frequency of image copies and change
accumulations 6.25, 6.32
frequency of physical
reorganiza tions 5.22
Gantt chart, use of 1.21
generalized sequential access method
(.§§~ GSA M)
get ca lIs (da ta base)
GHN 4.18
GHU 4.18
GN 4.15
GU 4. 14
get calls (data communication)
GN 4.52
GU 4.52
GET BOLD NEXT (GHN) call 4.18
GET BOLD UNIQUE (GHU) call 4. 18
GET NEXT (GN) call
data base segment, for a 4.15
message segment, for a 4.52
GET UNIQUE (GU)
data base segment, for a 4.14
message segment, for a 4.52
SPA, for a 4.53
GSAM (generalized sequential
access method)
checkpoint/restart, with 4.45
DBD generation 2.42
de sc ri ption 2.16
how to use 4.25
PSB generation 2.59
restrictions, online use 4.46
SYSIN/SYSOUT, use for 4.25
Guides, IMS/VS Primer
Master Terminal Operator's 8.2
Remote Terminal Operator's 8.7
HD reorganization reload utility
(DFSURGLO)
5. 10
HD reorganization unload utility
(DFS URGUO)
5. 8
HDAM data base
DBD generation 2.29
de seri ption 2. 1 1
design considerations 1.10
loading 4.29
PSB generation 2.57
root addressable area, size of
formula 2.84
using 2.78
BIDA~ data base
DBD generation 2.29
description 2.11
design considerations 2.78
loading 4.28
PSB generation 2.57
space allocation 2.83
using 2.78
hierarchical data structure 1.7, 2.77
hierarchical sequence, sorting segments
in 4.28
H15AM, simple (§~~ 5H15AM database)
I/O PCB 4.48
I/O work area 4.8, 4.52
IGNORE parameter
DEV statement (FEAT=) 3.39
MSG statement (SOB=)
3.32
image copy utility (§§! data base image
copy utili ty)
IMS and IKSBDR procedures to SYS1.PROCLIB,
adding 7.36, 7.78
I~S/VS cataloged procedures
1.66
ACBGEN
7.67
DBDGEN
7.68
Index
1.7
DLIB ATC H 7. 68
IMS
7. 71
Il!S BATCH 7.74
IMSMSG
7.75
IMSRDR
7. 76
PSBGEN
7.76
SECURITY 7.77
MFSRVC
7.. 77
MFSUTL
7.78
IMS/VS Data Ba se S yste m, installing
overview 7.4
tasks 7. 9
Il!S/VS data sets, allocation of
batch 7.4
online 7 .. 11
IMS/VS distribution tapes 7.4, 7.11
IMS/VS installation process
DB system 7.4
DB/DC system 7.11
IMS/VS interface to application
programs
batch 4. 2
online 4.47
overview 1.14
IMS/VS libra ries
DB system 7.4
DB/DC system 7.11
IMS/VS links to OS/VS, establishing
batch 7.2, 7.8, 7.78
online 7.2, 7.36, 7.78
IMS/VS system definition
(§~~ system definition)
IMSCTF macro statement, IMS/VS system
def in it io n 7.6, 7.20
IMSCTRL macro statement, IMS/VS system
definition 7.6, 7.19
IMSGEN macro statement, IMS/VS system
definition 7.7, 7.21
INCLUDE, use of 2.69
INDEX data base, primary 2.12, 2.40
INDEX data base, secondary 2.25, 2.54
inde x function, MP S, perf ormance
factors 9. 16
index pointer segment, secondary
define, how to 2.54
description 2.28
INDEX reorganization reload utility
(DFSORRLO)
5.6
INDEX reorganization unload utility
{DF SUR ULO)
5.4
indexes, secondary
concepts 1. 12
define, how to 2.50
description 2.25
rules for
1.12, 2.26
segment types use with
pointer segment, index 1.12
target segment, index 1.12
source seg me nt, inde x 1. 12
use, how to 2. 86
secondary processing sequence
1. 12
initial load program, sample 4.27
INOUT parameter
DIV statement (TYPE=)
3.40
input message formatting 3.24
I.a
IMS/VS Primer
INPUT parameter
DIV statement (TYPE=)
3.40
MSG statement {TYPE~
3.32
input/output call (§~ calls, DL/I batch
and calls, DL/I online)
inquiry only processing 3.12
inquiry only tra nsaction,
specifying on TRANSACT macro 7.26
insert tISRT) call
(~~~ I SR Teall)
installing
IMS/VS DB system 7.4
IMS/VS DB/DC system 7.11
integration, application data 1.1, 2.69
intent, data ba$e
conflic t, pote ntial
scheduling 3.9, 3.12
defined, how 3.10, 3.51
interface to application programs,
IMS/VS
batch 4.2
online 4.47
intermediate data base, using 3.64
intermediate text block (ITB)
3.47
IS RT call
basic 4.20
loading, for 4.29
logical relationships, with 2.24, 4.38
message segment, for a 4.53
secondary indexes, with ~.41
SPA, for a 4.66
ITB (intermediate text block)
3.47
iterative processing (MFLD/DFLO)
DO statement
DFLD 3.41
MFLD 3.34
ENDDO statement
DFLD 3.44
MFLD 3.38
JCL, sample
insta lla tion, for
batch 7.9
online 7.41
exercising, for 7.48
(§g~ s!§Q Chapter 2, Sample Job
Listing in the IMS/VS Primer
Sample Listings manual)
justification, ~FS field
3.24, 3.26
JUST= operand (MFLD statement)
3.35
key, data base root
1.9
L parameter (MFLD statement)
3.35
LCHILD sta teme nt
basic HIDAM data base, for 2.38
index target data base, for 2.51
logical related data base, for 2.45
primary index data base, for 2.38
secondary index data base, for 2.55
length
data base fields 2.37
device fields 3.26, 3.42
message fields
4.56
print lines, 3270
3. 29, 3.42
libraries, I115/VS l§~~ I11S/VS
libraries)
limiting access to data
1.14, 2.57, 3.49
line groups, terminal 7.31
LINE macro statement, I11S/VS system
definition 7.32
LINEGRP macro statement, I11S/VS
system definition 7.31
lines per printed page 3.29
link security (§~~ security
maintenance utilitn
linkages, MFS control block
chained 3.20
LPAGE/DPAGE 3.22
message descriptions 3.23
message fields and device fields 3.22
linking IMS/VS to OS/VS
I11S and IMSRDR procedures, making
accessible to CS/VS 1.9, 7.36, 7.78
link-editing modules into LPALIB
abend formatting routine 7.78
resource clean-up module 7.18
link-editing type 2 SVC in
as/vs nucleus 7.8, 7.37, 7.18
lit era 1 fie Id s
input message 3.24
output message 3.26
performance factors 3.60
system literals 3.35
literal length IMPS)
3.35
load, initial data base
basic data base, a
HDAM 4.29
HIDA11 4. 28
SHISAM 4.29
sort, use of 4.28
flowchart 4.26
logical relationships, a data
base with
4. 38
overview 4.26
planning for
1. 21
secondary indexes, a data base
base with 4.41
sample program and jobs 4.27
log, 1MS/V5 system
accounting, use for 9.20
administration of 6.31
modifications, recording data
base 6.5
power failure, closing after a 6.21
purpose of 3.15, 6.5
restart, for system 3.22
recove ry, use in 6.22
recovery of 6.18
retention periods for 6.26
serial numbers 6.32
statistics, retrieving from 9.19
termination of 6.27
write ahead option 7.60
log recovery utility program, system
(DFSULTRO)
6. 18
log tape, IMS/VS (~~ log, IMS/VS system)
log tape administration 6.31
log tape data set names 6.31
log tape retention periods 6.26
log tape write ahead 7.60
log terminator utility program, system
(DFSFLOTO)
6. 27
log ical chi ld
concept 1.10, 2.17
define, how to 2.44
deleting 2.24, 4.38
inserting 2.24, 4.38
rela tiOD ship to
physical parent
1.10, 2.17
logical parent 1.10, 2.17
use of
2.85
logical data base
concept 1.10,2.19
define, how to 2.47
relationship to physical
data base
1. 10
use of 2.85
logical data base reorganization
description 5.3, 5.26
flow chart 5.24
pe rf ormance consider at ions 5.25
restructure limitations 5.27
utilities for 5.2
logical page (LPAGE), MFS 3.33
logical paging, operator 3.27
logical parent
concept 1.10
define, how to 2.45
de Ie ting
4. 38
inserting 1.4.38
relationship to logical
chi Id
1. 10
replacing 4.31
logical parent pointer 2.25
logical relationships
building
2. 19
concepts and definition 1.10
description of 2.19
paths, access
1. 10
pointers used wi t.h 1. 10, 2.25
re structuring 5 .. 27
segment types in~,olved with
1.10
utilities used for 5.2
logical relationship resolution utility
programs
data base prefix resolution 5.15
data base prefix update 5.19
data base prereorganization 5.13
logical terminals
concept, definition of
1.27
relationship to physical
terminal
1.2'1
naming conventions for 1.30, 7.35
mc clearogical page)
3.33
LPAGE/DPAGE relationships 3.22
LTEFM (§!! !1§2 logical terminal)
access by application
prog ram
4.49
Index
I.9
concept, IMS/VS 1.27
relationship to node,
physical terminal, and
end user 1.25
LTH= operand
DFLD statement 3.42
MFLD statement 3.35
LTNAME parameter (MFLD statement)
3.35
MAeLIB, required OS/VS option 7.10
macro statements, IMS/VS DB system
definition
I!!SCTF 7 .. 6
IMSCTRL 7.6
I MS GEN
resource na ming rules 7 .. '6
macro statements, IMS/VS DB/DC system
definition
data base and application
APPLCTN 7.25
DATABASE 7.24
TRANSAcr
7.26
data communication-BTAM
COMK 7.31
C TL UN IT 7 .. 32
LINE 7.32
L1 NE GR P 7.3 1
NAME 7.35
T ERMIN AL 7. 33
data communication-VTAM
COMK 7.27
NAME 7.30
TERMINAL 7.29
TYPE 7.28
env ironme nt
BU FPOOLS 7. 23
IMSCTF 7 .. 20
IMSCTRL 7 .. 19
I MS GEN 7.21
MSGQUEUE 7.. 23
SPAREA 7.23
resource na ming rules 7.16
macro statements, maximum occurrences
system definition 7. 16
masks, PCB
batch 4.5
online 4.49
master terminal
commands overview and operating
procedures (2~~ IMS/VS Primer
MTO's Guide)
descr iption 1. 27, 3. 17
devices used for 3 .. 17
format, screen 3. 17
operator 8.2
operator procedures, maintaining 8 .. 5
as/vs console, relationship to 3.18
system definition of 7.30, 7.35
message
definition 3.2
editing of 3.24, 3.26
types of 3.7
message area (3270 master terminal)
3.17
message field (MFLD)
3.35
7."
1.10
IMS/VS Primer
messa ge forma t
input 3.7, 4.55
output 3.7,3.14,4 .. 56
performance factors
3 .. 60
message format service
control sta tements overview 3.30
description 3.18
design considerations 3.59
overview 3.18
message input descriptor (MID)
a ssoc ia ted MF S f unc tion s
3. 18
MFS statements used to create
DO 3 .. 34
ENDDO 3.38
LPAGE 3.33
MFLD 3.36
MSG 3.32
MSGEND
3.38
PASSWORD 3.34
SEG 3.34
rela tionshi p to other MFS con trol
blocks 3 .. 20
message input header 4.55
message output descriptor (MOD)
associated MFS functions 3 .. 18
MFS statements used to create
DO 3.34
ENDDO 3.38
LPAGE 3.33
MFLD 3.35
MS G 3.32
MSGEND
3.38
PASSWORD 3.34
SEG 3.34
relationship to other MFS control
blocks 3.. 20
message output header 4.56
message prefix
input 4.. 55
output 4.56
SPA 4.64
message processing region (MPP)
3.5
message queues
description 3.7
dat a sets 7. 13
recovery 3.15, 3.16
message scheduling 3.8
message segment
description 3 .. 2
format
input message 4.55
output message 4.56
scratch pad area (SPA)
4.64
Message/Format Language Utility Program
(§~~ MFS language utility program)
MFLD statement 3.35
MFS [2~~ message format servic~
MFS language utility program
control statements
compilation 3.44
definition 3.32
naming conventions 3.31
overview 3.30
example 3.42
e xecut ion 3.47
JCL 3.49
proced ures
MFSRVC 7.77
MFSUTL 1.78
syntax 3.31
MFS service utility program 3.49
MFSUTL procedure 7.78
MID (§!§ message input descriptor)
migration, DB to DB/DC 1.78
MaD (2~~ message output descriptor)
MOD parameter (DFLD statement)
3 .. 42
modifications, data base 109ging
of (§~ log, IMS/VS system)
monitor
tB system (~!§ DB Monitor,
IMS/VS)
DB/DC system (§~~ DC Monitor,
IMS/VS)
monitoring online performance 9.14
MSG statement, MFS 3 .. 32
MSGEND statement 3.38
MSGQUEUE macro statement, IMS/VS
system definition 1.23
multipage output message
3.27, 4.58
multiple message mode 3.1
multiple positioning in data
base 4.24
multipoint line, definition, IMS/VS 1.31
multisegment message 3.27, 4.58
NAME macro statement, IMS/VS system
definition 7.30, 7.35
names, logical terminal 1.30, 1.35
naming conventions
entities 1.18
formats, MFS 3.31
jobs, sample
1.19
log tape data set 6.31
logical terminals 7.30, 7.35
naming rules, IMS/VS system definition
resource 7.16
NCP/VS (Network Control Program/VS)
ge ne ra ti on 7. 39
introduction 1.24, 1.26
network (§§§ communications network)
Network control Program/VS (§~~ NCP/VS)
network design 3.38, 9.31
node, VTAM 1.25
NODISP parameter (DFLD statement)
3.42
non-upda te processing
batch 4.14
online 3.12,4.60,4.62
NOPFOT para mete r (DFLD sta temen t)
3.42
normal restart, IMS/VS 3.16
nue leus, as/vs,
linking 7.8, 1.37, 7.18
null characters (for MF~
COBOL, coding in 4.60
FL/I, coding in 4.62
use for 4.51
null fill
input message fields
description
3.24
FIL1= operand (MFLD)
3. 35
output device fields 3.26, 3.42
NULL parameter, MrS
MFLD statement (FILL=)
3.35
NIT= operand
LPAGE statement 3.33
online buffer pools, optimizing
optimizing 9.14, 9.23
operating system,
preparing for IMS/VS 7.2, 7.78
operator, IMS/VS master
terminal 1.27, 8.2
operator, remote terminal 8.6
opera tor logical paging 3.21
optimiz ation of
application programs
9.13
data communication design 9.30
IMS/VS online system 9.13
physical DB implementation 9. 12
VTAM storage pool parameters 9.21
organization of data, IMS/VS (~~
da ta base)
as/vs data files, use of
[~~~ GSAM)
as/vs libraries, cataloging for
IMS/VS system definition 1.4, 7.38
OS/VS links to 1MS/VS,
establishing 7.2, 7.78
as/vs programs used with IMS/VS 1.4
OS/VS supervisor call routine
required by IMS/VS 7.3
OS/VS system modification program
(SMP)
7 .. 81
OS/VS' consideration 7.2
OS/VS2(MVS) considerations 1.78
OSAM (overflow sequential access
method)
2. 10
output call, DL/I (§~~ calls,
DL/1 batch and calls, DL/I online)
output device field attributes 3.28
output limits, application program 7.26
ouput message default format
4.56
output message paging 3.27
output to alternate destination
al te rna te PCB 3.50
CHNG call, use of 4.54
overflow sequential access method
(OSAM)
2. 10
P A (program access)
PA 1 3.28
keys (3270)
PA2 3.28
PA3 3.18
PAG E= ope rand
DEV statement 3.39
MSG statement 3.32
paging, operator logical paging
paging, output message 3.27
3.21
I ndex
I. 11
password and/or terminal
security, IMS/VS
description
1.29, 7.64
definition utility 7.64
definition, MFS 3.34
PASSWORD statement, MFS 3.34
position in master terminal
format 3.17
PASSWORD statement, MFS 3.34
path calls 4.21
path, hierarchical
'.9
PCB (program communicu tion block)
dafin ing
alternate destination 3.50
batch 2.58
online 3.50
application program use
alternate destination 4.48
batch 4.5
online 4.48
PCB statement
alternate destination 3.50
basic data ba_J, for 2.58
GSAM data base, for 2~95
logical data base, for
2.59
secondary index data base, for 2.62
PCB mask (data base)
4.5
PCB mask (data communication)
4.49
performance considerations
[§~~ Chapter 7, Optimization)
PERT chart, samFle
DB system, for
1.21
DB/DC system, for 1.35
PFK12 (program function key 12) for
3270 remote copy 3.18
phases, Primer sam~le
introduction 1.4
jobs
phase 0 7.49
phase 1 7.49
phase 2 7.52
phase 3 7.54
phase 4 7.551
P hysical child
concept
1. 7
define, how to 2.29
pointers use with 2.14
physical data base
concepts, definition 1.5
relationship to logical
da ta ba se 1 • , 0
define, how to 2.29
types, subset 2.5
rules for defining logical
relationships in 2.22
physical data base reorganization
(see data base reorganization)
physical data base recovery (§~~
data base recovery)
physical terminal 1.26
physical/logical terminal
relationship
1.27
I.12
IMS/VS Primer
physical parent
concept, definition 1.7
define, how to 2.29
pointers used with 2.14
physical twin
concept, definition 1.7
pointers used with 2.14
PL/I Optimizer, conventions and use of
ba tch program structure
call formats (§!! individual calls)
guidelines 4.34, 7.37
IMS/VS interface 4.4-4.11
CAUTION for multi-tasking during
link-editing
4.35, 7.37
online program structure
call formats (§~~ individual calls)
conversational MP'P 4.70
guidelines 4.60, 4.68
IMS/VS interface 4.50
inquiry MPP 4.62
pointers, data base
basic 2. 14
logical ~elationships, with 2.25
secondary indexing, with 2.28
pools, IMS/VS buffer (2~~
buffer pools, IMS/VS)
pools, VTAM storage (§~~ VTAM)
POS= operand [DFLD statement)
3.42
positioning, data base, after
D1/I call 4.23
prefix resolution utility (§~~ data base
prefix resolu ti on utili ty)
prefix, segment 3.2
prefix, SPA 4.64
prefix update utility (2~~ data base
prefix update utility)
preparing for IMS/VS use
NCP/VS 7.39
operating system 7.2, 7.78
VTAM 7.38
prereorganization utility (§~~ data base
prereorga niza ti on uti li ty)
prerequisite publications v
primary index (H I DAM)
2. 12
primary master t~tminal
description 3.17
specifying 7.30, 7.35
Primer function, IMS/VS
concept iii
overview and limitations,
subset 1.35
print lines/page (3270)
3.29
PRINT statement, MFS 3.45
printed page format control 3.29
problem reporting, IMS/VS online
system 8.8
procedures, IMS/VS cataloged
description 7.66
listings 7.67
procedures, data base
reco ver y 6.20
procedures, data base
r eorganizat ion 5.20
procedures, IMS/VS
operating 8.1
processing intent, application
pr 0 g ram 2 • 5 8, 3. 1O. 3. 51
processing limits
message scheduling 3.8, 7.26
ouput messages, number and size
of 7.26
processing regions, types of 3.3
processing sequence, secondary 1.12
program access (PA) keys
PA' 3.28
PA2 3.28
PA3 3. 18
program communication block
(2~~ PCB)
progra m f unction key 12 (PFK 12)
3. 18
program isolation (PI) 3.12
program specification block
(see PSB)
Program Specification Block Generation
(PS BGEN)
ba tch 2.57
online 3.49
procedure, cataloged 7.76
programming languages
use with IMS/VS 4.2
programs, application (2~~
application programs)
project approach 1.19
project plan, sample
DB system, for 1.21
DB/DC system, for 1.35
PROT parameter (DFLD statement) 3.42
PSB (program specification block)
concept and definition 1.14
generation
bat ch 2.57
online 3.49
PSBGEN procedure 7.76
PSBGEN st at ement
basic data base, for 2.60
logical data base, for 2.62
secondary index data base, for 2.63
qualified SSAs 4.10
que ues, me ssage
allocation 7.13
description 3.7
recovery 3.15, 3.16
parameter (MFLD statement) 3.35
randomizing algorithm
description 7.57
HDAM, use of 2.12, 2.79
how to write 7.58
IMS/VS-supplied module 7.58
sort exit, use in 4.29
simple sequential, a 7.59
specification in DBD 2.31
record, data base
definition of 2.6
recovery, data base (§~~ data base
recovery)
R
recovery utility (2~~ data base recovery
utili ty)
regions, types of 3.3
relationships
logical 1. 10
MF'S control blocks, between 3.20
parent/child 1.7
reorganization, data base (~~~
data base reorganization)
reorganization utilities 5.3
repetitive generation of
DFLDs/MFLDs 3.34, 3.41
BEPL call
ba sic 4.18
logical relationship,
with 2.24, 4.37
secondary indexes,
with 4.40
replace call (§~~ REPL call)
re qui re men ts, gathering dat a
base 2.69
resource clean-up module (DFSMRCLO),
IMS/VS, including in OS/VS2{MVS)
3.49
resource naming rules, IMS/VS system
defini tion 7.16
response alternate PCB 3.50, 4.35
response time
design considerations 3.55, 9.30
estimating, simple technique 9.31
restart, IMS/VS
emergency 3.16
normal 3. 16
retention periods, log tapes and
image copies 6.26
review, design 2.87
root segment 1.9, 2.6
sa mple application, IMS /V S 1.2
(~~~ gl§2 sa mples, I MS/V S Prime r)
samples, IMS/VS Primer
application environment 1.2
ba tch prog rams
Assembler 4.27
COBOL and PL/I
phase 1 4.32
phase 2 4.39
phase 3 4.41
data base
Parts 2.2
Customer Orders 2.3
C ustome r Nam e
2. 4
data base load procedures 5.23
data base recovery procedures 6.20
data base reorganization
procedures 5.26
DB system definition 7.5
DB/DC system definition 7.13
DBDs, basic 2.40
DBDs, logical relationships 2.46, 2.49
DBDs, secondary indexes 2.56
distribution 7.5, 7.12
formats, MFS 3.46
Index
I. 13
jobs
phase 0 7.49
phase 1 7.49
phase 2 7.52
phase 3 7.54
phase 4 7.55
listings (§!! IMS/VS Primer
Sample Listings)
online programs 4.60, 4.70
overview 1.2
PSBs, basic 2.61
PSBs, logical relationships 2.62
PSBs, secondary indexes 2.63
PSBs, online 3.51
transaction/data element
lila trixes 2. 70
scheduling, IMS/VS message 3.8
scratch pad area {SPA)
description 3. 14, 4.64
definition 1.29
design considerations 3.57
defining at IMS/VS syste~
definition 7.23, 7.26
layout and use 4.65
screen formatting, 3270 display 3.18
secondary indexing 2.25
secondary master terminal, IMS/VS 3.17
security
establishing 7.64
overview 1.29
terminal commands, authorizing
use of 7.65
transactions, restricting entry
of 7.65
security maintenance utility,
ISS/VS 7.64
security violation attempts, recording
of 7. 27, 7.31
SEGM statement
basic data base, for 2.35
logical data base, for 2.48
logical relationship in physical
da ta base, for
real logical child, for 2.44
virtual logical child, for 2.45
secondary index data base, for 2.54
segment
data base 1.6
message 3.7
segment format
data base 2.7
message
input 3.7
output 3.14
scratch pad (SPA) 4.64
segmen t search arguments (SSAs)
characteristics 4.11
command codes for 4. 11
concept and function of 4.9
qualificaticn of 4.10
structure of 4.9
segments, data base
data portion 2.7
defining 2.35
def ini tion 1.6
1.14
IMS/VS Primer
fields 1.16
formats 2.7
length 2.7
prefix 2.7
relationship to data base
record 1.6
types
basic 1.9
logica 1 re la tion ships, with 1. 10
secondary indexing, with 1. 12
segments, sorting in hierarchical
sequence 4.28
SENSEG statement 2.59, 3.51
session, rela tionshi p to
end users and nodes 1.25
sequence fields and access paths 1.9
sequence, secondary processing 1. 12
S HIS AM data base
define, how to 2.29
description 2.15
using 2.85
sibling segments 1.9
simple HISAM data base (§~~ SHISAM data
base)
SMP (a~~ system modification program)
SNA (a~! system network architecture)
sort exit routine, E61
used during data base load 4.29
sort work files, allocating
during reorganization 5.25
sort/merge program required 7.4
sorting segments in hierarchical
sequence 4.28
SPA (§!~ scratch pad area)
space allocation
data base data sets, for 2.83
IMS/VS data sets, for 7.9, 7,.41
SPAREA macro statement, IMS/VS system
definition 7.23
SSA (§~~ segme nt sea rch arg umen ts)
Stage t, IMS/VS system definition
DB 7.5
DB/DC 7.13
ordering of input deck 7.35
Stage 2, IMS/VS system definition
DB 7.10
DB/DC 7.36, 7.44
STAT call 4.25
statistical analysis utility 9.'9
sta tistics
data base buffer pool
prod uced by DB Moni tor 9. 3
produced by STAT call 4.25, 9.1
prod uced by/DIS POOL
ALL command 9.14
DB monitor 9.4
DC monitor 9.21
log tape 9.19
online buffer pools 9. 14
status code, returned after OL/1
calls
use of, progralll 4.11
types 4.11
table of A.1
list of
B.1
overview 4. 11
steps with IKS/VS installation
DB 7.4
tB/De 7.11
storage pool trace, VTAft 9.27
subpool definition statement, for
defining size and number of buffers
OSA ft 7.62
VSAft 7.61
subsequencu field, secondary
index 2.28
subset, IftS/VS Primer
concept 1.1.1.
overview and limitations 1.35
SUF= operand (DO statement)
DFLDs 3.41
MFLDs 3.34
sve, OS/VS
IftS/VS use of 7.3
SVCTABLE, required OS/VS option 7.3
syntax conventions
tBDs and PsBs, for 2.30
formats, for 3.31.
IMs/VS system defin~tion 7.5
sYSMsG= operand (tEV statement) 3.39
sYSPRINT listing control, MFS
EJECT statement
3.45
PRINT statement 3.45
SPACE statement 3.45
TITLE statement 3.447
system console, Os/VS, as
IMs/VS master terminal 3. 18
system definition
IMS/Vs
batch 7.5
online 7.13
NCP/VS 7.39
VTAM
7.38
OS/VS2 (MVs) considerations 7. 1
Stage 1 7.5, 7.13
Stage 2 7.10, 7.36, 7.44
system literals (MFLD statement) 3.35
syste m me ssage field (3 'Z1 0 display
devices)
description 3.29
SYSMSG= operand 3.39
system modification program (SMP),
OS/VS 7.81
system network architecture
ba sic concepts 1.24
relationship to IMS/VS '.24
VTAMs role in 1.26
system service calls (~~~ calls, IMS/VS
system service)
System/370 console, IMS/VS
provided support 3.18
tapes, 1Ms/VS distribution 7.4
telecommunication (§~~ communications
network)
terminal commands, authori~ing use
of 7.65
terminal configuration supported 1.26
TERMINAL macro statement, IMS/VS
system definition 7.29, 7.33
terminal, master (!!! master terminal)
terminal response mode 1.30
terminal security 1.29, 7.65
termi nals
defining
IMS/VS, to 7.30
Nep/VS, to 7.40
VTAM, to 7.38
logical 1.27
physical 1.26
relationship to VTAM node 1.25
terminating an application program 4.11
testing
batch programs 4.30
online programs 4.30, 4.70
MTO procedures 8.5
TI ME 'paramete r (MFLD st at em ent)
3.34
TITLE statement, MFS 3.44
training terminal operators 8.6
transaction
application program, relation
to 2.69
data elements, relationship
to 2.67
define, at system definition 7.26
defini tion 2.66
design considerations
batch 2.. 67, 9.'0
online 3.54, 9.30
message, relationship to 3.2, 3.54
proce ssin 9 flow, messa ge 3.3
transaction codes, restricting entry
of 7.65
transaction/data element matrix
concepts and definition 2.67
gathering requirements 2.69
samples 2.70
truncation, MFS literal
filed 3.35
TYPE macro statement, IMs/VS
system definition 7.28
TYPE= operand
DEV statement 3.39
DIV statement 3.40
MsG statement 3 .. 32
use r input area, master t er minal 3. 17
user liason 8.6
utility programs, IMS/VS
data base loading, for 5.2
data base recovery, for 6.5
data base reorganization,
for 5.2
data base optimization 9.5, 9.22
log tape recovery 6.18
log tape statistics 9.19
log tape termination 6.27
DB Monitor report print 9.5
DC Monitor report print 9.22
overview
ba tch 1. 15
online 1.32
Index
I. 15
view on data, program (§!! masks,
PCB)
virtual child
concept and definition 2.17
define, how to 2.45
virtual control region, IMS/VS,
defining fixed pages in 7.37
virtually paired bidirectional
logical relationship
discussion of 2.17
use of 2.85
VSAM (virtual storage access method)
catalog recovery
considerations 6.26
data space allocation, data
base 2.85
IMS/VS buffer pools 7.59
subpool definition, IMS/VS
buffer 7. 61
VTAM (virtual telecommunication access
method)
description 1. 26
installation 7.38
library creation 7.38
main storage pools
adjusting 9.29
definition 7.38
tracing 9.27
operation considerations 8.8
relationship to IMS/VS 1.24
I.16
IMS/VS Primer
start options 7.38
storage pool trace 9.27
system definition, related
IMS/VS macros 7.27
write ahead option, log tape 7.60
write-to -opera tor-wi th-reply (WT OR)
backup master terminal, as 3.18
message DFS3125A, used for
test 4.30, 8.5
IF ST ca 11
batch, for 4.42
BMP, for 4.47
GSAM considerations
4.45
3270 Information Display System
clear key, impact of 3.41
copy function
candidate printers 7.30, 7.35
invoking of 3.18
program access (PA) keys 3.18, 3.28
program funct ion keys 12
(PF K12) 3 • 1 8
master terminal support 3. 17
message format service (MFS)
3.18
IMS/VS Version 1 Primer
SH20-9145 -0
Reader's
Comment
Form
This manual is part of a library that serves as a reference source for systems analysts, programmers, and operators of
IBM systems. This form may be used to communicate your views about this publication. They will be sent to the
author's department for whatever review and action, if any, is deemed appropriate. Comments may be written in
your own language; use of English is not required.
IBM shall have the nonexclusive right, in its discretion, to use and distribute all submitted information, in any
form, for any and all purposes, without obligation of any kind to the submitter. Your interest is appreciated.
Note: Copies of IBM publications are not stocked at the location to which this form is addressed. Please direct
any requests for copies of publications, or for assistance in using your IBM system. to your IBM representative
or to the IBM branch office serving your locality.
(I)
o
2
List TNLs here:
If you have applied any technical newsletters (TNLs) to this book, please list them here:
Last TNL _ _ _ _ _ _ __
Previous TNL _ _ _ _ _ _ __
Previous TNL _ _ _ _ _ _ __
Fold on two lines, tape, and mail. No postage necessary if mailed in the U.S.A. (Elsewhere,
any IBM representative will be happy to forward your comments.) Thank you for your
cooperation.
SH20-9145-0
Reader's Comment Form
Fold and Tape
........................................................................................................................................
First Class Permit
Number 6090
San Jose, California
Business Reply Mail
No postage necessary if mailed in the U.S.A.
~
en
Postage will be paid by:
<
en
<
..,
('t)
IBM Corporation
P.O. Box 50020
Programming Publishing
San Jose, California 95150
VI
c)'
::l
..,
i:I
3'
..,
('t)
........................................................................................................................................
Fold and Tape
en
:c
N
o
cO
......
~
iii
6
®
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, N.Y. 10604
IBM World Trade Americas/Far East Corporation
Town of Mount Pleasant, Route 9, North Tarrytown, N. V., U.S.A. 10591
IBM World Trade Europe/Middle East! Africa Corporation
360 Hamilton Avenue, White Plains, N.V., U.S.A. 10601
SH20-9145-0
s:
<
en
<
..,
en
(1)
(Il
o·
::I
~
3(1)
..,
CJ')
:c
N
o
cb
~
(J1
6
-";"
®
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, N. Y. 10604
IBM World Trade Americas/Far East Corporation
Town of Mount Pleasant, Route 9, North Tarrytown, N. Y., U.S.A. 10591
I BM World Trade Europe/Middle East/ Africa Corporation
360 Hamilton Avenue, White Plains, N. Y., U.S.A. 10601
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 Producer : Adobe Acrobat 9.13 Paper Capture Plug-in Modify Date : 2009:09:11 03:55:02-07:00 Create Date : 2009:09:11 03:55:02-07:00 Metadata Date : 2009:09:11 03:55:02-07:00 Format : application/pdf Document ID : uuid:5ca80d13-b9a5-4988-b7f4-82c45ff385fb Instance ID : uuid:05bf5661-2cef-4320-8591-45bcef66c0f0 Page Layout : SinglePage Page Mode : UseOutlines Page Count : 494EXIF Metadata provided by EXIF.tools