IMS-VS Version 1 System Application Design Guide Release 1.5 (7th ed.) 197809
SH20-9025-6
Program Product
IMS/VS Version 1
System I Application
Design Guide
Program Number 5740-XX2
Release 1.5
This edition replaces the previous edition (numbered SH20-9025-5) and its technical newsletter (numbered SN20-92661 and makes them obsolete.
This edition applies to Version 1 Rel~ase 1.5 of IMS/VS, program number 5740-XX2, and to any subsequent releases unless otherwise indicated in new editions or technical newsletters.
Technical changes are summarized under "Summ~ry of Amendments" following the list of figures. Each technical change is marked by a vertical line to the left of the change.
Information in this publication is subject to significant change. Any such changes will be published in new editions or technical newsletters. Before using this publication, consult the l~test I~tt ~I~i~~11Q ~iRli2g£!ehY, 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.
liP Copyright International Business Machines Corporation 1974, 1975,
.976, 1977, 1978
This publication presents the design considerations associated with installing and operating Information Management System/Virtual Storage (IMS/VS). It presents I8S/VS concepts, and the facilities available for designing IHS/VS Data Base (DB) and Data Base/Da ta Communication (DB/DC) systems.
This publication provides data base administrators, system designers, system programmers, and application programmers with the information they require to design an IMS/VS system and to design the applications which operate under IMS/VS.
Prerequisite to this publication is the t~~L!~ ~~n~~~i l~{~~~~~i~~ ~~~~~!, GH20-1260. In addition to information in the !~~!~ ~~n~~l in!2··~!i2~ ManY~l, the reader is expected to have a knowledge of Operating system/Virtual Storage (OS/VS) and OS/VS access methods. The chapters in this publication are:
1. "Design, Installation, and Maintenance of the IMS/VS Data Base System" that addresses the factors to be considered when installing a DB system.
2. "Design and Control of the Data Base/Data Communication Syste~ that addresses the factors to be considered when installing a DB/DC system.
3. "Application Program Design" that includes considerations for design of batch and telecommunication IHS/VS applications.
4. "Data Base Design Considerations" that describes data base concepts, structures, and the options available for designing IHS/VS data bases.
5. "Design Considerations for the Hultiple Systems Coupling (MSC) Feature" that describes rlSC and contains design considerations for its use.
6. "Design Considerations for the Fast Path Feature" that describes Fast Path and contains design considerations for its use.
jjt}Ij~ fY~!~}11QR§
l~~L!§ In§~AllA~iQn ~Yide, SH20-9081 This publication presents step-hy-step details for the IrlS/VS installation process.
!~~L!~ ~I§!!! ff29fg!!~ng Eef!f~n£! ~gnyg!, 5820-9027 This manual provides system programming personnel with installation considerations and details for generation (definition) of an IHS/VS system.
1~~L!~ !eel!£gi!Qn g~2gf~!!!ng ~~!!~!B£~ ~gnygl, SH20-9026 This document is a reference manual for the application programmer. It provides information about the coding techniques necessary to implement a designed application under the I8S/VS system.
Preface iii
I~aL!§ y~!!iti~§ l~!ere~£~ ~~~y~!, SH20-9029 This manual provides a description of the IMS/V5 system utility programs. It describes how to execute these utilities under the operating system.
I~aL!§ QE~IatQI~§ RefeI~~£~ ~!DY!1, 5H20-9028 This manual ~rovides the master terminal, remote terminal, and system console operators with the information associated with operating IMS/VS once the system has been established in a user envircnment.
I~§L!§ ~~§§~g~ fQI~~! §~I~i£~ Q§~I~~ ~~1q~, SH20-9053 This manual describes the use, def inition, and implement ation of the Message Format Service (MFS).
I~§L!§ !gY!n~g fg~ti2~ !2I f2!!Y~i£~!12n§, SH20-9054 This manual explains the IMS/VS support for advanced function communications systems. It addresses the areas that programmers or analysts involved in communicating with IMS/VS must be familiar with.
I~§L!§ ~~§§~g~§ !~g ~Qg~§ g~!~£~n£~ ~~n~~i, SH20-9030 This manual lists, explains, and suggests appropriate responses to the completion codes and messages produced by all the IBM-supplied components of the IKS/VS system.
I~§L!§ f!11~~ !~!11§1§ StIg£!gI~ ~~l~§ If!§Il tQI QY~~ An!lI§i§, LY20-8050
This manual contains a simple, structured approach to defining IMS/VS programming failures. This manual is for both 1M S/VS users and IBM progra mming support representatives who diagnose IHS/VS problems.
I~aL!§ Qi!gn2§!i£§ Ai£§, LY20-8063 This manual assists the IBM programming support representative and customer system programmers in using RETAIN/EiS for diagnosing IM5/VS programming failures. It provides a systematic approach both for searching RETAIN/EWS for IMS/VS failures and for constructing a set of keywords as entries into RETAIN/EW5.
I~§L!§ ~.QgI!~ kQgi£ H!ng!l, LY20-8069 The IKS/VS Program Logic Manual provides high level logic analysis information to programming systems representatives responsible for the maintenance of the IBM Information Management System/Virtual Storage (IMS/VS). The format of this manual farallels the function/subfunction breakdown employed in the I~U'!.§ Qi!gnQ§!i£§ !1!!§, LY20- 8063.
~]l~g~!~] fQ~~1~AI1QR§
· ln~IQgY~!i2~ 12 ~b~ I~~ J§~~ ~!§§ §!2I~g~ §1§!~~ l~§§l, GA32-0028
· Q§L!§ ~~§2 §1Q.I~g~ §I§t~! J~§§l .fl!!H!ing §Yi!!~, GC35- 0011
· I~H ~~~Q ~~§§ §~Q.I~g~ ~12!~! l~~§l gI!n~!El~§ Q! QE~I!!iQn,
GA32-0029
iv IMS/VS System/Application Design Guide
~Q!iIll!iI~
~~
PREFACE.
. .
·
· ·
FIGURES. · · SUMMARY OF AMENDMENTS.
. .
· ·
·
iii xiii xvii
CHAPTER 1. DESIGN, IHSTALIATICN, AND MAINTENANCE OF THE
IMS/VS DATA BASE SYSTEM
· ·
Description of Facili ties.
· ·
Systems.
· ·· · · ·
DB Syste m Ge ne ra tion Design Decisions.
OS/VS Option considerations. · · ·
IMs/VS System Definition ·
·
·
.
·. .
·
· ·
· ·
·
·
·
· ·
.
· · · · ·
....·
· ·
Special Access Method -- OsAM. ·
· ·
· ·
Generalized sequential Access Method (GsAM).
Data Base and Application Design Decisions ···
Data Base Description (DBD) Generation.
·
Program Specification Block IPSB) Generation.
·
Application Control Blocks (ACB) Creation and Maintenance. ·
Application Program Design ·
··
Execution and Control of the Data Base system··
Essential Program Elements for Execution
Program Specification Block (FSB).
Da ta Base De scription Block (DBD). Application Control Block (ACB).
·
· . · .· ·
·· ·
·
· · ·
Application Program. I8S/VS System Modules.
· ·· ·
·. · ·
·
· ·
Data Base System Execution.
·
· ·
Data Base System JCL Considerations. Data Base System Control Sequence Flow ·
· . · · ·
· ···
Data Base Buffering.
·
· ·· ·
System Integrity and Maintenance Considerations.
Data Base Logging.
Ba tch Checkpoint/Restart ·
Batch Backout Utility Program. IMS/Vs Use of STAE/ESTAE ·
· ·
IBM System/370 Power Warning Feature Support ·
IMS/VS DB Monitor.
·
·
·
1. 1 1. 1 1.2 1.4 1.4 1.4 1.5 1.5 1.6 1.6 l.8 1.8 1.9 1.9 1.9 1.10 1. 10 1· , 1
1 · 11 1. 11 1.12
,. '4
1.14 1. 16 1. 17 1.17 1. 18
1. 19 1.20 1.21 1.21
CHAPTER 2. tESIGN AND CONTROL OF A DATA BASE/DATA
COMM UNIC ATI ON 5 YSTEM. · ·· · ·
·
2. 1
Relationship of DB/DC to DB system ·
Organization of DB/DC Processing ··
Region Types ·
·· ·
·
.
·
·
.
2. 1 2. 1 2.1
Configuring the system through Opt ions
2.3
OS/V S 0pti ons.
··
Fixed or Variable Tasking.
·
2.3
2.3
IMS/VS Program Module Preload Function ·
2.3
Performance Considerations for Modules Preloaded
in MPPS/IFPs. · ···
·
··
2.4
I8S/VS in an OS/VS System.
·
2.5
Supported Configurations · · · ·
·
2.5
Os/VS Options Required or Recommended for IMS/Vs ·
2.5
Special Access Method -- eSA!!.
· ·
2.5
Allocation of OSA8 Data Sets.
··· ·
2.5
I8S/VS Facilities.
· ·
· ·
·
2.7
Control Program. · · ·
· ···
2.7
Processing Regions ·
· ·
2.7
Active I/O Requests.
2.7
Contents v
Checkpoint Frequency · · · · · · · · · · · · · · · · ·
System Queue Space · · · · · ·
· . IMS/VS Enqueue/Dequeue. · ·
Program Isolation. ·
· ····
· . Message Scheduling ·· · · · · ·
Message Class and Region Class
· ·
·
· ·
· ··
· ·
·
· ·
·
· ·
· · · ·
· · ·
·
· ·
·
Load Bala ncing · · · · · ·· Selection Priorities · · · · Proce ssi ng Limi ts. · · ·
· · · '. · · · ···· · ·· ·
· · · · · ·
· · ·
·
· ·
Application Program Output Limits···· · ·
·
Multiple and Single Segment Messages. Multiple and Single Message Mode ·
· · · ·
· · ·
· . Response Mode.
· · · ·
Non-Update Transaction Frocessing.
· · · · · ·
· · ·
Conversational Attribute · ·· Data Base Processing Intent..
·· ····
· ·
· · · ·
· · ·
Processing Intent specifications ···· Application Progra. Abnor.al Termination ·
· · · · ·· · · ·
·
·
Control Block Buffer Pools - PSB and DMB · · · · ·
Da ta Base s ·
··
· ·
· ·
· ·
Dynamic Allocation and Deallocation of DL/I and Fast Path
DED'S Dat.a Sets (M VS Only) · · · · · · · · ·· ·· · · ·
Starting and Stopping the 185/VS Control Region. ··· ·
Batch Checkpoint/R estart · · · ·· ·····
· ·
Message Que ue s · · ·· · · ·
· · · ·
· · ·
·
Message Queues and Message Selection · · · · · · · · · · · ·
Terminal Modes
· ·
· ·
Determining Message Selection. · ·
·
Queue Data Sets. ··
···
· ·
Opera tion of Queues. ···
· ····
· · · ·
Emergency Restart Queue Repositioning. ·
·· ·
·
.. Bessage Queue Reuse. · ·· ·· · · · ·
· · ·
Physical Terminals ·
· ·
· · '. · ·
·
·
Devices Supported. · ·
··
· ·
·
BTAM Da ta Set Line Groups.
Terminals Attached through VT AM. Physical Terminal Network Design ·
· ·
Logical Terminals. Definition of the
·· · Logical Terminal
c· o·nc·e
· p
t.
· · · ·
The IMS/VS Logical Terminal · · · · · · · · · · · ·
Logical Terminal Network Design. ·
· ·
· . Logical Terminal/Physical Termina 1 Rela tionship.
Master 'terminal. ···
··
system Console Support ·
·
·
Systems with Inoperable Master Terminal.
· ·
· · · · · ·
Message Format Service · · · · ·· · ···
·
Overview of IMS/VS 3270 Support.. ·
·· ····
'. 3270 Copy Function · · · · ·
· ··· ·
·
328~ Model 3 Printer Support. · · · · · · ·
·
3270 Master Terminal Suppcrt ···
· ·
Intelligent Remote Station support ·
· · · · ·
'transmission Blocks.
System/3 and System/7 Program Function Requirements. ·
·
IMS/VS System Messages · · · ·
·· ·
· ···
·
'transmission Control · · · · ·
· · ·
· ··
·
system Definition. · · · · · ·· · ····
·
Postpone Type Station.
·· ·
···
Ask Type Station · ·
·
· ·
transmission Limit ·
Combining Modes..
· ·
Considerations Unique to System/7 ·····
·.·.· · ·
·
System/7 Start/Stop Transmission Code Modes ··
Supported System/7 Start/Stop Line Types. Supported System/7 BSC Line Types · · · · ·
· ·
·
· · · ·
2.8 2.8 2.8 2.8 2.9 2.10 2.11 2.11 2.12 2.12 2.12 2.14
2.15 2.17 2.17 2.18 2.20 2.23 2.26 2.26
2.27 2.28 2.28 2.32 2.33 2.34 2.36 2.40 2.41 2.42 2.42 2.42 2.43 2.44 2.45
2.~5
2.46 2.46 2.47 2.48 2.50 2.53 2.54 2.54 2.54 2.56 2.57 2.58 2.59 2.59 2.59 2.60 2.61 2.61 2.62 2.62 2.62 2.63 2.63 2.68 2.68 2.68 2.68
vi 18S/VS System/Application Design Guide
Process controlling System/7 ·· ·· ········· ··
IlIS/VS Processing cf a Block Transmitted Sta rt/Stop from
a System/7. · · · · · · · ·
· ··········
Considerations Unique to System/3. ·· ···
··· ·
Design of the System/3 Application Using MLHP. ·· ··
IMS/iS Processing of a Block Transmitted from a System/3
or a BSC System/7 · · ·
· · ·· ······ ···
Control of the DB/DC system. · · · · · · · · · · · · ·
· ·
Security and Privacy ·
· · · · ·· ···
· · · · ·
Il1S/VS Sec uri ty with SitU ·
· · · · ·
· · ·
· ·
Te rminal Sec uri ty. · · · · · · · · · · · · ·
Password Security. ·
· · · ·
· · · ··
Resource Access Security..
· ·· ···
Transaction Command Security
· · · · · ·
· ·· · ·····
Signon Verification Security. ····
· ······
Other Security Aspects ·
· · ·· ······
·
Display Bypass · · · · · · · · · · · · · · · · · · · · · · ·
Limiting Access to Data. · · · · · · · · · · · · ·· · ··
3270 Switched Terminal Security.
····· ··
Violation Control. · · · · · ·
· ········
Installation Responsibilities. ·· ····
· ···
Il1S/VS DC lIonitor. · · · · · · · · · · · · · · · · ·· · ··
I"S/VS Sensitivity to Nongraphic Message Da ta. · · · ·
· ·
Editing of Output Message Segments · ·
·· ·
Editing of Input Message Segments by MFS · · · · · · · · · · ·
Editing of Input Message Segments by Basic Edit Routine. · ·
Common Editing Perf oImed by IlIS/VS. ··
· · ·
Using the 3850 lIass storage System (MS5) for DB/DC Processing.
Terminology. · · · · · · · · · · ·
· · ·
· ·
IMS/VS Batch Environment · · · · · · ·
· ·
· · ·
I"S/VS Online (DB/DC) Environment. · ·
·· ··
IMS/VS Online Using Bound Data and/or DASD without Batch ··
1MS/VS Online Using Bound Data and/or Real DASD wi th
IMS/VS Batch. · · · · · · ·
· ··········
IlIS/VS Online and Batch Using Some Bound a nd Some
Nonbound Data · · · · · · ·
· ·· · ····
· . . Sharing of Staging Space. · · · ·
· ·······
Data Base Organization and Access lIethod ···
How to Use the Additional Capacity of HSS with 1HS/VS· · · · ·
· . · . . CHAPTER 3. APPLICATION PBCGRA~ DESIGN.
. . . . Batch Application Program Design · ·
· . . General Considerations
· · · · · · · ···
· . . Programming Language to be Used.
·· · · ·
Future Conversion to Telecommunication ·· · · · · · ·
· . . · . . Batch Checkpoint/Restart Considerations ··
· ·
. . . . · . . Establishing Useful Conventions··
· · ·
Testing_ · · · · · · · ·· ··········
. . . . . . · . Nailing Conventions ····
·
· · ·
Use of COpy or INCLUDE · · ·
Using the Right DL/I Call. · · ·
· ··
Relationship between DL/I Calls and Physical I/O Operations··
Performance considerations ·
···· ·····
· ··
Using Accumulated DL/I Statistics. ·
· ·
· · · ·
Telecom.unication Application Program Design
· ·
Telecommunication Input/Cutput Interface ·······
Input Calls. · · · · · · · ·
· · · · · · · · ·
·
Output Calls · · · ·
· · ·
· · · · ·
Output to Alternate Destinations.
· ·
Modifiable Alternate PCBs. ·
·
· . Re sponse Alte rna te PCBs. · · · · · · · · ·
. . · . Converting from Batch to Telecommunication
Telecomllunication Device Independent Programming
· . Device Class Control Considerations.. · ··
· · · · ·
·
2.68
2.69 2.70 2.70
2.71 2.72 2.72 2.72 2.73 2.73 2.74 2.75 2.75 2.76 2.76 2.76 2.77 2.77 2.77 2.78 2.79 2.79 2.79 2.80 2.81 2.81 2.82 2.83
2.8/J
2.85
2.86
2.87 2.90 2.90
2.92
3.1
3. 1 3. 1
3.2 3.2 3.4 3.4 3.4 3.4 3.5 3.7 3.8 3. 10
3. 10
3.11 3. 11 3.14
3. 1/J
3.15 3.16 3. 17 3.17 3. 18 3.18
Con ten ts vii
Utilization of Sysout Devices.
·· ··
·
Program Testing Using SYSIN/SYSOUT · · · ·
Conversational Processing.
· ·
·
paging Feature -- 2260 and 2265.
Ba tch Message Processing Programs.
Use of EMP ·
·
Buffering.
Useful ~ech ni gues.
·
Intermediate Data Eases···
· ·
Message Editing.
Outputting a Mask to the 2260.
·
Passing Information from One Program to Another.
·
CHAPTER 4. DATA BASE DESIGN CONSIDERATIONS.
Concepts of Physical Data Bases.
· ·
· ·
Segments
·· ·
· · ·
·
Segment Formats. Segment Code ·
·
· ·
·
Delete Byte.
·
Fields ·
·
·
·
· ·
Structure.
Defining a Physical Data Base Hierarchy.
Calls.
· ·
Get Unique ·
Get Next.
·
Get Next within Parent.
Hold Form of Get Calls ·
·
· ·
Insert.
Delet e ·
·
Replace. · ··
·
·
SSA (Segment Search Argument).
·
Physical Data Base Organization in Storage
·
Hierarchic Sequential and Direct Methods of Storing a
Data Base · ·
·
·· ··
Pointers.
·
· ·
Hierarchic Pointers.
·
Physical Child/Physical Twin Pointers.
Data Set Groups.
Rules for Dividing a Data Base into Data Set Groups. · HSAM Storage Organization.
Simple HSAM.
HISAM Storage Organization · ·
HISAM Data Base Stored as One Data Set Group ··
HISAM Logical Record Lengths.
HISAM Root Segment Insertion ·
HISAM Dependent Segment Insertion.
·
HISAM Segment Deletion ·
Secondary Data Set Groups.
Simple HISA! ···
·
HDAM and HIDAI! Storage organizations ··
HDAM. ·
· ·
Size of Root Addressable Area. ··
Loading an HDAM Data Base.
HIDAM.
·
Loading a HIDAM Data Base. ·
·
·
·
· ·
HIDAM Data Base Root Segment Type Pointer Options.
Format of Data Sets Used for HDAM and HIDAM.
Free Space Anchor Point.
·
Free Space Element ·
·
Anchor Point Area.
Bi t Map Block. ·
·
Bit Map.
·
Inserts and Deletes in HDAM and HIDA" Data Bases.
Inserts.
3.20 3.20 3.20 3.22 3.22 3.23 3.23 3.23 3.23 3.24 3.24 3.24
4. 1 4.1 4.2 4.2 4.3 4.3 4.4 4.6 4.9 4.12 4.12 4. 12 4.12 4. 12 4.12 4.13 4.13 4.14 4.14
4.14 4.14 4.16 4. 16 4.18 4.19 4. 19 4.21 4.21 4.21 4.24 4.26 4.28 4.32 4.33 4.33 4.34 4.35 4.35 4.37 4.37 4.38 4.40 4.40 4.42 4.42 4.42 4.43 4.43 4.43 4.43
viii IMS/VS System/Ap~lication Design Guide
Deletes.
.·
Distributed Free Space · ·
· . · · ·
· ·· ·
· · ·
HISAH and HIDAM Key Segments ··
· ·
·
Options Available in Defining Fhysical Data Bases. ·
HSAM ·
· ·
HI SAM.
· · ·
· ·
·
BDAM or HIDAM.
· ··
Logica I Rela tionships...
· · · ·
· · ·
Methods of Relating Segment Types through a Logical Child··
Method One ·
·
······ ·
· ·
Method Two ·
· ·
Logical Relationship Paths.
· ·
Logical Child Segment.
· ··
Unidirectional Logical Relationship.
· ·· ······ ·
Physically Paired Bidirectional Logica I Rela ti onship ·
Virtually Paired Bidirectional Logical Relationship.
Defining Fields in Logical Child Segment Types ··
· ·
Pointers and the Counter Used in Logical Relationships.
· . Logical Parent Pointer ·
·
Logical Child/Logical Twin Pointers.
Physical Parent Pointers ·
Counter.
·
· ·
·· ·
Defining Sequence Fields for Data Bases Involved in Logical
Relationships. ·
·
· · · ·
· ·
· ·
Rules for Defining Logical Relationships in Physical Data
Bases ·
·
·
Logical Child.
Logical Parent · Physical Parent.· Replace. Insert and Delete Rules ·
··· ...
Introd uc tion Summary ·
RULES Coding ·
·
The Replace Rules. · ·
The Replace Call ·
·
·
· ·
· ·.
Physical Replace Rule Exam~le.
·
· ·
· · ·
Logical Replace Rule Example
Virtual Replace Rule Example ·
Replace Rules Summary.
·
The Insert Rules ·
· ·
Logical Child Inserticn.
· ·
The Insert Call.
Sta tus Code s · ·
·
· . · . · · · · ·
· . ·
· · ·
. .
· .
· ..
Physical Insert Rule Example.
Logical Insert Rule Example.
Virtual Insert Rule Example.
·
Insert Rules Summary ··
Delete Rules Introd uction.
Physical and Logical Deletion ··
Deleting Concatenated Segments
!he Third Access Path.
·
Delete Byte Definition ·
·
Segment Prefix -- [elete Byte.
The Delete Call.
·
·
· · ·
· ·· ..
·
·
Status Codes · DASD Space Release
· .
· .
Delete Rules ·
· ·
Logical Parent ·
Physical Parent (Virtual Pairing Only)
Logical Child.
Examples ·
· . Logical Child. Virtual Pairing -- Physical Delete Rule
Exa mple ·
· ··
· ·
To Delet e the Logical Child.
·
Logical Child, Virtual pairing -- Logical telete Rule
Example ·
4.44 4.46 4.46 4.47 4.47 4.47 4.47 4.48 3.49 4.50 4.51 4.53 4.54 4.55 4.56 4.57 4.59 4.59 4.60 4.61 4.61 4.61
4.61
4.62 4.62 4.62 4.63 4.63 4.64 4.65 4.66 4.66 4.67 4.68 4.69 4.69 4.71 4.71 4.71 4.72 4.72 4.73 4.74 4.75 4.75 4.76 4.76 4.77 4.77 4.77 4.78 4.18 4.79 4.79 4.79 4.80 4.80 4.80
4.81 4.81
4.82
Contents ix
To Delete the Logical Child.. · · · · · · · · · · · · ·
Logical Child, Physical Pairing --.Physical/Logical Delete
Rule Example. · · · · · · · · · · · · · · · · · · · · · · ·
To Delete the Paired Logical Children. · · · · · · · · · ··
Logical Child, Virtual pairing -- Virtual Delete Rule
Example · · · · · · · · · · · · · · · · · · · · · · · · · ·
To Delete the Logical Child. · · · · · · · · · · · · · · · ·
Logical Child, Physical Pairing -- Virtual Delete Rule
Example · · · · · · · · · · · · · · · · · · · · · · · · · ·
To Delete the Paired Logical Children.
· · · · · · · · ·
Logical Parent, Virtual Pairing -- Physical Delete Rule
Example · · · · ·
· · ··· · ··· ·· · · ·· · · · ·
To Delete the Logical Parent · · · · · · · · · · ·· ·
Logical Parent, Physical Pairing -- Physical Delete Rule
Example · · · · ·
· · ·· ··············
To Delete Either of the Logical Parents · · · · · · · · · · ·
Logical Parent, Virtual Pairing -- Logical Delete Rule
Example · · · · · · · · · · · · · · · · · · · · · · · · · ·
To Delete the Logical Parent · · · · · · · · · · · · · · · ·
Logical Parent, Physical Pairing -- Logical Delete Rule
Example · · · · · · · · · · · · · · · · · · · · · · · · · ·
To Delete Either of the Logical Parents · · · · · · · · · · ·
Logical Parent, Virtual Pairing -- Virtual Delete Rule
Example ·
· · · ·
· · ·· ·· ··· ·· · · ··
Deleting Last Logical Child Deletes Logical Parent ·····
Physical Parent, Physical Pairing -- Vi rtual Delete Rule
Example · · ·
· · · · · ·· ···
·
···
Deleting Last Logical Child Deletes Physical Parent. · ·
Physical Parent, Virtual Pairing -- Bidirectional Virtual
Example · · · · ·
·············· ·····
Deleting Last Logical Child Deletes Physical Parent. · ·
Accessibility of Deleted Segments. · · · · · ·
· ·
Avoiding Abnormal Termination. ·
· · · · · · · · · · · · ·
First Solution · · ·· ···········
· ·
Second Solution. · · ·
··· · · · · · · · · ·
·
Detection of Physical Delete Bule Violation. · · · ·· · ··
Physical Delete Rule Treated as Logical. · · · · · · ·
· ·
Inserting Physically and/or Logically Deleted Segments ····
Delete Rules Summary · · · · · · · · · ·
· ···
The DLET Call. · · ·· · · · · ··
· ·· ···
Physical Daletion. · · · · · · · ·
· · · · · · · · · · ·
Logical Deletion · · ·
· ·
· ·
Access Paths. · · · · · · · ·
··· ·· · ···
Propagation of Delete. · · · · ·
·· · · ···
Delete Rules · · · · · · · · · · ·
· ·· ·······
Logical Parent · · · · · · · · · · · · ·· ········
Physical Parent of a Virtually Paired Logical Child. ·
Logical Child. · · · · · ·
· · · · · · · · ·· · ··
Space Release. · ·
··· · ·· ·· · · · · ··
· ·
Defining a Logical Data Base · · · · · · · · · · ·
· ·
Definition of Crossing a Logical Relationship········
Definition of First and Additional Logica 1 Rela tionships
Crossed · · ·
· ·
· ······
Rules for Defining Logical Data Bases. · ·
· ······
Example 1. · · · ·
· ·
···· ······
·
secondary Index ing · ·
· · · · ·
· · · · · · ·
Secondary Processing Sequence. · · · · · · · · · ·· ··
Secondary Data Structure. · ·
· · · · · · · ·
· ···
Options and BuIes for Secondary Indexing ···
Organization of Secondary Indexes in Auxiliary Storage ···
· . . Index Pointer Segment Format · · · ·· · · · ·
· . . Constant · · · · · · ·
· · · · · · · · · · ·
. . Sea rch Field · · ·
·· ··
· ·
. . . . . . Subsequence Field. · ·
· · · ·
. . . . Duplica te Data Iield (DDA TA)
· · · ·
4.82
4.83 4.83
4.84 4.84
4.85 4.85
4.86 4.86
4.87 4.87
4.88 4.88
4.89 4.89
4.90 4.90
4.91 4.91
4.92 4.92 4.93 4.99 4.99 4.99 4.· 100 4.101 4. 101 4.102 4.102 4.102 4.102 4.102 4.102 4.103 4.103 4.103 4.103 4.103 4.104 4.104
4.105 4.107 4.108 4.109 4.11.1 4.111 4.113 4.114 4.115 4.116 4.116 4.116 4.117
x IMS/VS System/Application Design Guide
Additional Data in Index Pointer Segments·········· 4.117
System Related Fields. · ·· · ·············· 4.117
Suppression of Index Entries · ·· · ··········· 4. 118
· . Index Maintenance Exi t Boutine · · · · · · ·
· · · · · · 4.118
Index Maintenance Processing · · · · · · · · · · ·
4. 118
Shared Index Data Eases.
· · · · · · · ··
4. 119
Secondary Indexes and segment Search Arguments
· 4.120
Considerations · · ·
· · · · · · · ·
· ···· 4. 121
variable Length Segments · · · ·
· · ·
· · · 4.122
Considerations · ·
· · · ·
· ·
· ·
4.124
Conversion Considerations.
· · ·
· 4.125
Segment Edit/Compression Exit. · · · ·· · ·········· 4.125
Processing Time. · · · · · · · · · · · · ·· · ······· 4. 129
Direct Access Storage Space Utilization············ 4.134
Design Tradeoffs · · · · · · · · ·
· · · · · · · · · · 4.140
Viability of Data Base Design. · · · ·
· ·····
5. 142
Hierarchical Direct Design Considerations.
· ······
4.146
Design Considerations for the Index of a HIDA! Data Base · 4. 147
Design Considerations for Data Portion of HIDA! Data Base. 4.147
Design Considerations for an HDA! Data Base· · · · · · · · · 4. 147
HDA! -- HIDA! Considerations for Dependent Segments. · · · · 4.148
I!S/YS Use of BISA!/QISA!.
· · ·
· ·
4.148
· . . Utilities. ··
····· ··· ··
Da ta Base Becovery · · ·· · · · · · · · · · · · · -.
4. 149 4.149
Oat a Bas e Reorganiz ation ·· · · · · · · ·
4.150
Feorgani za tion Interval. ·
·
4. 151
Reorganization of HISA! Data Bases.. ·· Reorganization of HDA! and HIDA! Data Bases.
· .
4.151 4. 152
Partial Data Base Reorganization · · · · · · · · · · ·
· 4.152
PDBR Limitations · · · · · · · · · ·
· · · · ··· · ·
4.153
Step One: Pre-Reorganization. ·· ······ ······ 4. 153
1(.
Step Tvo: Pointer Resolution. · ·· ·
· · · · · · · · ··
· . The Data Base Surveyor Utility ·
· ···
· ·
· . . User Responsibilities · · · · · · · ·
· · · ·
· . Utility Control Facility · · · · ·
· · ·
I!S/VS Data Base Space Allccation ··
·· .. .. ·· .. ·· .. Allocation Considerations····
· · · · ·
4.153 4.154 4.154 4.155 4. 155 4.156
CHAPTER 5. tESIGN CONSIDERATICNS FOR THE !ULTIPLE SYSTEMS
COUPLING (!SC) FEATUR E.
· ·
· ··
5. 1
Relationship of a DB/DC/MSC System to a Single DB/DC System ·· 5.1
OVerview of the MSC Feature.
· ······
5.2
Links. · ·
· ·
Physical Link..
Logical Link · ·
. . · · · ··· ..· ..· ·. ..
· . 5.3 · 5.4 · 5.5
Message Routing.. · · · ·
·
· . . Routing Path · · · · · · · ·
· . · . . Logical Link Path ·····
. ·· .. .. .· . Logical Destinations ·······
. . . Input and Destination Systems.
· . Intermediate System· · · · · · · · ·
· . . ·· .. .· . · . Remote Transaction Priorities.
· · ··
· ·
5.6 5.6
5.6 5.1
5.7 5.8 5.9
Stopped Transactions ·
··· ··
· . . . Routing Exit Routines··
· . . Remote Destination Verification.
· . · · . · . . Application Program Abnormal Termination
. . Conversational Processing. · · · ·
. .· . · . · . . Routing Exit Routines ····
· . . Remote Destination Verification· · ·
· . Normal Conversation Termination. · ·
· . . · . Abnormal Conversation Termination.
· . . · . . · . . Multisystem Operations · · · · · · · · ·
· . ·· .. .. . Multisystem Communication Initialization.
· . . Multisystem Communication Termination· · · · ·
· . . Logical Link Assignments ·
· ·
· · · ·
· · ·
5.9 5.10 5.10
5. 11
5.11 5. 12 5.12 5.12
5. 13
5.13 5. 13
5.14 5.14
Contents xi
. Security ·
Recovery
· ·
· · ·
·
·
·
·
·· ·
·
Compatibility. ·
·
Performance Considerations for MSC · ·
Minimizing Resource Consumption. ·
· ·
Balancing Resource Demand.
·
8SC Examples ·
· ·
· ···
· · ·
· 5.14 · · 5.15
5.15
·
5.15
5.16
5.16
· 5.17
CHAPTER 6. DESIGN CONSIDERATIONS FOR THE FAST PATH FEATURE.
6.1
Fast Path Data Bases · · ·
·
· ·
. Main Storage Data Base (MSDB) · · Defining an MSDB
· · ·
·
· · · MSDB DL/I Calls.
·
The FLD Call ·
8SDB Buffer Allocation · · ·
· · ·
·
·
·
·
Data Entry Data Base IDEDB) · ·
· · ·
· ·
Root Addressable Part. · · ·
· ·
· ·
Independent Overflow Part. · · · · · · · · · · · ·
Sequential Dependent Part.
·
·
space Definition ·
·
· ·
Accessing Segments. · ·
·
·
Root Segment Processing. ·
·
· ·
Sequential Dependent Segment Processing.
6.1 6.1
6.2 6.2 6.3
6.3
· 6.4
· 6.6
· 6.6
6.7
6.7
6.7
· 6.8
6.8
Direct Dependent Segment Processing. ·
·
· · DEDB Synchronization Processing.
Defining DEDB Data Eases
·
DEDS USD Space Definition
·
DEDB DBD Space Considerations.
·
· ·
·
· ·
Example. Performance
Con·side·ration
in
· Loading
a
DEDS
Area.
· · 6.8
· 6.8
6.9
6.9
6. 10 6.12 6.13
DEDB tata Base Full Condition. ·
·
·
6.14
Fast Path Program Types. · ·
·
6.14
Message Handling · Input Message. · output Messages.
· ·
· · ·
6.15 6.15 6. 15
J
Synchronization Point Processing · · Fast Path and I8S/VS Interrelationships.
6.16 6.16
INDEX.
·
· ·
·
· 1.1
xii IMS/VS system/Application Design Guide
Il
Il
1-1. IMS/VS Data Base System Environment.
· . 1-2. DBD Generation Execution. · · · · · · · · · · · · · · · ·
1-3. PSB Gene ra tion Exec ution. · · · · · · · · · · ·
1-4. ACB Creation and/or Maintenance · · ·
···· ·
1-5. Essential Program Elements for Execution. · · · · · · · ·
1-6. Initializing the Batch tata Base System, Step One · · · ·
1-7. Initializing the Batch Data Base System, Step Two
··
1-8. Data Base System Flow · · · · · · ·
· ····
2-1. Dynamic Allocation Parameter List · · · ·
· ·
2-2. General Message Queue Structure ··········
2-3. Source of Messages. · · · · ·
· · · · · · · · ·
2-4. Queue Selection · · · · · · · ·
2-5. Que ue Data Set Relationships. ·
· · · · · · · ·
2-6. Separating Device Class Sensitive Terminal I/O. · · ···
2-7. Possible Physical/Logical Termina 1 Rela tionships·····
2-8. Message Formatting Using MFS · · · ·
2-9. Overview of Message Format Service. · · · · ··
· . . 2-10. 3270 Copy Function ExamJ,:le. · · · ·
· ·····
2-11. KSS in an IKS/VS Batch Environment · · · · · · ·
2-12. KSS in an IMS/VS Online Environment with Bound Data · · ·
2-13. MSS in an IMS/VS Online and Batch Environment · · ·
2-14. MSS with IMS/VS Online and Batch and Non-IMS/VS Data.
2-15. MSS in an IKS/VS Environment Using Shared Data Bases.
3 -1. Ba tch Application Progr am Design. · · · · · · · · · · · ·
3-2. Planning Future Conversion to Telecommunication ··
3-3. Application Program Using OS/VS Data Files and DL/I
Da ta Ba se · · · · ·
· · · · · · · · · ·
3-4. Application Program Using COBOL READ/WRITE Logic and
File Description. · · · ·
·· ···········
3-5. Qualified Segment Search Arguments······· 3-6. Telecommunication Ap~lication Program Design.
· . .
3-7. Application Program's View of the Terminal··
3-8. DB and TP PCBs · · · · · ·
. . . 3-9. Message Segment Format · · · · · · ·
3-10. Input Call Format · · · · 3-11. Three-Segment Message · ·
. . . . .
3-12. Output to Alternate Destinations ·· 3-13. Converting from Batch to Telecommunication··
· . .
3-14. Six-Segment Message Separated into ~wo Three-Segment
Messages by Use of the Furge Call ·
· · ·
3-15. Conversational Program. · · · ·
· ······
3-16. Intermediate Data Base. · · · · · ·
· ·······
4-1. Segment Formats. · · · · · ·
· · · ··
4 -2. Delete Byte ·
· · · ·
· · · · ·
· · ·
4-3. Concatenated Keys. · · ·
· ··
4 -4. Hierarchy of Segment TYJ,:es· · · ·
4-5. Data Ease in Storage········
4-6. Segment Types Numbered in Hierarchic Sequence.
4-7. Physical Twins. · · ·· ·····
4-8. Direct Address Pointers · · · · · · 4-9. Use of Backward Pointers for Delete · 4-10. Use of Physical Child Last Pointer.
....
4-11. One Data Base Record of HSAM Data Ease on Tape··
4-12. HISA!! Data Base Record in Storage (Single Data Set
Gro up). · '. · ·
·· ··· ·
·· · · · ·· ·
4-13. HISAM Data Base VSAM, ISAM and eSAM Logical Record
Formats · · · · · · · · ··
·· · · · · ····
4-14. Root Segment Insertion into Key Sequenced Data Set
Control Interval. · · · · ·
·· · · · · · · · ·
1.3 1. 7 1.8 1.9 1. 10 1.13 1.14 1. 15 2.27 2.33 2.37 2.40 2.41 2.49 2.50 2.55 2.56 2.58 2.83 2.84 2.85 2.87 2.90 3.2 3.3
3.5
3.6 3.8 3. 11 3. 12 3.13 3. 13 3.14 3.15 3. 16 3.18
3.19 3.21 3.24 4.3 4.4 4.5 4.7 4.8 4.10 4.11 4. 15 4.17 4. 18 4.20
4.22
4.23
4.26
Figures xiii
4-15. Root Segment Inserticn When ISAM/OSA! are HISAM Data
Base Access Metbcds · · · · · · · · · · · · · · · · · ··
4-16. HISAM Root Segment Insertion Sequence. · · · · · · · ··
4-17. Dependent Segment Insertion into a HISAM Data Base with
One Data Set Group. · · · · · · · · · · · · · · · · · ··
4-18. One Data BaSE Record in a HISAM Data Base (!ultiple
Data Set Group) · · · · · · · · · · · · · · · · · · · ··
4-19. HDAM Data Base Record in Auxiliary Storage. · · · · · ··
4-20. Insert of a Root Segment into a HIDAM Data Base after
Initial Load · · · · · · · · · · · · · · · · · · · · · · ·
4-21. Control Fields Used to Manage Entry Sequenced or OSAM
Data Sets Used fer HDAM or HIDAM Data Bases · · · · ·
4-22. Hierarchic Direct Deletion of Dependent Segment · · · · ·
4-23. Relating Occurrences of SKILL to Occurrences of NAME · · ·
4-24. Relating Occurrences of NAME to Occurrences of SKILL· · ·
4-25. Defining a Physical Farent to Logical Parent Path in a
Logical Data BaSE · · · · · · · · · · · · · · · · · · · ·
4-26. Defining a Logical Parent to Physical Parent Path in a
Logical Data Base · · · · · · · · · · · · · · ·
. . . . . . . . . 4-27. Format of Concatenated Segment Returned to User I/O Area · · · · · · · · · · · · · · · · · ·
4-28. Unidirectional Logical Relationship · · · · · · · · · · ·
4-29. Physically Paired Bidirectional Logical Relationship···
4-30. Physically Paired logical Child Segments ·········
4-31. Virtually Paired Bidirectional Logical Relationship.
4-32. Pointers Used in Logical Relationships · · · · · · · · · ·
4-33. Replace Rules · · · · · · · · · · · · · · · · · · · ·
4-34. Definition of Crossing a Logical Relationship. · · · ··
4-35. 1he First Logical Relationship Crossed in a Hierarchic
Path of a Logical Data Base · · · · · · · · · · · · ·
4-36. Logical Data Base Hierarchy Enabled by Crossing the
First Logical Relationship················
4-37. Variations of a Concatenated Segment Type Enabled by
Specification of KEY and DATA Sensitivity · · · · · ·
4-38. Segment Types Associated with a Secondary Index · · ·
4-39. Indexing to NA!E Segments Based on the Color Field of
a Dependent · · · · · · · · · · · · · · · · · · · · ·
4-40. Secondary Data Structure·················
4-41. VSAM Logical Record and Index Pointer Segment Formats · ·
4-42. Variable Length Segments. · · · · ··
. .. .. .. 4-43. Variable Length Segment Formats · · · · · · · · · · · · ·
4-44. Segment Edi t/Com~ression. · · · · · · · · · · 4-45. HI SAM Data Base Record in Auxiliary Storage ·
4-46. HISAI! Data Ease Record -- Larger Primary Data Set
Logical Record. · · · · · · · · · · · · · · · · · · · ··
4-47. Storage Sequence of Segments in HISAM Data Base Record. ·
4-48. HISAM -- Multiple Data Set Groups (ISAM/OSAM only) ··
4-49. HISAI! Segment Storage -- Multiple Data Set Groups · · · ·
4-50. HISAI! Secondary Data Set Group with a Larger Primary
Data Set Logical Record Length ·······
4-51. HISAM -- Small logical Record Length. ·
· ···
4-52. HISAI! -- Large legical Record Length · · · · · · · ·
4-53. HISAM -- Utilizing Slack space. · · · · ·
· ·····
4-54. Data Base Record Segmentation Options ··········
4-55. HISAM Single Data Set Group Segmentation. · ·
· ···
4-56. HI SAM Multiple Data Set Group segmentation.
· ···
4-57. Data Base Structure Rules. · · · · · · · · ·
· ···
4-58. HISAI! Physical Storage -- ISAM. OSAM. or VSAM ··
4-59 .· HISAM Physical Storage Blocked One or Multiple· · · · · ·
. . 4-60. Data ,Structure Change -- New Segment Type Defined at End of Hierarchy. · · · · · · · · · · .. · · · ··
4-61. Data Structure Change -- New Segment Type Defined
wi thin Existing Hierarchy · · · · · · · · · · · · ·
4-62. Data Structure Change -- New Segment Type Defined
within a Leg of the Existing Hierarchy ··········
4.27 4.28
4.30
4.34 4.36
4.39
4.41 4.45 4.50 4.52
4.53
4.54
4.55 4.56 4.57 4.57 4.58 4.60 4.70 4.105
4.106
4.107
4.108 4.110
4.111 4.112 4.115 4.123 4.124 4.126 4. 129
4.130 4. 131 4.132 4.133
4.134 4.135 4.136 4. 136 4.137 4.138 4.139 4.140 4.141 4.142
4.143
4.143
4.144
xiv IMS/VS System/Application Design Guide
IL
-- 4-63. Data Base Structure Hierarchic Leg Independence. · · ·
4-64. Restructured Data Base. · · · · · · · · ·
·
-- · · · · · · · 4-65. Data Base Structure Absence of Segment Types ·
· · · · 4-66. Application Program I/O Work Area Size Considerations
4.145
4.145 4.146 4.146
4-67. Logical Record Length Distribution. · ·
· · · · · 5-1. Single DB/DC System Transaction Flow. · · · · · · · · · ·
5-2. Multiple DB/DC Systems Transaction Flow · · · · · ·
· · · 5-3. A Sample configuration of Three Systems · · · · · · · · · 5-4. Summary of Physical Link Types. · · · · · · · · · · · · · 5-5. Multiple Physical Links in One Systelll/370 CPU · · · · · ·
5-6. Multiple Physical Links in Multiple System/370 CPUs
· · · 5-7. Relationship of Physical Link to Logical Link to
. ,. Logical Link Path
·
·
·
· · · · · · · · · · · · 5-8. Input Terminal and Input System on Input. · · · · ·
· · · 5-9. Destination Terminal and Destina tion system on Output · ·
5-10. Input from and Output to Different Terminals.
· · · ·
· · 5-11. An Intermediate System.
· ·
· ·
'.· · · ·· ·· · ·· · · · .. 5-12. Horizontal partitioning · · · · ·
5-13. Vertical Parti tioning
·
· · · · ·
· · · · · 6-1. DEDB Structure Example. ·
·
·
·
·
· · · · · · · · · · · · 6-2. DEDB Area Division.
·
· ·
· · · · · · · · 6-3. · · · · · · 6-4.
DEDI! Units-of- Work. Storage of DEDB Dependent
· · Segments in an
· · Area
·
·· · ···
· · · 6-5. Control Interval Format
·
· · · · · · · · · · · 6-6. Root Segment Format {with Sequential and Direct
· · · · . · . · · · · · 6-7.
Dependent Segments) Sequential Dependent
segment
· Format
·
·
· ·
· · · · · · ·· ·· 6-8. Direct Dependent segment Format ·
·
4.156 5.1 5.2 5.3 5.4 5.4 5.5
5.6 5.8 5.8 5.8 5.9 5.17 5.18 6.5 6.6 6.6 6.7 6.10
6. 11 6.11 6. 12
Figures xv
L
NEW PROGRAMMING FACILITIES · Access to Fast Path and IMS/VS data bases is available from both Fast Path and IMS/VS application programs within the same transaction process. · A utility can be used for partial reorganization of HIDAM and HDAM data bases.
PROGRAMMING ENHANCEMENTS · Extended security support can be used with RACF or a user-written exit routine to provide sign-on processing for user verification to determine whether or not a user is authorized to use a transaction code. Data base change tracking by specifi= user is facilitated by log records containing user identification obtained from user verification. · Additional screen sizes and PF keys of the IBM 3270 Information
Display System are supported by Message Format Service (MFS).
· More flexible use of I/O resources is made in the allocation and dea1location of IMS/VS data bases and DC Monitor log data set (OS/VS MVS only). · The time required to restart an IMS/VS system is reduced.
Enhancements include restarting from the disk log, online log
termination, use of the dynamic log from shutdown for data base
backout at restart, and automatic restart.
NE~ PROGRAMMING FEATURE A Data Base surveyor utility is available as a separate feature. This utility scans the data base being analyzed and provides a report describing the physical organization and the location and size of free space.
SPECIFICATION CHANGES
· The m~n~mum logical record length for primary/secondary data set groups for HISAM data bases bas been lowered.
Summary of Amendments xvii
· An example of DEDS dasd space definition is included. · Sample minimum space calculations are provided. · Performance considerations are discussed.
A clarification of the Delete rules for both logical parents and physical parents has been included.
A section describing the IMS/VS sensitivity to specific characters when users attempt to send and receive nongraphic data in IMS/VS messages has been added.
SERVICE CHANGES
A clarification of the STAE/ESTAE rules is included.
NEW PROGRAMMING FEATURE
The Fast Path feature provides data base and data communication facilities for applications requiring high transaction rates but needing only simple data base structures. The Fast Path feature uses functions of the Data Communication feature and operates in existing telecommunication networks.
Fast Path provides two new types of data bases that are accessed with standard DL/I calls and, optionally, with Fast Path DL/I calls. The feature includes a message-handling facility to expedite the processing of Fast Path messages.
This publication has been revised to reflect technical and editorial changes made for Release '.2.
TECHNICAL CHANGES
The Multiple Systems Coupling feature allows a user to define a configuration consisting of up to 255 interconnected IMS/VS systems
running on any combination of as/vs l' and OS/VS2. Information on
channel-to-channel communication with the Multiple Systems Coupling feature is for planning purposes only until IMS/VS support for this facility become s available.
xviii IMS/VS System/Application Design Guide
lith the addition of Synchronous Data Link Control, 3270s can now be attached on SDLC lines as well as BSC lines.
The 3350 may now be specified for data base and message queue data set reside nee.
3767 Communication Terminal
371Q ~!t~-~2!!~n!~~tr2n-~i§!!!
The 3767 and 3770 are supported on an 5DLC link through VTAM. I"S;VS functional capabilities are included.
Full
EDITORIAL CHANGES
· The IM5/VS planning information about M5S (mass storage system), previously contained in ~g~£ ~~~ El~nn1n~ intQ~m~1hQn: I]~l!~, £I£~l!~, ~n~ ~I~L!~, is now contained in Chapter 2 of this publication. The former MSS publication .is now obsolete.
· The information previously contained in Chapter 1 of this publication has been moved to the I~~l!~ ~~D~!~l Int£rm~li~Q ~~n~~l.
· The information previously contained in Chapters 6 and 7 and Appendixes C and D of this publication has been moved to the I~~l!~
~I§!~! fr2~I~mm~n~ E~f~~~n£~ ~!n~~l·
· The information previously contained in Appendix A of this
publication has been moved to the l~~l!~ In§1~~~~li2n ~yi£!.
· The information previously contained in Appendix B of this publication has been moved to the I~~L!~ !~~li£~liQQ ~r~~~~~mhng
~~feI~D£~ ~~n~~l.
Summary of Amendments xix
This chapter addresses the factors to be considered by the user data processing organization in planning, scheduling and controlling the installation of the IMS/VS Data Base (DB) Syste~. Three major time phases should be considered:
· Pre-installation system design and configuration
· Installation
· System tuning and phased expansion
For each of these phases, this chapter suggests the steps to be taken, referencing the tools provided by the data base management services of IMS/VS to facilitate the effort, and identifying those elements of the user installation which are involved or affected.
The data base management services of IMS/VS are packaged as basic material in an orderable component called the Data Base (DB) system. The DB system supports the implementation of multiple user-written batch processing applications in a common data base environment.
The DB system provides the user with full IMS/VS facilities to:
· Define, load, and reorganize data bases
· Access a data base from application programs via a high-level
language interface called DL/I
· Support systems integrity via data base logging, checkpoint/restart, and data base recovery programs
· Use system-provided exits to incorporate user extensions to IMS/VS
· Migrate to a full IMS/VS DB/DC syste~ in a shared terminal
environment
The major execution-time elements of the IMS/VS DB system are the DL/I (Data Language/I) interface and the data base logging program. DL/I interfaces between the problem program and the data bases the program wishes to access. The use of DL/I and its functions are described in detail in the I~~l!~ !EE!!£~!!Qn ~£Q~£~!!!n~ E~I~£~n£~ ~~ng~!. The data base logging capability is one of the principal IMS/VS recovery features. It provides a log of all activity against a data base. The log enables a user to analyze and tune his system, and is the basic support for recovery, restart, and backout activity. The log is discussed later in this chapter.
In addition, several utility programs which assist in creation and
maintenance of the DB System are supplied. Included in this utility
program set are:
IMS/VS System Definition
IMS/VS Data Base Description Generation
Design and Installation of a DB System 1.1
185/V5 Program Specification Block Generation
185/V5 Application Control Blocks Creation and 8aintenance
1M5/VS Data Base Reorganization and Load
185/V5 Data Base Recovery
1MS/YS Utility Control Facility
System definition is described in the I~~L!~ !n§i~!!~i!en 2~!~!: the
other programs are described in the l~~LVS Yi!l!i!!§ R!t!~n~! ~~ng~!.
The DB system operates on an IB8 5ystem/370, using the services of OS/VS in its multiprogramming configurations OS/VS1 and OS/VS2.
In the IMS/VS DB system, applications are scheduled for execution through the OS/VS job stream in a process called batch scheduling. The basic unit of work is assumed to be the operating syst~m job step. The application itself can be either transaction-oriented or batch-oriented. A transaction-oriented program facilitates migration to a DB/DC environme"nt.
It is common system practice to implement the full DB/DC capabilities in a phased manner by installing a batch DB system first. Once an initial program/data base cluster has been designed and installed, users can see the step-wise expansion leading to a comprehensive on-line installation.
Figure 1-1 shows the relationship of OS/VS, the 18S/VS DB system, and an application program at execution time. The program and the DB system are contained in a single batch-processing problem program address space (region, memory). A second application program can occupy a second address space, with a replica of the DL/1 and data base logging functions, accessing a separate data base and writing a second log tape. Two or more 1MS/VS batch systems can run concurrently in separate address spaces, if they do not access the same data bases. Most of the 1MS/VS DB system is composed of reenterable code.
The user's application program operates as an OS/VS problem program. As illustrated in Figure 1-1, the application program has two basic interfaces. These are:
1. Transaction Input and Response Output
2. Data Base Input/Output Operations
Although this is a batch processing environment, the concept of transaction processing is advocated, because it can be carried over to the 1MS/VS message processing environment. Typically, transaction input and response output are performed with OS/VS data management. Within the application program, file descriptions and read/write statements are in COBOL, PL/I, or Assembler Language syntax. Alternatively, the user of IMS/VS can build an interface for transaction input and response output similar to the data base input/output interface described below.
1.2 IMS/VS system/Application Design Guide
J
OS!VS
APPLICATION PROGRAM
1+--+----i~RANSACTIONI
L-bLL
r-----------+------------- - --------,
i I
~ATABASESYSTEM
I I I
I I
,-
--
i-----.
I I
I
I
I
I
DATA
I
LANGUAGE/I
DATA BASE
I
I I
I
LOGGING
I
I
I
I
I
I
I
!
I
I
I
I
I
I
I
LI _______________________________ _
Figure 1-1. IM5/V5 Data Base System Environment
All data base operations are initiated by the application program interface with DL/I. This interface consists of execution of a CALL statement from the application program. Parameters in this CALL statement provide the information necessary to perform a data base operation on a specific data element or segment in a specific data base.
An application program can interface with one or more Dt/1 data bases. In addition, standard OS/VS data management can be used for any purpose
in the application program.
The arguments in the CALL statement issued by an application program allow DL/1 to determine which data base is to be used and which data segment in the data base is to be retrieved, inserted, replaced, or
deleted. From this information Dt/I performs a VSAM, 5AM, 15AM, or 05A~ input/output operation. If the desired data segment already exists
within the data base main storage buffers, no input/output operation is required.
When the data base operation consists of data segment insert,
replace, or delete, a record of the data base modification is written on
an I"5/V5 log for the batch processing address space. The content and
tL
format of logged information are described in a subsequent section of this chapter.
Design and Installation of a DB System 1.3
One significant concept of the data base inpat/output interface is that the format and content of all information used to establish the
interface are symbolic. None of this information is dependent upon a
specific data management access method or organization.
Before the DB system can be used for batch data base processing, it must be tailored to the user's data processing environment. This process of system tailoring is called system definition. The details of
IMS/VS system definition are provided in the Ia~l!~ In§1~l~~ii2n 2gi~~. For IMS/VS, the system definition function is similar, in concept, to
as/vs system generation.
as/vs OPTION CONSIDERATIONS
The DB system operates under OS/VS1 or OS/VS2. Very little difference is experienced by the 18S/VS user, whether VS1 or VS2 is used. The primary differences are attributable to the OS/VS option characteristics. Chapter 2 of this manual describes the considerations for operation under VS1 or V52. These are primarily concerned with main storage management and reliability/serviceability. The effects of VS1 versus VS2 are considerably greater with the I8S/VS DB/DC system.
Only one as/vs option defined during OS/VS system generation is a
requirement for the DB system. This is user SVC inclusion.
Other OS/VS options or features which are desirable, but not required, for IM5/VS are VSAM access method, ISAM access method, COBOL, and PL/I Optimizing Compiler.
The ASSEMBLER, an 1MS/VS requirement, is automatically incorporated in OS/VS. Alternatively, the Assembler H program product may be used.
18S/VS SYSTEM DEFINITION
During and after system definition and before DB system execution, several 1MS/VS library data sets mast be defined. These include control block libraries, load module libraries, and a procedure library. The
details of data set definition and allocation are defined in the I~~l!~ !n§i~ll~1~~n ~g~~~. Libraries which are of importance to the discussion in this chapter are:
IMSVS.RESLIB - the IMS/VS system load module library
IMSVS.PGMLIB - the user's application program library
1MSVS.DBDLIB -
the 18S/VS control block library containing data base descriptions (DBD). Each member describes the
logical structure of data and its physical storage in a data base.
IMSVS.PSBL1B -
the 18S/VS control library containing application
program specification blocks (P5~_ Each member contains a description of how its associated
application program uses one or more data bases.
1MSVS.ACBL1B -
the 185/VS library which contains control blocks required for a specific application program. This is a combination of the DBDs and PSBs in an internal format required by DL/I for data base system
execution.
1.4 ISS/VS System/Application Design Guide
IMSVS.PROCLIB - the IMS/VS procedure library containing IBM-supplied procedures.
L
IMSVS.MACLIB - the IMS/VS macro instruction library containing at least DBD generation and PSB generation macro
instructions.
~e!£i~! !££~§§ ~~~~~~ -- Q§!~
The Overflow Sequential Access Method (OSAK) is a special data management access method supplied with IMS/VS. It is used with some of the IMS/VS data base organizations. The functions which OSAM performs vary and depend upon the data base organization specified for a particular OSAM data set. These functions are described in a subsequent chapter of this manual. The other modules of IKS/VS interface with OSAK through OPEN, CLOSE, READ, and WRITE macro instructions similar to those provided for any OS/VS access method. OsAM modules interface with the os/vs input/output supervisor through the EXCPVR macro instruction in VS1 and SVS and through the I/O driver interface in MVS. As far as OS/VS is concerned, an OSAM data set is described as data set organization equals physical sequential (DSORG=PS). In fact, an OSAK data set can be read using BSAM or QSAM. The advantages of OSAM to IMS/VS relative to either BSAM or BDAM are:
1. An aSAM data set can occupy a maximum of 60 extents. If the data set resides on a Rotational Position Sensing (RPS) device and the number of records per track is greater than 1, the maximum number
of extents decreases. A data set requiring a maximum sector table allows for a maximum of 52 extents.
The Data Extent Block (DEB) for an OSAM data set contains '6
L
bytes of OSAM information for each extent. In addition, a sector table is built for RPS devices. The length of the sector table is 8 bytes plus one byte for each data set record, rounded to a
multiple of 8 bytes. A sector table exists for each unique
device type.
2. An OSA8 data set can be opened for update in place and extension to the end through one data control block (DCB). The phrase, extension to the end, means that records may be added to the end of the data set and that new direct access extents may be obtained.
3. An OSAM data set need not be formatted prior to use.
4. An OSAM data set can have fixed length blocked or unblocked record format.
5. Pile mark definition is always used to define the current end of the data set. The addition of a new block causes the file mark to be placed after the new block. This concept is used as a
reliability aid while the OSAM data set is open.
It should be remembered that other OS/VS access methods, VSAM, ISAM,
and SAM are used for physical storage of data elements in addition to OSAM.
OSAM data sets are restricted to a 31 bit addressing limit.
i~n~~li~~~ §~gg~q~!~l !££~§§ ~2~h~~ (i§!~)
The Generalized sequential Access Method (GSAM) provides accessing support for simple physical sequential data sets, such as tape files,
Design and Installation of a DB System 1.5
SISIN, SYSOOT, and others that are not hierarchical. These are data sets which, before GSA", could not be used as 18S/VS data sets.
Support provided includes sequential or direct retrieval by a record identifier which defines the relative position of that record.
Support is provided for both OS/VS Sequential Access Method (SAM) and OS/VS Virtual Storage Access Method {VSAM) for entry sequenced data sets (ESDS). GSAM is fully described in !~§L!§ A~~lic~~!2n ~2g'!na!ng tef~'~n~ ~~ng~l. The concepts of hierarchy and segment described in this manual do not apply to GSAM.
DATA BASE DESCRIPTION (DBD) GENERATION Subsequent to IMS/VS system definition, DBD generations can be
performed. A DBD must be provided for each data base to be used by an application program, prior to execution of the program. The !~~!~ Yt!1!1!~2 li~!~£~n£~ ~~ng~l describes the details of DBD generation.
DBD generation is the execution of IMS/VS macro instructions to create a description of a data base. This data base description includes a definition of:
· The data base organization and access method · Segment formats, whether fixed or variable · Whether the segments are subject to data compression routines · Inter-segment relationships · Field formats within segments · The existence of index relationships for any field · The relationships, if they exist, between segments in two or more
data bases Figure 1-2 illustrates the execution of a DBD generation. The IMS/V5 user creates control card statements that are presented to DBD generation as a normal OS/VS problem program job. The I"S/V5 macro instructions used for DBD generation exist in IM5VS.MACLIB. The result of a DBD generation execution is the placement of the compiled DBD into IMSVS.DBDLIB as a member of the partitioned data set. The members of the IMSVS.DBDLIB library can be used during the Data Base System execution. A job control language procedure, named DBDGEN, is placed in the IMSYS.PROCLIB data set by IMS/VS system definition for subsequent DBD generation execution. This procedure is described in the !~~L!~ ~I21~!
frQ~~!!~ng R~~~n~ ~~ng~!·
1.6 IKS/VS System/Application Design Guide
OSIVS
DBD GENERATION
Figure 1-2.
DBD Generation Execution
PROGRAM SPECIFICATION BLOCK (PSB) GENERATION
The third necessary function prior to execution in the DB system batch processing environment is PSB generation. Associated with any batch processing application program is a PSB control block. The PSB control block defines the data bases used by the application program. In addition, it defines the manner in which the data bases are used (that is, retrieval only, retrieval and update, or data base create) and the segments within each data base to which the application program is sensitive. It also defines which, if any, additional secondary indexes can be used to assist in segment selection.
PSB generation is the execution of IMS/VS macro instructions to define an application program's use of one or more data bases. The IMS/VS user creates control statements that are executed during PSB generation as a normal OS/VS job. The I~S/VS macro instructions used for PSB generation are in IMSVS.MACLIB. The result of PSB generation execution is the placement of the compiled PSB into IMSVS.PSBLIB as a member of the partitioned data set (Figure 1-3). The members of the IMSVS.PSBLIB data set are used during the Data Base's system execution. The !~§L!§ Ut!l!!!~§ R~I~£~n~~ ~angal describes the details of PSB generation.
A procedure, named PSBGEN, is placed in the IMSVS.PROCLIB data set by IMS/VS system definition for subsequent PSB generation execution. This procedure is described in the !tt§L!§ §I§~~m ~£2g£amm~ng R~f~~~n~~
~SlngSll·
Design and Installation of a DB System 1.7
OS!VS
PSB GENERATION
IMSVS.MACLIB
Figure 1-3. PSB Generation Execution
APPLICATION CONTROL BLOCKS (ACB) CREATION AND MAINTENANCE The fourth necessary function prior to execution of the data base
system, is ACB creation and/or maintenance. This function is optional in a DB system. It is required in a DB/DC system. Associated with all batch processing application programs are DL/I control blocks which define the data bases, structures, and methods to be used with a particular application.
The information in these blocks can be constructed in either of two ways: (1) at initialization time, the logical block builder module (DFSDLBLO) is called to construct the blocks from the PSBs and DBDs associated with the application program to be scheduled; or (2) the Application Control Blocks Creation and Maintenance utility program (DFSUACBO) is used to prebuild the control blocks for the application program. In this case, the necessary control blocks are loaded directly from the IMSVS.ACBLIB data set, saving processing overhead.
Application Control Blocks Creation and Maintenance requires no IMS/VS resources other than IMSVS.PSBLIB, IMSVS.DBDLIB, and 1MSV5.ACBLIB. The user supplies control statements which specify the operations to be performed. (See Figure 1-4., The ~~~L!~ ~!ili!i§§ li~!~£~ll~~~~ll!!.~! describes the details of ACB creation and maintenance.
A procedure, named ACBGEN, is placed in the 1MSVS.PROCLIB data set by IMS/VS system definition for subsequent ACB creation and/or maintenance.
This procedure is described in the I~~L!~ aY§!§! f£Qg£~!mi~g li§I§~§n~~
~!nl!!!l·
1.8 1MS/VS System/Application Design Guide
OS/VS
ACB
CONTROL
CARDS
DBD
LIBRARY
ACB
CREATION
AND
MAINTENANCE
PSB
LIBRARY
IMSVS. ACBLlB
Fig ure 1- ". ACB Creation andlor Maintenance
APPLICATION PROGRAM DESIGN
The final function performed prior to DB system execution is the creation of application programs. Application programs are required to create and maintain all user-defined data bases. These programs are written in Assembler Language, COBOL, or PL/I, and must be placed in the IMSVS.PGMLIB data set after compilation and link edit. 1MS/VS JCL procedures are available to the user for program compilation and link edit. These procedures are placed in the IMSVS.PROCLIB data set by 1KS/VS system definition. Each compiled application program must be link-edited vith modules that viII be called by the application program during execution. JCL procedures cause this link-edit to be performed. For details see chapter "The 1KS/VS Procedure Library" in the !~~L!~
~I§1!1 f[2g'!mml~g i!t!£!a~! ~!ng!l·
This section of the chapter describes batch processing in the DB system. Prior to execution, the functions of 1KS/VS system definition, DBD generation, PSB generation, and application program compilation, and optionally, ACB creation, are assumed to have been performed.
ESSENTIAL PROGRAM ELEMENTS FOR EXECUTION
Figure 1-5 illustrates the program elements necessary for batch execution. The IKS/VS control blocks are obtained from the IMSVS.ACBLIB (if prebuilt blocks are to be used) or are constructed dynamically at execution time from the PSBs and DBDs associated with the application program. The application program is obtained from the IMSVS.PGMLIB data set. The IMS/VS DB system modules are obtained from the IMSVS.RESLIB data set.
Design and Installation of a DB System 1.9
OSIVS
APPLICATION PROGRAM LANGUAGE INTERFACE
IMSVS.PGMLlB
IMSVS.DBDLIB
IMSIVS
DATA
SYSTEM t--+--I LANGUAGElI
lICr.ARY
IMSVS.RESLIB
DATA BASE LOGGING
IMSVS.PSBLIB
Figure 1-5. Essential Program Elements for Execution
As previously described, there is a PSB associated with the batch processing application program. The PSB is composed of one or more subordinate control blocks called data base program communication blocks (PCB). Each data base PCB specifies a data base or logical structure of data segments used by the application program. The PCB specifies the name of the DBD associated with the desired data base and the names of
segments within the data base to which the program is sensitive. Secondary indexes can be specified to aid in segment selection. Segments to which an application program is sensitive can be retrieved, updated, inserted, and deleted. Segments to which an application is not sensitive are never presented to the application program. The concept of segment sensitivity provides some degree of data independence. Additional constraints can be placed on the manner in which an application program is sensitive to a segment. Levels of sensitivity can be defined for each segment. The lowest level of sensitivity is segment retrieval only. The next level of sensitivity allows segment retrieval, update, insert, or delete.
Each data base PCB in the PSB associated with the application program to be executed defines a DBD by name. This means that one or more DBDs are required for any batch program execution. Each DBD defines the
organization and segment structure in its associated data base. The concept of a logical data base and associated DBD is defined in a subsequent chapter of this manual. If the DBD named in a data base PCB is associated with a logical data base, one or more additional DBDs are required to define the data base and identify the segments within the data base to which the program is sensitive.
1.10 IMS/VS System/Application Design Guide
J
J
Together, the P5Bs and DBDs are used to construct the I~5/V5 application control blocks. This aay be done dynamically or by a utility program which prebuilds the blocks. The I~2L!~ Y1ili1!~§ ~~t~~£~ ~!~~!i describes this process.
An application program to be executed in the batch processing DB system environment may be written in COBOL, PL/I, or Assembler Language. 1 subsequent chapter of this manual describes design considerations for an application program. The details of application program
implementation are provided in the I~~L!~ !22ii£~1iQ~ R£Qg£!mming
g~~~£~£~ ~n!!l·
The IM5/VS modules utilized in the DB system environment are obtained from the IMSV5.RESLIB data set. These modules are placed in that data set by the execution of IM5/VS system definition. The majority of the modules are involved with handling data base requests from the application program. These modules in turn utilize the data management access method modules of VSAM, I51M, OSIM, GS1M, and SAM.
The primary IM5/VS modules are: Data Base Retrieval ~odule Data Base Insert Module Data Base Delete/Replace Module Data Base VSAM Interface Module Data Base IS1M Simulator Module Data Base Hierarchical Direct space Management Module Data Base 15AM/OSAM Buffer Handler Module Data Base Buffer Handler Router ~odule Data Base Hierarchical Direct Index Maintenance Module GSAM Access Method Modules OSAM Access Method Modules Data Base Logging Modules
A later chapter of this manual describes the IMS/VS data base access methods. Each of these data base access methods uses either standard OS/VS data management access methods or 05AM for the physical storage of segments. The following illustrates the relationships.
Design and Installation of a DB System 1.11
DAI!_~!~E_l~~I~~_~EIHQQ
LOW LEVEL ACCESS METHOD
!!~ILlQILH!~!~!L_~!QB!2E
HSAM
OSA!! or BS1!!
HISAM
BISA8·0SA8, OISAK-OSA!!, or VS1!!
HDAM
OSA!! or VS1M
HIDAM
BISAM-OSAM, OISAK-OSAM, or VSAM
GSAM
BSA!! or VSA!! (ESDS only)
If sequential processing of an HSAM data base is defined, OSAM is used in support of HS1M. If nonsequential processing of an HS1M data base is requested, BSAM is used in support of HS1M. When a HISA" data base is created or reorganized, OISAK load mode and OSAM are used. When an existing HISA!! data base is used for retrieval, insert, update, and/or delete, OIS1! scan mode and OSAM are employed. If a PSB generation defines two or more data base PCBs which relate to the saae HISA! data base, BISAM read and write are used for HISA!! retrieval, update, delete, and/or insert. OSIM or VSAM is used for all data segment storage when the data base access met~od is HIDAM or HDAM. The use of ISAM (BISAM or QISAK) in an HIDAK data base is for index segment storage only. The use of BISA! or OISAK in support of the HIDA!! data base access method is equivalent to that described for RISA!!.
DATA BASE SYSTEK EXECUTION
Once the functions of IMS/VS system definition, DBD generation, PSB generation, and application program creation have been accomplished, execution of the Data Base system may be performed. The initial DB system execution presumably loads data into one or more of the data bases previously defined by DBD generation. (The load process is described in the !~~L!~ ~i~l~i~~2 ~~fe~~n~~ ~!n~!l.) Subsequent executions would perform retrieval, update, insert, and/or delete operations against existing data bases and/or create additional data bases.
When a batch processing execution of the DB system is initiated, the control blocks associated with the application program must be obtained and initialized. This control block initialization process is part of the batch processing job step execution but precedes the loading of the application program. The first step inVOlves obtaining the DL/I control blocks. If PARK=DBB was specified, the required control blocks are obtained from IKSVS.ACBLIB by the block loader module. If PARH=DLI was specified, the block builder module is called to construct blocks dynamically. In this case, IKSVS.PSBLIB and I!!SVS.DBDLIB are used to obtain the required PSBs and DBDs. Once the blocks have been obtained, the initialization routines load the required DL/I action modules, initialize STAE, and format the necessary storage areas in preparation for loading and giving the application program control. Figure 1-6 illustrates this initialization process.
1.12 IMS/VS System/Application Design Guide
OS/VS
PROGRAM ....
CONTROLLER ~
IMS/VS SYSTEM LIBRARY
APPLICATION
CONTROL BLOCKS
IMSVS.ACBLlB
-----.
·
BLOCK
LOADER
~
-
IMSVS.RESLI B
CONTROL BLOCKS
r---------- -------1--- - - -------- - -,
I
-"
DBD LIBRARY
... - - _. -
f4- - - -- -- BLOCK
BUILDER
~
PSB
-
LIBRARY
: IMSVS.DBDLIB
IMSVS.PSBLIB
L _____________________________________ ~
Figure 1-6. Initializing the Batch Data Base System, Step One
The IKS/VS module which controls the DB system environment is called the program controller. The primary functions of the program controller are:
· Initiate the IKS/VS DB system block building process by passing control to the IMS/VS control block building modules (Figure 1-6).
· Initiate the DB system DL/I and data base logging modules and pass control to the user's application program (Figure 1-6).
· Terminate the DB system execution by returning to OS/VS.
The EXEC statement provided as part of the OS/VS job control language for the DB system batch processing execution includes, within the values of its PARK= operand, the names of the PSB and the application program to be executed. Control is passed from the region controller (not shown in Figure 1-6) to the program controller, to the block loading and building modules. The nalle of the PSB is supplied. Using the PSB name, the required control blocks are obtained. If the first PARM= value is DBB, the required control blocks are loaded from the IMSVS.ACBLIB data set. If the first PARM: value is DLI, the named PSB is loaded from the IKSYS.PSBLIB data set and referenced DBDs are loaded from the IMSYS.DBDLIB data set. From the PSB and DBD control blocks, internal IMS/VS control blocks are built for subsequent input/output operations in the DB system environment.
After the control block construction is complete, control within the CS/YS address space is returned to the program controller. At this point the remainder of the DB system functions are initialized (Figure 1-7). This includes loading of the required DL/I data base modules, loading of the data base log modules, creation of a data base buffer pool, and loading of the required data management access method modules.
Design and Installation of a DB System 1.13
Depending upon the data base organizations and the manner in which each data base is used by the application program, only the necessary DL/I and access method modules are loaded.
Finally, the application program to be executed is obtained from the application program library, IMSVS.PGMLIB. Control is given to the application program.
<: ::>
IMSIVS SYSTEM LlBRARj
MSVS.RESLIB
OS/VS I
Y
PROGRAM CONTROLLER
I
I
r-------l
I
I
I I
·
, I
I
APPLICATION PROGRAM
I
I
· I
--. DATA
-
: DATA
I BASE
LANGUAGE/I. I LOGGING
I
-
..."'"
CONTROL BLOCKS
DATA BASE BUFFER POOL
f-.. _:::0
APPLI CATION PROGRAM LIBRARY
IMSVS.PGMLI B
Figure 1-1. Initializing the Batch Data Base System, Step Two
I8S/VS provides procedures for DB system batch processing execution. They are DLIBATCH, DBBBATCH, IMSPLIGO, and IMSCOBGO. They are placed in IMSV5.PROCL1B during IMS/VS system definition. These procedures are
described in detail in the I~§L!§ §I§!§m f~Qg~smm!ng E§f§~~n£§ ~~n~~l
and include the basic JCL for execution. The user must add DD statements for all data bases to be used. The content and format of these DD statements are described in the "DBD Generation Control Statements" section of the I~l!§' !!!!li.t.!~§ !i~f§r§n.£2 ~sn~sl.
~!ta ~s§~ §I§!~~ ~Qli!£~l §.2g~~£2 rl~~
Figure 1-8 illustrates the DB system control sequence flow once the application program has been given control. Upon entry to the application program, a parameter address list is provided. The addresses in this list provide visibility to each data base PCB in the PSB for the application program (see arrow 1). These data base PCB addresses are subsequently used by the application program when issuing data base input/output call requests.
1.14 1M5/VS system/Application Design Guide
OS
I
PSB
REGION
CONTROLLER
LINK
I i ..---"_,__.....:.__----. CD
I I
: I -t~ I I
APPLICATION
I--_ _ _PR_O_G_R_A_M_ _ _
(.;'\
: I r--~A-:;;~~~U~~E~--l
I I
I I
I L
_
_
_
_
_INT_E_RF_A_CE_
_
_
_
_
I
J
~ ~
RESPONSE
S
~ \~®-r-1--0-'---I-r---
.........
O\It}8t~DB§D§S§!J DATA II ~:~: I-CD_9-+--I'~B~:
'"
(j) I LANGUAGE/I
LOGGING
CHANGES
ACCESS METHOD 1+--1
I
1
®
DATA BASE BUFFER POOL
Figure 1-8. Data Base System Flow
Arrows 2 and 3 in Figure 1-8 indicate the transaction input and response output interface with the application program.
All application programs operating under IKS/VS have a language interface link-edited with the application program. The language interface accepts a data base call from the application program and passes control to the DL/I data base modules (arrow 4).
The purpose of the language interface is to provide a consistqnt format to DL/I for all data base call requests, independent of the programming language used to write the application program. The IKS/VS-supplied OS/VS procedures for compiling and link editing application programs are described in section "Procedure Library" in chapter "The IMS/VS Procedure Library" in !J1§l!§ §Iii~! f£2g,£~n!.!lg [~!~£~!l£~ ~!!l~!.. The link edit step for each of these procedures
Design and Installation of a DB System 1.15
provides for the inclusion of the language interface with the correctly compiled PL/I, COBOL, or Assembler Language application program.
The language interface function of IMS/VS is reenterable and is upwardly compatible with that of IKS/360 Version 2. To take advantage of the reenterable capability of the IMS/VS language interface, application modules from IKS/360 installations must be re-link-edited, replacing the IMS/360 language interface with the IMS/VS language interface.
After control is passed to the DL/1 modules for execution of the data base call request, the following functions are performed.
1. The parameters in the call request are checked for valid content. This checking involves the use of data base PCBs (arrow 5) and DBDs (arrow 6).
2. If the data base call involves segment retrieval, the information contained in control blocks and data base buffers is used to attempt to satisfy the request. If the request can be satisfied, the desired data segment is placed in the input/output work area of the application program provided in the data base call.
3. If the retrieval request cannot be satisfied with information already contained in the data base buffer pool, the appropriate data management access method modules are invoked (arrow 7), and the data management access method modules perform the necessary input requests to place necessary data in the data base buffer pool (arrow 8).
4. If the data base call request involves data segment update or deletion, the segment must first be retrieved (from either the buffer pool or secondary storage). Subsequently, the segment is deleted or updated (arrow 10).
5. If the data base call request involves data segment insertion, the segment is placed in the data base buffer pool and subsequently written to direct access storage (arrow 10).
6. When the data base call request involves segment insertion, updating, or deleting, a record of the data base modification is placed on an IMS/VS log for the batch address space (region) execution. This logical information can subsequently be used for data base recovery or reconstruction (arrow 9).
~!~! ~!~~ ~~tt~£!~~
IMS/VS maintains two data base buffering functions: one for VSAM data bases, and one for ISAM/OSAM data bases. 1 separate pool of buffers is allocated for each type of data base (VSAM and ISAM/OSAM) and the data management access methods (VSAM, ISAM, and OSAM) are directed to read into and write from these buffers.
The concept of the buffer pool is to allow blocks of data to remain in main storage as long as possible to avoid secondary storage reads and writes. Data in the buffer pool can be accessed and updated without I/O as long as there is no need to reuse the buffer space the data occupies. A use chain determines the order in which the buffers are used. Empty buffers are placed at the bottom of the use chain and are always available for reuse. As buffers are accessed, they are placed at the top of the use chain. When a retrieve request occurs, the buffer pool is searched using the use chain (for IS1M/OSAK a hash table is used to direct the search), to determine if the requested data is already in main storage. If the data is not found, the least recently used buffer
1.16 IMS/VS System/Application Design Guide
(bottom of the use chain) is selected, the old data is written out if it has been changed, and the requested data is read into the select~d buffer.
The size of the data base buffer pools can have a significant effect on the performance of the IMS/VS system. The size of the buffer pool is defined during DL/I initialization, based on control statements provided by the user (see the section "Defining the IKS/VS Buffer Pool" in the ~~~L!§ ~n§ial1~ii2n ~uid~). The size of the ISAK/OSAM buffer pool, for IKS batch jobs, can be defined by the BUF parameter on the EXEC statement for the job step or by buffer control statements.
At the beginning of each of the data base buffer pools, there exists a work area used by IKS/VS to record statistics on the activity in the pool. These statistics are of value to the IKS/VS user in determining the appropriate buffer pool size for a given application program. The DL/I statistics call (STAT) can be used to obtain these statistics in an application program (see the ~~~!~ !~~!i£~1i2n R£2~~~!!in~ ~~~~~~n£~ ~~nY~! for a description of the STAT call).
For additional information on buffering see the section "DL/I Data Base Buffering Facilities" in the ~~§L!§ ~I§I~m RI2~I~m!in~ B~~~I~n£~
~~nyal.
DATA BASE LOGGING
All modifications to any data base used in the DB system environment are recorded on the IMS/VS log tape for the address space. If multiple data base system executions are performed concurrently under OS/VS1 or VS2 a separate IMS/VS log tape is associated with each address space. Unless a data base is being used for retrieval purposes only in all address spaces accessing the data base, no attempt should be made to access the same data base from more than one OS/VS address space at any one time.
Data base logging provides the IMS/VS system user with a recording of all modifications to all data bases used during a data base execution. The log can be written with BSAM or OSAM. See "Chapter 2. Log Facili~y" in the ~~~L!§ §I§I~! f~2~~mming ~~~~£~n£2 Kang~! for performance improvement considerations using OSAK. An IKS/VS option, log-tape write-ahead, insures that log records are written before the data in the data base is changed. See the section "DL/I Data Base Buffering
Facilities" in the !H§L!2 2I§i~! f£2g£~!ming ~~~~£~n£~ ~~ng~! for
additional information on log-tape write-ahead. The IKS/VS log tapes can be used in conjunction with the IKS/VS Data Base recovery utility to rebuild a data base. The !~2L!2 ~1ilili~§ ~~~~~~n£~ H~ng~! provides details on the use of data base log information for recovery.
If no data base changes will be made or if no data base recovery utilities will be used, the logging function can be made inoperable by specifying DD DUMMY on the primary log DD statement {DD name IEFRDER). If dual system logs are used and the primary log is specified as DD DUMMY the secondary log is ignored and no logging is done.
If a data base is destroyed because of input/output errors, it can he restored with the following procedure ·
· Restore the data base with a previously dumped copy. The Data Base Recovery utilities can be used for this purpose. Refer to the
!H§L!§ n!i!i1i~2 R~f~£~~£~ ~~~~~! for detailed information.
Design and Installation of a DB System 1.17
· Apply all data base modifications made to the data base since the dumped copy was created. The IKS/VS Data Base Recovery utility programs provide this function.
· Repeat the current DB system processing from the beginning.
Not~: The above discussion of data base logging and recovery does not apply to the 8SA! organization. Since the old data is not destroyed when updating HS1M, logging and backout are not required to maintain data base integrity.
BATCH CHECKPOINT/RESTART
The batch checkpoint facility provides for synchronizing checkpoints.
The CHKP function call to DL/I allows the coordination of program activity with data base activity. Lacking any means to identify significant events in an application program, DL/I treats data base calls as one continuous string of related actions. When a CHKP call is issued, the program is indicating to DL/I that a sync point has been reached and the data base buffers should be written to secondary storage. For batch programs, a checkpoint record is also recorded on the log data set to indicate the sync point and set the maximum point to which the data base backout occurs if it becomes necessary.
In the batch environment, the duration of the job may be long and the number of data base changes may be large. If the job lasts for many hours then the time for reloading direct access data sets and rerunning, if necessary, may be excessive. Batch checkpoint/restart allows the user to take one or more sync points during execution. The sync point then determines the amount of time required to backout the data base if restart occurs. Backout is effected only back to a specified checkpoint record.
The action taken by the DB system for batch programs when a CHKP call is issued is as follows:
1. Altered data base buffers are written.
2. The checkpoint ID supplied in the CHKP call is written to the log tape.
3. If as checkpoint/restart is used, the checkpoint ID must be
unique for all checkpoints issued by this application program. If IMS/VS expanded checkpoint/restart facility is used, the checkpoint ID must be unique for all checkpoints in the IMS/VS system.
4. Message DFS681I, containing the checkpoint ID supplied, is sent by a WTO to the system console, and to the programmer.
5. Optionally, an OS/VS checkpoint of the user's region is taken. If the IMS/VS log access method is OSAK, the OS/VS checkpoint is not taken.
It is the user's responsibility to checkpoint any non-IKS/VS information or data sets (such as transaction/response data sets) with issuance of the CHKP call. This can be done with the OS/VS checkpoint/restart option in the DL/I CHKP call.
1.18 IMS/VS System/Application Design Guide
As an alternative to the OS/VS checkpoint/restart option, the user
can specify the I~S/VS extended checkpoint/restart facility. This
Il
consists of a restart call (function code XRST) and optional parameters on the CHKP call. If used, the xaST call is the first call to IMS/VS
issued by the user program. If a restart is not in progress, the xaST
call is effectively a Nap.
The issuance of an XRST call causes the following action to be taken for subsequent CHKP calls issued by the program:
1. Optionally, user specified areas, that is, application variables, control tables, and position information for non-IMS/VS data sets, are recorded on the IMS/VS log.
2. The fully qualified key of the last record processed by the program on each IMS/VS data base is recorded on the log.
3. The functions of the standard CHKP call are performed, except
that the OS/VS checkpoint of the user's region is not taken. The user has the option of using OS/VS Checkpoint/Restart, or the
IMS/VS restart (XRST call), or neither, but not both.
~~t£h ~~£~2Y1 Y1!l!11 f~2g.~m
A checkpoint ID can be supplied to the IMS/VS Batch Backout utility program through a control statement. The backout of data segments from the data base is done from the end of the log tape until the matching checkpoint record is encountered.
In the case of a batch program, the checkpoint/restart facility used can then be invoked to restart the program from that point.
The batch checkpoint facility is implemented by the use of the CHKP system service call from the application program. This call is used to indicate a sync point at which any data base updates can be restarted. The actual checkpointing of the batch program environment and the routine used to restart it are at the option of the user. The DL/I checkpoint program cannot issue the as CHKPT macro.
If the DL/I user chooses to write his own checkpoint/restart routines, he must:
· Record application variables and control tables.
· Record position information for non-IMS/VS data sets.
· Provide a restart entry point and reinitialization procedure.
· Initialize IMS/VS control blocks, for example, PXPARMS.
Use of the xaST call and user area parameters on the CHKP call simplifies the task for the user writing his own restart routines.
· A restart situation is indicated by specifying a checkpoint ID in the PARM field (on the EXEC statement in the JCL) or in the XRST call itself.
· Normal entry point and initialization procedures are used.
· User areas recorded at checkpoint time are restored.
Design and Installation of a DB System 1.19
· A GET UNIQUE is issued for each GSA! data base for the last used record, if the data base was open at the time the checkpoint vas taken.
· No data is returned as the result of the GU, but key feedback and status codes are saved in the user PCBs.
· If the data base was opened for output, then a PNT function code, requesting POINT, is used.
· GSAM data bases are automatically repositioned at restart if the XRST call is used.
· The checkpoint ID is returned to the user program to allow it to link to its own restart subroutine.
Batch programs that do not utilize the batch checkpoint facility should be reprogrammed to do so. Th~ major advantage comes from significantly shorter backout runs after failure, and the ability to terminate a long running job and restart it at a current point with very small backout preparation and minimal rerun time.
IMS/VS USE OF STAE/ESTAE
IMS/VS makes use of STAE/ESTAE routines in the control region, the dependent message (MPP,BMP,IFP) regions, and the DL/I batch regions. The control region STAE/ESTAE routines ensure that data base logging and various resource cleanup functions are completed. In the dependent message region, STAE/ESTAE is used to notify the control region of any abnormal termination of the application program and/or the dependent message region itself.
If an application program uses STAE/ESTAE, the following rules must be observed:
· Establish the STAE/ESTAE only once, before the first DL/I call.
It is not recommended that the application program use the RETRY option when exiting from the STAE/ESTAE routine but return a CONTINUE WITH TERMINATION indicator at the end of the STAE/ESTAE processing. If the STAE/ESTAE routine does exit specifying the RETRY option, the retry routine must ABEND with the original abend code. The original error data in the System Diagnostic Work Area (SDWA) may not be available for the IMS/YS exit routines if the RETRY option is selected.
· The PL/I STAE exit options do not include the CONTINUE WITH TERMINATION option. Applications written in PL/I must not use the PL/I STAE option.
The user STAE/ESTAE exit routine must not issne DL/! calls since the original abend may have been caused by a problem between the application program and IKS. This would result in a recursive abend with a potential loss of data base integrity or problems in taking a checkpoint.
Note: Programs that are CS/VS subtasks of an application program called by-IMS/VS must not issue DL/I calls. If they do, the results will be unpredictable.
'.20 IMS/VS System/Application Design Guide
IBM SYSTEM/310 POWER WARNING FEATURE SUPPORT
The IHS/VS Power Warning Log Terminator program supports the power warning feature on System/370 Models 158 and 168. This support enables the user to close the IMS/VS log from a dump data set without having to restore memory. The procedure used to accomplish this is described in the !~~L!~ QR~~!iQ~!§ R~I~£gn£~ ~2nY!1·
I"S/VS DB MONITOR
The IMS/VS DB monitor is a tool for collecting performance data to investigate specific application designs, data base designs, and resource allocations. It consists of a monitor module, and a Monitor Report Print program. When activated, it analyzes and records the internal activities of the IMS/YS DB system. The monitor report print program is processed offline to produce reports that summarize and categorize, at various levels of detail, the information recorded by the monitor module. The actions required to activate the monitor module are described in the I~~L!~ Q~~I!tQ~!§ R~I~~~n£~ ~2n~!1. The monitor report print program is described in the !~~L!~ Qtiliii~§ R~I~~~n£~ ~!n~!l.
The monitor module collects data from IMS/VS control blocks during operation of the batch system (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 and is activated and deactivated through the system console.
The following are recommendations for use of the DB monitor:
· Collecting data -- The DB Monitor enables an IMS/VS user to collect performance data to assist in analyzing an existing IMS/YS batch system. The amount of data collected and the analysis time to understand the report output suggest short traces during various time periods. Reports produced from profiles of a batch execution considered as normal can be used as a profile and compared with reports produced 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 characteristics, data set placement, and pool sizes.
· Testing application -- In the final testing of new or revised applications, the DB Monitor can be useful in validating the internal operation of the programs and data bases. For example, the programmer thought a specific DL/I call could be satisfied with a single 110 retrieval. yet the DL/I call report indicated a large data base scan as shown by many IWAITs. Investigation 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 application program.
L
Design and Installation of a DB System 1.21
This chapter concerns the decisions and planning that must precede the installation and use of the IMS/YS Data Base/Data Communication (DB/DC) system. Familiarity with Chapter 1 of this manual is assumed.
For the most part, the design and control considerations of a Data Base system, as discussed in chapter 1, are applicable to the combined DB/DC (Data Base/Data Communication) system discussed in this chapter. The fundamental differences in the data base oriented considerations, when viewed from within the combined DB/DC environment, have to do with multiplicity and interaction. In the Data Base system, for example, only one program and its associated program specification block are used at a time. In the DB/DC system, planning must consider that multiple programs and their associated control blocks may be in use at the same time. Fur"thermore, the interactive effects among those multiple programs and control blocks must be considered. This kind of r@lationship applies, as well, to other resources managed in the DB/DC system; such as data base buffers, data base control blocks, terminal buffers, and message processing regions.
The contents of this chapter provide guidance in:
· Selecting an OS/VS configuration
· Selecting an IMS/VS configuration
· Establishing a message scheduling algorithm
· Selecting and configuring a physical terminal network
· Establishing a logical terminal network
Regions are distinguished by the kind of processing performed within them. There are several kinds of regions: the I~S/VS control (CTL), Message Processing Program (~PP), Batch Message Processing (BMP), IMS/VS Fast Path Processing (IFP), and batch. Note the distinction between batch processing using a local control program, and batch processing through the online control program. The local use of the control program is batch processing, provided by the DB system of IMS/VS. The use of the online control program to support batch-oriented operations is called batch-message processing.
REGION TYPES
For the online environment the region types that are utilized are the Control, Messaga Processing, Batch Message Processing, and Fast Path regions. The major types of processing programs are: control, message, batch-message, and Fast Path.
the IMS/VS control program is normally started by using the OS/VS START command. It can also be started as a system task or as a job step using JCL.
Design and Control of a DB/DC System 2.1
The dependent regions are initiated by using the OS/VS START or the IMS/VS START REGION command. This results in JCL being read from a procedure library which initiates the dependent r~gion. The dependent regions can also be started as a job step using JCL.
The Message Processing Program (MPP) region is initiated by the OS/VS job management facilities. The MPP region can contain an application program for processing against data bases in the online manner.
The Batch Message Processing (BMP) region can contain an application program for processing against data bases in a batch processing 0p8ration. The application program in the batch region is scheduled by OS/VS job management, but may utilize DL/I for data base reference. An application program executed in a BMP region can access only IMS/VS and Fast Path data bases that are defined in the IMS/VS control region.
A BMP region, in addition to being able to process data bases used for message processing, has access to input message queues and can provide output the the message queues. Access to the input message queues is provided by specifying, in the JCL for a BMP region, a transaction code ~o which access is wanted. Access to the output message queues is provided by specifying output terminal PCBs in the PSB for the application program that executes in the BMP region.
When the data bases normally used for message processing are not being used for that purpose, they can be processing in a batch processing region as described in the chapter "Design, Installation, and Maintenance of the IMS/VS Data Base System." This can be done when the IMS/VS control program is not operating as an OS/VS job or the data bases are deallocated using the /DBR command (KVS only).
The IMS/VS Fast Path Processing (IFP) region executes as a dependent region of the IMS/VS control region only. The IFP regions are handled differently depending on the type of program that is running in this region. There are three uses for the regions in which Fast Path processing is done:
· Applications for processing Fast Path messages, termed
message-driven programs.
· Applications for processing input external to Fast Pa~h, termed
non-message-driven programs.
· Utilities processed against Fast Path data bases. Past Path application programs can retrieve from as veIl as update DL/I data bases.
The Data Language/I (DLI) region operates in a batch processing mode without accessing the message queues. DL/I calls that are directed to a specific PCB are passed to IMS/VS for processing. IMS/VS Batch applications have no access to Fast Path data bases. For more information on DL/I, see Chapter 1 in this publication.
There are other batch region types in addition to those mentioned above, namely Data Base Batch (DBB) and IKS/VS Utility (ULU).
2.2 IKS/VS System/Application Design Guide
OS/VS OPTIONS
The selection of an OS/VS configuration has some effect on the potential performance and reliability and availability characteristics of IMS/VS. Certain options are required by IMS/VS in all of the applicable configurations. The functional characteristics of IM5/V5, based on the use of these options, are identical regardless of the OS/VS configuration selected.
The IMS/VS DB/DC system runs under OS/VS1 and 05/V52.
I~~L!~ ~~2~~~~ ~2~Y~~ ~~~~2~~ r~~£tio~
as/Vs, IMS/VS, and application programs that will run in regions of
IMS/YS can be made permanently resident in virtual storage. This can significantly improve throughput and response time for frequently referenced transactions, if sufficient virtual storage is available with high performance paging DASD.
Programs can be made permanently resident in two ways:
1. In LINKPACK/RAM
a. These programs are shared among all regions, resulting in a saving of virtual storage space. Initial access can be slow because the region JOBPACK and STEPLIB/JOBLIB are searched
before LINKPACK is searched. Subsequent access can be at cpcr speeds, if the region JOBPACK has not been purged by as/vs
space management (this would be the case if sufficient virtual storage were not available to satisfy a user request for space). This can be altered by specifying SRCH=1 in the 1MS procedure. For more information on the 1MS procedure, see the chapter, flIMS/VS Procedure Library" in the I~~L!.~
~!§1~m f~Qg~~mm!~g Ri~i~iU£~ ~~ny~!·
b. These programs are made resident by the same method used for
as/vs and IMS/VS modules.
c. Application modules with names identical to PSBs ShOl1ld not be placed in OS/VS LINKPACK, since this causes a conflict during the ACB generation process.
2. In REGION/PARTITION
a. These program modules are used only for transactions serviced by the region involved, and only for the duration of that region.
b. Because these modules are in the region JOBPACK, they are invoked without repeating the overhead of searching STEPLIB/JOBL1B, L1NKPACK, and SY51.L1NKLIB. The overhead of fetching the module into virtual storage is encountered only at region initialization time.
c. They are made resident by invoking the I"5/V5 Program "odule Preload function via the step execution JCL parameter.
Design and Control of a DB/DC system 2.3
d. In addition to those modules automatically preload9d into the IMS/VS control region, other OS/VS and IlIS/VS modules can be made resident in the IMS/VS control region by using Module Preload.
e. Module Preload can also be used for modules resident in LINKPACK/RAM. Thus, although the modules are physically residing in LINKPACK (and are being shared among multiple regions), the overhead involved in searching program libraries and LINKPACK are only experienced at region initiation.
Serially reusable programs can be resident only in the region/partition. They are made resident by invoking the Module Preload function via the step execution JeL parameter.
The CS/VS task under which modules are preloaded varies based on the IMS/VS region type:
!~~L~ ~~g!~~ IIE2
Q~L!~ I!!.§.t
control (CTL) Message (MSG) Batch Message (BMP)
Batch (DLI) Fast Path (IFP)
Physical Log
Region Control
Region/Program Control
Region/Program Control
Region Control
If modules are preloaded into MPPs, the following performance considerations apply:
1. Preloaded applications are invoked via the BRANCH instruction;
this avoids os overhead.
2. Applications that are not preloaded and that have not been previously invoked are located by issuing the BLDL macro instruction; this reduces operating system overhead by avoiding a PDS directory search for the application modules in subsequent scheduling. The maximum number of BLDL entries in the BLDL list can be specified in the PARM field of the MSG region JCL. The entries are kept in the list on the basis of:
a. most recently referenced
b. most often referenced
3. All non-reentrant pre loaded modules are reloaded after each
abnormal termination.
4. If an abnormal termination with DUMP occurs, all preloaded
modules will be printed.
2.4 IMS/VS System/Application Design Guide
IKS/VS IN AN OS/VS SYSTEK
!!1§L!~_l~!m~§
rlSC
BSC connection
x
CTC connection
Main-storage-to-main-storage
connection
x
Fast Path
X
Data Base Surveyor
X
x
X
X
X
x
X
!!1§L!§'_R~g~Q~_!Y£~
OS/VS1
_!::!_-
OS/VS2 (SVS) OS/VS2 (MVS)
---_!::!_---- __!::!_§.!!f__
CONTROL
MESSAGE BATCH-MESSAGE
BATCH FAST PATH
X
X
X
X
X
X
X
X
X
X
X
X
X
X
* IMS/VS determines whether a batch region is swapped regardless of
whether the user specifies the region as being swappable. ToX IMS/VS, a batch region is swappabl~ if it has not log, and it is
not swappable if it has a log.
OS/VS OPTIONS REQUIRED OR RECOMMENDED FOR IMS/VS
Many of the OS/VS system generation macro instructions must specify certain options and values to support an IMS/VS DB/DC system.
Certain OS/VS options are not required by IMS/VS, but are recommended for various reasons. For a full discussion of the required or recommended options consult the !~2L!§' !n2t~!l~!~Q~ Q~i~~.
Nota that IMS/VS supplies a user type 2 SVC that is nucleus-resident. If the IMS/VS SVC is available at OS/VS system generation, it is convenient to incorporate it by using the RESMODS macro instruction.
SPECIAL ACCESS METHOD -- OSAM
The functions and operations of OSAM described for the Data Base system in chapter 1 of this publication also apply to the DB/DC system. The DB/DC system uses OSAM for message queue management. Further discussion of message queue management appears later in this chapter.
!!!Q£~~iQll Qt Q2!~ ~~1~ 2~12
The normal mode of OSAM data set allocation is through the use of the JCL at the time the data set is loaded. This can be for single or multiple volumes, and is done using the SPACE parameter. This is the recommended method.
If the installation control of direct access storage space and volumes is such that the OSAM data sets must be preallocated, or if it is decided that a message queue data set will require more than one volUme, the OSAM data sets may be preallocated.
Design and Control of a DB/DC System 2.5
Preallocation is done by any of the accepted methods, with the following restrictions:
· DCB parameters should not be specified·
· If the data set is to be expanded beyond the preallocated space, a secondary quantity must be specified during preallocation. Note that queue data sets will not be extended beyond their initial or pre-allocated space quantity.
When a !Yl!!El~=Y2!Ym~ data set is preallocated, the method of allocation should allocate extants on all of the volumes to be used, and guarantee that the end of the data set is correctly indicated in the DSCB on the last volume.
The suggested method is to use the IEFBR14 utility once for each
volume on which space is desired. ~2 n2! simply use IEFBR1q and specify
a DD card for a multi-volume data set. !his will put an extent on the first volume only and will not indicate that the volume is the last volume of the data set.
II0SAl'1ALLO
liS 1 EXEC
IISYSPRINT IIEXTENT1
II IIS2 EXEC IISYSPRINT IIEXTENT2
II
JOB A,OSAMEXAMPLE PGM=IEFBR14 DD SYSOUT=A DD VOL=SER=AAAAAA,SPACE=tCYL, (20,5»
DSN=OSAM.SPACE,DISP={,KEEP) PGM=IEFBR14
DD SYSOOT=A DD YOL=SER=BBBBBB, SPACE= (CYL, (30,5»
DSN=OSAM,SPACE,DISP=(,KEEP)
,UNIT=3330, ,UNIT=3J30,
IILAST EXEC PG8=IEFBR1Q
IISYSPRINT DD SYSOUT=A
IIEXTENTL DD YOL=SER=LLLLLL,SPACE=(CYL, (30,5»,UNIT=3330,
II
DSN=OSA8.SPACE,DISP=(,KEEP)
1. Secondary allocation must be specified for all volumes if the data set is to be extended beyond the initial allocation.
2. Secondary allocation is not allowed for queue data sets; they can have multi-volume allocation however.
3. If the OSAM data set must be cataloged, use IEHPROGM or Access Method services to ensure that all volumes are included in the catalog entry.
1. Do not preallocate more volumes for OSA8 data set extents than will
be used during the initial load or reload process. Doing so may cause performance problems during a later OPEN process since OSAM will not have a valid end-fo-file (EOF) mark in the last volumes DSCB. This will force OSAM to SCAN the entire data base in order to
find the true Eor mark. Since all extents of system data sets are
formatted at OPEN, the above caution does not apply to message queue data sets.
2.6 I8S/VS System/Application Design Guide
J J
If your (re)load process does not put the EOP mark on the last volume, you can add and delete dummy records to the end of the data set to force the EOF mark to the last volume.
2. Do not reuse molti-voluae OSA! data set extents without scratching and reallocating the space first. If this is not done, an invalid EOF mark may be left in the DSCB of the last volume of the data set, for instance after an unload/reload (reorganization). This will cause OSA8 to improperly open the data set after IKS/VS utilities have operated against the data set. fhis will result in an imbedded EOF mark somewhere in the middle of the data base. For instance, a data set may be allocated on three volumes, with the EOF mark on the third volume, but after reorganization, the data set may require only the first two volumes, and therefore the new EOF mark would be placed on the second volume. Since OSAK always checks the last volume's DSCB for an EOF mark during OPEN processing, normal processing would use the old EOP mark in the DSCB on the third volume. Subsequent segment inserts would go after the old EOF mark on the third volume. A later image copy will use the reorganization reload EOF mark on the second volu~e as true EOF indication since it processes the data set sequentially, thus, ignoring the new data on volume three.
Configuring the IMS/VS system for a particular user environment is accomplished through IKS/YS system definition. IKS/YS system definition consists of macro statements, the operands of which tailor the IKS/VS system for the user. The next several sections of this chapter discuss the design considerations in selecting various system definition options. You may wish to subsequently review this chapter with the
system definition details in the !A§l!§ !n!i~!!~ti2n 2gi[~.
CONTROL PROGRAM
f[2~~!!ing R~gi2n!
The specification of maximum processing regions places a limit upon processing capabilities that can be changed through redefinition or through specifying the PST parameter in the IKS procedure referenced above. The value assigned to the MAXREGN keyword of the IKSCTRL macro statement includes Fast Path, message, and batch message processing regions. The maximum number of regions specified influences the calculation of maximum I/O requests. The largest value that can be specified is 15.
The specification of active 1/0 requests is one of the system-related specifications that directly influences the performance potential of the DB/DC system. It governs the maximum number of I/O requests outstanding at any time. You must specify a value on the MAXIO keyword of the IMSCTRL statement that exceeds, by at least two, the maximum number of regions that can be executing concurrently. It is recommended that the value be one-half the sum of the number of communication lines, plus the number of concurrently operating processing regions. This number should reflect a prediction of maximum to average number of active communication lines. If the autopoll feature is used, it should be possible to reduce the assigned value without significantly affecting performance. The largest value that can be specified on the KAXIO keyword is 255.
Design and Control of a DB/DC System 2.1
£h~£~EQ!~i E£~~~~~
rhe selection of a checkpoint frequency should be influenced by anticipated message and data base processing activity, and the need for rapid restart. The frequency value chosen determines the number of log records that are written between automatic environment checkpoints. Whatever the value chosen, it is somewhat self-adjusting to system processing rates. That is, as more messages and data base update activities are processed, more log records are written. Hence, automatic checkpoints occur more frequently.
System queue space must be sufficient to support the requirements of the OS/VS control blocks necessary for the operation of an IMS/VS system. See "IrIS/VS Storage Estimates" in the !.!1aL!~ ~!.§.t~m fl:Qg!:!!!l!!l!n~ Refi~~~£~ .!1~~~~i for the information necessary to estimate the required syst~m queue space.
Main storage is obtained dynamically within the control region by the IMS/VS enqueue/dequeue routines. The maximum amount of main storage that these routines obtain, and the maximum that these routines keep on an internal free chain, are specified by the CORE keyword in the IMSCTF macro statement.
R£2~£!m !§'Qi!i!Q~
Under the program isolation concept, all activity (data base modifications and message creation) of an application program active in the DB/DC system is isolated from any other application program(s) active in the system until that application program commits, by reaching a synchronization point, that the data it has modified or created is valid.
This concept makes it possible to dynamically back out the activities of an application program that terminates abnormally, without affecting the integrity of the data bases controlled by IMS/VS. It does not affect the activity performed by the other application program(s) processing concurrently in the system.
with program isolation and the dynamic backout facility, it is possible to provide data base segment occurrence level control to application programs. A means is provided for resolving possible deadlock situations in a manner transparent to the application program. The deadlock situation is detected by an IMS/VS routine called Exclusive Control Enqueue/Dequeue. Upon detecting a deadlock situation, one of the application programs involved in the deadlock is abnormally terminated with a special abnormal termination code. The abnormal termination causes the activity of the terminated program to be dynamically backed out to a previous synchronization point. Its held resources are freed. This allows the other program(s) to process to completion. The special code causes the t~ansaction that was being processed to be saved. The application program is rescheduled. This process is transparent to application programs.
Performance is enhanced by allowing control of data base updates to be maintained dynamically, as opposed to establishing the control at message scheduling time. This dynamic maintenance is controlled by the DL/I action modules through the use of the IMS/VS Enqueue/Dequeue routine. During the scheduling process, an analysis is made of the
2.8 IMS/VS System/Application Design Guide
intent of an application program toward the data base it uses. If a conflict exists with the data base usage of a currently scheduled transaction, the scheduling process must select another transaction code and try again.
MESSAGE SCHEDULiNG
Within 165/V5 each input message type is declared through system definition. Message types are called "transaction codes" o~ "transactions." At the time a transaction code is declared, many optional attributes can be selected. These attributes, either directly or indirectly, affect the schedulability of a transaction. They can also affect the manner in which a physical terminal reacts to entry of a transaction type.
Application programs are declared in separate but related macro instructions. Hovever, the application program designated to process a particular transaction code is really just another transaction attribute. The process through which a completely received input transaction is united with its associated application program is called "message scheduling." The variable attributes associated with the transaction code, the number and relative importance of other transaction codes, the number of received but not processed messages, the intent of associated application programs toward the data to be processed, the amount of currently available space in control block storage pools and buffers -- these and other factors influence the process of message scheduling. The influencing factors are called the "message scheduling algorithm."
Through selection of options at system definition time, through the design and use of data bases, specification of buffer sizes, and, most directly, through the declaration and selection of transaction code-related options, the IMS/V5 system designer can influence the scheduling algorithm. Depending upon the breadth of his understanding of the algorithm, he can enhance the performance of the system by aanipulating the algorithm to meet his requirements·
The remainder of this section on message scheduli·ng considers the scheduling algorithm in these topics:
· Message class and region class
· Load balancing
· Selection priorities
· Processing limits
· Application program output limits
· Multiple and single segment messages
· Multiple and single message mode
· Response mode
· Non-update transaction processing
· Conversational attribute
· Data base processing intent
· Processing intent propagation
Design and Control of a DB/DC System 2.9
· Application program abnormal termination
· Contention for resources
· Control block baffers -- PSB and DKB
Each message (transaction code) is assigned a class at system definition time. This class assignment determines into which message region an application program is loaded. When the IKS/VS message regions are started, they are assigned from one to four message classes. When a message region is assigned more than one class, the scheduling algorithm treats the first class specified as the highest priority class, and each succeeding class as a lower priority class.
If more than one class is specified, the message selection process is handled as follows. The first class specified is scanned, in transaction priority sequence, for waiting messages. If there are no messages vaiting for the first class, the second and following classes are also scanned in priority sequence. If there are messages waiting in the first class, the highest priority message is selected for scheduling. If, for external reasons (for example, program or transaction stopped by master terminal operator), this message is not schedulable, the next message of equal or lower priority in that class, or the highest priority message in the next class, is selected for scheduling. If the highest priority message in the first class is not schedulable for internal reasons (data base intent or no more space in PSB pool or DMB pool to bring in needed blocks), the scheduling option of the transaction indicates the type of scheduling algorithm that is used. The scheduling option is specified at system definition by the TRANSACT macro. The options are:
1. Schedule only transaction. of equal or higher priority in the selected class.
2. Schedule higher priority transactions in the selected class.
3. Schedule any transaction in the selected class.
4. Skip to the next class and attempt to schedule the highest
priority transaction in that class.
Note that these scheduling options are specified for each transaction; therefore, each attempt to schedule a different transaction may change the algorithm, if the algorithms are different for transactions within the same class.
Message region class assignments and transaction class assignments can be modified at execution time to control message throughput.
If multiple message regions process the same message class and a data base processing intent conflict occurs, the highest priOrity transactions scheduled against a data base viII not necessarily be processed before processing lover priority transactions scheduled against the same data base. If you desire to process all higher priority transactions scheduled against a data base before processing any lower priority transactions, no processing limit should be specified for the higher priority transactions, or only one message region should process that message class.
2.10 IMS/VS System/Application Design Guide
&2!!.~ 1!!!.l!!.!!£i!lSl
Load balancing is the facility to schedule the same application program and the same transaction in multiple message regions. The application program and the transaction are designated for parallel scheduling at system definition time. The application must be designated as a parallel scheduled application before any transaction processed by that application will be scheduled in multiple regions.
When an 5MB is available to be scheduled but is already scheduled in another region, it is checked to determine whether it can be parallel scheduled. The PARMLIM value of the TRANSACT macro specifies the number of messages that should be enqueued before another region is scheduled. This value is multiplied by the number of regions already scheduled for this transaction. If the result is less than the number of messages enqueued, another region is scheduled for the transaction. If the region is unschedulable for internal reasons (data base intent), the next transaction within the class is scheduled. No cutoff priority will be set as the transaction is already scheduled within IMS/VS.
When more than one transaction of a given type is waiting to be scheduled, the specified transaction scheduling priority determines which transaction code is selected next. It does not determine which is actually scheduled. Only the tests of the transaction's readiness for scheduling, which occur after selection, determine if the transaction queue is allocated to an application program. The selection priorities are useful for influencing the response time to input transactions and for load balancing. Two priorities can be specified. One is called the "normal priority"; the other, "limit priority." Related to the normal and limit priorities is a "lim~t count." When the number of input messages of a specific transac~ion type waiting to be scheduled is equal to or greater than the limit count, the normal priority is reset to the limit priority value.
The priority of a transaction code causes it to b9 selected either before or after other transaction codes. If there are multiple transaction codes at the same priority, they are selected on a first-in/first-out basis. However, if there are multiple transaction codes at the same priority and the same class, with many messages already enqueued for each transaction code, the individual transaction codes will be selected on a first-in/first-out basis, but the different messages may not be selected in the same sequence in which they were entered. For example, A, B, and C are transaction codes with processing limit counts of 1. These codes are entered in the sequence ABCBACCAC. The sequence in which they are selected is ABCABCACC. An example of the typical use of selection priorities can be found under the topic "Message Scheduling" in the I~§L!§ ~Sl!!~t~! IIl~Qt!!!~!iQ!l ~~n!!~!.
Another effective way to utilize the selection priorities is to declare a normal priority value of zero. Zero priority is a null or "not eligible for scheduling" level. Messages accumulate until the processing limit cOllnt is reached; at this point the limit priority is effected and scheduling occurs. This technique is called "hatching messages. "
The normal priority is not restored until all messages enqueued on the transaction code have been processed. It is possible that more messages will be added to the queue while the transaction is waiting or in process at the limit priority. Note that the priorities are selection priorities, not execution priorities. Once a transaction has been selected for scheduling, the selection priorities have no influence until it is again recognized to be waiting for scheduling.
Design and Control of a DB/DC System 2.11
The effectiveness of the selection priority assignments is related to how frequently the selection process occurs. The following section discusses a means of influencing this.
Through the establishment of processing limits, the frequency with which scheduling selection occurs can be influenced. In the time between schedulings, processing is going on in the message regions. Meanwhile, messages are accumulating in the message queues. As they accumulate, the interactive effects introduced by new message types, and the changing of selection priorities, are rearranging the ord~r of waiting transaction codes. Conceivably, while a large queue of messages is being processed, i.portant activity assigned to a high priority transaction code is waiting.
When the program processes a large queue of messages and updates data base segments, other application programs wish~ng to access an updated segment are placed into a wait state. The length of time that the other applicatioa programs have to wait depends on whether the updating program is processing its queue in multiple or single message mode.
To allow controlled re-entry to the message scheduling selection process, a processing limit count can be specified for each transaction code. Each time a scheduled (processing) program requests a new message, the limit count is checked. When the number of requests exceeds the limit count, the applic~tion program is told by the control program that there are no more messages. In fact, there may be more. When the application program is told there are no more messages, it completes its processing and returns the transaction queue to its proper place among others waiting to be scheduled. If it is returned to a priority level where other transaction codes are waiting, it assumes an eligibility for selection below tftem, even though all have the same numeric priority.
By establishing program output limits during system definition, the IMS/V5 user can influence the number and the size of the output segments from the application program to the message queues. When an application program exceeds the previously-specified limits, a status code is returned indicating an error. Any further attempt by the application program to e~ceed the limits results in abnormal termination.
Abnormal terminations can be prevented by checking the number and the size of application program segments. This process of checking eliminates IKS/VS system abnormal terminations that occur when application programs loop while inserting messages or segments into the message queues, or when they inadvertently insert segments of invalid lengths.
A message, in the most general sense, is a finite sequence of transmitted symbols. In the context of IKS/V5, this is called a transmission. A transmission is terminated by a logical condition called end-of-data {EOD). The transmission is partitioned into sequences of symbols, called messages, by an end-of-message (EOK) symbol.
2.12 IMS/VS System/Application Design Guide
J
A message is partitioned into smaller sequences of symbols, called segments, by an end-of-segment (EOS) symbol. There are only three valid
combinations of the conditions represented by EOS, EO~, and EOD. They are:
EOS
EOS
EOM
EOS/EO!!
EOD
EOS/EOM/EO])
In the most complex case, a transmission containing several multisegment and single segment messages would look like this:
----- ---S-E-G-!>-1-E-N-T------S-EG-l-Y-IE-t-~-T-
SEGMENT
SEG~1ENT
MESSAGE
MESSAGE
MESSAGE
TRANSMISSION
Using the simple symbols, the same transmission would be represented like this:
SEGMENT
SEGMENT
SEG~1ENT
SEGHENT
SEGMENT
MESSAGE
MESSAGE
TRANSMISSION
The assignment of values to the symbols that represent the conditions
end-of-transmission, message, and segment is not significant to this
discussion. However, it is significant that the conditions can be represented by more than one transmitted data character. Most
key-driven terminals generate only one character per keystroke. Thus, it may be necessary for the terminal operator to perform more than one
manual operation to signify EOS or EOM.
For input transmission, detection of the EOM condition by !MS/VS indicates that a complete message has been received. A complete message is eligible for scheduling, and ultimately processing, by the application program to which it is destined.
At the time the first EOS condition, or the first EOS following an
EOM, is detected, IKS/VS examines the text of the preceding segment.
Within the extent of the segment there must appear a valid transaction
code, predefined through use of the TRANSACT macro instruction. One of
L
the attributes that can be assigned to a transaction code specifies whether a message is multiple or single segment. The effect of this specification is null if multiple segment specification is selected. If
Design and Control of a DB/DC System 2.13
single segment specification is selected, the system equates the EOS condition to an EOM condition. Thus, each segment is treated as a complete message.
The primary concerns when selecting the multiple or single segment attribute are human factors, application requirements, and physical terminal characteriatics. For example, let us assume the following:
· An application requires only single segment entry.
· Most users enter data from a key-driven terminal.
· The terminal has an automatic character generation feature (EOS
after pressing carriage return).
Then, the selection of multiple segment as an attribute of a transaction code would require an additional keystroke to signify EOM or EOD.
Another example: assume all of the preceding conditions are true except that the line length of the data to be entered exceeds the single-line capacity of the terminal. The appropriate and more natural selection is multiple line. However, if the application were one with very high usage, the overhead of processing multiple line messages might be sufficient to justify adjustment of the short message buffer length. The operational characteristics of transaction entry would be altered. Using the same terminal with the special EOS generation feature disabled, the operator enters the first line, presses the carriage return, enters the remaining data on the second line, then presses the BOS key. The result is a single segment message.
When the Message Format Service (MFS) is used to forllat input, the relationship between the segments described above and the actual message segment created by !'IPS is user-defined.
When MFS is used to edit input, the end of input for a given message is signalled by:
· EOM or EOD · Completion of processing for all defined DFLDs
At the end of input for a message, !'IFS presents the completed message segments to the DC component of IMS/VS; this component looks for a destination name. If the destination is a transaction defined as a single segment and more than one segment has been created by MFS, an error message is sent to the input terminal.
For more information on MFS, see the section in this chapter called "Message Format Service."
Consult the ~~~L!~ QE~£~tQt~§ R~1~t~U£~ ~~n!~! for more information about the various terminals supported by IMS/VS.
MULTIPLE AND SINGLE MESSAGE MODE
The message mode attribute of a transaction code is used to notify the system of the manner in which an application program views the transactions it processes. Single mode indicates that each message is processed independently of all other messages that are read. Multiple mode indicates that all the messages of this transaction code, read during a given scheduling of the application program, are to be considered as related to one another. For example, the application program accumulates control totals that are written out only at program termination. It does not affect the message selection criteria of the
2. 14 I~S/VS System/Application Design Guide
scheduling algorithm. It does, however, affect the amount of main storage required by program isolation, message processing throughput, and, potentially, the integrity of the data bases used by user programs. If multiple mode is selected, there is potential for greater throughput. Kultiple mode results in fewer system-generated I/O operations, and less system time per message, when more than one message is processed per application program scheduling. However, all data base resources modified in any way by the user remain enqueued until user program termination.
If more than one message is processed per scheduling of a user program, large storage requirements for IMS/VS program isolation could result. If program isolation enqueue chains become very long, throughput is adversely affected. Also, if a program must be terminated and rolled back by IMS/VS to break a data base deadlock situation, the bacxout and reprocess time is increased in proportion to the number of messages processed. In addition, very long backout chains in the Dynamic Log may require extra I/O operations and increase the possibility of exceeding the capacity of the data set. If this happens, application activity is quiesced.
Internally, the difference in single and multiple mode transaction processing is related to the frequency at which pending data base buffers are written. In single mode, all pending data base buffers are written each time a new message is requested by the application program. These operations are performed regardless of the value assigned as a p=ocessing limit count. Multiple mode defers buffer write until the application program terminates, unless a CHKP call was issued by the application program. A CHKP call causes all buffers mo~ified by the user to be written at the time the call is issued.
An additional consideration is imposed for program isolation. When the transaction code causes data base updates. the enqueu@. of the updated segments is held until the point at which the program can be restarted without having to reprocess those updates. In single mode, this point is reached each time a new message is requested by the application program. Multiple mode defers reaching this point until the application program terminates. This causes more segments to be enqueued, and the enqueued segments to be held longer. Other programs needing access to the enqueued segments are delayed, and the chance of deadlock is increased. Since message response is also held, and not sent to its destination until the same point is r~ached, the choice of multiple mode processing can significantly increase terminal response time. For information on the use of the checkpoint call (CHKP) in conjunction with multiple mode processing, see the I~~L!~ !2E!i£~tiQn
~~Q~~mmin~ B~t~~~n£~ H~nY~!·
Response mode describes a connection between IMS/VS and a communication line or terminal that can occur only for certain terminal types under condition specified during IMS/VS system definition. When response mode is in effect, IMS/VS will not accept any input from the communication line or terminal until it has sent the output response to the previous input.
Response mode is in effect from the time the last segment of a transaction has been received by IMS/VS until the application program inserts a response to the response PCB, which is usually the I/O PCB. When more than one message is inserted using the response PCB, response mode is reset when the first message using the response PCB is transmitted. Any remaining messages issued by the application program are treated as non-response application program output. If the application program does not produce a response, the terminal remains in
Design and Control of a DB/DC System 2.15
response mode and master terminal intervention is required to restore proper terminal operation.
The terminal types that can be defined (TERMINAL or TYPE macro) to operate in response mode are the: 1050, 2740, 2741, CPT-TWX, 3270, 3600, 3767, 3770, and 37"90. The 3790 is forced to operate in response mode. The others may be defined as: "forced" -- always operating in response mode, "negated" -- never operating in response mode or "transaction dependent" -- operating in response mode only when a transaction defined by the TRANSACT macro as a response mode transaction is entered.
Response mode for the 1050, 2740, 2141, and CPT-TWX terminals stops all operations on the communication line and is referred to specifically as "line response mode." Response mode for the 3270, 3600, 3767, and 3790 stops all operations on the terminal and is referred to specifically as "terminal response mode."
The specification of terminal response mode and no automatic page delete (NPGDEL) is not recommended for the following reasons:
· NPGDEL causes the current output message not to be dequeued at the time of input.
· Terminal response mode causes input to be inhibited until the
current output message has been dequeued.
The combination of these specifications may reqaire master terminal intervention to reset the terminal response mode.
Q~§~~n £Qn§~~~£a1iQn§: Before response mode definitions are specified for terminals and transaction codes, consider the following:
· On a switched line, response mode enforces synchronization terminal o p e r a t i o n .·
· In response mode, terminal operators can only enter one transaction at a time and must wait for a reply before entering another transaction.
· For a terminal defined as "transaction dependent," transaction that
are n21 defined as response mode transactions permit entry of
additional input without waiting for a reply from the previous transaction.
· Master terminal intervention is required when an application program fails to respond to a transaction from a terminal in reponse mode.
· In some environments, specifying "forced" response mode for some terminal types may result in fewer line operations and improved performance.
· For some terminal types (2140 without Station Control Feature, 2141, and CPT-TWX), a specification of response mode prevents the operator from having to enter a null message to receive the response to the last input.
For BTAM or VTAM terminals don't use the following sp~cifications:
· The combined specification of FORCRESP and NPGDEL.
· The combined specification of TRANRESP and NPGDEL if
MSGTYPE=RESPONSE is specified for the TRANSACT macro.
The first specification is not recommended because NPGDEL prevents the current output message from being dequeued at the time of input; the
2.16 IMS/VS System/Application Design Guide
second specification prevents the terminal response from b~ing r~set until the current output message is dequeued.
Further information on terminal operations using response mode is contained in !~~l!~ Q£~~!~2£~§ Ei'~~!n£~ ~!UY!l, and !~~l!~ !u§1!11at12U 2Ylde.
For 3600 and 3790 support, see the section "Terminal Response Kode" in the chapter "IMS/VS Support for AFC Systems" in the !~~l!~ !g!!n£~g [~n£112U '2£ ~ommunic!il2U manual. For SLU typ~ P support, se~ the section "Terminal Response Mode" in the chapter "Type P Secondary Logical Unit Programmer's Guide" in the same manual. For KFS support, see the section "Type, Terminal, and Config Macros" in the chapter "IKS/VS System Definition Considerations" in the !~L!~_~§§!g~_I2£m!1
~itvi£i_~~~~§_2Yl~i·
A transaction code which does not cause an update to a data base can be so defined to the system. This allows a program that handles multiple transaction codes, and only updates the data base for a subset of these transactions, to be scheduled concurrently with other update programs when it is to process a transaction that does not cause an update.
Transactions must be defined as non-update transactions when ent~red from non-error-check~d terminals supported by IMS/VS. They are also non-update for entry by switched terminals that are signed on for INQUIRY purposes.
When a transaction is defined as non-update, the associat~d application program is prevented from updating the data base. This is the case even though the processing option in the PSB specifi~s update capability.
Scratch pad areas {SPAs) are work areas through which an application program and a terminal establish a quasi-interactive relationship called
a conversation. That is, continuity is established with the terminal
operator, by the application, across multiple message entry and response
sequences. The conversation can be suspended, reinstated, or terminated, by the terminal operator, through the command language. A conversation is normally terminated by the application, not the terminal
operator.
The system maintains scratch pad areas on a direct access data set or in main storage. Rasidency is specifiable by transaction code. The choice of main storage or direct access residency influences the response time for transactions that have the conversational attribute.
Although the system can operate with one maximum size main storage SPA, or one direct access SPA, then only one conversation can be in process at a time. If a high percentage of transaction processing is
conversational, a similar number of SPAs should be specified in the system definition SPAREA macro statement. If a conversational transaction code is entered, and all SPAs are in use, that transaction
is rejected by the system. An insufficient number of available SPAs could result in terminal user dissatisfaction.
If a transaction code has the conversational attribute, it can have
L
effects on overall system performance. The choice of main storage versus direct access residency affects not only system performance, but
Design and Control of a DB/DC System 2.11
also the response characteristics of the conversational transaction. The following discussion elaborates on the potential effects of buffer fragmentation and the relative throughput and response characteristics of conversational transactions.
Main storage resident SPAs, and read/write ~pace for direct access resident SPAs, are acquired from the Communication Work Area (CWAP) buffer pool when a conversation is initiated by entry of a conversational transaction code. Main storage is retained throughout subsequent exchanges between the terminal and destination applications. It is released upon termination of the conversation. Since the main storage SPA buffer space is retained over a relatively long period of time, its potential ability to fragment the buffer pool is relatively high. Fragmentation of the CWAP buffer pool can cause processing delays in terminal I/O service and in tha initiation of other conversations. However, since the SPA is both main storage resident and dedicated for the life of the conversation, response and throughput are significantly improved. The size of the CWAP buffer pool is specified during system definition with the GENERAL keyword of the BUFPOOLS macro. For more information on the BUFPOOLS macro GENERAL keyword parameter, see the
section IIDefining IMS/VS Buffer Pools" in the J.l!~L!~ I!!§1~1!a!iQ!l 2y.igg.
If the SPA is on direct access, space is initially acquired from the buffer pool at the same time as for a main storage resident SPA. However, it is retained only long enough to write to direct access. SPA buffer space is freed. Space is re-acquired when the application program returns the SPA, and is freed as soon as the SPA is rewritten to a direct access device. The use of direct access SPAs decreases the possibility of extended delays introduced by buffer fragmentation. However, because buffer requests are made during the time an application is active in the message processing region, any delay due to lack of buffer space directly affects throughput. In addition, since the application must wait for the SPA to be written out, overall processing time. for each transaction is increased and response time extended.
To enhance performance for conversational processing, conversational transactions can be defined with fixed-length SPAs. For such transactions, the main storage SPA uses only the fixed length that was defined. For direct access resident SPAs, the defined maximum length is always used, however, performance is increased on program-to-program switches because the direct access SPA is not updated.
Fixed-length SPAs (l.efilled during conversation initialization must remain in effect for the duration of that conversation. For conversations whose first transaction code defined fixed-length SPAs, all successive transactions used as destination applications in the same conversation must also be defined with fixed-length SPAs of the same length. If not, a status code indicating an error is sent to the calling application. If the Multiple Systems Coupling feature is used and conversations will run in a system that is not the input terminal system, fixed length SPAs must be used. For more information about the Multiple Systems Coupling feature, see Chapter 5 of this publication.
An additional performance enhancement for conversational processing is the automatic compaction of all SPAs for queuing and logging. All blanks and X'OO's are eliminated for queuing and logging, and the application program receives the unpacked SPA.
A factor that can significantly increase the overhead of the ~aheduling process is the intent of an application toward the data bases it uses. Intent is determined by examining the intent list associated with the PSB to be scheduled. At initial selection, this process
2. f8 IMS/VS System/Application Design Guide
involves bringing the intent list into the control region. Th~ location of the intent list is maintained in the PSB directory. If the analysis of the intent list indicat~s a conflict in data base usage with a currently scheduled transaction, the scheduling process must select another transaction code and try again.
There are several intent levels that can be stated for a given segment type. The list below shows the level of intent, how it may be stated for the PSB Generation utility prograll, and the a.ode that is used in the decision tables that follow:
N = No sensitivity -- segment type not referenced.
R = Express read-only -- segment type referenced -- PROCOPT=GO.
Note: See "Processing Intent Specifications" in this chapter for an explanation of the various processing o~tions (PROCOPTs,.
G = Retrieve segment type referenced -- PROCOPT=G or ~.
U = Update -- segment type referenced -- PROCOPT=A, I, R, or D
or segment type has propagated intent.
E = Exclusive use -- segment type referenced -- PROCOPT=E.
If exclusive use is specified for a program, that program will not be scheduled concurrently with any other program that is sensitive to the same segment types.
The following decision table shows which programs can be scheduled concurrently.
, r---I-n-t-e-n--t -o--f--C-u-r-r-e-n-t-ly--------,I
Executing Program
!
r---I-n-t-e-n--t-o--f--P-ro-g-r-a-m---- ------1------1------I-------I----1I
I Being Scheduled
E 1UI G1R1N!
1----------------------- -----1-----1-----1-----1-----1
I
E
xI X I XI Xl
,
1
1
,
1
I
1
1'---O -------------X ------- -----1I -----',-----1,-----11-----',
1
1
1
I
I
,
1----------------------- -----1-----'-----1-----1-----'
1
G
X,
1
I
,
1
I
!
,
1
1
11-----------R------------ ---X--11-----1I-----11-----',-----11
1
,
1
1
1
,
!
1-----------------------1-----1-----1-----1-----1-----I
I
NIl
I'
I
I
,
,
I'
1
.. ~---------------------------- --.~------.------------~
X Indicates conflicting Actions When Transaction Scheduling Is Attempted
Since exclusive intent does not allow a program to be scheduled while programs sensitive to those segments are operating, no dynamic serialization is done vi~ the enqueue/dequeue facility.
Design and Control of a DB/DC System 2.19
Conflicting actions occur only if the same segment type i~ declared "Exclusive Use" by at least one of two programs intending to reference the segment type.
A PSB that contains a PCB 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 SHISAM deletes. Since there is no delete flag, a VSA~ erase must be done to delete the segment, and since IMS/VS uses relative byte addresses as the identification of a segment, there is no way to prevent another user from inserting a segment with the same key prior to the time the program which did the delete reaches a sync point.
A PSB that contains a PCB for an HSAM data base will always be scheduled exclusively against these data hase segment types. Unless the PSB for the program being scheduled is currently resident in the PSB buffer pool, determining schedulability involves a direct access I/O operation.
Exclusive intent may be required for long running BMP programs that do not issue checkpoint call because of the excessively large size of the enqueue/dequeue table.
An exception to the use of the enqueue/dequeue facility to provide program isolation is accomplished by the use of the PROCOPT=GO option; this allows programs to access segments without an enqueue being done for those segments. When this occurs, a program can retrieve segments which have been altered or modified by programs which are still active and while the changes are subject to being backed out. See the ~~L!~ ~!ili!i~~ R~t~£~a£~ A~nY~l for a detailed explanation of the PROCO~T=GO option.
f£Q£~~ing In!gn! ~2g£it!£~!iQn~
With Program Isolation, the only processing intent that affects the schedulability of IMS/YS programs is exclusive intent.
The processing option parameter (PROCOPT) of the PCB and SENSEG statements of a PSB generation determines the processing intent an application program has on data. The scheduling options are:
G = Get function.
I = Insert function.
R = Replace function.
D = Delete function.
A = All, includes the previous four functions.
E = Used in conjunction with the previous five functions, and specifies that an application program has exclusive use of the data base or segment specified.
K = Indicates key sensitivity only.
~£h~d~ling In!2n! IIe~2: There are three scheduling intents used to
determine the schedulability of an application program: read only, update, and exclusive intent. If a segment has more than one intent type as the result of multiple references or intent propagation, the most restrictive use is set. Intent types are associated with the aforementioned processing intent specifications in the following manner:
2.20 IMS/VS System/Application Design Guide
· Read Only Intent
For schedulability without Program Isolation (PI) operative, read only intent allows the program to be scheduled with any other number of read only users and one update intent program. This intent is set for any segment that sp~cifiad PROCOPT=G or P~OCOPT=K on the associated SENSEG statement. In addition, this intent is propagated to all segments that are required to obtain the information necessary to satisfy a DL/I call. Fer example, a logical child seg~ent is requested in a call, and the logical parent's key was specified as "VIRTUAL." All segments that must be retrieved to construct the logical parent's concatenated key have read only intent set. The extent of propagation is discussed below.
· Update Intent
When PI is operative, update intent is treated as read only intent for scheduling purposes.
When PI is inoperative, update intent allows any number of programs that reference the same segment types for read only to be scheduled with the updating program. All programs that reference the same segment type for update intent must be scheduled serially.
This intent is set if the associated SENSEG statement specified PROCOPT=I, R, or D. Update intent is set for the associated segment regardless of any key sensitivity specification, either explicitly or implicitly specified. This intent can be propagated to other segments in this data base or related data bases. The amount of propagatior. is determined by the processing options specified, the data base organization, the pointer combinations USGd, and the SEGM statement RULES options chosen at physical DBDGEN time. The implications and extent of intent propagation are discussed below.
· Exclusive Intent
Exclusive intent prohibits the concurrent scheduling of any programs that reference the same segment type as the program that has specified exclusive use. Intent propagation must be considered when exclusive intent is used. Intent propagation is discussed below.
This intent is set if the associated SENSEG statement specified PROCOPT=E and the segment does not have key sensitivity. Key sensitivity can be specified on the associated SENSEG statement, using the KEY/DATA option of the SOURCE operand in a logical DBD, or by omitting the specification of the complete concatenated segment in a logical DBD. This occurs when you specify the logical child segment and not the logical or physical parent in the concatenated segment definition. There is no propagation of the E option. Note that the specification of both PROCOPT=E and K on a SENSEG statement causes the exclusive (E) option to be ignored.
!mE!i£!ii2B§ !U~ ~!i2Ui 2t !U12Ui R£2£~g!ii2U: As discussed earlier in
this section, the implications of intent propagation depend on many factors. Some of these factors are physical organization, pointer combinations, processing options, segment rules, and logical relationships. The following paragraphs explain their effect on scheduling concurrency as they relate to typical data base structures. Each processing option is discussed in a separate section. Keep in mind the fact that if a segment has more than one processing intent type (as the result of explicit or implicit processing options) the most restrictive intent is used.
Design and Control of a DB/DC System 2.21
· Get Processing Option
A segment using PROCOPT=G or K causes read only intent to be set for that segment. In addition, read only intent is propagated to all segments that are used to complete a GET type call. Sensitivity to a logical child segment implies sensitivity to its associated logical or physical parent. In either case, read only intent is propagated to the associated parent segment, and all its parent segments, in a direct line upward to the root segment.
· Replace Processing Option
A seg.ent using PROCOPT=R causes update intent to be set for that segment. If the segment is part of a concatenated segment definition, and the logical parent/physical parent part of the concatenation can be replaced, it has update intent propagated to it. No other propagation of intent occurs.
· Insert Processing Option
Insert intent propagation is based on two basic rules. These rules do not apply if Program Isolation is operative.
1. Programs that separately insert a physical parent segment and its physical child are not scheduled concurrently. If the program inserting the physical child terminates first, and if IMS/VS abnormally terminates before the program inserting the physical parent terminates, the physical parent segment is backed out of the data base by /ERESTART processing, leaving a dangling physical child segment.
2. Programs that insert child/logical parent concatenated segments involving the same logical parent are not scheduled concurrently. If the insert rule of the logical parent is either virtual or logical. The physical insert rule prohibits inserting the logical parent by means of a concatenated segment. Only the logical child need be inserted.
Update intent is set for the segment type designated by PROCOPT=I in the SENSEG statement of the PCB, or for all the segments designated by SENSEG statements when the PROCOPT=! is coded in the PCB statement (rule 1). Update intent is propagated to all the immediate children (down one level) from the designated segment because of rule 2. If the designated segment is a logical child, the update intent is propagated to the logical parent segment as specified by rule 3, and to the immediate children of the logical parent as specified by rule 2. If ~he ~nsert rule of the logical parent is physical, then one program per logical child segment type can be concurrently scheduled.
The first variable that affects insert intent is the data base organization. Since segments in a HISAK data base are hierarchically related by physical juxtaposition, a segment insert can cause o~her segments in the data base record to shift physical location. However, since a data base record can reside in several separate data set groups, only the data set group containing the inserted segment type is affected. The rule is: all segments residing in the same HISAK data set group as the segment type to be inserted have update intent propagated to them.
The second variable that affects insert intent is the pointer combinations specified for segments residing in HD type data base organizations. When physical child pointers are selected to address the designated segment, the physical parent has a different pointer for each of its children that concurrent programs maintain separately. However, if the choice is hierarchical pointers to address the designated
2.22 IMS/VS System/Application Design Guide
segment, the physical parent addresses all of its children by a single hierarchical pointer chain. Concurrent update programs for the different physical children, therefore, violate rule 1. When the immediate physical parent segment has hierarchical pointers, the data structure is scanned in an upward direction until a parent segment is found that uses physical child pointers, or until a root segment is encountered. The immediately previous physical child segment of the parent segment so located, and all dependent segment types of that immediate physical child segment, have update intent propagated to them.
· Delete Processing Option
The propagation of update intent from segments designated with PROCOPT=D is based on the physical child's dependence on the physical parent. If the physical parent is deleted, its physical children must also be deleted. Therefore, beginning at the designated segment type, update intent is propagated to all its physical dependent segment types and to their physical dependents, down to the lowest level of the data structure. When a segment that is a logical child is encountered in the downward scan, its logical parent's d~lete rule is determined. If the rule is virtual, update intent is propagated to the logical parent and its physical dependents. When a segment type that is a logical parent is encountered in the downward scan, the delete rules of its logical children and their physical parents are determined.
If the delete rule is virtual and/or hi-directional virtual, then update intent is propagated to the logical child and to its physical dependents, and/or to the physical parent and its physical dependents. Since the propagation is downward, all segments in the downward scan are inspected for logical relationships. As they are encountered, the logical child/logical parent/physical parent segment types are processed in the same manner as the original segment type. Deletion of the parent requires deletion of all physical dependents.
When the immediate physical parent of the designated segment has hierarchical pointers, the data structure is scanned in an upward direction until a parent segment is found that is a root segment, or a parent segment is found that is pointed to by physical child pointers. That segment type found, along with all its dependent segment ~ypes, have update intent propagated to them.
!EEli~ii2n ~£2~£!! !~n2£!!l I~£!in!iiQn
Upon abnormal termination of a message or batch-messaqe processing application program, internal commands are issued to prevent rescheduling. These commands are the equivalent of /STOP. They prevent continued use of the program and the transaction code in process at the time of abnormal termination. The master terminal operator can restart either or both stopped resources. At the time abnormal termination occurs, a message is issued to the master terminal and to the input terminal that identifies the application program, transaction code, and input terminal. It also contains the system and user completion codes. In addition, the first segment of the input transaction, in process by the application at abnormal termination, is displayed on the master terminal.
The stop action is performed automatically. Even though a message is issued, its occurrence could go unnoticed by the master terminal operator. Such a failure, involving a major application that serves many transaction codes, could have adverse effects on system performance.
Design and Control of a DB/DC System 2.23
The potential effects of commands entered from any terminal, that cause unavailability of scheduling resources. are severe. Operators should be instructed to display system status frequently. If a program that terminated abnormally inserted any message segments, they are transmitted, although the message may not be logically complete.
Program isolation dynamically backs out data base updates, and cancels message output made by application programs that terminate abnormally. To avoid the adverse effect that this backout can have on programs concurrently processing in the system, data base segments that have been changed are enqueued using the I~S/VS enqueue/dequeue routine. This routine ensures that no other programs can access the changed data base segments until either the application program that requested the change completes successfully, or terminates abnormally; and until all changed segments are restored to their original states.
Program isolation ensures that a dynamic log (IKSVS.DBLLOG) is maintained. The dynamic log is a sequential data set, on direct access storage. written with OSA~ to facilitate following chains through it. All the log records created because of a given user program are back-chained, with the chain anchor in the PST to which the program is attached. The chain pointer is the block number and the offset within the block. When a synchronization point is reached. or if the program terminates successfully, the anchor in the PST is reset to zero. If the program terminates with an abnormal termination, the data base changes are backed out to the last synchronization point specified by the KODE parameter of the scheduled transaction code. If it is a batch-message processing program that does not reference a transaction code, or whose transaction specified MODE=KULT, it is backed out to its schedule point, or to the last checkpoint, whichever is most recent. The hackout is accomplished by passing the data base log records. that were dynamically logged and chained, from the PST to the data base backout module.
A synchronization point is defined as the point at which an application program can be restarted.
SYNC POINT IS LATEST ACTION
r---------------------------,
I
I
I
1
I Msg GUI CHKP I SCHEDULING,
,
I'
,
r-----------------------------------------------------
I
I
I
I
1
, If MPP I Transaction,
,
I
I I
I 1 I I I MODE=Single I X I X I
X
,
1------------------------------------------
I
,
'I
1
I
,Transaction I
I
I
,
! MODE=Knltiple 1
I X 1
X
,
1
I'
I
I
1------------------------------------------------------I
I
1
1
I'
!
I If BMP 'Transaction I
I
,
,I,
I ' I ' I MODE=Single I X , X I
X
1-------------------------------------------1!
I
I
'I'
,
I
,Transaction I
"
,
1
, MODE=Kultiple ,
I
I
,
I
I
or
,
'I
,
I
I No Transaction I
I X1
X
!
, I " I , L _____________________________________________________ -~
2.24 I~S/VS System/Application Design Guide
All output messages inserted by an application program, with the exception of messages inserted to alternate PCBs that have been designated to have the Express Message feature, are enqueued to a temporary destination associated with the PST. The Express ~essage feature is a PSB Generation option for an alternate PCB. It specifies that messages sent to this PCB are not to be backed out if the application program terminates abnormally. ihen the application program successfully reaches a synchronization point, the program's output messages are transferred from their temporary destinations to their final destinations. If the application program abnormally terminates, all messages enqueued to temporary destinations are deleted and cancelled. Those messages inserted to the alternate PCBs that have the Express Message feature were never enqueued to the temporary destination and cannot be cancelled.
Program Isolation provides a call function (~OLL) through which an application program can remove the effect of its processing. Issuance of this call function abnormally terminates the application program task with an indicative completion code. Voluntary abnormal termination using this call function does not cause the program and transaction to be stopped, nor does it produce a storage dump.
One other kind of application program abnormal termination is possible. Since data base updates are isolated by the program isolation enqueue/dequeue facility, the possibility of a deadlock can arise. Deadlocks can be avoided by selecting one of the deadlocked programs for abnormal termination, with a special code that causes the program's data base updates and unsent message output to be backed out. The transaction input that was being processed by the program is retained, and the program is rescheduled.
The program to be abnormally terminated and rescheduled in a deadlock situation is selected using the following algorithm:
Both the waiting program that completes the deadlock circuit and the calling program whose request will cause a deadlock are evaluated according to the table below. Their corresponding values are compared. The program with the smallest value is selected for termination. In case of a tie, the time stamp taken at sync-point is the tie breaker. Por wait-for-input programs (including Past Path message-driven programs) the time stamp taken at message GU time is used. This action prevents time spent on the wait-for-input queue from biasing the tie-breaker computation in favor of a wait-for-input program that is not heavily utilized. A time stamp is also taken at program schedule time to indicate the implied sync point at program start.
r, -D--e-c-i-s-io-n--C--r-i-t-e-r-ia----------------------------------,--V-a-l-u-e-,,
1----------------------------------------------------------1
! 1. BMP mode=mult or no 5MB input
I 6
I 2. Fast Path non-message-driven program
I 6
I 3. Past Path online utility program
I 6
I 4. BMP mode=sngl
I 4
I 5. MPP mode=mult that did not deadlock in the I
I
previous scheduling
I 3
I 6. MPP mode=mult that was abnormally terminated I
,
for deadlocking in the previous scheduling I 2
, 7. MPP mode=sngl that did not deadlock in the I
1
previous scheduling
,
I 8. MPP mode=sngl that was abnormally terminated ,
,9. ,
for deadlocking in the previous scheduling I 0
L _____P__a_s_t _P__a_th__m__e_s_s_a_g_e_-_d_r_iv_e_n___p_ro_g_r_a_m_______________I __ 0 ! -----~
Design and Control of a DB/DC System 2.25
Whenever the resource that the calling program is requesting has
multiple owners (for example, several own~rs in share mode), the calling
program is abended. No other factor enters into the decision process. Whenever more than two programs deadlock, only the calling program
J
and the program completing the deadlock circuit are involved in the
selection process as to which is to be abended. The program completing
the deadlock is the program that the caller has to wait for to obtain
the requested resource.
In IMS/VS installations running under OS/VS1, after any abnormal termination in an MPP (for example, application program abnormal termination, program isolation deadlock, or ROLL call), the MPP may not be able to reclaim all the storage used by the application for future
scheduling. A system abend may eventually occur because of insufficient storage and the MPP will be terminated by 18S/VS, after two consecutive GETMAIN failures are detected, to release unusable storage in the region.
£QlltrQl ~lQ£~ g~ff~ ~Qol~ -- ~~g !ll~ ~~~
Control block pools are maintained in the IMS/VS control region for program specification blocks (PSB) and data management blocks (DMB). Each buffer pool must be at least as large as the largest control block it will contain, plus the next successively larger block, for each additional processing region concurrently active.
The IMSVS.ACBLIB data set must contain control blocks for all application programs (PSBs) and all data bases (DMBs) referenced by the application programs. When an application program is to be sch~duled, the PSB and DMS pools are examined to determine which control blocks must be brought into main storage. If all required blocks are resident, the program is scheduled. If required control blocks are not resident, the applicable pool is searched for space to hold the block. If space is found, the block is loaded and the program is scheduled. If the pool does not contain the required free space, the blocks currently resident are examined to determine which unused blocks can be removed. When the selection process is complete, any open data bases referenced by the unused blocks are closed, and the space is released for use by the new control blocks. The new control blocks are then loaded, and the application program is scheduled.
Excessive loading of control blocks can have a severe impact on performance. If possible, the DMB pool should contain enough space to hold all DKBs used with online data bases. This reduces the number of OS/VS opens and closes, and their impact on system performance.
System definition requires that data bases to be used in the DB/DC system configaration be identified. The positive declaration of data base names enables the system to limit the domain of the online control program to only some specific subset of all installation data bases.
2.26 IKS/VS System/Application Design Guide
If data base data sets, Fast Path DEDB area data sets, or the DC Monitor data set (if residing on a tape device) are specified with JCL statements included in the control region procAdure, these data sets are initially allocated at control region startup. Using the dynamic allocation macro (DFSMDA), the user can specify data bases to be dynamically allocated when needed, and deallocated when no longer being used. See the chapter, "Dynamic Allocation Interface Macro (DFSKDA)," in the !~~L!2 Y~iliti!~ R!t!~!~~ A~gs! for detailed information on how to code and use this macro.
Data base data sets and Fast Path DEDB areas can be dynamically allocated explicitly with the /START command, or implicitly through the Dt/I OPEN command and deallocated with the /DBR command. The DC Monitor data set can be dynamically allocated at the time it is started with the /TRACE ON command and deallocated when stopped by the /TRACE OFF command.
All data b~se data sets considered for dynamic allocation must be cataloged except DC Monitor data sets which must not be catalogad. A data set initially allocated with JCt can be dynamically deallocated and reallocated during the execution of the control region.
Figure 2-1 illustrates the creation of a parameter list to be used to dynamically allocate and deallocate 1MS/VS data bases. The 1HS/VS user prepares DFSKDA macro statements which are assembled in a normal OS/VS problem program job. The DFSKDA macro is placed in 1MSVS.MACLIB during 1KS/VS system definition. The assembler output is link-edited into I!SVS.REStIB, and will be loaded from there when needed.
A job control language procedure, named IMSDAtOC, is placed in the 1MSVS.PROCLIB data set by IMS/VS system definition for subsequent use in generating the parameter list(s). This procedure is described in the chapter "The 1MS/VS Procedure Library" in the !~~L!~ ~I§~!!t frQ!lrs!!lming
R!t~!n£! ~~gs!·
DFSMDA Macros
OSIVS
Parameter List Generation
r~ --
--..
-'"
IMS VS . RESLIB
-'
Figure 2-1.
....-
--.....
'
.-'"
IMS VS . MACLIB
--.
-----
Dynamic Allocation Parameter List
Design and Contr~l of a DB/DC System 2.27
A normal shutdown of I8S/VS is initiated by the master terminal operator entering a /CHECKP01NT command. The /CHECKPOINT command shuts down 1M5/VS in an orderly fashion. Following a checkpoint shutdown, the master terminal operator can start 185/VS and enter the /NRESTART command for a normal restart of IM5/VS. If 18S/VS was not terminated with an orderly shutdown, the /ERE5TART command must be entered to emergency restart IHS/VS.
The log tape, the restart data set, and the dynamic log are closed by the STAE routine when 1MS/VS fails. If the log tape cannot be closed, the master terminal operator must use the OS/VS DUMP command or execute a stand-alone dump to create a dump data set containing main storage. This dump data set will be used with the log tape to close the system log when 18S/VS is emergency restarted. Because the log tape can be closed during the emergency restart if it was not closed during an 18S/VS failure, the 18S/V5 system log terminator utility (DFSFLOTO) is optional.
18S/VS restarts can be performed from either the restart data set or the log tape. The restart data set is a direct access storage device (DASD) data set that contains the control blocks necessary for a normal restart or emergency restart of 18S/VS. With the restart data set, the master terminal operator can choose between restarting from DASD or restarting from the log tape. Even when the restart is from tape, the restart data set is used because it contains the checkpoint and log tape serial number information necessary for the restart. If the restart data set is unavailable, the serial numbers and checkpoint must he entered with the emergency restart or normal restart command.
The log tape must always be mounted when 18S/VS is running because it is used for restarting 185/VS, collecting statistical information, and recovering data bases. A normal restart of 1M5/VS only requires that the new log tape be mounted when 1M5/VS is restarted. With an emergency restart of 1M5/VS, the old log tape can be mounted in order to he closed by 185/VS. After the old log tape is closed, a request for a new log tape will be issued; after the new log tape is mounted, IM5/VS will continue with the restart until completion.
If OS/VS fails, a restart from tape will be required. Other conditions requiring a restart from tape are when the message queues need to be rebuilt or reformatted, or the log tape or 1MS/VS system data sets are not closed by IM5/VS. The master terminal operator can choose to do a tape restart by entering the serial number of the last mounted log tape with the normal or emergency restart command. The tapes required for restarting are determined by IHS/V5.
Automatic restart is an option that can be used if it was defined during system definition. With automatic restart, the master terminal operator starts 1KS/VS but does not initially specify the tyP of restart. Automatic restart determines the format of the restart and sends a message to the master terminal operator stating that the restart is in progress. If the restart data set is not available, the master terminal operator is asked to enter /NRESTART or /ERESTART depending on the type of restart required.
IMS/VS supports dual logging of system log tapes. Dual logging is the duplicating of information on two log tapes while IMS/VS is running. The purpose of dual logging is to ensure that a readable log tape is available for restart processing. During a restart from tape, IM5/VS will automatically switch between the primary log tape and the secondary log tape whenever an I/O error on missing record is encountered. For more information on closing and recovering the system log, see the
2.28 I~S/VS System/Application Design Guide
section "Restoring Integrity of the IMS/VS System Log," in the I!!§l!§
QE~I~i2~ R~I~~~n£~ ~~ng~l·
L
The batch checkpoint facility provides batch-message programs with the means of synchronizing checkpoints taken of their environment with the IM3/VS log tape~ It also enhances the integrity of data bases updated by batch-message programs, by allowing the restart facility to back out data base changes being made by such programs at the time of a system failure. If a batch-message processing program abnormally terminatess, program isolation ensures that backout procedures occur automatically. The data to be backed out is the data base change records logged since the last synchronization point created by a CHKP call. The time lag is significantly less using program isolation with batch checkpoint/restart, than if the data base had to be stopped and taken offline for batch backout.
The batch checkpoint facility is implemented by the use of the IMS/VS checkpoint (CHKP) system service call from the application program. This call is used to indicate a synchronization point at which data base updates can be restarted. The actual checkpointing of the batch program environment, and the routine used to restart it, are at the option of the user. If OS/VS checkpoint is to be used, the user must request, as part of the DL/I CHKP call, that the system take the checkpoint.
liQl~: The checkpoint ID table, as referenced below, is used to coordinate the checkpoints on the IMS/VS system log with the activity of any batch-message regions, for the purpose of emergency restart. This table also contains the ID and serial number of the last startup or shut40vn checkpoint.
For batch-message programs (not message-driven):
A non-message driven BMP program functions like a batch program, but receives data base service like an MPP. No identifiable (explicit) synchronization point exists antil the program issues the CHKP call.
1. Optionally, an OS/VS checkpoint of the user's region is taken.
2. Altered data base buffers are written.
3. The checkpoint ID, supplied in the CHKP call, is written to the log tape.
4. The checkpoint-ID table is updated, for use in subseq~ent
emergency restarts.
5. The dynamic log is updated by releasing all change records prior to the current synchronization point.
For batch-message programs (message-driven):
BMP programs that access the message queue via the IIO PCB, have a defined (implicit) synchronization point established by the KODE= parameter in the TRANSACT macro. To IMS/VS, the EMP program looks like an KPP. If KODE=KULT is selected, end-of-job is the natural synchronization point. BMP programs can issue the CHKP call to cause an explicit synchronization point, and define a pOint from which restart can be performed. Care must be taken to ensure that the dynamic log buffers do not become full because the CHKP calls are too infrequent. All output messages, that are not destined to express alternate PCBs, are held until a synchronization point occurs. All input messages since
Design and Control of a DBIDC System 2.29
the last CHKP are reprocessable. The following general events occur in this type of BMP:
1. Optionally, an OS/VS checkpoint of the user's region is taken.
2. Altered data base buffers are written.
3. The checkpoint ID, supplied in the CHKP call, is written to the log tape.
4. The checkpoint-ID table is updated, for use in subsequent
emergency restarts.
5. The dynamic log change records for the calling B~P are released.
6. Output messages to all TP PCBs are sent, and input messages are dequeued.
7. A GU to th~ I/O PCB is internally generated for the application program.
If MCD!=SNGL is specified on the TRANSACT macro instruction, a natural synchronization point exists at each GU on the I/O PCB. Functions similar to those above are performed by 1MS/VS; however, the user does not have to execute a CHKP call because the GU causes the necessary synchronization points.
Instead of the as/vs Checkpoint/Restart option, the user can specify
the IMS/VS Extended Checkpoint/Restart facility. This consists of a restart call (function code XRST) and optional parameters on the CHKP call. If used, the XRST call is the first call to 185/VS issued by the user program. If a restart is not in progress, th~ IRST call is effectively a NOP.
The issuance of an XRST call causes the following action to be taken for subsequent CHKP calls issued by the program:
1. optionally, user specified areas, that is, application variables, control tables, and position information for non-I8S/VS data sets, are recorded on the IMS/VS log.
2. The fully qualified key of the last record processed by the program on each 185/vS data base is recorded on the log.
3. The functions of the standard CHKP call are performed, except that the OS/VS checkpoint of the user's region is not taken. The user has the option of using OS/VS Checkpoint/Restart, the IMS/VS restart (IRST call), or neither, but not both.
For message processing programs:
The CHKP call functions exactly as a message GU £or a single mode program, allowing a program operating in multiple mode to control the spacing of its synchronization points.
In the case of a checkpoint FREEZE or DUMPQ shutdown, I~S/VS waits for any batch-message programs that are processing to issue a CHKP call, before proceeding with the shutdown. This action makes it possible to identify the point at which the batch-message program should be restarted.
In the case of a PURGE shutdown, IMS/VS waits for batch-message programs to terminate before proceeding with the shutdown.
2.30 IMS/VS System/Application Design Guide
The log record containing the checkpoint ID is used by emergency restart as follows:
Using the checkpoint-In table, emergency restart determines, and identifies to the operator, the point on the log where restart processing is to begin in order to back out incomplete updates made by the message and batch-message programs processing at the time of the system failure. It initiates restart processing from that point. If backout is successful, the CHKP ID from which each B~P can be
restarted is identified to the operator.
Transactions, partially processed by message processing programs at the time of system failure, that caused data base modifications, have their associated data base modifications backed out by emergency
restart.
The IMS/VS user must determine th~ means of checkpointing and
restarting his batch and batch-message processing programs. He may use the OS/VS checkpoint/restart facility, or create one of his own.
If the DL/I user chooses to write his own checkpoint/restart routines, he must, as a minimum:
· Record application variables and control tables.
· Record position information for non-IMS/VS data sets.
· Provide a restart entry point and reinitialization procedure.
· Properly initialize I8S/VS control blocksi for example, PXPARMS.
Use of the XRST call and user area parameters on the CHKP call
L
simplifies the task for the user writing his own restart routines. · A restart situation is indicated by specifying a checkpoint ID in
the parm field on the execute card in the JCt or in the XRST call
itself.
· Normal entry point and initialization procedures are used.
· User areas recorded at checkpoint time are restored.
· A GET UNIQUE is issued for each GSAM data hase for the last used record if the data base was open at the time the checkpoint was
taken.
· No data is returned as the result of the GU, but status codes are saved in the user PCBs.
· If the data base was opened for output, ~hen a PNT function code, requesting POINT, is used.
· GSAM data bases are automatically repositioned at restart if the XRST call is used.
· The checkpoint ID is returned to the user program to allow it to link to its own restart subroutine.
In the case of batch-message programs, an actual checkpoint/restart routine may not be required. If the program is truly driven by the mssage queues, IMS/VS repositions the queues to the point where a CHKP
call was issued. The user need only start the batch-message program normally.
Design and Control of a DB/DC System 2.3'
Even though most batch-message programs require some re-programming to accommodate the CHKP function, the increased data base integrity and availability should justify the effort.
Since the I8S/VS control region waits until all batch-message regions issue CHKP calls before proceeding with a shutdown checkpoint, a batch-message program with few or no CHKP calls can delay or prevent system shutdown. The /STOP REGION command with ABDU~P can be used to force the abnormal termination of such a region. However, it is recommended that the user add CHKP calls to batch-message programs, particularly if a FREEZE or DUMPQ checkpoint is to be requested. If a PURGE shutdown is used, re-programming is suggested for batch-message programs that run for a long time, because 1M5/VS waits for these programs to terminate before proceeding with the shutdown.
The 1~S/VS control program provides the ability to queue messages received on direct access storage and in main storage. Messages can be received from communication terminals or application programs and can be destined for communication terminals or application programs. A message destined for an application program is called a transaction and begins with a transaction code. All transactions of the same type (same code) are queued in a serial chain based upon time of receipt by IM5/VS. A serial queue exists for each defined transaction code. All messages destined for a particular communications logical terminal are queued serially like transactions. A serial queue exists for each defined logical terminal (Figure 2-2).
2.32 I85/VS system/Application Design Guide
TRANSACTION CODE
X
QUEUE CONTROL BLOCK
X QUEUE
END OF MESSAGE X
~UEUE
- COMMUNICATION
LOGICAL
TERMINAL
Q01 Message
~ Q01 Dequeue Pointer
Q01 Enqueue Pointer
I
Q02 Dequeue Pointer Q02 Enqueue Pointer Q03 Dequeue Pointer
Q04 First Mess age
~
I
Q03 Enqueue Pointer
Q04 Dequeue Pointer
- Q04 Enqueue Pointer
Q04 Message n
l
J
Q05 Enqueue Pointer
Q04 Last Message
y
~
Figure 2-2. General Message Queue Structure
MESSAGE QUEUES AND MESSAGE SELECTION
The serial queue for each defined logical terminal consists of an incore queue, four prioritized queues, and a nonprioritized queue. In descending priority sequence, the levels are as follows:
QOO
This is the incore queue. All messages in this queue are sent immediately and are not written to the direct access message queue data set. Messages on this queue are not considered recoverable and will be discarded if an error occurs during transmission.
QO 1
Reply to response type messages. This queue is used for response mode conditions when a terminal is in terminal or line response mode or conversational mode. This queue can contain only a single message.
Q02
Design and Control of a DB/DC System 2.33
Replies to a transaction from a terminal in exclusive mode. Output to a terminal in exclusive mode viII be queued to 002. If a response mode condition exists, the output will be placed in 001 instead of Q02.
Q03 system messages which are to be enqueued. This includes broadcast text, output from the IDISPLAY command, and all DFS messages with the exception of the DFS555 ahnormal termination messages. The DFS555 message will be placed on other ~han Q03 to notify the terminal of the abend (for example, a terminal in response mode vill receive the DFS555 abend message from 001).
All other traffic. This queue is used for application programming output, message switches, alternate PCB output, etc.
Q05 Backup message. This queue is used:
· To resend messages from terminals with the resend feature.
· For conversational processing, the last response to the terminal is kept for purposes of the IHOLD and IRELEASE commands. This queue is not prioritized and is transparent to the user.
The ~olloving are the possible modes of a terminal. The terminal is
not restricted to a single mode but may be in more than one mode at the same time.
· CONVERSATION -- A terminal is in conversation mode from the time it enters a conversational transaction until th& time the conversation is completed or abnormally terminated. A conversation is normally terminated when the message has been sent and dequeued and the application program has cleared the transaction code field in the
scratch pad area (SPA). A conversation can terminat~ abnormally in several ways:
1. An application program ASENDed.
2. The I~S/VS operator issues an IEXIT command, a ISTART NODE
command, a ISTART LINE command with no PTERM keyword, or an IIA" DONE command with an INQUIRY LTER! (switch line disconnect).
3. When there is an inconsistent definition betveen systems.
· EXCLUSIVE -- A terminal is placed in exclusive mode when the /EXCLUSIVE command is issued. Exclusive mode is terminated by an lEND command, a ISTART LINE command, a ISTART LINE PTERM command, a ISTART NODE command, or a IIAM command.
· RESPONSE MODE -- System definition specifications determine when a terminal will be placed in response mode. Terminal response mode is terminated in several ways:
1. When the message has been sent and dequeued.
2. The IMS/VS operator issues a 1ST ART LINE PTERM command, or a /RSTART LINB PTBPM command.
3. An IMS/VS restart.
J
2.3q IMS/VS System/Application Design Guide
Line response mode is terminated in several ways:
1. When the initial attempt to send the message has been made.
2. The IMS/VS operator issues a /START LINE command, a /RSTART LINE command.
3. An IM5/VS restart. If the Fast Path feature is used, terminal response mode will automatically be re-entered on an IK5/VS restart or after the issuance of an /RSTART LINE PTERK command if a message is in the output buffer.
· LOCK -~ The locked mode prevents the sending and rece~v~ng of messages to a terminal. A terminal, NODE, or a logical terminal (LTERK) can be placed in locked mode when the operator issues a
/LOCK command. This mode is reset by the /UNLOCK command or the
/IAM command.
· TEST -- Test mode ensures that any input message entered into a terminal is transmitted back to the terminal with error analysis procadure~ bypassed. A PTERM or NODE is placed in ~est mode by the /TSST command. Test mode is reset by an /END command, a/START command, or /IAM command.
· LOOPTEST -- The looptest mode provides for the establishment of an output write loop whereby a user-entered message is continuously transmitted to the terminal. A PTERK is placed in looptest mode by the /LOOPTEST command. Looptest is reset by an /END command, a /START command, a /RSTART LINE command, or an /IAM command.
· QERROR -- A logical terminal will be placed in a stopped state if an I/O error is encountered while attempting to read a message from or write a message to a message queue. This condition is reset when the operator issues the /START command.
· STOP -- The stopped state prevents the selection of any output queued on a logical terminal associated with a physical terminal.
For terminal using VTAM, the /STOP NODE results in the termination of the session between IMS and the node. This termination occurs immediately for most devices but only at the end of the message for 3270 devices and SLU type 2 devices. The /STOP NODE command also prevents logon until a /START command or /RSTART command has been issued.
The /STOP command, the /PSTOP command, and the /MONITOR command also cause a terminal to enter the stopped state. This state is reset by issuance of the /START command or the /RSTART command,
· SNA quiesce -- When IMS/VS is sending output messages to a VTAM programmable node and the node wishes to suspend reception, the node will signal IMS/VS to halt transmissions after an end-of-chain has
been sent. See the section "VTAM Signal Commands" in 111§.LY§.
!~!~~£ed fg~£!~Q~ tQ~ £Q!!gn~£~tiQn2 for further details on the guiesce-at-end-of-chain function.
· INOP -- The physical terminal is marked inoperable by IMS/VS device support whenever a physical error is detected. All logical terminals associated with this physical terminal are marked not eligible for selection for message transmission. The /START command or the /RSTART command will reset the inoperable condition.
Design and Control of a DB/DC System 2.35
· COMPINOP ways:
Component inoperative (not ready) can be set in two
1. An error is detected that can be isolated to a component of a
tarllinal.
2. By the issuance of the ICOMPT command or the IRCOKPT command for
terminals defined to VTAK. All logical terminals associated with
this component are marked ineligibl~ for selection for message
output. Component inoperative is reset when the operator issues
a ISTART LINE PTERK command, a ISTART NODE command, another
ICOMPT command, or a /RCOKPT command. Special signals from the
device. such as device end from a 3270 device, or special
commands from a 2270 device can also cause the resetting of the
component inoperative or not ready state. For unique device
considerations see the chapter "IMS/VS Telecommunication Device
Support" in the 1~§L!§ Q.2~':~12I~§ R~.{~~~n~~ ~n!t~l.
· PAGE. SCREEN, and COMPONENT PROTECTION -- This is a state supported
for video terminals and SLU type p devices. Logical terminals
associated with this physical terminal are ineligible for selection.
For a discussion on screen protection for the 3270 devices, see the
chapter "IMS/VS Telecommunication Device Support" in the Ir!~L!~
Q.2~.:~t2~~§ R~~~~~!l~~ !1~!l!!!!1, and the chapter "Message Formatting
FURctions" in the 1~§L!~ ~~§§~g~ ~2.:~i §~~X!~~ g§f~~§ 2!!!g~. For
programmable VTAM devices, see the section "Display Screen
Protection for Statians Defined as 3601" in the chapter "IMS/VS
Support for Advanced Function" and the section "Extended Output
Component Protection" in the chapter "Type P Secondary Logical Unit
Programmer's Guide" in the !MSL!~ Ag~!l£~g f!!n£i~2!l ~2~
£2!1Uni£U!2!l§·
DETERMINING MESSAGE SELECTION
J
The following figures allow you to determine which messages will be selected for transmission to a terminal when IMS examines the mess~ge
queues for a message to send.
· STEP 1:
Find, in Figure 2-3, the source of the message in question and note
the queue the message is in.
· STEP 2:
Referring to Figure 2-4, find the state of the logical/physical
terminal or node. Note the queue levels from which messages will be
selected when the terminal is eligible for selec~ion. If the
message is in one of these levels, IMS will attempt to send the
message. Otherwise, the message will remain in the queue for later
transmission.
Example: To find what happens to a /FORKAT command entered from a terminal in conversation mode:
1. Find the source of the message in Figure 2-3. The /~ORMAT is
entry I.A.1'. Since the terminal is not in exclusive moae, the
/FORMAT response will be placed in Q03.
2. Find the terminal state in Figure 2-4. Conversation is state 12.
Queue levels selected are QOO and Q01. Since the /FORMAT
response was in Q03, it will not be sent until th~ conversation
is terminated.
J
2.36 IMS/VS Syst~m/Application Design Guide
Source of Message
Queue Level
I. Control Region
A. IMS/VS Code
1. Error messages to a terminal created while processing input from or output to a terminal
(for example, messages such as DFS064 NO SUCH TRANSACTION CODE, DFS06S TRAN/LTERM STOPPED, etc.).
QOO*
2. The same error messages as above but detected
in a remote KSC system:
- The input message that was discarded because of the error put the terminal in response mode.
Q01**
- The terminal is in exclusive mode.
Q02
- None of the above.
Q03
3. Direct responses to terminal requests (for example, messages such as DFS290I NO MESSAGE AVAILABLE FOR OUTPUT).
QOO*
4. Terminal connect, disconnected, or restarted
QOO
(for example, DFS2002 TERMINAL CONNECTED,
DFSOS3 TERMINAL RESTARTED-PLEASE REFORMAT SCREEN).
5. Messages directed to the master terminal
Q03
(for example, DFS253I TCU INOPERABLE LINE x
PTERM y).
6. TEST or LOOPTEST messages.
QOO
1. DFS058 command completed.
QOO*
8. Output from the /DISPLAY, /RDISPLAY OUTPUT commands.
Q03*
9 .· /START, /RSTART, /STOP, /PSTOP command status
Q03
messages. These messages will be discarded if
the MSGDEL=SYSINFO or the MSGDEL=NONIOPCB parameter
vas coded in the TERMINAL macro statement.
10. Broadcast text. These messages will be discarded
Q03
if the MSGDEL=NONIOPCB parameter was coded in the
TERMINAL mac~o statement.
---;-ior-the-2170;-Iocal reader, and 2780, these messages are put in Q03 on a last-in first-out basis.
** If the terminal is removed from response mode before this message
is completely sent, the message will be moved to Q02 if the terminal is in exclusive mode or to Q04 for all other conditions.
Figure 2-3 (Part 1 of 3). Source of Messages
Design and Control of a DB/DC System 2.31
Source of ~essage
Queue Level
11. I~S/VS commands (for example, /FOR~AT, /TRACE, etc.).
- Terminal in exclusive mode.
Q02
- Terminal not in exclusive mode.
Q03
B. User Exit Routines
1. Request to cancel message via return code - an IMS/VS message is generated.
QOO*
2. Request to cancel message and send a message from the user's message table.
QOO*
3. ~essage 'echoed' back to terminal using the MFS segment exit.
Q01
C. Message Switch (terminal to terminal). This message
viII be discarded if the KSGDEL=NONIOPCB parameter
is coded in the TERMINAL macro statem~nt.
~
II. Dependent R~gion
A. I/O PCB or Response Alternate PCB**
1. Conversational mode.
Q01
---.-por-the-211o;-rocal reader, and 2780, these messages are put in Q03 on a last-in first-out sasis.
** Response Alternate PCB restrictions:
1. Conversational -- The destination must be the same physical
terminal. If not, an A9 status code will result if processing in
a local system; or a conversational abend will result if
processing in a remote MSC system and if the error was detected
at the terminal-attached system.
2. If the current input message put the terminal in response mode,
the destination must be the same physical terminal. If not, an
A9 status code will result if processing in a local system. This
is not checked if processing in a remote MSC system.
3. Output to both a response alternate PCB and the I/O PCB is not
allowed. If the terminal is not in conversational mode, output
to multiple response alternate PCBs is allowed.
4. Destination logical terminals must not have more than one
physical terminal assigned for input purposes. An AY status code
will result if processing in a local system. This is not checked
if processing in a remote MSC system.
S. An ISRT call prior to a GO DL/I call is not allowed to the I/O
PCB.
Figure 2-3 (Part 2 of 3). Source of Messages
2.38 IKS/VS System/Application Design Guide
Source of Message
Queue Level
f
L
2. The input message being processed put the terminal in response mode.
Q01*
3. Terminal in exclusive mode but not in response
Q02
or conversational mode.
4. None of the above.
Q04
B. Alternate PCB
1. If the /TRACE command vas issued for the
Q04
destination PTERM and the message ID was deleted,
a 6701 log record with an ID=ICLR is created. This
message is discard~d if the MSGDEL=NONIOPCB parameter
parameter was coded on the TERMINAL macro statement.
C. IMS DFS555 Abend Message
1. The input message being processed put the terminal in response mode.
Q01*
2. The terminal was in exclusive mode.
Q02
3. None of the above.
Q04
---;-If-the-t;riinal is removed from response mode before this message
is completely sent, the message will be moved to Q02 if the terminal is in exclusive mode or to Q04 for all other conditions.
Figure 2-3 (Part 3 of 3). Source of Messages
Design and Control of a DB/DC System 2.39
State
1. PTERM inoperative 2. Component inoperative 3. PTERM in test mode 4. SNA quiesce-at-end-of-chain received 5. Qerror 6. Line STOPPED, PSTOPPED, or MONITORED 7. Node stopped, before termination
of session, node disconnected due to
/CLSDT or LOSTER!'!, or IMS shutdown
8. PTERM STOPPED, PSTOPPED, or MONITORED 9. LTERM STOPPED or PSTOPPED 10. PTERM locked " . LTER~ locked 12. Conversational mode 13. Response mode 14. Exclusive mode 1S. Nona of the above
Queue Level Selected
QOO QOO QOO QOO QOO QOO,Q03* QOO
QOO,Q03* QOO,Q03* QOO,Q03*
QOO,Q03*
QOO,Q01 QOO,Q01 QOO,Q01,Q02 QOO,Q01,Q02,Q03,Q04
The line or terminal is not in response mode. An active conversation is not in process. The terminal is not in exclusive mode.
Figure 2-4. Queue Selection
QQ~!!li Q!ll ~~I~
The IMS/VS control program utilizes three OSAI'I data sets for direct access queue storage. All queue data sets have the same block size, which is specified by the IMS/VS user at system definition time.
Figure 2-5 illustrates the relationship between the three queue data sets.
2.40 II'IS/VS System/Application Design Guide
"iotll'ti."
"v:£:.'*"
TRANSACTIOII OR LOGICAL TERMINAL QUEUE
Figure 2-5. Queue Data Set Relationships
OPERATION OF QU~UES
All messages received are assigned OSA8 relative record numbers. However, they are not written immediately to the queue data sets. If no space is available in the main storage buffers, the buffer which has been referenced the least is written to its queue data set, and the space in main storage is assigned to the new message. If a message still exists in main storage when it is dispatched to its destination (input to a program or output to a terminal or another program), no reference to the direct access data sets is required. All messages are logged by the IMS/VS control program to provide message queue recoverability in case of failure of either the I~S/VS or host operating system control programs.
Messages received are represented by either single or ~ultiple segments. The amount of space required to contain a message determines the size of the records to which it is allocated. When the transaction or logical terminal queue is known, the average message size is also used to determine the record to be allocated. The lines of text are placed in a variable-blocked format within a record.
The IMS/VS message queue data sets must be preformatted before initial usage. The use of prefoimatted queues provides increased reliability. Reliability is increased with the preformatted data sets becaus the count field of the direct access device record X is not relied upon to write record X+1. preformatting is performed upon request during restart procedures. The need to reformat the message queues arises only if an input/output error occurs within a queue data set. A write error does not result in the inability to write subsequent records in the data set as is the case with unformatted gueu~ data sets.
Design and Control of a DB/DC System 2.41
Approximately 1.5 seconds is required to format each 2314 cylinder in an IKS/VS message queue data set and .8 seconds for each 3330 cylinder.
In order to provide for message queue recoverability if the queue data sets are destroyed, the IKS/VS control program logs:
· all input and output message text
· the queue pointers to each message queue chain, whenever a message is enqueued onto or dequeued from the chain
If a system failure occurs and the message queue data sets are retained intact, the restart facilities of IKS/VS can reposition the queues by use of the enqueue/dequeue pointers which were logged. If the queue data sets are destroyed, the restart facilities of IKS/VS can be employed to rebuild the queues from the log entries of message text.
EMERGENCY RESTART QUEUE REPOSITIONING
In an emergency restart situation, the message queues are repositioned as follows:
· SNGL mode processing
The message being processed at the time of the failure is the first message processed after the restart.
· MULT mode processing
All messages read by the program are processed at the time of the failure are returned to the queue. The first message processed after the restart is the first message read after the program's most recent CHKP call or scheduling.
MESSAGE QUEUE REUSE
Message queue records reside in fixed-length blocks with a block size common to all three data sets. The first record in each data set is a
bit map which controls the assignment of the next n records (n = 8 *
LRECL-1). Records in each data set are assigned from low to high by testing the bit map for the first bit which is on. When a bit is found on, it is turned off to indicate that the corresponding has been assigned. When a record contains a message that has been completely processed at its destination (has been degueued and will not be required in restarting the system), the bit corresponding to the record is turned on. This makes the record available for reuse.
For details on message queue data set space allocation, refer to the
I~~L!~ In§1A!!!!i2n igig~·
A physical terminal is the actual hardware device attached to the computer. The types of terminals supported include typewriters, eRTs (cathode ray tubes), paper tape readers, card readers, high-speed printers, and reaote computers. The I8S/VS terminal configuration is defined to IKS/VS during system definition.
2.42 IMS/VS System/Application Design Guide
DEVICES SUPPORTED
IPiS/VS supports:
· IBM 1050 Data Communication System · IBM 2260 Display Station, Models 1 and 2
· IBM
2265 Display Station, Model 1
· IBM 2140 Communication Terminal !IIodels 1 and 2
· IBM 2141 Communication Terminal · IBM 2710 Data Communication System · IBM 2780 Data Transmission Terminal · IBM 2980 General Banking Terminals, Models 1, 2, and 4 · IBM 3270 Information Display System
· IBM 3600 Finance Communication System
· IBM 3630 Plant Communication System
· IBM 3767 Communication Terminal
· IBM 3110 Data Communication System
· IBM 3740 Data Entry System, Models 2 and U
· IBPI 3790 Communication System
· IBM 5110 Computer · IBPI 7770 Audio Response Unit, Model 3 with a Touch-Tone* (or
equivalent) telephone or IBH 2721 Portable Audio Terminal
· IBM Series 1 system · IBM System/3 !IIodel 10
· IBM System/1 · IBM System 32 and 34 · IBM Communicating Magnetic Card/Selectric Typewriter (CMC/ST)
· Card reader/printer devices
· 33/35 Teletypewriter (ASR) IMS/VS supports various communication/attachment modes for the above
terminals. The major distinction is whether the attachment is local (through a channel) or remote (over telephone lines). Remote attachments are further broken down into two categories: switched and nonswitch~d (or leased). Switched communication lines permit the attachment of only one remote station or terminal at a time to a line, and require that the terminal operator use a data set, which is attached to the remote terminal, to dial up the main computer to establish
* Registered Trademark of the American Telephone & Telegraph Co.
Design and Control of a DB/DC System 2.43
connection. Nonswitched communication lines are leased; that is, they are dedicated to use by the terminals physically attached to them. A nonswitched line may be either a contention or polled line. Contention or polled refers to the line discipline used to communicate with the terminal. Only one contention-type terminal may exist on a line, while one or more can share a polled line concurrently. A pollAd line with more than one terminal is called a multipoint line.
See the I~L!~ ~~~~~! InfQ~~!!lQn ~~ng~! for a description of ~he communications modes supported by I~S/VS for each physical terminal and for lists of the required and optional features for each supported
terminal, control unit, and cpu.
BTAM DATA SET LINE GROUPS
The LINEGRP macro is used to describe each BTAM data set line group.
The terminal(s) defined for anyone LINEGRP must be of the same type (communication mode, polling techniques, transmission code). This means
that a separate line group must be used for each of the following terminal configurations (when used) :
· 1050 switched · 1050 nonswitched with poll · 1050 nonswitched with autopoll · 2260/2265 remote and 2260 local mode, nonswitched
· 2740 switched with transmit control · 2740 nonswitched contention · 2740 nonswitched polled · 2740 polled with autopoll
· 2741 switched* · 2741 nonswitched EBCDIC and nonswitched correspondence
· 2770 nonswitched · 2780 nonswitched polled · 2780 nonswitched polled ASCII · 2780 nonswitched polled 6-bit transcode · 2780 nonswitched contention EBCDIC · 2780 nonswitched contention ASCII · 2180 nonswitched contention 6-bit transcode · 2980 nonswitched
· 3270 local · 3270 local printer · 3270 polled remote · 3270 polled remote ASCII
· 3270 switched · 3270 switched (ASCII) · 3630 switched · 3740 switched · 7170 switched
· System/3 · System/7 nonswitched contention · System/7 nonswitched pollee · System/1 nonsvitched polled with autopoll
· Local card reader · Local output device (printer, punch, tape, DASD)
· Spool SISOUT · 33/35 switched
*For 27q1 switched, transmission codes for anyone line group do not have to be of the same type.
For further definition of a BTAK data set line group, refer to Q§L!~
lBiTnAeM,
GC21-6980. group. At
le
At as
t
lea on
st e
one communication physical terminal
line must
must
e~ist
exist within for each
each
communication line.
2.44 IMS/VS System/Application Design Guide
TERMINALS ATTACHEt 'lHROOGH nAM
'lerminals attached through V'lAM are defined according to terminal type hy using the TYEE lacre. Valid terminal types are: 3270 local, 3270 remote, 3601, 361~, 3iE7, 377C, and 3790.
PHYSICAL TERMINAL NETWORK DESIGN
Selection of terminal types should be based on what function is expected, the location and p=rsonnel using the equipment, and the speed or volume of data whick the teIKinals ale expected to handle.
Inquiry and ccnversational capabilities are best suited to typewriter or graphic type devices, the graphic devices being faster, whilE the typewriter gives a hard cCFY cf the transaction.
Batches of input can best he handled by cards or paper tape, with the 2770, 2780, or 3770 being used for high volume and the 1050 for low.
The printer-type terminals are best suited for applications where the shop floor requires infclaatien fIem the ccmputer but has no need to su~ply any in return. Again, the 2770 or 2780 is best suited fer high volume, with the others handling less volume.
Once the tYPES of terminals rEguired for the job are determined, the methed of cennecting them to the computer must be considered.
If many terminal locations are required with minimal volume, a switched network should be ccnsidered. 'Ihis allows the use of standard telephone lines. The terminal operator dials the computer when he wishes to make an entry. OnE drawback to this ap~roach is the possibility of busy lines, which may cause the operator to placE a call several times. AnotheI disadvantage is that voice-grade lines are more susceptible to malfunction than leased lines. This might require the operator to requEst entry acre than one time to allow the computer to read it error-free. Unchecked terminals (2741, 33/35, and 7770) can cause input and output tc be lest due to line errors which are trans~arent to the IMS/VS system.
When high volume is required or the terminal must be connected to the computer for long perieds ef time, a leased line may be more practical. This type of line is generally more error-free, can handle higher volume of data, and requires no eFeratcr action to connect to the computer. If the leased line is chosen, the next step is to determine how many terminals are to te ccnnEctEd tc this line. If several unbuffered terminals are connected to the line, significant delay may occur in the response to a terminal. It is therefore recemmended that unbuffered terminals be attached alone to a line. Another consideration may be the need to cluster several terainals in one location. The expense of running several telephone lines to the same location may be prohibitive. If so, buffered terminals sheuld be considered. Their slightly higher cost may be more than offset by the need to run only one line, thus reducing the contenticn fer line time, as the data is transferred to a buffer at operatoL speed and theD sent across the line at machine speed.
Most terminals suppcrted by ISS/iS are polled. For some terminals, consideration should also be given to the type of polling to be used: programmed or autepoll. FOI slallnetworks, programmed polling may prove more economical, since autopoll, except for binary synchronous lines, is an extra cost feature. However, Frogrammed polling requires more CPU interruptions and, for a larger network, may use enough CPU time to make the cost cf autcFcll worthwhile. For each terminal in the system, programmed polling causes a hardware interrupt approximately every second. Autopcll causes this interruption only when the cperator
Design and Control of a DB/DC System 2.45
has initiated some action on the terminal. which will generally be several minutes.
Lines can te collected by terminal type into line groups. Each new line group requires main stcrage for ccntrol blocks used by IMS/VS and the operating system. All lines for a particular type of terminal can be collected into one line grouF, minimizing this storage requirement. HOMever. this means that all these lines must be allocated to the system at all times. When cne is removed (possibly for use by a different job er system), IMS/VS does not function properly. Therefore, if ene or more lines are to be used by IMS/VS on a part-time basis, and it is desired to allocatE them to ether functions at times. they should be organized into separate line groups. Lines may be removed from the system by line group.
When binary synchronous terminals (except 3210) are used in the online IMS/VS system, timeout conditions can occur when the system is so loaded that it eannct prccess an input line buffer and respond to the terminal. If the terminal operator re-enters the data before verifying the applicatien program respcnse, to determine the proper restart point in the data stream, this could lead to duplicate data.
DEFlNITlON OF !HE LOGICAL !ERMINAL CeNCEr!
1he ~haracteristics of terminal devices vary widely. There are differences in the centrel mechanics. transmission code, display media. entry keyboards, switches, timing. and optienal features. Communication line and network characteristics further complicate and multiply the possible combinations of characteristics that must be managed in the data communication environment. It is readily apparent that the applicaticn prcgram shculd Dct become directly involved with or dependent upon the characteristics of the terminal network with which it deals.
By isolating the application program from its terminal network, economies in development cost. development time, and maintenance are achieved. In additicn, a certain degree of, if not complete, device independence is available. Applications written to a device-independent interface may be expanded witheut modification for the use of new terminal types or classes.
At the same time, USE cf device class dependent functions may be highly desirable in certain application areas. Control of device class dependent functions for an application system which serves only CRT-type devices could enhance the usability of that application.
Another requirement directly related to device independence is application independence. An application-supported function must be available from different terminal types. It is not feasible or practical to expect that a unique terminal be assigned to each function to be performed.
For reasons of security or resource management, it may be desirable to associate the use of a physical terminal with its user. Whereas users may exist in greater numbers than Fhysical terminals, they must be represented by abstractions. The primary characteristic of the abstract terminal is its identity. !he identity is known within I!S/YS as the "lcgical terminal name" or simply as "logical terminal."
2.46 IMS/VS System/Application Design Guide
I~
THE IMS/VS LOGICAL TERMINAL
Each logical terminal within IM5/VS has a unique set of attributes. A description of the attribute~ constitutes a partial description of the features available thrcugh use cf the lcgical terminal concept.
· Current Fhysical terminal assignment -- this characteristic may be dynamically altered for reasons of terminal resource managEDIent. Once a signon has teen acce8Flished by cennecting a logical terminal to a physical terminal, the functions and services available are the same as those for a nenswitched terminal.
· Security authorization -- can be unique for each logical terminal in the system or can represent a security level or group.
· Next logical terminal assignment -- multiple logical terminals can be associated with a single physical terminal. This provides, in conjunction with security, the ability to uniquely identify multiple users of a single Fhysical terminal.
Logical terminals can be assigned to physical terminals for output and input purFoses. When a logical terminal is assigned to a Fhysical terminal for outFut purFoses, all messages sent to that logical terminal are transmitted- to its associated physical terminal.. More than one logical terminal can be assigned tc a given Fhysical terminal for output FurFoses.. Only one physical terminal can receive the output for a given logical terminal. the diagram belcv shows the relationship between physical and logical terminals for output purposes:
Physical Terminal
Logical Terminal
Logical Terminal
When a physical terminal is assigned to a logical terminal for input purposes, any message entered frcm the Fhysical terminal is considered to have originated at the logical terminal.. When more than one logical terminal is assigned tc a Fhysical terminal for inFut purposes, a chain of input logical terminals is formed. Any input from the physical terminal is considered tc have criginated at the first logical terminal on the chain. If, for some reason (such as security or a stopped logical terminal), the first logical terminal is not allowed to enter a message, all logical terminals en the input chain are interrogated in chain sequence for their ability to enter the message.. If the physical terminal is a 31iC or a 3iEl, cnly the logical terminals associated with the input component are scanned.. The first appropriate logical terminal found is considered the originator of the message. If no appropriate logical terminal is found, the message is rejected with an error message. The diagram belcw shcws the relationshiF between physical and logical terminals for input purposes:
Design and Centrol of a DB/DC system 2.47
C
.. Physical Terminal
INPUT CHAIN
.. logical Terminal
---'"
logical Terminal
Use of a queue for input messages received or pending output messages enables the application tc be independent of time of arrival or transmission of messages. Association of the queue with the logical rather than the physical terminal permits it to be moved, independent of the application, from device to device. Within restrictions, it permits a queue of messages to be mcved even among device classes.
The logical terminal prevides a stable platferm or reference for the application program. Regardless of how the physical terminal network changes, the application remains insensitive. !o the application program, a logical terminal can be viewed as just another sequential data input sourCE er eutput destinatien.
The application program interface to the logical terminal is through the same call interface mechanics descrited for the DB system.
When 2980 terminals are defined, IMS/VS uses a logical terminal to define the 297~ eommen tuffer. !his is an exception to the physical terminal/legical terminal relationship, in that the 2972 commen buffer is not a physical terminal in the conventional sense.
LOGICAL TERMINAL NE!~ORK DESIGN
Design of a logical terminal network can be as important as design of a physical terminal network. It has potential impact upon systel security, maintainability, and usability. Careful consideration should be applied from each viewpoint.
System SEcurity administration can be hampered by not providing an appropriate number cf logical terminals through which proper terminal security authorization ~ay be applied. Too few logical terminals limits the number of unique security authorization~. Too many may prove cumbersome or ineffective in achieving security objectives. A judicious comtination of passwcrd and logical terminal security can reduce the number of logical terminals required to administer security policy.
Where a community of users deals with multiple applications through a common set of physical terminals, output volumes, schedules, priorities, human factors, and terminal availability are some of the more imFortant usability factors to consider. If priorities require that management or supervision have ready access to terminals ordinarily used fer operational purposes, then ~rovisioD must be made for interrupting operational work. A physical terminal might have two logical terminals ordinarily assigned -- CDe fer c~erations, one for priority work. Authorization of the /lCCK command to the priority logical terminal would enable it to stcp inFut and output from the operations terminal. Further discussion of the security p1an~in9 for this particular case may be found under the topic "Security and Privacy" in this chapter. It is mentioned here to illustrate several of the aspects of logical terminal network planning. ~he same solution to the security or pricrity aSFect, that is, multiple lcgical terminals, can be applied if the control of output volume is a problem.
2.48 IKS/VS Syster/Applicaticn Design Guide
Where particular applications make use of device class dependent
functions, such 8S curser ccntrol, it might be useful to specify a separate set of logical terminals which have a relationship to that group of applications. Calling the application group an application class and the logical terminal group a logical terminal class, it is possible through lcgical terminal security to associate all input and output relationships with a known set of logical terminals. At the same time, non· device-class sensitive transactions may be used through non-specific logical terminals fro~ the same physical terminals. Processing applications are insensitive to ihe separation. The following example (figure 2-E) illustrates this use of logical
terminals:
PHYSICAL TERMINAL
LOGICAL
TERMINALS
APPLICATION
r----'
/ 1) ,
_ AAA _
r-.......
..J
,--
'~I
-
--I
1 DEVICE
,/ L---
!L ____ 'I x
CLASS
I
I SENSITIVE J
/
/
D
NOT DEVICE
CLASS
SENSITIVE
Figure 2-6.. Separating Device Class Sensitive Terminal I/O
70 establish such a relationship requires defining two logical terminals for each physical terminal, then securing the transactions destined for application X through logical terminals AAA and CCC. The common entry security for AAA and CCC cculd be referred to as a device class sensitive security group. All logical terminals defined for that purpose would then te secured in the same group.
In certain applications it may be necessary to associate a different physical device for output than the one ordinarily used for input. Conversely, certain physical terminal types are input-only devices. If output is required, a different device must be associated with this type for output. IMS/VS system definition and ccmmands support assignment of cutput devices different from the input device. The allowable physical/logical relationships which can be expressed are shown in figure 2-7.
Design and Centrol of a DB/DC System 2.49
PHYSICAL TERMINAL
LOGICAL TERMINAL
~I--.~--.~~
L -________
APPLICATION
NORMAL ASSIGNMENT OF ONE OR MORE LOGICAL TERMINALS! PHYSICAL TERMINAL, OUTPUT GOES TO INPUT TERMINAL· APPLICATION INSENSITIVE
ALTERNATIVE ASSIGNMENT, INPUT AND OUTPUT THROUGH SAME LOGICAL TERMINAL, OUTPUT TO DIFFERENT PHYSICAL TERMINAL· APPLICATION INSENSITIVE
APPLICATION INSENSITIVE TO INPUT, USES SPECIFIC LOGICAL TERMINAL FOR OUTPUT
Figure 2-1. Possible Physical/Logical Terminal Relationships
!2n2Wi1£~!d ~2milni£!ii2n2 !!t~2~: The best way to describe the relationship between a terminal user, a physical terminal, a commanication line, and a logical terminal is a diagram:
I USER
I ·
.. .. PHYSICAL TERMINAL
.. I NON SWITCHED
I ·
I J COMMUNICATION LINE
r------ IMSNS --,
I
I ..
LOGICAL TERMINAL
I
~
I
I
I I "- _ _ _ _ _ --J
IMS/VS system definition describes the characteristics and relationship of physical terminals, communication lines, and logical terminals. On a nonswitched communication line, the relationship between a physical terminal at one end and a logical terminal within 185/VS at the other is a stable relationship defined at system definition time. If there is only one user of a particular physical terminal, typically there would be a one-to-one relationship betwe~n physical terminal and logical terminal. However, if a physical terminal is operated by multiple users, it can have many logical terminals associated with it. 1M5/VS system definition might include a separate logical terminal for each user of a particular physical terminal.
The relationship established between a physical terminal and one or more logical ter.inals at system definition ~an be changed through the command language or by a new system definition. The /AS5IGN command
2.50 IMS/VS System/Application Design Guide
changes logical/physical relationships dynamically. It is normally executable only from the master terminal.
2!ii£h~~ ~~ic!i!2~ H~i~~£!: The logical/physical terminal relationship on a switched communications network is considerably more complex than in the nonswitched communication line environment. IMS/VS system definition defines the characteristics of a physical terminal, communication lines, and logical terminals. However, the relationship between a particular physical terminal and a logical terminal is not established until the remote terminal user dials the System/370 computer to communicate with IMS/VS. The relationship between a terminal user, a physical terminal, a communication network, and logical terminals at system definition time is depicted in the following diagram:
~________~I~"'~--~·I..___ ~ _ USE~
~
..
TERMINAL
PH_Y_S_I_C_A_L__
LINES
~
/~,
r - - -IM-SN-S - - ,
O /'
--
2 - - "---II
LOGICAL TERMINAL
III
'''0/ :
,
·
I --t
~IL
_____ _
J
Once the remote terminal user dials in to the ~omputer and issues the
/IAK command to sign himself on to IMS/VS, a stablp. relationship between
'(,-,
the physical terminal and one or more logical terminals is established.
SIGNED-ON USER
PHYSICAL TERMINAL
·
r--- -- IMSNS --,
LINE
I
I
J 0-t-~----1I--1 LOGICAL
I,..
TERMINAL
I
I
L ________
In a switched communications network enVironment, one logical terminal per line is created automatically as the inquiry logical terminal. In addition to the physical line/terminal definition, and the automatic creation of the inquiry logical terminal, a pool of logical terminals can be defined at system definition time. When a remote terminal user dials into IMS/VS, an IIAM command can be issued which associates logical terminals from a pool with the physical line and physical terminal issuing the /IAM command.
Within any logical terminal pool for a switched communications network, the IMS/VS user must define one or more logical terminal sub pools. A logical terminal subpool is composed of one or more logical terminals within a given logical terminal pool. A particular logical terminal can exist in only one pool and subpool. A remote terminal user can dial the IMS/VS system and sign on for a single logical terminal or all logical terminals within a logical terminal subpool. At system definition, the environment appears as indicated in the following diagram:
Design and Control of a DB/DC System 2.51
REMOTE TERMINAL USER
· ·
PHYSICAL TERMINAL
,
/
I
1/./
f\
······
r--------.,
I
I I
r- -
-- ---,
I
LOGICAL
-
INQUIRY LOGICAL TERMINAL 1
,......_ _ _-~-
I
TERMINAL POOL
I
I
r-----'
I LOGICAL I
I
I TERMINAL I
I SUBPOOL I
I
- - _ _ _ _ _ 01
- - INQUIRY LOGICAL TERMINAL 2
--~ I
--~
I
r - - - - ' I LOGICAL I
I TERMINAL I SUBPOOL
I..... ---_ ....I
_-1 ..... -----
- - ~-.....::;~..,
INQUIRY LOGICAL TERMINALN
I I
r------, I r-----'
I I I LOGICAL I
I I
I I
I TERMINAL I
L _SU_BP_OOL_ ....I.
I I
r-----'
J I
I I I
I I
I I
I LOGICAL I TERMINAL
L _SU_BPO_OL_
II
I L ______ ....
"--------
After a remote terminal user has dialed the System/310 computer
operating under IMS/VS, several situations can exist. If the IIAM command is used to sign on and the LTERM parameter specifies ~he inquiry
logical terminal, the following diagram applies:
REMOTE INQUIRY USER
PHYSICAL TERMINAL
IMSNS
r------,
.. .. LINE
II..- INQUIRY
\fJ':-:-\IIIII----I...·
LOGICAL TERMINAL
I
FOR LINE X
:
I I
L. _____J
If the IIAM command is used to sign on and the LTERM parameter specifies a logical terminal from the logical terminal subpool, the following diagram applies:
2.52 IMS/VS System/Appiicatior Design Guide
REMOTE TERMINAL USER
PHYSICAL TERMINAL
IMSNS
r - -------,
8 --.-...-- LINE
I LOGICAL
L.., TERMINAL
I
FROM
I I I
POOL
I I L... _ _ _ _ --J
REMOTE TERMINAL USER
PHYSICAL TERMINAL
r-----l
o · ~~~~iLS LINE
I
I
~--"""Il_1 ~~BPOOL I
I
I
I' - - - - _ ......I
If the /IAM command is used to sign on and the LTER! and PTER~ parameters are specified, all logical terminals within a subpool are associated with the physical terminal.
The use of the logical terminal subpool concept allows for efficient use of communication facilities. All output queued on each of the logical terminals in the subpool for which the /IAM command was issued is sent to the physical terminal.
A subpool can be defined to contain the logical terminals for all of the users of a single physical t~rminal. While a user is signed on to a logical terminal within the subpool, the subpool is una.vailable to users signing on from other physical terminals.
All inguiry logical terminal names must begin with INQU. When signing on for an inquiry logical terminal, only these first four characters are considered significant by IMS/VS. This lets a user call any autoanswer line and sign on for, and use, the inquiry logical terminal (for inquiry transactions only), if he is aware of the INQU prefix. The inquiry logical terminal can only be used for non-update transactions, and queued output is preserved only while the user is signed on. So that IKS/VS can distinguish inquiry logical terminal names from subpool logical terminal names at the time a user signs on, no subpool logical terminal name can begin with INQU.
The master terminal is the IMS/VS control center. It must be either a 1050, a station-controlled 2740, a 3270, a 3767, or a 3110. If a 1050 or 2140 is used, it must be attached through a non-switched polled communications line. A 3210 master terminal can be attached locally or through a non-switched polled line. The IMS/VS provision for a 3110 master terminal is intended for the 3110 console component. The non-console components will not operate correctly if they are used as the master terminal.
The master terminal operator must know all the operating aspects of the system. The physical location of the master terminal in relation to the computer console is important. If, for security reasons, they are not close, telephone communications should be provided.
The details of starting the system, checkpoint, restart, and all commands available to the master terminal operator are in the !n~L!~
QE~rai2~~§ lief~~!~~ ~~~g~!.
Design and Control of a DB/DC System 2.53
SYSTE~ CONSOLE SUPPORT
IMS/VS provides support for the OS/VS system console using the OS/VS write-to-operator (WTO) and write-to-operator-with-reply (WTOR) facilities. All functions available to the IKS/VS master terminal are available to the system console. The system console and master terminal can be used concurrently, to control the system. Usually, however, the system console's primary purpose is as a backup to the master terminal. The system console is arbitrarily defined as 1MS/VS line number one.
SYSTEMS WITH INOPERABLE MASTER TERMINAL
IMS/VS requires a master terminal be defined for its use during 18S/VS system definition. Under certain conditions, however, it may be impractical to provide a master terminal facility; for example when the 210X line is inoperable. In these instances, the OS/VS system console can be utilized to replace the IMS/VS master terminal. If desired, the master terminal DD statement can be omitted. If the master tArminal is inoperable, messages will continue to be routed to it until they are routed to the system console or another terminal with the /ASS1GN command. In addition, all of the functions ordinarily performed at remote operational terminals can also be performed through the System/310 console.
Through the Message Format Service (MPS), a comprehensive facility is provided for 18S/VS users of 2140, 2141, 3210, 3600, 3161, and 3170 devices. MFS allows application programmers to deal with simple logical messages instead of device dependent data; this simplifies application development. The same application program may deal with different device types using a single set of editing logic while devicA input and output are varied to suit a specific device. The presentation of data on the device or operator input may be changed without changing the application program. Full paging capability is provided for display devices. Input messages may be created from multiple screens of data.
A program using MFS need not be concerned with the physical characteristics of the device used for input and output messages unless it wants to use certain very specific device featnres. Eyen when these features are utilized, the program can request functions in a logical manner; no device control characters or orders may be sent directly from the program or may be received by the program. The presentation of data on the device may be changed without application program changes. Both logical and physical paging facilities are provided for the 3210 and 3604 display stations; this allows the application program to write a large amount of data that will be divided into multiple screens for display on the terminal. The capability to page forward and backward to different screens within the message is provided for the terminal operator. The conceptual view of the formatting operations for messages originating from or going to an MFS-supported device is shown in Figure
~L
2.54 IMS/VS System/Application Design Guide
MFS Supported Device
MFS
IMSIVS Application Program
MFS
MFS Supported Device
Device Input
Input Message
Output Message
Device Output
Figure 2-8. Message Formatting Using MFS
M?S has three major compo~ents:
· MFS language utility
· MFS pool aanager
· Message editor
The MFS language utility is executed offline to generate control blocks and place them in a format control block data set named IHSYS.FORKAT. The control blocks describe the message formatting that is to take place during message input or output operations. They are generated according toa set of utility control statements specified by the IMS/YS system designer. There are four types of format control blocks:
· Message input descriptor (MID)
· Message output descriptor (KOD)
· Device input format (DIF)
· Device output format (DOF)
The KID and MOD blocks relate to application program input and output message segment formats, and the DIP and DOF blocks relate to terminal I/O formats. The MID and DIF blocks control the formatting of input messages, while the MOD and DOF blocks control output message formatting.
The message editor and MFS pool manager operate online during the normal production mode of operation. The message editor performs the actual message formatting operations using the control block specifications. The MFS pool manager controls residence in the main storage MFS buffer pool of the format control blocks required by the message editor. Efficient use of available pool space is provided by look-ahead fetching of required control blocks from direct access storage, and by maintenance of last-referenced format control block chains for reuse of pool space.
Tvo other MFS components, a MFS service utility and a MFTEST pool manager are available to support optional MFS operations.
The MFS service utility provides a method for additional control of the for, at control block data sets. It executes offline and can be used to creata and maintain an index of control blocks for online use by the MpS pool manager.
The MFSTEST pool manager replaces the MFS pool manager to support the optional MFSTEST mode of operation. The IMS/VS /TEST MFS command can be used to place online MFS terminals into MFSTEST mode during which new
Design and Control of a DB/DC System 2.55
applications and modifications to existing applications can be exercised without disrupting production activity.
Figure 2-9 provides an overview of major ~FS operations. The circled numbers reference notes that indicate major distinctions in MFS processing when the MFSTEST facility is used. The i~~L!~ ~!~~~g! r~~~t ~ty!£! ~~~t~~ ~~i~! provides a complete description of MFSTEST facility.
PROVIDED BY MFS APPLICATION
DESIGNER
OFFLINE EXECUTION
ONLINE EXECUTION
MFS TERMINAL
Message and Format Control Statements
G) Message/
Format language
Utility
0 MFS
1--......, Buffer
Pool
Service Utility Control
Statements
MFS
0
Pool Manager
MFS
Message
Editor
Message Queue
MFSTEST DISTI NCTIONS
1. Can execute concurrently with the IMS/VS online control region only in MFSTEST mode. 2. Replaced by IMSVS. TFORMAT in MFSTEST mode; IMSVS. FORMAT is available as secondary source of
control blocks in MFSTEST mode. 3. The communication line buffer pool is used in MFSTEST mode. 4. Replaced by MFSTEST pool manager in MFSTEST mode. 5. Terminal operator must use /TEST MFS command to enter MFSTEST mode.
Figure 2-9.
Overview of ~essage Format Service
The I~S/VS Message Format Service (MPS), d~scribed in the previous section, is used exclusively to format data transmitted between IMS/VS and the devices of the 3270 Information Display System. MPS provides a high level of device independence for the application programmers and a means for the application system designer to make full use of the 3270
2.56 IMS/VS System/Application Design Guide
I~
If ~
device capabilities in terminal operations. The I~~L!~ ~!§§ag! E2~m~t ~!~!i£! U~~!§ gYi~! contains a complete description of MFS.
3270 COpy FUNCTION
When an IRS/iS system is defined to include printer components of the
3270 Information Display System attached through a polled asc or SDLC
line, it is possible to allow through IMS/VS an automatic or operator-controlled hard copy of the vid~o output (or input) to be sent to a 3210 (3284, 3286, 3281, 3288, or 3289) printer. This hard copy can be requested through the use of the SCA field in the application program's output data, the definition of the message (see I~~l!2 n2§2~g! !::2~nt ~!~!.i£! !l2!!:.!2 g!!i~!), or by operator action. The hard copy listing is produced on an appropriate printer, which must be attached to the same 3210 control unit (3271/3214 or 3275/3276) as the display station containing the information to be copied. If a request is sent to a terminal that is not defined as allowing the copy function, or that does not support the copy function (3270 local attachment), the request for the copy function is ignored.
For a complete description of terminals supporting the copy function see the I~ 1~lQ Iuf2~m~!i2U ~i2E!~Y ~Y§t!m ~2mE2U!U! Q~2£~iEt12n
1!~nY~!·
The format of the printed output can vary from that on the display station as a result of blank lines (or null lines), which are ignored by some models of the 3284, 3286, 3287, 3288, or 3289 printers. In all cases, the buffer size of the printer must be equal to or larger than the buffer size of the display station to be copied (3215/328~ Model 3 has no printer buffer and this consideration does not apply).
When printers are attached to a 3271/3274/3276 the IMS/VS system definition process determines which printers are eligible to receive the hard-copy output of a copy operation. These printers are called candidate printers. When a copy operation is requested by the operator or an application program, the candidate printers are searched in a predetermined order to find a printer that can be used. The firs~ printer that is not stopped, is not currently printing a message, is not in exclusive status, and is ready, is used. If the operator made th9 copy request and all printers are busy, the keyboard on the display station is left inoperable until a printer is available and the message is successfully copied to the printer. If the copy request is from an application program and all printers are busy, the message is not displayed until a printer becomes available. This prevents the operator from altering the data to be printed before the message is successfully copied to the printer. If no candidate printers are currently available, an appropriate error message is sent to the display station requesting the copy operation. If the copy operation was requested by the application program or the format description (DE V statement, DSCA operand), an attempt to send the message will be retried when the error message is cleared from the screen through the ~essage Advance Function (see section "3270 Information Display System" in the I~~L!~ QE!~~12~~§ R~I~£~~£~ ~~~~!). If the copy function was requested by operator, the operator can ready the candidate printer(s) and retry the copy operation.
Candidate printers for a particular display station result from the way the physical terminals are defined during IMS/VS system definition. Candidate printers for a display station must be defined after that display station but before any other display station-printer groups. Other display stations can intervene between a display station and its candidate printers, but other display station-printer sequences cannot intervene. For example, in Figure 2-10, PTERM 1 might be a 3275 with its own dedicated printer. If PTERM 2 and 3 allow the copy function,
Design and Control of a DB/DC System 2.57
then PTERMs ~ and 5 will be the candidate printers for these PTERMs. If PTERM 6 is allowed to use the copy function. then PTERM 1 viII be the candidate printer for PTERK 6. Note that the candidate printer PTERM 1 will not be used fer copy functions from PTERKs 2 and 3. nor will candidate printers PTERKs 4 and 5. be used for copy functions from PTERK 6. And. in non-VTAK environments. the copy function is not permitted across line, linegroup. or 3210-control-unit boundaries.
3275 WITH 3284 MODEL 3
.......................................... PTERM 1
3277 MODEL 1
.........................................
PTERM2
3277 MODEL 1
..........·..·.·.·........................ PTERM6
- 3284/3286 MODE L 1 D
PTERM7
3271, MAY BE ON SAME 3271 AS PTERMS 2.
3, 4AND 5
3277 MODEL 2
~
--------------- PTERM 3
.....................
3284/3286 MODEL 2
3271
D
PTERM4
3284/3286 MODEL 2
D
PTERM 5
Figure 2-10. 3210 copy Function Exa~ple
3284 MODEL 3 PRINTER SUPPORT
The 3284-3 printer. when attached to a 3275. is supported by !MS/V5 as a component of the 3215 terminal. Messages are sent to the two components on a rotating basis. as with any component-type terminal. If no messages can be sent to the printer component. messages are sent continuously to the display component. just as if no printer component existed. If no messages can be sent to the display component, messages are sent to the printer as though the display component did not exist. As long as messages can be sent to the printer. no operator intervention is required. When a message is sent to the display component while messages are enqueued for the printer. the operator must intervene to allow either further display output or printer output. Any situation (such as a stopped LTERM or an inoperable printer) that prevents the sending of messages for the LTERK(s) assigned to a particular component causes message transmission to cease to that component.
2.58 IMS/VS System/Application Design Guide
3210 KASTER TERMINAL SUPPORT
IMS/VS supports a 3210 terminal as a master terminal. A 32~Q master terminal consists of two 3210 components: a 3210 display (3275/3211/3216/3278) and a 3270 printer (3284/3286/3287/3288/3289). The 3215 with an attached 3284-3 is not supported as a 3210 master terminal.
When IMS/VS uses a 3270 master terminal, all messages are routed to the display component. Selected system-generated messages, critical to INS/VS operation, are also sent to the printer component.
A 3270 display selected as the master terminal must have a 24-line 80-column display screen to allow the use of the MFS master terminal formatting option. For additional details, see "MFS Formatting for the 3270 or SLU Type 2 Master Terminal" in the I~§L!§ ~§§!g~ !:2t!lll §!rvi£~
!!~!:!.§ ~l:!!g~.
IMS/VS provides for attachment of a System/3 Kodel 10 and System/1 using the IRSS (intelligent remote station support) interface. The interface provides a remote station with powerful tools to control the flow of data between a System/310 and terminals attached to the intelligent remote station. This interface provides the definition of transmission block formats. A primary purpose for these formats is to define message transmission associated with one or more terminals attached to the intelligent remote station. These Intelligent Remote Station formats are described in detail in the I~§L!§ §Y§i!!l ~t2gt!m!l!ng
R~'itin~ ~!nl:!!l·
Conversational processing as well as presetting of destinations are available to terminals attached to the remote station. IKS/VS provides the facility of routing transaction responses to the originating source as veIl as to alternate destinations without application program involvement. IMS/VS provides a restart facility for the remote station by logging and retransmission of appropriate block and message identifiers.
TRANSMISSION BLOCKS
Two types of transmission blocks are defined in the IRSS interface. The data block type is used to carry message segments. The synchronization block type is used to carryall other required information such as shutdovn, restart, status change, ask for output, and dequeue output.
Each data block contains a block identifier containing, in four bytes, information that can be used by the remote station to restart its transmission of data to INS/VS, if it has a restart facility. The content of this identifier is up to the remote station, but if the same identifier appears in the first data block received by IKS/VS as was contained in the restart message, after INS/VS has transmitted a restart message, IKS/VS consiaers the block retransmitted and vill scan for a restart point as described below.
Each data segment in a data block contains a message identifier. This one byte messag~ identifier contains information that enables the remote station to identify a message or segment within a block. In addition, IMS/VS appends the message identifier from a segment in error, if an error message must be transmitted by INS/VS to the remote station due to an error discovered while processing a segaent. The message identifier is also contained in restart messages and can be used by the
Design and Control of a DB/DC System 2.59
remote station to restart its transmission of data because it indicates the last complete message processed by IMS/VS within the identified block.
The message identifier is used by IMS/VS to scan for a restart point if a block was retransmitted after restart. IMS/VS scans the received block until a segment with the same message identifier as in the restart message, and which is flagged as the last segment, is found. IMS/VS then starts processing with the segments following the one found, if any. The entire block is discarded if no segment that meets the above specifications is found. Cold start messages do not contain block and message identifiers since none are available, but they imply binary zero identifiers. Therefore, the remote station should not use a block identifier of binary zeros in the first block transmitted to 1KS/VS following a cold start message from IMS/VS, or the block will be ignored.
A two-byte terminal identifier is used by the IRSS interface for destination control. The terminal identifier used in communication with IMS/V5 must be defined when performing the 1MS/VS system definition. The TERMINAL macro is used for this purpose. IKS/VS treats each defined terminal identifier as a physical terminal. Since IMS/VS has no knowledge about the actual physical terminals attached to a remote station, there is no requirement that the terminal identifier correspond to a physical terminal address. The number of physical terminals attached is also independent of the number of terminal identifiers specified. The terminal'identifiers employed by 1KS/VS IRSS provide a means of extending all IMS/VS facilities characteristics of a physical terminal to any logical destination within a station supported by IRSS. Since IKS/VS has no knowledge of the terminal itself, this designator can be used to accomplish a variety of application-dependent functions; for example:
· Routing to specific terminals or devices in the remote station
· Scheduling of specific application programs within the remote
station
· Batch-type terminal support similar to 2110 or 2180 terminals by proper definition of the remote station I/O components
· Data collection from a variety of I/O devices into a single stream identified to IK5/VS as a unique terminal for specific IKS/V5 application program processing
Prior to the enqueue of a message received f=om a remote station, IMS/VS logs the identifiers pertaining to the last block and segment of the message. This information is also kept in the communications restart block (CRB) and is restored by restart. The identifiers, pertaining to the last message enqueued, are transmitted to the remote station in all types of restart messages except the cold start message.
SYSTEM/3 AND SYSTEM/1 PROGRAM FUNCTION REQUIREMENTS
The IKS/VS support for System/3 and System/7 does not include a program residant in either computer. The IKS/YS user must supply this program. The user's program residing in the. System/3 or the System/7 must be able to handle at least the following parts of the IRSS interface:
· Transmission control
· Data blocks
2.60 IMS/VS System/Application Design Guide
· Immediate shutdown request from I85/VS
· 5end output complete message to I85/VS
It is recommended that the program be capable of recogn1z1ng error messages. All other information provided by IMS/VS can be used or ignored at the discretion of the user.
!~§L!~ ~Y£i~ ~!~~g!!
IMS/VS system messages contain a message identification whose first three characters are DrS. The IRSS support extracts the number from the message, in case of an error message, and builds a synchronization block. All user initiated messages should be set up so they cannot be confused with an I8S/VS system message.
TRANSMISSION CONTROL
IMS/V5 receives transmission blocks from a remote station in input mode and transmits blocks to a remote station in output mode.
IMS/VS may request the line to do the following while in input mode:
· Transmit error messages pertaining to received data.
· Transmit command completed messages pertaining to received commands.
· Return a test message it a terminal has been placed in test mode through the ITEST command.
· Transmit an immediate shutdown request message.
IM5/VS causes a reverse interrupt sequence to be transmitted if any
of the preceding conditions occur when in input mode. 1M5/VS then accepts one additional input block after transmission of the reverse interrupt. An attempt to transmit more than one block results in a
transmission error and the station is logically deactivated.
Error messages and shutdown request messages are transmitted using the appropriate synchronization block. Command completed messages and test messages are transmitted using data blocks.
A message transmitted by 18S/VS in output mode must be removed from the queue through a request from the remote station. This is done to ensure that no message is removed from the 18S/VS queue until it has reached its final destination at the remote station. The request to remove a message is made using the appropriate synchronization block. This can be performed at any time after the last segment of the message has been received by the remote station but before any message is transmitted to 1MS/VS using the same terminal identifier. IMS/vS retains an output message in progress on the queue if an input message
is received for the same terminal identifier, even if the last segment has been transmitted but the remove request is not received.
The remote station can transmit an error message to IMS/VS at any
time after the first segment of the message has been received, but
before it is removed from the queue or retained on the queue because of
an input message. An error message causes the logical terminal, on
which the message is queued, to be stopped and a message sent to the
master terminal. The message is retained on to the queue. Error
L
messages are transmittted using a synchronization block. Messages transmitted by IM5/VS while in input mode are not queued and, therefore,
Design and Control of a DBIDC system 2.61
cannot be removed from a queue. Conseqnently, the remove from queue message should not be sent.
Any error detected in the interface between IMS/VS and the remote station results in logical deactivation of the remote station by an EOT.
SYSTEM DEFINITION
The System/3 and System/7 are defined using the STATION macro. Included in this macro are the station's polling address (if applicable) and the station's operating modes.
Three operating modes may be defined in any c~mbination:
· Postpone type -- non-postpone type · Ask type -- non-ask type · Transmission limit -- no-transmission limit
A System/7 station on a start/stop line has the added definition of output transmission code modes. The station can be defined to require all data blocks to be transmitted in PTTC/EBCD code, pseudo-binary PTTC/EBCD code, or to allow I8S/VS to determine the code.
A station defined as postpone type is started with the postpone output flag set in all defined terminals. The remote CPU must send the resume output I/O synchronization block to IMS/VS to receive output.
A postpone type station has the advantage of specific terminal output requests by the user program in the remote CPU. This function can conserve resources within that system.
To allow the user's program to control when to receive blocks from IHS/VS, the station can be define~ as ask type. After the restart message has been transmitted by IdS/VS, IKS/VS waits to receive an ASK message before transmitting anything else. The ASK message is sent by a remote station to inform IKS/VS that the station is ready to receive. This message is required:
· After IMS/VS has transmitted the NO-OUT message (I/O synchronization message flag value X'OS') to the remote station.
· Aft~r IMS/VS has transmitted a user specified number of blocks to the remote station. This count is reset each time an ASK message is received. Messages sent following a LINE TURN AROUND requested by IMS/VS are not counted.
IMS/VS transmits blocks according to normal rules after an ASK message. has been received. When all available output that can be sent has been sent, IMS/VS transmits the NO-OUT I/O synchronization message. IMS/VS then waits to receive an ASK message before transmitting any further output. The transmission of the NO-OUT message can be preempted by reaching transmission limit. The ASK message is an I/O synchronization message with flag value X'10'. The NO-OUT message is an I/O synchronization message with flag value X'08'. The format of these messages is described in chapter "Communication with Intelligent Remote Stations" in the IMSLll §.Y2i~ R!:2g~~!l!!ing ~~t~t:~n~~ ~~DJ!~!.
2.62 IMS/VS System/Application Design Guide
IMS/VS system definition allows for the specification ~f a transmission limit for each remote station defined. The transmission limit is the maximum number of transmission blocks, excluding the block transmitted following a reverse interrupt sequence and the shutdown synchronization block, that IKS/V5 will send in output mode between remote station initiated resets. The remote station uses the ASK message to perform this function. The ASK message is sent by a remote station to inform IMS/VS that the station is ready to receive. The transmission limit defined to IKS/VS should be the number of buffers in the remote station minus one, because IMS/VS may be required either to transmit blocks to the remote station while in input mode (see the description under "Transmission Control" in this chapter) or send a shutdown synchronization block while in output mode. This message is required:
· After IMS/VS has transmitted the NO-OUT message (I/O synchronization message flag value X'08') to the remote station.
· After 1M5/V5 has transmitted a user specified number of blocks to the remote station. This count is reset each time an ASK message is received. Messages sent following a LINE TURN AROUND requested by IMS/VS are not counted.
The transmission limit can range from 1 to 15, or be defined as zero, indicating unlimited transmission.
The three re~ote CPU operating modes can be defined in any
L
combination. The presence (or absence) of postpone type does not impact IMS/VS function. IMS/VS function does vary, however, when ask type and/or transmission limit are specified or are not specified.
The flowcharts below show IMS/VS function for the possible combinations of operating modes:
· Basic (non-ask type, no-transmission limit) · Ask-type, no-transmission limit · Non-ask type, transmission limit · Ask-type, transmission limit
Design and Control of a DB/DC System 2.63
Basic (non-ask type, no transmission limit)
* - - ) *'**" ***T*RBANB1L*SOM*C*IKT***A******* *********************
IMS/VS wILL START TRANSMITTING OUTPUT AS SOON AS THE LINE IS AVAILABLE AFTER AN OUTPUT MESSAGE H~S BEEN EN'UEUEC o
v
C10*0 *0
o· *Y--E-S*00* *
0* MORE *0 OUTPUT
AVAILABLE?
0
0
**00*
*" *0 *0*NC
IMS/VS CONTINUES TR~NSMITTING AS LONG AS THERE IS OUTPUT AVAILABLE THAT ~AY eE SENTo I~S/VS TRANSMITS CNLY O~E MESSAGE FeR A GIVEN TERMINAL IDENTIFIER REGARDLESS OF THE NUHfER OF MESSAGES ENQUEUED o
V
*****D1**********
***RESET THE LINE *'"
'**" *****************'"
I~S/VS TRAN5MITS EDT Te TERMINATE TR~NSMI SSICNc
J
2.6~ I"S/VS system/Application Design Guide
*****81**********
** TRANSMIT A **
*--)*
BLOCK
*
*********************
IMS/VS ~ILL START TRANSMITTING GUTPUT AS SOON AS THE LINE IS AVAILABLE AFTER AN "ASK" FOR OUTPUT MESSAGE HAS BEEN RECEIVED.
" C1 .*.*.
YES.* .*OUMTOPRUET *. *.
*---*. *.A*V.A*I.LA*B.*LNGE.*? .*.*
I~S/VS CONTINUES TRANSMITTING AS LONG AS THERE IS OUTPUT AVAILABLE THAT MAY BE SENT. IMS/VS TRANSMITS ONLY ONE MESSAGE FGR A GIVEN TERMINAL IDENTIFIER REGARDLESS OF THE NUMBER OF MESSAGES ENQuEUED.
V
,**. * * * *TR0 1A*N*S*M*IT* * * * ****
* *
"NO-GUT" MESSAGE
* *
*******************
IMS/VS TRANSMITS A SYNCHRONIZATION BLOCK INDICATING TO THE REMOTE CPU THAT NO OUTPUT MESSAGES. THAT MAY BE SENT. ARE CURRENTLY AVAILABLE.
V
*****E1**********
***RESET THE LINF. *** *********************
IMS/VS TRA~SMITS EGT TG TERMINATE TRANSMISSICN.
Design and Control of a DB/DC System 2.65
Non-ask type, transmission limit
*****81**********
** TRANSMIT A
*~->*
BLOCK
***
*********************
IMS/vS WILL START TRANSMITTING CUTPUT
AS SOON AS THE LINE IS AVAILABLE AFTER AN OUTPUT MESSAGE HAS BEEN ENQUEUED.
.* .*CR1EA.*CvH.E*D. *. *. YES
*.T*R.A*NL. S*IMM. *IIST.S*?NIO.O*N.* .*---*
IMS/VS CONTINUES TRANSMITTING AS LONG AS THER~ IS OUTPUT AVAILABLE, THAT MAY BE SENT! UP TO A USER SPECIFIED NUMBER CF TRAN~MISSION SLeCKS. IMS/VS TRANSMITS ONLY ONE ~ESSAGE FOR A GIVEN TERMINAL ICENTIFIER REGARDLESS OF THE NUMBER OF MfSSAGFS EN'UEUfD.
Y~S
*---
*
.
.
* ·*O01U~OT.RP*vUE. T*·*. *.A*V.A*I.LA* B. N*LC.E
?*.
** ..*
(------
V
J
*****E1**********
***RESET THE LINE ***
IMS/VS TRANSMITS EOT TO TERMINATE
TRAt-.SHISSION.
I *********************
2.66 IKS/VS System/Application Design Guide
Ask type, transmission limit
*****81**********
** TRANSMIT A *
*-->*
BLOCK
*
·**· ·* . * · · *.**** · · **·
IMS/VS ~ILL START TRA~SMITTING OUTPUT AS SCaN AS THE LINE IS AVAILABLE AFTER AN nASK" FOR OUTPUT MESSAGE HAS BEEN RECEIVED.
.. v C1 ··· *. "'.
·· REACHED "'. YES
*.T*R.A*N.LS·IM·MIITS.S*?I.O*N.'" .*---*
i"C
IMS/VS CONTINUES TRANSMITTING AS LONG AS THERE IS OUTPUT AVAILABLE} THAT MAY BE SENT, UP TO A USER SPECIF ED NUMBER OF TRANSMISSION BLOCKS. IMS/VS TRANSMITS ONLY ONE MESSAGE FOR A GIVEN TERMINAL IDENTIFIER REGARDLESS OF THE NUMBER OF MESSAGES ENQUEUED ·
·
.*V.
*01MORE
*·
*
.
Y-E-·S·.**A. *VO.AU*I.LTAP*UB.*TNLOE.·? ."*'..*
IJ
*.*.*El********·*
*'" TRANSMIT *'"
· "NO-OUT" · '" MESSAGE '"
·*·"'··*****·· *****'"
(----------*
IMS/VS TRANSMITS A SYNCHRONIZATICN BLCCK INDICATING TO THE REMOTE CPU THAT NO OUTPUT MESSAGES, THAT MAY BE SENT, ARE CURRENTLY AVAILABLE.
V
*****F1**···**···
*··**R·E·S·E·T···TH··E **LI·N·E···*···*
I
IMS/VS TRANSMITS EOT TO TERMINATE TRANSMISSION.
Design and Control of a DB/DC System 2.67
CONSIDERATIONS UNIQUE TO SYSTEM/7
IKS/VS requires synchronization blocks to be transmitted using the pseudo-binary PTTC/EBCD transmission code. This code is described in the ~I~1~~Ll 19n£1ion~1 ~h~£~£1~ri2!ic2 ~ng!!, GA34-0003.
Data blocks are transmitted using either the standard PTTC/EBCD transmission code or the pseudo-binary PTTC/EBCD transmission code. IKS/VS accepts either code on input and scans the output data to determine if the block contains any characters that cannot be transmitted using the standard PTTC/EBCD transmission code. If such characters are found, the block is converted to pseudo-binary PTTC/EBCD. Otherwise, the message is translated as standard PTTC/EBCD transmission code.
IMS/VS allows the user to specify at IMS/VS system definition, on a per station basis, that all data blocks should be transmitted in one of the above transmission codes. If all data blocks are to be transmitted in the standard PTTC/EBCD code, all characters that cannot be transmitted in that code are replaced by a colon.
The output buffer size specified by the user at IMS/VS system definition is doubled to allow for conversion to pseudo-binary PTTC/EBCD, unless the user specifies that all data blocks are to be transmitted using the sta'ndard PTTC/EB'CD transmission code.
IMS/VS allows a System/7 to be attached on a nonswitched contention line or a nonswitch~d polled lin~. A polled line may be polled using programmed polling or autopoll.
IMS/VS can control a polled line and therefore initiate output, if allowed to, at any time data transfer is not taking Rlace without a potential loss of data and without System/7 intervention. To try to avoid errors caused by loss of data on a contention line, some of the responsibility for keeping communication open is dependent upon the System/7 program. IMS/VS issues a read when output is not available to send and this read must be terminated by transmission from the System/1. Since there is no indication of whether, after receiving a block, IKS/VS intends to transmit or return to read, unless the System/7 is defined as ask type, it is recommended that a System/7, attached on a contention line, be defined as ask type. The receipt of the cutput not available (NO-OUT) message informs the System/7 program that I~S/VS, immediately following the completion of this message, is issuing a read.
~YEE££1ed ~I~t~~Ll ~~£ ti~~ !IE~2
IMS/VS allows a System/7 to be attached on a nonswitched contention or polled line. IMS/VS is defined as the controlling station. All transmissions must be in BSC EBCDIC transparent mode.
:fI.~!!22 £2!lll21!i!lCl ~I~illLl
Since there is no facility to prevent an IMS/VS shutdown checkpoint while a process controlling System/1 is active, the System/1 should transmit a message to the IMS/VS master terminal operator, when communication is started, informing the operator that a process controlling machine is attached and that the operator should not issue a shutdown checkpoint until informed that the process controlling machine is either stopped or stoppable.
2.68 IMS/VS System/Application Design Guide
The flowchart below shows how IMS/VS processes a transmission block received from a System/7 ·
.0 B2···
.· ·0 .0 .0 PREVIOUS
o. __---------------------------).. ·· PBRLOOCCKESTSO?
.*Y-E-S-.
·.ro· -. .*
........j........ .-------··--------).RE·····.C.E··ICIiE2·A··B··L·O.C··K·····.
IF AN ADDITIONAL BLOCK WAS TRANSMITTED WHEN IMS/VS SENT RVI IT WILL NOW BE PROCESSEDo THE INPUT SEQUENCE IS STARTED WHEN IMS/VS RECEIVES A BLOCK FROM A SYSTEM/30
c.02..~..0 .0
YE S 00
EOT
··
io<~· ~--o-·----- -
---
.
.
*
.
RECEIVED?
*0 *. .*
··
........j........ ··o···P·REOC2ESV.S···T·H·E.···.·
···
BLOCK
···
THE INFORMATION CONTAINt8 IN THE RECEIVED BLOCK IS PROCESSED. ONE II. MORE ERROR MESSAGES MAY eE GENERATED AS A RESULT CF THE BLCCKS CONTENTS.
·····Fl. ········
·
·
.·0 F2 .0
.0 ·· ERROR
················.·. .0·0·0i.·.· .<--------*. · MAKE READ.
· CONTINUECACK-O
NC.. MESSAGE ·· GENERATED? ··
· OR ACK-ll.
.*
YES
IMS/VS MAKES A READ CONTINUE CAUSING EARNROARCKM-DE SOSARGEACWKA-Sl TNOOT BGE ETNREARNASTMEOIT.TEO IF AN
··.··I·N··TGEMRA2RKUE·P·VT·RE·A·(RD.V..I .···. · · · SEQUENCE I ·
l:~~Y~GM~~E~vt ~~a3E~~IE~~U&I
TRANSMITTED IF AN ERROR MESSAGE WAS GENERATED. AN ADDITIONAL INPUT BLOCK MAY BE RECEIVED AT THIS TIME·
........j::::::::_-_.
........j........
· · ····.HZ·I·I········
· TRANSMIT ERROR.
· · ··
MESSAGE
·
·
1M SIllS TRANSMITS THE ERROR MESSAGE USING A SYNCHRONIZATION BLOCK.
0·0
·· J2MORE ·· ·· ·· ERROR ·· YES
o. ·· ·· MNEESESADGEDES? ··--
·0 io".. *0
L
----------------------------.RE····.·.·S.·E·.·.T·K··TZH·E······L···I··N.··E·.·.····.
Design and Control of a DB/DC System 2.69
CONSIDERATIONS UNIQUE TO SYSTEK/3
IMS/VS snpport of the System/3 is designed to provide a high degree of flexibility in function but 1S consistent with the main storage constraint inherent in smaller computers.
While IMS/VS IRSS does not require it, it is anticipated that System/3 programs designed to interface with IMS/VS will take advantage of the ask-type station facility described under "System Definition." This facility allows the system/3 programmer to allocate his main storage resource only when he is ready to accept data from IMS/VS: thus alleviating the requirement for a larger, permanently-dedicated buffer area.
Transmis~ion of data in the EBCDIC transparency mride allows all types of data to be transmitted from an IMS/VS application program. This could save additional storage or programming in the System/3.
If the System/3 is used as a subhost for locally attached terminals, using either the MLTA (for start-stop) or KLKP [for BSC) features of the System/3 Disk System Control Program, the IRSS provides each of th~se terminals direct access to an IMS/VS system with the additional advantage of a common I/O interface.
Though IMS/VS IRSS supplies a large amount of status type information to the System/3, the System/3 programmer does not need to design his application to process all types. Consequently he can realize a savings in main storage or programming within the System/3.
To fully utilize the features provided by IRSS to the System/3, the System/3 programmer should design his application to use the Disk System Control Program with the BSCA Multiline Multipoint feature. This support allows the user to directly control the line discipline and to recognize many types of responses from I"S/VS.
To utilize ~L~P support in the System/3 to communicate with IMS/VS through the IRSS, the System/3 user should:
1. Define two BSCA files, one for transmit and one for receive.
2. The transmit file should be single buffered to prevent more than one block being transmitted after a reverse interropt (RVI) indicator has bee~sent by IMS/VS. The reverse interrupt indicator must be defined and recognized for this file.
3. It is recommended that the System/3 user utilize the get-block and put-block modes of the GE~ and PUT macros. This is recommended because IKS/VS IRSS data structures do not normally lend themselves to the record separator mode of deblocking (unless of course the data to be transmitted can be guaranteed not to contain a particular character).
4. If multiple System/3s are to be multidropped on a single communication line, it is important for the System/3 application program to take the necessary steps to assure a negative response to polling when communication is inactive between the System/3 and IMS/VS. This usually requires the issuance of a GET type operation in the System/3 and the use of the cancel function when the next direction of transmission is to be a PUT type operation for the System/3.
2.70 IMS/VS System/Application Design Guide
The flowchart below shows how I"S/VS processes a transmission block received fro. a SJste./3.
*****81**********
........j........
*-->***RECEIVE A BLOCK***
* *
*·
THE INPUT SEQU~~CE IS STARTEC WHEN IMS/VS RECEIVES A BLOCK FROM A SYSTEMI1.
0·0
.0 ··0*ClEOT.0 .0 YES
·· RECEIVED? 0.---
o. *0
*0
o ·
· 0 c*
j"
ASK TYPE: IF ASK REQUEST RECEIVED, OUTPUT IS ~~~lE!~I~~~A~~3~~~0 OTHER~ISE, ~C~~_L IMS/VS NON-ASK TYPE: IF TRANSMISSICN LIMIT NOT REACHED OR NOT SPECIFIED, OUTPUT IS SENT IF AVAILABLE. CTHERWISE NORMAL IMS/VS PROCESSING RESUMES,
·*··· 01·****·****
......·. ........
** PROCESS T"E **
· * ·
\BLOCK
· * *
*· C .0
.0 · *EElRRCR
o. MESSAGE *. YES
*. GENERATED? .*---*
I .0*· · *··
L
j"*0 0*
<--*.·..'C..IR.C.MCOFALNKElET·IN·RY·UE·AEA·DC·K··I ·*····
AIMCSI/VROSLEMAYKETSO ABEREATCRACNOSMNTITINTUEDE CIFAUASNINGERROR MESSAGE WAS NOT GENER_TEO.
*·**.*.**········*·
.~ ----------
*····G1*.·····**· *· MPAOKESIT~IRVIETE ·* *· 'CIARCCKLNEOWDLEOAGCEKI *·
·*················*
IMS/vS MAKES A WRITE POSITIVE
'N ACKNOWLEDGE CAUSING A CIRCLE D TO BE
TGREN'NESRMATITETDE·D If
ERkOR MESSAGE WAS
<----------*
V
........j........
· · **.**H1···**····.
· TRANSMIT ERROR *
·* MESSAGE ·*
*
*
IMS/VS TR_NSMITS THE ERROR MESSAGE USING A SYNCHRONIZ_TION BLOCK.
o. 0.-- 0*
*. 0·0
JEMlRORROER
*.
*.
YES
o. *. *. MNEESSEACGECES?
r*0 .0 0*0*
*.***K1*·····****
---*R*·ESET THE LINE**.
·**················*·
IMS/VS TRA~S~ITS EDT TC TERMIN_TE TRANSMISSICN,
DeSign and Control of a DB/DC System
2.71
SECURITY AND PRIVACY
It is the objective of IKS/VS to provide safeguards through which access to data may be limited. The ,mechanics of the safeguard system can be used to admini~er security and privacy policies. Administration is accomplished by careful interpretation of policy in system and application design, and into parameters and control statem@nts used for: system definition, the security maintenance utility, program specification block generation, data base description generation, and statistical analysis program.
IMS/VS SECURITY WITH SMU
The basic level of security is called default terminal security. It exists even if the us~r does not choose to use the additional Recurity facilities provided by IMS/VS.
To establish additional system security measures, the IMS/VS Security Maintenance Utility (SKU) can be run after the IMS/VS system definition is completed. SMU optional security measures include the following levels of security:
· Terminal Security
· Password Security
· Resource Access Security
· Transaction Command Security
· Signon Verification Security
MVS users can also specify use of the RACF program product, if desired. For more information on security see the section, "Establish IMS/VS System Security (Optional)" in the !~~L~ In~tslla!i2U Qg~~2. Security requirements may be redefined at normal restart, subject to limitations imposed by system definition, by the master terminal op~rator. The security modules specified by the master terminal operator or system definition will be loaded when IMS/VS is sta~ted. Security enforcement in IMS/VS involves the use of various tables or modules; these can be chosen or not, but they cannot be selectively replaced without rerunning SMU.
It is recommended that the security measures be designed to require minimal master terminal operator action in normal situations. Although all documentation emphasizes the identity and importance of the master terminal, there are only a few characteristics that make it unique in the DB/DC system. It is the only logical terminal to which messages about the operational status· of the systam are automatically routed. It and the System 370 console are the only terminals, by default, through which the DB/DC syste~ can be restarted. The control that the master terminal exercises over the system is made possible through the IMS/VS command language.
A thorough examination of the commands. the system to be protected, the requirements of users, and the objectives of your security and privacy policy will provide guidance in the distribution of authority to use the command language. Refer to the !~2L!~ QE2£at2~~~ R2!2~2n£2 ~ang~l for a complete description of the commands and the command language.
2.72 IMS/VS Sytitem/Application Design Guide
Terminal security restricts the entry of transactions and commands to specified terminals. Link security (a subset of terminal security) allows the addition or deletion of transaction code security requirements for the Mse links in a multiple IMS/VS system configuration.
Through the entry of transaction codes, the terminal operator identifies the destination of the text or data that follows. When one examines the syntax of input messages, as defined by ISS/VS, it can be seen that all entries from terminals are classified by means of an identity code. In general, there are two levels of recognition. The first level establishes whether the entered data is a command by reserving the initial character /. The first character of every input segEent is examined for a /. If one is present, the segment is treated as a command seqment. Input destined to a program or logical terminal must not contain a / as the first character of any segment. The second, or operational, level verifies that the identity code is known to ISS/VS. If it is known, then it and the text that follows are classified based upon the attributes of the identity code. If the code was defined during system definition as a transaction code, the message is routed to the application program which is to process it. If the code was defined as a logical terllinal name, then the messa1e is routed to the physical terminal to which that logical terminal is attached. It becomes a message switch operation.
The possible contents of a message destined for an application processing program, the actual functions which ara performed by that program, and the content of any output subsequently generated by that program are unknown to IMS/VS. Because applications may deal with critical or private matters, safeguarding tools are provided by the system to help prevent unauthorized entry of transaction codes, and hence unauthorized use of appliction program functions.
The entry of each transaction code can be limited to anyone or any group of logical terminals in the system. Depending on the ratio of secured to unsecured transaction codes, the authori~ation plan that is developed can be inclusive or exclusive. To use the Security Maintenance Utility effectively, the operational plan must be inclusive. That is, you must specify the transaction codes which are to be secured. There is no provision for specifying those which are not to be secured. There are, however, alternative views of the plan that can be helpful. You can look at the transaction codes as being authorized for entry from a list of logical terminals. Or, think of each logical terminal as being authorized to enter a list of transaction codes. Either viewpoint may be translated easily into the operational input statements that describe what you want to do with the Security ~aintenance Utility. However, the number of input statements can vary substantially between the two viewpoints. If, for example, you have one transaction code you want to authorize from five logical terminals, six input statements are required. Conversely, if you specify five logical terminals and authorize the same transaction code from each, ten input statements are required.
Password security is used to restrict specified IMS/VS resources to someone who supplies the correct password.
Design and Control of a DB/DC System 2.73
passwords can be used instead of, or in addition to, logical terminals to limit transaction entry. The security provided by passwords can be specified and viewed in the same manner as that provided through logical terminals. When a transaction is defined with SKU as requiring a password, IKS/VS will not allow the user to execute the transaction unless the password is specified with the transaction
code.
Command functions can be protected against unauthorized us~ in four
ways: by permitting the command verb to be entered only from certain
logical terminals, by requiring that a password be entered with the
command verb, or by a combination of both, or with transaction command
security. Some objects of commands can be protected against
unauthorized action by requiring a password to be entered with the
parameter. Th~ protection of the command object is controlled by
assigning a protected attribute to each member of the class of objects
to be protected.
.
For example, to require a password be entered to alter the status of logical terminals (LTERK) 111, 222, and 333. one must specify to the
Security Maintenance Utility a password for each terminal. If PTERMs 11', 222, and 333 are the only LTERMs in the system and all are
protected by the salle password, then the object keyword is secuI;ed throughout the system. If, however, it is only necessary to protect LTERM 222, then the LTERK keyword can be used without a password on LTERKs 111 and 333.
Another way to look at using safeguards to protect the command language is by individual user profile. Equate passwords to user signon or identification codes. An authorization plan can be developed that authorizes each user to use, individually, a set of command functions. That authorization could be localized geographically through restricting entry of the cOllmand verb to a group of logical terminals.
A class profile system could be used. For example, password x validates the use of four command verbs, YIYY validates three different command verbs. ZZZZ however is valid not only for the com.~nds protected by x and IIYY, but also authorizes the holder to enter an
immediate DB/DC system shutdown command from any terminal.
Resource access security limits the set of IRS/VS resources which may be used by dependent regions that are authorized to access a specific Application Group. This group represents a set of user defined IMS/VS resources (PSBs, TRANs, and LTERMS).
The IMS/VS SECURITI macro allows the user to specify during system definition whether or not resource access security will be included in the system, and whether the RACF product or a user exit routine will be used for the authorization validation. The specifications may be overridden via an I~S/VS procedure parameter. RACl or a user exit routine, depending on the usar specifications, will validate the dependent region authorization to use the Application Group. The same parameter (ISIS) can specify no resource access security checking be done. Subsequently, IKS/VS will ensure each time a request is issued that the TRAN, PSB, or LTERM is defined in the authorized Application Group. SMU enables the user to define the Application Groups and to indicate which resources are available for each group.
2.74 IMS/VS System/Application Design Guide
SHU can be used to designate transactions to be passed to an application program which is allowed to issue a subset of !MS/VS operator commands. The online application programs that process these transactions cause IMS/VS operator commands to be executed and can receive status on the execution of the commands. In the absence of specifications authorizing one or more of these commands, no transaction processing programs are allowed to enter IMS/VS commands. For more information on how to authorize transaction processing programs to issue IMS/VS commands, see the section, "Establish IKS/VS System security (Optional)," in the !!1.2L!~ I!l§.t!!.!!!ti2!l ~l:!i!l~. In addition, see the "Automated Operator Programming" chapter in the I~~L!~ ~y§.!~~
g~2g~!!~i~g R~t~~!l2! !1!!!ll:!~!.
Signon verification security identifies a particular user to IMS/VS as being Fresent from the /SIGN ON command entry until a /SIGN OFF command is enteren to remove the association created by the first command. When transaction authorization is in effect for a physical terminal, as each transaction is entered from that terminal, a check is made to determine whether or not the transaction is authorized to the userid curreatly logged on.
The IMS/VS security macro allows the user to specify during system definition, whether signon verification only. or together with transaction authorization security will be included in the system. Both the user verification and the transaction authorization can be done by the RACF product, user exit routines, or by both. The specifications may be overridden via IMS/VS procedure parameters or /NRESTART command specifications. Since transaction codes are checked against the userid of the terminal operator ent~ring the request" transaction authorization security requires user verification through the ISIGN ON command be performed as well. For information on user exit routines see "DC User Exi t Routines" in the !!1~L!~ ~y§.t~!!l2 ~I2g~!!!!l~j.Jlg B~f~£~!l£E ~!!!!l:!~!.
The /SIGN command provides a means of identifying a particular user to IMS/VS as being present at the physical terminal. When a signon is processed, IMS/VS will verify through the RACF product, a user exit routine, or through both (depending on the system definition specifications and the IMS/VS start-up parameters). the user identification entered. Upon verification, IMS/VS creates a record on the IMS/VS system log associating the user with the physical terminal and records in a control block that the terminal is signed on to a specific user identification.
If transaction authorization is included, as each transaction is entered, the RACF product, a user exit routine, or both validate the transaction authorization for the user identification logged on. With program-to-program switching through the DL/I change call or by means of changing the transaction code in the SPA, the RACF product, the user exit routine, or both are also invoked for transaction level authorization checking. The same applies when the transaction code is changed by means of the /SET, /LOCK, or /UNLOCK commands. In addition, as the application program associated with the transaction produces data base changes. the User identification is logged with the change records on the IMS/VS system log to identify the changes performed by a specific user. When the /SIGN OFF command is issued, the session is terminated and another record is written to the IMS/VS system log. For more information on the /SIGN command see the I~§L!§ Q~~!!t2~~§' R~I~£~n£E ~!!~!!l. The identification of the physical terminals that require signon verification is done by the Security Kaintenance crtility. For more information on the SHU, see the I~.2L!~ !!l§.tal!!!!i2!! ~l:!1~~.
Design and Control of a DB/DC System 2.75
Consideration should be given to physical security measures that support system security measures. These measures may include:
· Controlled access to and egress from the computer area.
· Authorization of l)P operat.ions and non-operations personnel in the computer and certain terminal areas.
· Separately controlled areas for media such as tapes, disks, cards, files, or other media.
· Control of computer forms.
These are some of the considerations for physical security of a computer facility. Physical security needs are likely to be dynamic and merit periodic review and adjustment.
Q!~H~l~I ~IE.~§§
Il'IS/VS does not provide a software function to blank out or obliterate passwords from the terminal device display media after they are accepted. However, Message Format Service (MFS) facilities enable users to define fields with a non-display attribute (for 3270 display devices). IMS/VS removes passwords from messages prior to recording them on the log.
Most hard copy key-driven terminals have a feature which permits characters to be entered without displaying them. This feature is the bypass feature. Ordinarily, a terminal with this feature is operated continuously in display or bypass mode. If passwords are to be used to support security requirements, this feature is a necessity.
The bypass feature can be used operationally, that is, by establishing standards for protection not only of passwords, but also of command verbs, commands, transaction codes, and text.
Through centralized control over the content of Data Base Definitions, Program Specification Blocks and the libraries in which they reside, an effective scheme of protE ~ion attributes can be assigned to data. This assignment is made relative to each application program which has access to the data base. The smallest unit of data which may be so protected is the segment. The basic actions that can be authorized are:
· None no access to segment type.
· Read sagment type may only be retrieved. One or more of the following additional actions combined with read
can be authorized:
· Add -- new occurrences of segment type can be inserted.
· Update an existing occurrence of a segment type can be replaced.
· Delete an eXisting occurrence of a segment type can be deleted.
2.76 IMS/VS System/Application Design Guide
Although access authorization is declared at the program level, enforcement of the authorization can be made to appear at the transaction code or individual hierarchical level of a data base. If only one transaction code is associated with a particular program, then the access authorization has been promoted to the transaction level. Through use of passwords or through use of the transaction code and terminal bypass feature, access authorization can be promoted to the individual level...
For information about specifying segment access authorization, refer to npSB Generation" in the Itt§L!~ Qtili~i~2 E~~~~~g~~ ~sn~!l. The control statements through which segment data access is authorized are PCB and SENSEG.
3270s on a switched line can have their hardware IDs verified for authorization to access I"~/VS by use of the IDLIST macro. For additional terminal security information concerning 3270 switched terminals, refer to the IDLIST Macro Description in the I~§LY~
In~1ail!1i2n ~yid~.
VIOLATION CONTROL
IMS/VS records security violation attempts on the IMS/VS system log tape. The violations recorded are:
· Input message from an unauthorized terminal
· Password omitted when one is required
· Password incorrect for authorization
· Misspelled password
· Rejected Signon
· Unauthorized DL/I CMD call from application program
IMS/VS rejects invalid input messages by sending a message to the terminal entering the message, and logging the violation.
The log tape provides an audit trail to look into possible security problems. If more immediate action is desired, the user can request notification to the master terminal at the time of violation. Since the number of violations for a large network may be high due to misspelled passwords, transaction codes, commands, etc., the user can specify a threshold for notification such that the master terminal is not notified until the specified number of violations occur without a valid input from a given terminal. This eliminates or reduces the number of notifications due simply to operator error, while still providing evidence of real attempts to avoid security safeguards.
In§1!11!tiQg R~§£Qu§!~!li1i~~
IMS/VS security functions only as well as the installation controls over the environment. IMS/VS assumes nothing about the attributes of the caller and relies on the optional security tables, user exit routines, and RACF specifications to determine what resources the caller can access.
Design and Control of a DB/DC System 2.11
By using the Security Maintenance Utility (SKU), the user can specify several levels of security: terminal, password, transaction command, resource access, and user verification. The output of the SKU is in the form of security tables and matrixes that are stored in the IKSVS.MATRIX data set.
The IMSVS.MATRIX data set and the I"SVS.JOBS data set, which contains IMS/V5 related jobs, may be secured by the user assignment of PACF password protection (MVS only). For more information on security implementation, see the !H~l!~ In2t~11~tlQn ~g!de~
1"S/VS DC MONITOR
The I"5/VS DC monitor is a tool for collecting performance data ~o investigate specific application designs, data base designs, and resource allocations. It consists of a monitor module, and a Konitor Report Print program. When activated, it analyzes and records the internal activities of the IMS/VS DB/DC system. The monitor report print program is processed offline to produce reports that summarize and categorize, at various levels of detail, the information recorded by the monitor module. The actions required to activate the monitor module are described in the !~~l!~ QE~£~tQ£!2 R~I~~~n£! ~~nY~l. The monitor report print program is described in the I~~l!~ Yt!1!ti~2 R~I~~~n£! ~~nY~l.
The monitor module collects data from IMS/VS DC control blocks during operation of the online sys~em, with minimum interference to the system, and records the data on an independent data set. The monitor remains resident and is activated and deactivated through master terminal control.
Following are recommendations for use of the IMS/VS DC monitor:
· Collecting data -- The I"S/VS DC monitor enables an 1"5/VS DC user to collect performance data to assist in analyzing an existing IMS/VS online system. The amount of data collected and the analysis
a time to understand the report output suggest short traces during
various time periods. Reports produced from profiles of time period considered as normal can be used as a profile and compared with reports produced during a time period characterized by unusual responses.
· Tuning system The IMS/V5 DC monitor can be used to quantify the effect of actual changes to data base structures, program characteristics, data set placement, pool sizes, number of message processing regions, transactions, and message region class scheduling.
· Testing application -- In the final testing of new or revised applications, the IM5/VS DC monitor can be useful in validating the internal operation of the programs and data bases. For example, the programmer thought a specific DL/I call could be satisfied with a single I/O retrieval, yet the DL/I call report indicated a large data base scan as shown by many IWA!Ts. Investigation of such items could assist in det~rmining 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 application program.
2.78 IMS/VS System/Application Design Guide
· Integrating applications -- The IMS/VS DC monitor can be used to
determine the effects on the IMS/vS production system as new
L
applications are merged from a test system to the production system.
One of the basic problems in integration of new applications into an existing system is the requirement of re-tuning options in the
production system, such as data set placement and buffer pool sizes,
as discussed above in the tuning of the system.
· Communicating criteria If the above recommendations are implemented, then data is collected to establish a performance base, profiles are available for the problem periods, the system is tuned for the production and test systems, and applications are tested and merged into the IMS/VS production system with an understanding of their effects and interactions. Thus, the IMS/VS DC monitor reports can be used as a basis to communicate and define performance.
This section describes IMS/VS sensitivity to specific characters when users attempt to send and receive nongraphic data in IMS/Vs messages.
EDITING OF OUTPUT MESSAGE SEGMENTS
For output message segments that are edited by the Message Format Service (MFS), only graphic data (X'qO' through X'FE') is allowed in the output message presented to the device. Nongraphic characters, if present in the output message, are changed by MFs before the data is presented to the device. Device control characters HT, CR, LF, NL, and BS are changed to X'OO' for 3270 video. For all other devices, these characters are changed to blanks. All other nongraphic characters are changed to blanks.
If the Distributed Presentation Management (DPM) option of MFs is used for 3600 and 3790 controllers, the user may specify GRAPHIC=NO in the SEG statement. Nongraphic characters, if present in the output segment with GRAPHIC=NO specified, are presented unchanged to the remote program.
For programmable terminals supported through VTAM, IM5/VS may insert function management headers (FMHs) and may perform additional editing fo~ device control sequences when splitting a single IMS/VS segment into multiple transmissions.
EDITING OF INPUT MESSAGE SEGMENTS BY MFS
If MFS is defined for a device, the user should be aware of the following considerations:
· Tha user should specify GRAPHIC=NO in the sEG statement to prevent uppercase translation on a segment if the destination requests it with the EDIT=ULC specification on the system definition TRANSACT macro.
· For the first input record from a 274x, 3600, sCS1 or SCS2 device, or from DPM-An, the segment is discarded if the last characters of the segment are two asterisks (**) or two asterisks followed by NL (X' 15') or IR S (X' 1E') ·
Design and Control of a DBIDC System 2.79
· The presence of two slashes (II) at the beginning of a message segment is considered an escape sequence. (See the section "Input Message Formatting" in the chapter "Message Formatting Functions" in
the Itt~L!~ tt~22ag~ l2t!!! ~~txi£~ Q2~~~~ 2~i~~ for additional
information. )
· If the card feature is defined for an SCSl device (with the CARD= operand in the DEV statement), the input from an SNA character string 1 (SCS1) device is scanned for the secure string reader (SSR) code and the code is removed.
No!~: The definition of the MFS delete characters (LDEL= operand in the DEV stat'ement) and field tab character (FTAB= operand in the DEV statement) for ~FS-supported devices, except the 3270, can direct the
editing of input message segments. Refer to the Itt~L!~ ~~~!g~ lQ£!!!
~~£~i£~ Q~£!§ 2~ig~ for information on using these specifications.
EDITING OF INPUT MESSAGE SEGMENTS BY THE BASIC EDIT ROUTINE
The following editing is performed if the IMS/VS basic edit routine is used:
· For the first segment of an input message when a terminal is U2! in
conversation mode, leading characters less than X'41' are removed. For other than the first segment or when a terminal is in conversation mode, l~ading charac~ers less than X'40' are removed.
· If a terminal is not in conversation or preset mode, a left parenthesis within the first nine positions of the first segment indicates a password. The left and right parentheses and the passw~rd are removed, and the segment is compressed.
· An X'26' character that appears as the last character in a segment is removed.
· Two asterisks (**) or two asterisks followed by NL (X'lS') or IRS (X'1E') that appear as the last characters of a segment cause the entire segment to be discarded.
· For unbuffered keyboard devices (for example, 1050, 2740-1, 2741), backspace (X'16') characters are treated as character-delete indicators. Each backspace character and the preceding input character a~e removed from the segment. This editing is optional for the 3767 and 3770 consoles.
· If the destination of the input message is a transaction, an NL (X'tS') character appearing at the end of a segment is removed.
· If a device is in preset mode, the transaction code is added to the first segment.
· For input from 3270 devices, the attention identifier (AID, and cursor address are removed, and all start buffer address (SBA) sequences are changed to blanks.
· If the first character of any segment is a slash (I), the entire input message will be treated as a command.
2.80 IMS/VS System/Application Design Guide
L
COMMON EDITING PERFORKED BY IMS/VS
Certain common editing is done by both MFS and the basic edit routine for any device that enters an input message.
· A slash (/) used as the first character of the first segment will be treated as an attempt to enter a command.
· When a terminal is ngt in either preset or conversation mode, a transaction code or logical terminal name must be present in the beginning of the first segment. The transaction code must be 1 to 8 characters in length and followed by a blank.
· Uppercase translation is performed if it is specified in the system definition TRANSACT macro.
· If a terminal was in conversation mode and the application terminates the conversation by inserting the SPA with the transaction code set to a nonconversational transaction code, this code from the SPA will be added to the beginning of the first segment of the next input message number. (See the section "Terminating a Conversation" in the chapter "Data Communication: Conversational Processing" in the IMSL!~ !££!i£!ti2n f£2g£!!!ing ~'2~2n£2 ~!U~~! for further details.)
· When a conversation is started, the transaction code is removed from the first message segment and placed in the SPA.
!2t~: This does not apply to MFS option 3 segments (see the I~~L!~ ~§§!g~ [Q~m!! l2~!~! Se£!i£~ y§2~~§ ~Yi4~) ·
· For devices suppo~ted through VTAM, IMS/VS removes the FMH (if any) that appears at the beginning of the first transmission of a chain.
· For a 3170 or type 1 SLU card reader, Transmit Data Set (TDS), or User Data Set (UDS) input, deblocking into IMV/VS message segments occurs at each inter-record separator (IRS) control character, and the IRS control character is discarded.
· For 3161, 3710, or type 1 SLU consoles, deblocking into IHS/VS message segments occurs at each new line (NL) or forms-feed (FF) control character if the optional MFS editing is not selected. This character mayor may not be discarded, depending on other criteria related above.
· For 3614 work stations, message formats for transaction IDs and class fields must conform to the specification prescribed by the hardware. See ~~ ~60~ Ei~n£~ £~m!Yni~li~n ~I§t~m 1~1! f£~g~~mm~~~§ ~ui~~ !n~ R~fe~n£~ ~!ny!! for information on hardware specifications governing 3614 message formats.
IMS/VS supports the IBM 3650 Hass Storage System (MS5) through its normal 05/VS1 and OS/VS2 interface. MS5 extends the capacity of 3330 Disk Storage. The uses of ~S5 with 18S/VS are:
· As a residence device for batch and online data bases
· For the development and testing of new applications
Design and Control of a DB/DC System 2.81
· As the storage media for historical or cutoff versions of data base
· As a centrally controlled location for data (DB/DC and other types) in a data processing system
Each of the preceding uses requires an understanding of the characteristics of IHS/VS and MSS that could affect an installation. This section presents the information needed to understand and take advantage of these characteristics. Design considerations and guidelines related to the following topics are described in detail.
· Using HSS in a batch IMS/VS environment.
· Using MSS in an online IMS/VS environment. Three different online environments, ranging from simple to complex~ are described.
· Sharing staging space.
· Data base organization and access methods.
· Using the additional capacity of the MSS with IMS/VS.
In this section, MSS is described only as it relates to !~S/VS, even though the considerations and guidelines generally apply to any DB/DC system. Since no attempt is made to explain the facilities of MSS and its operating system support, you should be familiar with the following publications:
· Q~L!~ ~s§§ §t2~ag~ ~Y2tim lnsSt f!anning ~Yigi
· I~~ 1~~Q ~a§2 §t~ag~ §Y2t~m l~§§l f~in~!E!i§ 2! QEi~~li2n
TERMINOLOGY
The terms "stage," "bind," and "cylinderfault" are used in this section. stage. bind, and cylinderfault specify how data that is stored on an MSS volume is to be staged.
~!~gi: Stage specifies that the data is to be staged from mass storage to a direct-access staging device when the cluster or component is opened. If it can't be staged at the time the cluster or component is opened, because of other staging activity, data is staged as a processing program needs it through page fault.
~!ng: Bind specifies that the data is not only to be staged but also to be kept on the direct-access staging device until it is closed. If it can't be staged at open time because of other staging activity and if there is staging pack space available for the entire data set, data is staged as a processing program needs it through page fault.
£Y!!ngir£~~!t: Cylinderfault specifies that the data is not to be staged when the data set is opened. It will be staged as the processing program needs it.
As a general rule, MSS can be used in a batch IKS/VS environment in stage, bind, or cylinderfault mode. In an online environment, it is recommended that the data base reside on real DASD or that it be staged with the bind option if transaction throughput and response time are critical.
2.82 IMS/VS System/Application Design Guide
I8S/VS BATCH ENVIRONMENT Figure 2-11 shows the use of !S5 in an 1M5/VS batch environment for
data base residence. A batch environment that includes MS5 allows: · Operational control of an entire system of data bases and files through !ISS. · An extra dimension of flexibility because processing of large data bases can be done with fewer staging drives compared to the number that would be required if real drives were used. In this environment, it might be more efficient to do some types of processing at a reduced throughput rate and save the investment in additional disk drives. · The testing of large data bas~ applications can be done using fewer staging drives than would normally be required in a production environmenti this can be tailored to meet t~e needs of an installation.
lMS/VS
Batch
L
Mass Storage Facility
MSS
Figure 2- 11. MSS in an IMS/VS Batch Environment
The paragraphs that follow describe how MSS can be used to advantage in an IMS/VS batch environment with certain disk drive saving opportunities. You may know from experience that you will process only a fraction of a very large data base. For example, only 10~ of an insurance data base might have policy updates, claims, or billing activity in the course of a day. If the full data base occupied 10 disk drives, then some number of staging drives equal to or less than 10 might be sufficient to handle the day's activity in cylindArfault mode. The exact number of staging drives required would depend on data storage patterns, reuse of staging drive space, the distribution of data across
Design and Control of a DB/DC System 2.83
cylinder pages, and MSS staging algorithms. The KSS publications referenced earlier contain detailed information on these factors.
If you know the reference patterns that your applications require, then possibly only a DL/1 data set group has to be staged for processing.
Month-end cutoff processing of a data base also lends itself to the use of MSS with IMS/VS batch. In a non-KSS environment, a month-end cutoff copy of a data base is normally gotten by copying the data base to tape. The tape is later restored to disk so month-end reports, etc., can be written from the month-end copy of the data base. The KS5 allows you to destage a month-end cutoff to MSS cartridges; later stage the data from the cartridges, possibly to a subset of data base staging drives; and process the month-end cutoff data without having to go through disk to tape and tape to disk dumps and restores.
IMS/VS ONLINE (DB/DC) ENVIRONMENT
Just as MSS offers an added dimension of flexibility in an 1MS/VS batch environment, there are added opportunities in an online environment, but planning is far more critical. An online DB/nC environment usually includes certain transactions that require fast response and throughput as well as fast recovery. Th~se transactions will be referred to as critical transactions.
In the online environment the following assumptions are made:
· Response time and transaction throughput for critical transactions should be the same whether or not KS5 is part of the operational environment.
· Recovery time in the event of an IMS/VS, OS/VS, or hardware failure should be the same in an MSS environment as in a non-KSS environment.
To maintain the response and recovery time criterion required by your installation and still use MSS effectively in an online IMS/VS environment requires that you consider the following factors during planning:
· Logging and restart processing
· Sharing of staging drives
· Sharing of data bases
· Update activity
· Initialization and prestaging
The following contains considerations and guidelines for these factors in each of three different online environments: (') IMS/VS online using bound data or real DASD and no batch applications, (2) IMS/VS online bound data using bound data and/or real DASD with IMS/VS batch, and (3) I8S/VS online using some bound and some unbound data.
Additional factors, data base organization and access methods, apply egually to all environments and will be described as a separate topic later in this section.
2.84 IMS/VS system/Application Design Guide
This is the simplest online environment to plan for. IMS/VS logs the system activity and runs recovery as necessary using the log tape much the same as in a non-MSS environment. Because all data is either mounted and bound on staging volumes or residing on real DASD, there is minimal planning necessary for sharing staging DASD. The sharing of data bases by multiple Message Processing Programs (MPPs) requires the same planning as in a non-MSS environment. Figure 2-'2 shows this kind of environment.
IMS/VS Control
MPP
or
BMP
MPP or BMP
Real DASD
Staging Drive
Mass Storage Facility MSS
Figure 2-12. M5S in an I8S/VS Online Environment vith Bound Data
Initialization and prestaging must be planned if real DASD is not
used. If the data is to be bound, it is important to ensure that the
data be staged and bound on the staging packs before startingIMS/VS
online operations. If the staging packs are used to hold only the bound
data, and never used to hold other data, then the data is staged and
bound once, and it does not have to be restaged and bound each tim~
IMS/VS is started. However, if the staging packs are used for other
work (for example, during off-shift operations), the staging and binding
of I8S/VS online data must be scheduled before starting IMS/VS at the
beginning of each work day. The process of staging and binding data can
be a lengthy process requi~ing careful scheduling to ensure that it
completes prior to starting online 18S/VS operations. Also, there
should be sufficient staging pack space available to hold all the data
L
to be staged and bound.
Design and Control of a DB/DC System 2.85
Methods of staging bound data prior to data set OPEN processing are
contained in "How to Use the Additional capacity of KSS with 1"5/'5" later in this section.
All planning considerations are the same as in the previous environment if the 185/'5 batch is also using bound data and/or real DASD, which is unlikely. If IKS/VS batch is cylinderfaulting to the staging volumes, there could be a delay as 1KS/VS batch and online contend for staging pack space. As a general rule, if IMS/VS batch will cause contention for staging pack space, stage and bind the critical online data before tha batch operations begin.
Although this example uses IKS/'S online and batch, the same considerations apply to any activity (OS/iS batch, TSO, etc.) running with an online lKS/VS system. See "Sharing of Staging space" in this section for additional information on this topic. Figure 2-13 shows this kind of environment.
IMS/VS Control
MPP
MPP
IMS/VS
or
or
Batch
BMP
BMP
Real DASD
Mass Storage Facility MSS
Figure 2-13. MSS in an IMS/VS Online and Batch Environment
2.86 I~S/VS system/Application Design Guide
Recovery should be the same in this environment as in a non·MSS environment because IKS/VS online has its own separate logging facility and data bases are not shared between online and batch operations. Operational procedures may differ, however. For example, where batch backout in a non-SSS environment involvesquiescing activity to a data base, closing the log tape, and moving the data base and log tape to a different address space or CPU, the MS5 environment involves quiescing the activity to the data base, closing the log tape, demounting the virtual volume, and remounting the virtual volume for batch backout. Again, this procedure varies depending on where batch backout is to be run: in the same host or in another host of a multihost system. Destage and restage mayor may not be necessary at batch backout time depending on the configuration and the virtual unit address (VUA) specified in the mount order for the mass storage volume at initial IKS/VS load.
Even though staging packs vith their virtual volume data cannot be physically moved from one staging disk drive to another, as is often dOne for batch backout with real DASD, the data can be moved (destaged and staged to another disk drive) to accomplish the same purpose.
This environment requires considerable planning. Again, the objective is to work in this environment and for certain critical transactions to maintain the same response time and throughput as well
as recovery time, in the event of failure as would be experienced in a
non-MSS environment. Figure 2-14 shows this kind of environment.
L
MPP
IMS/VS Control
or BMP
MPP or BMP
IMS/VS Bat<:h
Non-IMS
Batch or
TSO
Staging Drive
Mass Storage Facility MSS
Figure 2-14. H5S with IMS/VS Online and Batch and Non-IMS/VS Data
The data to be bound should be staged onto the staging packs before IMS/VS transaction processing begins assuming there viII be contention for the staging packs. Next, data sets or data set groups that will be referenced should be staged onto staging packs. Also, selected portions
Design and Control of a DB/DC System 2.87
of a data base that will definitely be referenced, if that can be determined, can be staged onto the staging packs. This might be accomplished by starting a batch message processing (B"P) program that issues DL/I calls causing selected data to be staged in cylinderfault mode. This essentially is prestaging. Prestaging data to staging packs is somewhat analogous to putting and keeping data in the data base buffer pool for future reference.
Prestaging through an IMS/VS application program can be very effective in a DL/I environment because it allows the user to stage selected portions of the DL/I data base using the standard DL/! facilities.
Frequently the data base reference patterns cannot be determined. For example, it is almost impossible to determine which customer of an insurance company will phone to report a theft. Prestaging, in this case, could be accomplished by entering a simple transaction that does no more than read the data from the data base using DL/I for the customer phoning the report. This would cause cylinderfault staging of policy information about that customer while information for a more complex transaction is being gathered based on the conversation between the insurance agent and his customer.
This environment assumes a mix of transactions in the system, some critical transactions requiring fast response and throughput as well as fast recovery in the event of failure, and transactions that are not so critical.
Since both the critical and the noncritical transactions share the same log tape used for emergency restart, and since critical transactions require a fast restart, it is important that cylinderfaults do not occur during emergency restart. This can only be guaranteed in this environment if all data required at restart time is available on real DASD or staging packs. This means that either there must be enough staging pack space available so data is never destaged to make room for other data, or that there is no update activity to data bases running in cylinderfault mode. Data base updates could cause cylinderfaulting during emergency restart if the changed data base records had been destaged to MSS cartridges to make room for other data on the staging packs and some of the data that had been destaged was required during restart. Emergency restart of critical transaction activity would be delayed by cylinderfaulting of noncritical transaction activity because backout is done serially.
If only BMPs are using online data bases in cylinderfault mode then specifying NOBMP at emergency restart would eliminate the backout of BKP updates and the delay to emergency restart caused by cylinderfaulting.
In addition, batch backout and program isolation dynamic backout will take longer if cylinderfaulting must occur during backout. Similar guidelines apply to batch backout and program isolation dynamic backout as apply to emergency restart with the exception of NOBMP, which applies only to emergency restart.
The preceding point regarding no update activity for data bases running in cylinderfault mode may appear restrictive. It is only a recommended guideline to ensure fast emergency restart. It is also tunable where the number of emergency restarts or batch backouts, the number of updates, and the degree to which staging pack space is overcommitted are the tunable considerations. For example, it may be satisfactory to allow updates to data bases running in cylinderfault mode depending on the number of updates per sync point or checkpoint, or if emergency restarts are infrequent.
2.88 IMS/VS System/Application Design Guide
Data bases that are read to gather data to generate reports are likely candidates for use of shared, overcommitted staging pack space. An example here might be month-end accounting reports that are generated from month-end cutoff versions of a data base.
In this environment, transactions requiring fast response and throughput should not be scheduled to run in the same message processing region as transactions that could require cylinderfault staging. The critical transactions could end up being queued until transactions requiring a call for data on MSS have completed.
Message class scheduling affects the queuing of transactions in IMS/VS. Transactions requiring fast response and throughput should be assigned to a separate class from transactions that could require cylinderfaulting. The classes should then be assigned to separate regions when IMS/YS is started.
The HSS staging drive group concept can be used for added tuning in this environment. Not all data bases have to use the same level of overcommitment. Staging drives can be divided into staging drive groups so that there may be more contention for staging drive space for very low priority work and less contention, or even no contention, for higher priority work. Activity from work outside the I8S/VS online system, such as batch work, could adversely affect the I85/VS online system if all work shared the same staging drive group and the scheduling of work was not otherwise controlled.
The sharing of data bases has to be well planned in this environment. Avoid having a transaction that requires fast response use data from both a data base on a bound volume or real DASD and also from a data base residing on overcommitted staging packs. Also avoid a logical relationship between these same two data bases where processing, especially insert or delete processing, could slow down processing of ~he bound or real DASD data base.
Also to be avoided, but less obvious, is a situation with the following or equivalent characteristics:
· Program A scheduled by transaction A requires fast response.
· Program B scheduled by transaction B does not require fast response.
· Program A uses data base A which is on bound staging packs.
· Program B uses data base B which is on overcommitted staging packs
and also uses data base A.
Figure 2-15 shows this situation. It is possible that a program B could impact program A's processing and it would depend on the extent to which program E was holding data fro. data base A while staging data base B, and program A required the same data being held by program B.
This may be an unusual situation but it points out that application schedulinq and use of data bases in this environment should be well planned to avoid less obvious throughput problems. Again, the same caution regarding doing updates to a data base on overcommitted staginq packs, as described earlier, applies in the above example.
Design and Control of a DB/DC System 2.89
IMS/VS Control
MPP Program A
MPP Program B
Staging Drive (DB A)
Staging Drive (DB B)
Mass Storage Facility
MSS
Figure 2-15. ~SS in an INS/VS Environment Using Shared Data Bases
SHARING OF STAGING SPACE
Closely related to the sharing of a data base is the sharing of staging space. staging space sharing considerations were partially described under the second and third environments earlier in this section. Well planned use of the MSS staging drive groups is a valuable way to control the amount of staging pack space allotted to various applications or data bases.
When allocating staging space for IMS/VS, view the entire system as known to MSS. This could include not only INS/iS online and batch systems, but non-IMS batch or TSO, for example. Staging pack space may be known to MSS across multiple CPUs. It is necessary, then, to consider possible interference to INS/VS processing from outside of IMS/VS itself. MSS staging drive groups can be used to help control unwanted staging from shared staging space. This should be well planned, because there could be interactions between the INS/iS and non-IMS/iS environments. The use of staging drive groups is further described under the topic "How to Use the Additional capacity of MSS with I!!S/VS."
DATA BASE ORGANIZATION AN~ ACCESS METHOD
I5AM data sets can only be accessed in the cylinderfault mode. This means that the IS AM portion of an I5AM/OSAN data base cannot be staged or bound at OPEN time; the time of the first DL/I call. Staging of a cylinder of data takes place only as the result of a DL/I call for data in that cylinder. It then follows that if ISAM/OSAK is used, and cylinderfaulting presents an unwanted delay, some form of prestaging or, better yet, VSAM should be used.
OSAM data sets can only be defined with the stage attribute. Because 05AM uses EXCPVR, the operation of K5S with EXCPVR applies to OSAM. The
2.90 IMS/VS System/Application Design Guide
OSAM portion of an I5AM/OSAM data base will be staged at OPEN time because that is when the data sets using EXCPVR are staged.
The entire extent of an OSAH data set will be staged, even at initial load time. An exception to this occurs when IMS/V5 uses QSAM to write an OSA~ data set as in recovery when the DFSRRCOO PAR! is UDR. Under such a condition there is no staging of the output data set at OPEN time.
05AR data sets cannot be bound. Therefore, there are so~e implications that should be considered. Even though the data requested in the first DL/I call will be returned to the application as soon as the requested page is staged, the entire data set will be scheduled for staging at the time of the first DL/I call. If you can determine ahead
of time that data from the I5AM/05A" data set will be required, it might be advisable to do one of the following: cause staging to begin shortly after IHS/VS ~s started by scheduling a simple application that issues a DL/I call to the !SAM/OSAH data base, or cause staging of the OSA" data by running a short IMS/VS batch job ahead of the IMS/VS job that requires the OSAH data to be staged. The IKS/VS batch job would issue a DL/I call, which would cause OPEN and staging. At the end of the batch job the data would remain staged. This assumes there is enough staging pack space available for the OSAM data. It also assumes other activity in the system does not cause destaging of the OSAH data before it is
needed. Refer to "Data Reuse" in the !!l1£2SY£li2!l 12 ih.~ I~~ 1~Q. 1!!!§.§.
~i2£!g~ ~I§.1~ l~~~l manual for details on the reuse of virtual volume data.
VSAM data bases can have the stage, bind, or cylinderfault staging
attribute. Also, VSAM data can be destaged synchronously or
asynchronously, vhere I5AM/OSAR data bases can only be d~staged
asynchronously ·
~ ..
The following points should be considered ~n determining whether a
VSAM data base should be destaged at CLOSE time with the delayed
response request. Destaging at normal CLOSE time with the delayed
response request causes synchronous destaging and insures successful
de staging of the updated cylinders before CLOSE is complete. However,
there are conditions under which IMS/VS closes a data base during
on-line processing, for example, if the DMB pool runs out of space, or
if the /DBR command stops the data base. Under such a condition the
IMS/VS control region waits for CLOSE processing to complete before
allowing any other on-line processing to proceed. This temporarfly
stops all on-line processing until the destage of updated cylinders
completes if the data base was closed with delayed response. Each
installation has to determine how it wants to close its data bases
depending on the frequency of situations that can close a data base
during on-line operations, the importance of never interrupting on-line
operations, and the importance of insuring a successful destage of
upda~e cylinders at CLOSE time.
In general, data bases should be VSAM based to provide maximum flexibility in both staging and destaging. For a very large noncritical HISAM or HIDAM data base, it might be desirable to define the HIDAM index cluster or the HIS!M index component. of the KSDS as bound and the data portion as cylinderfault. This could be somewhat better than accessing the entire data base in cylinderfault mode, and it would require bound disk drive space for just the index portion of a large data base.
The same guideline applies to secondary indexing. It might be helpful to define the secondary index as a hound data set.
Design and Control of a DB/DC System 2.91
HOW TO USE THE ADDITIONAL CAPACITY OF KSS WITH IKS/VS
Since PISS offers a vast amount of storage beyond what has, in the past, been used in an IPIS/V5 system, it is meaningful to ask how that additional storage should be used·. What kind of work can be put on IMS/YS given the added capacity of the PISS?
As a general rule, applications requiring a small number of large, infrequently referenced, preferably read-only data bases, where response time or batch turnaround time is not critical, can be added to an existing I85/YS system to take advantage of the additional capacity of the PISS.
The applications could be new or they could be old ones that previously required data to be restored to disk from a save tape before they could be run.
It is likely that the added applications wo~ld run in cylinderfault mode to avoid an investment in additional disk drive space. It then follows that the new applications would use new data bases that are separate from the existing critical IKS/VS online data bases.
The added data bases should be infrequently referenced. Added v9rk in cylinderfault mode could eventually impact existing work in the MSS system as the staging facilities of the MSS are absorbed. This cannot be quantified because it depends on th~ existing load on the 1MS/VS PISS system, but it should be considered.
It is recommended that the new applications be read-only because changes to a data base require a destage of updated cylinders. Therefore the impact of additional applications can be minimized by adding mostly read-only applications to the IKS/VS MSS system.
An example of a new application is a report writing application using a small amount of data from a large data base.
The staging and binding of data in an IPIS/VS environment can be handled in several ways depending on when the user wishes to experience a possible delay for staging. As stated earlier, if staging packs are not used for other work during off-shift operations, then there is no staging required each day because the data still exists on the staging packs. Staging at a data set level is determined at data set OPEN time based on the DE?INE attributes for the data set. Since 18S/VS OPENs a data set only when required at the first DL/I call, any necessary data set staging could take place at the first DL/I call. Again, if the staging disk drives were not used for other work, this would not cause any delay in processing at the first DL/I call.
If your ISS/VS installation requires that bound data be available for critical processing during a relatively short period of time, for example 8 to 12 hours a day, it might be better or necessary to use the staging disk drives for other off-shift work. After the off-shift work has completed, and before IMS/VS critical processing is again started, it might be advisable to run a short IMS/VS batch job that OPENs the critical data sets and causes restaging and binding of the critical data. Then when IMS/VS critical processing is started, there will not be a delay for staging at the first DL/1 call.
Because most installations require IMS/VS to be up for more than one shift, it is not necessarily restrictive to dedicate bound staging space for certain critical data bases. This can greatly reduce the staging time that might otherwise be required if staging space was used for other work during off-shift operations.
2.92 IPIS/VS system/Application Design Guide
If certain staging drives are to be dedicated to bound staging space that will not be used by other work during off-shift, they should he put in a separate staging drive group to ensure that the disk drives are not inadvertently used when l~S/V5 is stopped.
The staging drive groups are set up at M55 Table Create time. lM5/VS data sets are allocated to the staging drive groups as par~ of normal IMS/YS initialization via the UNIT assignment in the DD statements for the data bases.
This section has described some of the points that should be considered to effectively use MS5 with laS/VS. With proper planning, the M55 can provide both added storage capacity and flexibility to the lKS/VS system.
Design and Control of a DB/DC System 2.93
I
'.........
L
This chapter includes considerations for design of both 1"S/V5 batch and telecommunication applications. Information concerning the data base interface applies to batch and online applications. The designer of a telecommunication application should cover all material in this chapter prior to designing his application. The designer of the batch application need only cover the material relating to batch applications, but is encouraged to cover the entire chapter prior to design of an application.
GENERAL CONSIDERATIONS
Design of IMS/VS batch application programs deals with the environment shown in Figure 3-1. This environment is established through the IMS/VS system definition utility. Considerations for establishing this environment can be found in Chapter 2 of this manual.
The application program, in conjunction with IMS/V5, runs as an operating system job in VS1 or V52. For the individual application program design, DL/I can· be looked at as an additional access method. The logging facility is a system function and does not involve the application program directly. Changes to the data base are automatically logged. Instead of the standard OS/VS terminology of SYSIN (input) and SYSOUT (output), TRANSACTION input and RESPONSE output respectively are used. This choice of nomenclature is used to encourage the design of a transaction-oriented system.
A transaction-oriented system can reduce recovery problems for program abnormal terminations and system failures. A transaction-oriented system is one in which there is a definite po!nt at which each transaction (input) is considered complete. This point must be prior to receiving the next transaction. This isolates recovery problems to a particular transaction.
Design of the application program must be done in concert with data base design. Each influences the other. With good communications between application design and data base design, a more viable system will be developed. A viable system is one which accommodates change with minimum modification.
Programs that are OS/VS subtasks of an application program called by IMS/VS must not issue DL/I calls. If they do, the results will be unpredictable.
Application Program Design 3.1
OS!VS
r--------,
I
Lc--
I
APPLICATION
I
I
PROGRAM
I
I
I
IIL_--,
_
_
_
_
_
_
_
I
r
~
I
TRANSACTION RESPONSE
DATA LANGUAGE/I
DATA LOGGING
DATA
BASE
Figure 3-1.
Batch ~pplication Program Design
f~~£!m!in~ ~n~g!~! i~ ~! ~2!~
The use of IMS/VS should have little influence on the choic9 of a programming language for the application. The standard operating system CALL interface is used for COBOL, PL/I, and Assembler. IMS/VS offers no special advantage to these languages. However, the basic benefits attained by using a high level language do apply.
The Program Module Preload function of IMS/VS does offer a potential performance improvement, if application programs are written to be serially reusable or reenterable.
ihen designing an application program it is important to determine if there is a possibility of converting the program to a message processing program to be used in a telecommunication system. Kaking this determination prior to design of the application can save conversion 'lillie and cost.
3.2 IMS/VS System/Application Design Guide
Figure 3-2 shows the essential difference between the batch and
telecommunication applications with IMS/VS. In the batch environment, the application program deals with DL/I for data base input/output and with OS/VS data management for external input/output such as SYSIN and SYSOUT. The same application program is shown below after being converted to a telecommunication application. The basic change is the replacing of READ/WRITE or GET/PUT logic with calls to DtlI for external input (TRANSACTION) and output (RESPONSE).
BATCH
APPLICATION PROGRAM
PROCEDURE
OS/VS EXTERNAL INPUT/OUTPUT
DL/I DATA BASE INPUT/OUTPUT
INPUT OUTPUT
DATA
BASE
L
APPLICATION PROGRAM
TE LECOMMUNICATION
PROCEDURE
- DL/ITELECOMMUNlc'ATiON- ...---...
--t.... _INPUT/OUT~!..... _ _ _ _
-t....:.:.:::~:::._.....J
DL/I DATA BASE INPUT/OUTPUT
DATA
BASE
Figure 3-2. Planning Future Conversion to Telecommunication
Application Program Design 3.3
By centralizing the statements in the batch application program which deal with external input/output, the future conversion to telecommunication can be made with a great deal more ease.
BATCH CHECKPOINT/RESTART CONSIDERATIONS
A general facility for batch checkpoint/restart is provided. It
consists of a DL/I call function for checkpoint (CHKP) and the batch
backout utility program. Batch checkpoint/restart can be complemented
either by OS/VS checkpoint/restart or by installation-supplied
checkpoint/restart routines. Installation-supplied routines can be
simplified by using the IMS/VS restart call (IRST) and user-area
parameters on the CHKP call.
.
To use batch checkpoint/restart, the application first invokes its complementary checkpoint routines. If the user wants to issue an OS/VS checkpoint within a batch only region, he must first close all open data bases, generate a unique checkpoint ID, issue an OS/VS checkpoint macro,
and issue the DL/I call with a matching checkpoint ID (this is required because OS/VS restart does not restore data management storage in total). If the user wants IMS/VS to issue an OS/VS checkpoint for him, a fourth parameter, which points to an OS/VS checkpoint DCB, must be specified for the DL/I checkpoint call. Opon completion of those routines, and before issuing any other DL/I call, a DL/I checkpoint call is submitted. Along with the checkpoint call, the application passes the identification of its previously completed complementary checkpOint. DL/I ensures that all pending data base activity is physically recorded.
Then the supplied checkpoint identification is recorded on the log tape and supplied to the operator in a WTO message. Control is returned to the application program, which can then proceed to execute, submitting
other DL/I calls as necessary.
To restart at a selected checkpoint, the batch backout utility is used to restore th~ data bases to their condition at the time of the checkpoint. Then the batch job is restarted at the same checkpoint.
ESTABLISHING USEFUL CONVENTIONS
Designing applications for ase with IMS/VS affords an opportunity for establishing useful conventions and procedures. Adopting conventions which prove useful in application design and implementation can reduce costs and development cycle time.
Each program that is designed and implemented must be tested. Testing the application requires a test data base. A test data base requires a data base description generation, a program specification block generation, and a data base load program. Since a number of
application programs will be dealing with the same data structure, a central agency for generating and maintaining test data bases should
exist.
It is important to establish naming conventions for data bases, data segments, fields, PSBs, and programs. A requirement in the IMS/VS DB/DC system is that the name of the PSB and the application program must be the same. Adopting this convention in the batch system can reduce conversion time.
3.4 IMS/VS System/Application Design Guide
As the system increases in scope through time there will be multiple data bases, each with a number of different segment types. One naming convention which can be helpful is to adopt a two-character code as the first two characters for a data base name. This two-character code can then be used as a prefix for all segment names within the data base. This ensures that no two segments will have the same name, eliminating communications proble.s.
As the system becomes more complex with the relationship of programs, PSBs, data bases, segment types, and fields, a dictionary will be necessary. Questions such as, "What data segments and fields does this program update?" or "Which programs update this segment?" could be included in a data dictionary. Maintenance and control of such a dictionary should be the responsibility of the systems Operation personnel responsible for all system control.
q~~ Q{ £Qf! Q~ I!£~yal
Extensive use of COPY or INCLUDE can be made for segment I/O area definition, PCB masks, and segment Search Arguments (SSAs) within an application program. The use of COpy or INCLUDE in conjunction with a data dictionary can reduce maintenance disruptions to a minimum.
Figure 3-3 shows an application program that is making use of standard operating system data sets and DL/I data bases. DL/I makes use of standard OS/VS data management facilities and provides a special access method called OSAM (Overflow Sequential Access Method).
I<: ;:::;;,
OSNS
< ::::
L
DATA FILES
r-.------------
DATA MANAGEMENT
DATA BASES
........ .......
...... .....
'"
APPLICATION PROGRAM
~
- DATA
LANGUAGE!I
Figure 3-3.
Application Program Using OS/VS Data Files and DL/I Data Base
Application Program Design 3.5
A parallel can be drawn between operating system data management input/output and DL/l input/output. Figure 3-4 shows an application program making use of the READ/WRITE logic of COBOL, which in turn makes use of a file description block. The same program is also reading and writing a data base through DL/I. The DL/I interface makes use of the standard OS/VS CALL facility. The control block for DL/I that replaces the file description of the operating system is called a program communication block (PCB). Just as a file description block is used for each file that is accessed by a program, each logical. data structure that is accessed requires a program co.munication block. The I~l!~ !~21~£aiLQn ~£Qg£a~!ing R~[~[~n£i ~~ngal provides a discussion of logical data structures and their relation to data bases.
A unique characteristic of the application program interface with DL/I is that all information passed across the interface is described symbolically. There is nothing in the interface definition which relates to a specific access method or physical storage organization.
FILE DESCR.
READ WRITE
APPLICATION PROGRAM
CALL DL/I CALL DL/I
PROGRAM COMMUNI· CATION BLOCK
< .::>
DATA FILE
.......
.......
Figure 3-4.
< :>
DATA BASE
-- ......
Application Program Using COBOL READ/WRITE Logic and File Description
Details of CALLs to DL/1 can be found in the !~~l!~ !2~1~£!!i2n f£2~£a!!ing Ri[i£in£i ~a~a!·
Traditionally, application programs have been designed to obtain an entire record from a file and then deal with only selected portions of the record for reference or update. The application program was record oriented. With DL/I, the application program is designed to obtain only those portio~s of the record necessary to perform the required procedure. I/O is on a segment basis. The segment can contain one or more fields of information.
The fact that I/O is on a segment basis should have some influence on the design of the application, as well as on the design of the data base. Once a segment is retrieved with a Get Hold type call, the next call using the same data base PCB can be a replace or delete call. If an intervening call is made, it would be necessary to do another Get Hold type call to update the segment. One way to avoid this is to use multiple data base PCBs for the same data base. This allows multiple positions, as well as multiple segments, to be in HOLD status at one time.
3.6 IMS/VS System/Application Design Guide
(r.......,
Application programmers are sometimes faced with a decision concerning the use of DL/1 fUnction codes and segment search arguments.
A function code is a four-character code which is supplied to DL/I by
the calling application program to specify the input/output function to
be performed. S5As (segment search arguments) are used to give specific
information about the path to be followed in satisfying a call. SSAs
are qualified or unqualified. An unqualified 5SA specifies only the
name of the desired segment. A qualified SSA specifies, in addition to
the segment name, a field name within the segment, a relation operator,
and a comparative value.
For segment insert, delete, and replace, there is only one code for each specif.ic function to be performed. For the segment retrieval function, however, there is a family of function codes: GET UNIQUE (GU),
GET HOLD UNIQUE (GHU), GET NEXT (GN), GET HOLD NEXT (GHN), GET NEXT WITHIN PARENT (GNP), and GET HOLD NRXT WITHIN PARENT (GHNP). Each of these call functions provides for a variation in the method of retrieving a segment, depending on the existing position in the data base and the segment qualification. There are times when more than one of these calls will accomplish the same thing.
When faced with a choice of GU, GN, or GNP with or without the HOLD option, there are a number of considerations. In addition to choosing a function code, the question of whether or not segment search arguments (SSAs) should be provided must be answered. If the SSAs are provided, the question of qualified o~ unqualified must be answered.
Generally speaking, the GU call is used to retrieve a specific segment o£ to obtain a specific position within a data base. The GN or GNP only moves forward in the data base, except when the F command code is used. Once a logical position is established within a data base, the
GU or the GN and GNP, used in conjunction with the F command code, are the only calls which can establish a position at some earlier logical point in the data base.
There is no measurable difference between a GU, GN, or GNP call, if each has fully qualified SSAs and no logical position exists within the data base. If a logical position exists and movement is forward, a GN or GNP function call may be more efficient. An additional difficulty in making a choice of GU function calls comes when there is insufficient knowledge to provide complete qualification.
Normally, a GU call r~quires more time to execute than a GN or GNP call statement.
The implications of providing unqualified segment search arguments can be seen in Figure 3-5. The calIon the left has an unqualified segment search argument at level two for B. As a result, DL/I searches through all Segment Bs under Segment A with key of 6. All Segment Cs are searched before finding that the call cannot be satisfied. The call on the right is the same, except that the segment search argument for B is qualified at level two. When DL/I encounters the B with a key of q, the search ends. At this point, DL/I realizes that the call cannot be satisfied.
Application Program Design 3.7
A 6
I I
8
B
I--l
1 17/. 1
/~ ~'l ,1/
'/1 I
6
C
1~
r
5
0 2
GU A (KEYA=6) B C (KEYC=4)
GU A (KEYA=6) B (KEYB=3) C (KEYC=4)
Figure 3-5. Qualified Segment Search Arguments
RELATIONSHIP BETWEEN DL/I CALLS AND PHYSICAL I/O OPERATIONS
Although DL/I calls issued by application programs are independent of the physical storage techniques used to store and access data, it is important for the reader to understand the the physical I/O operations performed by IMS/VS. The use of any DL/I call mayor may not require physical I/O operations. If the DL/I call can be satisfied from information in the data base buffer pool, no physical I/O operations are required. When this is not the case, the actual physical I/O operations performed depend upon the following:
· The DL/I call issued
· The physical data base access method and organization
· The current position in the data base known by the DL/I control
blocks for this application's use of the data base
· Information in the data base buffer pool
The following tables should be of assistance in understanding the physical I/O operation which may be performed in satisfying GET UNIQUE (GU) or GET NEXT (GN) callG.
3.8 IMS/VS System/Application Design Guide
I~S/VS DB/DC CONTROL PROGRAM
r----------1---
-------------------------------------------------,
DL/I ! DATA
BASE
ACCESS
METHOD
CALL 11---H-I-SA--M----,----H-D-A-M------I--------H-ID-A-M----------------11
1
1
1--------------------------- 1
FUNCTION I
1
,INDEX, HIDAM
I
I
1
I
! Data Base 1 Data Base
1
1, ----------,-------------, ------------I------------,---------------1,
1
I VSAM-Get J VSAM-Get ! VSAM-Get !VSAM-Get Direct,
I Direct 1 Direct ,Direct I
1
GU
, or BISAM I or OSA" ,or BISAM lor OSAM
,
I or OSAM I Read
, Read
,~ead
1
, Read,
, or OSAM I
1
,
I
,
1 Read
1
I
--------------------------------------------------------------1
1
GN
VSAM-Get Direct or BISAS
or OSAK Read
VSAM-Get Diract
or 05AM
Read
VSAM-Get Direct or BISAI!
Read or OSA!!
I VSAM-Get Direct 1
I
I
,
lor 051M
,
IRead
,
!
Read
!
1
L--------------------------------------------------------------~
Application Program Design 3.9
IKS/VS DB BATCH PROCESSING
1r----------,----------------------------------------------------,,
1 DL/I I DATA
BASE
ACCESS
KETHOD
,
1I CALL ,I----H-IS-A-M-----I----H-D-AM------I--------H-ID-A-I-1---------------!
I I I FUNCTION 1
I 1
1I ---IN--D-E-X--------H-I-D-A-K--------,!
I
1
,
, Data Base Oa ta Base
,
1, ----------I------------' ------I ------------------ ---------------1,
I
I VSAI1-Get- 1 VSAI1-Get 1 VSAK-Get VSAM-Get
I
I
1 Skip Seq 1 Direct
1 Skip Seq
Direct
!
1 GU
1 or QISAK 1 or OSAS ,or QISAS or OSAK
I
!
I Get
i Read
, Set!. &
Read
,
I
I
I
, Get
I
I
I
1
1-----
I
I
, VSAI'l-Get- ,
I VSAM-Get-
,
I
,Direct,
I Direct
,
,
I or
I
, or
I
!
, BISAM,
I BISAH
,
I
I Rea d '" I
I Read *
I
,
I
I
,
1
,-----------------------------------------------------~--------,
I
I VSA~-Get- ,YSAM-Get ,YSAM-Get- I VSAM-GET
,
I
I Skip Seq I Direct
,Skip Seq 1 Direct
I
I GN
1 or QISAK I or OSAI1 ,or QrSAI1 I or OSAI1
,
I
I Get I OSAM , Read
, Set!. & I Read
I
1
I
1I R-e-ad----,I
,1 -G-et- - - - ,I
,I
I
I YSAM-GET I
I VSAM-GET I
,
I
I Direct I
I Direct ,
,
1
1 or
,
I or
1
,
I
I BISAM
I
I BISAI1
i
!
* ' * , I
I Bead
I Read
1
---------J LI -- _________I ____________I ____________I ____________I ______
,
* BISAH read or VSAM Get Direct is used if two or more data base PCBs
are defined in an application program's PSB for one physical data base. Random or direct access operation is assumed. QISAM SetL/Get or VSAM Skip Sequential is used if one data base PCB per physical data base is used.
It is suggested that, where possible, the GET NEXT call, with or without SSAs, be used in preference to the GET UNIQUE call function for segment retrieval. This results in more efficient operation. Remember, however, that the GET NEXT call function can only be used to progress forward in a data structure, and across data structures in a data base.
PERFORMANCE CONSIDERATIONS
During execution of the batch application program, statistics are accumulated by DL/I concerning reading, writing, and buffering activity. This information can be utilized to tune the application for higher
performance. Details for obtaining these statistics are in the I~§L!~
!e£~!£~!!~ ~£Qg£~miug a~t~£~u£~ ~~ng~!·
3.10 II1S/VS System/Application Design Guide
L
TELECOMMUNICATION INPUT/OUTPUT INTERFACE
Design of a TP (telecommunication) application encompasses the batch
application program design as well. There is little difference between
the batch program and th~ telecommunication program when using IKS/VS.
Figure 3-6 shows the environment in which the TP application functions. This shows 01/1 as the interface between telecommunication terminals as well as data bases. The application program in a TP
environment deals exclusively with DL/I for input and output for
terminals as well as data bases.
OS/VS
'-"
I MS/VS CONTROL
~
I'
I~~~~::~-:~:-ION-~~~-
Ir
DATA COMMUNI CATIONS
r----l
I APPLICATION 'I
I PROGRAM
I
I
I
I
I
I
I
I
L_.__ I
I
l
.JI
r----l
I II APPLICATION I I I PROGRAM
I
I
I
I
I
I
L_-.__ lI
I
...JI
MESSAGE QUEUES
~---+---+-I
DL/I
0lIl(----...1
I
:---:
/
~---J '---~--........0
lIl(- ' - - - - - - - -
/~----~--~----~
DATA BASE
Figure 3-6. Telecommunication Application Program Design
The three areas shown under the operating system each represent operating system jobs. Each is under a different storage protection key. The job on the left consists of the IMS/VS control program, which is responsible for all physical input/output for IKS/VS applications. The control program is also responsible for maintaining logical
Application Program Design 3~"
information for restart and recovery purposes. The two application programs shown are each contained in a message processing region. Each message processing region is an operating system job. This IMS/VS control region is responsible for causing the appropriate application program to be loaded for processing.
With I~S/VS, the interface to data bases is unchanged when gOing from a batch application to a TP application. In addition, the same interface used for data bases is used for input and output to terminals.
The application program deals with logical terminals. These are control blocks that IMS/VS associates with physical terminals. Thus the application programmer generally does not concern himself with the. physical attributes of the terminal with which he is dl'!!aling·. Figure 3-7 shows an application program's view of the terminal.
The control block with which the application program deals is the TP PCB {telecommunication program communication block). There are two types of TP PCBs -- the I/O PCB and alternate PCBs. An I/O PCB is always provided by I~S/VS to an application program that executes in a TP environment. Alternate PCBs are optional, and are created as part of the PSB (Program Specification Block). To obtain an input message and reply to it, the application program must reference the I/O PCB. To send a reply to a terminal other than the terminal that orginated the input message, the program references an alternate PCB. The section named "Output to Alternate Destinations" contains a further description of alternate PCBs. Figure 3-8 shows a DB PCB (data base program cOllmunication block) in addition to the TP PCB. The data base is viewed as a logical structure and the terminal is viewed as a logical terminal.
APPLICATION PROGRAM
/
I
8--1--~
I I
---- MASK
~~
I
\
J
, \
'\
Figure 3-7. Application Program's View of the Terminal 3.12 IKS/VS System/Application Design Guide
APPLICATION PROGRAM
/
--~ I
I
BASK
--
----~
I \
, \
"
Figure 3-8.
/
I
,I
I
\
\
\
LOGICAL
\
DATABASE STRUCTURE
" "
DB and TP PCBs
Information received from or sent to a terminal is called a message. A message is comprised of one or more segments. Figure 3-9 shows the format of a message segment. The L field specifies the length of the segment. If line addressing is being used, field Z is used for screen control when sending output to a 2260 or 2265 Display Station. The Z field is followed by the message text. This is the information input at the terminal. Below the segment format are shown two examples of input -- one with a password and the other without. Notice that the password has been eliminated from the text prior to the application program
receiving it.
r---1-. ---------z-·------------TE-X--T--------,
,, L--------------------------------------~
!
1
1
I
1--> Message segment up to '30 characters
1
I
1--> Reserved for DL/I (halfword binary)
I
1--> Segment length in bytes including L, Z, and TEXT
(halfword binary)
Terminal input segment with password:
TRANS (PASSWORD) THIS IS THE
SEGMENT TEXT
Received by application:
TRANS THIS IS THE SEGKENT TEXT
Terminal output segment
without password:
TRANS THIS IS THE SEGMENT TEXT
Received by application:
TRANS THIS IS THE SEGMENT TEXT
Figure 3-9. Message Segment Format
Application Program Design 3.13
Calls for input message seg.ents are like calls for data base record segments, except that no segment search arguments are required. The get unique call is used to obtain the first segment of each message and the
get next call is used to obtain subsequent segaents. Figure 3-10 shows the format of the input call. The three parameters s~own being passed to DL/I are the function code, the I/O PCB address, and the address of an input area. Message A, as shown, consists of three segments, while
Message B consists of two segments.
ENTER LINKAGE. COKMENT ONLY
CALL 'CBLTDLI' USING IFUN, LTPCB, IMSG-IO-AREA.
ENTER COBOL. COMMENT ONLY
MESSAGE A
r--------------------------------------,
I
FIRST SEGMENT
I <---------GET UNIQUE
11----------S-E-C-O-N-D---SE-G-M--E-N-T--------------11 <---------GET NEXT
11 ----------T-H-I-R-D--S-E-G-M--E-N-T---------------1I <---------GET NEXT
L--------------------------------------~
MESSAGE B
Ir----------F-I-R-S-T--S-E-G-M--EN-T---1-------------,, <---------GET UNIQUE
11----------S-E-C-O-N-D---SE-G-M--E-N-T--2------------11 <---------GET NEXT
L--------------------------------------~
Figure 3-10. Input Call Format
QYi£~1 £sl!§
Sending output to a logical terminal is like inserting new segments to a data base. As with the input call, no segment search arguments are required. Figure 3-11 shows a three-segment message being built. The parameters passed in the call to DL/I represent the function code, TP PCB, output area, and message format name. The message format name is ignored on systems without the Message Format Service. Format of the output message is the same as that of the input message. The application programmer must supply the character count.
3.14 IMS/VS System/Application Design Guide
Message X
r------------------------------,
1
I
I
FIRST SEGMENT
I
1I ------------------------------1I
I
I
1 I
SECOND SEGMENT
I I
1------------------------------1
I
I
1
THIRD SEGMENT
1
I
1
L------------------------------~
CALL 'CBLTDLI' USING OFCN, TPPCB, OftSG-IO-AREA, KSG-FMT.
CALL 'CBLTDLI' USING OFUN, TPPCB, Ol'lSG-IO-AREA.
CALL 'CBLTDLI' USING OFUN, TPPCB, OMSG-IO -ARE A.
Figure 3-11. Three-Segment Message
OUTPUT TO ALTERNATE DESTINATIONS
In addition to sending output back to the terminal that generated the input, the application program can sand output to additional destinations. Output can be sent to other logical terminals or to other programs. The mechanism for sending to these alternate destinations is the alternate PCB, as shown in Figure 3-12. When sending output to another program, the receiving. program can ~e a message processing program or a batch message processing program. The batch message processing program, in addition to making use of online data bases and message queues, can utilize operating system data management facilities. Use of batch message processing programs is discussed later in this chapter. For information on Past Path use of alternate PCBs see the "Fast Path and I~S/VS Interrelationships" section in the chapter "Design Considerations for the Fast Path Feature."
L
Application Program Design 3.15
APPLICATION PROGRAM
r---T-i""""''''''''---''''
I
I
I
I L
MASK I
I/O
PCB
___ .LI _ _ -'-_ _--I
r---r---r-----,
I
I
I MASK I
ALT.
TERMINAL
I I L
_
_
_
-L
_
_-
PCB
' -_ _ _....
/
/ I
I \
, \
\
/
/
I
f
\ \
\
r---"'-
I : MASK
ALT. 'PROGRAM
I PCB
L _ _ --' _ _ _ L.-_ _--'
/ /
(I I PROGRAM X
\ \
"
Figure 3-12. Output to Alternate Destinations
The modifiable PCB and change call have been provided for those users who would otherwise require a prohibitively high number of alternate PCBs to allow for all possible destinations. This would, for example. be those 1050 or 2780 users with a requirement for an alternate PCB for each component assigned to the terminal represented by the I/O PCB. Without this function these users would require as many as four alternate PCBs per terminal defined in the system. By providing a naming convention within the IMS/VS system to allow the application programmer to identify a group of logical terminals by I/O PCB name. this requirement could be reduced to four modifiable alternate PCBs or less.
For example: If NAME is found to be the I/O PCB logical terminal name, NAMECP is the logical terminal assigned to the card punch, NAMEPFT is the printer. etc. With this convention the user could add the suffix CP to the I/O PCB name to cause output to go to the card punch associated with the physical terminal that entered the message. PRT would allow the Qutput to go to the printer, etc. This requires that
3.16 IMS/VS System/Application Design Guide
the naming convention be established by system definition and maintained by instructing the master terminal operator to reassign component tTERKs by groups, so that all the components are always associated with the same physical terminal.
This function could also be used by any application that, depending on the processing involved, requires one of many possible output
destinations.
The user should define one modifiable PCB per possible destination
per transaction, as the destination can be set only once per message without as~ of the purge call, which is not recommended. This means simply that the destination cannot be changed once a message segment has been inserted to the PCB until a get unique to the I/O PCB is issued.
Normal use of the function would therefore be:
GU CHNG ISRT GU
CHNG etc.
I/O PCB Modifiable alternate PCB Modifiable alternate PCB
I/O PCB
Modifiable alternate PCB
An alternate PCB can be used to respond to terminals in response
mode, conversational mode, or exclusive mode, if the PCB is so defined
on the alterna~e PCB statement. Use of this response alternate PCB
allows the application program to send output to a logical terminal that
did not originate the input message, while still satisfying the
L
requirements of these operating modes. This response alternate PCB is only valid for naming a logical terminal.
IMS/VS can also be directed to verify that the logical terminal named in the response alternate PCB is assigned to the same physical terminal as the logical terminal that originated the input message. This verification is required for alternate response PCBs used by conversational programs and response mode transactions. Verification is not needed if alternate response PCBs are used to send messages to
output-only devices that are in exclusive mode. Additional information on response alternate PCBs is found in !tt2L!2 !E~li£~liQn f~Qgt~mming
g~!~t~n£~ a~nY~l·
CONVERTING FROM BATCH TO TELECOMMUNICATION
Conversion from batch to online with IMS/VS can be a simple process. Figure 3-13 shows a batch application program which deals with DL/1 data bases. The procedural portion of the application program differs little between batch and TP. The DL/I data base I/O calls need not be altered at all. The area of conversion will be that portion which deals with external input (SYS1N) ana output (SYSOUT). The TRANSACTION and RESPONSE in the application program shown represent the primary input and output. The READ/WRITE or GET/PUT in the batch system are replaced by DL/I calls for input and output for telecommunication. Instead of the input coming in from SYSIN. it comes from a logical terminal. Output, instead of be5,ng written to SYSOUT, is written to a logical terminal. It can be seen that use of DL/I for transactions and respons~s as well as data base I/O, makes DL/I the single I/O interface with which the application program deals.
L
Application Program Design 3.17
r - - - - - - - - - - - , APPLICATION PROGRAM
:
PROCEDURE
:
TRANSACTION
I
OSNS
READ I
I
EXTERNAL INPUT/OUTPUT WRITE
RESPONSE
/
/ I
CONVERTING I
TO TElE- ,
COMMUNICATION I
I
\
\
I
Dln
I
I
I
DATA BASE INPUT/OUTPUT
II
L ___________ J---t"----'"
DATA BASE
'''-{
DLII TELECOMMUNICATION CAll Dl/I .....E--~
INPUT/OUTPUT
Figure 3-13. Converting from Batch to Telecommunication
T!LECOKMUNICATION DEVICE INDEPENDENT PROGRAMMING
If a variety of devices are to be used on an IKS/VS telecommunication system, some consideration should be given to designing application programs in such a way that input is processed properly regardless of the physical terminal type from which it is received. For example, input might be received from either a 2740 Qr a 3270. The maximum physical line length for a 2740 is 130 'characters, and one line of input is handled as one message segment. For a 3270, on the other hand, the user defines the structure and length of a message segment.·
If I/O formats are to be consistent between devices with different length I/O characteristics, design must be aimed toward the limiting device. For example, a 3270 can only accommodate 80 characters on each line, while the 2740 can handle 130. A design for a 130-character line would not operate identically with the 2740 and the 3270. Another approach is to have the application program written so that it can determine the class of device with which it is dealing. This can be accomplished through the use of naming conventions. For example, the first character of each logical terminal associated with an 80 character device could begin with the letter V.
The application program has access to this name at the time the message is acquired.
DEVICE CLASS CONTROL CONSIDERATIONS
Control ~haracters for control of output devices are the responsibility of the application programmer. The 2260, 2265, and the 2265 component of the 2710 system makes use of the Z field in the message format shown earlier, in conjunction with the line addressing feature of the 2260/2265 and the paging feature of IMS/VS. On a 2980 General Banking Terminal Model 1 or Model 4, the Z field of the message format is used to direct output message segments to a passbook; on a 2980 Model 2 terminal, this field is used to require the presence of the
3.1S IMS/VS System/Application Design Guide
auditor's key, in order to receive an output message segment. Switched dey ices (except 3270) also make use of the Z field in the message format shown earlier. This is used by the application program to request that the line be disconnected after the present message is sent. This field is ignored by communications control if the output is physically sent to a device without this capability.
Carriage return characters, or new line symbols, are embedded in the text portion of the message by the application programmer. If output is going to a 2770 printer component, 2780, or local printer (SYSOOT) device, the first two characters of the message can be carriage control characters. These are also the responsibility of the application programmer.
Vocabulary drum address characters may be the text portion (or part thereof) of the message going to a 7170-3 line. These are also the responsibility of the application programmer.
Under special conditions, it may be desirable to terminate an output message at a specific point. The DL/I purge call with TP PCB address can be used to accomplish this function. Figure 3-1q shows two messages to the destination being built.
The purge call releases the output message segments for processing without waiting for the application program to signify normal completion (by a get unique of the next transaction or normal termination) of the current transaction.
ENTER LINKAGE. COMMENT ONLY
CALL 'CBLTDLI' aSING PURG, TPPCB.
ENTER COBOL. COMMENT ONLY
Message A(1)
,r----------F-I-R-S-T---SE-G-M--EN-T----------------,I <---------INSERT
11----------S-E-C-O-N-D---SE-G-M--E-N-T--------------1I <---------INSERT ,1----------T-H-I-R-D---SE-G-M--E-N-T---------------1I <---------INSERT
L--------------------------------------~ <---------PURGE
Message A(2)
Ir------F-I-R-S-T---(F-O-U-R-T-H-)---SE-G-M--EN--T----------,1 <---------INSERT 1, ------S-E-C-O-N-D---(F-I-F-T-H--) --S-E-G-M-E-N-T----------11 <---------INSERT 1L1 ------------T--H--I-R---D-----(-S--I-X---T--H--)-----S--E--G--K--E--N--T----------_-_-_-_-_-_-_1~I <---------INSERT
<---------GET UNIQUE or program termination
Figure 3-14. SiX-Segment Message Separated into Tvo Three-Segment Messages by Use of the Purge Call
Application Program nesign 3.19
UTILIZATION OF SYSOUT DEVICES
The use of support provided for SYSOUT devices (printers, tape, or DASD) allows a wide range of applications, including:
· Local terminal simulation using a card reader and printer.
· High volume output, such as reports using either a printer or tape volume.
· Intermediate output to be used by a non-IMS/VS application program using either tape or disk volumes.
Since record formats, logical record lengths, and block sizp.s are user-defined, a SYSOUT data set can have a variety of different attributes.
By using the spool SYSOUT option, a local printer can be simulated without dedicating the device to the IMS/VS system.
SYSIN data streams can be assigned to a local card reader line, providing a means by which nonconversational telecommunication application programs can be tested. When such an assignment is made, a program can be tested with data entered through SYSIN and output produced using any of the optional types of SYSOUT support available. Only one file of data can be entered per line. Any logical errors detected in processing the data stream (for example, invalid transaction codes) are ignored by IMS/VS. Care must be taken to avoid undesirable results when this type of error occurs in the first segment of a multisegment transaction, since all following segments are processed as new messages.
When SYSIN data streams are used by IMS/VS, no logging of position occurs while messages are being processed. Consequently, only a cold start of IMS/VS operation should be performed after using SYSIN input streams, or duplicate message processing may occur.
CONVERSATIONAL PROCESSING
Conversational processing is an optional IMS/VS feature available to users of the data communications facility. It allows a user's application program to retain information acquired through multiple interchanges with a terminal, even though the program leaves the message region b~tveen interchanges.
If conversational processing is to be used, it must be considered during system definition. Transactions that will invoke a conversational program must be identified at this time. The user must also describe the number and size of the SPAs (scratchpad areas) to be allocated, either in main storage or on a direct access device. An SPA is used to contain the information to be retained during conversational interchange s.
Figure 3-15 shows a simple conversational process. When IMS/VS receives a conversational transaction it assigns an SPA to the input terminal and schedules the associated application program.
3.20 IMS/VS system/Application Design Guide
r------,
[ SCRATCH ,
L _P_AO___ ...lI
Figure 3-15. Conversational Program
When the program executes and issues its first GU, it receives the SPA. The first segment of the message input from the terminal is obtained by a GN call. After processing the segment, the program must issue an ISRT call to return the SPA to IMS/VS. IKS/VS retains the scratchpad either in main storage or on disk until needed. Th@ program then must use ISRT to send an output message to the terminal in conversation.
A response to the terminal in conversation is required to allow the conversation to continue. The conversational transaction need only be entered to initiate the conversation; during subsequent interchanges IHS/VS considers all input from that terminal to be a part of th@ conversation.
IMS/VS allows more than one program to participate in a conversation. One conversational program passes control to another, either by changing the transaction code in the SPA to another conversational transaction, or by inserting the SPA to an alternate PCB identifying the program to take control of the conversation.
When a conversation is processed to its normal completion, it is terminated by the application program. The program places blanks in the transaction code in the SPA before returning it through the ISRT call. The prograa can also put the code of a nonconversational transaction in the SPA; the conversation then remains active until the next input is received from the terminal. IKS/VS routes this input to th~ nonconversational transaction, thus terminating the conversation.
IMS/VS terminal commands are valid during a conversation. Commands are provided, in fact, to allow the operator to temporarily susp~nd a conversation in progress {/HOLD command) and to resume it at a later time (/RELEASE command). The /EXIT command is available for the operator to terminate the conversation.
Some applications require that a conversational process not be interrupted once it has started. This is because non-program initiated termination could result in partially-updated data bases. This type of termination can occur if the operator prematurely uses the /EXIT command, or if a program involved in the conversation abnormally terminates. When this condition occurs, a user exit routine can be entered to analyze the termination and, if desired, to cause another program to be scheduled to complete or backout any data base updates. The user exit routine cannot cause the conversation to continue. The
Application Program Design 3.21
Ia~~ 2Y2i~~ ~~Q~~~~~ ~ef~~n£~ ~!n~al contains specifications for a conversation abnormal termination exit routine.
For information on the Automated Operator Application Program, see the "Automated Operator Programming" chapter, in the U~L!~ ~Itl~!!
f~2g£!!!!ng B~!~£~n£~ ~!n~!!·
PAGING FEATURE -- 2260 AND 2265
The paging feature allows an application program to insert a multiple screen message to the 2260 or 2265 which can be viewed by the operator in any sequence he wishes. If, after viewing the first screen, the operator chooses to skip all remaining screens and go to the next message, he can. Alternatively, as an example, he can look at the first screen, page forward to the 17th screen, page back to the fifth screen, view several screens in sequence, etc. He can go to the next message or series of screens at any time, whether or not he has looked at all the screens in this series. Once this option is taken however, he cannot return to look at any image from a previous series. IMS/VS prevents the operator from inadvertently paging past the end of one series into another, thus losing the current series.
The opera'tor is supplied with a page-request indicator (=) to specify which page is to be viewed next. If Auto Delete was specified in system definition, any other input message, that is, one that does not begin with a page-request indicator, causes the series of pages being viewed to be considered complete and the series to be dequeued. Therefore, when an operator has completed viewing a series of pages he has merely to enter a new transaction code to signify this to the system. If a multiple-page message is routed to a non-paged terminal, such as a 2740, the paging is ignored, and the message is transmitted as any other message. If Auto Delete was not specified, the operator can enter a message while viewing a page. This causes the first page of the series to b~ redisplayed, and the operator must specifi'cally enter a next-output indicator (1) to cause the series of pages to be dequeued. While this mode of operation may have merit in specific applications, it may prove cumbersome to the operator in a generalized system application. It is recommended, therefore, that the user be aware of the operational procedures required for non-Auto Delete operation before specifying this mode of operation.
While the IMS/VS telecommunication system is in operation, it may be desirable to let a batch program have access to online data bases or input/output message queues. This can be accomplished by a batch message processing program (BMP). This program is loaded in the conventional operating system manner. It has access to online data bases and message queues, and can also make usa of operating system data management facilities.
When starting a BMP, several parameters may be specified on the EXEC statement. These include the PSB and program name. For message processing programs, the PSB and program name must be the same; however, they can be different for BMPs. This allows a utility program to be run using different PSBs.
BMP can implement a checkpoint to purge data base and message buffers. It writes a checkpoint ID to the system log. This checkpoint is independent of CTL (control region) and other BMP region checkpoints. IMS/VS maintains a checkpoint table to correlate BMP checkpoints with control region checkpoints for purposes of emergency restart. Design considerations for using this checkpoint table are contained in
3.22 IKS/VS System/Application Design Guide
chapter 2 under the topic "Batch Checkpoint Restart." The !~~l!~ !~1~c~~i2n f~2g~~mm!ng ~~t~~~n~ ~sng~! contains a description of the checkpoint (CHKP) call.
Emergency restart after a system failure backs out all resources for each BMP region to the last checkpoint for that B~P region. The master terminal operator has the option of specifying that BMP data base changes NOT be backed out at emergency restart.
If there is no bacKout for a BMP, the operator also has the option of releasing the resources that were reserved for the B~P (that is, starting stopped data bases). If backout has been done, the resources are not reserved since data base integrity has been maintained.
USE OF BMP
The BMP is useful for several types of processing. If data is being collected for batch processing, the message processing program can retrieve the collected data from the queue. Upon a single loading, a BMP can deal with only one input queue (transaction code). The transaction code is also specified on the EXEC statement when the B~P is started. The BMP sends output to logical terminals or other programs through the queues. The BMP is useful for doing summary reports while the data bases are being utilized in a telecommunication environment. Use of the BMP to update data bases, while the online system is in operation, can prevent message regions from being scheduled when (1) the MPP and BMP use the same data base and that data base was not specified for parallel scheduling, or (2)' when PROCOPT=EXCLUSIVE is specified. Note also that BMPs that do not issue a checkpoint call m&y cause excessive waiting or deadlocks for MPPs accessing the same data base.
BUFFERING
Heavy utilization of data base buffers by a BMP can impact response time at a terminal, if a relatively small data base buffer pool is allocated. Since the pool is utilized for all data bases, and the oldest buffer is always freed for current I/O requests, additional I/O requests may be required for those telecommunication programs performing data base updates. It is possible that a message processing program may obtain a segment for update, and prior to the REPLACE call have the buffer containing the segment may be freed. DL/I must then reread the segment for replacement.
INTERMEDIATE DATA BASES
If the user wants to save information between loads of an application program, without making use of the conversational capability, intermediate data bases can be utilized. Figure 3-16 shows an intermediate data base being utilized for purchase order writing. Each logical terminal is represented by a root key in the data base. Since all logical terminal names are unique, there is no possibility of conflicts between terminals. The application program has access to the source of each input through the input/output logical terminal PCB.
Application Program Design 3.23
I~~~~-- ----------- ~--~~------,
~ ~-- ----------
Figure 3-16. Intermediate Data Base
MESSAGE EDITING If free form input is allowed from input terminals r a single message
editing routine is an alternative to redundant code in the COBOL or PL/I program. The message editing routine can convert the message from a free format into a fixed format.
The edit routine can be located in the IMS/VS control region or in the message processing region with the application program. If an edit routine is to be used a great deal r it should be included in the !MS/VS control region. In some instances this helps reduce the region size required for the message processing region.
If the edit routine is to be included in the message processing region as a part of the application program, the possibility of placing the module in link pack should be explored.
Use of a single message edit routine for all programs could have value for some user environments. The message edit routine could be the only user module making calls on DL/I for message input/output. This could reduce the amount of error checking required in each application program.
OUTPUTTING A MASK TO THE 2260 When a 2260 is being used in an interactive manner, terminal operator
time can be saved by having the application program send out a mask or form to the 2260. The terminal operator then fills in the appropriate information and transmits the entire screen as input.
PASSING INFORMATION FROM ONE PROGRAM TO ANOTHER When a program is to be designed in a modular fashionr there are
several ways in which information can be passed from one program to another. The first way is by sending output to an alternate destination through the queues. Another is to store information in an intermediate data base, as discussed earlier. A third way is to use a scratchpad area for passing the information from one program to another. If the scratchpad area is resident in storage r the input/output overhead is less than by the other approaches.
3.24 I8S/VS System/Application Design Guide
The data management portion of IMS/VS is designed to simplify the task of assembling and maintaining large amounts of data while still offering flexibility in how the data is organized and used. To accomplish this, IMS/VS uses an organization for data called a data base.
Under I~S/VS, different types of data bases can be created by the user. Each requires two definitions before the data base can be used by application programs. The user defines the data base structure and content through Data Base Description Generation (DBDGEN). He also defines what data within the data base each application program will user and what processing options each application program is allowed to use on that data through Program Specification Block Generation (PSBGEN). Each of the data base types is supported by and named after its own access method. The access methods and the data base type each is used for are:
· Hierarchic Sequential Access Method (HSAM)
HSAM
· Hierarchic Indexed Sequential Access
Method (HISAM)
HISAM
· Hierarchic Direct Access Method (HDAM)
HDAM
· Hierarchic Indexed Direct Access
Method (HIDAM)
HIDAM
· Logical
Logical
L
· Generalized Sequential Access Method tGSAM) · Main Storage Data Base
GSAM MSDB
· Direct Entry Data Base
DEDB
For information on the Main Storage Data Base (MSDB) and the Data Entry Data Base (DEDB) see the "Fast Path Data Bases" section in the chapter "Design Considerations for the Fast Path Feature."
A logical data base is comprised of data stored in one or more physical data bases that is structured logically to satisfy the requirements of an application program.
GSAM data bases are limited to a single, unstructured data set.
Prior to discussing the advantages and disadvantages of each type of data base, the concepts and terms used for IMS/VS data bases must be understood.
In general, an IMS/VS data base is a hierarchic organization of the different types of data required by one or more applications. We'll
examine first its content and structure, and we'll then describe the DL/I calls that are used to process a data base. Included in content are segments and fields. Structure includes the definition of the hierarchy of a physical data base. Note that GSAM data bases are not hierarchic and are based on physical records rather than segments.
Data Base Design considerations 4.1
SEGMENTS
A data base is a storage organization that enables the user to manage multiple sets of data, and multiple elements of each set. The content of a data base is defined by segment type through the DBDGEN utility. For each set of data the user wants to store in a data base, he defines a segment type and the physical characteristics to use when storing segments of that type. In turn, when multiple elements of data of a set are stored in a data base, they are stored as segments of the type defined and use the physical characteristics defined for that segment type. A segment in a data base is also called an occurrence. Both terms are used interchangeably to refer to a segment. A data base can contain a maximum of 255 segment types, and the number of segments of any type defined is limited only by the space allocated for the data base.
The input to DBDGEN that defines a segment type and the physical characteristics of that segment type is the SEGM statement. Among the physical characteristics defined for each segment type are the name, length, and hierarchic position to be used when storing segments of that type. The name specified is used to identify segments of that type in storage, and in turn, the application program uses the name of a segment type to address the type of segment to be processed. The length specified f'or a segment type tells 18S/VS the number of bytes of auxiliary storage to use for the data portion of each ~egment of that type. For the segments in storage that contain a prefix and data portion, the prefix is used by IMS/VS in managing the segment, and the data portion of the segment contains the user data. The length specified for the data portion of a segment type must be fixed, except when VSAM is used as the operating system access method. When VSAM is used, the length specified for the data portion of a segment type can be either fixed or variable. When variable length is specified, the amount of auxiliary storage space used for the data portion of each segment of that type can vary between a user specified minimum and maximum number of bytes. In the case of fixed, the data portfon of each segment of the same type occupies the same amount of auxiliary storage space. The length specified for a segment type cannot exceed the physical record length of the storage device used. The hierarchic position defined for a segment type determines how segments of that type are stored in a data base in relation to segments of other types. For an explanation of the hierarchic position of a segment type in a physical data base, refer to "structure" in this chapter.
SEGMENT FORMATS
When defining a segment type, the segment length specified by the user can be either fixed or variable. In either case, segments in I8S/VS data bases contain a prefix and a data portion except for three cases where only the data portion is present. For an H5AM, simple HSAft or simple HISAM data base that contains only one segment type, no prefix is stored with occurrences of the segment type in the data base.
The fixed and variable length format for segments in H5AM, H~SAM, HDAM and HIDAM data bases are shown in Figure 4-1.
4.2 IMS/VS system/Application Design Guide
Fixed length segment format
PREFIX
DATA
L
SEGMENT DELETE
POINTER AND COUNTER
FIXED LENGTH
CODE
BYTE
AREA
USER DATA
Variable length segment format
SEGMENT
PREFIX
DATA
I
DELETE POINTER ANt-D-C-O-UN-T-E-R--r---V-A-R-I-A-B~LEE:=JENGTH
CODE
BYTE
AREA
USER DATA
~-----~------~----~
Figure 4-1. Segment Formats
Segments in all data base types contain a prefix and data portion except in the 3 cases stated previously. The prefix of a segment
contains data used by IMS/VS that is transparent to application programs. The data portion of a segment contains user data. As a minimum, the prefix of a segment contains a segment code and a delete byte. The content of the remaining portion of the prefix varies by data base type. Segments are related through direct address pointers in HDAK and HIDAM data bases, so all segments in those data bases will contain
one or more pOinters in their prefix. Segments in HS1M and HISAM data bases are related through physical adjacency so they will have no direct address pOinters in their prefix. The one exception to this is a segment in a HISAM data base that is involved in a logical relationship with a segment in an HDAM or HIDAM data base. When the segment in the HISAM data base points to the segment in the 'HDAM or HIDAK data base, it can have a direct address pOinter specified to point to the HDAM or
HIDA!! segment directly. A counter is only present in the prefix of a segment under certain conditions when it is involved in a logical relationship. For the conditions under which the counter will be present in a prefix and the use of the counter, see "Pointers and the counter Used in Logical Relationships" in this chapter.
~!u~ni £2!l~
To identify each segment stored in an IMS/VS data base, a one byte segment code is placed in the first byte of the prefix of the segment. The segment code is a number from 1 to 255 that identifies a segment type to IMS/VS in place of its name. Segment code values are assigned to the segment types in a data base in asc~nding sequence starting with the root segment type and then continuing to all dependent segment types following the hierarchic sequence defined for the segment types in a data base by the user.
The delete byte is used by IMS/VS to maintain the delete status of segments within a data base. The meaning of each bit within the delete byte is shown in Figure 4-2.
Data Base Design considera~ons q.3
DELETE BYTE
BIT
MEANING
o
SEGMENT HAS BEEN DELETED (HISAM OR INDEX ONLY)
DATA BASE RECORD HAS BEEN DELETED (HISAM OR INDEX ONLY)
2
SEGMENT PROCESSED BY DELETE
3
RESERVED
4
DATA AND PREFIX ARE SEPARATED IN STORAGE
S
SEGMENT DELETED FROM PHYSICAL PATH
(PHYSICAL DELETE (PD) BIT)
6
SEGMENT DELETED FROM WGICALPATH
(WGICAL DELETE (LD) BIT)
7
SEGMENT HAS BEEN REMOVED FROM ITS LT CHAIN
(BIT 7 IS ASSUMED SET IF BITS SAND 6 ARE SET)
Figure 4-2. Delete Byte
FIELDS
An application program addresses segments in a data base through the name specified for their segment type, and through the names of fields defined within a segment type. The segment name alone allows an application program to address a specific segment type within a data base. To address a specific occurrence of a segment type, fields must be defined within that segment type.
Within the data portion of each segment type, the user can define fields through the DBDGEN utility. Each is defined through a FIELD statement which is input to DBDGEN. The maximum number of fields that can be defined within a segment type is 255 and the maximum within a data base is 1000. The two types of fields that can be defined are sequence fields and data fields. Both fields can be used by an application program to address specific segments in a data base. A sequence field, often referred to as a key field, has two purposes in addition to that of the data field. It is used to store occurrences of a segment type in a sequential order. The order is determined by the value placed in the sequence field of each occurrence. The value in the sequence field of a segment is called the key of that segment. Occurrences of a segment type are stored in ascending order in the data base starting with the occurrence that contains the lowest sequence field key. The sequence field is also used as all or part of a symbolic pointer to a segment in a data base. The symbolic pointer is actually the concatenation of the keys in the sequence fields of all segments that must be retrieved to reach the desired segment including the sequence field key of the desired segment as shown in Figure 4-3.
Only one sequence field can be defined in each segment type. Sequence fields can be defined as unique or non-unique by the user. When defined as unique, occurrences of a segment type must contain sequence field values that uniquely identify them within a data base, and segments are stored in the data base in the manner described previously. When defined as non-unique, sequence field values do not have to uniquely identify a segment within a data base. In this case, segment occurrences are still sequenced according to their sequence
4.4 IKS/VS System/Application Design Guide
field value which controls all segments except those with the same
value. If placement of those with the same value is of concern, the user
L
must control their placement either through his data base load program, or through the combination of his load program and by stating insert rules for segment placement through DBDGEN.
CONCATENATED KEYS
SEQUENCE FIELD KEYS
SKILL SEGMENT
STCLERK STCLERK
NAME SEGMENT
SM!TH STCLERKSMITH
L
EXPR SEGMENT
EDUC SEGMENT
RW8
PHAR
STCLERKSMITHRW8
STCLERKSMITHPHAR
Figure 4-3. Concatenated Keys
L
Data Base Design Considerations 4.5
STRUCTURE
The hierarchy of a data base is created by defining an order of dependence for the segment types it contains. To 18S/VS, the hierarchy represents the order in which the user wants his application data stored. To the application program, it represents the order in which the segment types in a data base are available for processing. The criteria normally used in determining the hierarchy is how th@ data in one segment type relates to data in another segment type, and the frequency in which a segment type will be accessed by an application program.
To understand how a data base hierarchy is developed, we'll us~ as an example a skills inventory application. We'll determine what segment types a data base should contain for the application and the hierarchic order of those segment types. In addition, we'll show the data base that CQuld result in storage by defining the segment types and th~ir hierarchic order through the DBDGEN utility.
Let's assume in our example that an application program wants to locate a given skill, and then find out what employees possess that skill. In addition, the application must have access to the experience and education records of each employee.
In the assumptions, four sets of data were required by the skills inventory application. Each will be defined as a segment type in our skills inventory data base. Let's now create a hierarchic data structure that reflects the order in which the four s~gment types are required by the application. To do this, we must determine both the order in which the application program must use each type of data, and the order in which each type of data must be presented to the application program so that the data retains its meaning. In the assumptions, it was stated that the application wanted to find a given skill and then find the names of the employees that possessed that skill. From this statement we know that skill should be the first type gf data in our structure and that name should follow skill. For the remaining types of data, experience and education, no indication was given as to how they should fit in our structure, but we can determine their position in the structure if we can establish how they should relate to the skill and name typ~s of data. For our application, experience and education data have no meaning by themselves, to each other or in relation to skill. When related to name data however, the experience and education types of data do have meaning since they are the experience and education records of specific employees. We can now complete our data structure. At the top is skill, below skill is name, and name in turn is followed by experience and education as shown in Figure 4-4. Experience and education are below name since they are dependent on name for the skills inventory application. An employees name must be established before his experience and education records have meaning. In turn, name is dependent on skill since the application will locate a given skill and then associate employee names to that skill. In summary, the data structure sh6wn in Figure S.q represents the sets of data and the order of dependence for those sets required by the skills inventory application. It contains four sets of data arranged in three levels of dependence. An IMS/VS data base can contain a maximum of 255 sets of data arranged in up to 15 levels of dependence.
4.6 IMS/VS System/Application Design Guide
SKILL
NAME
I
EXPERIENCE
I
EDUCATION
Figure 4-4. Hierarchy of Segment Types
The data structure just created is called a hierarchy of segment types. It represents the segment types and the hierarchic arrangement of those segment types that would be defined through DBDGEN to define our skills inventory data base. If we now assume data for each segment type, Figure 4-5 shows the data base that would result in storage.
Figure 4-5 shows how segments of each type can be loaded in a data base. Three occurrences of the skill segment type are shown. Related to each are the specific occurrences of the Name segment type that contain the names of the employees who possess that particular skill. Related to each Name segment in turn, are the specific segments of the Experience and Education segment types that contain the experience and education records of each employee. Skill is the root segment type in this data base, and each data base has only one. The root segment type is always the first segment type defined in a data base, and, as shown, it is the only segment type that occupies the first level of a data base hierarchy. Segments of all other types in a data base are stored in relation to an occurrence of the root, and as such are termed dependents of the root. In addition, occurrences ~f the Experience and Education segment types, shown at the third level of the hierarchy, are dependents of the Name segment type since they are stored in relation to occurrences of the Name segment type. When a data base hierarchy is read from top to bottom with the root at the top, each lower level in the hierarchy contains the dependent segments of the segments at the next higher level. Before any dependent segment is loaded in a aata base, the segments on which it is dependent must be loaded. In all cases, a dependent segment in a data base is dependent on one segment at each higher level in the hierarchy.
The major unit of organization for segments within a data base is the data base record. A data base is comprised of one or more data hase records, and a data base record contains one occurrence of the root segment type and all of its dependents arranged in hierarchic sequence. Hierarchic sequence for the segments in a data base record is top to bottom, then left to right passing through each segment only once. The skills inventory data base shown in Figure 4-5 contains three data base records, and the hierarchic sequence of each is shown.
Data Base Design Considerations 4.1
·-"=
.".Q..
CD
1.0
/:l
t1
If)
H
i:i:
~
til
I
"<:
til
UI
dHeifeirnaerdchIyhorfosue:;;~~;:~s
I SKJL~
til
'cI
I..I.I..
CD
~
.I.»...
19
I»
"iJ>f
'Q
Il' I»
'Q
III
.~ ...
0
(1)
....
..I..».....
0
t:!
.t..i.l.
t:!
0
t1
t='
I»
(1)
t.Q
I..I.I.
If)
t.Q
::J
«1
./.:.l..
0
CD
~:~
Resul ling da la base I.n storage
~ I
I
I
1-------- --
I
'
I
"
'.
~
" " ')
+
, /
~
l,
~
The hierarchy of a physical or logical data base can contain a maximum of 15 levels. The order of dependence for segment types in the hierarchy is from level one, or the top of the hierarchy, to level 15, the bottom of the hierarchy. The top level of the hierarchy of any data base can contain only one segment type. It is called the root segment type for that data base. Subsaquent levels below the root can contain any number of segment types such that the maximum of 255 total segment types in the data base is not exceeded.
u~tin~n~ ~ ghY§i£~l ~~i~ ~~§~ B~~£~I£hY
The input to the DBDGEN utility that defines the segment types a data base contains, their physical characteristics and their hierarchic position is the SEG~ statement. (The SEGM statement is described in the 1~§LY§ Yiil~!~~§ R~t~£~~~~ ~~~g~l.) For our explanation here, it is only necessary to know that a data base hierarchy is defined through the order in which SEGM statements are arranged for input to DBDGEN, and through use of the PARENT= operand of the SEGM statement.
The PARENT= operand of the SEGM statement is used to define the physical relationships that exist between the segment types on each two adjacent levels in a data base hierarchy. The two segment types involved in the relationships are called a physical parent and a physical child. A physical parent is a segment type that has a dependent segment type defined at the next lower level in the data base hierarchy. A physical child is a segment type that is dependent on a segment type defined at the next higher level in the data base hierarchy. These two terms are used to state the order of dependence for the segment types in a data base. In a data base with multiple segment types defined, the root segment type is the physical parent of all segment types defined at the second level of the data base. In turn, the segment types on the second level are physical children of the root. Each level of a data base contains the physical parent segment types of any segment types defined at the next lower level, and the physical child segment types of any segment types defined at the next higher level. The PARENT= operand of the SEGM statement is used to state specifically which segment type at the next higher level is the physical parent of a physical child. All segment types in a data base, except the root, are physical children since each is dependent on at least the root. On the SEGM statement that defines each physical child, the PARENT= operand is used to specify the name of the physical parent segment type.
The PARENT= operand of the SEGM statement defines the top to bottom order of segment types. The arrangement of SEGM statements for input to the DBDGEN utility defines the left to right arrangement of segment types. For input to DBDGEN, SEGM statements must be arranged in hierarchic sequence. Hierarchic sequence is defined as top to bottom, then left to right passing through each segment type only once. The seqment types in the hierarchic structure shown in Figure 4-6 are numbered to show the order in which SEG" statements to d~fine that structure must be arranged for DBDGEN input.
Data Base Design Considerations 4.9
I
2
I
J
I
3
4
1
5
J
I
6
7
I
8
I
9
I
I
I
10
11
Figure 4-6. Segment Types Numbered in Hierarchic Sequence
Previously, the terms physical parent and physical child were defined. The remaining term used to describe physical relationships is physical twin. Physical twins are occurrences of the same segment type that are dependent on the same occurrence of the physical parent segment type. In Figure 4-7, the three Name segments Adams, Jones and Smith are physical t~ins since all three are dependent on the skill segment that contains the data artist. Under Adams, the three Experience segments are physical twins and the three Education segments are physical twins since, in each case, the three are of the same segment type under the same occurrence of the physical parent segment type.
The term sibling, used frequently in data base literature, refers to the relationship between two or more segment types at the same level that are dependents of the same parent type segment.
The hierarchies of all four physical data base types are defined as just described, but in auxiliary storage, each of the four physical data base types is organized differently. To understand the advantages of one data base organization over another, a basic understanding of the DL/I calls used to process segments in a data base is r.equired, since the primary trade off between the four types is auxiliary storage space versus the performance of application programs processing a data base through DL/I calls.
4.10 IMS/VS System/Application Design Guide
r
...
1-'
\Q I::
t1
t1)
·-'='
..,J
'1:1 ::r
~
III
o1-"
I» I-' t-3 C 1-' 1:1 III
t:I
rP+I
PI
IJj
PI fII
t1) t:I t1) fII
1-'
\Q
1:1
o o
1:1 fII 1-' PI CD t1
.rP.+.I.
o
1:1 fII
.."
{'
Hierarchy of segment types defmed through DBDGEN
r
Resulting data base in storage
Physical twins
/ ~'/ \'"
"-
/~
""-
/
/
"
/
IuE:x.'P·'R
'. ~'-- ,.
'" " \ " " \ \ '
\
CALLS
The segments in an IMS/VS data base are processed through calls issued by an application program. Calls are issued to get, insert, delete or replace a segment or a path of segments at a time. A call references a parameter list which includes all data required by IMS/VS to complete the call. Included in the list are a function code and an SSA (segment search argument). The function code states the call to be performed, and the SSA states the segment or path of segments to be processed. A call is unqualified when no SSA is included with the call, and a call is qualified when an 5SA is provided for the call. A brief description of the primary calls used in processing a data base and a brief description of SSAs follows. For more detailed information, refer
to the I~§L!~ !££ii£!1iQa f~2[~~!mins ~212~!B£~ tt~n~~!.
The direction of movement in a data base is called forward when the search for a given segment is going away from the first occurrenc~ of the root stored in a data base towards the last segment stor@d in the data base. Backward movement is movement in the opposite direction. Position in a data base is the segment or segments in a data base from which the search for another segment starts.
The GU (get unique) call is used to retrieve a specific segment or path of segments from a data base, and at the same time establishes a position in a data base from which additional segments can be processed in a forward direction.
~21 !2~1
The GN (get next) call is used to retrieve the next desired segment or path of segments from a data base. The get next call normally moves forward in the hierarchy of a data base from current position. It can be modified to start at an earlier position than current position in the data base through a command code, but its normal function is to move forward from a given segment to the next desired segment in a data base.
The GNP (get next within parent) call is used to retrieve dependent segments of a given parent segment from a data base. A get unique or get next call is used to establish parentage for the get next within parent. After a get unique or get next retrieves a given parent segment, successive get next within parent calls retrieve the dependent segments of that parent in hierarchic sequence.
tlQ!g rQ~m 2! ~~i £s!!§
Another form of the three get calls is the hold form. A GHU (get hold unique), GHN (get hold next), or GHNP (get hold next within parent) indicates the intent of the user to issue a subsequent delete or replace call. A get hold call must be issued before issuing a delete or replace call.
In2~~~
The ISRT (insert) call is used to insert a segment or a path of segments into a data base. It is used to initially load segments in all data base types, and to add segments to existing HI5AM, ROAM and HIDAM
4.12 IMS/VS system/Application Design Guide
data bases. segments can not be inserted or added into an HSAM data base except at load time.
L
To control where occurrences of a segment type are inserted into a data base, the user can define a unique sequence field in the segment
type, or specify insert rules that control placement of occurrences of a
segment type that has no sequence field or a non unique sequence field
defined. When a unique sequence field is defined in a root segment
type, the sequence field of each occurrence of the root segment type
must contain a unique value. When defined for a dependent segment type,
the sequence field of each occurrence under a given physical parent must
contain a unique value.
Following are the insert rules the user can specify to control the placement of segments in a data base. They are used to control the placement of occurrences of a segment type with non-unique sequence field values and for placement of all occurrences of a segment type when
no sequence field has been defined.
FIRST - States that a new occurrence of a segment type is inserted before the first existing occurrence of this segment type. If this segment has a non-unique key, a
new occcurrence is inserted before all existing occurrences of the same type that contain the same sequence field key.
LAST -
States that a new occurrence is inserted after the last existing occurrence of this segment type. If this
segment has a non-unique key, a new occurrence is
inserted after all existing occurrences of the same type that contain the same sequence field key.
HERE -
Assumes the user has established position on the specified segment type by a previous Data Language/I call
and the new occurrence is inserted before the segment which satisfied the last call. If current position is not within occurrences of the segment typ~ being inserted, the new occurrence is inserted before all e~isting occurrences of that segment type. If this
segment has a non-unique key and data base position is not within occurrences of the segment type with
equivalent key value, a new occurrence is inserted before all existing occurrences that contain the same sequence field key.
~~!~~
'he DLET (delete) call is used to delete a segment or path of segments from a data base. It should be noted that, due to the hierarchic arrangement of segments in a data base, the deletion of a parent segment implies the deletion of that parent's dependents. When a parent segment is deleted in an IMS/VS data base, all of its dependents are deleted.
R~E!!£~
The REPL (replace) call is used to replace the data in the data portion of a segment or path of segments in a data base.
Data Base Design Considerations ~.'3
An 55A identifies a segment or group of segments that are to be processed by a call. An 55A can contain three parts. 1s a minimum, it contains the name of the segment type to be processed. Optionally, an 5SA can contain command codes and/or qualification statements. Command codes, when used, specify a functional variation of a call. Qualification statements identify through fields which segment or segments of the specified segment type are to be processed by the call. A qualification statement contains a field name, relational operator and comparative value. When occurrences of the segment type are searched, the specified field is compared to the comparative value in accordance to the relational operator specified.
HIERARCHIC SEQUENTIAL AND DIRECT METHODS OF STORING A DATA BASE
Two storage organization methods are used to create the hierarchic arrangement of segments in storage for the four physical data base types. The hierarchic sequential method is used for HS1M and HISA" data bases, and the hierarchic direct method is used for HDA" and HID!K data bases. The hierarchic sequential method consists of using physically adjacent storage locations to store all segment. within a data base record in hierarchic sequence. This creates a hierarchy for the occurrence of the root and all of its dependents within each data base record in which each segment is related to the segment that hierarchically follows it through physical adjacency in storage. The hierarchic direct method consists of placing four byte direct address pointers in the prefix of .each segment stored in the data base to establish the hierarchy of segments in each data base record.
A description of the types of pointers used in HDA" and HIDA" data bases follows.
To relate each segment in an HDAM or HIDA" data base to its related segments, direct address pointers are used. The pointers are four bytes long, and they are placed in the prefix of each segment stored in the data base. A direct address pointer consists of the relative byte address of a segment from the beginning of a data set. Either one of two methods of direct address pointing can be specified for each segment type in an HDAM or HIDA" data base. The two methods are hierarchic pointing, or the combination of physical child/physical twin pointing. Figure 4-8 should be referred to when reading the following descriptions of the types of pointers.
4.14 IMS/VS system/Application Design Guide
rr
, I I,
,
r
I
I
I
I
/
/
/
~::::.~~/
,
-'"1-+----,
I I LL-_ _-'-'
Hierarchical fon.'ard pointers
/
, / ./
/
/
/
I
I
I
I
I
I
I
I
I
Hierarchical forward and backward pointer.
r.------~
I
I
'r~---"=='-" \
, _ NEXT SKILL
r~---~
I I
Physical twin "toward pointers
r.------~
PRECEDING S",LL.--'r~---"=='-"
\ .... - NEXT SKILL
,r----~
Phy.ical twin forward and backward pointer.
I
,-
I
I
I
L
,
I
I
L
l_
rl-.-----,
IPI Ifl( I FI l
Figure 4-8.
ph~lial child f... <1 " ....,,"'
-----
phy-':'lchild r.... _00 lalt PONUtn
Direct Address Pointers
Data Base Design Considerations ~. 15
Two options for hierarchic pointing can be specified for each segment type in an HDAM or HIDAM data base. They are hierarchic forward, or hierarchic forward and backward pointing. When hierarchic forward pointers are specified for all segment types in a data base, each segment in a data base record pOints to the segment that hierarchically follows it through a four byte hierarchic forward pointer. When forward and backward pointers are specified, the backward pointer points from each segment in a data base record to the segment that hierarchically precedes it. The use of hierarchic pointers in an HDA~ or HIDAM data base results in the same arrangement of segments within each data base record as the hierarchic sequential method provides in an HSAM or HISAK data base, but rather than segments being related through physical adjacency, they are related through pointers that require additional auxiliary storage space. For most data bases with high update activity, the additional auxiliary storage space used for poi~ers is more than compensated for through the space reuse facilities gained in HDAM and HIDAM data bases.
In a data base that contains hierarchic pointers, when a call is issued to process a segment in the data base, the hierarchic forward pointers are followed in searching for the segment to be processed. Hierarchic backward pointers are used only when a segment is being deleted. For delete, the backward pointers improve performance by enabling the pointers in the segments that hierarchically precede and follow the segment to be deleted to be updated without first going to the physical parent of the segment being deleted. With forward only pointers, deletion of a dependent segment requires going to the physical parent of the dependent, and then searching forward to update the pointer in the segment that precedes the segment being deleted as shown in Figure 4-9.
Physical child/physical twin pointers benefit applications that process the segment types in a data base randomly. They allow the most direct paths to the dependent segment types in a data base. Two options for physical child and/or physical twin pointers can be specified for each segment type in a data base. The physical child pointers that can be specified are physical child first, or both physical child first and last. The physical twin pointers that can be specified are physical twin forward, or both physical twin forward and backward. When specified for all physical child segment types, physical child pointers are stored in the prefix of each physical parent segment, and they point to each of the physical child segment types of that physical parent segment. A physical child first pOinter points from a physical parent segment to the first occurrence of a physical child segment type in a data base that is a dependent of that physical parent. A physical child last pointer points from a physical parent segment to the last occurrence of a physical child segment type in a data base that is a dependent of that physical parent. If a physical parent segment has multiple physical child segment types, its prefix contains physical child first, or first and last pointers to each of those physical child segment types. Physical twin pointers are used to relate all occurrences of the same physical child segment type that are dependents of the same physical parent segment. Physical twins are multiple occurrences of the same segment type that are dependent on one occurrence of a physical parent segment type. A physical twin forward pointer pOints from a given twin to the twin following it in the data base, and a physical ~win backward pointer points from a given twin to the twin before it in the data base.
4.16 IMS/VS System/Application Design Guide
Delete segment B4:
L
Al
B5 B4
Enter B4 to delete B4:
( II Place pointer to B5 that is in B4 in work area.
(21 Go up to A I.
Bl
(31 Follow pointers forward to B3.
(41 Replace pointer to B4 that is in B3 with pointer to B5 from work area.
(51 DeleteB4.
Al
B5 B4
Enter B4 to delete B4:
(II Place Forward & Backward pointers that are in B4 in work area.
Bl
(21 Follow backward pointer to B3. (31 Replace pointer to B4 that is in B3 with pointer to B5 from work
area.
(41 Follow Forward pointer to B5.
(5 I Replace pointer to B4 that is in B5 with pointer to B3 from work
area.
(61 Delete B4.
Figure 4-9. Use of Backward Pointers for Delete
In searching for a given segment in a physical data base using physical child/physical twin pointers, the physical child first and physical twin forward pointers state the hierarchic path to be followed in search of the segment. The normal path followed in locating a desired segment is from a given physical parent segment to the first occurrence of one of its physical child segment types, and then forward through all occurrences of that segment type to the last occurrence following physical twin forward pointers.
A physical child last pointer enables a search to go directly from a physical parent to the last occurrence of one of its physical child segment types as shown in Pigure ~-10. In so doing, the physical child last pOinter eliminates the forward search of all occurrences of a segment type under one physical parent when only the last occurrence of the physical child is desired. A physical child last pointer is used when inserting a new segment with no sequence field and the insert rule specified is last, or for get or insert, when command code L is
Data Base Design Considerations
specified for the call and the 55A for the call has no qualification statement. When a physical child last pointer is followed to the last occurrence of a dependent segment, any further movement in the data base is forward. A physical child last pointer does not enable searching from the last to the first occurrence of a dependent segment under one physical parent segment.
A1
B9 B8 B7
B1
Figure IJ-10.
Physical child last pointer eliminates the need for a forward search of all occurrences stored before the last occurrence
Use of Physical Child Last Pointer
Physical twin backward pointers in dependent segment typos are used to improve delete performance as described for hierarchic backward pointers. In addition, when physical twin forward and backward pOinters are specified for the root segment type of a HIDAM data base, they enable sequential processing across data base records withou~ intervening references to the HIDA! index. Whgn only physical twin forward pointers are specified for the root segment type of a HIDAK data
base, sequential proc~ssing across data base records requires intervening references to the RIDAK index.
DATA SET GROUPS
To describe what data sets are used for storing the segment types in a data base, and to describe the physical characteristics of those data sets, data set groups are defined through the DBDGEN utility using DATASET statements. For an HSAM data base, one data set group is defined. For HISAM. HDAM and HIDAM data bases, from one to 10 data set groups can be defined. The terms used to describe data set groups are primary and secondary. A primary data set group contains the root segment type. All other data set groups· are called secondary data set groups. A primary data set group must be defined for each data base type. A secondary data set group is normally defined to enable using data sets with different logical record and control interval or block lengths to enhance auxiliary storage space utilization. In a HISAM data base, a secondary data set group offers one additional advantage. It enables direct access to a segment type at the second level of a HISAM data base without first accessing a root.
4. 18 IMS/VS System/Application Design Guide
!!ll~ t2': 12i!i~i.ng, ! ~i! ~!U iIl12 Q!U §.il ~~!la§.
HISAK, HDAK and BIDA" data bases can be divided into a maximum of 10 data set groups according to the rules that follow.
For HISA! data bases, secondary data set groups cannot be defined when VSAM is used as the OS/iS access method for the data base, or when a HISAM data base is indexed by a secondary index. HISA" data bases using ISAM/OSA! as the OS/VS access methods and not indexed by a secondary index can only be divided into multiple data set groups at the second level of its hierarchy. The first segment type defined in a secondary data set group must be a segment type defined at the second level of the hierarchy of a HISAM data base. Included in a secondary data set group, are all segment types dependent on the first segment type defined in that secondary data set group.
For HDA! or HIDA! data bases, secondary data set groups can be started with a seg.ent type defined at any level of the hierarchy and the secondary data set group can contain any combination of the segment types in the data base. However, the following restriction must be met. A physical parent and its physical children must be connected by PC/PT pointers when they are in different data set groups; a PC/PT pointer means that each parent must be a physical child (PC) pOinter to the first occurrence of each child type, and that the children must be connected to each other by physical twin (PT) pointers.
HSAM STORAGE ORGANIZATION In an HSAM data base, all data base records within a data base, as
well as all segments within each data base record are related through physical adjacency in storage as shown-in Figure 4-11. An HS1M data base is stored on a tape, or a direct access storage device as a sequential data set. The data set is loaded in chronological sequence and it uses a fixed length unblocked format (REcr~=F). Since the data set is loaded in chronological sequence, the order in which the user presents each segment to be stored in the data set establishes the hierarchic arrangement of segments in the data base. 1 sequence field is not required in the root segment type of an HS1M data base.
Data Sase Design Considerations 4.19
MTAMSE~
ST.:n.
SKIll
1
I 11ft I lINE
lilT3
IW£
I "/'~~~. I,
". t f / I iI' /
" EX(PEEXRPIRE).'CE1~~~
ED(ElICIIUACTI)(II1~}
BlOCK .1
BlOCK 12
BLOCK 13
ISKIW I fWlll EXPRi I EDlQII fWt2 I EXPflI EXPR3 I EXPM 1'I1""'::1INE3=rT'"11EIiiC2===:==-ll""'IijW=--,r----,
Figure 4-11. One Data Base Record of HSAM Data Base on Tape
When a sequence field is defined in the root segment type, each data base record must be presented for loading in a~cending key sequence. Within each data base record, all segments must be presented for loading in hierarchic sequence.
In the data set, one or more consecutive blocks are used to store a data base record. Each block is filled with segments of a data base record until the remaining space is not sufficient for the next segment to be stored. When not sufficient for the next segment to be stored, the remaining space in the block is padded with zeros and the segment is stored in the next consecutive block. When the last segment of a data base record has been stored in a block, any unused space, if sufficient, is filled with segments from the next data base record.
Initial entry to an H5AM data base is through get unique or get next calls. When the first call is issued, the search for the desired segment starts at the beginning of the data base in storage, and passes sequentially through all segments stored in the data base until the desired segment is reached. After the desired segment is reached, the position it occupies is used as the starting position for any additional calls that process the data base in a forward direction. From current position in an HSAM data base that has a unique sequence field defined in the root segment type, if a get unique is issued to retrieve a segment that is forward in the data base, the search starts from current position and moves forward to the desired segment. If the desired segment requires backward movement in the data base, the proc~ssing option parameters G or GS, which are specified during PSBGEN,determine how backward movement is accomplished. The G processing option specifies the get function only, whereas the GS processing option
4.20 IKS/V5 System/Application Design Guide
specifies get segments in ascending sequence only. If GS has been specified and backward movement in a data base is required to satisfy a get unique, the search for the desired segment will start at the beginning of the data base and move forward. Under the same conditions when the G processing option is specified, from current position the search will move backwards in the data base. This is accomplished by backspacing over the block just read on tape or disk, and the block preyious to the block just read, then reading the previous block forward until the desired segment is found.
An HSAM data base can be randomly processed through get unique calls within one volume. When no sequence field has been defined in the root segment type of an 8SA~ data base, each get unique causes the search for the desired segment to start at the beginning of the data base regardless of current position.
Insert, delete and replace calls cannot be used when processing an existing 8SAM data base. The only calls that are valid for processing an existing 8SAM data base are th~ get calls which enable retrieval of segments from the data base only. To update an 8SAM data base, it must be reloaded.
A simple 8SAM data base is an HSAM data base that contains only one segment type. When a simple 8SAM data base is defined, occurrences of the segment type are loaded into the data base without prefixes.
8ISAM STORAGE ORGANIZATION
In a HISAM data base, segments within each data base record are related through physical adjacency in storage as with an HSAM data base. On like 8SAM however, in a 8ISAM data base each data base record is indexed. In d9fining a H1SAM data base, the user must define a unique sequence field in the root segment type of the data base. When defined, the sequence field values in occurrences of the root are used to index to each data base record in the data base.
In defining a H1SAM data base, the user can specify VSAM or the combination of ISAM/OSAM as the access methods to be used for the data base. When ISAM/OSAK are specified, he can also specify that the H1SAM data base be stored as one to 10 data set groups. If VSAM is specified, a HISAM data base can have only one data set group. When VSAM is specified as the access method, a data set group contains one key sequenced data set and one entry sequenced data set. When ISAM/OSAM are specified as the access methods each data set group contains one ISAM data set and one OSAM data set. In both cases, one data set, key sequenced or ISAM, is used for primary storage of segments and as an index. The other data set, entry sequenced or OSAM, is used for overflow storage of segments. The terms used to describe data set groups are primary and secondary. A primary data set group contains the root segment type. All other data set groups are called secondary data set groups.
tlI2An Q~!~ ~~2~ 2!Q£~~ ~2 Q~~ Q~!~ 2~! §£QYE
When only one data set group is defined for a HISAM data base, the data base is stored as shown in Figure 4-12. Each key sequenced or ISA~ logical record will contain in hierarchic sequence an occurrence of the root, plus all dependents of the root that there is sufficient space for in the logical record. When no space remains for the remaining segments in a data base record, the remaining segments are stored in hierarchic
Data Base Design Considerations 4.21
sequence in one or more logical records of the entry sequenced or OSAM data set. To relate all logical records in both data sets that contain segments in one data base record, a direct address pointer is stored in each logical record to chain them in hierarchic sequence.
MTA lASE IlECOIID STBT1IIIE
KEY SEQUENCED OR
ISAM DATA SET
EXPERIENCE
(EXPR)
PTR
ENTRY SEQUENCED OR
OSAM DATA SET
Figure 4-12. HISAM Data Base Record in Storage (Single Data Set Group)
The structures of logical records for VSAM, and ISAM or OSAM data sets are shown in Figure 4-13. The first 3 bytes of each logical record for ISAM or OSAK, and the first 4 bytes of each logical record for VSAM are used for a direct address pointer. The pointer is used to maintain root segments in ascenaing key sequence and to maintain all segments within a data base record in hierarchic sequence when new segments are inserted into a data base after initial load. Following the pointer are one or more segments of a data base record in hierarchic sequence. At the end of the last segment in the logical record for VSAM, ISAM or OSAK, a one byte segment code of zero is stored to indicate that the last segment in the logical record has been reached. Following the zero segment code for VSAM, remaining space in a logical record is residual. Following the zero segment code for IS1M or OSAM, there are three bytes of zeros, or a 3 byte direct address pointer.
4.22 IKS/VS System/Application Design Guide
t
NOTE 1
SEGMENT
ISAM/OSAM Format
SEGMENT
SEGMENT
SEGMENT CODE a
(1 BYTE)
000 OR
NOTE 2
RESIDUAL
t
NOTE 3
SEGMENT
VSAM Format
SEGMENT
SEGMENT
SEGMENT CODE
a
(1 BYTE)
RESIDUAL
NOTES:
1. The pointer is comprised of the 3 byte relative record number of the OSAM data set logical record that contains a root inserted after initial load.
2. The pointer is comprised of the 3 byte relative record number of the OSAM data set logical record that contains the next dependents in hierarchic sequence.
3. The pointer is comprised of the 4 byte relative byte address of the entry sequenced data set logical record that contains the next dependents in hierarchic sequence.
Figure ~-13.
HISA~ Data Base VSA~, ISAM and OSAM Logical Record Formats
Three bytes of zeros indicate that this logical record contains the last segment in a data base record. If not zeros, a three byte pointer points to the logical record that contains the next segments in the data
base record in hierarchic seq~ance.
In a VSAM data set, one or more logical records are contained in each control interval. In an ISAM or OSAM data set, one or more logical records are contained in each block. A control interval or block is the unit of data transferred between an I/O device and main storage. For VSAM and I5AM data sets, the respective access method uses an index to address a specific control interval or block in a data set. For an entry sequenced data set or an OSAM data set, direct addresses are used to address each control interval or block respectively in a data set.
To load a HI5AK data base, occurrences Of the root segment type must
be arranged in ascending key sequence, and all dependents of each root
must follow that root in hierarchic sequence. In the key sequenced or
I5AM data set, consecutive logical records within a control interval or
block are used to store root segment occurrences in ascending key
sequence. The first logical record contains the root segment with the
lowest key, the next consecutive logical record contains the root
segment with the next higher key, and the last logical record contains
the root segment with the highest key in that control interval or block.
In addition, control intervals or blocks within a data set are loaded in
ascending root segment key sequence, this enables a given data base
L
record to be accessed directly through the key of its root.
Data Base Design Considerations 4.23
Logical record lengths are a major consideration in a HISAM data base. They affect space and access time.
Extremely short or long logical records tend to increase wasted space. Since only complete segments are stored in a logical record, a gap of space is usually unused at the end of each logical record. The number of gaps increases as the LRECL becomes small, and the size of gaps increases as the logical record length becomes large (if data base records are shorter than the logical record length, the remaining space is lost) ·
All segments in a logical record are accessed with one read of an 1/0 device. Accessing additional logical records may require additional reads and seeks depending on physical positioning. The number of seeks and reads to access an entire data base record is in proportion to the number of logical records which comprise that data base record, and therefore increases as the logical record length decreases.
To choose a value for LRECL, several choices should be tried with the following restrictions:
1. Primary data set group:
The minimum length for a logical record in the primary data set must be at least equal to the maximum root segment length, including prefix, plus 5 bytes for VSAM or 7 bytes for IS1M. The minimum length for a logical record in the overflow data set must be at least equal to the longest segment in the data set qroup, including prefix, plus 5 bytes for VSAM or 7 bytes for 05AM. If a HI5AM data base using 15A8/05A8 has only one physical segment type, the IS18/0SAM overhead is 3 bytes, not 7 bytes.
2. Secondary data set group:
The minimum length for a logical record in the primary data set must be at least equal to the longest second level segment type, including prefix, plus the root key length plus 7 bytes. The minimum length for a logical record in the overflow data set must be at least equal to the longest segment in the data set group, including prefix, plus 7 bytes.
3. The logical record length in the overflow data set must be greater than or equal to the logical record length in the primary data set.
4. For I5AM/OSAM the maximum length cannot exceed the physical block size of the I/O device used. Note that 15AM requires keyed blocks while OSAM uses non-keyed blocks. For VSAM, the maximom logical record length is 30720.
5. For 15A8/0SAM, LRECLs must be divisible into physical block size (1/2, 1/3, 1/4, etc.)
6. VSAM LRECL values must be an even length.
For each LRECL value chosen, the average usable space within a record can be calculated as follows:
u = (LRECL - A - B)
2
4.24 IM5/VS System/Application Design Guide
where:
u = usable data characters per logical record.
A = weighted average of segment lengths not including the root segment.
B = 7 for ISAM/OSAM, and 5 for VSAM.
The number of logical records required for a particular type data base record is then calculated by dividing the usable logical record length into the total length of the data base record. By breaking the file into a number of typical record types and calculating the space required for each, the total space requirements can be approximated.
As stated before, the number of reads required to obtain an entire data base record is proportional to the number of logical records it requires. By using "typical" records the number of logical records required for the entire file can be calculated. Due to record blocking and the IMS/VS buffer pool management, the actual number of accesses required will be less than the number of logical records. A file requiring fewer (large logical record length) logical records can be accessed faster than the same file with an LRECL value requiring more logical records (small logical record length).
If the number of logical records (relative access time) and total space are plotted against several trial LRECL values, the graph should take the following general form:
High
---....
I
W U
~
p..
trl
~
~
E-t 0
E-t Low
Ul
'U
~
0
U
- - --.... ........
........
....... - -
pQ::J; t1' 0
~
4-1
0 .
0 Z
LRECL increase~
As shown, as the value of LRECL gets larger, the number of logical
records decreases continually, until the LRECL specification equals the largest data base record length. At this point, the number of logical records equals the number of data base records.
The total space requirements tend to rise if the value of LRECL is either too long or too short. Once several trial LRECL values have been plotted, it should be possible to pick a good one for the file. Consideration should be given to the relative importance of space and access time in the individual situation.
L
The 15AM and OS!K portions of the data base need not have the same LRECLs. To determine the effect of different values for LRECL, each portion of the data base must be figured separately as above.
Data Base Design Considerations ~.25
To maintain root segment in ascending key sequence when new roots are inserted after initial load of a HISAM data base, one method is used when VSAM is specified as the access method for the data base and another method is used when the combination of ISAM and OSA" are specified as the access methods.
The method shown in Figure 4-14 is used when VSAM is specified. The proper control interval in the key sequenced data set for the new root is obtained, and if the control interval has a free logical record, the new root is stored in ascending key sequence in the control interval by pushing all logical records that contain roots with higher keys to the right one position. If no free logical record exists in the control interval, the control interval is split forming two control intervals that are both equal in size to the original.
Insert root with key of 15
BEFORE
! *t ROOTIOEPIOEP lO
R~TI OEPIOEP
FREE LRECL
FREE LRECL
FREE LRECL
10 BYTES OF VSAM CONTROL INFORMATION"
AFTER
* t
ROOTIOEP 10
IOEP
t
R~~TI OEP IOEP
* t
ROOTI 20
OEPI
OEP
FREE LRECL
FREE LRECL
10 BYTES OF VSAM CONTROL INFORMATION"''''
t ~~
I
_ _ ~----- ---------------------------CONTROLINTERVAL----------------------------.~~
* The pointer is comprised of the 4 byte relative byte address of the
entry sequenced data set logical record that contains the next
dependents in hierarchic sequence.
"'* For unblocked data sets, the VSAM control information is only 7 bytes.
Figure q-14. Root Segment Insertion into Key Sequenced Data Set Control Interval
Each new control interval will contain approximately one half of the logical records that were stored in the original control interval which results in free logical records in the last half of each new control interval. After the control interval has been split, the new root is stored in the proper control interval in ascending key sequence by pushing all logical records that contain roots with higher keys to the right one logical record.
To maintain root segments in ascending key sequence when 151M and OS1M are specified as the access methods for a HISAM data base, the method shown in Figure 4-15 is used. Each new root is stored in an OS1M logical record. To maintain root key sequence, a direct address pointer is placed at the beginning of the ISAM logical record that contains the
4.26 IMS/VS System/Application Design Guide
root segment with the next higher key to point to the OSAM logical record that contains the inserted root as shown in Example 1. Example 2 shows a second root segment being inserted in the OSAM data set. The
logical record that contains the root with the next higher key in the IS!M data set points to the OSAK logical record that contains the root with the lowest key. That OSAM logical record in turn points to the
OSA! logical record that contains the next higher key.
E.XN!lI 1 - IISERT IIIIJI' 15
EXAII'lE :5 - INSERT ROOT 13
EMLE 2 - I!!SERT R!!OT 11
Figure 4-15,. Root Segment Insertion When ISAM/OSAM are HISAM Data Base Access Methods
In a HISAI1 data base, the order of chaining a series of root segments can significantly impact updates. If the addition of root segments is a part of the update, insertions should be made in descending sequence,
highest key first when ISAM/OSAK are the as access methods. This
reduces the number of reads necessary to find a point at which to insert a new root. It can be seen in Figure 4-16 that, even with a short chain, the insertion of higher root keys requires a larger number of accesses than the insertion of lower keys. For example, to insert Root 46 it was necessary to read both Roots 34 and 36. The insertion of 32, however, only required the reading of Root 34. Note that the building of long chains of roots occurs only when a large number of updates affects the same area of the data base. The need for descending insertions is less if the inserts are distributed over the data base.
Data Base Design Considerations u.27
When VSAM is used for a HISAM data base, new roots can be inserted in either ascending or descending sequence. Ascending sequence should provide slightly faster performance.
PHYS JCAL RECORD
!4-l0GICAL R[CORD
,
LOGICAL RECORD~-lOGICAL RECORD-.
ROOT
DEP1
27
ROOT
31
DEP1
ROOT
A
DEPI
2
48
./
ROOT B
f 1
( 1ST t+ 36 LOGICAL RECORD 1
-
PHYSICAL BLOCK A ROOT
ROOT A 1
34
2ND
.\+--lOGICAL RECORD 2~
ROOT
3RD 47
32
4TH
I+-- LOGICAL RECORD 1----..
PHYSICAL BLOCK B
Figure 4-16. HISAM Root Segment Insertion Sequence
The method used to maintain the hierarchic sequence of segments within a data base record when new dependent segments are inserted into a HISAM data base is essentially the same for both VSAM, and the combination of ISAM and OSAM access methods.
In a HISA~ data base, one logical record in the primary storage data set and, if necessary, one or more logical records in the overflow storage data set, are used to store each data base record. Within each logical record and across all logical records that contain segments in one data base record, segments are hierarchically related through their physical sequence in storage. Within each logical record, segments are physically stored in hierarchic sequence, and across logical records, a direct address pointer relates each logical record to the next in hierarchic sequence.
4.28 IMS/VS System/Application Design Guide
Figure ~-11 shows how the physical sequence of segments within a data
base record in storage is maintained when inserting dependents into a
data base after initial load. Example 1 shows a dependent segment being
inserted into a logical record that contains sufficient space for the
new depend~nt_ The new dependent is stored in its proper hierarchic
position within the logical record by shifting the segments that will
hierarchically follow it to the right within the logical record.
Example 2 shows segments displaced to a logical record at the end of the
overflow data set when the inserted segment did not leave sufficient
space for them at the end of the original logical record. In Example 3,
the length of the segment being inserted is greater than the space
remaining in the original logical record even after displacing following
segments in that logical record, so all are placed in an overflow
storage logical record. Example q shows an inserted segment that will
not fit into the original logical record, and a displaced segment that
viII not fit into the first overflow logical record with the inserted
segment. Two overflow logical records are used, and they are chained
together in hierarchic sequence.
.
In the previous examples, the overflow logical records referred to are at the end of the entry sequenced data set vhen VSAM is the access
method specified, and they are at the end of the OSAK data set when ISAM/OSAM are specified as the access methods. In both cases, logical records at the end of the respective data sets are used for newly inserted or displaced segments from both the primary storage data set and the overflow storage data set.
Data Base Design Considerations 4.29
Example 1· Space available in logical record for dependent being inserted.
Key sequenced, ISAM or OSAM data set
IBEFORE ROOT SEGM100
DEP10
DEP30
Example 2· Space available in logicel record for dependent being inserted by displacing existing segments in logical record to an OSAM or entry sequenced data set logical record.
Key sequenced, or ISAM data set
I BEFORE 1:~g~100 DEP10
DEP20
DEP30
Entry sequenced or
OSAM data set
*The pointer is at the beginning of VSAM logical records.
Figure 4-17 (Part 1 of 3). Depend~nt Segment Insertion into a HISA" Data Base with One Data Set Group
4.30 IMS/VS System/Application Design Guide
Example 3- Space available in logical record after segments are displaced but dependent being inserted is too large.
Key sequencad. ISAMor OSAM data set
I I I I
BEFORE :~GO~100 DEP10
DEP20
DEP30
Entry sequenced or OSAM data set
DEP27
*The pointer is at the beginning of VSAM logical records
Figure 4-17 (Part 2 of 3). Dependent Segment Insertion into a RISAM Data Base with One Data set Group
Data Base Design Considerations 4.31
Example 4- Space available in logical record after segments are desplaced to overflow, however, segment being inserted is too large and segment displaced will not fit in 1st overflow.
Key sequenced, or ISAM data set
BEFORE
AFTER
INSERT DEP15
DEP20
Entry sequenced or OSAM data set
*The pointer is at the beginning of VSAM logical records
Figure q-17 (Part 3 of 3). Dependent segment Insertion into a H15AM Data Base with One Data Set Group
IS!KLQ~ll: When segments are deleted in a IllS!!! data base that uses ISAM/OSAK, segments are simply marked as being deleted in the delete byte contained in their prefix. They are not physically deleted from a data base. To regain space occupied by deleted segments, a H1SAM data base must be unloaded and reorganized by the user through the HISA~ reorganization unload and reload utilities.
!~!~: Segment deletion in a H15AM data base using V5AM is the same as stated for 15AM/OSAM except as follows. When a root segment is deleted from a HISA!! data base that uses VSAM, the logical record in the key sequenced data set that contains the root is either erased or the delete byte is marked as when using ISAM/OSAK. An erase is only done when processing the data base in batch mode, the root or any dependent of the root is not involved in an active logical ralationship, and there is only one PCB per data base within the PSB.
Q.32 1MS/VS System/Application Design Guide
~~£ond~~I Q~i! ~~ 2t2y~!
Secondary data set groups should be considered for HISA" data bases using ISAM/OSAK as the OS/VS access methods in two cases. They should be considered when storage space is wasted because an efficient logical record length cannot be found for the primary data set group due to segment types in the data base whose lengths vary considerably. And, when access to a dependent segment type in the data base is too time consuming through the primary data set group.
As in a primary data set group, each secondary data set group uses two data sets. An ISAM data set is used as the first storage dat.a set and as the index to the first segment type defined in that data set group. An OSAK data set is used as the overflow storage data set. The benefit gained in defining multiple data set groups is that each data set gro~p defined can have different logical record and block lengths. In addition, the occurrences of the first segment type defined in each secondary data set group are indexed through the key of the root segment they follow in a data base record. When defining a secondary data set group, the minimum LRECL must be expanded by the amount necessary to append sequence field keys of the root segment type onto occurrences of the first segment type defined in the secondary data set group.
When only one data set group is defined for a HISAM data base, the segments in each data base record are stored in hierarchic sequence using one logical record in the first storage data set and, if necessary, one or more logical records in the overflow data set. To index each data base record, the key of the root that starts each data base record is used. When multiple data set groups are defined, one logical record in the first storage data set of each data se~ group and, if necessary, one or more logical records in each overflow data set are used to store the segm~nts of one data base record as shown in Figure 4-18. To index each data base record, the key of the root that starts each data base record is duplicated and is used to index the segments in each secondary data set group that are in the same data base record. In the figure, the secondary data set group contains a duplicate of the key of the root that starts that data base record. The duplicate key is followed by the first occurrence of the description segment type in the data base record, which in turn, is followed by all other segments in that base record in hierarchic sequence.
The use of multiple data set groups to store a HISAK data base has an affect on main storage requirements. Each data set group requires addit.ional space in the DMB pool.
A simple HISAM data base is a HlSAK data base that contains only one segment type. When defining a simple HISAM data base, VSAM must be the access method specified. When defined, occurrences of the segment typ9 are loaded into the data base without prefixes, thus making the data sets that contain the data base compatible for use by VSAM as well as IMS/VS.
Data Base Design Considerations U.33
MTA lASE ECOID STUTUIE
PllfIARY DATA SET GROUP
Duplicate Of SKILL1. Key
SECONDARY DATA SET GRuUP
Figure 4-18. One Data Base Record in a HISAM Data Base (Multiple Data Set Group)
HDAM AND HIDAK STORAGE ORGANIZATIONS
Two of the primary advantages gained with HDAM and HIDA" data bases are space reuse and the ability to access segments within the data base through direct address pointers. Either data base type is stored in one or more VSAK entry sequenced or OSAK data sets depending on the number of data set groups defined. Space within each data set is managed through free space elements and bit maps. When segments are inserted or deleted from either data base type, the space used or freed by those segments is recorded in a bit map to enable its reuse when inserting new segments. To hierarchically relate segments in HDAM and HIDAM data bases, direct address pointers are used. In either data base type, hi~rarchic, physical child/physical twin or any combination of the two types of pOinters can be specified.
The storage organization methods used for HDAM and HIDA" data bases are essentially the same. The primary difference between HDAM and HIDAM data bases is that access to occurences of the root segment type is through a user randomizing module for an HDAM data base, and through an index for a HIDAM data base. To access a given root in an HDAM data base, the randomizing module examines the key of the root, and through hashing or some other arithmetic technique, computes the address of the root and passes it to IMS/VS. To access the same root in a HIDA" data base, an index must be searched by IMS/VS to find the address of the root. When found, the root is accessed. By using a randomizing module to locate roots, the I/O operations required to search the index are eliminated.
4.34 IKS/VS System/Application Design Guide
HDAM
To use an HDAM data base, the user must supply a randomizing module. The randomizing module determines where each root should be stored in the data base, and supplies the address of each root stored to IMS/VS each time that root must be accessed. Addresses supplied by a randomizing module consists of a relative block number and an anchor point number. Anchor points are stored in the anchor point area of each control interval or block, and each is a four byte direct address pointer to a root. To access a given root, the relative block number locates a specific control interval or block in relation to the start of the data set, and the anchor point number locates a specific anchor point in the anchor point area of that control interval or block.
Figure 4-19 shows the organization of an HDAM data base in storage. The entry sequenced or OSAM data set in the primary data set group is divided into tvo areas called the root addressable area and the overflow area. The root addressable area is the first n control intervals or blocks in the data set, and the overflow area is the remaining portion of the data set.
The root addressable area is the area in which the user randomizing module assigns roots. The length of the root addressable area is spacified by the user through the DBDGEN utility. Also specified is the number of anchor points to be placed in the anchor point area of each control interval or block in the root addressable area. A third parameter specified is the maximum number of bytes of a data base record to be stored in the root addressable area. The root addressable area is used as the primary storage area for segments in each data base record, and the overflow area is used for overflow storage. Since data base records vary in length, the bytes parameter is used to control the amount of space used for each data base record in the root addressable area. The bytes parameter limits the number of segments of a data base record that can be consecutively inserted into the root addressable area. When consecutively inserting a root and its dependents, each segment is stored in the root addressable area until the next segment to be stored will cause the total space used to exceed the bytes parameter. The total space used for a segment is the combined lengths of the prefix and data portions of the segment. When exceeded, that segment and all remaining segments in the data base record are stored in the overflow area. It should be noted that the bytes parameter only controls segments consecutively inserted in one data base record. Consecutive inserts are inserts to one data base record that are not intervened by any call to process a segment in a different data base record.
The general criteria to determine the size of the root addressable area is:
Number of bytes of
a data base record
the expected number
to be stored in the
x of data base records
root addressable area
= required size of the root addressable area in blocks
Data Base Design Considerations ~.35
HDAM
DATA BASE RECORD STRUCTURE
SKIll 1
I NAME NAME
NAME IJj2~3,,~,
I
~/I
'~,
I
... ~~"
'':,-',...
EX(PEEXRPIERN) CE1r=2~""4;
ED(EUDCUATCI)ON1:-=21
Figure 4-19. HDAM Data Base Record in Auxiliary Storage In addition, if distributed free space is specified, the space
estimate obtained must be multiplied by one factor for free blocks and another for free space within each block as shown in the following formula:
(Total Space) = (Minimum Space) X _tett_ X
fbff-1
where:
= 2 ~ fbff S 100 or fbff 0 and 0 ~ fspf < 100
See "Distributed Free Space" in this chapter for definitions of !.ett
and I~H~t.
4.36 IMS/VS System/Application Design Guide
At least root segments should be stored in the root addressable area. In addition, active dependent segments should be placed in the root addressable area since this will provide fast access to them because of their physical proximity to the root segment. When all space in the root addressable area is occupied, all segments inserted (roots included) are placed in the overflow area.
The size of the root segment addressable area is fixed with DBD generation. The overflow area however, can be dynamically extended if the overflow storage data set allocation is specified as secondary allocation.
To load each data base record into an HDAM data base, the user randomizing module generates a relative block and anchor point number for the root that starts that data base record and passes ~hem to IMS/VS. IKS/VS in turn, attempts to store the root in the control interval or block specified. If space is available in that control interval or block, the root is stored and a four byte direct address pOinter to the root is stored in the specified anchor point position in the anchor point area of that control interval or block. When space is not available in the control interval or block specified, IMS/VS ases the HD space search algorithm to find the available space nearest to the control interval or block specified by the randomizing module. When found, the root is stored and a pointer to that root is stored in the original anchor point position and relative block number specified by the randomizing module.
When a randomizing module produces the same relative block and anchor point number for multiple roots, the specified anchor point points to one, and the rest are chained through physical twin pointers. When a unique sequence field has been defined in the root segment type, the anchor point points to the root with the lowest key and the rest are chained in ascending key sequence through physical twin pointers. When a unique sequence field is not defined, the insert rules of FIRST, LAST or HERE determine the sequence in which the roots are chained. All roots chained from a given anchor point are called synonyms since all have the same relative block and anchor point number. To reduce the length of root segment synonym chains if they affect performance, the user should increase the number of root anchor points specified for each control interval or block in the root addressable area. The user randomizing routine can then distribute the roots across more anchor points, thereby reducing the number of synonyms per anchor point.
After a root is loaded into the root addressable area, the next segments in a data base record are stored following the root until the bytes parameter causes the remaining segments in a data base record, if any, to be stored in the overflow area.
HIDAM
A HIDAM data base in auxiliary storage is actually comprised of two data bases that are normally referred to collectively as a HIDAM data base. When defining each through the DBDGEN utility, one is defined as the primary HIDAM index data base and the other is defined as the HIDAM data base. In the following discussion the terms 'HIDAM data base' will refer to the HIDA~ data base defined through DBDGEN.
The primary HIDAM index data base is used to index to the data base records stored in a HID AM data base. When a HIDAM data base is d~fined throu9h DBDGEN, a unique sequence field must be defined in the root segment type. The resulting key in the sequence field of each
Data Base Design Considerations 4.37
occurrence of the root is used by IM5/VS to create an ind~x segment for each root that is stored in the index data base. To identify which root an index segment indexes, the key in the sequence field of a root is stored in the data portion of an index segment. To index to that root, the address of the root in the HIDAM data base is stored as a direct address pOinter in the prefix of its index segment.
~Q~~1ng ~ fil~!~ ~~!~ ~~§~
When the user loads a HIDAM data base, the primary HIDA" index data base is loaded automatically by IMS/VS. In loading a HIDAM data base, all roots must be inserted in ascending key sequence, and all dependents of a root must be inserted following that root in hierarchic sequence. As each root is sto~ed in the HIDAM data base, IMS/VS generates the index segment for that root and stores it in the index data base.
The index data base consists of an ISAM and an OSAM data set when 15AM/OSAM are specified as the access methods for the data base, or it consists of a key sequenced data set when VSAM is specified as the access method as shown in Figure 4-20. When I5AM/OSAM are specified for the index data base, the ISAM data set is used for storage of index segments created during initial load of a HIDAM data base, and it is called the primary data set. The OSAM data set is used for storage of index segments created when new roots are added to a HID AM data base after initial load, and it is called the overflow data set. When VSAM is specified for the index data base, the key sequenced data set is used for both index segments created during initial load and after initial load.
When 1SAM/OSAM are used for an index data base, all index segments for roots initially loaded are stored in ascending key sequence in the ISAM data set. ihen roots are added after initial load, the index segment for that root is stored in the first available logical record in the 05AM data set. When this occurs, a pointer is stored at the beginning of the logical record in the ISAM data set that contains the next higher key. The pointer points to the logical record in the OSAM data set that contains the added index segment. When multiple index segments have to be chained from the same logical record in the ISAM data set, the logical record in the ISAM data set points to the OSAM logical record that contains the index segment with the lowest key. Any additional OSAM logical records to be chained are chained from the first 05AM logical record in ascending key sequence. Since index segments added after initial load are stored in the OSAM data set, their access requires additional I/O operations. To improve performance degraded by root inserts, the index data base should be reorganized through the HISAM Reorganization Unload and Reload utilities.
A HIDAM data base is stored in from one to ten entry sequenced or OSAM data sets depending on the number of data set groups defined and the access method specified. Each data set group uses one entry seguenced data set when VSAM is specified as the access method, and one OSAM data set when OSAM is the access method specified. When initially loading segments into a HIDAM data base or when inserting segments into a HIDAM data base after initial load, the HD space search algorithm is used to find the most suitable space available.
4.38 IMS/VS System/Application Design Guide
r
r'
r
.".I.f.
VSAM
\Q C
-'N[)'i:X---------------- ---- -----------,
11
CD
-'==
Key Sequenced Data Set
I
IV
·0
ISAM/OSAM
1---------------------- ---- -- --------,
,: INDEX
I I ~
~
ISAM DataSet
HH
::J::J .... !II
...... (1)
...·11 1» ....
0 t-'HI 0 1»1» P
ta 0
.0...
til (1)
0
\Q
.I.»..
IS (D
I»
.:.:J..
III I»
....
!II
(1)
.:.:J..
0
0
(1)
I»
.!.I.I.
\Q
H =
::J
0
It"
0
::&
0
....::J
!II
\::I I» r1'
P.
I»
(1)
11
III
.I...»....
I» !II
(1)
0
::J
I»
!II
.H...I
(1)
11
·-'==
\"D""
Entry Sequenced Data Set
-----
[!~~ ~!! ~!~~ !2£t ~~!~~! II~~ ~2int~ 22ti£n2
If forward only hierarchic or physical twin pointers are specified for the root segment type of a HIDAK data base, sequential access to each root segment is accomplished by using the index. When forward and backward hierarchic or physical twin pointers are specified for the root segment type, for sequential processing the index is only used to access the first root segment. From the first root, additional roots can be processed sequentially without further reference to the index.
I££!!I of ~!!! ~~!~ y~~~ t£[ ~~!! !nd ~!R!~
In defining an HDAft or HID!ft data base, the user can specify VSAM or OSAK as the access method to be used for the data base, and he can also specify that the data base be stored as one to ten data set groups. When VSAM is specified, each data set group consists of one entry sequenced data set. When OSAM is specified, each data set group consists of one OSAK data set. In either case, the resulting data set will have an unblocked format. When not specified by the user, DBDGEN generates logical record lengths for the data sets that are equivalent to a quarter-track, third-track, half-track, or full-track block.
Direct address pointers within the prefix of a segment and the anchor point(s) of a block are constructed by the following formula:
Pointer Value = (Block Size) X (Block Number) + (Offset within Block).
This formula is also used for pointers in the prefix of segments of an INDEX data base when relating to segments in a HIDAS data base.
In order that all segments will be on half word alignment, within the data set a slack byte is added to the end of any segment in HDAK data bases or HIDAK whose total length is an odd number.
The control fields used in managing entry sequenced or OSAK data sets for HDAK and HIDAS data bases are (See Figure 4-21):
· Free space anchor point · Free space element · Anchor point area · Bit map control interval or blocks
4.40 I85/VS System/Application Design Guide
r
r'
(
~ ,
,>..c.j.
\Q d 11 /I)
~
-I
IV
·
Entry sequencBC! or OSAM data set
t::In 1»0
ANCHOR POINT
r+::I
I»r+
FSEAP
AREA
BITMAP
Relative Blo·. k or Control Interval # I
11
til 0
(1)1-'
rm+ >,c...j.
Q/I)
ml-'
/l)P
p-m
HlQ
om
11(1)
Po
t::I
::a
I»
t::Ir+
r+
IJ"O
I»
:3
011111···· ·1011
->-
111001· .......... ·10111
U 00(
'0"::
00(
FSEAP
ANCHOR PTS
190 CP
Relative Blo :k or Control Interval IF 2
FSE <\L
~'.'"".I :'"!i
1~-:~~-1--~-k~~JI~~~~~r:~::::::::::::~~ ~~'" · 1--"
NAMEI I 00
_I_
Q
-=======dI.l ''(c''r- 315 _____
...00(
.
oo
0::
~,
:3
01
01»
I»
11 ::I
m
I»
FSEAP
480
FSE
CP I AL
/I)
::a\Q
t::I
/I)
.e.n..
H/I)
t::I IJ"ViI
RELATIVE BLOCK OR
3::1
CONTROL
r+
INTERVAL #N
2
2
\Q
t::Il1
::I
I»~
r+
FSEAP
(")
I» til
0
/I)
RELATIVE
:,e.:n.I..
p-
/I)
OIIQ
BLOCK OR
eI»n
g /I)
m/I) (::)J
CONTROL INTERVAL#M
2
2
232 CP
. _. EDue3 I 00 ,
I..
NAME3
00 I 25 I
UNUSED
00(
~..
~
~
'0"::
00(
9
"0:":
~'"
UNUSED
-,
.., 273--------====::::;~
1,I,..»1.....
pCO
0
FSE
0
11
::I
rn
0
til
:.
3
· ~
~
· VSAM only. 7 bytes of VSAM control information
l~~ ~E!~ In£~~ f2!~i
Each control interval or block in an entry sequenced or OSAM data set respectively starts with a four byte free space anchor point (FSEAP) field. The field contains, in the first two bytes, the offset in bytes to the first free space element in that control interval or block. The second two bytes contain a flag that identifies bit map blocks. For blocks other than bit map blocks, the second two bytes of the field contain zeros.
A free space element identifies each area of free space in a control interval or block that is eight bytes or more in length. To identify each area of free space, a free space element occupies the first 8 bytes of each area of free space. The fields in each free space element are:
· Free space chain pOinter field (CP) This field contains, in
bytes, the offset to the next free space element in the control
interval or block from the beginning of the control interval or
block. The length of this field is 2 bytes.
· Available length field (AL) -- This field contains in bytes the length of the vacant space that this free space element identifies. The value in the available length field includes the leng~h of the free space element itself. The length of this field is 2 bytes.
· Task ID field (ID) -- This field contains the task ID of the program that freed the space that is identified by this free space element. The task ID enables a given program to free and reuse the same space during a given scheduling without contending for that space with other programs.
The task ID consists of a one-byte calendar date followed by a three byte cumulative sync point count for the day_
For an HDAM data base, the user specifies the number of four byte direct address root anchor points desired in each control interval or block in the root addressable area. For each anchor pOint specified, four bytes of space is reserved in the anchor point area of each control interval or block in the root addressable area. The space for anchor points is not reserved in those control intervals outside the root addressable area, including the bit map control intervals. This space is initially made free space and is available just as other free space in a control interval.
For a HIDAM data base, when forward-only hierarchical or physical twin pointers are specified for the root segment type, one 4-byte anchor point is present in each control interval or block. The anchor point addresses the last root inserted into the control interval and the roots are chained in the reverse order from the sequence in which they were inserted into the control interval. With a forward-only (not forward and backward) pointer at the root level, it is impossible for IMS/VS to keep the roots chained in key sequence when new roots are inserted in~o an existing data base. Because the forward pointer chains roots in reverse time sequence and not in key sequence, it is not used by IMS/VS to obtain the next sequential root. The index is ased to do sequential processing. For a HIDAM data base we recommend that you use no-twin, twin forward and backward, or hierarchical forward and backward pointers at the root level. When one of these options is used, no anchor point is placed in the control interval. If your processing is primarily
4.42 IMS/VS System/Application Design Guide
random, no-twin is best because all accesses to the root segments are via the index. If your processing is primarily sequential~ use physical or hierarchical forward and backward. With these pointers tHe roots are chained in key sequence.
~ii ~~~ ~!2~~
A bit map control interval or block starts with a two byte free space chain pointer field. The field always contains zeros in a bit map control interval or block in the root addressable area of an RDAM data base since no space is available in those bit map control intervals or blocks for segments. The next two bytes contain a bit map flag. A lov order one in the second two bytes of a control interval or block indicates that the control interval or block contains a bit map. The same two bytes in all other control intervals or blocks in a data set will contain z~ros. The next 0 to n bytes of a bit map control interval or block are for root anchor points. Following the anchor point area when present, the remainder of the control interval or block is a bit map.
The first control interval or block of the first extent of the data set specified for each data set group in an RDAM or HIDAM data base is used for a bit map. If, however, the organization is VSAM, ~he second control interval is used for the bit map and the first control interval is reserved. In the bit map, each bit is used to describe whether or not space is available in a particular control interval or block. The first bit corresponds to the control interval or block the bit map itself is in, and each consecutive bit corresponds to the next consecutive control interval or block in the data set. When the bit value is one, it indicates that the associated control interval or block has sufficient space remaining to store an occurrence of the longest segment type defined in this data set group. When the bit value is zero, sufficient space is not available for an occurrence of the longest segment type defined in this data set group. The first bit map in a data set contains n bits that describe space availability in the next n consecutive control intervals or blocks in the data set. After the first bit map, another bit map is stored at every nth control interval or block to describe space availability in the remaining control intervals or blocks in the data set.
!n2~£i2 aug ~gl~1g2 in liQ!tt ~ng tll~Att ~a1~ ~~2~2
The techniques used to insert or delete segments are the same for both HDAM and HIDAM data bases. The techniques involve use of bit maps, space available chains and available length fields. The three are used to find space when inserting a segment, or to record free space when a segment is deleted.
The following HD space search algorithm is used to find the most suitable space for a segment being inserted into an RDAM or HIDAM data base.
Data Base Design Considerations 4.43
HD Space Search Algorithm
SEARCH CRITERIA: When searching for space, if space the exact size of the request is found, it is used; otherwise, three free areas are
selected in the following order of preference:
1. Smallest ~ REQUEST + min. segment in data set 2. Smallest ~ REQUEST *2 3. Smallest ~ REQUEST
From this set, the first area that does not alter bit map setting is selected, if there is one. Otherwise, the first area found is selected.
1. SAME BLOCK
2. ANY BLOCK CURRENTLY IN BUFFER POOL ON SAME TRACK
3. ANY BLOCK CURRENTLY IN BUFFER POOL ON SAME CYLINDER
4. ANY BLOCK ON SAME TRACK WHERE SPACE FOR MAXIMUM SEGMENT LENGTH
EXISTS (Based on bit map)
.
5. ANY BLOCK ON SAME CYLINDER WHERE SPACE FOR MAXIMUM SEGMENT LENGTH
EXISTS (Based on bit map)
6. ANY BLOCK CURRENTLY IN BUFFER POOL WITHIN ~ N CYLINDERS
7. ANY BLOCK ON ~ N CYLINDERS WHERE SPACE FOR MAXIMUM SEGMENT LENGTH
EXISTS (Based on bit map)
8. ANY BLOCK IN BUFFER POOL AT END OF DATA SET
9. ANY BLOCK AT END OF DATA SET (Based on bit map)
10. ANY BLOCK IN THE DATASET WHERE SPACE POR MAXIMUM SEGMENT LENGTH
EXISTS (Based on bit map)
In the algorithm, the same block as that which contains the immediately preceding segment in the hierarchy of a data base record is chosen for the new segment insertion under search criteria one. If not satisfied, search criteria two through ten are used in sequence in
attempting to obtain space for insertion.
~~!~.!:~§
Deletion of a segment from an HDAM or HIDAM data base involves:
· Updating the pointers in any other segments that point to the
deleted segment.
· Accumulating the space occupied by the deleted segment on the space available chain for the block and possible adjustment to the bit map. If a deleted segment is adjacent to an already available area of space, the two areas are combined into one.
Figure 4-22 illustrates the deletion of segment EXPRq and the incorporation of the space it occupied on the space available chain.
4.44 IMS/VS System/Application Design Guide
r'
r'
('
"l!I
~.
IQ C
t1
/I)
+:
I
IV
·IV
Entry Sequenced or OSAM Data Set
.I.J.:.:.
CD
11
PJ
11
0
RELATIVE 1
IFSEAP
ANCHOR 8 POINT
.t.r..-.
0
BLOCK #2 OR CONTROL
INTERVAL #2
210 00 2
1032
SKILLI I NAMEI I EXPRIB I 00 I 295 I
JooII
.1_ 4
1----32~150~2O
UNUSEO 295---
_ I
.t..I..
11
CD
0
tt-
RELATIVE
FSEAP A~I~~R
~ C:P AL ' ID
4B4 · CP I AL
tI PJ
...tI
CD
~~O~NTROL 1
INTERVAL#N
tt-
CD
2
4
PJ
.t.t.. .
00 20 ----.l*,,1-
b'
0
PJ !II CD
d
(0
l:I
160
FSEAP
ANCHOR
I
0 HI tI
RELATIVE
B~NLORTC~K~!~~LMI
POINT
160 00
00
· CP
EDUC2 1 EDUC3 1 00 1 345 1
I
!..I.I..
CD
~
IQ
CD
2
4
1_ '--76~76 ...
l:I
l:I
P-
n
CD
O
l:I
l:I
c+
.!.I.I..
UI
P-
CD
(1)
IQ
11
51
· VSAM only; 7 bytes of VSAM control information
PJ
CD
.t.t..-.
l:I tt
0
l:!
UI
UNUSED 345
- - - --------r
.-'='
+: U1
Ri§t[i£gt~~ l[~~ ~£~£~
A consideration affecting HDAM or HIDAM data base performance is a result of certain types of dependent segment insert activity. After an HDAM or HIDAM data base is initially loaded or reorganized, high segment insert activity may degrade performance. This degradation occurs when added segments are not placed physically adjacent to their related segments. For HDAM or HIDAM, segments inserted after a data base is initially loaded or reorganized are stored at the end of their data set group, or in the position of previously loaded segments that have been deleted from that data set group as follows:
Space for an inserted segment in an HDAM or HIDAM data base is acquired by scanning a user specified number of disk cylinders to locate the free space nearest to its related segments. If no space is found, the segment is inserted at the end of that data set group. This method attempts to place added segments in the position physically closest to their related segments to keep direct access storage device access time to a minimum. However, since this method does not always place added segments in space physically adjacent to their related segments, data bases must be reorganized periodically to eliminate the degradation to
~rl~e~.
The distributed free space option can be selected during DBDGEN for HDAM and HIDAM data bases. It is intended to minimize degradation to performance caused by insert activity, and in so doing, decrease the frequency in which HDAM or HIDAM data bases must be reorganized. It accomplishes this by allowing the user to specify, on the DATASET statement for each data set group, periodic blocks of free space and/or a percentage of free space in each block to be left vacant during initial load or reorganization of the data base. These free spaces are then used after data base initial load or reorganization to store added segments physically close to their related segments.
The FRSPC= operand on the DATASET statement is used to specify free space in each data set group of an HDAM or HIDAM or data base. In the operand, any combination of two parameters can be specified. One is the fbff (free block frequency factor). The fbff specifies that every nth block in a data set group will be left as free space during data base load or reorganization {where fbff=n). The range of fbff includes all integer values from 0 to 100 excluding fbff=l. The second parameter that can be specified is the fspf (free space percentage factor). The fspi specifies the minimum percentage of each block in a data set group that is to be left as free space during load or reorganization. The range of fspf is from O"to 99.
For HISAM or HIDAM index data bases using ISAM/OSAM, IMS/VS generates an additional root segment and stores it as the last root segment in the data base. This additional root segment has the sequence field filled with X'PP's. It is generated and placed in the data base by IMS/VS because add~d root segments are chained from the root with the next higher sequence field key.
HIDAM data bases using VSAM also contain an X'FF' key segment. It is used for twin backward pointing at the root level.
For variable length or compressed segments, an X'FF' key segment is allocated the maximum length specified for the segment type, and the size field of the segment has the high order bit turned on (X 'SXXX'). This segment is never compressed.
4.46 IMS/VS system/Application Design Guide
L
Following is a summary of the characteristics of the four physical data base types.
HSAft
· All segments and data base records are related through physical
adjacency.
· Stored as a sequential data set.
· Can only retrieve segments from existing data base. To update
req~ires reload.
· Can be stored on tape.
HISAM
· Segments within data base records are related through physical
adjacency.
· Indexed access to data base records.
· User can specify multiple data set groups. (ISAM/OSAM only)
· Space occupied by deleted segments is not reusable, except when root segments are deleted in a key sequenced data set.
· VSAH or the combination of ISAM/OSAM can be specified as the
operating system access method.
· Logical relationships using symbolic pointers.
· Secondary Indexing using symbolic pointers for single data set
groups.
· When VSAH is specified as the operating system access method for a HISAM data base, the additional options available are:
Variable Length Segments
User Segment compaction/Expansion Routines
HDAK OE HIDAM
· Segments within data base records are related through hierarchic and/or physical child/physical twin direct address pointers.
· Access to the root in each data base record is through a user
randomizing module for HDAM and through an index for HIDAH.
· User can specify multiple data set groups.
· Space occupied by deleted segments is reusable.
· VSAM or OSAM (combination of ISAM/OSAM for HIDAM index) can be
specified as the operating system access method.
· Logical relationships using direct address or symbolic pointers.
· Distributed Free Space.
Data Base Design Considerations Q.u1
· Secondary Indexing using direct address or symbolic pointers
· When VSAK is specified as the operating system access method for the data base, the additional options available are:
Variable Length Segments
User Segment compaction/Expansion Routines
For information on defining the Main Storage Data Base (KSDB) and the Data Entry Data Base (DEDB) see the "Past Path Data Bases" section in the chapter "Design Considerations for the Past Path Feature."
In multi-application data management systems, data duplication is often a problem. Duplicates in storage waste storage space and cause duplicate maintenance. Duplicates are caused when a given type of data is common to several applications, but each application requires the common data stored in relation to different types of data, or in combination with different types of data. To eliminate storage duplication, logical relationships are used. Logical relationships enable the user to store a given segment type once and to define that segment type as dependent on one segment type in a physical data base and a different segment type in a logical data base. Logical relationships are also used to create logical data bases that contain a combination of segment types from different physical data bases without duplicating them. This means the segment types in two different physical data bases, for two different applications, can be combined into a logical data base for a third application without creating a third physical data base.
All logical relationships establish a relationship between two segment types in one or more physical data bases. They are defined in the physical data bases of the segment types they relate to, and they are used when the related segment types are processed through a logical data base. When defined between segment types in the same physical data base, a logical relationship enables a different hierarchy of segment types to be defined for the segment types in that physical data base. When defined between segment types in different physical data bases, it enables a hierarchy of segment types to be defined that combines the segment types in both data bases into a single data bas9. In each case, the new hierarchy of segment types is defined through th9 OBDGEN utility to create a logical data base. The hierarchy of segment types for a logical data base is comprised of a subset of the physical and logical relationships defined between the segment types in their physical data bases.
Logical relationships enable occurrences of two segment types to be stored independently of each other, yet enable an application program to process them through a logical data base as if stored in relation to each other. Through the logical data base, the relationship between the two segment types appears to be that of a physical parent segment type and One of its physical child segment types in a physical data base. An application processes occurrences of the related segment types through their logical data base in the same manner as occurrences of a physical parent segment type and a physical child segment type are processed in a physical data base.
4.48 IMS/VS System/Application Design Guide
A logical relationship is defined in the physical data base or data bases of the segment types being related. Through a logical relationship~ segment types in the same or different physical data bases are related in a manner that is in most cases transparent to application programs using the physical data bases. To enable use of a logical relationship defined between two segment types in one or more physical data bases, a logical data base must be defined.
The terms used to describe the segment types involved in logical relationships are physical parent, Ingical parent, and logical child. The terms physical parent and logical parent are used to describe the two segment types being related through a logical relationship. The term logical child is used to describe one or both of the additional segment types that are required to relate two segment types through a logical relationship.
"ETHOD5 OF RELATING SEGMENT TYPES THROUGH A LOGICAL CHILD Three types of logical relationships can be defined in 1"5/'5 data
bases. The three types are unidirectional, physically paired bidirectional, and virtually paired bidirectional logical relationships. For each of the three types of logical relationships, a logical child segment type relates two segment types by one of two methods. The first method described in the following text is used for unidirectional and physically paired bidirectional logical relationships. The second method described is used for virtually paired bidirectional logical relationships. In both methods, a logical child is physically related to one of the segment types being related through a logical relationship. In addition for the first method, the logical child points to the othe~ segment type. In the second method the logical child points to the other segment type, and is pointed to by the other segment type. Figure Q-23 shows the first method of relating segment types through a logical child segment type.
Data Base Design Conaiderations Q.Q9
NAME
NAMES KILL ARTIST STENO
SKILL ARTIST
NAME JONES
NAMESKILL STENO
SKILL STENO
NAME
SKILL TYPIST
NAMESKILL ARTIST STENO
Figure ij-23. Relating Occurrences of SKILL to Occurrences of NAME
Figure 4-23 shows occurrences of the SKILL segment type being related to occurrences of the NAKE segment type through occurrences of an additional segment type that is required to relate NAKE and SKILL segments. A logical child is an additional segment type that is required to relate two segment types through a logical relationship. A logical child segment type relates tvo segment types by being physically related to one segment type and by pointing to the other segment type. The segment type that the logical child segment type is physically related to is called the physical parent of the logical child. The segment type that the logical child segment type points to is called the logical parent of the logical child. The pointer in a logical child that points to a logical parent is called a logical parent pointer. In
4.50 IHS/VS System/Application Design Guide
Figure 4-23, NAftE is the physical parent, SKILL is the logical parent, and NAMESKILL is the logical child segment type. To establish the physical relationship between the NAftE and NAKESKILL segment types shown in Figure 4-23, NAMESKILL is defined as a physical child segment type of NAME in the physical data base of the NAftE segment type. Since NAME and NAMESKILL are a physical parent and a physical child segment type in the same physical data base, occurrences of each are related when loaded into their physical data base. To relate an occurrence of SKILL to an occurrence of NAME in storage, the user loads an occurrence of NAMESKILL, the logical child segment type, as a physical child of a given NAME segment. This process is rep~ated for each occurrence of the logical parent that is to be related to that NAME segment. When loading a logical child segment into its physical data nase, the user identifies which logical parent segment the logical child points to, by placing the concatenated key of the logical parent in the data portion of the logical child segment. Since the concatenated key of a logical parent segment is the symbolic pointer to that segment in its physical data base, when the user loads logical child segments as physical children of a given physical parent segment, the respective logical parent segment pointed to by each logical child is related to the physical parent segment. When processing the related segment types through a logical data base, it is the physical relationship between occurrences of the physical parent and logical child segmen+. types in their common physical data base, plus the logical parent pointer contained in each logical child segment, ·that enables access to related occurrences of the logical parent segment type from each occurrence of the physical parent segment type.
In the second method of relating two segment types through a logical child segment type, all of the conditions described for the first method remain the same. The logical child segment type is physically related to its physical parent segment type and points to its logical parent segment type. One occurrence of the logical child segment type is loaded as a physical child of a given physical paLent segment for each occurrence of the logical parent segment type that is to be related to that physical parent. To identify which logical parent segment is being related to a physical parent segment through a logical child segment, the user places the concatenated key of the logical parent in the data portion of each logical child segment loaded. Through the relationship of physical parent and logical child segments in their physical data base, and the logical parent pointer in each logical child segment, related occurrences of the logical parent segment type can be accessed from physical parent segments. In addition, logical child pointers are used in the logical parent segment type, and logical twin and physical parent pointers are used in the logical child segment type, as shown in Figure 4-24. The additional pointers are used to enable accessing specific occurrences of the physical parent segment type that are related to each occurrence of the logical parent. Logical twins are multiple occurrences of the same logic~l child segment type that point to the same occurrence of the logical parent segment type. When specified in the logical child segment type, logical twin pOinters pOint from each logical twin to tha next to chain together all logical twins that point to a given logical parent. The physical parent pointer in each occurrence of the logical child segment type is generated automatically by IMS/VS to endble access to the physical parent segment of each logical cbild from that logical child. A logical child pointer is specified for the logical parent segment type to enable accessing a logical child segment from a logical parent segment. A logical child pointer points from a given logical parent segment to one of the logical twins, which also points back to that logical parent segment. Since all logical twins that point to the sa.e logical parent are chained t~rough logical twin pointers, and ~ach logical child contains a physical p~rent
Data Base Design Considerations 4.51
pointer, the specific physical parent segaents that are related to a
given logical parent segment can be accessed from that logical parent
segment.
'
NAME ADAMS
SKILL ARTIST
NM1ESKILL ARTIST STENO TYPIST
SKILL STENO
STENO
NAME
NAMESKILL ARTIST STENO
SKILL TYPIST
Key: PP-Physical parent pointer LP-Logical parent pointer LCF-Logical child first pointer LTF-Logical twin forward pointer
Relating Occurrences of NAKE to OccurrenceR of SKIL~ 4.52 IKS/VS System/Application Design Guide
L2gi£~! R~!~l~2n§~~E ~~!~§
The physical relationship bp.tween physical parent and logical child segments in their physical data base, and the logical parent pointer in each logical child segment creates a physical parent to logical parent path between each physical parent segment and the logical parent segments related to each physical parent segment. To define use of the path in a logical data base, the logical child and logical parent segment types are defined as one concatenated segment type that is a physical child of the physical parent segment type as shown in Figure 4-25.
PHYSICAL DATA BASE(S)
LOGICAL DATA BASE
PHYSICAL PARENT
LOGICAL PARENT
PHYSICAL PARENT
LOGICAL CHILD
LOGICAL I LOGICAL
CHILD
I
I PARENT
,
Concatenated Segment Type
Fi~are 4-25. Defining a Physical Parent to Logical Parent Path in a Logical Data Base
In addition, when logical child pointers are used in the logical parent segment type, and logical twin and physical parent poin~ers are used in the logical child segment type, a logical parent to physical parent path is created between each logical parent segment and the physical parent segments related to each logical parent segment. To define use of the path in a logical data base, the logical child and physical parent segment types are defined as one concatenated segment type that is a physical child of the logical parent segment type as shown in Figure 4-26.
Data Base Design Considerations 4.53
PHYSICAL DATA BASE(S)
PHYSICAL PARENT
LOGICAL PARENT
LOGICAL DATA BASE
LOGICAL
PARENT
LOGICAL CHILD
LOGICAL
.
CHILD
I PHYSICAL
I I
PARENT
Concatenated Segment Type
Figure 4-26. Defining a Logical Parent to Physical Parent Path in a Logical Data Base
When use of a physical parent to logical parent path between segment types is defined in a logical data base, the physical parent segment type involved in the logical relationship is the physical par9nt of the concatenated segment type. When an application program retrieves an occurrence of the concatenated segment type from a physical parent segment, an occurrence of the logical child and the respective logical parent pointed to by the logical child are concatenated and pr9sented to the dpplication program as one segment. When use of a logical parent to physical parent path is defined in a logical data base, the logical parent segment type is the physical parent of the concatenated segment type. When an application program retrieves an occurrence of the concatenated segment type from a logical parent segment, an occurrence of the logical child and the physical parent segment pointed to by the logical child are concatenated and presented to the application program as one segment.
In each case the physical parent or logical parent segment type included in the concatenated segment type is called the destination parent. For a physical parent to logical parent path, the logical parent is the destination parent in the concatenated segment type. For a logical parent to physical parent path, the physical parent is the destination parent in the concatenated segment.
By definition, a logical child segment contains the concatenated key of the destination parent followed by intersection data, if any. A
logical child segment relates a specific physical parent segment to a specific logical parent segment. Since a logical child is the pOint of intersection for a physical parent and logicalpar9nt segment, any data contained in a logical child segment in addition to the concatenated key of a destination parent is called intersection data. When defining a logical child segment type in its physical data base, the length specified for the segment type must be sufficient to contain the concatenated key of a logical parent. Any length greater than that required for the concatenated key can be used for intersection data.
4.54 IMS/VS System/Application Design Guide
To identify which logical parent segment will be pointed to by a logical child segment, the concatenated key of the logical parent segment must be present, with each logical child segment, in the user's I/O area when the logical child segment is initially presented for loading into a data base. However, if the logical parent segment is in a HDAM or HIDA~ data base, its concatenated key may not be written to storage when the ~ogical child segment is loaded. If the logical parent is in a HISAM data base, a logical child in storage must contain the concatenated key of its logical parent.
When a concatenated segment is retrieved through a logical data base, it contains the concatenated key of the destination parent, followed by intersection data in the logical child segment, which in turn is followed by the data in the destination parent segment. Figure 4-27 shovs the format of a retrieved concatenated segment in the user I/O area. The concatenated key of the destination p~rent is returned with each concatenated segment to identify the destination parent retrieved. I~S/VS obtains the concatenated key of the destination parent from the logical child in the concatenated segment, or by constructing the concatenated key. If the destination parent is the logical parent of the logical child and the concatenated key of the logical parent has not been stored with the logical child, I~S/VS constructs the concatenated key of the logical parent segment and presents it to the user as a part of the concatenated segment. If the destination parent is the physical parent of the logical child, IMS/VS must always construct the concatenated key of the physical parent.
Logical child segment
Destination parent concatenated key
Intersection data
Destination parent segment
Destination parent segment
Figure 4-21. Format of Concatenated Segment Returned to User I/O Area
UNIDIRECTIONAL LOGICAL RELATIONSHIP
A unidirectional logical relat'ionship is used to relate two segment types in one direction. Figure 4-28 shows the schematic view of a unidirectional logical relationship that is defined between tvo segment types in the same or different physical data bases, and the resulting view of the segment types involved that is defined in a logical data base. In a physical data base, a logical child segment type is defined as a physical child of one segment type, and a direct address or symbolic pointer is specified in the logical child segment type to point to the other segment type. This results in creating a physical parent to logical parent path between occurrences of the tvo segment types when they are loaded into storage.
Data Base Design Considerations 4.55
PHYSICAL DATA BASE(S)
A
C
LOGICAL DATA BASE A
B
I
B
I
C
I
Concatenated Segment Type
Figure 4-28. Unidirectional Logical Relationship
PHYSICALLY PAIRED BIDIRECTIONAL LOGICAL RELATIONSHIP
A physically paired bidirectional logical relationship is used to relate two segment types in two directions, and to provide the same intersection data in both directions. Figure 4-29 shows the schematic view of a physically paired bidirectional logical relationship that is defined in a physical data base or data bases, and the resnlting views of the segment types involved that are defined in a logical data base. In a physical data base or data bases, a logical child segment type is defined as a physical child of each of the two segment types being related, and a direct address or symbolic logical parent pointer is specified for each logical child segment type. One logical child segment type creates a physical parent to logical parent path between occurrences of the two segment types in storage in one direction, and the other logical child segment type creates a physical parent to logical parent path between occurrences of the two segment types in storage in the other direction as shown in Figure 4-29. When defining each logical child segment type in its physical data base, ~he user specifies that each logical child segment type is paired with the other logical child segment type to enable IMS/VS to maintain the same intersection data in paired logical child segments. In storage, paired logical child segments provide two different paths between the same tvo segments, and both logical child segments contain the same intersection data. For example, in Figure 4-30 under the NAME segment ADAMS, the occurrence of NAKESKILL that points to ARTIST, and under the SKILL segment ARTIST, the occurrence of SKILLNAME that points to ADAMS are physically paired logical child sagments since they provide two different paths between the same two segments and they contain the same intersection data. In a physically paired logical relationship, if the user updates intersection data in one logical child segment, IKS/VS automatically updates the intersection data in the paired logical child segment. When initially loading paired logical child segments, the user must place the same intersection data in each of the paired logical child segments.
During the initial load of a data base that contains physically paired logical children, the application program must load (using an ISRT call) both sides of the physical pair. The intersection data for the paired segments must be identical. After the initial load, in any update step, if an insert, delete, or replace is done for one of the paired segments, I~S/VS performs the same function for the paired segment.
4.56 IMS/VS System/Application Design Guide
L
PHYSICAL DATA DASE(S)
A
C
B
D
LOGICAL DATA BASE(S)
A
C
~and/or~
I
B
I
C
I
,
, D
I
A
L
Concatenated Segment Types
Figure 4-29. Physically Paired Bidirectional Logical ~elationship
NA..1Io1E
SKILL ARTIST
NAMESKILL ARTIST
SKILLNAME ADAMS
Figure 4-30. Physically Paired Logical Child Segments
VIRTUALLY PAIRED BIDIRECTIONAL LOGICAL RELATIONSHIP
In a virtually paired bidirectional logical relationship, one logical child segment type in storage relates two segment types in two directions, and provides the same intersection data in both directions. Figure 4-31 shows the schematic view of a virtually paired bidirectional logical relationship that is defined in a physical data base or bases, and the resulting views of the segment types involved that are defined in a logical data base.
Data Base Design Considerations 4.51
Physical Data Base(s)
Logical Data Base (s)
A
C
A
C
~and/or~
B
~
Real logical child
r-- --,
I
I
I
D
I
I
I
7L ----.J
Virtual logical child (Represents B when accessed from C)
Key: pp- Physical parent pointer lP-Logical parent p'.inter lCF-Log"",1 child first pointer
I
B
I
C
l
I
D
I
A
I
Concatenated Segment Types
Figure 4- 31. Virtually Paired Bidirectional Logical Relationship
To define a virtually paired bidirectional logical relationship, two logical child segment types are defined in the physical data bases involved in the logical relationship, but only one is actually placed in storage. The logical child segment type that is defined and results in storage is called the real logical child. The logical child segment type that is defined, but does not result in storage is called the virtual logical child.
In a virtually paired bidirectional logical relationship, occurrences of the real logical child create physical parent to logical parent, and logical parent to physical parent paths betwe~n occurrences of the two segment types being related. To accomplish this the real logical child is defined as a physical child segment type of one of the segment types being related, and a symbolic or direct address logical parent pointer is specified for the real logical child segment type. This creates a physical parent to logical parent path between occurrences of the two segment types being related. In addition, logical child pointers are specified for the logical parent segment type of the real logical child, and logical twin pointers are specified for the real logical child segment type to create a logical parent to physical parent path in storage between occurrences of the two segment types being related. The physical parent pointers required in occurrences of the real logical child for a logical parent to physical parent path are generated automatically by IMS/VS.
For the physical parent to logical parent path, the user controls the sequence in which occurrences of the real logical child are accessed from their physical parent segment by defining a sequence field in the real logical child segment type, or by specifying use of the insert rule of first, last or here when defining the real logical child in its physical data base. For the logical parent to physical parent path, the user controls the sequence in which occurrences of the real logical child are accessed from their logical parent by defining a virtual logical cbild segment type as a physical child of the logical parent of the real logical child, and in addition, by defining a sequence field in the virtual logical child. Or, the user can specify a second insert rule of first, last or here that controls the sequence of real logical child segments as viewed from their logical parent segment. The insert rule that controls the sequence of real logical child segments as viewed from their physical parent segment is specified on the SEGM statement that defines the real logical child segment type in its physical data
Q.S8 IMS/VS System/Application Design Guide
base. The insert rule that controls the sequence of real logical child
segments as viewed from their logical parent is specified on an LCHILD
statement. As input to DBDGEN when defining a segment type in a
L
physical data base that is used as a logical parent in one or more logical relationships, an LCHILD statement must follow a SEG~ statement
that defines a logical parent segment type for each logical child
segment type of that logical parent. LCHILD statements identify the
logical child segment types of a logical parent by following a SEG~
statement that defines a logical parent. For a virtually paired
bidirectional logical relationship, when no sequence field or a
non-unique sequence field is defined for the real logical child segment
type as viewed from its logical parent segment type, the insert rule of
first. last or here specified on an LCHILD statement controls the
sequence in which occurrences of the real logical child are accessed
from their logical parent segment.
To enable using a sequence field for sequencing occurrences of the real logical child from its logical parent segment type, a virtual logical child segment type is defined. A virtual logical child segment type is defined as a physical child of the logical parent segment type of the real logical child. A virtual logical child segment type is defined in the physical data base of the logical parent of the real logical child to represent the view of the real logical child when accessing the real logical child from its logical parent. In defining a virtual logical child segment type, a name is specified for the virtual segment type and the name of the real logical child segment type is associated to the name specified. To enable sequencing occurrences of the real logical child through sequence field values from the logical parent, a sequence field is defined in the virtual segment type. Since the virtual segment type represents the real logical child as viewed from its logical parent, the sequence field defined represents fields in the real logical child segment type as viewed from its logical parent type.
Since a logical child segment, by definition in a logical data base contains the concatenated key of a destination parent, followed by intersection data, if any, the concatenated key of the destination parent is included as a part of the logical child segment type when defining fields within the logical child segment. For a physical parent to logical parent path, fields can be defined within the logical child segment type that are comprised of the concatenated key of the logical parent. For a logical parent to physical parent path, fields can be defined within the logical child segment type that are comprised of the concatenated key of the physical parent. In addition for a logical parent to physical parent path. fields defined within the logical child segment type can be comprised of non-contiguous data in the logical child.
POINTERS AND THE COUNTER USED IN LOGICAL RELATIONSHIPS
Logical relationships can be defined in HISAK, RDAM and HIDAM data bases. or between any combination of the three. In defining logical relationships in each type or between types, the data organization methods used for the data bases must be considered when specifying the pointers used in logical relationships. Physical adjacency in storage is used to relate segments in a HISAM data base which means that all pointers to segments stored in a HISAM data base must be symbolic. In HDAM and HIDAM data bases, segments in storage are related through direct address pointers. Segments stored in HDAM and HIDA" data bases can be pointed to by symbolic or direct address pointers.
Data Base Design Considerations 4.59
The following pointers are used in defining logical relationships (see Figure 4-32):
· Logical Parent Pointer · Logical Child Pointer · Logical Twin Pointer · Physical Parent Pointer
Physical Parent
Physical Parent
Physical Parent
PP
PP
PP
Key: PP-Physical parent pointer LP-Logical parent pointer LCF-Logical child first pointer LCL-Logical child last pointer LTF-Logical twin forward pointer LTB-Logical twin backward pointer
Figure 4-32. Pointers Used in Logical Relationships
~2g1~!! Pa~~nt ~oint~£
A logical parent pOinter points from a logical child segment to a logical parent segment. To point to a logical parent segment type in a HISAM data base, a symbolic pointer must be stored with each logical child segment. XO pOint to a logical parent segment type in an HDAM or HIDAM data base, a symbolic pointer can be stored with each logical child segment and/or a direct address logical parent pointer can be specified.
4.60 IMS/VS system/Application Design Guide
&2~i£!! £hi!!l12~~£!! ~~~~ ~2ini~~2
Logical child and logical twin pointers are only specified in virtually paired bidirectional logical relationships. The logical child pointers that can be specified are logical child first, or logical child first and last pointers. A logical child first, or a combination of logical child first and last pointers are stored in the prefix of a logical parent segment to point to each of its logical child segment types. A logical child first pointer points to the first occurrence of a logical child segment type, and a logical child last pointer points to the last occurrence of that segment type when viewed from the logical parent.
The logical twin pointers that can be specified are logical twin forward or the combination of logical twin forward and backward pointers. Logical twins are multiple logical child segments of the same type that pOint to the same occurrence of a logical parent. A logical twin forward pointer points from a given logical twin to the logical twin stored after it and a logical twin backward .pointer pOints from a given logical twin to the logical twin stored before it. Use of the logical twin backward pointer improves delete performance.
ghysi£!! ~s~~n1 ~Q~ni~~2
In HDAH and HIDAK data bases involved in logical relationships, physical parent pOinters are generated automatically by IMS/VS. IHS/VS places physical parent pointers in the prefix of all logical child and logical parent segments, and in the prefix o~ all segments on which a logical child ,or logical parent segment is dependent in its physical data base. This creates a path from a logical child or logical parent segment to the root segment on which the logical child or logical parent segment is dependent. Since all segments on which a logical child or logical parent segment is dependent are chair-ed through physical parent pointers from the logical child or logical parent segment to its root, access to those segments in reverse order is enabled through a logical data base.
A four-byte counter is required in all logical parent segments that do not contain logical child pointers. It is stored in the prefix of a logical parent segment to maintain a count of how many logical child segments point to the logical parent. When required, it is placed in logical parent segments automatically by IMS/VS.
DEFINING SEQUENCE FIELDS FOR DATA BASES INVOLVED IN LOGICAL RELATIONSHIPS
To avoid potential problems in processing data bases involved in logical relationships, unique sequence fields should be defined in all logical parent segment types, and in all segment types that a logical parent is dependent on in its physical data base. When unique sequence fields are not defined in all segment types on the path to and including a logical parent segment type, multiple logical parent segments in a data base can have the same concatenated key. When multiple logical parent segments have the same concatenated key, problems can arise during initial data base load, and after initial data base load when symbolic logical parent pointers in logical child segments, are used to establish position on a logical parent segment to be processed.
Data Base Design Considerations 4.61
At initial data base load time, if logical parent segments with nonunique concatenated keys exist in a data base, the logical relationship resolution utilities attach all logical child segments that contain the same concatenated key to the first logical parent segment in a data base that has that concatenated key.
When inserting or deleting a concatenated segment and position for the logical parent portion of the concatenated segment is determined by the logical parents concatenated key, positioning for the logical parent stops on the first segment at each level of the logical parents data base that satisfies the key equal condition for that level. For insert when using this method of establishing position in the logical parents data base, if a segment is missing on the path to the logical parent segment to be inserted, a GE status code is returned to the application program. Under the same conditions for deletion of a logical parent segment a 0803 abnormal termination occurs.
RULES FOR D£FINING LOGICAL RELATIONSHIPS IN PHYSICAL DATA BASES
Pollowing are the rules that must be followed when defining logical relationships in physical data bases.
1. A logical child segment type must have a physical parent s~gment type and a logical parent segment type.
2. A logical child segment type can have only one physical parent segment type and one logical parent segment type.
3. A logical child segment type is defined as a physical child segment type in the physical data base of its physical parent.
4. A logical child segment type is always a dependent segment type in a physical data base, and as such, it can be defined at any level except the first level of a data base.
5. In its physical data base, a logical child segment type can not have a physical child segment type defined at the next lower level in the data base that is also a logical child.
6. A logical child segment type can have physical child segment types. However, if a logical child segment type is physically paired with another logical child segment type, only one of the paired segment types can have physical child segment types.
~2Si£~l R~~~~1
1. A logical parent segment type can be defined at any level of a physical data base including the root level.
2. A logical parent segment type can have one or multiple logical child segment types. Each logical child segment type rela~ed to the same logical parent segment type defines a logical relationship.
3. A segment type in a physical data base can not be defined as both a logical parent and a logical child.
4. A logical parent segment type can be defined in the same physical base as its logical child segment types, or in a different physical data base.
4.62 IMS/VS system/Application Design Guide
fllIsi£!! fY!!l~
1. A physical parent segment type of a logical child cannot also be a logical child.
REPLACE, INSERT AND DELETE RULES
xxxxxxxxxxxx
xxxxxxxxxxxx
x CUSTOMER x
x LOANS x
x
PP x
xxxxxxxxxxxx
*
x
LP x
xxxxxxxxxxxx
x
xxxxxxxxx xxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxx * ***** *
*
*
*
* v
v v
v
v
vvvvvvvvvvvv
x ACCOUNTS x
x BORROW x
v CUST v
x
x
x
LCx
v
VLC v
xxxxxxxxxxxx
xxxxxxxxxxxx
vvvvvvvvvvvv
x
x
xxxxxxxxxxxx
x PAYMENTS x
x
x
xxxxxxxxxxxx
PHYSICAL PATH
TO COSTOMER and BORROW
xxxxxxxxxxxx
x COSTOMER x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxxxxxx
x BORROW/LOANS x
x
x
xxxxxxxxxxxxxxxx
LOGICAL PATB
TO LOANS
PHYSICAL PATH
TO LOANS
xxxxxxxxxxxx
x LOANS x
x
x
xxxxxxxxxxxx
x
x
XXXXXX1:XXXXXXxxxx
X CUST/CUSTOMER x
x
x
xxxxxxxxxxxxxxxxx
LOGICAL PATH
TO CUSTOMER and BORROW
Insert, Delete, and Replace rules are needed when a segment is involved in a logical relationship because that segment is updatable from two paths; a physical path and a logical path.
Think a minute about the following questions:
1. Should the CUSTOMER segment be insertable by both its physical and logical paths?
2. Should the BORROW segment be replaceable via only the physical path, or by both the physical and logical paths?
3. If the LOANS segment is deleted by its physical path, should it be erased from the data base or should it be marked as physically deleted but remain accessible by its logical path?
Data Base Design Considerations 4.63
4. If the logical child segment BORROW or the concatenated segment BORROW/LOANS is deleted from the physical path, should the logical path CUST/CUSTOMER also be automatically deleted or should the logical path remain?
The answer to these questions depends on the application, but the enforcement of the answer depends on choosing the correct insert/delete/replace rules for the logical child, logical parent and physical parent segments.
The application processing requirements must be determined first, and the rules that support (enforce) those application processing requirements must be determined second.
For instance, the answer to question one depends on whether or not the application defines that a CUSTOMER segment must have been previously inserted into the Data Base prior to accepting the loan. An insert rule of physical (P) on the CUSTOMER segment would prohibit the insertion of the CUSTOMER segment expept by the physical path. While an insert rule of virtual (V) would allow inserting the CUSTOMER segment by either the physical or logical path.
It probably makes sense for a customer to be checked (past credit, time on current job, etc) and the COSTOMER segment inserted prior to approving the loan and inserting the BORROW segment. Thus, the insert rule of the CUSTOMER segment should be physical (P) to prevent this segment from being inserted logically (which incidentally provides better control of the application).
Consider question three. We can reason two ways: (1) If it is possible for this load institution to terminate a type of loan (cancel 7~ car loans -- create 9% car loans) before everyone who has that type of loan has fully paid the loan, then ve are saying that it's possible for the LOANS segment to be physically deleted and still be accessible from the logical path. This condition is supportable by specifying the delete rule for LOA~S as either logical (L) or virtual (V) but not as physical (P).
The physical (P) delete rule prohibits physically deleting a logical parent segment prior to all its logical children having been physically deleted (which means the logical path to the logical parent is deleted first) ·
INTRODUCTION SUMMARY
Data Base Administrators should examine all application needs and
·
decide who may insert, delete, and replace segments involved in logical
relationships and how those updates are to be made (physical path only
or physical and logical path). The insert/delete/replace rules in the
physical DBD and the PROCOPT parameter in the PCB are the means of
control. These rules are explained in detail in the following pages.
4.64 IMS/VS System/Application Design Guide
SEG!
NAME=
,
,
,
,
,
,
PPP FIRST ,RULES=(LLL,LAST )
VVV HERE
B
i!l!~~I _____I I /
_____ ~~J.~I~
II
___ ~~2J.!~~
J
P = PHYSICAL
L = LOGICAL
V = VIRTUAL
B = BIDIRECTIONAL VIRTUAL
The operands of the RULES parameter are positional. Position one defines the INSERT rule, position two defines the DELETE rule and position three the REPLACE rule.
For example, RULES=PLV says the insert rule is physical, the delete
rule is logical and the replace rule is virtual. Notice the "B" rule is
only applicable for delete.
The second positional operand (FIRST,LAST,HERE) does not apply in any way to a discussion concerning LOGICAL UPDATE RULES and was only included to maintain the correctness of the coding example.
In general the UP" rule (physical) is the most restrictive and the
"V" rule (virtual) the least restrictive with the "L" rule (logical)
somewhere in between.
RULES are applicable only to the segments involved in logical paths; the Logical child segment and its Logical Parent and Physical Parent segments. Rules are not coded for the virtual logical child.
xxxxxxxxxxxx
xxxxxxxxxxxx
x CUSTOMER x
x LOANS x
x
PP x
xxxxxxxxxxxx
*
x
LP x
xxxxxxxxxxxx
x
x
xxx
x xxxxxxxxxxxxxxxxxxx
x
x
xxxxxxxx
xxxxxx
x
x
xxxxxxxx
xxxx
* *
*** *
*
*
*
*
*
vv
v
v
v
vvvvvvvvvvvv
x ACCOUNTS x
x BORROW x
v CUST v
x
x
x
LC x
v
VLC v
xxxxxxxxxxxx
xxxxxxxxxxxx
VVVVVVVVVVVY
x
x
xxxxxxxxxxxx
x PAYMENTS x
x
x
xxxxxxxxxxxx
Data Base Design Considerations 4.65
THE REPLACE RULES
Applicable to the Physical Parent, Logical Parent and Logical Child segments of a Logical Path.
1. PHYSICAL: The segment can only be replaced when retrieved via a physical path. If this rule is violated, no data is replaced and an 'RX' status code is returned.
2. LQ~!£!~: The segment can only be replaced when retrieved via a
physical path. If this rule is violated, no data is replaced, however, an 'HX' status code is not returned. A ,~~, status code is returned.
3. !IRI~!~: The segment can be replaced when retrieved by either a
physical or logical path.
A replace can be performed only on that portion of a concatenated segment to which an application program is data sensitive.
If no data is changed in a segment, no data is replaced and no replace rule is violated.
If data in a concatenated segment has been changed, data is replaced only if neither portion of the concatenated segment violates its replace rule.
The replace rule is not checked for a segment which is part of a concatenated segment but was not retrieved.
The status code returned to an application program will indicate the first violation that was detected. These status codes are:
'AM'
Replace attempted and PROCOPT¢R
'DA'
Key field of segment was changed
'HX'
Replace rule violated
U.66 IKS/VS System/Application Design Guide
RULES= (--P)
RULES= (--P)
XXXXXXXXXXXX
x CUSTOl'tER x
x
PP x
XX'lXXXXXXXX'l
X LOANS x
'I
LP x
XXXXXXXXXXXX
* x
* * x
* * XXXXXXXXXXXXXXXXXXXXXXXXX
* * x
x
* * X
x
** * XXX'lXXXXXXxx
XXXXXXXXXXXX
xxxxxxxxxxxx
'I
V V
'I
V VVVVV'IVVVVVV
X ACCOUNTS X
X BORROW x
'I CUST 'I
X
X
x
LC X
v
VLC V
xxxxxxxxxxxx
xxxxxxxxxxxx
vvvvvvvvvvvv
X RULES= (--P)
x
XXXXXXXXXXXX
x PAYKENTS x
X
X
xxxxxxxxxxxx
XXXXXXXXXXXX
X CUSTO!!lER X
x
x
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXX
X BORROW/LOANS X
X
x
XXXXXXXXXXX'lXXXX
XXXXXXXXXXXX
X LOANS X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXX
X CUST/CUSTOftER X
X
x
xxxxxxxxxxxxxxxxx
GHU 'CUSTOMER' REPL GHN 'BORROW/LOANS' REPL
STATUS CODE=' trJi' ,STATUS CODE='~~' STATUS CODE= '101' STATUS CODE='RX'
The physical replace rule prevents replacing the LOANS segment as part of a concatenated segment. Replacement must be ~y the segment's
physical path.
Data Base Design Considerations 4.67
XXXXXXXXXXXX
XXXXXXXXXXXX
RULES=(--L)x CUSTOMER X
RULES=(--L)x LOANS X
* X
LP X
XXXXXXXXXXXX
X
LP X
XXXXXXXXXXXX
* * X
* X * * XXXXXXXXXXXXXXXXXXXXXXXXX
* X * X * * XXXXXXXXXXXX
X
*
X
* XXXXXXXXXXXX
X
X X
X
X
XXXXXXXXXXXX
X ACCOUNTS X
X BORROW X
* X CUST x
x
X
X
LC x
X
I.C x
XXXXXXXXXXXX
XXXXXXXXXXXX
XXXXXXXXXXXX
X RULES=any
RUI.ES=any
x
XXXXXXXXXXXX
X PAYMENTS X
X
x
XXXXXXXXXXXX
XXXXXXXXXXXX
x CUSTOMER X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXX
X BORROW/LOANS X
x
X
XXXXXXXXXXXXXXXX
XXXXXXXXXXXX
X LOANS X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXX
X CUST/CUSTOMER X
X
X
XXXXXXXXXXXXXXXXX
GHU 'CUSTOMER'
'BORROW/LOANS'
REPL
STATUS CODE='~~'
STATUS CODE='~~I
The logical replace rule prevents replacing the LOANS segment as part of a concatenated segment, since replacement must be ,by the segment1s physical path. However, the status code returned is I~WI. The BORROW segment, being accessed by its physical path, is replaced. Since the access of the logical child is by its physical path, it does not matter what replace rule is selected.
The LOGICAL replace rule provides for the special case of allowing the replacement of only the logical child half of the concatenation, and the return of a I~I status code.
4.68 IMS/VS System/Application Design Guide
RULES= (--V)
RULES= (--V)
XXXXXXXXXXXX
xxxxxxxxxxxx
x CUSTOKER x
x LOANS X
x
PP x
xxxxxxxxxxxx
*
X
LP X
xxxxxxxxxxxx
x
x
XXXXXXXXXXXXXXXXXXXXXXXXX
X
x
* *
* *
* *
*
*
v v
V
v
X
XXXXXXXXXXXX
X ACCOUNTS X
'" X
*
xxxxxxxxxxxx
*
X BORROW X
V
vvvvvvvvvvvv v COST v
x
x
X
LC X
V
VLC V
XXXXXXXXXXXX
xxxxxxxxxxxx
vvvvvvvvvvvv
X RULES= (--V)
X
XXXXXXXXXXXX
X PAYMENTS X
x
x
xxxxxxxxxxxx
XXXXXXXXXXXX
X CUSTOMER X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXX
X BORROW/LOANS X
X
X
xxxxxxxxxxxxxxxx
XXXXXXXXXXXX
X LOANS X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXX
X CUST/CUSTOMER X
X
X
xxxxxxxxxxxxxxxxx
GHU REPL
'LOANS'
'CUST/CUSTOMER'
STATUS CODE='~~'
STATUS CODE='~li'
~he virtual replace rule allows replacing the CUSTOMER s9gment via its logical path as part of a concatenated segment.
Specifying the replace rule as virtual, on any of the segments involved in the logical relationship, allows replacing that segment by either its physical path or logical path.
Specifying the replace rule as physical, on any of the segments involved in the logical relationship, prevents the replacement of that segment except when retrieved via its physical path.
Data Base Design Considerations 4.69
The logical replace rule provides for a special case. Specifying the replace rule for the logical parent as LOGICAL, allows !KS/VS to return a .~. status code but without replacing any data when the logical parent is accessed concatenated with the logical child. Since the logical child has been accessed by its physical path, its replace rule may be any of the three. Thus using the LOGICAL replace rule allows the selective replacement of the logical child half of the concatenation and
a 'HW' status code.
Figure 4-33 shows all possible combinations of the replace rules that can be specified, and the resulting actions that take place for each combination when a call is issued to replace a concatenated segment in a logical data base.
SEGMENT REPLACE RULES
Logical View I
B
C
Replace rule specified
B P P P P P P P P P L L LL L L L L LV VV VV VV VV CP P P L L LV VV P P P L L L VV VP P P L L LV vy
Denotes segment BX XX XX XX XX XX XX XX XX X
you are attempting
to replace
C XX XX XX XX XX XX XX XX XX
Status code
Data replaced?
Y =yes N =no
IRJ< RX
RXRX
RXRX
BY NY YY YY NY YY YY NY YY Y
C NN NN YY NN NN YY NN NN YY
Logical View 2
B
A
Physical
r -Da-ta -Ba-se -I - l
I
I
I
I
I
I
i'-- _ _ _ _ _ _ ..JI
Replace rule specified
B P P P P P P P P P L L L L L L L L LV VV VV VV VV AP P P L L LV VV P P P L L L VV VP P P L L LV VV
Denotes segment BX XX XX XX XX XX XX XX XX X
your are attempting
to replace
A XX XX XX XX XX XX XX XX XX
Status code
Data replaced?
Y =yes N =no
RXRJ< RJ< RX RXRX RX RXRX
RXRX
B N NN NN NN NN NN NY NY YY Y
A NN NN YN NN NN YY NN NN YY
Physical
r--Data--Base -2 -,
I
I
I
I
I
I
I
I
I
I
I
I
Logical View I
Logical View 2
Figure 4-33. .Replace Fules
4.70 IKS/VS System/Application Design Guide
THE INSERT RULES
Applicable to the Destination Parent (Logical Parent and Physical Parent) segments, but not to the Logical Child segment. See "Logical Child Insertion" below.
1. RHI§I£!L: The destination parent may be inserted QUll via its
physical parent path.
This means that the destination parent must exist prior to inserting a logical path. A concatenated segment is not needed: the logical child is inserted by itself.
2. &Q~I£!~: The destination parent may be inserted either via its physical path or concatenated with the logical child via the logical path.
When a logical child/destination parent concatenated segment is inserted, the destination parent is inserted provided it does not already exist and the I/O area key check does not fail (see 'DA' status code). If the destination parent does exist, it will remain unchanged and the logical child will be connnected to it.
3. !IRI2!L: The destination parent may be inserted via its physical
path or concatenated with the logical child via the logical path.
When a logical child/destination parent concatenated segment is inserted, the destination parent is replaced if it already exists. and is inserted if it does not.
LQ~i£g! £hi!g IU2~£!iQn
The RULES operand must be coded to supply replace and delete rules for the logical child. However, the insert rule has no meaning except to satisify the RULES macro's coding scheme, so any insert rule (P,L,V) may be coded.
1. A logical child will be inserted provided that the insert rule of the destination parent is not violated, and
2. The logical child to be inserted does not already exist (that is, is not a duplicate).
The I/O area in an application program must contain either the logical child or the logical child/destination parent concatenated segment in accordance with the destination parent's insert xule.
The logical child/destination parent concatenated segment insert operation is performed only if both components of the concatenated segment can be inserted4
The insert operation is not affected by KEY or DATA sensitivity as specified in a logical DBD or a PCB. This means that if a program is other than DATA sensitive to both the logical child and the destination parent of a concatenated segment, that program must nevertheless supply both in the I/O area when inserting a logical path, and the insert rule is logical or virtual. Thus maintenance programs that insert concatenated segments should be DATA sensitiYe to both segments in the concatenation.
Data Base Design Considerations 4.71
'AM' 'GE'
'II' 'IX'
An insert was attempted and PROCOPTII.
Parent of the destination parent or logical child was not found.
Attempt to insert duplicate segment.
Physical rule and destination parent not found.
I/O area key check fails. Concatenated segments contain the destination parent's key twice -- once as part of LCHILD's LPCK and second as a field in the parent. The keys must be equal.
ROLES= (P--)
RULES= (P--)
xxxxxxxxxxxx
xxxxxxxxxxxx
x CUSTOMER x
x LOANS x
x
PP x
x
LP x
xxxxxxxxxxxx
... xxxxxxxxxxxx
x x
... *...... vv
xxxxxxxxxxxxxxxxxxxxxxxxx
x
x
x
x
...
*
...
*
*
*
xxxxxxxxxxxx
xxxxxxxxxxxx ...
v
v v
yvvvvvvvvvvv
x ACCOUNTS x
x BORROW x
v CUST v
x
x
x
LC x
y
VLC v
xxxxxxxxxxxx
xxxxxxxxxxxx
VVVVVVYVVVVV
x RULES= (P--)
x
xxxxxxxxxxxx
x PAYMENTS x
x
x
xxxxxxxxxxxx
xxxxxxxxxxxx
x CUSTOMER x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxxxxxx
x BORROW/LOANS x
x
x
xxxxxxxxxxxxxxxx
xxxxxxxxxxxx
x LOANS x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxxxxxxx
x CUST/CUSTOMER x
x
x
xxxxxxxxxxxxxxxxx
If the LOANS segment does exist then:
ISRT 'CUSTOMER' ISRT ' BORROW'
STATUS CODE='Vlt'
STATUS CODE=' tJl!f'
However r i f LOANS does not eXist r then:
ISRT 'CUSTOMER' ISRT ' BORROW'
STATUS CODE='litJ'
STATUS CODE='IX'
4.72 IMS/VS System/Application Design Guide
RULES::: (L--)
RULES= (L--)
XXXXXXXXXXXX
X CUSTOl!ER X
XXXXXXXXXXXX
X LOANS X
X
PP X
X
LP X
XXXXXXXXXXXX
'" XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXXXXXXX
X
X
x
x
* * '" '"
* *
v v v
** '" *
y
v
XXXXXXXXXXXX
XXXXXXXXXXXX '"
VVVVVVVVVVVV
X ACCOUNTS X
X BORROW X
v CUST v
x
X
X
LC X
V
VLC V
XXXXXXXXXXXX
XXXXXXXXXXXX
x RULES= (L--)
VVVVVVVVVVVV
X
XXXXXXXXXXXX
X PAYMENTS X
X
X
XXXXXXXXXXXX
XXXXXXXXXXXX
X CUSTOf!ER X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXX
X BORROW/LOANS X
X
X
XXXXXXXXXXXXXXXX
XXXXXXXXXXXX
X LOANS X
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXX
X CUST/CUSTOMER X
X
X
XXXXXXXXXXXXXXXXX
ISRT · LOANS' ISRT 'CUST'
STATUS CODE='~~' STATUS CODE='IX'
The 'IX' status code is the result of omitting the concatenated segment CUST/CUSTOMER in the second call. IMS/VS checked for the key of the CUSTOMER segment (in the I/O area) and failed to find it. With the logical insert rule, the concatenated segment must be inserted to create a logical path.
Data Base Design Considerations 4.13
RULES= (V--)
RULES= (V--)
XXXXXXXXXXXX
XXXXXXXXXXXX
x CUSTO!ER x
x LOANS x
x
PP x
X
LP X
xxxxxxxxxxxx
.- XXXXXXXXXXXX
x
** v
x
* * XXXXXXXXXXXXXXXXXXXXXXXXX
* * x
x
* * X
x
** * XXXXXXXXXXXX
XXXXXXXXXXXX
v v
V
V
VVVVVVVVVVVV
x ACCOUNTS X
X BORROW X
V CUST V
x
x
x
LC X
V
VLC V
XXXXXXXXXXXX
XXXXXXXXXXXX
vvvvvvvvvvvv
x RULES= (V --)
X
XXXXXXXXXXXX
x PAYMENTS X
X
X
XXXXXXXXXXXX
XXXXXXXXXXXX
X CUSTOMER x
X
x
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXX
X BORROW/LOANS X
X
X
XXXXXXXXXXXXXXXX
XXXXXXXXXXXX
X LOANS x
X
X
XXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXX
X CUST/CUSTOMER X
X
X
XXXXXXXXXXXXXXXXX
ISRT 'CUSTOMER' ISRT 'BORROW/LOANS'
STATUS CODE=' )'1" STATUS CODE='W~'
Remember this action will replace the LOANS segment if present, and
insert the LOANS segment if not, so the virtual insert rule is a very powerful option.
4.74 IM5/VS System/Application Design Guide
In2~ RY1~ ~Ynm~~I
The virtual insert rule is the most powerful of the three rules in that it will insert the destination parent (inserted as a concatenated segment via the logical path) if the pa~ent didn't previously exist, and replace the existing destination parent with the inserted destination parent otherwise.
Specifying the insert rule as logical on the logical parent and the physical parent, allows insertion via either its physical path or its logical path as part of a concatenated segment. When inserting a concatenated segment, if the destination parent already exists, it will remain unchanged and the logical child will be connected to it. If i~ does not exist, it will be inserted. In either case, the logical child will be inserted provided that the segment is not a duplicate and that the destination parents insert rule is not violated.
Specifying the insert rule as physical prevents inserting the destination parent as part of a concatenated segment. This means that a destination parent may be inserted only by its physical path. If the insert creates a logical path, only the logical child needs be inser~ed.
DELETE RULES INTRODUCTION
xxxxxxxxxxxx
xxxxxxxxxxxx
x CUSTOMER x
x LOANS x
x
PP x
xxxxxxxxxxxx
*
x
LP x
xxxxxxxxxxxx
x
* · x
xxxxxxxxxxxxxxxxxxxxxxxxx
x
x
x
x
* xxxxxxxxxxxx
xxxxxxxxxxxx
*
* * * *
*
*
* v v v v v
'1'1'1'1'1'1'1"'1'1'1'1
x ACCOUNTS x
x BORROW x
v CUST v
x
x
x
LC x
v
VLC v
xxxxxxxxxxxx
xxxxxxxxxxxx
vvvvvvvvvvvv
x
x
xxxxxxxxxxxx
x PAYMENTS x
x
x
xxxxxxxxxxxx
PHYSICAL PATH
TO CUSTOMER and BORROW
xxxxxxxxxxxx
x CUSTOMER x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxxxxxx
x BORROW/LOANS x
x
x
xxxxxxxxxxxxxxxx
LOGICAL PATH
TO LOANS
PHYSICAL PATH
TO LOANS
xxxxxxxxxxxx
x LOANS x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxxxxxxx
x CUST/CUSTOMER x
x
x
xxxxxxxxxxxxxxxxx
LOGICAL PATH
TO CUSTOMER and BORROW
L
Data Base Design Considerations 4.75
The DLET call is a request for access path deletion not DASD space release of a segment. Delete rules are needed when a segment is involved in a logical relationship because that segment belongs to two paths; a physical path and a logical path.
The selection of the delete rules for the logical child and its logical and physical parent (or two logical parents if physical pairing), determines whether one or two DLET calls are necessary to delete the two access paths.
1. ffiI~I£A1 Ql~IIIQ!: Physically deleting a segment prevents further access to that segment via its physical parents. Physically deleting a segment also physically deletes its physical dependents.
EXCEPTION: If one of the physical parents of the physically deleted segment is a logical child segment which has been accessed from its logical parent. then the physically deleted segment is accessible from that logical child since the physical dependents of a logical child are "Variable Intersection Data."
further 2. LOGICAL DELETION: Logically deleting a logical child prevents access-via its logical parent. Unidirectional logical child segments are assumed to be logically deleted.
A logical parent is considered logically deleted when all of its logical children are physically deleted. For physically paired logical relationships, the physical child paired to the logical child must also be physically deleted. before the logical parent is considered logically deleted.
The picture below shows that an application program can be sensitive
to either the concatenated segment (SOURCE=(DATA/DATA). (DATA/KEY). (KEY/DATA) or only the logical child, since it is the logical child that is either physically or logically deleted (depending on the path accessed) in all cases.
xxxxxxxxxxxx
x CUSTOMER x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxxxxxx
x BORROW/LOANS x
x
x
xxxxxxxxxxxxxxxx
SOURCE=(DATA/DATA)
xxxxxxxxxxxx
x CUSTOMER x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxx
x BORROW x
x
x
xxxxxxxxxxxx
(DATA/KEY)
xxxxxxxxxxxx
x CUSTOMER x
x
x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxx
x LOANS x
x
x
xxxxxxxxxxxx
(KEY/DATA)
4.16 IMS/VS system/Application Design Guide
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG1 x x x pp x xxxxxxxxxxxx
xPDx SEG3 x x x pp x xxxxxxxxxxxx
*x x SEG7 x
*
* *
*x x LP x xxxxxxxxxxxx
x
x
xxxxxxxxxxxx
x
xxxxxxxxxxxxx*
* ** *
*
v
v
vvvvvvvvvvvv
x x SEG2 x
xPDx SEG4 x *
v SEG8 v
* x x LC x*
XXXXXXXXX1.~XX
xLDx I.e x xxxxxxxxxxxx
v
VLC v
vvvvvvvvvvvv
* * * *
x
xxxxxxxxxxxxx xPDx SEGS x
* *
* *
x x
x
xxxxxxxxxxxx
x
x
* xxxxxxxxxxxx
*xPDx SEG6 x
x x I.P x
xxxxxxxxxxxx
There are three paths to the logical child segment SEG4. The physical path from its physical parent SEG3, the logical path from its logical parent SEG7, and a third path from its physical dependents (SEG5 and SEG6) because segment SEG6 is a logical parent accessible from its logical child SEG2'.
These paths are "full-duplex" paths, meaning that accessibility is two way (up and down). There are two delete bits that control access along the paths, but they are "half-duplex," meaning that they only block half of each respective path. There is not a bit that blocks the third path. If SEG4 were both physically and logically deleted (PD and LD bits set), it would still be accessible from the third path and so would both of its parents.
Neither physical nor logical deletion prevents access to a segment from its physical or logical children. Logically deleting SEG4 prevents access to SEG4 from its logical parent SEG7, but does not prevent access from SEG4 to SEG7. Likewise, physically deleting SEG4 prevents access to SEG4 from its physical parent SEG3, but does not prevent access from SEG4 to SEG3.
DELETE BYTE DEFINITION
== ~~g~~~ g~~ti!
~~!~1~ ~Yl~
The delete byte is used by I8S/VS to maintain the delete status of segments within a data base. The meaning of each bit within the delete byte is shown in Figure 4-2.
The logical delete bit is only meaningful for logical child segments and their logical parents. The PD and LD bits are set or assumed set as follows:
· If a segment is physically deleted (prevent further access from its physical parent), then delete processing scans downward from that segment through its dependents, turns upward and either releases
Data Base Design Considerations 4.77
each segment's DASD space or sets the PD bit. HISA" is an exception
the delete bit is set in the segment specified by the DLET call and processing terminates.
· If the PD bit is set in a logical parent, then the 1D bit is set in all logical children that can be reached from that logical parent.
· In physical pairing when the PD bit is set in the physical child of a pair of logical children, the LD bit is set in its pair.
· When a virtually paired logical child segment is logically deleted
(prevent further access from its logical parent), the LD bit is set
in the logical child. If physical pairing, the LD bit is set in the
logical child and the PD bit is set in its pair (a physical child of
the logical parent).
.
· The LD bit is assumed to be set in all logical children of
unidirectional logical relationships.
· ~he LD bit is assumed set in a logical parent when the PD bit is set in all of its logical children. If physical pairing, the PD bit must be set in both paired logical children.
Ihi Qi!i!~ ~~!!
A Dt/I delete call may be issued against a segment defined in either a physical or logical DBD. The call can be issued against either a physical segment or a concatenation.
A delete call issued against a concatenated segment is a request for the deletion of the logical child along the accessed path.
If a concatenated segment or a logical child is accessed from its logical parent, then the DLET call is a request for logical deletion. In all other cases, a DLET call is a request for ph ysical deletion.
Physical deletion of a segment propagates logical deletion request to its logical children and propagates physical deletion request to its physical children and to any index pointer segments for which it is the source segment.
telete sensitivity must be specified in the PCB for each segment against which a DLE~ call may be issued, but need not be specified for the physical dependents of those segments.
Delete operations are not affected by KEY/DATA sensitivity as specified in either the PCB or logical DBD.
· DX'
'DA'
A delete rule is violated Key changed in the I/O area
4.78 IKS/VS System/Application Design Guide
DASD SPACE RELEASE
The delete call is not a request for DASD space release. Depending on the data base organizaticn, DASD space mayor may not be reused when it is released. DASD space for a segment is released when the following conditions are met:
· Space has been released fer all physical dependents of the segment.
· The segment is physically deleted (PD bit set or being set).
· If the segment is a logical child or a logical parent, then it must be physically and logically deleted (PD bit set/being set, and ID bit set/assumed set).
· If the segment is a dependent of a logical child {variable intersection data) and the DLET call was issued against a physical parent of the logical child, then the logical child must be both physically and logically deleted.
· If the segment is a primary index pointer segment, the space has been released for its target segment.
DELETE RULES
1. g~I~l~~: The logical parent must be previously !Q~~£sl!I ~~l~!~~ before a DLET call is effective against the segment or any of its physical parents. Otherwise the call results in a 'DX' status code and no segments are deleted.
However, if a delete reguest is made against the segment as a result of propagation across a logical relationship, then the PHYSICAL rule acts like the following LOGICAL rule.
2. 'Q§l~A': Either physical cr logical deletion can occur first.
When the logical parent is processed by a DLET call, all logical children are logically deleted, but the logical parent continues to be accessible from its logical children.
3. YIR1Y~': A logical parent will be deleted along its physical path:
· Explicitly when deleted by a DLET call. All of its logical children are logically deleted although the logical parent remains accessible from these logical children.
· Implicitly when it is no longer involved in a logical relationship. A logical parent is no longer involved in a logical relaticDshif when:
It has DO logical children pointing to it (its logical-child counter is zero, if it has any), and
It points tc no logical children (all of its logical-child pcinters are zero, if it has any), and
It has no physical children that are also real logical
childre~
Data Base Design Considerations 4.79
fhI§l£~! f~~~~t (!l~~!! f!l~lng Qn!I)
1. f!!!~!Q~L~Qq!,£UL!!.RI!!!!!: Meaningless 2. ~!.R~~I!'Q!!~ !!'RIQ!~: The physical parent will be automatically
deleted along its physical path when it is no longer involved in a logical relationship. The physical parent is no longer involved in a logical relationship when:
· It has no logical children pointing to it (its logical-child counter is zero, if it has one), and
· It points to no logical children (all of its logical-child pOinters are zero, if it has any), and
· It has no physical children that are also real logical children.
1. f!!!§I£!!:: The logical child segment must be logically deleted first and physically deleted second. If physical deletion is attempted first, the DLET call issued against the segment or any of its physical parents results in a lOX' status code and no segments are deleted. If a delete request is made against the segment as a result of propagation across a logical relationship, or if the segment is one of a physically paired set, then the rule acts like the following LOGICAL rule.
2. !:Q~I£!!:: Deletion of a logical child is effective for the path for which the delete vas requested. Physical and logical deletion of the logical child can be performed in any order.
The logical child and any physical dependents remain accessible from the non-deleted path.
3. !i~I!!!!:: A logical child is both logically and physically deleted when it is deleted through either its logical or physical path (setting either the PD or tD bits, sets both). If this rule is coded on only one logical child segment of a physically paired set, it acts like the LOGICAL rule.
For logical children involved in unidirectional logical relationships, the meaning of all three rules are the same, so any of the three rules can be specified.
EXAMPLES The following examples illustrate the use of the delete rules
individually for each of the segment types that the rule can be coded for (logical children, and their logical and physical parents).
Only the rule pertinent to the examples are shown in each figure. The explanation applies to the specific example.
4.80 IMS/VS system/Application Design Guide
XXXXXXXXXXXX
XXXXXXXXXXXX
RUL~S=(---)X CUSTOMER X
RULES=(---)x LOANS X
X
PP X
XXXXXXXXXXXX
* X
LP x
XXXXXXXXXXXX
X
* * X
* * XXXXXXXXXXXXXXXXXXXXXXXXX
* * X
X
* * X ** * XXXXXXXXXXXX
X
XXXXXXXXXXXX
v
v v v v
vvvvvvvvvvvv
X ACCOUNTS X
X BORROW X
V CUST v
X
x
X
LC X
"
VLC v
XXXXXXXXXXXX
XXXXXXXXXXXX
'1'1'1'1'1'1'1'1'1'1'1'1
X RULES= (-P-)
X
XXXXXXXXXXXX
X PAYMENTS X
x
x
XXXXXXXXXXXX
XXXXXXXXXXXXXXX
X X LOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
X X CUST/CUSTOMER X
xLOx
X
XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
X X CUSTOltER X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPOx BORROi/LOANS X
xLOx
X
XXXXXXXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXX
xPDx PAYMENTS x
X X
x
XXXXXXXXXXXXXXX
GHU OLET
'LOANS'
'CUST/CUSTOMER'
STATUS='~If'
STATUS='If~'
The physical delete rule requires the logical child be logically deleted first. The LO bit is no~ set in the BORROW segment.
GHU OLET
'CUSTOMER'
'BORROi/LOANS'
STATUS=')fif'
STATUS=' If~'
The logical child can be physically deleted only after being logically deleted. After the second delete, both the LO and PO bits are set.
The physical delete of the logical child also physically deletes the physical dependents of the logical child. The PO bit is set.
Data Base oesign Considerations 4.81
XXXXXXXXXXXX
XXX XXX XXX XXX
RULES=(---)x CUSTOMER X
RULES=(---)x LOANS X
X
PP X
XXXXXXXXXXXX
* X
LP X
XXXXXXXXXXXX
x
** V
X
XXXXXXXXXXXXXXXXXXXXXXXXX
X
X
* *
* *
*
*
V V V
X XXXXXXXXXXXX
** * X
XXXXXXXXXXXX
V VVVVVVVVVVVV
X ACCOUNTS X
X BORROW X
V COST V
x
x
X
LC X
V
VLC V
XXXXXXXXXXXX
XXXXXXXXXXXX
vvvvvvvvvvvv
X RULES= (-L-)
x
XXXXXXXXXXXX
X PAYIiENTS X
X
x
XXXXXXXXXXXX
XXXXXXXXXXXXXXX
X X CUSTOMER X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx BORROW/LOANS X
X X
X
XXXXXXXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXX
xPDx PAYMENTS X
X X
X
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
X X LOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOKER X
XLDx
x
XXXXXXXXXXXXXXXXXXXX
GHU 'CUSTOI!ER'
, BORROIl/LOANS'
DLET
STATOS=' )1)1'
STATUS=')I)I'
The logical delete rule allows the logical child to be deleted physically or logically first.
Physical dependents of the logical child are physically deleted, but remain accessible from the logical path not logically deleted.
GHU DLET
'.LOANS'
'CUST/COSTOI!ER'
ST ATU S=' )Jl!f'
STATOS='lJ)I'
The delete of the virtual logical child sets the LD bit on, in
the physical logical child BORROW (BORROW is logically deleted)
4.82 II!S/VS System/Application Design Guide
xxxxxxxxxxxx
XX1:XXXXXXXXX
RULES=(---)x CUSTOMER x
RULES=(---)X LOANS X
x
LP x
x
LP X
XXXXXXXXXXXX ·
x
*
XXXXXXXXXXXX
· X
X
·
* XXXXXXXXXXXXXXXXXXXXXXXXX ·
· · x
x
*
X
X
* · XXXX1:1:1:XX1:XX
XXXXXXXXXXXX
X ACCOUNTS 1:
X BORROW X
* *
X
X
X
X
XXXXXXXXXXXX X CUST X
X
X
X
LC x
X
LC X
XXXXXXXXXXXX
XXXXXXXXXXXX
xxxxxxxxxxxx
X RULES= (-P-)
RULES= (-P-)
X
-L-
-L
xxxxxxxxxxxx
X PAYMENTS X
X
X
XXXXXXXXXXXX
XXXXXXX1:XXXXXXX X X CUSTOPlE'R X
X X
X
XXXXXXXXXXXXXXX
X
X
xxxxxxxxxxxxxxxxxxxx
XPDx BORRO~/LOANS X
X X
X
XXXXXXXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXX xPDx PAYMENTS x
X X
x
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX X X LOANS X
X X
X
XXXXXXXXX1(XXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMER X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
GHU DLET
'CUSTOMER'
'BORROW/LOANS'
STATUS=' lflf'
STATUS='lfJf'
With the physical or logical delete rule, each logical child must be deleted from its physical path.
Physical dependents of the logical
child are physically deleted, but
remain accessible from the paired
logical child not deleted.
GHU DLET
'LOANS'
'CUST/CUSTOPlE'R'
STATUS=' mr'
STATUS='lflf'
Physically deleting BORROW set the LD bit in CUST. Physically deleting CUST viII set the LD bit in the BO'RROW segment.
Data Base Design Considerations 4.83
XXXXXXXXXXXX
RULES=(---)X CcrSTOMER x
x
PP x
XXXXXXXXXXXX
RULES={---)x LOANS x
X
LP X
XXXXXXXXXXXX
x
*
x
'" XXXXXXXXXXXXXXXXXXXXXXXXX
'" '" x
'" x
x
'"
X
'" '" XXXXXXXXXXXX
XXXXXXXXXXXX '"
x ACCOUNTS X
X BORROW X
x
X
X
LC X
XXXXXXXXXXXX
xxxxxxxxxxxx
X RULES= (-V-)
x
'" XXXXXXXXXXXX
'"
V
V
V
V
V
VVVVVVVVVVVV
V CUST V
v
VLC v
VVVVVVVVVYVV
XXXXXXXXXXXX
X PAYMENTS X
X
X
XXXXXXXXXXXX
XXXXXXXXXXXXXXX
X X CUSTOMER X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx BORROW/LOANS X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXX
xPDx PAYKENTS X
X X
X
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX
X X LOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMER X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
GHU 'CUSTOMER' 'BOR ROW /LOUS'
DLET
. STATUS=' "W'
STATUS=' W)f'
The virtual delete rule allows the logical child to be deleted physically and logically. Deleting either path, deletes both paths.
Physical dependents of the logical
child are physically deleted.
GHU , LOANS'
'CUST/CUSTOMER'
STATUS='GE'
The previous physical delete, deleted both paths, because the
delete rule is virtual. Deleting either path, deletes both.
4.84 IMS/VS system/Application Design Guide
XXXXXXXXXXXX
xxxxxxxxxxxx
RULES=(---)X CUSTOMER X
RULES={---)X LOANS X
X
LP X
X
LP X
XXXXXXXXXXXX '"
XXXXXXXXXXXX
X
*
*
X
X
* XXXXXXXXXXXXXXXXXXXXXXXXX
'" '" X
X
* '" *
X X X
X
XXXXXX~XXXXX
'" X
XXXXXXXXXXXX '"
'"
X
rxxxxxxXXXXX
X ACCOUNTS X
X BORROW X
'" X CUST X
X
X
X
LC X
X
LC X
XXXXXXXXXXXX
xxxxxxxxxxxx
xxxxxxxxxxxx
X RULES= (-V-)
RULES= (-V-)
X
XXXXXXXXXXXX
X PAYMENTS x
X
X
XXXXXXXXXXXX
XXXXXXXXXXXXXXX X X CUSTOMER X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx BORROW/LOANS X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXX xPDx PAYMENTS X
X X
X
XXXXXXXXXXXXXXX
XXXXXXXXXXXXXXX X X LOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMER X
xLDx
X
xxxxxxxxxxxxxxxxxxxx
GHU 'CUSTOMER' 'BORROW/LOANS'
DLET
STATUS=' )fW'
STATUS=IW~'
With the virtual delete rule, deleting either logical child deletes both paired logical children.
(notice the PD & LD in both)
Physical dependents of the logical child are physically deleted.
GHU 'LOANS' 'CUST/CUSTOMER'
STATUS='GE'
Physically deleting BORROW also physically deleted CUST, so the CUST segment was not found, that is, 'GE' status code.
Data Base Design Considerations U.85
xxxxxxxxxxxx
RULES=(---)x CUSTOKER x
x
PP x
XXXXXXXXXXXX
RULES=(-P-)x LOANS X
X
LP X
XXXXXXXXXXXX
'" XXXXXXXXXXXX
x
x
'" '" XXXXXXXXXXXXXXXXXXXXXXXXX
'" '" x
x
'" '" XXXXXXXXXXXX
X
*
X
* XXXXXXXXXXXX
'"
'"
'"
V
V
V
V
V
VVVVVVVVVVVV
x ACCOUNTS X
X BORROW X
V CUST V
x
x
X
LC X
V
VLC V
XXXXXXXXXXXX
XXXXXXXXXXXX
vvvvvvvvvvvv
X RULES= (- --)
X
XXXXXXXXXXXX
X PAYMENTS X
X
X
XXXXXXXXXXXX
"BEFORE"
XXXXXXXXXXXXXXX
X x LOANS X
x x
x
XXXXXXXXXXXXXXX
x
x
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMEB x
x x
X
XXXXXXXXXXXXXXXXXXXX
"AFTER"
XXXXXXXXXXXXXXX
xPDx lOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXY.XXXXXXXX
XPDX CUST/CUSTOKER X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
GHU 'LOANS' DLET
ST ATUS=' 101'
STATUS=' }If)f'
The physical delete rule requires that all logical children be previously physically deleted.
Physical dependents of the logical parent are physically deleted.
The DLET status code will be 'DX'
if all of its logical children
were not previously physically
deleted.
All logical children are logically deleted. LD bit is set in the physical logical child BORROW.
4.86 IMS/VS Sy~tem/Application Design Guide
XXXXXXXXXXXX
xxxxxxxxxxxx
BULES=(-P-)x CUSTOMER X
BULES=(-P-)x LOANS X
X
LP X
X
LP X
xxxxxxxxxxxx '"
XXXXXXXXXXXX
X
*
'"
x
'" X
xxxxxxxxxxxxxxxxxxxxxxxxx
x
x
'"
'" x
X
'" xxxxxxxxxxxx
XXXXXXXXXXXX '"
'" '" '"
'"
x x
X
X
xxxxxxxxxxxx
x ACCOUNTS x
X BORROW x
* X CUST X
x
x
X
LC x
X
LC X
xxxxxxxxxxxx.
xxxxxxxxxxxx
XXXXXXXXXXXX
x RUU!S= (---)
RULES= (_._)
x
xxxxxxxxxxxx
x PAYMENTS x
X
x
xxxxxxxxxxxx
"BEFORE"
XXXXXXXXXXXXXXX
X X C()STOrtER x
x X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXxx
xPDx BORROW/LOANS X
xLDx
X
xxxxxxxxxxxxxxxxxxxx
"AFTER"
XXXXXXXXXXXXXXX
xPDx CUSTOMER X
X X
x
xxxxxxxxxxxxxxx
X
X
xxxxxxxxxxxxxxxxxxxx
xPDx BORROW/LOANS X
xLDx
X
xxxxxxxxxxxxxxxxxxxx
X
X
XXXXXXXXXXXXXXX
xPDx PAYMENTS X
X X
x
xxxxxxxxxxxxxxx
GHU 'CUSTOMER' DLET
STATUS=' )"r'
STATUS='l!!')j'
The physical delete rule requires: (1) all logical children to be
previously physically deleted. (2) physical children pair~d to its
logical child to be previously physically deleted.
CUSTOMER, the logical parent has been physically deleted.
Both the logical child and its pair had previously been physically deleted. (PD and LD set on in the "BEFORE" figure of BORROW/LOANS)
All physical dependents of the physical parent are physically deleted; ACCOUNTS (not shown) is physically deleted.
Data Base Design Considerations 4.81
xxxxxxxxxxxx
XXXXXXXXXXXX
RULES=(---)x CUSTOMER x
BULES=(-L-)x LOANS X
x
PP x
xxxxxxxxxxxx
*
X
LP X
xxxxxxxxxxxx
x
* * x
* * XXXXXXXXXXXXXXXXXXXXXXXXX
** * x * x * * XXXXXXXXXXXX
x
X XXXXXXXXXXXX '"
V
v
V V V
VVVVVVVVVVVV
x ACCOUNTS X
X BORROW X
V CUST V
x
x
X
LC X
V
VLC V
XXXXXXXXXXXX
xxxxxxxxxxxx
VVVVV'YVV'YVVV
X RULES= (---)
x
XXXXXXXXXXXX
X PAYMENTS X
X
X
xxxxxxxxxxxx
"BEFORE"
XXXXXXXXXXXXXXX
x x LOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
xxxxxxxxxxxxxxxxxxxx
X X CUST/CUSTOMER X
x X
X
XXXXXXXXXXXXXXXXXXXX
"AFTER"
xxxxxxxxxxxxxxx
xPDx L01NS X
x X
x
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
X X CUST/CUSTOMER X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
GHU 'LOANS' DLET
STATUS='l'!'Jd"
STATUS= 'JIll'
The logical delete rule allows
either physical or logical deletion
first; neither causes the other.
Physical dependents of the logical
parent are physically deleted.
The logical parent LOANS remains
accessible from its logical
children.
All logical children are logically
deleted. LD bit is set in the
physical logical child BORROW.
The above processing and results would be the same if the logical parent LOANS delete rule were virtual instead of logical. An additional example to explain the virtual delete rule follows.
U.BB IMS/VS system/Application Design Guide
XXXXXXXXXXXX
XXXXXXXXXXXX
RULES=(-L-)x CUSTOMER X
RULES=(-L-)x LOANS X
* X
LP X
XXXXXXXXXXXX
X
LP X
XXXXXXXXXXXX
X X
* *
* *
X
X
XXXXXXXXXXXXXXXXXXXXXXXXX
X
X
* * **
X X
X
XXXXXXXXXXXX
X ACCOUNTS X
X
*
* * XXXXXXXXXXXX
* X BORROW X
X
XXXXXXXXXXXX
X CUST X
X
x
x
LC X
X
LC X
XXXXXXXXXXXX
XXXXXXXXXXXX
X RULES= (---)
XXXXXXXXXXXX
RULES= (---)
X
XXXXXXXXXXXX
X PAYMENTS X
x
X
XX XXXX XXXXXX
"BEFORE"
XXXXXXXXXXXXXXX
X X LOANS X
X X
X
XXXXXXXXXXXXXXX
X
x
XXXXXXXXXXXXXXXXXXXX
X X CUST/CUSTOMER X
x X
X
xxxxxxxxxxxXXXXXXXXX
"AFTER"
XXXXXXXXXXXXXXX
xPDx LOANS X
X X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMER X
X X
X
XXXXXXXXXXXXXXXXXXXX
GHU 'LOANS'
DLET
STATUS=' )StI'
STATUS=' tI)f'
The logical de19te rule allows either physical or logical deletion first; neither causes the other. Physical dependents of the logical parent are physically deleted.
The logical parent LOANS remains
accessible from its logical
children.
All physical children ar~ physically deleted. Paired logical children
are logically deleted.
The above processing and results would be the same if the logical
parent LOANS delete rule were virtual instead of logical. An additional example to explain the virtual delete rule follows.
Data Base Design Considerations u.89
xxxxxxxxxxxx
XXXXXXXXXXXX
RULES=(---)x CUSTO"ER x
RULES={-V-)x LOANS ~
x
PP x
x
LP X
xxxxxxxxxxxx
x
· ·'" XXXXXXXXXXXX v
x
'" '" XXXXXXXXXXXXXXXXXXXXXXXXX
'" '" x
x
'" '" x
X
'" '" XXXXXXXXXXXX
XXXXXXXXXXXX '"
V V V V
VVVVVVVVVVVv
x ACCOUNTS X
X BORROW X
V CUST v
X
X
X
LC X
V
VLC V
XXXXXXXXXXXX
XXXXXXXXXXXX
X RULES= (---)
VVVVVVVVVVVV
x
XXXXXXXXXXXX
X PAY"ENTS X
X
X
XXXXXXXXXXXX
"BEFORE"
XXXXXXXXXXXXXXX
X X CUSTOMER X
x X
X
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
X X BORROW/LOANS X
x X
x
XXXXXXXXXXXXXXXXXXXX
"AFTER"
XXXXXXXXXXXXXXX
xPDx LOANS X
X X
X
XXXXXXXXXXXXXXX
X
x
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMER X
xLDx
X
XXXXXXXXXXXXXXXXXXXX
GHU 'COSTO!'lER'
, BORROW/LOANS'
DLET
STATUS=' JltJ'
STATUS=' tJ".,
The virtual delete rule allows
explicit and implicit deletion.
Explicit is same as logical rule.
Implicit means the logical parent is physically deleted when the last logical child is physically deleted.
Physical dependents of the logical child are physically deleted.
The logical parent is physically deleted. Physical dependents of the logical parent are physically deleted.
All logical children are logically deleted. LD bit is set in the physical logical child BORROW.
4.90 IMS/VS system/Application Design Guide
XXXXXXXXXXXX
RULES=(-V-)x COSTOMER x
x
LP x
xxxxxxxxxxxx
RULES=(-V-)x LOANS X
X
LP X
XXXXXXXXXXXX ...
x
...
XXXXXXXXXXXX
...
X
x
...
XXXXXXXXXXXXXXXXXXXXXXXXX
x
X
...
...
...
... '"
X X X
x
X
!Ie
X
XXXXXXXXXXXX
XXXXXXXXXXXX !Ie
!Ie
XXXXXXXXXXXX
x ACCOUNTS X
x
x
X BORROW X
X
LC X
'" X CUST X
x
LC x
xxxxxxxxxxxx
XXXXXXXXXXXX
xxxxxxxxxxxx
X RULES= (---)
RULES= (---)
X
XXXXXXXXXXXX
X PAYKENTS X
x
1
XXXXXXXXXXXX
"BEFORE"
xxxxxxxxxxxxxxx
X X CUSTOMER X
x x
x
XXXXXXXXXXXXXXX
X
X
XXXXXXXXXXXXXXXXXXXX
X X BORROW/LOANS X
xLDx
X
xxxxxxxxxxxxxxxxxxxx
"AFTER"
xxxxxxxxxxxxxxx
xPDx LOANS X
x x
x
xxxxxxxxxxxxxxx
x
X
XXXXXXXXXXXXXXXXXXXX
xPDx CUST/CUSTOMER X
xLDx
. X
XXXXXXXXXXXXXXXXXXXX
GHU DLET
'CUSTOMER'
'BORROW/LOANS'
ST ATUS=' lttW'
STATUS=' )f)J'
The virtaal delete rule allows
explicit and implicit deletion.
Explicit is same as logical rule.
Implicit means the logical parent is physically deleted when the last logical child is physically and logically deleted. Physical dependents of the logical child are physically deleted.
The logical parent is physically deleted. Any physical dependents of the logical parent are physically deleted.
HQI!~~: CUST segment must have physically deleted prior to the DLET call. (See above that the LD is set in BORROW)
Data Base Design Considerations 4.91
XXXXXXXXXXXX
RULES=(-B-)X CUSTOMER X
X
PP X
XXXXXXXXXXXX
XXXXXXXXXXXX
RULES=(---)X LOANS X
* X
LP X
XXXXXXXXXXXX
X
x xxxxxxxxxxxxxxxxxxxxxxxxx
** V
* *
V
V
* * X
x
* XXXXXXXXXXXX
x
* *
X
**
XXXXXXXXXXXX
V V
YVVVVVVVVVVV
X ACCOUNTS X
X BOP-ROW X
V CUST V
x
X
XXXXXXXXXXXX
X
LC X
xxxxxxxxxxxx
X RULES= (---)
V
VLC V
vvvvvvvvvvvv
x
xxxxxxxiJ:xxxx
X PAYMENTS X
X
X
xxxxxxxxxxxx
"BRFORE"
XXXXXXXXXXXXXXX
x X LOANS X
X X
X
xxxxxxxxxxxxxxx
x
X
xxxxxxxxxxxxxxxxxxxx
X X CUST/CUSTOMER X
X X
X
xxxxxxxxxxxxxxxxxxxx
"AFTER"
xxxxxxxxxxxxxxx
xPDx CUSTOMER x
x X
x
xxxxxxxxxxxxxxx
X
X
xxxxxxxxxxxxxxxxxxxx
xPDx BORROW/LOANS X
xLDx
X
xxxxxxxxxxxxxxxxxxxx
X
X
xxxxxxxxxxxxxxx
xPDx PAYMENTS X
X X
x
XXXXXXXXXXXXXXX
GHU DLET
'LOANS'
'CUST/CUSTOMER'
STATOS=')!,I1!'
STATUS=''')!''
The bidirectional virtual rul~ for the physical parent, is equal to virtual for the logical parent.
When the last logical child is logically deleted, the physical parent is physically deleted.
The logical child (as a dependent of the physical parent) is physically deleted.
All physical dependents of the physical parent are physically deleted; ACCOUNTS (not shown), BORROW and PAYMENTS.
4.92 IMS/VS System/Application Design Guide
!££!§§!bi!!iI ~{ ~!i!l!~ [~!!ni§
A physically deleted segment remains accessible under the following circumstances:
1. A physical dependent of the deleted segment is a logical parent which is accessible from its logical children.
2. A physical dependent of the deleted segment is a logical child which is accessible from its logical parent.
3. A physical parent of the deleted segment is a logical child which is accessible from its logical parent. The deleted segment is this case is variable intersection data of a bidirectional logical relationship_
A logically deleted logical child cannot be accessed from its logical parent.
Neither physical nor logical deletion prevents access to a segmen~ from its physical or logical children. Since logical relationships provides for inversion of the physical structure, a segment may be either physically or logically deleted or both and still be accessible from a dependent segment, because of an active logical relationship. A physically deleted root segment can be accessed when it is, defined as a dependent segment in a logical DBD. The logical DBD defines the inversion of the physical DBD.
Data Base Design Considerations U.93
1. !!A~~~! Q! Q~~!~ ~~2~~!~ !~~~~§!~I~~!!: When the physical dependent of a deleted segaent is a logical parent with logical children not physically deleted, the logical parent and its physical parents are accessible froa those logical chi.ldren.
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG 1 x
xPDx SEG3 x
*x x SEG7 x
x x PP x xxxxxxxxxxxx
x x pp x xxxxxxxxxxxx
*
* *x x LP x
* xxxxxxxxxxxx
x x xxxxxxxxxxxx
x
xxxxxxx xxxxxx*
* **
*
*
v v vvvvvvvvvvvv
x x SEG2 x
xPDx SEG" x *
v SEG8 v
x x LC x*
x x LC x
v
VLC v
xxxxxxxxxxxx *
xxxxxxxxxxxx
vvvvvvvvvvvv
* * * *
x)
x xxxxxxxxxxxx xPDx SEGS x
* *
x x xxxxxxxxxxxx
* *
x
x
* xxxxxxxxxxxx
*xPDx SEG6 x
x x LP x
xxxxxxxxxxxx
The above physical structures show that SEG3, SEG", SEG5, and SEG6
have been physically deleted. probably by issuing a DLET call for SEG3.
This resulted in all of SEG3's dependents being physically deleted.
(SEG6's delete rule # PHYSICAL or a 'DX' status code would be the
result).
.
SEG3, SEG4, SEG5, and SEG6 reaain accessible from SEG2, the logical child of SEG6, because SEG2 is not physically deleted.
However, physical dependents of SEG6 cannot be accessible, and their DASD sp~ce is released unless an active logical relationship prohibits such release.
4.94 IKS/VS System/Application Design Guide
2.
Qr ~!~f&~
~~~!~~ ~~2~~!!~ l~~~~§!~!&I!!: When the physical
dependent of a deleted segment is a logical child whose logical
parent is not physically deleted, the logical child, its physical
parents and its physical dependents are accessible from the
logical parent.
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x S;G1 x
xPDx SEG3 x
*x x SEG? x
x x PP x xxxxxxxxxxxx
x x PP x xxxxxxxxxxxx
*
*.. .
x x LP x xxxxxxxxxxxx
x x
xxxxxxxxxxxx
x
xxxxxxxxxxxxx·
*
*'" *
*
v v vvvvvvvvvvvv
x x SEG2 x
xPDx SEGU x *
v SEGS v
x x LC x*
x x LC x
v
VLC v
xxxxxxxxxxxx *
xxxxxxxxxxxx
vvvvvvvvvvvv
* ...
x x
...
xxxxxxxxxxxx
*
xPDx SEGS x
* ...
...
x x
x
xxxxxxxxxxxx.
x
...
x
· xxxxxxxxxxxx
*xPDx SEG6 x
x x LP x
xxxxxxxxxxxx
The above physical structures show that SEG3, SEG4, SEGS, and SEG6 have been physically deleted.
The logical child segment SEG4 remains accessible from its logical parent SEG? (note that SEG? is not physically deleted). Also acc~ssible are segments SEGS and SEG6, which are variable intersection data. The physical parent of the logical child (SEG3) is likewise accessible from the logical child ISEG4).
Data Base Design Considerations 4.95
QI 3~ t!!~~
~&tI~ ~t2~!~ !££t~~~!&II!: A physically and
logically deleted logical child can be accessed from its physical
dependents.
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG1 x x x PP x
xxxxxxxxxxxx
xPDx SEG3 x x x PP x
xxxxxxxxxxxx
*x x SEG7 x
*
· *
*x x LP x xxxxxxxxxxxx
x
x
· ·
v
x xxxxxxxxxxxx
x xxxxxxxxxxxx·
**
*
v
vvvvvvvvvvvv
x x SEG2 x
xPDx SEGU x.
v SEG8 v
x x LC x* xxxxxxxxxxxx
*
xLDx LC x xxxxxxxxxxxx
v
VLC v
vvvvvvvvvvvv
* *
* *·
x
x
xxxxxxxxxxxx
xPDx SEGS x
x x
x
'" xxxxxxxxxxxx
'" *
x x
'" xxxxxxxxxxxx
*xPDx SEG6 x
x x LP x
xxxxxxxxxxxx
The above physical structures show that the logical child SEG4 is both physically and logically deleted~
From a previous example (number 1) we know that SEG6 (a logical parent) is accessible from SEG2, if that segment (its logical child) is not physically deleted. Likewise ve know that once we have accessed SEG6, its physical parents (SEG5, SEG4, SEG3) are accessable. It does
1,. not matter that the logical child is logically deleted (which is the
only difference in this example from example
The third path cannot be blocked because a delete bit for this path does not exist. Thus the logical child SEG4 is accessible from its dependents regardless of its being physically and logically d~leted~
4.96 IMS/VS system/Application Design Guide
4. EX1!PLE OF DELETED SEGMENTS ACCESSIBILITY: When a segment accessed-by-its-THIiD-path-iS-deleted,-it is physically deleted
in its physical data base, but remains accessible from its THIRD path.
------~£~---------
xxxxxxxxxxxxx x SEG1 x xxxxxxxxxxxxx
x
xxxxxxxxxxxxx x SEG2/SEG6 x xxxxxxxxxxxxx
x
xxxxxxxxxxxxx x SEG5 x xxxxxxxxxxxxx
GHU 'SEG5' DLET
STATUS='tJtJ'
STATOS='tJ)1'
ACTION: SEG5 is physically deleted
by the action of the DLET call and
SEG6 is physically deleted by prop
agation. SEG2/SEG6 has unidirec
tional pointers, so SEG2 was
considered logically deleted prior
to the DLET call ('LDI bit only
assumed set).
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG 1 x
x x SEG3 x
*x x SEG7 x
x x PP x xxxxxxxxxxxx
x x PP x xxxxxxxxxxxx
· *
*
*x x LP x xxxxxxxxxxxx
x
x xxxxxxxxxxxx
x x SEG2 x
· x
x xxxxxxxxxxxx·
x x SEG4 x *
* *
*
'"
v v
VVVVVVVVYVVV
v SEG8 v
xLDx LC x*
x x LC x
v
VLC v
xxxxxxxxxxxx *
xxxxxxxxxxxx
vvvvvvvvvvvv
*
x x
* * **
xxxxxxxxxxxx
xPDx SEG5 x
x x
x
xxxxxxxxxxxx
·
x
*
x
* xxxxxxxxxxxx
*xPDx SEG6 x
x x LP x
xxxxxxxxxxxx
The results are interesting. SEG5 is unaccessible when accessed by its physical parent path (from SEG4) unless SEG4 were accessed by its logical parent SEG7 (SEG5 & SEG6 are accessible as variable intersection data). SEG5 is still accessible from its third path (from SEG6) because SEG6 is still accessible from its logical child. Thus a segment can be physically deleted by an application program and still be accessible to
that application program, using the same PCB used to delete the segment.
Data Base Design Considerations 4.97
5. !~~E~!~-I~~~I!!IIQR_fQ~§~I~II!: If a logical parent is physically and logically deleted, it's DASD space will be released. For this to occur, all of its logical children must be physically and logically deleted. However, these logical children may not be DASD space released because of physical dependents with active logical relationships. Accessing such a logical child from its physical dependents may result in an 850 through 859 abnormal termination if the LPCK is not stored in the
logical child or if the concatenation definition is data sensitive to the logical parent.
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG 1 x
x x
PP x
xPDx SEG3 x
x x
pp X
*xPDX SEG1 x
* *xLDx LP x
xxxxxxxxxxxx
x
x
xxxxxxxxxxxx
x x SEG2 x
* * xxxxxxxxxxxx
xxxx xPDx
x x xxxxxxxx* SEG4 x
* * * * *
*
* x x LC x*
xxxxxxxxxxxx
xLDx
LC x
xxxxxxxxxxxx
* * * * * * *
x
x
xxxxxxxxxxxx
xPDx SEG5 x
x x
x
xxxxxxxxxxxx
x
* *
x
xxxxxxxxxxxx
*xPDx SEG6 x
x x
LP X
xxxxxxxxxXJ:X
The logical parent SEG7 has been physically and logically deleted (the LD bit is never really set, but only assumed set. It is shown for the purpose of illustration). All of the logical childr~n of the logical parent have also been physically and logically deleted. However, the logical parent has had its segment space released, whereas the logical child (SEG4) still exist due to an active logical relationship that precludes releasing its space.
If an application program accesses SEG4 from its dependents (SEG1 to SEG2/SEG6 to SEG5) IM3 must build the logical parents concatenated key if that key is not stored in the logical child. When IMS/VS attempts to access the logical parent SEG7, the results will be an abnormal termination. The 850 through 859 abnormal termination codes indicate that IKS/VS followed a pointer that did not lead to the segment expected.
4.98 IMS/VS System/Application Design Guide
AVOIDING ABNOB~AL TERMINATION We must avoid creating a physically deleted logical child which can
be accessed fro. below in the physical structure (its third path). A logical child can be accessed from below if any of its physical dependents are accessible through logical paths.
One solution is to require the logical paths to dependents to be broken before physically deleting the logical child. This can be done by using a PHYSICAL rule for the dependents as long as no physical deletes are allow to propagate into the data base. Therefore no VIRTUAL rules on logical children can be allowed at or above THE LOGICAL CHILD. since with the V rule a propagated logical delete causes a physical delete without a P rule violation check (see DETECTION OF PHYSICAL DELETE RULE VIOLATION). The LOGICAL rule will also cause propagation if the PD bit is already, but ~he depAndents PHYSICAL rule will prevent that case. Similarly. no VIRTUAL rule can be allowed on any logical parent above the logical child, since the logical delete condition would cause the physical delete.
A second solution is to break the logical path whenever the logical child is physically deleted. This can be accomplished for subordinate logical child segments with the VIRTUAL delete rule. Subordinate logical parent segments need to have bidirectional logical children with the VIRTUAL rule (must be able to reach the logical children) or physcially paired logical children with the VIRTUAL rule. This solu~ion will not work with subordinate logical parent's pointed to by unidirectional logical child~en.
Data Base Design Considerations 4.99
DETECTION OF PHYSICAL DELETE RULE VIOLATION
The delete routine scans the physical structure containing the requested segment to be deleted to determine if any segment in the physical structure has the physical delete rule and whether that rule is
violated.
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG1 x
x x SEG4 x
x x SEG8 x
x x
x
xxxxxxxxxxxx
x
x x LP x*
xxxxxxxxxxxx *
x RULE~L
*
*
*
*x x LP x xxxxxxxxxxxx
RULE=L.x
x RULE=L xxxxxxxxxxxx x x SEG2 x
x xxxxxxxxxxxx x x SEG5 x
*
*
·
·
*
x
xxxxxxxxxxxx x x SEG9 x
x x LP x.
* XXXXXXXXXXll'X
x x LC x* xxxxxxxxxxxx
*x x LC x xxxxxxxxxxxx
V
··
·· VVVyvvvvvvvvv **
· · v SEG3 v
· · v
VLC v
· · vvvvvvvvvvvv
x RULE=V
RULE=V
x
xxxxxxxxxxxx
x x SEG6 x
x x PP x RULE=any
xxxxxxxxxxxx
*·· *·
x x
'"
'" xxxxxxxxxxxx
* *x x SEG1 x
x x LC x RULE=P
xxxxxxxxxxxx
________f£~ ________ _
xxxxxxxxxxxx
x x SEG4 x
x x
x
xxxxxxxxxxxx
GHU 'SEG4' DLET
STATUS='W'
ST ATUS=' DX'
SEG1 (logical child of SEG3) has the physical delete rulp. and it has not been logically deleted (the LD bit has not been set) so the physical rule is violated; a 'DX' status code is returned to the application program and no segments are deleted.
4.100 IMS/VS System/Application Design Guide
PHYSICAL DELETE RULE TREATED AS LOGICAL
After the delete routine determines that neither the segment specified in the DLET call nor any physical dependent of that segment in the physical structure has the physical delete rule, any physical rule encountered later (logical deletion propagated to logical child or logical parent causing physical deletion (V rule) in another data base) is treated as LOGICAL.
xxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
x x SEG1 x
x x SEGq x
xPDx SEG8 x
x x
x
x x LP x·
*x x LP x
xxxxxxxxxxxx
xxxxxxxxxxxx lie
lie xxxxxxxxxxxx
x x RULE=L
x RULE=L lie '" RULE=L x
x
lie
x
xxxxxxxxxxxx x x SEG2 x x x LP x*
xxxxxxxxxxxx
'" xPDx SEGS x '" xLDx LC x·
'" xxxxxxxxxxxx '" xPDx SEG9 x "'xLDx LC x
xxxxxxxxxxxx lie
xxxxxxxxxxxx
xxxxxxxxxxxx
V
· lie
x RULE=V
RULE=V
V
· '"
x
vvvvvvvvvvvv '"
'" v
v
SEG3 v VLC v
*
*
'" '" vvvvvvvvvvvv
'" '" lie lie
xxxxxxxxxxxx xPDx SEG6 x
x x PP x RULE=any
xxxxxxxxxxxx x
'" '" x lie lie xxxxxxxxxxxx
'" *xPDx SEG7 x
x x LC x RULE=P
xxxxxxxxxxxx
________ _________ f£~
xxxxxxxxxxxx
x x SEG8 x
x x
x
xxxxxxxxxxxx
GHU 'SEGS' DLET
STATUS=')J}I'
STATUS='l!f)J'
SEG8 and SEG9 are both physically deleted, and SE~9 is logically deleted (V rule). SEG5 is physically and logically deleted because it
is the physical pair to SEG9 (with physical pairing setting the LD bit in one set the PD bit in the other and vice verse). Physically deleting
SEGS causes propagation of the physical delete to SEGS's physical dependents, thus S~G6 and SEG7 are physically deleted. Notice that the
physical delete of SEG7 is prevented if the physical deletion had
started by issuing a DLET call for SEG4. But the physical rule of SEG7 is treated as logical in this case.
INSERTING PHYSICALLY AND/OR LOG!CALLY DELETED SEGMENTS
When a segment is inserted, a replace operation will be performed (that is, space will be reused) and existing dependents of that ~egment remain, provided:
· The segment to be inserted already exists (same segment type and same key field value for both the physical and logical sequencing), and
· The delete bit is set on for that segment along the path of
insertion.
Data Base Design Considerations q. 10'
If the DB organization is HD, the logical twin chain will be established as required, and eXisting dependents of that segment will remain.
If the DB organization is HISAM, and the root segment is physically and logically deleted before the insert is attempted, then the first LRECL for that root in primary and secondary DSGs is reused and remaining LRECLs on any OSA" chain are dropped.
DELETE RULES SU~MARY
A DLET call issued against a concatenated segment (SQURCE=DATA/DATA, DATA/KEY, KEY/DATA) is a DLET call against the logical child only.
A DLET call against a logical child which has been accessed from its logical parent is a request that the logical child be logically deleted.
In all other cases a DLET call issued against a segment is a request for that segment to be physically deleted.
A physically deleted segment cannot be accessed from its physical path with one exception -- if one of the physical parents of the physically deleted segment is a logical child segment which can be accessed from its logical parent, then the physically deleted segment is accessible from that logical child since the physical dependents of a logical child are "variable intersection data."
By definition, a logically deleted logical child cannot be accessed from its logical parent. Unidirectional logical child segments are assumed to be logically deleted.
By definition, a logical parent is considered logically deleted when physical deletion has occured for all of its logical children and for all of its physical children which are part of a physically paired set.
Neither physical nor logical deletion of a segment prevents access to the segment from its physical or logical children, or from the segm~nt to its physical or logical parents. A physically deleted root segment can be accessed only from its physical or logical children.
Pr~U~~9:~!i2!l 21 !l!!l!!!!! In bidirectional physical pa~r~ng, physical deletion of one of the
pair of logical children causes logical deletion of its pair. Likewise, logical deletion of one causes physical deletion of the other.
Physical deletion of a segment propagates logical deletion requests to its bidirectional logical children and propagates physical deletion requests to its physical children and to any index pointer segments for yhich it is the source segment.
4.102 IMS/VS System/Application Design Guide
DELETE RULES Further delete operations are governed by the following delete rules:
~Q~i£~! R~~n!
1. [gI2I£!~: If the segment is not already logically deleted, then a DLET call against the segment or any of its physical parents results in a 'DX' status code and no segments are deleted. If a request is made against the segment as a result of propagation across a logical relationship, then the rule acts like the LOGICAL rule.
2. ~QGI~!~: Either physical or logical deletion can occur first and neither causes the other.
3. !!~IQ!~: Either physical or logical deletion can occur first. If the segment becomes logically deleted as the result of a DLET call, then it will be physically deleted also.
1. PHI~I£!~L~Q~I£!~!IRIll!~: Meaningless. 2~ ~IgIB!£IIQ!!~ !I~ll!~: Whenever all physical children which are
virtually paired logical children are logically deleted, the physical parent segment is physically deleted.
1. ffi!~£!1: If the segment is not already logically deleted, then a DLET call requesting physical deletion of the segment or any of its physical parents results in a 'DX' status code and no segments are deleted. If a delete request is made against the segment as a result of propagation across a logical relationship, or if the segment is one of a physically paired set, then the rule acts like the LOGICAL rule.
2. 1Q~!£!~: Either physical or logical deletion can occur first and neither causes the other.
3. !I~*[!1: Either physical or logical deletion can occur first and either causes the other. If this rule is used on only one segment of a physically paired set, it acts like the LOGICAL rule.
Depending on the data base organization, DASD space mayor may not be reused when it is released. DASD spac~ for a segment is released when the following conditions are met:
· Space has been released for all physical dependents of the segment. · The segment is physically deleted · · If the segment is a logical child or a logical parent, then it must
be physically and logically deleted.
Data Base Design Considerations ~.103
· If the segment is a dependent of a logical child (variable intersection data) and the DLET call was issued against a physical parent of the logical child, then the logical child must be both physically and logically deleted.
· If the segment is a primary index pointer segment, the space must have been released for its target segment.
DEFINING A LOGICAL DATA BASE
To identify which segment types in one or more physical data bases are used in a logical data base, the segment types in the physical data bases are redefined in a logical data base through DBDGEN using SEGK statements. The NAME= operand of the SEGM statement is used to specify the name used for the segment type in the logical data base, and the SOURCE= operand is used to identify which segment type or types in physical data bases are represented by the name specified in the logical data base. On the SOURCE= operand, the user specifies the name of the segment type in a physical data base that is represented in the logical data base through the name specified on the NAKE= operand. Also specified on the SOURCE= operand is the name of the physical data base that contains the segment type being defined in a logical data base. When defining a concatenated segment type in a logical data base, the names of both segment types that comprise th~ concatena+ed segment type, and the name of the physical data base that contains each segment type to be concatenated are specified on the SOURCE= operand.
As in the definition of a physical data base, the hierarchy of segment types in a logical data base is defined through use of the PARENT= operand of the SEGM statement, and through the order in which SEGM statements are presented as input to DBDGEN. The PARENT= operand is used to specify the physical parent segment type of each dependent segment type defined in the logical data base, and the order in which SEGK statements are arranged determines the left to right order of physical child segment types of each physical parent segment type.
1 concatenated segment type is defined in a logical data base to enable use of a logical relationship. When a concatenated segment type is defined in a logical data base, the concatenated segment type enables access to the destination parent in the logical relationship. In addition. subject to rules for defining logical data bases, the concatenated segment type enables crossing a logical relationship to access segments that are in the hierarchic path of the destination parent in the physical data base of the destination parent.
Before the rules for defining logical data bases can be unders~ood, crossing a logical relationship, and the first and additional logical relationships crossed in a hierarchic path of a logical data base must be understood.
A logical relationship is considered crossed when it is used in a logical data base to access a segment that is a physical parent or a physical dependent of a destination parent in the destination parents physical data base. If a logical relationship is used in a logical data base to access a destination parent only, the logical relationship is considered not to be crossed. In Figure 4-34, DBD1 and DBD2 are two physical data bases with a logical relationship defined between them. DBD3 through DBD6 are the four logical data bases that can be defined as a result of the logical relationship between DBD1 and DBD2. If the structure shown for DBD3 is defined as a logical data base, no logical relationships are crossed since no physical parent or physical dependent
4.104 IMS/VS system/Application Design Guide
of a destination parent is included in the logical data base. If DBD4 through DBD6 were defined as logical data bases, a logical relationship is crossed in each case since each logical data base contains a physical parent or a physical aependent of the destination parent.
Physical Data Bases
DBDl
DBD2
DBD3
Logical Data Bases
DBD4
DBDS
DBD6
No crossing
A logical relationship is crossed
Figure 4- 34. Definition of Crossing a Logical Relationship
Multiple logical relationships can be crossed in a hierarchic path of a logical data base. Figure 4-35 shows three physical data bases (DED1, DBD2 and DBD3) in which logical relationships have been defined. Also in the figure are two logical data bases (DBD4 and DBDS) that can be defined as a result of the logical relationships defined in the physical data bases. In DBD4, the two concatenated segment types {BF and DI) that have been defined enable access to all segment types in the hierarchic paths of their respective destination parents. If either logical relationship or both are crossed, each is considered to be the first logical relationship crossed in the hierarchic path of logical data base DBD4 since each concatenated segment type is reached by following the physical hierarchy of segment types in DBD'. In logical data base DBDS, an additional concatenated segment type (GI) has been defined that was not included in DBD4. The additional concatenated segment type GI in DBDS enables access to segments in the hierarchic path of the destination parent if crossed. When the logical relationship enabled by the concatenated segment GI is crossed, this constitutes an additional logical relationship crossed in the hierarchic path of the logical data base since, from the root of the logical data base, the logical relationship enabled by the concatenated segment type
BF must be crossed to enable access to the concat~nated segment type Gr.
Data Base Design Considerations 4.'05
DBDI
Physical Data Bases
DBD2
DBD3
DBD4
Logical Data Bases
DBDS
H
Figure 4-35. The First Logical Relationship Crossed in a Hierarchic Path of a Logical Data Base
When the first logical relationship is crossed in a hierarchic path of a logical data base, access to all segment types in the hierarchic path of the destination parent is enabled as follows:
· Parent segment types of the destination parent are included in the logical data base as dependents of the destination parent in reverse order as shown in Figure 4-36 ·
· Dependent segment types of the destination parent are included in the logical data base as dependents of the destination parent without change in their order as shewn in Figure 4-36.
4.106 IMS/VS System/Application Design Guide
Hierarchic path of physical data base
Resulting"order in the hierarchic path of a logical data base
Figure 4-36. Logical Data Base Hierarchy Enabled by Crossing the First Logical Relationship
When an additional logical relationship is crossed in a hierarchic path of a logical data base, access to all segments in the hierarchic path of the destination parent is enabled as in the first crossing.
1. The root segment type of a logical data base must be the root segment type of a physical data base.
2. A logical data base must be supported by one or more physical data bases. A logical data base must use only those segment types, and physical and/or logical relationship paths that are defined in the physical DBD generation(s) referenced by the logical DBD generation.
3. The path used to connect two segments in a logical data base (that is, a parent and a child) must have been defined as a physical relationship path or a logical relationship path in the physical DBD generation(s) referenced by the logical DBD generation.
4. Physical relationship paths and logical relationship paths may be intermixed in a hierarchical segment path of a logical data base.
5. After a logical relationship has been crossed in a hierarchic path of a logical data base, additional physical relationship paths and/or logical relationship paths may be included by proceeding in an upward and/or downward direction from the destination parent. When proceeding downwards along a physical relationship path from the destination parent, direction may not be changed except by crossing a logical relationship. Whe~ proceeding upwards along a physical relationship path from the destination parent, direction may be changed.
6. Dependents in a logical data base must appear in the same relative order as they appear under their parent in their physical data base. If a segment in a logical data base is a
Data Base Design Considerations 4.107
concatenated segment (that is, a logical child concatenated with either its physical or logical parent), the physical children of each of the concatenated segments may not be intermixed. The relative order of the children of each of the concatenated segments must remain unchanged. 7. Different variations of a concatenated segment type can be defined as physical child segment types of a physical parent segment type, but only one variation can have dependent segment types. Figure 4-37 shows the four variations of a concatenated segment type that can be defined in a logical data base. When multiple variations are defined under a single physical parent segment type. the variation of the concatenated segment type under the physical parent that has dependents must be the left most variation of the concatenated segment type. A PCB for the logical data base can be sensitive to only one variation of the concatenated segment type.
Key: LC- Logical child segment type DP-Destination parent segment type K-KEY sensitivity specified for the segment type
D-DATA sensitivity specified for the segment type
Figure 4-37. Variations of a Concatenated Segment Type Enabled by Specification of KEY and DATA Sensitivity
When only one logical relationship is crossed in a hierarchic segment path of a logical data base to reach a destination parent:
a. All segment types on which the destination parent is dependent in its physical data base can be included in the logical data base as dependents of the destination parent in inverted order.
b. All segment types that are dependent on the destination parent in its physical data base can be included in the logical data base as dependents of the destination parent without change in their order.
c. All segment types that are dependent on any of th~ inverted order segment types defined in (a) can be included without change in their order.
4.108 IKS/VS System/Application Design Guide
Physical Data Base
Logical Data Base can include
A
(DESTINATION
LOGICAL 1----+1 PARENT) CHILD
B
C
o
LOGICAL
CHILD
B
I I IJ
A
C
0
I
I
I
E
z
E
I
I I
G
F
C
Example 1.
Secondary indexes are used to establish alternate entries to physical or logical data bases for application programs. Following are definitions of the terms used for secondary indexing:
· Secondary Index
A secondary index is comprised of an ind~x pointer segment type defined in a secondary index data base that provides an alternate entry into a physical or logical data base.
· Index Pointer Segment Type
A segment type defin~d in a secondary index data base that contains the data and pointers used to index an "index target segment type" in a physical or logical data base (see Figure ~-38).
· Index Target Segment Type
A segment type defined in a physical or logical data base that is pointed to by an index pointer segment type (see Figure 4-38).
· Index Source Segment Type
A segment type that is the source from which a secondary index is created (see Figure 4-38).
· Secondary Processing Sequence
The sequential order in which occurrences of an index target segment type are accessed through a secondary index.
Data Base Design Considerations 4.109
· Secondary Data Structure
The hierarchic order of segm-ent types in a physical or logical data base that results automatically when a data base is accessed through a secondary index.
PHYSICAL OR LOGICAL DATA BASE
SO:CONDARY INDEX DATA BASE
Can be root or dependent segment type.
INDEX TARGET SEGMENT TYPE
INDEX POINTER SEGMENT TYPE
Can be the same segment ---1----1 type as index target segment type. or as shown. a dep endent of the index target
segment type.
INDEX SOURCE SEGMENT TYPE
The content of a specified field or fields in each index source segment is duplic ated in the respective index pointer segment generated
from each index source segment.
Figure 4-38. Segment Types Associated with a Secondary Index
An index target segment type can be the root or a dependent of a physical or logical data base, and an index source segment type can be either the index target segment type itself or any physical dependent of the index target segment type. A secondary index contains one index pointer segment for each occurrence of the index source segment type in a physical or logical data base.. If the same segment type in a data base is used as both the index target and index source segment types, the secondary index contains one index pointer segment that points to each index target segment. If a dependent of an index target segment type is used as the source segment type for a secondary index, the secondary index contains one index pointer segment that points to an index target segment for each source segment that is a dependent of that index target segment as shown in Figure 4-39.
The user specifies through DBDGEN what data within the index source segment type is to be used to index occurrences of the index target segment type. From one to five fields, that can be non-contiguous, within the index source segment type can be specified for use as search da~a in a secondary index. When sp~cified, the content of each field specified is copied in the search field of the respective index pointer segment generated from each source segment.
4.110 IMS/VS System/Application Design Guide
SECONDARY PROCESSING SEQUENCE
Entry to a data base through a secondary index enables access to the index target segment type and all segment types in the hierarchic path of the index target segment type. Through the secondary index, the order in which index target segments are accessed is called their secondary processing sequence. The secondary processing sequence of index target segments is determined by the search field values placed in index pointer segments.
INDEXED DATA BASE
INDEX DATA BASE
CITY
NAM E is index target segment type
NAME ADAMS
NAME
I
JONES
I
g I
I
I
~I Index Source
:
segments
BLUE
RED
YELLOW
/
/
/ Automobile Segment Type used as source for secondary index
NAME SMITH
I
.----'-.....&, BLACK
IREDI~
/'
" "
BLACK
BLUE
RtD
RED
YELLOW
Unless suppressed, one index pointer segment is generated from each index source segment.
used as
search field
for secondary
index
Figure 4-39. Indexing to NAME Segments Based on the Color Field of a Dependent
SECONDARY DATA STRUCTURE
The order in which segment types in the hierarchic path of an index target segment type are accessed is called their secondary data structure. The hierarchic arrangement of segment types for the secondary data structure is created automatically by I~S/VS. To enable use of the secondary data structure, the user must define sensitivity to the segment types in the secondary data structure through PSBGEN.
Figure 4-40 shows a physical data base hierarchy in which a dependent segment type is indexed through a secondary index. Also shown is the secondary data structure for the segment types in the hierarchic path of the index target segment type.
Data Base Design Considerations 4. 1'1
PHYSICAL DATA BASE HIERARCHY
SECDNDARY DATA STRUCTURE HIERARCHY
-INDEX ON SEGMENT TVPE G
Figure 4-40. Secondary Data Structure
The secondary data structure for segment types in a data hasp. is determined as follows:
1. The index target segment type is the root.
2. Parent segment types of the index target segment tYPB in a data base become the left most dependents of the index target segment type in reverse order.
3. All dependents of the index target segment type are included in the secondary data structure without change in their order except when a parent of the index target segment type is included in the secondary data structure as stated in item 2. In this case, dependents of the index target segment type are displaced one position to the right in the secondary data structure.
4. Only those segment types in the hierarchic path of the index target segment type are included in the secondary data structure.
4.112 IHS/VS System/Applicatjon Design Guide
5. When the root segment type of a data base is indexed through a secondary index, the hierarchy of the data base is unchanged for the secondary data structure.
L QE~~2S§ ~S~ Bn!§§ t2£ 2§£2Sg!~I !ng~ing
· A secondary index can be defined for any HDAM or HIDA" data base.
· A secondary index can be defined for any single data set group HISA" data base.
· A secondary index cannot be defined for a multiple da~a set group HISAM data base.
· A secondary index cannot be defined for a HSAM data base.
A secondary index can be defined using:
· Fields in the index source segment type that contain unique or non-unique data for the search field of the secondary index.
· Up to 5 non-contiguous fields in the index source segment type as the search field of a secondary index.
To enable processing a secondary index as a data base itself:
· The user can specify that data in fields of index source segments is to be duplicated in the index pointer segment generated from each index source segment.
· Index pointer segments can contain any additional user data desired.
A secondary index can be used:
· To index selectively or sparsely by using an option and/or exit provided to enable suppressing the creation of index entries for desired index source segments.
· To access segment types in a single hierarchic path of a data base using the index target segment type as the root for all segment types in that path.
· To selectively access a given segment, through data contained in that segment or a dependent of that segment.
· To access a given dependent in an HDAM or RIDAM data base in less time than is normally required through the primary addressing method.
Following are the rules that must be observed in secondary indexing:
1. In a physical data base, a logical child, or a dependent of a
logical child cannot be an index target segment type.
2. You cannot declare a secondary processing sequence on an index if the target is a concatenated segment type or a dependent of a concatenated segment type in a logical data base.
3. When using a secondary processing sequence, you cannot insert or delete an index target segment, or any segment on which an index target segment is dependent in a physical data base.
4. Data in any fields of segments can be changed except for data in sequence fields. If data in fields of an index source segment is
Data Base Design Considerations
changed and those fields are used in the search or subsequence fields of an index pointer segment, the index pointer segment is deleted from the position determined by its old key, and reinserted into the position determined by its new key.
5. If a variable length segment type is used as an ind~x source segment and an attempt is made to insert an occurrence of the segment type whose length does not include any fields or portions of any fields specified for use in the search, subsequence or duplicate data fields of an index pointer segment, one of the following actions occur:
a. If the missing index source segment data is used in the search field of an index pointer segment, generation of the index pointer segment for that source segment is suppressed.
b. If the missing index source segment data is used in the subsequence or duplicate data fields of an index pointer segment, the index pointer segment field will contain one of the three following representations of zero for the missing data (P='OOOF', X=X'OO', or C='O'). The representation used will be the type specified on the FIELD statement that defined th~t index source segment field.
6. When symbolic pointing only is used to point to index target segments from index pointer segments, unique sequence fields must be defined in the index target segment type and all segment types on which the index target segment type is dependent in it's physical data base.
7. DL/I does not assume responsibility for the order of index
pointer segments that contain non-unique keys after a
reorganization of the secondary index.
8. A logical child segment type cannot be used as an index source segment type. However, a dependent of a logical child can be used as an index source segment type.
9. In a logical data base, no qualification on indexed fields is allowed in the SSA for a concatenated s9gment. However, an SSA for any dependent of a concatenated segment can be qualified on an indexed field.
10. The insert rule of FIRST is always followed when entries are adJed to secondary indexes for data base maintenance.
~~sn~~si!Qn 2£ ~~£Qn~s~~ rngg~~ in A~~i!~sII ~iQIsg~
A secondary index is stored using a VSA~ key sequenced data set only if index pointer segment keys are all unique. If not unique, the index is stored in a key sequenced and an entry sequen~ed data set pair. The key sequenced data set is used to store the first occurrence of an index pointer segment with a given key, and the entry sequenced data set is used to store additional index pointer segments that contain the same key. Within both data sets, one logical record is used to store each index pointer segment. When multiple index pOinter segments with the same key are stored in the secondary index data base, a pointer is placed at the beginning of the logical record that contains each to chain them together. In the chain, the key sequenced data set logical record always contains the first index segment with a given key, and it ~oints to one of the duplicates in the entry sequenced data set. The sequence in which logical records that contain duplicates are chained in the entry sequenced data set is determined by the insert rule of FIRST.
4.114 IMS/VS System/Application Design Guide
In~~~ fQin~~ ~~gm~nt f2~m!t
Figure 4-41 shows the structure of an index pointer segment within a VSAM logical record. In a logical record, the optional non-unique pointer is used to chain logical records that contain index pointer segments with duplicate keys. The remaining portion of each logical record contains an index pointer seg.ent.
......---------------- ----------------:1 VSAM logicalrecord
r "".I......--PREFIX-----I.....I..........- - - - - - - - - - DATA -----------I-~.
Pointer to an Index Pointer Segment with a non.unique
key ·
Delete flag
Direct address index target segment pointer··
Constant (Optional)
Search field
Subsequence field (Optional)
Duplicate data field (Optiona\)
Concatenated key of index
···target segment
· Not present if a unique sequence field is defined in the index pointer segment type.
....Not present when symbolic pointing to the index target segment type is specified
.... Present when symbolic pointing to the index target segment type is specified, and the concatenated key is not present in the subsequence or duplicate data fields.
Figure 4-41. VSAM Logical Record and Index Pointer Segment Formats
An index pointer segment is a fixed length segment that contains a prefix and a data portion. The prefix contains a one byte delete flag and a four byte pointer field when the index uses direct address pointers to point to an index target segment. If symbolic pointing is designated in the index data base, the pointer field is omitted from the prefix. The delete flag is used to mark an index pointer segment as being deleted when the respective index source segment from which an index pointer segment was created is deleted. For HDAM and HIDAM data bases, the pointer field contains a direct address pointer that is used in secondary indexes to point to the occurrence of the index target segment type that is indexed by an index pointer segment. Symbolic pOinters may also be specified for HDAM and HID!M data bases if th~ user desires. In a secondary index for a HISAM data base, the concatenated key of the index target segment must be stored in the data portion of the index pointer segment to pOint to the index target segment. The user can specify its position within the data portion by defining the concatenated key as a system related field. ~hen not defined as a system related field, 1M5/VS automatically places the concatenated key in a predetermined position in the index pointer segment as shown in Figure 4-~'.
The data portion of an index pointer segment contains up to four classes of system maintained data: constant, search, subsequence, and duplicate data. Of the four, only search data is required for index pointer segments. Constant, subsequence, and duplicate data are optional.
Three fields and a constant can be defined in an index pointer segment type through an XDFLD statement. The fields defined through an XDFLD statement are called search, subsequence and duplicate data (DDATA) fields. A search, subsequence or duplicate data field in an index pointer segment type is comprised of one to five fields that are defined in the index source segment type through FIELD statements. For each respective field in the index pointer segment type, a list of names
Data Base Design Considerations 4. 115
of one to five fields defined in the index source segment type can be specified for use as that index pOinter segment field. The content of the index source segment fields specified are duplicated in the respective index pointer segment field when each index pointer segment is created. The sequence of field names in a list determines the order in which the fields are stored in the index painter segment field. Names of source segment fields can be specified in any desired order.
In auxiliary storage, the key of an index pointer segment consists of the values in the constant, search field, and subsequence field when all three are specified on an XDFLD statement. Of the three, only the search field is required in each index pointer segment. The constant and subsequence field are optional. When only the ~earch field is specified for an index pointer segment type, the search field contains the entire key of each index pointer segment. When a constant is specified, the key of a~ index pointer segment consists of the constant followed by the search field value. When a subsequence field is specified, the subseque~ce field value is appended to the search field value and it becomes a part of the key of the index pointer segment. The combined length of the constant, search and subsequence fields that make up a key must not exceed 240 bytes.
The use of each field in an index pointer segment is as follows.
When specified, a one byte constant occupies the first byte of the data portion of each occurrence of the index pointer segment type. The constant is used to identify all index pointer segments associated with each secondary index when multiple secondary indexes are defined in the same index data base. The use of the shared index option is described under the heading of "Shared Index Data Bases."
The data in the search field of an index pointer segm~nt is a collection of the data in from one to five index source segment fields. In an index pointer segment, the search field is used as all or a part of the key of that index segment. The search field contains the value(s) in a field or fields of an index source segment on which an index target segment is indexed. This means to the user, the presence of the constant and/or subsequence fields in the keys of index pointer segments are transparent to calls. To process a specific index target segment through a secondary index, the S5A of a call is qualified on the search field value only.
The data in the subsequence field of an index pointer segment is a collection of the data in from one to five index source segment fields. The purpose of the subsequence field is to extend the key of index segments to prevent storing index segments in an overflow data set in cases where search field values are non-unique. Index segments in an overflow data set can degrade performance. One example could be that of indexing a personnel data base segment type by birth data. If the last name of the individual were specified as subsequence data then all segments with identical birth date fields would be stored in alphabetical order by last name in the primary storage data set. This would not necessarily eliminate all synonyms, but most keys would now be unigue. The extension of the index pointer segment key by adding the subsequence field is transparent to the caller since calls are qualified on search field values only.
4. 116 IM5/VS System/Application Design Guide
When the key of an index pointer segment type is comprised of search field values only, index pointer segments with the same search field value are stored in one key sequenced data set logical record, plus the required number of entry sequenced data set logical records. By specifying a subsequence field, the key of index pointer segments is extended. When subsequence field values are unique, multiple occurrences of the index pointer segment type with the same search field value are stored in consecutive logical records in the key sequenced data set. Increased performance results since no searches among the duplicates in the entry sequenced data set are required.
Data in the DDATA field of an index pointer segment is a collection of the data in one to five index source segment fields. When specified, space for its contents is alloted adjacent to the subsequence or search field value in an index pointer segment. The DDATA field is defined to prompt the system to duplicate data contained in index source segments in index pointer segments to enable using that data when a secondary index is processed as a data base itself.
The user can include any additional data desired in index pointer segments by specifying a length for the index pointer segment type that is sufficient to include the additional data. When included, the additional data is available to the user when processing the secondary index as a data base itself. The user should note however, that initial loading of additional data, and maintenance of the additional data when reorganizing an indexed data base maintenance is his responsibility. During reorganization of an indexed data base, the secondary index(s) for that data base are recreated. When each secondary index is recreated, any additional user data that existed in the original secondary index is lost.
System related fields are defined in index source segment types for use in secondary indexing. They are defined using FIELD'statements, and can only be defined for index source segment types. Two types of system related fields can be defined for use in secondary indexing.
The first type of system related field consists of defining a portion or all of the concatenated key of an index source segment as a field within the index source segment. The name of this field can be up to eight characters long, and its name must begin with the three characters
l£K. It may appear in the field list for either subsequence or DDATA
fields defined by the XDFLD statement.
The name of the second type of system related field begins with the three characters l2!. A l2! field is a four byte field that contains an IMS/VS generated value that uniquely identifies a source segment. It may appear only in the subsequence field of an index pointer segment, and may only appear if the index source segment is in an HDAK or HIDA~ data base.
System related fields are defined in the index source segment type, but do not physically exist as fields within that segment type. system related fields are defined in the source segment type for use in the subsequence or DDATA fields of index pointer segments. The subsequence and DDATA fields of the index pOinter segment type are defined through an XDFLD statement. In defining each, the names of up to five fields
Data Base Design Considerations 4.111
defined in the index source segment type can be specified for each on the XDFLD statement.
The ~K or L~! fields are used in the subsequence field of index pointer segments to make their keys more unique. In addition, a L~K field can be used to store portions of the concatenated keys of occurrences of the index source segment type in their respective index pointer segments. This may reduce space requirements where pointing is symbolic and part of the concatenated key is to be used as subsequence data. In a secondary index for a HISAM data base, the concatenated key of each index target segment must be included in its' respective index pOinter segment for use as a symbolic pointer. When not included in the subsequence or DDITA fields of the index pointer segment type used for a H1SIM data base, 18S/VS automatically appends the concatenated key of each index target segment to any data in the subsequence or DOlT A fields of the respective index pointer segment.
Two operands, that can be specified during DBDGEN, can be used to suppress the creation of index pointer segments. The two are the NULLVAL=, and the EXTRTN= operands on the XDFLD statement.
In the NULLVAL= operand, a one byte self-defining term, or the words BLANK or ZERO can be specified. If the NULLVAL operand is specified, all fields in an index source segment that comprise the search field in the index pointer segment are checked to see if each byte within the field(s) contains the specified value. When the field or fields in the index source seg_ent are filled with the specified character, an index pointer segment is not created.
The EXTRTN= operand is used to specify the name of an index maintenance exit routine that is supplied by the user to suppress the creation of selected index entries.
secondary indexing allows specification of a user supplied index maintenance exit routine which can selectively suppress the creation of index segments. The routine enables the user to control the density of a secondary index. One exit routine is allowed for every secondary index or a generalized routine may be written to serve several indexes. For detailed information on index exit maintenance routines, see the
!~~L!~ ~Y2!~~ f£Q~£~~mi~~ R~fe£~~~ ~~~gal.
The name given to the load module used for controlling index maintenance must be the value of the EXTRTN= operand on the XDFLD statement in the DBD generation for the indexed data base.
When an index source segment is inserted, deleted, or replaced in a data hase, DL/I index maintenance keeps the index synchroni~ed with ~he contents of the data base. The action taken depends on the operation being performed: insert, delete, or replace.
When a source segment is inserted, a copy of the proposed indexing segment is constructed during index maintenance. The NULLVAL test and exit routine test are performed on the copy to determine the suppression status of the indexing segment. If no suppression status is indicated, the indexing segment is inserted into the index.
4.118 IMS/VS System/Application Design Guide
When a source segment is deleted, a copy of the alleged existing indexing segment is constructed during index maintenance. The NULLVAL and exit routine tests are performed to determine the suppression status of the indexing segment. If no suppression status is indicated, the matching segment is found in the inde~ and deleted.
If suppression status is indicated for an insert or delete, no further processing is required for that entry.
When a source segment is replaced, an index entry mayor may not be affected. The indexing segment may be replaced or it may be deleted and a new indexing segment inserted. It is also possible that no action is required. The action taken is determined by comparing the constructed copies of the old and new indexing segments. The following describes the action to be taken:
· If no suppression is indicated for either segment and:
there is no change to indexing, segment, no action is taken.
only tha data in the indexing segment is changed, the indexing segment is replaced·
· the key in the indexing segment is changed, the old segment is
deleted and a new segment is inserted ·
· If suppression is indicated :
for the old indexing segment but not the new, the new indexing segment is inserted.
for the new indexing segment but not the old, the old indexing segment is deleted.
for both the old and new indexing segment, no action is taken.
The question asked by the DL/I index maintenance routine when it invokes the user index exit routine is, "Will this index pointer segment appear in the index?" The exit routine answers the question through a return code.
Suppression of indexing by the exit routine must be consistent. The same inde~ pointer segment cannot be examined at two different times and have suppression indicated only once. Also, user data cannot be used to evaluate suppression, since the actual index pointer segment is only seen by the exit routine just before insertion of the new one. In the cases of replace and delete, only a prototype is passed which contains the constant, search data, subsequence data, and source data, plus any symbolic pointer which may have been added.
Multiple secondary indexes can be placed in a single shared index data base. A shared index data base is created, accessed, and maintained in the same manner as a data base containing only one secondary index. To be eligible for combining, all indexes must be comprised of segments of equal length, with key fields of equal length, and with equal key offset positions. A maximum of 16 indexes can share a single shared index data base. Each secondary index in a shared index data base must have a constant specified which uniquely identifies that index. The advantage of a shared index data base is a reduction in the number of control blocks for VSAM and DL/I.
Data Base Design Considerations 4. 119
A secondary index can be processed as a data base by providing a PCB which references the DBD of the secondary index. The purpose of
processing a secondary index as a data base could be to scan -the subsequence or duplicate data fields, to perform logical comparisons or data reduction between two or more indexes, or to add to or change the
user maintained data area. Whatever the purpose of processing a secondary index separately, the following guidelines and restrictions apply:
· No changes to system-maintained data fields in the index pointer
segment will be allowed unless ACCESS=("NOPROT) is specified in the index DBD. Attempts to change system maintained data without the NOPROT option specified will result in an AK status code.
· Inserts will not be permitted to any data base in which ACCESS=INDEX is specified
· Any changes to system-maintained data in an index may render the
index as unuseable and unmaintainable.
· Deletion of index entries by the user when the associated index
source segments exist will result in NE status codes if the user
makes updates to the index source segment which will result in index
maintenance.
·
· Qualification on the key of index pointer segments in SSA's must supply a value which includes not only the search portion of the
key, but also the constant and subsequence data if supplied. This
is the only case in secondary indexing that the user is aware of the constant and subsequence data in the key.
· In processing a secondary index which is a member of a shared index data base, the secondary index is regarded as a separate index data base. A series of GN calls will not violate the boundaries of the
secondary index for which they are intended. Each secondary index in the shared index data base has its unique DBD name and root
segment name.
SSAs of calls for index target segments can be qualified on the search field of one or more secondary indexes when accessing index target segments through their primary or secondary processing sequence. This is accomplished by using indexed fields defined within the index target segment type to qualify SSAs. An indexed field is defined in name only for an index target segment type. During DBDGEN, one indexed field is defined in the index target segment type for each secondary index that points to that segment type. The name specified for the indexed field actually represents the search field of the associated secondary index. Since the name specified for the indexed field of an index target segment type represents the search field of a secondary index, when an 55A is qualified on the indexed field of an index target segmen~, the search field of the associated secondary index is searched to satisfy the call. Qualifying calls on the search field of a secondary index is allowed when processing the data base through the secondary index. It is also allowed when the secondary index is specified in the INDICES operand of the SENSEG statement during PSBGEN. Otherwise, qualifying calls on the search field of a secondary index is not permitted.
When a secondary index is searched to see if an index poin~er segment satisfies a call, the call is satisfied when an index pointer segment contains th~ specified search field value and points to the index target segment under consideration.
4.120 IMS/VS System/Application Design Guide
In cases where index source segments are several levels below index
target segments, qualifying calls on the search field of a secondary
index can prove to be an efficient means of selecting index target
L
segments based on data in index source segments. In no case should this use be made of a secondary index when the index target segments and
index source segments are the same segment type, and the indexed data
base is being processed through its primary processing sequence. Even
where the index target and irtdex source segment types are differeRt, the
following guideline should be used. The method should be chosen which
causes the fewest accesses to the data base or index.
In using secondary indexing, consideration should be given to the following:
· When an index source segment is inserted into or deleted from a data base, a respective index pointer segment is inserted into or deleted from the respective secondary index. This maintenance occurs in all cases, regardless of whether or not the application program doing the updating actually uses the secondary index.
· When replacing data in a source segment that is used in the search, subsequence or ddata fields of an index, the index is updated by IMS/VS to reflect the change. When data used in the ddata field of an index pointer segment is replaced in a source segment, the index pointer segment is updated with the new data. When data used in the search or subsequence fields of an index pointer segment is replaced in a source segment, the index pointer segment is updated with the new data, and in addition, the position of the index pointer segment within the secondary index is changed. The position is changed since a changp. to the content of the search or subsequence field of an index pointer segment changes the key of that segment. The secondary index is updated by deleting the segment from the position determined by the old key and re-inserting the index pointer segment in the position determined by the new key.
· The use of secondary indexes viII increase storage requirements of all steps which include within the PSB: 1) a PCB for the indexed data base, and 2) the processing option which allows the index source segment to be updated. The additional storage requirements for each index data base will range from 6K to 10K. A percentage of this additional storage will be fixed in real memory by VSAM. For add~tional information on storage requirements, refer to the topiC "IMS/VS Data Base Buffer Pools" the storage estimates chapter of the IMS/VS system Programming Reference Manual.
· The use of a secondary index must be considered relative to alternate means of achieving the same function. As an example, it may be desired to produce a report from an HDAM data base in root key sequence. A secondary index vill conveniently provide this capability. However, the access of each sequential root will, in most cases, be a random operation. It would be a very time consuming operation to fully scan a large data base where Poach root access is random. It may be more efficient to scan the data base in physical sequence (GET NEXT not using a secondary index), and then sort the results by root key so that the final report can be produced in root key sequence.
· A secondary index uses a key sequenced data set only if all index pOinter segment keys are unique, and a key sequenced and entry sequenced data set when index pointer segment keys are non-unique. Whenever possible, the data used for keys should be unique to eliminate the need for the entry sequenced data set, which in turn,
Data Base Design Considerations
eliminates the additional I/O operations required to search tbe
entry sequenced data set.
· When calls for an index target segment type are qualified on tbe search field of a secondary index, and the indexed data base is not being processed through the secondary index, additional I/O operations are required since the ind~x must be accessed each time an occurrence of the index target segment type is inspected to see if that occurrence satisfies the call. Since the data contained in the search field of a secondary index is a duplication of data in a source segment, the user should determine whether or not an inspection of source segments in their da~a base might yield the same result faster.
Variable length segments enable the user to vary the amount of storage space used to store different occurrences of the same segment type. They are intended for use by application programs that process variable length text or descriptive data. In addition in some cases, they can be used to enhance utilization of secondary storage. Variable length segments enable the user to vary the space used for each occurrence of a segment type between a minimum and maximum number of bytes through a two byte size field loaded with each occurrence.
Variable length segments can be used in HISAM, HDAM and HIDAM data bases when VSAM is specified as the access method for the data base. To use variable length segments, a segment type must be defined as variable in length when defining the segment type through the D~DGEN utility. The variable length of a segment type is specified using the BYTES= keyword of a SEGM statement as shown in Figure 4-42. ~AXBYTES specifies the maximum length used for the data portion of occurrences of a segment type and MINBYTES specifies the minimum length used. In addition, the user must include a two byte size field in the first two bytes of the data portion of each occurrence of that segment type when loading it into the data base. The size field is loaded with each segment to tell 1MS/1S the length of datu in that segment. Since the size field is in the data portion of a segment, the data length placed in the size field must include the length of the size field itself. In addition, if a sequence field is defined in the segment type, the minimum length specified in the size field must include at least the size field and all data to the end cf the sequence field.
When initially loading occurrences of a variable length segment type, the space used to store the data portion of an occurrence is the length specified in MINBYTES or the length specified in the size field, whichever, is greater. When MINBYTES is greater than the length specified in the size field of an occurrence. more space is allocated for the segment than is required for the segment. The additional space allocated is free space that can be used when existing data in the segment is replaced with data that is greater in length.
4.122 IMS/VS System/Application Design Guide
SEGM NAME=SEGNAME, BYTES=(MAXBYTES, MINBYTES)
SPACE ALLOCATED FOR SEGMENT CAN
VARY FROM MINBYTES TO MAXBYTES
"'" MAXBYTES
MINBYTES*
~I
DATA LENGTH INCLUDES LENGTH OF SIZE FIELD
SIZE
SEQUENCE
..J FIELD
FIELD
'--_*_----I_ _ _ _ _ _-L..._ _ _~ _ _ _ _ _
CONCATENATED SEGMENT
LOGICAL CI'IILD SEGMENT
LOGICAL
J
SIZE PARENT
.FIELD CONCATENATiD KEY
MINBYTES
IpHYSICAL: TWIN SEQ.
IFIELD I
I LOGICAL I I TWIN I I SEQUHJCE
FIELD I
~I
l
SIZE FIELD
LOGICAL PARENT _ SEGMENT
l I
ISEQ. IFIELD I
I---MINBYTES--1
LOGICAL CHILD SEGMENT IN PHYSICAL DATA BASE
*MINBYTES MUST BE;;;' 4 BYTES AND MUST INCLUDE: 1. PHYSICAL TWIN SEQUENCE FIELD, IF PRESENT,
AND KEY COMPRESSION IS NOT ENABLED BY A
SEGMENT EDIT/COMPRESSION ROUTINE.
2. LOGICAL PARENT CONCATENATED KEY. 3. LOGICAL TWIN SEQUENCE FIELD, IF PRESENT.
Figure 4-42. Variable Length Segments
Variable length segment formats are shown in Figure 4-43. Fixea length and variable length segment formats are the same except for a size field placed in the data portion of a variable length segment. In addition for HDAM and HIDAH data bases, when the prefix and data portions of a segment are separated in storage du~ to update activitiy, the first four bytes of space following the prefix are used for a direct address pointer to the separated data portion of the segment.
The user can load segments initially with a given number of bytes of data, and then either increase or decrease the length of data in each by replacing the data. When the length of data in an existing segment in a HISAM data base is increased, the logical record containing the segment is rewritten to acquire the additional space required. Any segments displaced through the increased data length are placed in overflow storage. When the length of data in an existing segment in a HISAM data base is decreased, the logical record is rewritten to make all segments contiguous within the logical record. When the data in an existing segment in an HDAM or HIDAM data base is replaced with data that is greater in length and the space allocated for the existing segment is not sufficient for the new data, the prefix and data por~ions of the segment are separated in storage to obtain sufficient space for the new
Data Base Design Considerations 4.123
data. When separated, a pointer is placed in the first four bytes of space following the prefix, which remains in its original position, to point to the new data portion of the segment. When separated and existing data is replaced with data that fits into the original space allocated for the data portion of the segment, the new data portion is placed in the original space allocated overlaying the data pOinter. When the prefix and data portions of a segment are not separated, and
data in an existing segment in an BDAK or HIDAK data base is replaced with data that is shorter in length, the new data followed by free space occupies the position of the original data.
HISAM, OR HDAM AND HIDAM WHEN PREFIX AND DATA ARE NOT SEPARATED
PREFIX
I I
M~
I """'SE-G-M-E-N-T--r-D-E-L-E-T-E"""'T--PO-NI-T-E-R-<~f-N-D-C-O-U-N-T-E-R-r-SI-Z-E--r--V-A-R-IA-B: LENGTH
CODE
BYTE
AREA
FIELD DATA
~---~---~----i'l J ~-----L--~----<
HDAM AND HIDAM WHEN PREFIX AND DATA ARE SEPARATED PREFIX
SEGMENT CODE
DELETE BYTE
POINTER AND COUNTER AREA
DATA POINTER
FREE SPACE
PREFIX
DATA
CODE
DELETE SIZE
BYTE
FIELD
VARIABLE LENGTH DATA
Figure 4-43. Variable Length Segment Formats
CONSIDERATIONS
For BISAK data bases, replacing existing data in segments with data that is greater in length can affect performance since this may require displacing segments to overflow logical records. Replacing data in an existing segment in a HISAM data base with data that is shorter in length has no affect on performance. The additional overhead required to use variable length segments in a HISAM data base consists only of the two byte size field loaded with each occurrence.
Additional storage requirements in HDAM and HlDAM data bases when variable length segments are initially loaded consists of the two byte size field in the data portion. In addition when the prefix and data portions of a segment are separated in storage, a one byte segment code and one byte delete byte are stored with the data portion of the segment. Performance can be affected when the prefix and data portions of segments are separated and stored in different blocks in a data set.
4.124 IKS/VS System/Application Design Guide
CONVERSION CONSIDERATIONS
When a segment type has been defined as variable in length, before initially loading or inserting any occurrence of that segment type into its data base, a size field must be present. To convert an existing data base from fixed length to variable length segments, a size field must be added to each segment before it can be loaded or inserted into a data base as a variable length segment.
The user must supply his own routine to convert an existing data base from fixed length to variable length segments. For the new data base, a new DBD must be created that identifies the variable length segment types. The routine could then sequentially retrieve segments from the existing data base, add the size field to variable length segments, and then insert the segments into the new data base.
A second method of converting from fixed length to variable length segments enables use of the IMS/VS Unload/Reload utilities; however, this method requires that an interim DBD be created. The interim DBD is required to enable a user routine to place a size field in fixea length segments before they can be loaded into a data base as variable length segments.
For the interim DBD, the user specifies a fixed length for the segment type that is being converted to variable length. In addition, the user specifies use of the segment edit/compression exit for that segment type. Using the reload utility, each time an occurrence of the segment type is presented to an IMS/VS action module for loading, the segment edit/compression exit enables a user routine to gain control to add a size field to the segment. After the size field is added, the user routine passes control back to the action module which then loads the segment into the data base. After the data base is reloaded by the reload utility, the user then creates a new DBD to define the variable length of the segment types converted.
The segment edit/compression exit facility of IMS/VS enables the user to supply a routine to edit a segment during its movement between the application program input/output area and the data base buffer pool. The facility offers the user the ability to encode data for security purposes, to format data to be used by application programs, and to compress a segment to eliminate redundant characters. The edit/compression routine should be transparent to the application programs.
The routine to be used for edit/compression is named by the operand COMPRTN= routine-name on the SEGM statement in the DBDGEN operation for the data base. A segment work area is constructed by IMS/VS at initialization time, and the edit routine is loaded when the data base is opened. As a segment from that data base is requested by the user, its location in the buffer pool is obtained. If an edit routine has been specified, the address of the data portion of the segment, and the start of the segment work area is supplied and the routine is given control. On a retrieve operation, the edit routine is responsible for moving the data from the buffer pool to the segment work area. IMS/VS will move it from the segment work area to the application program I/O area. For load, insert, or replace operations, data is moved from the application program I/O area to the segment work area by the edit routine, then to the buffer pool by IMS/VS. See Figure 4-44 for a visual explanation of segment edit/compression.
Data Base Design Considerations 4.125
RETRIEVE
g
cr:
-----.J"SiZEf= 0..
o Z
AINRPEUAT
LflHQ USER DATA
~ ~
Il:
- - - - - - - - - - -c{ - -
LOAD/INSERT/REPLACE
OUTPU~iYE-1
AREA
I FIELD.
USER DATA
(SOURCE)
- - ' - - . . . , . . . . - - - -....
USER--~
IMS
oCcr!:l
0..
SEGMENT WORK
o..J
cr:
~rsiZE AREA
-rI--U-S-ER-DA-T-A--'
f
oZ
(.)
~~~D~_ _ _ _~
ROUTINE
SEGMENT WORK AREA
EDIT ROUTINE
USER
ROUTINE
EDIT
ROUTINE
IMS
BUFFER POOL
SOURCE
BUF~rO_L_____t-______--,
lSIZE I
I FIELD
EDITED
I
USER DATA
Figure 4-44. Segment Edit/Compression
To assist the user in providing parameters to his edit/compression routine, the DBD control block has a table appended to it in the form of assembly language control sections. One control section is developed for each segment type to be edited or compressed. These control sections contain information such as the edit/compression routine name, the name of the segment, and the total length of that control section. Each control section may be extended by the user to contain any desired data or algorithm information.
Although the segments may be defined as fixed or variable length to the application program, the segments to be processed by the edit/compression routine must be variable length in the data base. The data length is contained in a size field in the first two bytes of the segment. If the segment is defined as fixed length to the application program, the size field must be stripped off by the edit/compression routine before the segment is pres.nted to the application program. In addition, if the segment vas compressed, it must be expanded by the edit routine to the fixed length expected by the application program. In reverse, if the application program presents a fixed length segment, the edit/compression routine must append the si~e field prior to the segment being written to the data base. If the edit/compression routine compresses the segment, the size field must be updated to reflect the correct length.
4. 126 IMS/VS System/Application Design Guide
To convert existing data bases to use this facility, the following steps must be performed:
1. Unload the current data base using the reorganization/unload utility and using the current DBD.
2. Define a new OED which specifies VSAM as the access method and specifies a COMPRTN for those segments which are to pe converted. Reload the data with the reorganization/reload utility.
3. The named COMPRTN provided during reload should encode, compress or edit the segment (as determined by the installation's requirements) and add the two byte size field.
There are two types of segment manipulation possible through the DL/! edit/compression facility:
~~i~ ~Q~E~~§§~Qn -- movement or compression of data within a segment in a manner that does not alter the content or position of the key field. Typically, this type involves compression or encoding of data from the end of the key field to the end of the segment. This is the only time that the location of the fields may be altered. The segment size field of a variable length segment cannot be compressed.
~2Y ~QmE[222!Qn -- movement o~ compression of any data within a segment in a manner that can change the relative position, value, or length of the sequence field as well as any other fields.
Any segment type in a physical data base can be specified during DBDGEN as being compressible with either the KEY or DATA option, with the following exceptions:
· Any segment type which is defined as a logical child may not be
specified
· Segments residing in an INDEX data base may not be specified
· segments defined as root segments of a HISAM data base may be
specified for DATA compression only
Although the contents of the sequence field or the data may be modified by the edit/compression routine, the segment's position in the data base is determined by the original sequence field value. An example may help tv explain this. If the defined sequence of a particular segment type is based on last names, and the data base contains segments for people named SMITH, JONES, and BROWN, the segments are maintained in alphabetical sequence -- BROWN, JONES, SMITH. Assume that an edit routine encodes these names as follows:
BROWN-------->29665
JONES-------->16552
SMITH-------->24938
The encoded value is placed in the sequence field. The segments will be maintained in the original sequence (BROWN, JONES, SMITH) rather than in the numerical sequence impli~d by the encoded values (16552, 24938, 29665). The records are maintained in the originally defined sequence so that if the application program issues a GET NEXT request, the correct segment is retrieved. This also applies to secondary index fields contained in index source segments involved in secondary indexing.
Data Base Design Considerations 4.121
COISIDBRAUOIS
General conside~ations which apply to using the segaeat edit/coapression exit facility are:
· Any segllent specified to be edited aust reside ia a lSI! data set
· All segaeat editing takes place OD segaents described io a physical data base oaly
· If the user routine is designed to edit aore than one segllent type. in one or more phfsical data bases,. the routine lIust be link-edited as reentrant
· Adequate storage for the edit routine(s) lIust be proyided for both batch and online systems
· Since this lIodule beco.es a part of the I!!S/YS region,. .any abnor.al terllinatioD on its part terainates the entire I8S/IS region
· The user routine cannot eaploy such operating Systell aacros as SPtB and STAB
The segllent edit/co. pression exit prowides the user with a yaluable tool. Howeyer. seTeral additional considerations are worth noting. Edit/compression processing of each segaent OD its way to or froll an application prograa inyolyes added CPU tiae. In addition, the search time required to locate the requested segaent aay be increased, depending upon the options selected. In the case of full segaent compressioD, using the KEY compression option. eyery segment type that is a candidate to satisf, either a fully qualified key or data field request must be expanded or decoded to allow exallin&tion of the appropriate field by the I~S/YS retrieve aodule. For key field qualification, only those fields froa the start of the segaent through the sequence field are expanded during the search. For data field qualification. the total segllent is expanded. In the case of data compression and a key field request, little more processing is required to locate the segment than that of non-compressed segments, since only tae segment. sequence field is used to deteraine if this segaent occurrence satisfies the qualification.
Other considerations can iapact. total syst.em performance, especially in an online teleprocessing enyironaent. For example, being able to LOID an algorithm table into mellorr viII giYe the compression routine a large amount of flexibility. However, this action can place the entire I!S control region into a wait state until the requested member is present in main storage. It is suggested that all alternatives be explored to lessen the impact of situations such as this.
Q!I! i~ ~~! CONSIDEB1TIORS
HIERARCHICAL SEQUENTIAL DESIGN CONSIDERATIONS
This section discusses the various data base design considerations with which programaing personnel shoyld be familiar to get the best use from the capabilities of the I!S/VS Hierarchic Sequential data base organization and in particular the HISAH data base access aethod.
4.128 IMS/VS System/Application Design Guide
PROCESSING TIME
Before performing I/O operations, I!S/VS uses information within its internal data base tables. and data base buffers in an attempt at satisfying segment requests. If no information is found in main storage, the index and the necessary primary data set record are read from auxiliary storage. In accessing a segment of information, a VSAM or ISA! index is used to obtain the root segment of the specified record. Dependent segments of that root are reached in a sequential manner. If the information is not found in a primary data set record, a pointer in the primary data set logical record causes a read to be performed on an overflow record.
I
I
171
VSAM or ISAM INDEX
A
17
B
104
c IB I
32 : 108 LRECL
POINTER
'"
Primary Data Set Logical Record
B
121
o
61
E
42
POUlTER *
Overflow Data Set Logical Records
F
181
193
E
51 lRECl.
10 G
1
I ;
26
I I I I
Overflow Data Set Logical Records
* The pointer is at the beginning of VSAM logical records
Figure 4-45. HISAM Data Base Record in Auxiliary Storage
The first solution to reduce the number of direct access refer~nces (and hence processing time) is to increase the size of the primary data set logical record length, thus eliminating the need for overflow records.
Data Base Design Considerations 4.129
ISAM INDEX
(
B C
B
1I
E
32 108 ql 121 61 42
F E 193 51
G 0 26
Primary Data Set
Logical Record
(NO OVERFLOW RECORD REQUIRED)
Figure 4-46,. HISAM Data Base Becord -- Larger Primary Data Set Logical Record
The segment which is logically farthest from the root in the top to bottom, left to right, hierarchy, is also physically farther from the root when the segment is stored. This indicates that the logical structure may be manipulated to reduce the number of direct access references required to obtain a particular segment.
4.130 IMS/VS System/Application Design Guide
A
L
I
17j
I
I
I
L
I
121
61
B 10Sf=
~
104 Ff""
-.Jl
E 51
iL;?'
I
!
I I
1 1
G
F 181 ,.1..3..
26
I
I
,
I
c~
32
A
D
I
E
I
F
I
?OIN1ER Primary Data Set
17
61
!iZ
I
I
181
*
Logical Record
ISAl'1 LrtE.CL
F
E
G
B
FCINTER OVerflow Data Set
L
193
51
26
104
*
Logical Records
OSAH LRECL
C
B
r
"
B 0
32
108
41
121
OS"" LRE.CL
Overflow Data Set Logical Records
* The pointer is at the beginning of VSAM logical records
Figure 4-47. Storage Sequence of Segments in HISA~ Data ~ase Record
Another solution is the use of multiple data set groups. This allows second-level segments and their dependent segments to be accessed through an index with no need to access the root or intervening segments. The maximum number of data set groups for a data base is ten. The use of multiple data set groups is allowed for a HISAM data base only if ISAM/OSAM is the access method. See Figure 4-48.
Data Base Design Considerations 4. 131
TWO DAIA SET GROUPS: 1. PRIMARY DATA SET GROUP
A. B. CSEGMENTS 2. SECONDARY DATA SET GROUP
D. E. F. GSEGMENTS
Primary Data Set
rJPrimary Data Set
Overflow Data Set
~ "
Secondary
Data Set Group
/
~ ~
/ ~ /
' ,,
"
' "
,I,
/
I
E G
Figure 4-48. HISAM -- Multiple Data Set Groups (ISAK/OSAM only)
AS can be seen, segments in the secondary data set group can be retrieved without reference to the primary data set group.
Figure 4-48 shows that segments D, E, F, and G are placed into a secondary data set group. Figure 4-49 shows that, because no references to the primary data set group are necessary, the number of references needed to obtain Segment F with key 1B1 has been reduced. Note that the index in both data set groups contains the key value of the root seglllent.
4.132 IMS/VS system/Application Design Guide
PRIMARY DATA SET GROUP
L
117 r
ISAM Index
A
B
C
17
104
32
Primary LRECL
C 41
I
I I
I
I
B
121
I0 I
Overflow LRECL
B POINTER
108
SECONDARY DATA SET GROUP
ISAM INDEX
D
E
F
17
61
42
181
Primary LRECL
E
51
G
I
I
I I
0
26
I
I
Overflow LRECL
F
193
POINTER
Figure 4-49. HISAIi Segment Storage -- Multiple Data Set Groups
With multiple data set groups, we may also elect to expand the size of the logical record of the secondary data set group as shown in Figure 4-50. In this case, no overflow logical record would be required. Logical record sizes of data set groups representing a single data base may vary. In addition, the logical record length of each primary data set and of its associated overflow data set in ~he same data set group may be equal, or the overflow logical record length may be greater than the primary logical record length.
Data Base Design Considerations 4.133
SECl»lDARY DATA SET &ROUP
Figure 4-50. HISAM Secondary Data Set Group with a Larger Primary Data Set Logical Record Length
In summary: · Logical record size can be expanded to accommodate more segments,
thus eliminating or minimizing the need for overflow records. · The logical structure can be manipulated to bring the most active
segment types hierarchically closer to the root. · Multiple data set groups can be used to avoid accessing a root
segment and intervening dependent segments when accessing a
particular segment type.
· The logical record length of primary and overflow data sets across data set groups may vary. The logical record length of an overflow data set must be equal to or greater than the primary logical record length in the same data set group.
DIRECT ACCESS STORAGE SPACE UTILIZATION The percentage of utilization of direct access storage d~vice space
by an 185/VS data base at load time is a function of the relationship between the logical record lengths and the size of the actual data base records being loaded. Data base records within a data base usually vary in size, but, since IMS/VS uses fixed-length logical records, the choice of a logical record length to contain the largest data base record results in unused space for the smaller data base records. Choice of a logical record length to hold the smaller data base records results in better space utilization in the primary data set, but parts of larger data base records are forced to the overflow data set on initial loading.
The choice of a logical record length must be made with appropriate consideration for the type of processing to be accomplished against the data base. For example, if Dew dependent segments are being created with great frequency. it may be a good idea to assign an oversized logical record length. This logical record length allows many dependent segments to be placed in the primary data set. Figure 4-51 shows what happens if a small logical record length is chosen for two records - Record 1 and Record 2. Two overflow records are required, and there is very little slack space.
4.134 I8S/VS System/Application Design Guide
DATA BASE RECORDS
L
osl IlCORD 1 ROOT
DEPI DEP2 DEP3
IlCORD 2
-------+1:1 II++---- lRECl--B'lK.SIIZ4EI~--lRECl--"
primary
Overflow
Overflow
Figure 4-51. HISAK -- Small Logical Record Length Figure 4-52 shows the same records with a large primary data set
logical record length. There is no requirement for overflow records, but there may be a large amount of slack space in primary data set logical records. All unused space in the primary data set is tied to specific roots.
Data Base Design Considerations
DATA BASE RECORDS
RECORD 1 ROOT osl DEPl DEP2 DEP5 DEpq
J
RECORD 2 ROOT ll\ DEPl
14
LRECL
·1
I I RECORD 3. ROOT OS\ DEPl DEP2 DEP3 DEPq
14
LRECL
·1
RECORD 2 [ ROOT 111 DEPl 14
SLACk
-I
NO OVERFLOW REQUIRED FOR THESE TWO RECORDS
Figure 4-52. HISA!! -- Large Logical Record Length
The slack space in Figure 4-53 can only be used by dependent segments of Root 24. New dependent segments of Root 18 would have to be put into
overflow, even though the slack space related to Root 24 is not being used and is in the same physical block·
...- - - - l A E C l - - -··~.I. - - - - LAECL---".
I
ROOT DE?l DEP2 DEP3 : ROOT _SLACK
18
:I 211
Primary Data Set Block
Figure 4-53. HISAM -- Utilizing Slack Space
Segmentation also influences utilization of direct access storage device space. See Figure 4-54. The minimum logical record length which
can be assigned for the primary data set of the data base must be large enough to hold the root segment defined for the data base; the minimum
logical record length which can be assigned for the overflow data set of the data base must be large enough to hold the largest segment defined for the data base. The following describes two different methods of segmenting for a 2000-byte record: Case A, where the ROOT and DEP'
segments are combined into one 1500-byte segment, yields a minimum logical record of 1500 bytes and produces 1000 bytes of slack in a OSAM record. This slack is only available for dependent segments which relate to a particular root. The logical record sizes for overflow must be at least as large as the primary logical records. The different method of segmenting the same record in Case B, where the ROOT and DEP' segments are separate segments, yields a minimum logical record size of
'000 bytes, with no excess in the overflow record.
4.136 IMS/VS System/Application Design Guide
ASSU:~E: DATA BASE RECORDS OF 2000 BYTES
L
SEGMENTATION: 1
I CASE A ROOTDEP1
11J:V;"V"!
2080
!
DEP2 i
1
! CASE B ROOT
lOI)Q
1500
2(,80
I I DEFI
DEP2
FOR CASE A THE MINHiUt-l LRECL is 1500 BYTES
-JI 1
l~O
I~_R_OO_T_DE_P_I______________________
PRIMARY
1
SOO
1500
I !. . DEP2
------SlP.CK -------~3 OVERFLOW
FOR CASE B THE MlimillJ1 lRF.Cl IS lOCO BYTES
I1 ROOT
1000
I PRH1ARY
1
I DE?l
500
lono
I I DEP2
OVERFLOW
Figure 4-54. Data Base Record Se glD'!'!ntation Options
Since the sizes of logical records in data set groups will probably be different, multiple data set groups can also be used for hetter utilization of DASD space provided that ISAM/OSA~ is the access method. Figure 4-55 shows a data base record for a single data set group with segments of considerably different sizes. The primary logical record size is 225 bytes; the overflow logical record size is 1500 bytes. Initially, no slack remains in the primary or overflow records. However, this choice of logical record size may leave 1450 by~es of
slack in the overflow record when a new root is inserted after the initial load. This slack space will remain until other inserts cause the space to be used.
Data Base Design Considerations 4.137
I
100 BYTES DEP1
J
75 BYTES DEP2
fO)T SO BYTES
J
1
DEP3 1500 BYTES
SINGLE DATA SET GROUP
14
LRECL 225 BYTES
..I
I PRIMARY
ROOT
DEPl
I DEP2
I
j.-so-+l..
100
.. j..-75
--I
I
I..
LRECL 1500 BYTES
~
I OVERFLOW
DEP3
I
I..
1500
--I
Figure 4-55. HISA~ Single Data Set Group Segmentation
Figure 4-56 shows the same record as Figure 4-55, except that multiple data set groups are used. The primary data set group has a primary and overflow logical record size of 225 bytes. The secondary data set group has a primary and overflow logical record size of 1500 bytes. There is no slack space, and no overflow records in the overflow data set are used during initial load. After initial load, new segments can make optimal use of space in each of the different size overflow records of the two data set groups.
4.138 IMS/VS System/Application Design Guide
I
100 BYTES DEP1
I
75 BYTES DEP2
ROOT SO BYTES
I I
DEP3 1500 BYTES
MULTIPLE DATA SET GROUP
PRlrlARY DSG
14
I PRH1ARY
ROOT
1+-50
LRECL 1500
~I
DEP1
DEP2
.14 100-+1+-75---+1
SECONDARY DSG
14
LRECL SOO
~I
I
PRIi1ARY
DEP3
Figure 4-56. HISAM Multiple Data Set Group segmentation
The reader should remember that the logical record length of the overflow data set within a data set group must be equal to or greater than the logical record length of the primary data set. Also, the primary logical record length must accommodate the root segment, and the overflow logical record length must accommodate the largest segment in the data base. For secondary data set groups, the minimum logical record length must be expanded by the amount necessary to append sequence field keys of the root segment type upon occurrences of the first segment type defined in the secondary data set group.
Both primary and overflow logical records can be blocked one or multiple logical records to a physical block.
Data Base Design Considerations 4.139
DESIGN TRADEOFFS A review of the logical and physical structures supported by IMS/VS
is recommended. The IMS/VS Hierarchical sequential organization supports the
Hierarchical Sequential and the Hierarchical Indexed Sequential Access Methods (HSAM and HISAK). H5AM is based on BSAM and QSAKi HISAK, on VSAM or 15AM with an EXCP extension named OSA! (Overflow Sequential Access Method). The following discussion is based on HISAM.
In Figure 4-57. each block represents a segment type. with the bloCK at the top referred to as the root segment (A). The other segments, B, C. and D, are dependent segments. Root segment A is also level one, segments Band C are level two. and segment D is level three.
1-255 SEGMENT TYPES 1-15 LEVELS 1 ROOT SEGMENT PER DATA BASE RECORD
o TO N DEPENDENT SEGMENTS PER PARENT
1 TO N SEGMENTS PER DATA BASE RECORD 1 TO N DATA BASE RECORDS PER DATA BASE Figure 4-57. Data Base structure Rules
The principal reason for the existence of dependent segments is that they give the user the ability (by variable-le~gth records and dependent segments) to take care of information which it would otherwise be necessary to repeat from 0 to n times.
Figure 4-58 shows the physical order of storage -- top to bottom a~d left to right. As shown, this data base record begins in the primary data set and requires two additional logical records in the overflow data set. The two overflow records can be blocked within one overflow physical block. The technique of pointing from one record to another allows data base records within a data base to vary considerably in length. but for all practical purposes their size is unlimited.
4.140 IMS/YS system/Application Design Guide
A
17
L
I
I
I
fl
104
~ I
..ill
I
I
I
I
I
2~ c 32
D 61
lr
E
42
~ I
I I
I I I
G
F 18] ~
26
OVERFLOW
I I I I I I I I I I I I I I. /
Fr~·,".-~rr-.--~* I
I I ~~~~=-~~--41' I
\ \ \
\ \ \ \ ,\ \
\ \ \
\
o 1
*The pointer is at the beginning of VSAM logical records
Pigure 4-58. HISAM Physical Storage -- ISA~. OSAM, or VSAM
Primary and overflow data set logical records are always blocked one or more for each physical block (see Pigure 4-59). A data base record may be contained in one primary data set logical record, or it may consist of one primary data set logical record and one or more overflow logical records. The overflow logical records must he at least as large as the primary logical record. Overflow logical records may be unblocked or blocked. The number of overflow logical records within a physical block may be equal or not equal to the number of primary logical records within a physical block.
Data Base Design Considerations ~. 141
LRECL
lRECl
Primary or Overflow (BLOCKED)
LRECI.
lRECL
I. . .----BLKSIZE----··,.....----BLKSIZE
TRACK OF DASD
LRECL
~I
Primary or Overflow CUrmLOCKED)
LRECL IllRECl II LRECL II LP.ECl. II LRECl /I LRECL
I. . !+sLKSIZE..j..IILKSIZE-+!+BlKSIZE-+RLKSIZE¥BLKSIZF.... -BLKSIZE-1
TRflCK OF DASD
Figure 4-59. HISAM Physical Storage Blocked One or ~ultiple
VIABILITY OF DATA BASE DESIGN
In the design of a data base, the designer must consider the viability of that design. How can he anticipate, at least in some measure, changes such as the additions of new data, new applications for new data, new applications for existing data, discontinuance of existing data, in short, the change in the level of activity against the data?
In adding new data segment types, the simplest approach is to extend the data base to the right (see Figure 4-60). By the addition of new segment types in this manner, segments to the left and applications dealing with those segments need not be modified. An additional benefit for HISAM data bases, or HDAK and HIDAM data bases that use hierarchic pOinters is that only the data base descriptions need to be regenerated. It is not necessary to unload and reload the data base. For HDAM and BIDAM data bases where the segment type being added will be pointed to by physical child pointers, it is necessary to unload and reload the data base to add physical child pointers to the prefix of the physical parent of the segment type being added.
4.142 IMS/VS System/Application Design Guide
,.--_........_-,----------------j
I
Figure 4-60. Data Structure Change -- New Segment Type Defined at End of Hierarchy
In Figure 4-61, the bew data, "Production Control" and "Work Station," could be added to the data base at a different position. A disadvantage of adding new segment types in this way is that the physical code of each segment type changes. The order of segment insertion being top to bottom, left to right, such a change would require a reload of the file. Again, there would be no reprogramming required for existing application programs. One reason for this arrangement could be that the majority of the processing activity is to be against the Production Control information.
Figure 4-61. Data Structure Change -- New Segment Type Defined within Existing Hierarchy
Figure 4-62 shows an arrangement that will almost certainly impact existing application programs, by making it necessary to regenerate the PSB for any program which is sensitive to "Standard Information." The degree of modification to the application program will, of course, be a function of the type of calls made against the data base and the use made of the concatenated key feedback information. Assuming that no use is made of the concatenated key, the series of calls at the left would function properly without modification, after the PSB is made sensitive to "Production Control" and "Work Station~"
Data Base Design Considerations 4. 143
PART
NUf'IBER
I
I
I
I
PRODUCTiON
,, CONTROl
I
WORK
STAnON
, I
-,I
STANDARD INFO Rf/.,4TION
INVENTORY
STATUS
I
I
I
PHYSICAL
BACK
COUNT
ORDER
GU PART NUI1BER GN STANDARD INFORMATION
GU PART NUMBER
GN
Figure 4-62. Data Structure Change -- Nev Segment Type Defined within a Leg of the Existing Hierarchy
It is evident that the series of calls on the right side of Figure 4-62 would not function properly. The unqualified GET NEXT call would obtain the "Production Control" segment instead of the "Standard Information" segment.
In user applications with existing data, if the activity becomes weighted to the right it may be desirable to move certain segment types, logically and physically, nearer the root. This would ensure that they were located in the record containing the root segment. In the data base of Figure 4-63, an increase in activity against the Production Control segment could make a new data base design more desirable·
4.144 · I~S/VS System/Application Design Guide
L
Figure 4-63. Data Base Structure -- Hierarchic L~g Independence One solution, moving the segments logically and physically to the
left, is shown in Figure 4-64. It is possible to plan for the freedom to move the legs of the data base around in this manner withont affecting the functioning of application programs. If the data base and applications are dgsigned in such a manner that each application program relates to the root and to only one leg of the data base, it is possible to manipulate the legs without impacting applications.
Figure 4-64. Restructured Data Base Another solution to an increase in activity against certain segment
types is to move those segment types to a secondary data set group_ In this instance, however, the tradeoff against increased core buffer requirements would have to be considered.
When segments representing a particular segment type cease to exist, there is no mandatory adjustment necessary to the data base design nor is there any measurable penalty for not doing so. Eliminating segment types, however, requires a new data base description generation. If there are no oc~urrences of the segment type in the data base and the segment types are farthest away from the root in the top to bottom, left to right fashion, there is no need to unload and reload the data base. In Figure 4-65, "Production Control" and "Work Station" could be dropped.
Data Base Design Considerations 4.145
,I
I
lI _________.J
Figure 4-65. Data Base Structure -- Absence of segment Types
Eliminating segment types which are not logically last requires that the data base be reloaded. Program specification blocks which were sensitive to the segment types being deleted would be regenerated. Since the segment types are deleted because the applications and data no longer exist. there is no need to modify the majority of remaining application programs. The extent of the modification would in all probability be only a change in some call parameters to Data Language/I.
Expanding the size of a segment can cause a change in the program {see Figure 4-66). On an indi¥idual application basis, this change can be a¥oided by using oversized vork areas in the application program. As an example. a Data Language/I I/O area of 150 bytes could be defined when in reality the size of the segment to be operated on need only be 100 bytes. With this technique, the size of the segment could be expanded without affecting the application program. It should be noted that the size of the application program viII be increased, but this added overhead is usually more desirable than the possible reprogramming effort.
SE6IOT Ii
EXTlNIID SEGI£NT Ii
1+---150 BYTES---+t
APPLICATION PROGRAII
DLlI 110 AllA
1+--150 BYTES--+oI.1
Figure 4-66. Application Program I/O Work Area Size Considerations
HIERARCHICAL DIRECT DESIGN CONSIDERATIONS The Hierarchical Direct organization is composed of two data base
access methods: HDA~ and HIDA!. The HIDA" access method uses two
4.146 IMS/VS System/Application Design Guide
physically distinct data bases for access and storage of the data. The INDEX data base is used to determine the sequence in which data is presented to an application program, but does not actually contain any of the data in the HIDAM data base. The HIDAM data base contains all the actual data and is physically distinct from th9 index. The HDAM access method uses one data base and a randoaizing algorithm for accessing data.
~~i~n £Qq§~q~£!liQn§ t~£_1he !n~~! at ! li!Q!~ ~!t! ~!§~
The INDEX data base contains index segments which perform indexing. The content of the index segment is equivalent to the sequence fiela key in the root segment of a HIDAM data base. The INDEX data base used for HIDAM is composed of a single data set group which is similar to the HISAM organization.
Since the INDEX data base is basically a HISAM data base containing only index segments, the majority of the design considerations from the HISAM section apply equally well to the index. Of course, both the primary or primarY and overflow data sets should have relatively high blocking factors. For example, a quarter track of a 2314 for block size would be appropriate. The HISA! unload and reload reorganization pr~gram should be run fairly frequently against an INDEX data base to reduce long OSA! chains when ISAM/OSAM are the access methods. This procedure should not require an excessive amount of time, since the INDEX data base is much smaller than the HIDA~data base it references.
~~2ign £Qn~g2~!liQn§ tQ~ Q!l! fQ~li~n 21 liIQ!~ ~!1! ~!§~
Considerations for the design of the data portion of the HIDAM data base involve the tradeoff between direct access space and access time. The most efficient organization for access time, when application programs do not access every segment in any data base record, is to choose the physical tYin/physical child manner of relating segments of a data base record. If this option is chosen, any path through the data base may be followed without looking at segments not on the path. ~he negative aspect of this choice is that more storage is needed than if the user elects the hierarchical pointer approach to relate segments.
The hierarchical pOinter option reduces prefix size by stringing together all segments of a data base record, but IMS/VS must process it in much the same manner that it processes HISAM. That is, the segment on the right of the structure is at the end of the hierarchical pointer chain. All segments to the left of a desired segment have to be scanned to get to the desired segment. Therefore, this option should be used for those portions of a data base record that are normally accessed sequentially.
If root segwents are often accessed sequentially, the user should probably select the bidirectional physical twin pointer option for root segments. If this option is chosen, and the user issues a data base call which references either implicitly or explicitly the next data base record, the index data base is not used to satisfy the request.
Q~2i~n ~Qn§ig~~s!iQn§ !Q~ !n liQ!~ Q!ts ~s§~
The two major considerations in designing an HDAM addressing or randomizing algorithm are access time versus storage and reorganization considerations. Ideally, an addressing or randomizing algorithm spaces root segments across the root segment addressable area of a data base in such a manner that little storage is wasted and yet synonym chains are very short. Long synonym chains negate the savings made by not having
Data Base Design Considerations 4.147
to access an index. On the other hand, a sparse storage of root segments may waste direct access space that could be used if the organization were HIDAK.
If a data base is increasing in size, some thought should be given to reducing the problems when it must be reorganized. Some randomizing routines yield radically different results for the same set of keys when the size of the root segment addressable area is increased or decreased. If this is the case, the user is faced vith the choice of loading randomly, which may be very slow, or doing an offline sort prior to reloading. Randomizing routines can be constructed that viII not seriously alter the sequence of data when the size of the root segment addressable area is changed. An example of this is the binary halving routine illustrated in the ~~!~ ~Ist~m ~£Q~~mm!ng R~fe£~n£~ a~~~l.
The user may wish to take advantage of the bytes parameter of the RMNAKE= operand on the DBD statements for a DBD generation. The use of this parameter reduces the inefficiency caused by dependent segments of a very large data base record taking excessive space in the root segment addressable area. If excessive space is used for dependent segments, other root segments are forced out of their prime blocks in the root segment addressable area and into overflow.
The use of bidirectional root segment physical twin chains is not recommended in HDAM, since roots are chained only off a root anchor point and thus do not tie the whole data base together as in HIDAK. Bidirectional pointers may cause additional processing time at insert time, since the NEXT root on the synonym chain must be updated to point back to the root being inserted. Hovever, use of the physical twin baCKward pointers provides improved delete performance.
HDAM -- HIDAM CONSIDERATIONS FOR DEPENDENT SEGMENTS
The user may wish to give some thought to the use of additional data set groups in a HDAM or HIDA! data base to save access time and make better use of disk space. For example, a data base may contain a segment-type which is quite bulky and infrequently accessed. This segment-type can be placed in a separate data set group, thus reducing access time among the more frequently used segment-types.
Another form of separating segments into data set groups the user may wish to investigate is separation by segment size. The Hierarchical Direct organization bit maps, which describe free space existing on blocks within the data base, contain information based on the maximum segment size within the data set group. If segments of about the same size are contained within each data set group, better space utilization may result.
Proper direct access data set block siz9 is another factor to be considered in system performance. The larger the block size, the more data that is obtained with a single input/output operation. If the majority of the data is used, then larger block sizes have a good payoff. However, if the data is accessed randomly within a data base record and only small portions of any particular block are used, then the user has paid a penalty in terms of system channel time and core storage buffer space to access large blocks.
The IMS modules concerned with management of DL/I data bases make use of the OS BISAM and QISAK access methods. These access methods are used to access d~ta stored in os ISAM data sets. OS ISAM data sets are used by IMS/VS to store data for HISAM data bases and for the index data base
4.148 IMS/VS System/Application Design Guide
to a HIDAM data base. BISAM and QI5AM are used by IM5 under the following conditions:
1. BISAM is always used to manage an I5AM data set t.hat is accessed from an IM5/VS CTL region (that is, in a message processing environment) ·
2. The following rules apply to a batch processing environment only:
a. QI5AM is used to manage an 15AM data set of a HIDAM data base when the root segment of the HIDAM data base is referenced by one PCB only, and when the processing option for the root segment is retrieve or load only. In all other cases, BI5AM is used to manage the ISAM data set of an index data base.
b. BISAM is used to manage the ISAM data set of a HISAM data set group when (1) a PCB is sensitive to a logical parent that exists in the data set group, or (2) multiple PCBs are sensitive to segments within the data set group. Other data set groups will use QISAM. Note, therefore, that for- a HISAM data base, BISAM may be used for some data set groups, while QISAM may be used for other data set groups.
c. If use of both BISAM and QISAM is indicated for an ISAM data set by the rules presented above, use of BI5AM takes precedence.
d. If a user desires, for performance reasons, to cause IM5/VS to use BI5AM to manage a particular 15AM data set, he can do so by ensuring the presence of one of the conditions outlined above that will cause use of BISAM. A user can cause IMS/VS to use Q1SAM for an ISAM data set only by ensuring the absence of any of the conditions that would cause IMS/VS to use BISAM.
e. Note that, because of the rules described above, both BISAM and QISAM may be used during execution of a particular application program.
I/O buffers for data sets using BISAM are always obtained from the IMS/VS data base buffer pool. 1/0 buffers for data sets using QISAM are always obtained by QISAM. If QISAM, use QISAM for read and writes; if BI5AM, use ISAK or OSAM for read, 05AM for write.
DATA BASE RECOVERY
!Msivs supplies a number of utility programs designed to provide a
rapid recovery of a data base data set rendered unusable because of read/write errors. Although these programs will be used infrequently, judicious preplanning will enhance data base availability in the event of failure.
The data base recovery utility program set includes:
1. A program to create an image copy or dump of a data base in a batch system. In addition, the online image copy utility allows increased IMS/VS availability by taking image copies of data bases in an online system. (For information on how to use and execute this utility, see "Online Data Base Image Copy Utility" in the "Data Base Image Copy Utility" section in the "Data Base Recovery Utilities" chapter of the !~2!!2 ~!!!!!!~~ ~2f~~2U£~
Data Base Design Considerations 4.149
~~g~!.) Potential users of this utility must assure availability of an adequate data base buffer pool, CPU, and real storage resources to keep interference to the online workload at an acceptable level. Online image copy dynamically acquires storage and operates in a batch message processing region. This storage is used primarily for buffers for the SYSIN, SYSPRINT and the image copy data set(s). VS1 and SVS use two buffers per QSAM data set and MVS uses 5 buffersi these numbers can be increased with JCL statements.
2. A program to restore an image copy or dump of the data base.
3. Logging routines in the IMS/VS batch and control regions to record on system log tapes any changes made to a data base.
4. A program to accumulate information from system log tapes about the latest changes to a specific data base.
5. A program to rebuild the data base using, a) a previously created da"ta base image copy, b) accumulated data base changes obtained from log tapes, and c) input from log tapes which have not been processed by the accumulation change programA
The initial consideration in the use of these programs should be the frequency of data base image creations. The amount of data bas~ activity and size of data base will determine the intervals between data set image copy creations. Since image copy input to the Data Base Recovery Utility provides the most rapid means of recovery, the shortest interval possible between image copy time and data base recovery is desirable.
The second consideration should be the frequency of accumulation change creations. The accumulation change input provides a sorted, combined record of data base changes to be merged with the image copy. Since the sorted input is by physical block number within the data base, the application of the accumulation change input can be accomplished almost as rapidly as an image copy only. In addition, the accumulation change utility operates independently of IKS/VS, allowing the log changes to be accumulated without impacting data base availability.
Since log change input is processed chronologically, random access to the data base being reconstructed is quite probable. The same physical record may be accessed multiple times in a single recovery. It becomes readily apparent that the accumulation of data base changes from log tapes with the accumulation program will greatly enhance performance of the data base recovery.
See the chapter "Data Base Recovery Utilities" in the !~§l!§ ~!i!i!i2~ R~~2~~R£~ ~!R~a! for additional information regarding the Data Base Recovery program set.
DATA BASE REORGANIZATION
Data base reorganization utility programs provide a convenient means for achieving physical and logical reorganization of IMS/VS data bases. Use of these facilities allows:
· Recovery of direct access space occupied by deleted segments in a HISAM data base
· Reorganization of a data base when the physical sequence of its segments has become different from its logical sequence because of insertion and/or deletion of segments.
4.150 IKS/VS System/Application Design Guide
· Physical and logical restructuring of a data base to better meet the requirements of IMS/VS application programs. Examples of restructuring of a data base include changing a data base access method and organization from HISAM to HIDAM, changing the physical placement of a segment type from one data set group to another, addition of segment-types, and addition or deletion of physical and/or logical intersegment relationships.
The details of all the data base reorganization utilities are provided in the chapter "Data Base Reorganization/Load Processing" in the !~~L~ Q1i!iti~2 !~f~t~u~s ~~al.
Data bases may be reorganized separately, or several may be reorganized concurrently. If nonreorganizad data bases are logically related with direct addresses to those being reorganized, then these must be scanned for all logical children whose logical parents are in one of the reorganized data bases. Programs are supplied to scan the nonreorganized data bases, and where necessary update their direct addr~ss relationships to a reorganized data base.
The IMS/VS statistics programs provide data that can help systems operation personnel determine whether a data base should be reorganized. Determination of an appropriate interval at which a data base is to be scheduled for reorganization depends, to a large extent, on systems operation personnel's knowledge of the overall activity on the data base (that is, the number of segment additions and deletions), of the physical organization of the data base, of the relationship of the data base to other data bases, and of the installation's planned use of the data base in the future.
~ost data base reorganizations are done to recover space occupied by deleted segments and/or to physically resequence segments in their logical order. The number of segment insertions and deletions can be determined from data provided by the application accounting report, and the distribution of transaction response times as shown in the transaction response report. When segment chains become long, and when they involve segments that are in different areas of a storage device, response times tend to increase. Growing response times can indicate a need for data base reorganization.
Frequency of reorganization should be considerably less for HDA~ and HIDAM than for HISAM data bases. HDAM and HIDAK both reuse space freed by deleted segments and both attempt to place inserted segments physically near their logically related segments (that is, near segments to which they are chained by physical child, physical twin forward, or hierarchical forward pointers).
Three aethods can be used to reorganize HISAM data bases. A specially written user program can be provided, the 18S/VS-provided HISAM reorganization utilities can be used. or the IMS/VS-provided HD reorganization utilities can be used.
The first method must be used when you want to accomplish data base structural changes that cannot be accomplished through the use of the HD reorganization utilities. The special program involves use of GET NEXT calls to retrieve segments from a data base, use of special user routines to accomplish the desired changes to the data base, and use of INSERT calls to reload the data base. Care must be taken in writing a
Data Base Design Considerations 4.151
special reorganization -program so that concatenated key pointers, used for logical relationships, are properly maintained.
The second method uses the HISA~ reorganization utilities and should be used whenever a HISAM data base is to be reorganized with no changes. The HISAM reorganization is accomplished by a rapid unload/reload program that references data on a physical data base block level. The utilities drop deleted segments and then restore segments to the data base so that their physical sequence is the same as their logical sequence. External pointers that reference segments within the HISA" data base are unaffected, since they must be concatenated key pointers. Pointers within the HISAM data base that reference segments in other data bases are affected only if the other data bases are reorganized and if the pointers are direct pointers. Pointers contained in segments stored in the HISAM data base can be updated as described in the !tt~L!~
Y1i1!1i~ Ref~~~n~~ ~!nuai.
If structural changes are required, the third method should be used. This is described under Reorganization of HDA~ and HIDAM Data Bases, following.
Several methods can be used to reorganize HDAM and HIDAM data bases. One method involves use of GET NEXT and INSERT calls with a user-written application program as described above.
Another method is to use the I~S/VS-provided HD reorganization unload and reload utilities. These utilities use unqualified GET NEXT calls to sequentially unload segments from the data base to be reorganized. Data is appended to each segment to resolve logical relationships after doing the reload. After unload is completed, the segments are reloaded using INSERT calls. At reload time, a check is made to determine if a segment is involved in logical relationships. If so, data describing the logical relationships is written to work tapes for later use in updating the logical relationship pointers. Note that the BD unload and reload utilities can be used to reorganize HISA" data bases, but that performance does not equal that of the rapid unload/reload utility. However, if structural changes are required, the HD reorganization utilities must be used.
If the data base has logical relationships, the HD reorganization utility must be used to reorganize the data base.
The reload utility also provides statistical data that can be used as described in the I~2LY2 g1i!ili~~ E~f~£~n£~ ~~Ug!!·
The Partial Data Base Reorganization (PDBR) utility reorganizes user-specified ranges of a HDAM or a HIDA!! data base. (A "range" is either a group of HIDAM records with contiguons key values or a group of HDAM records with contiguous r.elative block numbers, and is specified by using a low and high pair of key or block number values.) The Data Base surveyor utility can be used to aid in the selection of the ranges to be reorganized. Full data base reorganizations are required less often because you are able to reorganize portions of a data base. PDBR is a process consisting of:
· step one which uses DBD and control information to build sets of, control tables, and optionally produces PSB source statements required for step two.
4.152 I"5/V5 System/Application Design Guide
· Step two which reorganizes the key range{s) or area{s) of the data
base specified by the aser in step one including all logically
L
related segments and their pointers. Statistical reports are produced by both steps.
PDBR LIMITATIONS
PDBR does not:
1. Permit data base structure changes,
2. Reorganize HD or HIDAM data bases which are logically related to HISAM data bases which use a direct pointer in a logical child or logical parent segment.
PDBH reorganization consists of:
· Reading control statements that specify the range of records
· Creating control tablfts for ase by step two (above)
· Determining logically related data bases that may require pointer resolution
· Preparing a report
STEP ONE: PRE-REORGANIZATION
This step requires as input, the data base name to be reorganized, its DBD, and utility control statements defining the reorganization ranges and sort options. The primary output is the set of control tables to be used in the next step to perform the reorganization. Optionally, PSB source statements can be produced by creating a PSB in the next step. Additional outputs include reports, error messages, and a return code.
STEP TWO: POINTER RESOLUTION
This step reads the control tables produced in step one and the user-supplied control statements. According to the specified record ranges, alL segments (roots and their dependents) are unloaded in hierarchical order to an intermediate data set. The space within the data base that these records occupied is freed. The records are reloaded into ranges of free space within the data base apd the new record locations are saved in work records. Then all logically related data bases are scanned for pointers to the records that have been moved. Work records are created to designate where pointer resolution is required. All work records are then sorted (by OS/VS SORT) according to data base name and segment name. Finally, all pointers to the records having new locations are changed to point to those locations.
Output from this step includes the partially reotganized data base, as well as a report of what was done and a return code. In the case of an unsuccessful execution, an error message is issued. For more information on reorganization and control statement examples, see the
I~~LY~ Y!!!i!!~§ R~t~~n£~ ~~aga!·
Data Base Design Considerations 4.153
THE DATA BASE SURVEYOR UTILITY
The user must determine the range of records in a data base to be reorganized and identify where to move the reorganized records. The Data Base Surveyor utility scans the data base to be reorganized and provides a report describing the physical organization and the use of free space. Using this report, an installation can determine the range of records ~o be reorganized and identify free space in the data base where the reorganized records can be moved. Surveyor analyzes the data base and produces a report which statistically summarizes chain length and free space information for user specified areas of the data base.
USER RESPONSIBILITIES
The purpose of using PDBR is to improve availability of the data base. The user should consider the trade-offs between reorganizing the entire data base or doing a partial reorganization. If the user decides to perform a partial reorganization, an area for reorganization must be selected and designated as a target area. If the user fails to select an area large enough, the execution of PDBR could defeat its purpose and in some cases, degrade performance.
To have an effective reorganization of part of the data base, the user must at minimum know the information about the data base described in the following paragraphs. The Surveyor utility can be used to collect this information.
The user must locate the data base segments that require reorganization. If the Surveyor utility is not used, an alternative is to analyze the insertion and deletion activities (or transaction patterns) that were applied to the data base. The application accounting information recorded on the system log can be used for this analysis.
Once a range is identified, the user must calculate the average byte length of the data base records within the range to be reorganized. The purpose of this calculation is to estimate how much free space is required to hold those segments to be reloaded. A sampling technique could be employed here for efficiency. For a given range of data base records, the number of segments to be unloaded is usually unknown, since the number of occurrences of each segment type of a data base record is a variable. For HDAM, the number of root segments chained off of any root anchor point is also a variable. If the target area is different from the specified unloading range, the root will be chained off of the original root anchor point.
The user must tabulate all the free space existing in the data base and look for a target area that is large enough. The user must also take into account all the space that will become available (the UNLOAD command frees the space occupied by a given segment) and select a sufficiently large target area. The target area may be the same area in which the data originally resided prior to Partial Reorganization. If such a target area does not exist in the data base, then the user must decide whether to extend the data base or to use the existing free space scattered in the data base. (Arbitrarily extending an existing data base is not a good practice as it increases the number of volumes of an already large data base.) If the choice is to use the existing free space scattered in tha data base, the user must consider whether the amount of existing free space is large enough to justify a partial reorganization.
If the existing contiguous free space can hold only a small percentage of the total segments to be reloaded, the remainder will be scattered in different blocks throughout the data base by the insertion
4.154 IMS/VS System/Application Design Guide
process. If, however, the existing contiguous free space can hold a high percentage of the total segments, the reorganization might be effective and the operation should be performed.
The user must estimate the time required to reorganize a range of the data base. In general, it takes a great deal more than 'O~ of the normal reorganization time to reorganize 10~ of the entire data base. This is especially true when the data base to be reorganized has a substantial amount of logical relationships. If any scan actions are required to be done or if the decision is made to scan segments (based on the step one option report), SCAN is performed. The SCAN process accesses and examines every occurrence of a given logically related segment type regardless of the number of the data base records being unloaded or reloaded. If logical relationships exist within the larg~ data base being partially reorganized, SCAN will access all the segments in the data base, even though only a fraction of the data base is actually being reorganized. As with any reorganization, it is recommended that the data base be protected by a backup copy before and after a partial reorganization.
UTILITY CONTROL FACILITY
IMS/VS also supplies the Utility Control Facility (UCF). The UCF directs the data base initial load, reorganization, recovery, and change accumulation utilities, and provides for restart processing after a utility failure or a user request to end processing.
The UCF provides a method of performing most data base utility operations and maintenance in preparation for recovery and reorganization under the control of one job, one step, and in one scheduling. It handles the data base recovery and data base data manipulations in reorganization, the combining of data base data ·changes into composite change records in change accumulation, and backup copy proeessing. Restart processing is invoked by an EXEC parameter or a control statement, and normal processing is directed by control statements.
See tha ~~L!~ Y1~!~~i~§ Ref~~n£~ ~~nY~! for a full description of the UCF.
When direct access storage is required for a data base, the amount of space needed and the device type must be specified. IMS/VS follows the same approach as OS/VS.
The amount of space required can be specified in terms of blocks, tracks, or cylinders. If it is desired to maintain device-independence across direct access types, space requirements should be specified in terms of blocks. Otherwise, if the request is in terms of tracks or cylinders, such items as their capacity must be considered. IS!" data sets must be allocated by cylinder. The amount of space is supplied in the DD statement for the data set.
Allocating the space for an IMS/VS data base that uses IS!M and OSAK CHISAM and INDEX) is similar to allocating space for an operating system indexed sequential data set; similar because an operating system data set can be divided into three areas, prime, index, and overflow. The three areas of an I~S/VS data base are index, prime, and overflow. Each data set group of a HISA! data base requires a primary and overflow data set to be allocated.
Data Base Design Considerations 4.155
Allocating the space for an IMS/VS data set that uses only OSAM (HDAM and HIDAM) is similar to allocating space for an operating system direct (BDAM) data set. Each data set group of an HDAM or HIDA" data base requires one OSAM data set to be allocated.
DBD generation computes, from the user's definition of segment frequency, the logical record length and/or block size of a data base. It considers the device and rounds to the next higher one-fourth track, one-third track, one-half track, or full track.
DBD generation also computes from the user's definition of segment frequency the space allocation requirements for a P-ISAM or INDEX data base.
For use by Systems Operation personnel, IMS/VS has two parameters that can be inserted when a DBD generation is performed. These provide an additional means of specifying the logical record size (RECORD) and blocking factor (BLOCK) for a data set group within the data base. Instead of DBD generation specifying the logical record size and block size, it can be overridden by specifying the RECORD and the BLOCK
parameters in the DATASET control card. Refer to the Itt§LY§ ~tiliti2§
~~t~£~n~~ ~snYs! for details.
ALLOCATION CONSIDERATIONS
Space allocation should be considered with regard to the data base structure, the application programs that will access that structure, and the tools of IMS/VS DBD generation. The following discussion deals with a direct access device.
When an 1MS/VS data base is loaded on a direct access device, it is necessary to allocate space for that data base with JCL data definition statements. The creation of a HISAM or INDEX data base may require up to three DD statements, one each for the index, prime, and OSAM overflow areas. This discussion should provide assistance in initially determining the amount of space to allocate to these areas for any specific application.
600 SOo "00 300 200 100 -
SOl 101 901
1001
Figure 4-67. Logical Record Length Distribution
The graph in Figure 4-67 indicates that 50~ of the logical records are 150 bytes or less in length, 70% of the logical records are 200, bytes or less in length, and 100% of the logical records are 600 bytes
or less in length.
4. 156 IMS/VS System/Application Design Guide
With fixed-length ISA~, it is necessary to establish a fixed value for LRECL in the prime area. If a value of 600 bytes is selected for LRECL, all logical records can fit in the prime area. However, 90~ of the records then have at least 100 bytes of slack or wasted space; 701 of the logical records have at least 400 bytes of unused space.
In this example, if a value less than 600 bytes is selected for the LRECL value, the ISAM prime area is not capable of holding all the logical data base records. Those dependent segment occurrences that do not fit in an ISA~ prime logical record are housed in OSAM overflow records. Therefore, the determination of an ISAM prime logical record length must consider the tradeoff between storage in the ISAM prime area and in the OSAM overflow area.
To determine a best balance between ISAM prime and OSAM overflow, the following points must be considered:
1. Access to data that is wholly contained in the prime area is more rapid than access to data contained in the two areas. Access is even slower to those logical data base records that require more than one overflow record.
2. Disk space allocated to OSAK overflow can be used to hold segment occurrences that overflow from any logical data base record. Unused space in the prime area is tied to specific roots.
3. Records may be blocked in the prime area and in the OSAM overflow area. The logical record length in the OSAM block must be equal to or greater than the ISAM logical record length in the same data set group.
4. The nature of the accesses to the large logical data base records also has an important effect. If the large logical data base records are highly used, the value of the prime LRECL should be increased to completely house more logical records, and the total size of overflow should be reduced. If the large logical data base records are infrequently accessed, an opposite shift should be made to increase the use of OSAM overflow.
Considering these relevant factors for a specific data base, a percentage balance must be established between the ISAM prime and the OSAM overflow. For example, it may be best, in the context of optimizing space and time utilization, that 90~ of the logical data base records completely fit in the prime area and 10% require some OSAM overflow storage. After this percentage is selected, the frequency of dependent segment occurrences is developed for the 90% percentile of the parent segments. The 90~ is an estimated value for this specific data base.
When space is allocated for a data base which uses only OSAM (HDAM or HID AM) for data segment storage, DBD generation selects the appropriate physical block size for storage. Since space within physical blocks can be shared by segments from different data base records, logical record definition is not utilized.
The number of physical blocks, tracks, and/or cylinders which should be defined in the JCL statements for any IMS/VS data base allocation can be estimated in the following manner:
· Calculate the average data base record length (sum of segment
lengths times frequency) ·
· Calculate the number of logical records and physical blocks CHISAM or INDEX) or physical blocks (HDAM or HIDAK) required to store a data base record.
Data Base Design Considerations 4.157
· Multiply the number of physical blocks p~r data base record times the number of data base records.
· The result should provide an estimate for m1n1mum space allocation. In addition to this value, space must be provided for additions to the data base after initial load.
· If distributed free space vas specified in the DBD, then multiply the minimum space allocation by: fbff
fbf!=;
where:
2 ~ fbff ~ 100 or fbff = 0 and 0 ~ fspf < 100
See "Dataset Statement" in the chapter "Data Base Description," in the 1~~L!~ Y!ili!~2 ~~t~~n~ n!n~!l for more information on fbff and fspf.
4.158 IMS/VS System/Application Design Guide
This chapter describes the Multiple Systems Coupling (MSC) feature and contains design considerations for its use. Familiarity with the preceding chapters of this manual is assumed.
The MSC feature provides the ability to connect geographically dispersed IMS/VS systgms in such a way as to allow programs and operators of one system access to programs and operators of the connected systems. Communication between two or more (up to 255) IMS/VS systems running on any combination of OS/VS1 and 05/VS2 MVS systems in one or more 5ystem/370 CPUs is permitted.
The MSC feature also provides a way to extend the throughput of an IM5/VS system beyond t~e capacity of a single 5ystem/370 Model 168MP. This is possible if the IMS/V5 applications can be partitioned among systems such that either:
· Applications execute in more than one system with data base contents split between systems (horizontal partitioning) ·
· Applications execute in one system with t~e complete data base, that they reference, attached to that system (vertical partitioning) i the transactions can originate in any system. For information on the ase of the MSC feature in conjunction with the Fast Path feature, see the "Fast Path and 1MS/V5 Interrelationships" section of the chapter, · 'Design Considerations for the Fast Path Feature."
In addition to the considerations for a single DB/DC system described in the previous chapter, major design considerations for MSC are: determining how to distribute functions among systems and obtain acceptable pC!rformance, d-afining valid connections between the systems, and implementing operating procedures for maintaining consistent connections.
The flow of a transaction through processing in a multisystem environment requires a few steps in addition to those required in a single system environment. The additional steps can be identified by comparing Figures 5-1 and 5-2.
MFS
t
IMSIVS Device Support
t Access Method
IMSIVS Scheduling
t
Application Programming
t
DL!l
IMSIVS Device Support
t
MFS
t
Terminal
Figure 5- 1.
Single DB/DC System Transaction Flow Design Considerations for the ~sc Feature 5.1
Processing System
Message Queue
IMSIVS Scheduling .j,
Application Program .j, DL/l
Message Queue
MSC Support t Access Method
MSC Support .j,
Access Method
Terminal System
Access Method t MSC Support
MFS t IMSIVS Device Support t - - - - i t Access Method
Message Queue
Access Method .j,
MSC Support
Message Queue
IMSIVS Device Support .j, ! - - _..IMFS .j,
Access Method
Terminal
Figure 5-2.
Multiple DB/DC Syst9ms Transaction Flow
This section presents a general description of the "S~ feature and introduces MSC t~rminology. To do this, an example is used of a
multisystem environment consisting of three systems -- System A, System B, and System C. Figure 5-3 shows the sample environ~ent.
5.2 I~S/VS System/Application Design Guide
A IMSA
B IMS B
C
I" IMSC
Figure 5-3.
A Sample Configuration of Thr~e Systems
In a multisystem environment, the term !2£!! ~~~~~is used to
identify a specific system within tha multiple configuration. All other systems are consid~red ~~2~g ~I2~gm§. For example r if we vere considering the activities required by System B when it receives a message, System B is the local system and Systems A and C are remote systems.
When the mUltisystem environment is defined, the items defined for each local system include:
· All transactions received by and/or processed by that system
· All logical terminals attached to this system and all logical
terminals in remote systems that are referenced by transactions
processed in this system or by terminal operators
· The physical and logical connections between this system and the remote systems that share in the processing of the specified transactions
LINKS
The connection between two systems is called a !iU!. All links must
be defined during the IMS/VS system definitions for each I~S/VS system.
There are tvo types of links, £hI2i~!1 lint and !2gi~!1 lint. A
physical link is the actual hardware connection. A logical link is the mechanism through which a physical link is related to the transactions and terminals that make use of that physical link. The assignment of a logical link to a physical link can be specified during system definition, or made dynamically during system execution.
Design Considerations for the MSC Feature 5.3
A physical link is defined by the RSPLIMK macro instruction. Three types of physical links are allowed by the RSC feature:
· Binary synchronous communication (BSC) line · Channel-to-channel (CTC) adapter (OS/V52 MVS only) · Main storage-to-main storage (MT!)
Only the BSC line and CTC adapter represent actual hardware links. The KTM link is a software link between IRS/VS systems running in the same System/370, and is intended primarily for backup and testing purposes. Physical link buffer sizes must be equal and if BSC is chosen for the physical link, CONTROL=YES must be specified for one end of the' physical link and CONTROL=NO must be specified for the other end of the physical link. Figure 5-4 summarizes very simply the three types of physical links.
A
IMSA
B IMS B
IMSC
I IIMS I ~T~IIMS
C1
C2
Figure 5-4. Summary of Physical Link Types
One System/370 CPU may be linked to another CPU by one or more of each physical link type, as shown in Figure 5-5. The KTM link is recommended when two or more 1MS/VS systems reside in one System/370.
A
Figure 5-5.
BSC Line
Multiple Physical Links in One System/370 CPU
5.4 IMS/VS System/Application Design Guide
Orr multiple links may exist between CPUs. See Figure 5-6.
A
Figure 5-6. Multiple Physical Links in Multiple system/370 CPUs
A logical link is defined by the MSLINK macro-instruction. A logical link relates a physical link to the transactions and terminals that can use that physical link. Each system in a multisystem configuration has one or more defined logical links. Two IMS/VS systems defined to communicate with each other, each through a specific logical link, are called £S~i~~~2. To establish connection between two IMS/VS sys~ems, each partner must have a logical link definition. The two logical link definitions must specify the same partner identifications and be assigned to the same physical link. IKS/VS system definition assigns a number to each defined logical link. Logical link numbers are assigned sequentially, beginning with 1, in the order in which the links are defined. A logical link can be reassigned to a different physical link but the two systems must always communicate through a logical link partnership.
IMS/VS system definition does not require that a physical link be specified for each logical link. The assignment of the physical link to the logical link can alternatively be made online using the IMS/VS /MSASSIGN command. There can be no communication between partners until the assignment is made.
A logical link definition must include one or more logical link paths. Logical link paths are described in this chapter under the heading "Logical Link Path."
If any logical terminals in a remote system are referenced by messages originating in the local system, the logical link definition must also include NAME macros to identify those~~!2i~ !2~!£s!
i~!ina!2·
Figure 5-7 summarizes the relationships of one physical link to one logical link to multiple logical link paths. Although more than one logical link can be defined with each physical link, only one logical link to physical link relationship can be assigned at anyone time.
Design Considerations for the MSC Feature 5.5
Logical Link Path
Logical Link Path
Logical Link
Hardware r------,or
Software Physical Connection Link
Physical Link
Logical Link
Logical Link Path
Logical Link Path
Logical Link Path
II (relationship can be assigned dynamically)
Logical Link Path
Figure 5-1.
Relationship of Physical Link to Logical Link to Logical Link Path
MESSAGE ROUTING
The message routing function of the MSC feature supports transaction processing by more than one system, transaction processing by more than one application program in the same or different systems (by program-to-program switches), and message switches between terminals in the same or different systems. Conversational processing is available to any system in a multisystem configuration to the same extent as in a single system.
The route through which IMS/VS passes a message from its origination through processing is called a ~~i!ng ~!1h. One or more systems may be included in a routing path. The routing path defined depends on the
multisystem configuration and the functions assigned to each system.
The path between any two systems is called a lQSi£~i lin! e~ih. One or more logical link paths must be defined for each logical link. A logical link path is defined in the MSNAME macro and specifies a ~Y~i~m i~~~iifi~iiQ~ for the system where messages using this path are to be processed and specifies a system identification for the system being defined.
Each system in a multisystem configuration has one or more unique system identifications (SYSID) ranging from 1 to 255. SYSIO assignments are implicit based on the logical link paths defined by MSNAME macros. For example, here are two KSNAME definitions:
· MSNAME SYSID=(2,1)
· MSNAME SYSID=(3,1)
The first definition above says that messages using this logical link path are processed in the remote system whose local SYSID is 2. The second definition above says that messages using this logical link path are processed in the remote system whose local SYSID is 3. By way of these definitions, IMS/VS system definition assigns SYSIO 1 to the system being defined and recognizes two remote systems with SYSIOs of 2
5.6 I"S/VS System/Application Design Guide
and 3. If a third path were defined with SYSID={5,4), IKS/VS would also assign SYSID 4 to the local system.
Each system maintains a SYSID table containing all logical link paths defined in that system. The size of this table is determined by the highest SISID defined and it will contain gaps for SYSIDS that are not
defined.
Transactions are assigned to logical link paths in the APPLCTN macro definition. Consider the following application definitions, each with one transaction code defined:
APPLCTN
TRANSACT APPLCTN
TRANSACT
APPLCTN TRANSACT
PSB=A
CODE=A
PSB=B,SYSID:(2,1)
CODE=B
PSB=C,SYSID=(3,1)
CODE=C
The SYSID keyword identifies the logical link path to be used for the transactions associated with the application. Transaction A is
considered a lQ£a! i£aU§a£ii2U since the absence of the SYSID keyword indicates transaction A is totally processed by the system being
defined. Transactions Band C are ~~2!2 i£~U§~£iiQn~. Felating the application definitions to the previous KSNAME definitions, IMS/VS would return via SISID 1, responses from transactions Band C to the system being defined unless the application program specified an alternate destination for the response.
Since inconsistencies among SYSID definitions may exist between various system definitions, IMS/VS provides offline and online methods
of verifying SYSID assignments. The Multiple Systems Verification
utility is provided for offline execution to verify the consistency of
definitions prior to attempting online system execution. Using this
offline utility, consistencies among all systems in the multisyst~m configuration can be verified in one execution. You should use t~is utility to verify the MSC configuration each time an individual system
is redefined. The /MSVERIFY command is available for online use to
identify and display inconsistencies between two systams.
Message routing is accomplished by !Qg!£!! ~~2~iU!~iQU2' as it is in a single system environment. A destination is either a logical terminal or a transaction code. It is considered a local destination if it resides in the local system and a £~Q1i ~~~~In!ir2n-if-it-resides in a remote system. In a multisystem environment, each system knows (by way of system definition) all local destinations and all remote destinations that may be referenced in this system. IMS/VS system definition requires that all local and referenced remote destinati~ns be defined with unique names.
Message routing is automatic according to the defined scheme unless £2Yii~ ~~i~ £Qutini~ are employed for dynamic routing control. Routing exit routines are described later in this section.
Iu£yt ~n~ Qi§iiU!~!QU ~Y21im2
To introduce the terms used to describe message routing, let's look again at tae sample configuration. Assume a message with a transaction destination is entered into Terminal X attached to System A. The transaction is defined to be processed by System B with its reply to be returned to the originating terminal.
Design Considerations for the MSC Feature 5.7
Refer to Figure 5-8. On inpat, system A is considered the in~~!
sIsi~m because the in~~! !~~!!n~! (Terminal X) is attached. System B is considered the ~~§!in~i~n §~!~m. The message is considered a ~im~~I £!g~~§! until processed. If the application program inserts a message with a transaction code destination during processing, this message is
considered a §~~~~~I ~~~~~§i. A message sent to the input terminal by an application program is called a ~~E2n!2.
~L------IAI ·ILB ------I
Terminal
Input System
Destination System
Figure 5-8. Input Terminal and Input System on Input
Refer to Figure 5-9. On output, System A is considered the destination §I§i~! and Terminal X is considered the ~~§!in~i12n !.2~~ in~!'=--
Terminal
Destination System
Figure 5-9. Destination Terminal and Destination System on Output
Refer to Figure 5-10. Assume the transaction were defined to originate in system A but be processed by System B with its output being sent to Terminal Y attached to System B. In terms of message routing, this example is the same as the previous one for input. For output, however, System B is considered the destination syst~m and Terminal Y is
considered the destination terminal.
I~,---A-----II
Terminal
Input System
·IL--..'------'~"
Destination System
Terminal
Figure 5-10. Input from and Output to Different Terminals
Another term related to message routing is In!~~!~gi~!~ §I§i.2!. Four systems linked as shown in Figure 5-11 illustrate an intermediate system.
5.8 IMS/VS System/Application Design Guide
Input Terminal
Input System
A
Intermediate System
B
D
c
Intermed iate System
Destination System
Figure 5- 11. An Intermediate System
Assume that a message originating in system 1 is defined to be
processed and replied to in System C. To reach System C (destination system) from System A (input system), the message must be routed through either System B or System D as defined by system definition. In this instance, either System B or System D is considered the intermediate
system. By referencing the SYSID table, the intermediate system routes the message to the next link toward the destination system. Whenever there is no direct link between the input and destination systems, there
is always at least one intermediate system. If the configuration had just three systems but the link between Systems A and C was unavailable, a message could be routed through System B as the intermediate system by
reassigning the appropriate links.
B~mQ1~ %~s~£!iQa f~iQ~i!i~§
The definition of each transaction code identifies the priority used to send the transaction to the processing system and the response back to the input system. Based on the specified priorities, three priority groups are considered during processing:
· High priority is assigned to primary requests in the input system whose specified priority is 8 through 14.
· Medium priority is assigned to secondary requests, responses and primary requests in an intermediate system, and primary requests in the input system, whose specified priority is 7.
· Low priority is assigned to any requests in the input system whose specified priority is 0 through 6.
In each priority group, message priority is based on the current transaction priority specified in the input system for primary requests and in the most recent processing system for secondary requests and responses.
a!Q££~~ %~sn§s£ti~n§
If a destination transaction code is stopped fO,r queueing, the action taken by the destination system varies based on the type of request:
· For a primary request that is not conversational or that starts a conversation, IMS/VS sends an error message to the input terminal and cancels the message.
Design Considerations for the MSC Feature 5.9
· For a primary request that continues a conversation or a secondary request, IMS/VS queues the message. If the request is the first one received for that stopped transaction, IMS/VS also sends a message to the master terminal at that transaction~s local system.
Message routing is automatic according to the defined scheme unless a routing exit routine is provided by the user. The routing exit routine is called before the message destination is verified. There are three types of routing exit routines: terminal routing, link routing, and program routing_
The t~~mina! ~Qgting ~~~i £Qgi1n~ executes in the input system and is called on terminal inpat. This routine can inspect the destination specified and, if desired, change it to any local or remote destination_ This routine may examine the first segment of the message to determine what the destination of the message should be. If this routine do~s not change the destination, the originally specified destination is used for routing. IMS/VS will not call a terminal routing exit routine for commands, for any message received from a terminal in preset destination mode, or from a terminal that is continuing a conversation_
In a configuration with horizontally-partitioned applications, the terminal routing exit routine could be used to screen all input messages and route them to the appropriate processing system based on information in the first segment of the input message. If transactions and links are appropriately defined, this routine might also be used to compare the load on the link associated with the specified transaction with other links. The message could be routed to a less-busy link.
The !1nt £QY1i~g ~!i1 ~Qgt1n~ can be used to determine the
destination (system message block) when the transaction arrives at the processing IMS/VS system, thereby minimizing the number of remote transaction definitions per system. This exit routine is called when the transaction reaches the remote processing system_ It can inspect the transaction code and if desired, change it to another transaction code with the same attributes. This routine can examine the first segment of the message to determine what the new transaction coda should be_ If the routine does not change the transaction code, the destination remains the originally specified transaction code.
The 2~g£a! £Qg1ing ~!1t £Qg1in~ is called when an application
program issues a change call while processing a transaction that originated in a remote system. This routine can request that an output message be returned to the input system for destination verification. This allows the applicati6n program to reply to a remote logical terminal without requiring the processing system to know the logical terminal name, thereby minimizing the number of remote logical terminal definitions per system. If two systems use the same logical terminal names for the master terminal, the program routing exit routine can also be used to send a message to the master terminal of either the local system or the input system. It should not be used for program-to-program switches since the routing for transac~ion processing is specified during IMS/VS system definition_ If the program routing exit routine is not used, the destination specified in the change call must be defined in the processing system. Conversational programs cannot use the program routing exit routine.
To maintain system integrity and prevent erroneous operation, an IMS/VS system in a multisystem configuration v~rifies all specified
5.10 IKS/VS System/Application Design Guide
destinations. Remote destination verification occurs on input from a
ter.inal or upon receipt of an application program reply if a remote destination is specified for the message. The routing exit routine, if available, has completed.
Destination verification occurs as follows:
Logical terminal
Ve~!'!~~ fQ~
· Destination type: The original
destination must have been a logical terminal.
Transaction
· Destination type: The original
destination must have been a transaction.
· Transaction attributes: The following attributes must be consistent in the transaction definitions in the ~nput
and destination systems:
inquiry/noninquiry single segment/multiple segment recoverable/nonrecoverable conversational/nonconversational
Conversational transactions must have fixed-length SPAs; SPA size must be the same for all transactions that participate in a conversation.
When an invalid destination is recognized, IMS/VS cancels the message, sends an error message to the input terminal and to the master
terminal of the local system, and logs an invalid request. If the message is conversational, the conversation abnornal termination exit routine is called in the input system and the conversation is
terminated.
A££li£l~!2n f~Q~~!! !2n2t!!! l~~!!n!iion
When an application program abnormally termiantes, and the abnormal termination is not the result of a deadlock situation, a DFS554 message is sent to the master terminal of the system where the abnormal termination occurred. If the input message is still available, an error message that includes the first portion of the input message is sent to the input terminal. When the error message to the input terminal is sent, the DPS554 message includes the logical terminal name of the input terminal.
CONVERSATIONAL PROCESSING
Conversational processing is available to terminals attached to any system in a multisystem configuration to the same extent as in a single system. All transactions used in a conversation must be defined as conversational in each system of the mUltisystem environment. The input system controls the conversational resources for the duration of the conversation. When the input system receives a conversational transaction, it inserts the scratchpad area (SPA) as the first m~ssage segment and routes the message to the destination application program.
Each conversation step can be processed by any system of the multisystem configuration. Program-to-program switches can be routed
Design Considerations for the KSC Feature 5.11
from system to system. SPAs used in multisystem conversations must be defined as fixed-length to allow 1"S/VS to avoid SPA data set updates trom a remote system for program-to-program switches. The SPA size specification must be the same for all transactions that participate in the conversation.
For the most part, multisystem conversations are transparent to terminal operators and application programs. One exception is if a conversational program inserts a message to a response alternate PCB in a remote system. By implication, this destination is in the input system and viII, therefore, be verified by the input system. Destination verification in this instance includes assuring that the specified logical terminal is still assigned to the inputting.physical terminal. If the logical terminal has been reassigned, the input system invokes the conversation abnormal termination exit routine and terminates the conversation. !Q §1s1g§ £2~! i§ '!1~n!~ 1~ !h! !m!li£!tiQf! .e~2gnl!·
The other exception is if an application program that does not execute in the input system uses the SPA to specify a transaction code and thereby pass conversation control to anothgr program. If the specified transaction code is invalid, the input system invokes the conversation abnormal termination exit routine and terminates the conversation. !2 §ta1~§ £Qg! i§ '!1~'ned 12 1h! !221i£!1i2n 2'Qg,!!.
A terminal routing exit routine may be used for the input message that starts a conversation. It is not applicable at any other conversational step since the application program, not the input terminal, provides the destination for continuation of the conversation.
A program routing exit routine cannot be used during conversations.
B!!Qt~ ~~§tinstiQ~ !!rifi£!1io~
Destination verification for program-to-program switches occurs in the system vhere the program requesting the svitch executes. If valid, that system sends the SPA and the message directly to the destination transaction. If invalid, that system returns a status code to the application program.
Destination verification for a message to the input terminal is performed by the input system. The logical terminal specified must still be assigned to the inputting physical terminal. The input system also verifies the next transaction specified in the SPA. If the destination is invalid, the input system invokes the conversation abnormal termination exit routine and terminates the conversation. !Q §tat~§ £~de i2 '~i~~n~~ !Q ia~ !221icaii~ 2~~g'~m.
!Qr~!l ~~Y~r§s1i~~ !~~!i~!1iQ~
A conversation can be terminated by either the application proqram or by the terminal operator. An application program normally terminates a conversation by inserting a message to the input terminal with a SPA that contains either no transaction code or the transaction code of a non-conversational transaction. The terminal operator terminates a conversation by entering either the /EXIT or /START LINE command.
5.12 IMS/VS System/Application Design Guide
The /EXIT command can be used any time during the conversation but the conversation is not terminated until the current conversational step has replied to the input terminal. This means that all data base processing for the current step is accomplished before a conversation ends.
If the input system is shut down and subsequently cold started, all the conversations that it controls are lost. It cancels any conversational messages it receives for input terminals previously involved in active or held conversations.
As in a single system environment, if the input system is shut down and subsequently warm started, all the conversations that it controls are lost if /START LINE is used to start the communication lines. The /RSTABT LINE must be used to retain the previously active or held conversations.
If a remote system is shut down when a conversational step is processing or is queued in it, and is subsequently cold started, all references to the conversation are lost. A conversation lost in this vay must be specifically cancelled in the input system by the /EXIT command.
A conversation is abnormally terminated if anyone of the following occurs:
· The conversational program abnormally terminates.
· An invalid destination in the SPA, or for a conversational response, is recognized in the input system.
· A conversational message is inserted to a terminal whose conversation was terminated.
· Destination verification fails for a conversational message.
· No output was generated in the application program.
The conversation's SPA is passed to the conversation abnormal termination exit routine in the input system along with an indication of the cause of the termination.
Each system in a multisystem configuration is operationally an independent unit. It exclusively owns its own communication resources, which are controlled by its own master terminal.
~ULTISYSTE~ CO~KUNICATION INITIALIZATION
Communication between two IMS/VS systems does not begin until the /RSTART LINK command is issued in each system. The normal procedure would be for the master terminal operator to issue this command when a system is started up. This procedure does not require coordination between master terminal operators. Communication is allowed only if the characteristics of the specified links are compatible. If a required link is not successfully started, messages will wait until the links have been reassigned.
Design Considerations for the MSC Feature 5.13
If a system that has messages queued in it is cold started, these messages are lost. Since the messages that were lost can be from or to terminals and programs in other systems, the impact of a cold start is not limited to the cold started system.
MULTISYSTEM COMMUNICATION TERMINA TION
A /PSTOP LINK command from either of two linked systems terminates transmission on the specified link. When transmission is terminated on one side, its partner in the other system terminates its own transmission and notifies the master terminal operator.
LOGICAL LINK ASSIGNMENTS
Initial logical link assignments (logical link to physical link) are normally made during IMS/VS system definition. The /MSASSIGN command can be used to dynamically make or change a logical link assignment. This approach is used primarily for unscheduled reassignments resulting from failing physical connections or systems.
Since a logical link must !!!!y§ communicate with its partner, the master terminal operators of the two systems must coordinate their assignments to a corresponding physical link. Any type of physical link may be replaced by any other type of physical link.
If a restart is pending on a ~ogical link due to physical link failure, both systems should use the following procedure to reestablish communication through an alternate p~ysical link:
· Reassign the logical link to the alternate physical link·
· Use /RSTART LINK to start the logical link.
SECURITY
Security maintenance in a multisystem environment is performed independently for each system. Password security is verified on terminal input after execution of the terminal routing exit routine. Terminal security is verified on terminal input, and after an application program change call if the call is issued in the input system.
When a destination system receives a message to process, it verifies security based on the input terminal's association with the logical link path. This prevents transactions sent by unautho~zed systems from being processed.
In MSC configurations, if any system uses the Resource Access control Facility (RACF) then all systems must use RACF. User verification and transaction authorization are checked on terminal input. Transactions received from across a link call will be passed to the transaction authorization module for authorization checking, but since the password isn't passed across the link, transaction authorization checking fails if a password is required. Transactions not requiring a password can be accepted. Enhanced security allows the use of RAeF (MVS only) or a user-written security exit routine for validation of the dependent region's authorization to use resources specified in the Application Group Name (AGN) table. For more information on Security provisions, see the chapter, "Design and Control of a Data Base/Data Communication System" in this manual, or the section "Establish IMS/VS System Security (Optional)" in the !~~L!~ !n~l~!!~liQn ~gi~~.
5.14 IMS/VS System/Application Design Guide
RECOVERY
Each system in the multisystem configuration uses the full recovery capabilities of I~S/VS. These capabilities assure that messages are never lost or duplicated within the single system as long as no cold start or emergency restart BUILDQ from an earlier checkpoint is performed, or no log records are lost.
In addition, the ~SC feature assures that messages are never lost or duplicated across a multisystem link as long as no system in the configuration is cold started or no log records are lost. This is accomplished by logging information about a transmission in both the sending and receiving systems. This information is restored during restart and exchanged between the systems once the link is started. The sending system can then dequeue a message that was received by the receiving system but for which the acknowledgment was lost due to a link or system failUre. The sending system can also resend a message that was sent but never enqueued by the receiving system due to a failure in the receiving system. If a system in the multisystem configuration fails to recover, the messages for which it has recovery respons~bility are lost.
Since IMS/VS provides commands to dynamically change link assignments, an inoperable System/310 can be backed up by an alternate System/370. The IMS/VS system that resides in the inoperable CPU can be executed in the alternate CPU once all involved links are properly reassigned by the master terminal operators.
IMS/VS system definition has been expanded to include new macros for mUltisystem facilities. Current terminal and transaction definitions can be used for remote destination definitions since macro operands that do not apply to remote destinations are ignored in remote definitions. The use of Message Format Service (MFS) is the same in a multisystem environment as in a single system environment. If a message is created in one system for a terminal attached to another system, the required message and format descriptions must be available to the system to which the terminal is attached, and definitions with the same name must be defined identically in each system.
The design and tuning recommendations that apply to a single IMS/VS system are applicable to each IMS/VS system in a MSC environment. There are, however, additional considerations, related to resource consumption and demand, that must be take~ into account when defining systems that are part of a MSC configuration.
For IMS/VS transactions that are processad in a local syst~m, the transaction uses ess~ntially the same hardward and software resources that it would in a non-~SC environment. For transactions that are processed in a remote system, additional resources are required. These resources are used to transmit the transaction over physical links to
the remote CPU and to receive the response back from the remote cpu.
Performance considerations are directly related to minimizing the resources consumed by remota processing and balancing the resource demand between several CPITs in a MSC configuration.
Dasign Considerations for the MSC Feature 5. 1S
MINIMIZING RESOURCE CONSUMPTION
To minimize resource consumption, you should:
· Design the environment so that as many transactions as possible are processed locally.
· Provide physical links that go directly from local to remote
systems; no interm~diate systems should be involved in the
transaction routing process. Transactions that must be routed
through intermediate systems require additional CPU activity,
message queue activity, and logging activity.
· Design the Message Queue Buffer Pool in each CPU to eliminate
unnecessary Message Queue I/O activity.
· Use CTC links, if possible, rather than Bse links; the CPU requirements to support a CTC link are lower per message than those for Bse links.
· Define the physical link buffer sizes large enough to hold the
message prefix plus all the segments of most messages.
BALANCING RESOURCE DEMAND
In a MSC environment with two or more cPUs, you should distribute the workload in a way that avoids excessively high utilization of anyone
cpu. You do this by distributing IMS/VS applications and their
associated transactions and terminals between the available CPUs in a way that, dependent, on the comple~ity of the application and the capability of the CPU, avoids overloading each CPU.
If the current design of the data basgs is such that the data bases and their associated applications cannot be distributed across the available CPUs (vertical partitioning), you can:
· Duplicate or share inquiry-only data bases; this allows the data to be referenced by more than one system.
· Split the data bases into several component data bases (horizontal partitioning). The component data bases must be completely independent for distribution among the availableCPUs. For example, it may be possible to divide a data base by key range intervals. The new data bases and their associated applications could then be distributed among the existing IMS/VS systems and the Terminal Routing Exit could be used to route incoming transactions to the correct ISS/VS system. Another possibility is to divide the data base by geographic area. Each IMS/VS system could process the transactions that refer to the data bases for its own geographic area and route transactions that refer to a remote geographic area.
In addition to balancing the workload ~cross CPUs, you may also have to balance the workload on physical links. This occurs when a physical link between two systems is of the BSC type and multiple physical links have been installed. You can balance the workload on physical links by:
· Specifying. during IMS/VS system definition, proper logical link paths and logical links for each remote application.
· Using a user-written Terminal Routing Exit to examine the load on each of the alternative physical links and choose the least busy link for routing.
5.16 IMS/VS System/!pplication Design Guide
\
KSC EXAKPLES
Figures 5-12 and 5-13 illustrate, respectively, horizontal and
L
vertical partitioning.
X IMSIVS System (San Francisco)
Customer Data Base (SFO Region Customers)
BSC Link
y IMSIVS System (Los Angeles)
Figure 5-12. Horizontial Partitioning Design Considerations for the MSC Feature 5.17
X IMSNS System
CTC Link
y IMSNS System
Vertical Partitioning
5.18 Ins/vs Syst~m/l~plication Design Guid~
This chapter describes the Fast Path feature and contains design considerations for its use.
The Fast Path feature provides improved performance for applications that require large transaction rates and use only simple data structures.
The Fast Path feature shares the IMS/VS Data Communication network. The functions of the Data Base system and the Data Communication feature are not reduced when the Fast Path feature is installed. The Fast Path feature complements the eXisting system and does not replace it. A system with the Multiple Systems Coupling (MSC) feature installed can also have the Fast Path feature installed; however, the Fast Path feature cannot receive input from the MSC intersystem links.
The Fast Path feature provides two data base types: Main Storage Data Base (MSDB) and Data Entry Data Base (DEDB).
The Fast Path data bases are simple in structure and provide for improved performance. In addition, Fast Path data bases can be accessed by either Fast Path or IMS/VS transactions.
MAIN STORAGE DATA BASE (MSDB)
An MSDB is designed for efficient processing of the most frequently used data in an installation. The MSDB resides in main storage, which reduces I/O activity.
The amount of data that the MSDBs can hold is limited by the amount of available storage.
An MSDB is a root-only data base; it has no dependent segments. Only fixed-length segments are allowed in an MSDB.
There are two types of MSDBs: Terminal-related and Nonterminal-related.
Terminal-related MSDBs are either fixed or dynamic. Inserts and deletions are not allowed in a fixed terminal-related MSDB but are allowed in a dynamic terminal-related MSDB. Both dynamic and fixed terminal-related MSDBs have the following characteristics:
· The record can be updated only by messages issued from the LTEFM that owns the record. However, the record can be read as a result of messages from any LTERM.
· The name of the LTERM that owns a segment is the key of the segment. An LTERM cannot own more than one segment in anyone MSDB.
· The key does not reside in the segment.
· Each segment in a fixed terminal-related MSDB is assigned to and owned by a different LTERM.
Design Considerations for the Past Path Feature 6.1
· A dynamic MSDB may have a pool of unassigned segments. A segment is assigned to an LTER~ by an ISRT call and =eturned to the unassigned pool by a DLET call.
One use for a fixed terminal-related MSDB would be in an application where each segment contains data that is associated with a logical terminal. In this type of application it would be possible for a batch application program to read the segment (possibly for general reporting purposes), but update would be impossible.
A dynamic terminal-related MSDB can be used as a 'scratch pad' area to simulate conversational processing not available for Fast Path transactions.
Nonterminal-related MSDBs have the following characteristics:
· There is no ownership of segments in a nonterminal-related MSDB.
· No insert or delete calls are allow~d against a nonterminal-related KSDB.
· The key of nonterminal-related MSDB segments can be an LTERM name or a field in the segment. As with a terminal-related MSDB, if the key is an LTERM name; it doesn't reside in the segment. If the key isn't an LTERM name, it does reside in the sequence field of the segment. If the key resides in the segment, the segments must be loaded in key sequence because, when a qualified 5SA is issued on the key field, a binary search is initiated.
The nonterminal-related MSDB without terminal-related keys would be used in any application where a large number of people need access to and update capability for data in a high transaction rate situation, for example, a real time inventory control application, where reduction of inventory could be noted from many cash registers.
An MSDB is defined with DBDGEN in the same way as any other IM5/VS data base. The data base is specified as an MSDB by coding ACCESS=MSDB in the DBD statement. The REL keyword in the DATA SET statement is used to select one of four MSDG types:
· Terminal-related dynamic
· Terminal-related fixed
· Nonterminal-related with LTERM keys
· Nonterminal-related without LTERM keys
The definition of an MSDB data base is covered fully in the I~2L!2
gti!itig§ Rg12~~n£2 ~~n~~!·
All DL/I data base calls, except those that specify "within parent," are valid with one or more types of MSDBs. Because an MSDB is a root-only data base, a "within parent" call is meaningless. Additionally, there is a DL/I call, FLD, applicable to all MSDBs. The FLD call allows an application program to check and modify a single field within an MSDB segment.
6.2 IMS/VS system/Application Design Guide
1:h~ KbQ £~!!
The FLD DL/I call is unique to Fast Path. It allows for the operation on a field rather than on an entire segment. Additionally, it allows conditional operation on a field.
Modification is done with the CHANGE form of the FLD call. The value of a field can be tested with the VERIFY form of the FLD call. These forms of the call allow the application program to test a field value before applying the change. If a VERIFY fails, all CHANGE requests in the same FLD call are denied. This call is described fully in the
!~2L!2 !22!i£~ti2n R~2~~~!!~n~ R~t~~n£~ ~~ng~!·
Allowable processing options for KSDB types are shown below:
Non-related---------------G,R Related flxed-------------G,R Related dynamic-----------G,I,R,D,A
The following chart shows relationships between ~SDB calls, MSDB types and call qualifications. Numbers refer to notes below. X indicates an allowable combination.
1r--D-B--T-Y-P-E----I ----C-A-LL---Q-U-A-L-I-F-IC-A--T-IO-N---,1
rI -D--L-/1---1--M-i-n--- -N-o-n-l-R-e-l-l-R-e-l-l-------I---------I -------1I
1 Call IPROCOPT rellfixldynlNo SSAIUnq.SSAIQual.SSAI
I------!------- ---1---1---1------1-------1--------1
1 GU 1 G
X I X I X, X 1 X ! X
,
1------1------- ---I---I---I------I-------I--------!
1 GHN 1 G
x: 1 X 1 X I X I X 1 X 1
1------1------- ---1---1---1------1-------1--------1
I GN 1 G
X I ~ 1X1 X 1 X 1 X 1
1------1------- ---1---1---1------1-------1--------1
,GHU 1 G
X 1X 1X I X 1 X I X
1
1------1------- ---1---1---1------1-------1--------1
1 REPL 1 R
I 1 I I X I X I X 2, X 2 I
1------1------- ---1---1---1------1-------1--------1
I FLO 1 G/R 1 I X , X 1 X 1 X , X 1 X
,
1------1-------1---1---1---1------1-------1--------1
1 ISRT 1.[
I 1 I XI! X I X 3 ,
1------1-------1---1---1---1------1-------1--------1
I DLET 1 D
, ! 'X 1 X , X 2 1 X 2 !
L--------------------------------------------------J
1. R requir~d for ch~nge. 2. Combination allowed, SSA ignored. 3. Qualification ignored but segment name is used.
Fast Path data base buffers are allocated when a call to update an KSDB record is issued by an application program, a verify call, or if hexadecimal translation is required. The buffers hold the update information until a synchronization point is reached. The maximum number of buffers that the application program can use is dependent on
Design Considerations for the Fast Path Feature 6.3
the number of normal page-fixed buffers (NBA) and the number of additional page-fixed buffers (OBA) specified in the EXEC PARM field.
DATA ENTRY DATA BASE (DEDB)
A Data Entry Data Base (DEDB) is a hierarchical data base containing a maximum of eight segment types (a root segment, an optional sequential dependent segment, and zero to seven direct dependent segments). If the optional seguential dependent segment type is defined, a maximum of six direct dependent segment types can be defined. Sequential dependent segments are stored in chronological order, regardless of the root on which they are dependent. Direct dependent segments are stored in hierarchical fashion, allowing for rapid retrieval.
The DEDB is designed to:
· Collect or gather detailed information ·
· Enhance data base availability ·
· Retrieve and update summary information.
The physical format of the data base enhances the availability of the data. In a traditional IMS/VS data ~ase, the logical data structure is spread across the entire data base, or if multiple data sets are used, the data structure is broken up on a segment basis. A DEDB may use multiple data sets, called areas, with each area containing the entire data structure, as illustrated in Figure 6-1. A DEDB record (a root and its dependent segments) does not span areas. A DEDB can be divided into as many as ~!Q such areas. This organization is transparent to the application program. The randomizing module is used to determine what records go to what area.
Initialization, reorganization, and recovery is done on an area basis. Resource allocation is done at the Control Interval (CI) level so that multiple programs or online utilities can concurrently access an area within a data base, providing they are using different CIs.
Each area in a DEDB is a VSAM data set. An area is op~ned by th~ first call to it from a program that is eligible to access it. A single area in a DEDB can be stopped by the operator with the /STOP AREA command. A DEDB can be stopped with the /STOP DATABASE command. These commands do not affect programs that are currently scheduled against the DEDB. The /STOP DATABASE command does prevent the scheduling of any new programs needing access to the stopped data base. When a write error is detected in an area, that specific area is stopped and the application program receives an FH status code. ~ven though a part of a data base may not be available (one or more areas are stopped), the data base is still logically available and tr~nsactions using that data base are still scheduled.
6.4 IMS/VS System/Application Design Guide
AREA 1
I
Sequential Dependent Segment
Root Segment
Direct Dependent Segment
I
Direct Dependent Segment
AREA 2
I
Sequential Dependent Segment
Root Segment
Direct Dependent Segment
l
Direct Dependent Segment
AREA
3
I
Sequential Dependent Segment
Root Segment
Direct Dependent Segment
I
Direct Dependent Segment
Figure 6-1.
DEDS Structure Example
A DEDB area is divided into three parts: · Root addressable, · Independent overflow, and · Sequential dApendent part
Design Considerations for the Fast Path Feature 6.5
Root Addressable Part
Independent Overflow Part
Sequential Dependent Part
Figure 6-2.
DEDB Area
DEDB Area Division
Figure 6-3 shows how the DEDB is further divided into units-of-work {UOW) in the root addressable part of the area.
DEDB
________ r~------------------------------~A~----------------------
~,
Area 1
Area 2 A DEDB may contain a maximum of 10 Areas
Figure 6-3. DEDB Units-of-Work
Area 3
The root addressable part of an area is the only part that is actually divided into units-of-work (UOW), as shown in Figure 6-3. A
uow consists of a user-specified number of contiguous control intervals.
Each UOW is further divided into a base section and an overflow section. The base section contains CIs that are addressed by the randomizing
routine. The overflow section contains logical extensions of any CI in the UOW.
The independent overflow part contains empty control intervals that can be used by any UOW in the area. Once a UOW obtains a control interval from the independent overflow part, the control interval can only be used by that UOW. A control interval in the independent overflow part can be considered an extension of the overflow section in the root addressable part as soon as it is allocated to a OOW. The independent overflow CI remains allocated to a specific crow unless, after a reorganization, it is no longer required at which time it is freed.
6.6 IMS/VS System/Application Design Guide
~~~Y~n1isl ~~~!ng!n1 ~s~1
The sequential dependent part holds sequential dependent segments from roots in all units-of-work in the area (see Figure 6-4). The sequential dependent segments are stored in chronological order without regard to the root or unit-of-work that contains the root. When the sequential dependent part is full, it is reused from the beginning. However, before the sequential dependent part can be reused, the user must use the DEDS utility DBFUKDLO to delete a contiguous portion, or all, of the sequential dependent segments in the sequential dependent part.
Units of Work
Base Section
Independent Overflow Part
Sequential Dependent Part
Qv"flow
I
_______________________ ______ ____________ L-\~::::::::::::::::~
~
~_~
~_;~
- L______~
-
v-
Root Addressable Part
~""----------------------------~v,...-----------------------------JI
DEDB Area
Figure 6-4. Storage of DEDS Dependent Segments in an Area
You can specify the size of the UOW, the base section, the overflow section, and the number of UOWs in the root addressable part and in the independent overflow part. This gives flexibility in controlling resource and space management. Each area in a DEDB has its own space management parameters. These parameters may be chosen according to the message volume that can vary from area to area.
Root segments in a DEDS have, and direct dependents may have, a single key field. They can be accessed direcly by this key. The sequential dependent segments can have scan fields by which they can be identified in a sequential scan. Scan fields do not have to be unique. Because the sequential dependent segments are stored in a time-of-entry sequence, there is no guarantee that they will be maintained in scan field sequence. All segments in a DEDB are variable in length and the length may be changed with a REPL call.
Access to a DEDB is by a subset of DL/I calls that are compatible with the standard IMS/VS DL/I calls. Get, replace, delete, and insert
D9sign Considerations for the Fast Path Feature 6.7
calls are provided for root and direct dependent segments. Get and insert are the only calls allowed against a sequential dependent segment.
!22i ~~~~a! f£2£~22~~~
DEDB root segments are stored as prescribed by the randomizing routine, chained in order of ascending key from each anchor point. Each control interval in the base section of a UOW within an area has a single anchor point. Sequential processing using Get Next calls will process the roots in order of:
1. Ascending area number
2. Ascending UOW
3. Ascending key within each anchor point chain
DEDB sequential dependents are stored in the sequential dependent part of an area in the order of entry. Sequential dependents chained from different roots within an area are intermixed in the sequential part of an area without regard to which roots are their parents. Sequential dependents have been specifically designed with a fast insert capability. However, online retrieval will not be as efficient because increased input operations might result. If all the sequential dependents were chained from a single root segment, processing with Get Next Within Parent calls would result in a backward sequential order. (Some applications may be able to use this method., Normally, sequential dependent segments are retrieved sequentially only by using the sequential dependent scan utility which is described in the I~2L!2 Y1i~i!i~§ R~~~£~~£~ ~!n~a~. They are then processed by offline jobs.
Di£~£! ~2E~~~~1 ~~g!~a! f£2~2§ing
The DEDB maintains processing efficiency while supporting a hierarchic physical structure with direct dependent segment types. A maximum of seven direct dependent segment types are supported (only six if a sequential dependent segment is present) ·
Direct dependent segment types can be efficiently retrieved hierarchically and the user has complete online processing control over the segments. Supported processing options are insert, get, delete, and replace. The length of the segment can be altered by the user using the replace function. The DEDB space management logic attempts to store an inserted direct dependent in the same control interval that contains its root segment. If sufficient space is not available in that CI, the Root Addressable Overflow and then the Independent Overflow portion of the Area are searched.
Physical chaining of direct dependent segments consists of a Physical Child First Pointer in the root for each defined dependent segment type and a Physical Twin Forward pointer in each dependent segment.
~ED~ ~In£££Qni~~!i2a prQ£~22i~g
The physical update of a DEDB root and direct dependents is held in abeyance until a synchronization point has been reached and synchronization processing is completed successfully. This sequence eliminates the need for backout processing in case of a user program
6.8 IMS/VS System/Application Design Guide
failure. DEDBs are physically updated after the associated log records are written.
DEDB sequential dependent segments are gathered at synchronization processing time but are not written to the physical data base until a control interval is filled. Logging takes place during synchronization processing, and changes are discarded if a failure occurs.
~~tin~n~ ~g~~ ~!i! ~!~~~
A DEDB is defined through the DBDGEN process as are all other IMS data bases. To specify that a data base is to be a DEDB, !CCESS=DEDB is specified in the DBD statement. Further information on generating a DEDB is contained in the I~L!§ Yiili1i~2 R~t~r~n£~ ~!nY!l.
Prior to the initialization of DEDB areas, the areas (data sets) must be defined via VS!M Access Method Services. Following is an example of Access Method Services input that defines a VSAM cluster which will later be defined in a DBDGEN as an area with the name of AREA':
DEFINE CLUSTER (NAME (AREA') VOLUMES (SER123) NON INDEXED CYLINDE RS (1) CONTROLINTERVALSIZE(1024) RECORDSIZE(1017) SPEED) DATA (NAME (DATA 1» CATALOG (USERCATLG)
The following keywords have special significance when defining a DEDB area:
· NAME: The name supplied for the cluster is the name subsequently referred to as the areaname. The name for data component is optional.
· NONINDEXED: DEDB areas are not indexed clusters.
· CONTROLINTERVALSIZE: The value supplied must be 512, 1024, 2048, or 4096 bytes due to a VSAM ICIP requirement.
· RECORDSIZE: The record size is always seven less than the control interval size. These seven bytes are used for VSAM control information at the end of each control interval (see "OEOB OBD Space Considerations").
· SPEED: This keyword is recommended for performance reasons.
· CATALOG: This parameter may be optionally used to specify a user catalog.
Design Considerations for the Fast Path Feature 6.9
DEDB DBD SPACE CONSIDERATIONS
When designing a DEDB, attention must be paid to ensure that sufficient space is allocated in all parts of the area. To do this, the designer must know how much space is available in each control interval for data and how much space is used for Fast Path and VSA" control fields. Fast Path control fields consist of both control-interval control fields and SEGH control fields (segment prefixes).
The folloving figures illustrate control interval and segment formats.
r---------------------------------------------------------------------,
I FSE I CI I RAP I
SEGMENTs and FSEs
RBA
RDF
CIDF I
I AP I TIP I
I
L---------------------------------------------------------------------J
FSEAP 2 bytes
Offset to the first Free Space Element. These two bytes are unused if the CI is in the Sequential Dependent Part.
CITYP 2 bytes
Describe the use of this CI and the meaning of the four next bytes.
RAP
q byt~s
Root Anchor Point if this CI belongs to the Base
Section of the Root Addressable Area. All Root
segments randomizing to this CI vill be chained off
this RAP in ascending key sequence. There is only
one RAP per CI.
Note: In the Dependent and Independent Overflow Parts, these q bytes are used by FP for control information. There is no RAP in sequential Dependent CIs.
RBA
q bytes
RBA of this CI
RDF
3 bytes
Record Definition Field (VSAK Control Information)
CIDF 4 bytes
CI Definition Field (VSAM Control Information)
Note: CI control field length in Root and Overflow parts: 19 bytes CI control field length in Sequential Dependent part: 15 bytes
Figure 6-5. Control Interval Format
6.10 I8S/VS System/Application Design Guide
r, -S--I-P ----I --P-T-F---1---S-P-C-F----, --P-C--F-,----//----,-P-C--F-I---L-L--1-------D/A/T-A-------,I LI -C--I--D--I----PT-R- ___1___PT_R_____1___P_T_R__,__//_____1___P_T_R_I _____1_ ------//--------JI
,'1
4
8
4
41
1
1
,
SEGMENT
1<-------------------------------------------->1
PREFIX
SC
byte
Segment Code: 01
PD
byte
Prefix Descriptor
PTF
4 bytes
Physical Twin Forward Pointer. Contains RBA of the
next root in key s6quence.
SPCF 8 bytes
sequential Physical Child First Pointer. Contains RB! of the last inserted sequential dependent under this root. This pointer will not exist if the sequential dependent segment is not defined.
PCF
4 bytes
Physical Child First Pointer. Points to the first
occurrence of a direct dependent segment type.
There can be up to 6 PCF pointers or 1 if there is
no sequential dependent segment. This pointer will
not exist if direct dependent segments are not
defined.
LL
2 bytes
Variable Length of this segment.
Figure 6-6.
Root segment Format twith sequential and direct dependent segments)
r, -S---I -U---I -S-P-T-F---I -L-L---I --------------------D-A//T-A-------------------------,1
L1 -C--I--N--I--P-T-F---I------1-----------
__________
/
/
__________________________
1
J
II 1 8 I
1 ! SEGMENT
1<------------>1
PREFIX
SC
byte
Segment Code: 02
UN
byte
Unused
SPTF
8 bytes
sequential Physical Twin Forward Pointer. Contains RBA of the immediately preceding sequential dependent segment under the same root.
LL
2 hytes
Variable length of this s~gment.
Figure 6-7.
Sequential Dependent Segment Format
Design Considerations for the Fast Path Feature 6.11
r-----------------------------------------II---------- __4 _____________,
I S I U I PTF I LL I
D1 T1
ILC---I--II--I--P-T-R---I -----I-_____________________//__________ ----------------JI
!1 1 4 I
I I SEGMENT I[------------] I
PREFIX
SC
1 byte
Segment Code
UN
1 byte
Unused
SPTF 4 bytes
Physical Twin Forward Pointer. Contains RBA of the
next occurrence of this direct dependent segment type.
LL
2 bytes
Variable length of this segment.
Figure 6-8. Direct Dependent Segment Format
Assume that all root segments in an area will be 200 bytes in length (198 bytes of segment data plus 2 bytes for the length field) and that there will be 850 root segments in the area. There are sequential dependents defined. The control interval length is 1024. There will be 200 sequential dependent segments inserted. Each sequential dependent
segment is 150 bytes long (148 bytes of data and a 2-byte length field). There is one direct dependent segment type define! with an average length of 20 bytes (f8 data and 2 bytes length fi~ld). The expected
frequency of 6ccurrence is one direct dependent per root segment.
Calculate the minimum space required to hold root segments:
1024 19
control interval length Minus control-interval control fields
1005
Equals the amount of space for root segments and their prefixes.
1005 I 244 = 4.1
The space required by the root segment and its prefix is 218 bytes and for the direct dependent and its prefix is 26 bytes. Total space with single occurrence of the direct dependent is 244 bytes.
The amount of root, direct dependent, and prefix space divided by the total length required by a root and its direct dependent equals the number of roots that are likely to fit in one control interval. Because DEDB segments do not span control intervals, the DEDB area will hold four roots per control interval.
6.12 IMS/VS System/Application Design Guide
= 850 I 4 212.5
The m1n1mum amount of space to hold the
defined number of roots with their expected direct dependent segments to
be inserted into this area (850) would then be 213 control intervals.
Calculate the minimum space required to hold the sequential dependent segments:
1024 15
Control interval length Minus control-interval control fields
1009
Equals the amount of space for sequential dependent segments and their prefixes.
1009 I 160 = 6.3
200 I 6 = 33.3
The amount of sequential dependent and prefix space divided by length of one sequential dependent segment and its prefix equals the number of segments that viII fit in one control interval. Because DEDB segments do not span control intervals, this DEDB area viII hold six (6) sequential dependent segments per control interval.
The minimum amount of space required to hold the defined number of sequential dependents to be insert~d into this area (200) would then be 34 control intervals.
The m1n1mum amount of space that must be allocated for this area is 2~7 control intervals (213 for roots and 34 for sequential dependent segments) ·
£2~tQ~m~n£~ £Qn§~~~~~t~QU2 ~n ~Q~~~n~ ~ ~~~~ !£~s
Performance can be significantly improved if the segments to be inserted are first processed through the randomizing module -- vithont actually loading the DEDB area -- and the address of the selected area and anchor point for each segment noted. (See the ~!§1~n f£Q~£~nm!ng li~t~~2n~ ~~ngs! for a complete discussion on the output from the Fast Path data base randomizing module.) The input segments should then be sorted into ascending sequence based upon the area and anchor point obtained from the randomizing module.
For example, if segments S1, 52, 53, and 54 will be randomized by area and anchor point to the sequence 52, 54, 51, and 53, it would be advantageous to place the input segments into this order prior to actually loading the DEDB area. If direct dependent segments are also to be loaded, they s~ould be sorted to follow the root segment in appropriate order. By presorting the input segments, the insertions will be processed in a physical sequential manner and will result in acceSSing and filling each control interval only once during the loading process. When a program that has specified PROCOPT=P, attempts to cross a unit-of-work boundary, the GC status code is obtained. It is recommended that a SYNC call is made to commit the inserts to the DEDB. Use of the PCB option PROCOP=P will hold positioning for subsequent insertions across synchronization point processing. If the segments are not sorted to correspond to the output of the randomizing module, the control interval viII have to be accessed for each insertion of a segment into the control interval. This will result in significant overhead during the DEDB loading process.
Design Considerations for the Fast Path ?eature 6.'3
The 'data base full' condition in a DEDB area indicates that either the sequential dependent portion or one unit of work in the root addressable portion of that area can no longer accept ISRT calls. system and user responses to the condition vary according to which portion is filled and what type of region issued the ISRT call.
The out of space condition for sequential dependents is originally detected at synchronization point processing. If there is not sufficient space for the insert, all updates that occurred during that sync interval are discarded. If the ISRT call was issued from a Fast Path non-message driven or a BMP region, an 'FS' status code is returned to the caller. If the call was from either a Fast Path message driven or an MPP region, the input message is rescheduled for execution. All subsequent calls to insert a sequential dependent to that area (including the rescheduled transaction that originally detected the out of .pace condition) will receive an 'FS' status code at call time.
Oat o~ space in the root addressable portion of the area is indicated to the user in one of two ways. If the ISRT was issued from a Fast Path non-message driven or a BMP region, an 'FS' status code is returned at call time. If the ISRT was issued from a Fast Path message driven or from an MPP region, the region will be abnormally terminated with a user 844 abend code.
There are two techniques Fast Path allows the user to monitor space
utilization within a DEDB Area. The 'post call can be used to track the
sequential dependent portion of the area while the /DISPLAY DATABASE operator command ~ill show the total allocated and the total used control intervals in both the root addressable and the sequential dependent portions of the area.
If the DEDB Area does reach the data base full condition, Fast Path provides two online utilities which may negate the need for doing a data base unload/reload offline to resolve the problem. One of the online utilities, the Sequential Dependent Delete utility, will delete the sequential depe~deut segments in all or part of the sequential dependent portion of the area and thus make this space available for sequential dependent inserts. The other online utility, the Direct Reorganization utility is run against one DEDS Area at a time and is used to remove space fragmentation within that area. Although the reorganization can be limited to the one unit of work which did not allow inserts, it may be advisable to reorganize more or all of the area as any independent overflow space that is freed from one unit of work becomes available for use by any other unit of work within that area.
A Past Path application program execnte~ in a Fast Path IFP region. The IFPs are handled differently depending on the type of program that is running in the region. There are three uses for the regions in which Fast Path processing is done:
· Applications for processing Fast Path messages
· Applications for processing input external to Fast Path
· Utilities initiated against the data bases
Regions executing message-initiated applications operate in a wait-for-input mode. Both, message-driven and nonmessage-driven application programs executing in an IFP region. can access and update MSDBs, DEDBs, and IMS/VS online data bases. Nonmessage-driven
6.14 IMS/VS System/Application Design Guide
application programs can also access as/vs data sets through as/vs data
management.
Regions executing online data base utilities execute concurrently with Fast Path processing. This region type is similar to a nonmessage-driven application program but no user-written application program is needed.
Message-driven application programs cannot terminate normally unless a QC status code is posted in the I/O PCB. Nonmessage-driven application programs cannot terminate normally without releasing the buffers. A SYNC or ROLB call must be issued to release the buffers.
With the Fast Path feature installed, all Fast Path exclusive or Fast Path potential transactions are directed to a Fast Path routine, with a user exit routine, that determines if the transaction is for ?ast Path or IMS/VS.
Messages from a non-Fast Path eligible terminal are routed directly to IMS processing without resorting to the user exit routine. Messages from Fast Path terminals that meet the Fast Path criteria defined by the user exit routine are routed to the Fast Path message handling routines.
Fast Path input and output messages can only be a single segment and must not exceed a fixed maximum length.
The Fast Path online application programs operate in a wait-for-input mode, and must be prescheduled before a transaction can be entered through Fast Path terminals. Parallel scheduling is supported through IMS/VS system definition.
INPUT MESSAGES
Fast Path input messages are limited to a single segment. Every Fast Path transaction is defined to the system as a Fast Path potential or Fast Path exclusive transaction. Potential transactions can be executed under IMS/VS processing or Fast Path processing. A user-written exit is required to analyze the input message to determine if it should be routed to IMS/VS or Fast Path.
A Fast Path exclusive transaction can only be processed by a Fast Path application program.
All input messages that are to be processed under Fast Path must be issued from a Fast Path eligible terminal. A Fast Path potential transaction that is to be processed by IMS/VS can be issued from a terminal that is not Fast Path eligible.
OUTPUT MESSAGES
Fast Path output messages are limited to a single segment. Only one · insert call can be issued against the PCB. The output segment cannot exceed a prespecified maximum segment length defined at system generation.
The output message and the input message are not logged until a Get Unique is issued to the PCB to obtain the next input message. If a failure occurs before this synchronization point is reached, both the input and output messages are lost.
Design Considetations for the Past Path Peature 6.15
The sync process is structured into phases. During phase 1, required resources are obtained and log records are created. Obtaining only the resources required by this sync process allows this sync process to execute in parallel with other sync processes. After phase 1 there is a transition portion during which the log records are passed to the logical logger. After transition, phase 2 continues the necessary updating, and then a cleanup portion of phase 2 releases resources and cleans up control blocks.
Synchronization point processing is performed after a message Get Unique call, a SYNC call, or CHKP call from an application program. The philosophy of Fast Path processing is to hold all application program updates in main storage until a synchronization point is reached. All logging on the IMS/VS log tape is performed during synchronization pOint processing but before the application of data base updates.
If the application program uses the verify function in MSDB calls, the verify will be re-executed during synchronization point processing.
If the conditions are met, the synchronization point processing completes as expected. If the conditions are not met, the synchronization point processing purges all update information and gives the same input message to the application for reprocessing.
Fast Path application programs can retrieve from, as well as update all Dt/I data bases available to IMS/VS online application programs. Fast Path applications can use all facilities associated with alternate PCBs to route messages to any terminal, as well as to IMS/VS transactions. The routing of messages to terminals and transactions can be either local or remote if the MSC feature is co-resident. All calls directed to the I/O PCB or response alternate PCB by Fast Path applications are processed by Fast ~ath. All Dt/! calls that are not directed to a specific PCB are passed to IMS/VS for analysis and processing.
All IMS/VS online applications can retrieve from, as well as update all Fast Path data bases. Only DL/I calls directed to a DEDB or MSDB PCB are processed by !MS/VS/FP; all other calls are processed by IMS/VS. The use of the alternate PCB to send a message to a Fast Path transaction from an IMS/VS transaction is prohibited. Any attempt to use a CHNG call to set the destination of a modifiable alternate PCB for a Fast Path exclusive transaction results in an A1 status code. An ISRT calIon a non-modifiable alternate PCB with a Fast Path exclusive transaction as destination results in a QH status code. Any attempt to message-switch to a Fast Path potential transaction results in the routing of the message to the IMS/VS application program without going through the IMS/VS/FP input Editing/Routing exit routine.
6.16 IMS/VS System/Application Design Guide
abnormal termination avoiding 4.99
example of 4.98 solutions 4.98 abnormal termination, application
program 2.23 absence of segment types 4.146
ACB (~~~ application control blocks) ACBGEN procedure 1.9 access authorization, data 2.74
access method (GSAM)
generalized sequential 1.5 overflow 1.5 access to data, limiting 2.76 alogrithm, message scheduling 2.9
alternate PCB 3.15 modifiable 3. 16
response 3.17 anchor point area, HDAK data base 4.42 application class 2.49
application control blocks (ACB)
creation and maintenance
methods of 1.8
required, when 1.8
utility, use of 1.8
use of 1.11 application program abnormal termination
effects on message scheduling of 2.24 effects on system performance 2.24
program isolation, operation of 2.24 deadlock situation, decision
table for 2.25 application program, batch
design considerations 3.2
checkpoint/restart 3.4 conventions, establishing 3.4
conventions, naming 3.4 conversion to
telecommunication 3.3 COpy or INCLUDE, use of 3.5
DL/I call function, DB batch
processing 3. 10 DL/I call function, DE/DC control
program 3.9 DL/I call, using the correct 3.7 DL/I calls and I/O operations,
relationship between 3.8 DL/I statistics 3.10 performance consideraticns 3.10 program language 3.2
storage allocation 3.11 testing 3.4 written in DL/1 3.11 DL/1 int erface symbolic data description 3.5 application program design, telecommunication 3. 11
application program I/O work area size considerations 4.146
application program, telecommunication design considerations 3.11 batch message processing program ~MP), use of 3.23 buffering 3.23 conversational processing 3.20 conversion, batch to telecommunication 3.18 device class control 3.19 device independence, programming for 3.19 input calls 3. 14 input/output interface 3.11 output calls 3.14 output to alternate destinations 3.16 paging, 2260 and 2265 3.24 PCBS 3.13 program design 3.11 SYSOUT devices, use of 3.20 terminal, program's view of 3.12 environment 3.11 message segment
description 3.13, 3.14
format 3.13,3.14
telecommunication program communication block (TPPCB) 3.12
application programs, useful techniques for 3.23 information passing, program to program methods 3.24 intermediate data bases
example 3. 23
u.se of 3.23
message editing
purpose 3.27
output masks 3.24
application program, user's interfaces, DB system 1.2 language interfaces compatibility 1.15 how to make 2.3 improve throughput, to 2.3 LINKPACK/RAM, in 2.3 purpose 1. 15 REGION/PARTITION, in 2.3 permanently resident in virtual
storage 2.3
areas, DEDB 6.6 independent overflow part 6.4 loading considerations 6.13 root addressable part 6.U sequential dependent part 6.7 space definition 6.7 example 6.9
ask type station, System/3, System/7 2.62
Index I.l
auto delete, paging feature 3.22 automatic rest art of IMS/VS 2.28 available length field (AL) 4.44
backward pointers, use of 4.17 batch and telecommunication applications,
differences between 3.3 illustration 3.3
batch checkpoint facility 2.29 batch checkpoint/restart facility
batch backout utility program use of 3.4
CHKP call, use of procedures for 3.4
functions provided iTO message 3.4
batch checkpoint/restart, DB/DC system 2.29 batch-message programs, for
message-driven 2.29
not message-driven 2.29
message processing programs, for user written, reguirements for 2.30
batch checkpoint/restart, DB system 1.18 batch backout utility program
implemented, how 1.19
use of 1. 19
CHKP call to DL/I DB system action, resulting 1.18 use of 1. 18 user responsibilities 1.18 XRST call to DL/I 1.18 DB system action, resulting 1. 18
batch data base system initializing step one 1.13 step two 1.14
batch-message processing (BMP) definition 2.2 description 2.2
batch message processing program (BMP) checkpoint table 3.23 telecommunication system, in a buffering 3.23
emergency restart 3.23
starting 3.23
uses of 3.23
batch processing definition 2.1,2.2
hatch scheduling, definition 1.2 EI5AM/QISAM, IMS/VS use of 4.148 bit map, aDAM or HIDAM data base 4.43 block identifier 2.59 BMP (batch-message processing) region 2.2 BMP (2~~ batch message processing
program) BSClink 5.4 buffer allocation, MSDB 6.3 buffer pool
concept, explanation of 1.16
statistics, location of 1.16
statistics, retrieval of 1.16
system performa nce, effects of size
on 1. 17
calls, DL/I
backward movement 4.12
data base 4.12 delete, use of 4.13 forward movement 4.12 function code 4.12 get calls, hold form 4.12 get next, use of 4.12
get next within parent, use of 4.12 get unique, use of 4.12 insert, use of 4.12
FIRST 4.13
HERE 4.13
LAST 4.13
purpose 4.12 qualified 4.12
replace, use of 4. 13
segment search argument (55A) 4. 14 unqualified 4.12 checkpoint, EMP 3.22 checkpoint frequency, selection of 2.8 checkpOint ID table 2.29 checkpoint/restart routines, user written requirements 1.19
rules for 1.19 checkpoint/restart routines, writing 2.31 checkpointing batch-message processing
programs 2.30 COBOL READ/WRITE logic 3.7 cold sta rt 5. 14
command functions. protection against unauthorized use of 2.74, 2.75
communica tions network, switched 2.51 computer area security 2.76
concatenated keys 4.5 concatenated segments, deletion of 4.76 contention for resources, message
scheduling effects of ·2.25
control block buffer pools, message
scheduling effects of excessive loading of, effects on system performance of 2.26 size requirements 2.26
control block pools 2.26 control interval, DEDB 6. 10 control sequence flow, DB system 1.15 conventions and procedures, p.stablishing
useful 3.4 conventions, naming 3.4 cpnversational attrib~te
effects on system performance 2. 17 performance, enhancing 2.17
scratch pad areas, residency of 2.17 conversational processing·
advantages 3.20, 3.21 defini tion 3.20, 3.21 description of 3.20, 3.21 example 3.21
SPAS, effect on 3.20
scratch pad areas (SPAS)
use of 3.20
system defini tion of 3.20
1.2 IMS/VS system/Application Design Guide
temporarily suspending ccmmands
used 3.21, 3.22
terminated, how 3.21, 3.22
converting from batch to telecommunication
illustration 3.18 Froced ure 3. 17 COPY, use of 3.5 copy function, printer selection for 3270 2.57 crossing 4.105 crossing a logical relationship 4.104 eTC link 5.4 CTRLPROG, OS/VS macro 2.5
DASD space release, conditions for 4.79 data access limitations 2.76 data base
allocation, deallocation 2.27 cont ent
fields 4.1
segments 4.2
defining 4.2
design considerations
processing time 4.129
design, viability of 4. 142
HDAM, using 4.35
HDAM and HIDAM 4.34
logical (§~~ logical data base)
physical (§~~ physical data base)
segments 4.2
simple HISAM 4.33
space alloca tion, IMS/VS 4. 155
structure rules 4.140
absence of segment types 4.146 hierarchic leg independence 4. 145 new segment type defined at end of
hierarchy 4.143 new segment type in leg of existing
hierarchy- 4.144 new segment type within existing
hierarchy 4.143 restructured data base 4.145 types of 4.1 data base access methods relationships 1.12 when used 1.12 data base buffering 1.16 data base/data communications (DB/DC) syste m 2.1 configuring 2.3 OS/VS options, selection of 2.3 recommended 2.3 required 2.3 design and control of 2.1 fast path feature 6.1 IMS/VS features batch checkpoint/restart 2.29 checkpoint frequency, selection
of 2.8 console support, system 2.54 control of the DB/DC system 2.72 control region, virtual 2.7 dat a bases 2.26
I/O reqllests, active, specification of 2.7
immediate checkpoint 2.8 intelligent remote station
support 2.59 master terminal 2.53 message scheduling 2.9 physical terminal network
design 2.45 physical terminals 2.42 processing regions 2.7 program isolation 2.8 security and privacy 2.72 system queue space 2.8 violation control 2.77 3270 support, IMS/VS 2.56 processing, organization of 2.1
relationship to DB system
differences 2.1
data base description (DBB) generation definition of 1.6 execution of 1.7 re sults of 1.6 data base description block (DBD) pu.rpose of 1.10 requirements, definition of 1.10 'data bas: full' condition 6.14 data base input/output interface 1.2 data language I (DL/I), using 1.3 format, symbolic 1.3 data base integrity, restoring procedure 1.17 data base logging capability 1. 1 data logged, type of 1.17 modifications, data base 1.3 pover failure protection 1.21 power failure, closing after a 1.21 purpose 1.1 recovery, use in 1.17 data base organization auxiliary storage, in 4.10 main storage, in 4.8 data base processing intent, message scheduling conflicting action, defined control of 2. 18 intent levels 2.19 intent list 2.19 in tent specifications 2.20 scheduling algorithm, impact upon 2.20 data base record contents 4.9 data base record, HSAM 4.21 data base record segmentation options 4.137 data base structure rules 4.140 data base system 1. 1 access methods 1.12 application program design 1.9 application program interfaces 1.2 ba tch checkpoint/restart 1.18 advantages of 1. 19
batch processing execution 1.12
control sequence flow 1.14
Index I.3
essential program elements 1.10 ACB 1.11 application program 1.11 DBD 1.10 IMS/VS system modules, list of 1.11 PSB 1.10
execution 1.12 execution and control 1.9 facilities frovided 1.1 GS AM 1. 5, 1. 6 IflS/VS library data sets, used vi th
definitions, list of 1.4
initialization process 1.13
job control language (JC~
considerations 1.14
logging 1. 17
logging capability 1.1
monitor, IMS/YS 1.21
operating environment, batch
scheduling 1.2
as/vs options, differences 1.4
aSH 1.5 phased installation 1.2 pover varning feature, System/370 1.21 STAE/ESTAE, use of
application program, rules for use of 1.20
purpose 1.20
system definition, IMS/VS 1.4
utility programs 1.1
data base system execution 1.12 data base buffering 1.16 execution sequence 1.13 initialization 1.13 data base system flow 1.15 data bases, DB/DC 2.26 allocation, deallocation 2.27 data dictionary 3.5 data entry data base 6.4 access 6.7 areas 6.4 control interval formats 6.10 'data base full' condition 6.14 description of 6.4 defining 6.9 independent overflow part 6.6 insertion of inFut segments 6.13 loading considerations 6.13 root addressable part 6.6 segments 6.4
processing 6.8 sequential dependent part 6.7 sequential processing 6.8 space considerations 6.10 space definition 6.7 STOP commands 6.5 structure 6.4, 6.5 synchronization processing 6.8,6.16 Data Language/I (DL/1) 1.3 call reguest, functions performed 1. 16 calls, physical 1/0 operations
generated by 3.8
data base systeR, with 1.3
DL/I calls, programs that cannot
issue 1.21
1.4 1MS/VS System/Application Design Guide
input calls 3. 16
language interface
purpose 1. 16
output calls 3.17
d,a ta protec tion 2.76
data sets
allocation, deailocation 2.27
da ta set '1 roups
creating, rules for 4.18
defining 4.18
data structure change 4. 155
data structure, secondary indexes 4.123
data transmission block 2.59
data, limiting access to 2.72, 2.76
DB monitor 1.21
(§gg ~!§Q monitor, DB)
DBD (§gg data base description block)
DC monitor 2.78
(.2g~ ~!.2Q mon itor, DC)
deactiva tioD, conversational
processing 3.20
deadlock situation (IMS/YS) 2.8
DE DB (2~S data entry data base)
area definition 6.6
independ~nt overflow part 6.6
root adressable part 6.6
sequential dependent part 6.7
space definition 6.7
synchronization processing 6.7
defining data base sequence fields 4.61
defining physical data bases, options
available
HDAM or H1DAM, for 4.47
H1SAM, for 4.47
HS AM, for 4.47
delete byte
definition 4.3, 4.77
delete call 4.77
DASD space release 4.79
status codes 4.79
forma t of 4.3
logical delete bit 4.3
physical delete bit 4.3
delete call 4.77
delete rules 4.78
additional operations
logical child 4.103
logical pa rant 4.103
physical parent of a virtually
paired logical child 4.103
space release 4.103
deleted segments, accessibility
of 4.93
example " logical parent 4.94
example 2, logical child 4.95
exa IIple 3, ph ysical
dependents 4.96
example 4, third path 4.97
example 5, abnormal termination
possibility 4.98
examples 4.80
logical child logical delete,
of 4.82
logical child
physical delete,
of 4.83
logical child -- physical/logical delete, of 4.83
logical child -- virtual delete, of 4.84, 4.85
logical parent -- logical delete, of 4. 86, 4.87
logical parent -- physical delete, of 4.50,4.91
logical parent -- virtual delete, of 4.90, 4.91
physical parent -- bidirectional virtual delete, of 4.92 introduction
requirements 4.75
selection 4.75
logical child
logical 4.80
physical 4.80
virtual 4.80
logical parent
logical 4.79
physical 4.79
virtual 4.79
physical parent bidirectional virtual 4.80 physical/logical/virtual 4.80
summary
access paths 4.102
OLE~ call 4.102
logical 4.102
physical 4.103
propagation of 4.103
delete 10LET) 4.13
byte, defined 4.3
call 4.78 OLET call 4.75, 4.102 examples of 4.80
logical child, for 4.80
logical parent, for 4.79 physical parent, for 4.EO rules 4.79 status codes 4.78
use of 4.13 deleted segments 4.93, 4.102
accessibility of 4.93 examples of 4.92
logical child 4.96 logical parent 4.95
physical dependents 4.96 third· path 4.97 inserting physically and/or
logically 4.101
deleted segments, accessibility of 4.93 examples of 4.95, 4.97
deletes, HOAM or HIDAM data base 4.44 deletion 4.76
access paths accessibility 4.77 full-duplex 4.77
illustration 4.77 logical parent, from 4.77 physical dependencies, from 4.77 physical parent, from 4.77 prevention 4.77
concatenated segments
illustration 4.76
logical
child 4.76
parent 4.76
physical exception 4.76
dependent segment insertion, HISAM data base 4.28 illustration 4.30
dependent segments, considerations for HDAM, HIDAK 4.148
design considerations, batch application program 3.1
design considerations, data base 4.128 design considerations, MSC 5.15-5.17 design decisions, DB system
generation 1.4 design tradeoffs 4. 140 destination type 5.11 device class control considerations 3.18 device class sensitive terminal I/O,
separating 2.49 device independence logical terminal
provided 2. 46 device independence, programming for 3.20 device input format (DIF) 2.55 device output format (OOF) 2.55 devices supported, list of 2.43 OFSOLELO 1.8 OFS UACBO 1.9 direct access storage space
utilization 4.134 direct address pointers 4. 16 direct reorganization utility, DEDB 6.14 display bypass feature 2.76 distributed free space, HDAM or HIOAM
data base 4.46 OL/I call
(§~~ ~!.§Q. calls, OL/1) function
DB batch processing 3. 10
DE/DC control program 3.9
I/O oferations, relationship to 3.8 using the correct 3.7 DL/1 data base, use of 3.5 OL/I function codes definition of 3.6 segment retrieval function codes, list of 3.7, 3.8 function codes, use of 3.7, 3.8 OL/1 interface 3.5 OL/I statistics 3.10 DLET call (§ss delete (tLET))
edi ting routine 3.24 emergency restart, queue repositioning
during 2.35, 3.22 end-of-data (EeD) 2.13 end-of-message (EOM)
detection, I"5/YS
meaning 2.13
Index 1.5
end-of-segment (EOS) 2.13 detection, I'MS/VS IMS/VS action resulting from 2.14
EOD (end-of-data) 2.13 EOM (end-of-message) 2.13 EOS (end-of-'"segment) 2.13 exclusive control enqueue/dequeue 2.8 ESTAE/STAE, use of 1.20 /EXIT command 3.21, 5.13
facilities provided, IMS/VS data base system 1. 1
Fast Path feature 6.1 access to data bases 6.1 data entry data base {DEDB) 6.4 FLD DL/I call 6.3 IMS/VS, relationshiF with 6.16 main storage data bas~ {MSDB) 6.1 messages 6. 15 multiple systems ceupling (MSC) feature, use with 6.1
processing regiens 6.14
program types 6.14
field call 6. 3 fields, data base segment
contents of 4.4 defining 4.4 key field
purpose of 4.4
maximum number of 4.4
sequence field
limitation 4.5
non-unique 4.5
unique 4.5
symbolic pointer
definition of 4.4
illustration 4.5
types of 4.4 file description entry 3.6 first logica 1 rela ticnship crossed, logical data base 4.105 FLD call 6.3 format control blocks, types of 2.55 formatting 3270 messages 2.54 free space anchor pOint, OSAM data set 4.42 free space chain pOinter field (CP) 4.42
generalized sequential access method IGSAM), restrictions with IMS/VS 1.5
GET NEXT (GN) 3.7 function of 3.7 use of 4.13
get next within parent (GNP) use of 4.13
GET UNIQUE (GU) 3.7 execution time of 3.7 function of 3.7 recommended use 3.10 use of 4.13
GSAM (2g~ generalized sequential access method)
HDAM and HIDA!! data set format 4.40 HDAM data base 4.35
anchor point area 4.42 inserts 4.43
bit map 4.43 bit map block 4.43 dependent segments, considerations
for 4.148
design considerations for 4. 148
forma t of data sets used 4.40
in auxiliary storage 4.35
inserts and deletes 4.43
loading 4.37
options available 4.47
root addressable area, size of
formula 4.37 using 4.35
HIDA! data base 4.37 anchor point area 4.42 inserts 4.43 bit map 4.43 da ta portion, desig n consi der at ions for 4.147
dependent segments, considerations for 4.148
format of data sets used 4.40
free space anchor point 4.42
free space element
available length field (AL) 4.42 free space chain pointer field
(CP) 4.42 task ID field {l~ 4.42 index data ba se 4.38 index, design considerations for 4.147 inserts and deletes 4.43
loading 4.37 after initial load 4.37
I SA M/OSAM, using 4.38
VS AM, us in g 4 · 38
options available 4.47 root segment type pointer options 4.40
hierarchic forwa rd and backward pointing 4.16
hierarchic forward pointing 4.16 hierarchic leg independence 4.145
hierarchic structure, physical data base exa mple 4.10
HISA! and HIDAM key segments 4.46
HISA! da ta base as one data set group 4.21
illustration 4.22 definition 4.21 dependent segment insertion 4.28
into a HISAM data base with one
data set group 4.30, 4.31 description 4.21 HISAl! data base 4.21 loading of 4.23 logical record lengths 4.24 logical records, structures of 4.24
illustration 4.23
options available 4.47
1.6 IMS/VS System/Application Design Guide
root segment insertion 4.26 insertion sequence 4.28 into key sequenced data set control i nte rval 4. 26 sequence of 4.28 when ISAM/OSAM are HIS1M access methods 4.26
secondary data set groups 4.33
multiple data set group 4.34
segment deletion 4.32
simple HISAM 4.33
storage orga ni 'Za ti on 4. 21
HISAM physical storage -- 151M, OSA! or VSAM 4.141 HISAM single data set group 4.21, 4.22 horizontal partitioning 5.1,5.10 HSUJ data base 4.19 data base record, stcring 4.19
data base record on tape 4.19
definition 4.19
DL/I calls, -restriction 4.21
options available 4.47
processing 4.21
search sequence 4.~1
simple HSAM 4.21
storage organization 4.19
I/O requests, specification of active recommendations 2.7
I/O work area size considerations 4.146 IAK command (IMS/VS) 2.53 identifier, block 2.59 identifier, terminal 2.59, 2.60 identity code (terminal security) 2.73 immediate checkpoint 2.8 IMS/VS and last Path 6.16 IMS/VS in an CS/VS system
supported configurations 2.5 IMS/VS program module preload function,
DB systell 2.3 IMSVS. ACBLIB
defini tion 1.4 I!!JSVS. DBDL IB
def inition 1.4 I!SVS.!ACLIB
definition 1.5 IMSVS.PGIUIB
definition 1.4 IMSVS.PROCLIB
definition 1.5 I!S VS· PSB LI B
definition 1.4 II'lSVS.BESLIE
definition 1.4 INCLUDE
use of 3.5
index pointer segment, secondary
index 4.115 additional data in 4.117
fields constant, use of 4.116 duplicate data 4.117 search, use of 4.116 subsequence, use of 4.117
format 4.115 indexes, secondary 4.109
addi tional l/C operations 4.121
alternatives to 4.121 da ta structure 4.111
determining 4.113 definition 4.109 fields, index pointer segment
constant 4.115, 4. 116 duplicate data 4.117 search 4. 1.16 subsequence 4.116
system related 4.117 index pointer segment 4.115
additional data in 4.117
fields, use of 4.116 format 4.115 insertion of 4.118, 4.119 key sequenced data set, usp, of 4.121 maintenance processing 4.118 maintenance exit routine 4.118 options and rules for 4.113 organizatio n 0 f in aux ilia ry storage 4.114
processing sequence 4.111 segment search arguments 4.120 segment types 4. 109
shared index data bases 4.119 storage requirement, increase of 4.121 suppression of entries 4.118
terlls used for index pointer segment type 4.109 index source segment type 4.109 index target segment type 4.109 secondary data structure 4.109
secondary processing sequence 4.109
updated, when 4.121 use of 4.109 i ndi vid ual user pro til e 2. 75 information passing, program to program 3.24
input call, DL/I examples 3.14, 3.15 format 3. 14, 3. 15
input messages, Past Path 6.15 input/output interface, telecommunicaticn
application program 3.11 inquiry logical terminal 2.50
Index 1.7
insert (I sa T) 4. 12 FIRST 4.13 HERE 4. 13 insert call 4.71 status code 4.72 LAST 4.13 logical child insertion 4.71 rules logical insert 4.71 physical insert 4.71 virtua 1 inse rt 4.71 use of 4.12
insert call, the 4.71 inserts and deletes, HDAM and HIDAM data
bases 4.43 inserts, HDAM orHIDAM data base 4.43 intelligent remote station support 2.59
considerations System/3 ask-tYFe station 2.62, 2.70 EBCDIC transparency 2.70 line discipline, control of 2.70 locally attached terminals, with 2.70
mult iline lIultiFcint (!!L!!P) feature 2.70 transmission block, IMS/VS processing of 2.71 using MLMP, design recommendations for 2.70 considerations System/7 line types 2.68 output buffer size, effects on 2.68 polled line, choices 2.68 process control 2.68 transmission block, IKS/VS processing of 2.69 transmission code modes 2.68 conversational Frocessing 2.59 destinations, presetting of 2.59 interface, purpose 2.59 operating modes, System/3, System/7 2.63 ask-tYFe operating mode 2.63, 2.67 basic operating mode 2.63 combining modes 2.63 non-ask-type operating mode 2.66 system definition 2.62 ASK message 2.63 ask-tYFe sta tion, defining 2.62 operating modes, definition of 2.63 output transmission code modes, System/7 2.63 postpone output flag 2.63 postpone type station, defining 2.63 transmission limit, defining 2.63 unlimited transmission, indicating 2.63 system messages, IMS/VS message number, use of 2.61 System/3, Syste m/7 requirements 2.60, 2.61 transmission blocks block identifier 2.59 data type, description of 2.59
1.8 IMS/VS System/Application Design Guide
message identifier 2.59
synchronization type, description of 2.59
terminal identifier 2.59 transmission control
error messages. remote station 2.61 input mode 2.61 logical deactivation, cause of 2.62 output message, remote station
response to 2.61 output mode 2.61
synchronization block, use of 2.61 intent propaga ti on 2. 20
delete option 2.23
get option 2.22 implications of 2.21
insert option 2.22 replace option 2.22 intermediate data bases, using
exa aple 3.24
JCL considerations, data base system 1.14
key segments, HISA! and HIDAM 4.46
leased line, design considerations 2.45
limiting access to data 2.76
line groups, terminal 2.45
. .~
line types, System/7 2.68
~
LINEGRP macro
use of 2.44
load balancing, message scheduling 2.11
loading a DEDB area 6.13
loading a HDAM data base 4.37
local system 5.3
local transaction, Mse 5.7
log tape. restarting lMS/VS 2.28
logging, dual 2.28
logical child -- logical delete, example
of 4.82, 4.83
logical child -- physical delete, of 4.81
logica 1 child -- physical/logical delete,
example of 4.83
logical child -- virtual delete. example
of 4.85
logical child insertion 4.71
logical child/logical twin pointers 4.61
logical child segment 4.54
logical child segment, access paths 4.77
logical child, delete rules for 4.80
logical child, rules for defining 4.62
logical data base 4.104
defining 4.104
illustration 4.107
rules for 4.107
definition 4.104
logical relationships, crossing 4.104
example 4.108
first and additional crossed 4.104
illustration 4.106. 4.107\~
logical destinations, Mse 5.7
~
logical insert rule 4.71 example of 4.73
logical link numbers 5.5 logical link, MSC 5.5, 5.6
logical link path 5.5 logical parent -- logical delete, example
of 4.89. 4.90 logical parent -- physical delete,
example of 4.87 logical parent virtual delete, example
of 4.90
logical parent pOinter 4.61 logical parent segment counter 4.61 logical parent, delete rules for 4.79 logical parent, rules for defining 4.62 logical/physical relationships,
changing 2.50 logical record formats, HISAM data
base 4.24 logical record length distribution 4.156
logical record lengths, HIS AM data base 4.24
logical records, HISAM structure of 4.23, 4.24 logical relationship paths 4.53
logical relationships 4.48 defined in, possible data sets 4.59 defining data base sequence
fields 4.61 description of 4.48 logical child segment 4.54 pointers and the counter used in 4.59
counter 4.61 logical child/logical twin
pointers 4.59
logical parent pointer 4.60
physical parent pointers 4.59 relationship paths 4.53
segment types, relating through a logical child 4.48 method one 4.50 method two 4.51
terms used to describe 4.48 types of
physically paired bidirectional 4.49
unidirectional 4.49 virtually paired bidirectional 4.49 use, reason for 4.48
logical replace rule 4.66
example 4.68 logical terminal class 2.46 logical terminal/physical terminal
rela tionship diagram 2.50 multiple users 2.49 nonswitched network 2.49 one user 2.49
switched ne~work diagram 2.51
lAM command (IMS/VS) 2.52 inquiry logical terminal, the 2.52 logical terminal subpools 2.52 sign on 2.52 system definition, IIlS/VS 2.50
logical terminal pool 2.52 logical terminal subpool 2.52
use of 2.53 logical terminals
concept, definition of 2.46 1M S/VS logical termina 1
attributes of 2.47 device class sensitive terminal
I/O, separating 2.49 input/output 2.47 physical terminals, input
relationship to 2.47 physical terminals, output
relationship to 2.47 network design 2.48
application class 2.49 logical terminal class 2.49 security considerations 2.47, 2.48
main storage data base 6.1 buffers 6.3 defining 6.2 description 6.1 DL/I calls 6.2 dy namic 6.2 nonterminal 6.2 processi ng options 6.3 types 6.1
maintenance exit routine, secondary index 4.118
maintenance processing, secondary indexes 4.118
masks, output 3.24 mass storage system (MSS) 2.81 master terminal
devices allowed as 2.54 inoperable, backup when 2.54 operator, defining security for 2.73 ph ysical location 2.SQ· 3270 2.57 message 3. 13- 3.19 definition of 2.12,2.13 message class 2.10 me ssage -dri ven BMP 2.29 message edi ti nq edit routine, locaticn of 3.24
control region 3.24 control region, IMS/VS 3.24 link pack 3.24 message processing region 3.24 purpose 3.23, 3.24 message editor 2.55 message format service 2.54 message identifier 2.59 message input descriptor (MID) 2.55 message output descriptor (MOD) 2.55 message processing region initiating 2.2 performance for modules preloaded 2.4 message queues emergency restart repositioning MUlT mode processing, when in 2.42 SNGL mode processing, when in 2.42 index 2.35, 2.41
Index I.9
logical terminal, for 2.32
operation of 2.41
system failure, tii th 2.42
queue data sets
block size 2.33
destroyed, if 2.34
preformatted 2.34
relationship bettieen 2.33
queue recoverability 2.34
queue storage 2.34
reuse of 2.34
structure of 2.33
transaction code, for 2.32
message routing, ~SC 5.6 message scheduling algorithm 2.10
application program abnormal
termination 2.23
deadlock situations 2.25
effects on system
performance 2.24, 2.25 program isolation, operation of 2.24, 2.25 synchronization FOint, program isolation 2.24, 2.25
contention for resources 2.25, 2.26
control block buffer pools
excessive loading, system performance effects of 2.25, 2.26
size requirements 2.25, 2.26 conversational attribute
effects on system performance 2.17
performance, enhancing 2.17 data base processing intent 2.18, ~.19
intent levels 2~19
intent list 2. 19 load balancing
definition of 2.11
message class a nd region class,
by 2.10
conflict resolution 2.11
message selection process 2.10
scheduling options 2.10
multiF1e/single segment messages
end-of-data IEOD) 2.12
end-of-message (EO~) 2.13
end-of-segment IEOS) 2.13
exa IIple 2. 13
primary concerns when
selecting 2. 14
non-update transaction processing
definition of 2.17
output limits, application program
results of 2.12
use of 2. 12
processing intent specifications 2.20 exclusive 2.21 intent types 2.20, 2.21 options 2.22 read only 2.21 update 2.21 processing limits
limit count, use of 2.12
response and non-response messages
recommendation 2.17
scheduling concurrency, factors effecting 2.21
delete option 2.23
get option 2.22
insert option 2.22
replace option 2.22
selection priorities
explana tion of 2. 11 limit pr iority 2.11 normal priority 2.11 zero priority, assigning 2.11
terminal response mode defini ti on 2. 15 line performance, effects on 2. 15 options 2.16
message scheduling algorithm definition of 2.9 influences on, design 2.9
message scheduling, definition 2.9
message segment format 3.15 message segments
definition of 2.13 message Fast Path 6.15 modes of response 3.17 modifications, data base
logging of 1.3
module preload function 2.3
monitor, IMS/VS DB activation/deactivation of 1.21
description of 1.21
function of 1.21
recommendations for use
collecting data, for 1.21 testing application, for 1.21 tuning system, for 1.21
monitor, I~S/VS DC description of 2.78 function of 2.78
recommendations for use collecting data 2.78 integrating applications, effects of 2.78,2.79 testing applications 2.78 tuning system 2.78
/MSASSIGN command 5.5, 5.14
MSC fea ture l.~~~ mu1 ti pIe syst ems coup ling
(M5C) fea ture) MSU NK macro 5.5 MSNAME macro 5.6
MSDB 6.1
(2~~ ~l2Q main storage data base) M5S 2.81 !T~ link 5.4 multiline multipoint (MLMP) feature,
system/3 2.70 multiple data set group segmentation,
HISA~ 4.139 multiple data set group, HISAM data
base ij.34
multiple data set groups, HISA~ 4.132 multiple data sets, DEDB 6.4 multiple systems coupling 1M SC)
feature 5.1
comaunication initialization,
multisystem 5.13
I.l0 IMS/VS system/Application Design Guide
communication termination,
multisystem 5.14
compatibility 5.15
conversation termination 5. 12
abnormal 5.13
normal 5.12
conversational processing 5.11
description of 5.11, 5.12
scratchpad areas ISPAs) 5.11
description cf 5.1, 5.3 design considerations 5.15, 5.16
overhead, minimizing 5.16
wcrkload, balancing 5.16
destination system 5.8, 5.9
destination terminal 5.8, 5.9
stopped transactions 5.9
destination verification 5.10-5.12 examples 5.17, 5.18 Fast Path feature 6.1 horizontal partitioning 5.1, 5.10, 5.17
input system 5.7, 5.8 input terminal 5.8
intermediate system 5.9
link security 2.73
(§§§ ~l§g terminal security)
links 5.7
logical link 5.5-5.7 assignments 5.14 partners 5.5
remote logical terminals 5.5 ph Ysi cal lin k 5.4
types of 5.4
local destination 5.7
local system 5.3
local transaction 5.7
logical destinations 5.1
local 5.7 remote 5.7
logical length path 5.7
message routing 5.6
multiple systems verification
utility 5.1
overhead, minimizing 5. 16
physical link 5.4
recovery capabilities 5.15
remote destination 5.7
remote logical terminals 5.5
remote systems 5.3
remote transactions 5.7
priorities 5.9 routing exit routines 5.10,5.11
program routing 5.10
terminal routing 5. 10
routing path 5.6
security maintenance 5.14
system identification 5.6
examples of 5.6, 5.7 vertical parti Honing 5.1, 5. 16, 5. 18 workload, balancing 5.16 multiple systems verification utility 5.7 multipoint line, definition 2.44 multisegment and single segment messages message scheduling 3.15 multisystem envircnment 5.1, 5.3, 5.7
NAaE macros 5.5 nalles, logical terminal 2.53 naming conventions
advantages of 3.4 dictionary, responsibility for 3.5 requirements, IMS/VS 3.5 network design 2.48 network design, physical terminal 2.45 line groups 2.44 polled terminals
types of polling 2.44 switched network 2.44 non-message driven EaF 2.29 non-update transaction processing, message scheduling for 2.17 nonswitched communication lines, definition of 2.44 nonswitched network 2.50 nonterminal-related aSDB 6.1
operating modes, System/3, System/7 2.63 operating relationshiFs, program
description 1.2 illustration 1.3 options and rules for secondary indexes 4.113, 4.114 options, recommended OS/VS 2.5 options, required CS/VS 2.5 organizations, physical data base 4.14 OS/VS data files, use of 3.5 OS/VS options 2.5 required 2.5 special access method (OSAM) 2.5
allocation of data sets 2.5 pre-allocation restrictions 2.6
IEFBR14 utility 2.6 use of 2.5 OSA" (~~~ overflow sequential access method) OSAM data sets, allocation of 2.5 OS!", DB system use of 2.5 output call, DL/I example 3.14
format 3. 14
output device, control characters carriage retuJ:n characters 3.19 drum address characters 3. 19 new line symbols 3.19 purge call, tL/l 3. 19 output limi~s, message scheduling 2.12 ou~put masks 3.24 output message, remote station response to 2.61 output messages, Fast Path 6. 15 output to alternate destinations al ternate peE 3. 16
illustration 3.6
modifiable alternate PCB
advantages of 3. 16 definition 3.16 modifying, example of 3.16 use of 3.17 use, limitation of 3.17
Index I.l1
response alternate PCB
purpose of 3.17
use of 3. 17
sending 3. 15 output transmission code modes,
System/7 2.62 overflow data set 4.33 overflow sequential access method 10 SAM)
advantages to I~S/VS DB system 1. 5
functions with 1MS/VS DB system 1.5
requireme nts, DE system 1.5
page-reguest indicator 3.22 paging faature, 2260 and 2265 3.22
auto delete, operation with 3.~2 function of 3.22 page-reguest indicator 3.22 using 3.22 partners 5.5, 5.14 password and/or terminal security defining 2.73 display 2.76 passwords, design of 2.74 PCB 3.12,3.13,3.14-3.17 performance considerations, batch application program 3.10
buffering 3.23, 1. 16
conversational Frocessing 3.20
conversion, batch to
telecommunication 3.17
device class control 3.18
device independence, programming
for 3.18 input calls 3.14 input/output interface 3.11 output calls 3.14, 3.15 output to alternate destinations 3.15 paging, 2260 and 2265 3.22 storage allocation 3.11 tuning, using statistics for 3.10 performance considerations, modules preloaded in MPPs 2.4 physical child definition 4.9 physical child last pointer 4.17, 4.18 physical child/physical twin pointers benefits of 4. 16
rules 4.16
use of 4.17
physical data base concepts of 4.1
calls 4.12, 4. 13
fields 4.4, 4.5
segments 4.2, 4.3
structure 4.6
defining options
HDAM or HIDAM, for 4.47, 4.48
H1SAM, for 4.47
HS AM, for 4.47
definition 4.1
HDAM and HII:AM
advantages 4.34
organization in storage 4.14
data set groups 4.18
HDAM 4.35
HIDAM 4.37
HI SAM 4.21
HSA~ 4.19
methods of 4. 14
pointers 4.14
organization of 4.14
rules for defining logical
relationships in
logical child 4.62
logical parent 4.62
physical parent 4.63
physical data base hierarchy, defining 4.9 physical delete rule 4.102 logical, treated as 4.101 violation, detection of 4.100 physical insert rule 4.11 example of 4.72 physical insert rule, example of 4.72 physical link, MSC 5.4 physical/logical terminal relationships 2.50 physical parent def inition 4. 9
physical parent -- bidirectional virtual delete, example of 4.92
physical parent pointers, data base 4.61 physical parent, delete rules for 4.80 physical parent, rules for defining 4.63 physical replace rule 4.66
example 4.67 physical terminal network deaign 2.45 physical terminals 2.42
definition 2.42
input/output assignments 2.50
LINEGRP macro 2.44
logical terminals, relationship
to 2.50 types of, supported 2.43 physical terminals, input relationship to 2.50 physical terminals, output relationship to 2.50 physical twin definition 4.10 illustration 4.11 physically paired bidirectional logical relationship use of 4.56 pointers, data base dir9ct address 4.14
illustration 4.15
types of 4.14
hierarchic 4.16
illustration 4. 17
options 4. 16
physical child/physical twin 4.16 backward pOinters 4.17 benefits of 4.16 illustration 4. 18 rules 4.16 use of 4.17 pointing, hierarchic forward 4. 16
1.12 IMS/VS system/Application Design Guide
peinting, hierarchic forward and backward 4.16
polled terminals 2.44 pool, lcgical terminal 2.52
pool manager, MFS 2.55 pools, control block 2.26 Fostpone type station, System/3,
System/7 2.62 power warning feature 5/370 1.21 pre-allocation, OSAK data set 2.5
multiple volume data set 2.6
restrictions 2.6
primary requests 5.8
primary groups 5.9
priorities, message scheduling 2. 10
process control System;7 2.6C processing intent specifications,
message scheduling 2.20 intent types
EXCLUSIVE 2·.21
BEAD ONLY 2. 21
UPDAU 2.21
scheduling options 2.20
processing limits, message scheduling 2.12
processing regions
defining maximum 2.7
initialization 2.2 types 2.1 processing secondary index as a data base
guidelines and restrictions 4.120 processing sequence, secondary
indexes 4.111
processing, batch (§!~ batch processing) program communication block (PCB) ~6
. definition 3.6
program controller, DB system environment
functions 1.13 program isolation 2.8
application program abnormal termination 2.23 synchronization point, definition of 2.24
call function (BOLL) 2.25 definition 2.8
dynamic log, maintenance of 2.23, 2.24 cperation of 2.23, 2.24
selection for termination 2.25 uses for 2.8
program specification block (PSB) 1.7 description of 1.10 generation of 1.7 purpose of 1.7 segment se nsi ti vity data independence, for 1.10 levels of 1.10
program specification block (PSB) . generaticn
illustration 1.7
PSEGEN procedure 1.7
results of 1.7
use of 1.10
program-to-Frogram switch 5.6, 5.10 program types, Fast Path 6.14 programming language, choice of 3.2
programs, testing 3.20 protection of command functions 2.74 P5B (§~~ program specification block) /PSTOP link 5. 14 purge call, DL/I 3.19
illustration 3. 19 output termination, to cause 3.19
queue data sets block size 2.33, 2.34 relationships 2.33, 2.34
queues message 2.32 operation of 2.33, 2.34 preformatted 2.33, 2.34 recoverability of 2.33, 2.34
recovery capabilities, MSC 5.15 region class 2.10 regions, types of 2.1 remote logical terminals 5.5 remote station, intelligent 2.59 remote system 5.3 remote transactions, M5C 5.7 reorganization, data base 4.150
HDAM and HIDAM data tases 4. 152
HISAM data bases 4.151
reorganization interval 4.151
replace (FEPL) 4. 13 introduction 4.64 rules 4.66
coding 4.65
illustration 4.70
logical 4.66
physical 4.66
virtual 4.66
status code 4.66 use of 4.13 replace call, the 4.66 /RSTART LINE command 5.13 restarting the IMS/VS control region 2.28 restructured data base 4.145 root segment definition 4.7 insertion, HISAM data base 4.26 insertion sequence 4.27 root segment type pointer options, HIDAM data base 4.40 routing exit routines, MSC 5.10, 5.11 link input 5. 10
scheduling priority for specified transactions 2. 11
scratch pad areas (SPAs) definition of 2. 17
secondary data set groups, HISAM data bases
description and use 4.33
overflow data set 4.33
when used 4.33
secondary indexing (§~~ indexes, secondary)
Index I. 13
secondary request 5.8 security and privacy, DB/DC system 2.12
command functions, protection against authorized use of 2.74 class Frofile system 2.14 individual user profile 2.74 Fasswords 2.74
display bypass feature 2.76 identity code 2.73 installation responsibilities 2.11 levels of security 2.18 limiting access to data 2.76 log tape, using 2.77 password security 2.73
RACF 2.72 recommendations for design 2.72 resource access security 2.74
application group 2.74 security maintenance utility,
(SMU), IMS/V5 2.72, 2.74, 2.75 security violation attempts,
recording of 2.71 signon verification security 2.75
system log 2.75 switched terminal security, 3270 2.77 terminal security 2.13
link security 2.73 transaction codes, restricing antry
of 2.73 transaction command security 2.75 violation control 2.77 3270 switched terminal security 2.77 security maintenance, MSC 5.7 security maint~nance utility, IM5/V5 2.72 security violaticn atte~pts, recording of 2.74 security, design considerations for system 2.72 5EGM statement, use of PAREN'I= operand 4.9 segment deletion, HISA8 data base ISAM/CSAM 4.32 VSAM 4.32 segment edit/compression 4.126 considerations for ~se 4.128 conversion to use
steps for 4.127
data compression
definition and use 4.127
descripticn of 4.125-4.121
exit 4. 125
illustration 4.126
key compression
definition and use 4.127 segment types, compressible 4.127 use of 4.125 segment formats, data base data portion 4.3 delete byte 4.3
delete byte, illustration 4.4 I/O 3.8 use of 4.3 illustration 4.3
prefix 4.2
related, how 4.3
segment code
use of 4.3
types 4.3
fixed length 4.2
variable length 4.2
segment oriented program 3.1 segment search arguments (5SAs) 3.7, 3.9 definition of 4.14 illustration 3.8 definition of 3.1
parts of 4.14
qualified 3.7
unqualified
definition of 3.7 segment search arguments, secondary indexes 4.120 SEgment types, relating through a logical child 4.49 segments, data base 4.2 data portion 4.2 defining 4.2 definition 4.:2 fields 4.4 formats 4.2 delete byte 4.3 d~lete byte, illustration 4.4 illustration 4.3 segment code 4.3 length 4.2
limitation of 4.2
prefix 4.2
SEGM statement 4.2
types 4.2
segments, data entry data base 6.4 access 6.1 formats 6.10-6.12 length 6.7 processing 6.8 segments, variable length advantages of 4.122 conversion to 4.125 forllats 4. 123 ill ustra tion 4. 124 loading 4.122 performance, effects on 4.124 storage requirements for, additional 4.124 uses 4.122 sequential dependent delete utility. DEDB 6.14 shared index data bases, secondary indexes 4.119 sign on, switched network lAM command (IHS/VS) 2.51, 2.53 names, logical terminal 2.53 verification security 2.75 simple HISAM data base 4.33 single data set group segmentation, HISAM 4.138 size of root addressable area, formula for 4.35 SPA 3.20, 5.11 space allocation, IMS/VS 4.155 space search algorithm, HD 4.44
I.14 IMS/VS System/Application Design Guide
space utilization, direct access
storage 4. 134
5SA 4. n
5TH/ESTlE, use of 1.~1 /STABT LINE command 5.12
status code, insert call 4.72 status code, replace code 4.66
storage sequence of segments, HISAM data base record 4.131
structure, physical data base 4.6 data base record contents 4.9 data base structure in storage 4.1 defining 4.6 developing, example 4.1 hierarchy of segment types 4.1 crea ting 4.1 hierarchy, defining 4.9
hierarchic structure 4.10
physical child 4.9
physical parent 4.9
physical relationships 4.9
root segment 4.9
SIGH statement, use of 4.10
level
order of dependence 4.9 sub pool, logical terminal 2.53 suppression of entries, secondary
indexes 4.118 switched communication lines, definition
of 2.43 switched network 2.51
design considerations 2.45 switched terminal security, 3210 2.71 synchronization block, use of 2.61 synchronization process, Fast
Path 6.8, 6.16 synchronizaticn transmission block 2.59 SYSID system identification 5.6 SiSOOT devices, use of
program testing 3.20
spocloption 3.20
system console, CS/VS
functions available 2.54 primary purpose 2.54 system definition, IKS/VS 2.50, 2.1 system definition, System/3, SystelD/1 2.62 system execution, data base 1.12 systelD generation design decisions, tB 1.4 system queue space, requirements for 2.8
system related fields, secondary indexes defining 4.117
types of 4.115
/CK 4.118
/5X 4.118
system identification, !lSC 5.6 System/3, design considerations unique
to 2.70 System/3, System/1 requirements 2.62 system/1, design considerations unique
to 2.68
task ID field (ID) 4.42 telecommunication application program
design 3.11 (§~~ ~!~~ application program, telecommunication)
terminal commands, authorizing use of 2.73
terminal configurations supported 2.42-2.44
te=minal identifier 2.60 terminal-related MSDB 6.1
fi xed 6.1
dynamic 6.1
terminal response mode definition 2.16 line performance, effects on 2.16 options 2.16 terminal security, design considerations 2.13 terminal types, selection of 2.42-2.44 terminal, master 2.53 terminals, polled 2.44 testing, application requirements for 3.4 tradeoffs 4. 140 transaction attributes 5.11 transaction command security 2.75 transaction oriented system 3.1, 3.3 transaction codes 2.9 restricting entry of 2.73, 2.15 transactions application programs, relation to 2.9 attributes, defining 2.9 transmission block System/3, IMS/VS processing of 2.10, 2.71 transmission block System/1, IMS/VS processing of 2.69 transmission blocks 2.59 transm~ssion control 2.61 transmission limit, system/3, System/1 defining 2.63
una uthorized processing, pr evention of (see transacticn command seciirl ty) 2.15
unbuffered/buffered terminals, considerations 2.46
unidirectional logical relationship use of 4.55
unit-of-work, DEDB 6.6 utili ties
data base recovery 4.149 data base reorqanizatiQn 4.150
HDAM and HIDA~ data bases 4.152 HIS1M d at a bases 4.151 reorganization interval 4.151 utility control facility 4.155 utility, MFS 2.54 utilizing slack space, HISAM 4.135
Index 1.15
violation control 2.77 virtual partitioning 5. 1 virtual control region
design considerations 2.7 virtual control region, IMS/VS 2.7 virtual insert rule 4.71
example of 4.74 virtual replace rule 4.66
example 4.69 virtually paired bidirectional logical
relationshi~ 4.57 defining fields in logical child segment tYFes 4.59
discussion of 4.58
use of 4.57
VSAH Access Method Services and DEDB 6.9
zero priority transaction code 2.11
3270 information display system 2.56 copy function 2.57
candidate printers 2.57 example 2.58
output, format of 2.57 printer, selection of 2.57 purpose 2.57 requested by 2.57 master terminal support comprised of 2.59 message format service (MFS) 2.54 format control blocks, types
of 2.55
major components 2.55 major operations, overview 2.56 message editor 2.56 pool manager, MFS 2.56 pool manager, MFTEST 2.56
utility, MFS 2.56 overview of 2.56
3284 model 3 printer
message transmission to,
output 2.58 3284-3 printer 2.58 3850 MSS 2.81
I.16 IMS/VS System/Application Design Guide
·
,
SH20-9025-6
~
(f)
<:
(f)
..o<(.1...),·
::J
- ---------= ------ ---- -------------.--.- .---=--®
International Business Machines Corporation Data Processing Division 1133 Westchester Avenue, White Plains, N. V. 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.Y., U.S.A. 10601
IMS/VS Version 1 System!Application Design Guide SH20-902S-6
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 ofIBM 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.
o11>
z
t
t
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-9025·6
Reader's Comment Form
...·..... eo··· .......... ,.......F.o..ld...a·n.d..T·a.p..e......·..................·..·...·..·...·..... ,. ...·...·.....··.......·...··.·.····...····.····.·
Business Reply Mail
No postage necessary if mailed in the U.S.A.
First Class Permit Number 6090 San Jose, California
Postage will be paid by:
IBM Corporation
P.O. Box 50020
Programming Publishing
San Jose, California 95150
."
:::!.
:J
[
3'
c
···································· t ..................................................................................................... .
Fold and Tape
en l>
---- -------- ~ _------g .---- ®
'j
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, N.Y. 10604
IBM World Tradp Americas/Far East Corporation Town of Mount Pleasant, Route 9, North Tarrytown, N.Y., U.S.A. 10591
IBM World Trade Europe/Middle East/Africa Corporation 360 Hamilton Avenue, White Plains, N.Y., U.S.A. 10601
FUJITSU fi-6130Zdj Adobe Acrobat 9.0 Paper Capture Plug-in