DBRC Guide and Reference

IMS Version 7

DBRC Guide and Reference

SC26-9428-01

��

IMS Version 7

DBRC Guide and Reference

SC26-9428-01

��

Note

Before using this information and the product it supports, be sure to read the general information under “Notices” onpage xvii.

Second Edition (June 2001)

This edition replaces and makes obsolete the previous edition, SC26-9428-00. The technical changes for this versionare summarized under “Summary of Changes” on page xxiii. The technical changes for this edition are indicated by avertical bar to the left of a change.

© Copyright International Business Machines Corporation 1974, 2001. All rights reserved.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . xixProduct Names. . . . . . . . . . . . . . . . . . . . . . . . . xix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiPrerequisite Knowledge . . . . . . . . . . . . . . . . . . . . . xxiHow to Use This Book . . . . . . . . . . . . . . . . . . . . . . xxiHow to Read the Syntax Diagrams . . . . . . . . . . . . . . . . . xxiRelated Reading . . . . . . . . . . . . . . . . . . . . . . . . xxiHow to Send Your Comments . . . . . . . . . . . . . . . . . . . xxii

Summary of Changes . . . . . . . . . . . . . . . . . . . . . xxiiiChanges to The Current Edition of This Book for IMS Version 7 . . . . . . xxiiiChanges to This Book for IMS Version 7 . . . . . . . . . . . . . . . xxiiiLibrary Changes for IMS Version 7 . . . . . . . . . . . . . . . . . xxiii

Part 1. How to Use DBRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. DBRC in the IMS Database Recovery Process . . . . . . . . 5What Is DBRC? . . . . . . . . . . . . . . . . . . . . . . . . . 5

DBRC Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 6DBRC Components . . . . . . . . . . . . . . . . . . . . . . 6IMS Recovery utilities and functions . . . . . . . . . . . . . . . . 7Recording Recovery-Related Information . . . . . . . . . . . . . . . 8Generating JCL . . . . . . . . . . . . . . . . . . . . . . . . 8

When Should You Use DBRC? . . . . . . . . . . . . . . . . . . . 10Initializing DBRC . . . . . . . . . . . . . . . . . . . . . . . . 10

Specifying When DBRC Is to Be Used . . . . . . . . . . . . . . . 10Registering Databases and Database Data Sets . . . . . . . . . . . 12Considerations for Using DBRC. . . . . . . . . . . . . . . . . . 12DBRC Functions . . . . . . . . . . . . . . . . . . . . . . . 13Data Set Naming Conventions . . . . . . . . . . . . . . . . . . 21DBRC Support for Remote Site Recovery . . . . . . . . . . . . . . 22

Chapter 2. Considerations for a DBRC System . . . . . . . . . . . . 25Database Backup Copies . . . . . . . . . . . . . . . . . . . . . 25

The Image Copy Utilities (DFSUDMP0, DFSUICP0, DFSUDMT0) . . . . . 26Database Image Copy (DFSUDMP0). . . . . . . . . . . . . . . . 27Database Image Copy 2 (DFSUDMT0) . . . . . . . . . . . . . . . 27Online Database Image Copy (DFSUICP0) . . . . . . . . . . . . . 28Concurrent Image Copy . . . . . . . . . . . . . . . . . . . . 28Creating Image Copy Data Sets for Future Use and Reuse . . . . . . . 29Controlling the Number of Image Copies Managed. . . . . . . . . . . 29Recovery Period of Image Copy Data Sets and GENMAX . . . . . . . . 30Reusing Image Copy Data Sets. . . . . . . . . . . . . . . . . . 30HISAM Copies (DFSURUL0 and DFSURRL0) . . . . . . . . . . . . 31Nonstandard Image Copy Data Sets . . . . . . . . . . . . . . . . 32Frequency and Retention . . . . . . . . . . . . . . . . . . . . 32

Log Record Change Accumulation . . . . . . . . . . . . . . . . . . 33

© Copyright IBM Corp. 1974, 2001 iii

||

Condensing the Accumulated SLDS or RLDS (Change Accumulation). . . . 33When Is Change Accumulation Required? . . . . . . . . . . . . . . 35

Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 38The Database Recovery Process . . . . . . . . . . . . . . . . . 38How DBRC Helps in Recovery . . . . . . . . . . . . . . . . . . 39Planning Recovery Procedures . . . . . . . . . . . . . . . . . . 39Setting Up Recovery Mechanisms . . . . . . . . . . . . . . . . . 39Recovery Facilities . . . . . . . . . . . . . . . . . . . . . . 40Recovery without DBRC . . . . . . . . . . . . . . . . . . . . 42Restart after IMS Failure . . . . . . . . . . . . . . . . . . . . 42Restart after DBRC Failure . . . . . . . . . . . . . . . . . . . 42Recovery Involving IRLM Configurations . . . . . . . . . . . . . . 42Batch Backout . . . . . . . . . . . . . . . . . . . . . . . . 43Archiving Log Records . . . . . . . . . . . . . . . . . . . . . 43

Chapter 3. Initializing and Maintaining the RECON . . . . . . . . . . 45Planning Considerations for the RECON . . . . . . . . . . . . . . . 46

First-Time Users . . . . . . . . . . . . . . . . . . . . . . . 46Avoiding RECON Contention Problems . . . . . . . . . . . . . . . 46Initial RECON Access . . . . . . . . . . . . . . . . . . . . . 54Records in the RECON . . . . . . . . . . . . . . . . . . . . . 55Maintaining the RECONs . . . . . . . . . . . . . . . . . . . . 64

Chapter 4. RECON Upgrade Utility (DSPURU00) . . . . . . . . . . . 71What Is the RECON Upgrade Utility?. . . . . . . . . . . . . . . . . 71Before You Start . . . . . . . . . . . . . . . . . . . . . . . . 71Upgrade Procedure . . . . . . . . . . . . . . . . . . . . . . . 71Input and Output . . . . . . . . . . . . . . . . . . . . . . . . 73JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . 73Upgrade Utility Return Codes and Message Information . . . . . . . . . . 73Example of RECON Upgrade Utility JCL . . . . . . . . . . . . . . . 74

Chapter 5. Database Recovery Control Utility (DSPURX00) . . . . . . . 75What Is the Database Recovery Control Utility (DSPURX00)? . . . . . . . 75Input and Output . . . . . . . . . . . . . . . . . . . . . . . . 75Example of DBRC Utility JCL . . . . . . . . . . . . . . . . . . . 76JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 6. Hints and Tips for DBRC . . . . . . . . . . . . . . . . 79Locating the Last SLDS Stop Time in RECON . . . . . . . . . . . . . 79Adjusting GENMAX When It Is Reached or It Is Too High . . . . . . . . . 80

Solutions for Situation #1 . . . . . . . . . . . . . . . . . . . . 81Solution for Situation #2 . . . . . . . . . . . . . . . . . . . . 81

Getting PRILOG Compression to Work . . . . . . . . . . . . . . . . 82PRILOG Record Sizes . . . . . . . . . . . . . . . . . . . . . . 82Using NOTIFY.PRILOG to Close an Open Online PRILOG . . . . . . . . . 83Deleting Log Records . . . . . . . . . . . . . . . . . . . . . . 84Working with Subsystem Records (SSYS) . . . . . . . . . . . . . . . 84

Naming Conventions for SSIDs in RECON Subsystem Records . . . . . . 84Batch Backout . . . . . . . . . . . . . . . . . . . . . . . . 85Deleting a Subsystem Record . . . . . . . . . . . . . . . . . . 85Subsystem Record Size . . . . . . . . . . . . . . . . . . . . 85

Removing Authorization Inconsistency between the SSYS from DB/AREARecords . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Getting Change Accumulation to Start Processing Logs Again . . . . . . . 86Getting Change Accumulation Working When It States Nothing to Process . . . 86

iv DBRC Guide & Reference

Moving Log Data Sets . . . . . . . . . . . . . . . . . . . . . . 87Reorganizing RECON to Increase Maximum RECORDSIZE . . . . . . . . 87Cataloging Data Sets . . . . . . . . . . . . . . . . . . . . . . 89Performing Multiple Cold Starts in a Test Environment . . . . . . . . . . 90Avoiding Some Causes of RECON Enqueue Problems . . . . . . . . . . 91

In a Shared DASD Environment . . . . . . . . . . . . . . . . . 92In a Non-Shared DASD Environment . . . . . . . . . . . . . . . . 92

Part 2. Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . 93

Chapter 7. DBRC Commands . . . . . . . . . . . . . . . . . . . 99Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . 99

Separators . . . . . . . . . . . . . . . . . . . . . . . . . 100Continuation Characters . . . . . . . . . . . . . . . . . . . . 100Comments . . . . . . . . . . . . . . . . . . . . . . . . . 100Commands . . . . . . . . . . . . . . . . . . . . . . . . . 100Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 100DBRC Time Stamps . . . . . . . . . . . . . . . . . . . . . 101Using the Commands in This Book . . . . . . . . . . . . . . . . 107Notational Conventions . . . . . . . . . . . . . . . . . . . . 107How to Read the Syntax Diagrams . . . . . . . . . . . . . . . . 107

DBRC Online Command Syntax . . . . . . . . . . . . . . . . . . 110

Chapter 8. BACKUP Command . . . . . . . . . . . . . . . . . . 111BACKUP.RECON . . . . . . . . . . . . . . . . . . . . . . . 111

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 111Example of Creating Backups of a RECON . . . . . . . . . . . . . 111

Chapter 9. CHANGE Commands . . . . . . . . . . . . . . . . . 113CHANGE.ADS . . . . . . . . . . . . . . . . . . . . . . . . 113

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 113Example of Changing an ADS Record . . . . . . . . . . . . . . . 113

CHANGE.BKOUT . . . . . . . . . . . . . . . . . . . . . . . 114Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 114Example of Using the CHANGE.BKOUT Command . . . . . . . . . . 116

CHANGE.CA . . . . . . . . . . . . . . . . . . . . . . . . . 116Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 116Example of Changing a Change Accumulation Run Record . . . . . . . 117

CHANGE.CAGRP . . . . . . . . . . . . . . . . . . . . . . . 118Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 118Examples of Using the CHANGE.CAGRP Command . . . . . . . . . 119

CHANGE.DB . . . . . . . . . . . . . . . . . . . . . . . . . 120Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 121Example of Changing a Record for a DB Identified with the DBD Parm 125

CHANGE.DBDS . . . . . . . . . . . . . . . . . . . . . . . . 126Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 127Example of Changing a Record for a Fast Path DEDB . . . . . . . . . 132

CHANGE.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . 132Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 133Example of Changing a Group of DBDSs. . . . . . . . . . . . . . 134

CHANGE.IC . . . . . . . . . . . . . . . . . . . . . . . . . 134Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 135Example of Changing an Image Copy Record . . . . . . . . . . . . 136

CHANGE.PRILOG (for OLDS) . . . . . . . . . . . . . . . . . . . 137Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 137Example of Renaming an OLDS . . . . . . . . . . . . . . . . . 138

Contents v

CHANGE.PRILOG (for RLDS) . . . . . . . . . . . . . . . . . . . 139Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 140Examples of Using the CHANGE.PRILOG (for RLDS) Command . . . . . 142

CHANGE.PRILOG (for SLDS and TSLDS) . . . . . . . . . . . . . . 143Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 144Examples of Using CHANGE.PRILOG (for SLDS and TSLDS) . . . . . . 147

CHANGE.RECON . . . . . . . . . . . . . . . . . . . . . . . 147Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 148Suggestions for Time Zone Label Table Management . . . . . . . . . 155Example of Updating the RECON Header Record . . . . . . . . . . 155

CHANGE.RECON (for THT or REPTHT) . . . . . . . . . . . . . . . 156Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 156Example of Specifying a Replacement THT Entry. . . . . . . . . . . 156

CHANGE.SECLOG (for OLDS) . . . . . . . . . . . . . . . . . . 156Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 157Example Showing a SECOLDS Error . . . . . . . . . . . . . . . 158

CHANGE.SECLOG (for RLDS) . . . . . . . . . . . . . . . . . . 158Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 159Examples of Using CHANGE.SECLOG (for RLDS) . . . . . . . . . . 161

CHANGE.SECLOG (for SLDS and TSLDS) . . . . . . . . . . . . . . 162Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 163Examples of Using CHANGE.SECLOG (for SLDS and TSLDS) . . . . . 166

CHANGE.SG . . . . . . . . . . . . . . . . . . . . . . . . . 167Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 167Example of Changing the Status of a Service Group . . . . . . . . . 167

CHANGE.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . 168Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 168Example of Identifying the IRLM . . . . . . . . . . . . . . . . . 169

CHANGE.UIC . . . . . . . . . . . . . . . . . . . . . . . . . 170Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 170Example of Changing the Nonstandard ICDSN in RECON . . . . . . . 170

Chapter 10. DELETE Commands . . . . . . . . . . . . . . . . . 171DELETE.ADS . . . . . . . . . . . . . . . . . . . . . . . . . 171

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 171Example of Deleting an ADS Record . . . . . . . . . . . . . . . 171

DELETE.ALLOC . . . . . . . . . . . . . . . . . . . . . . . . 171Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 172Example of Deleting an Allocation Record . . . . . . . . . . . . . 172

DELETE.BKOUT. . . . . . . . . . . . . . . . . . . . . . . . 172Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 172Example of Using the DELETE.BKOUT Command . . . . . . . . . . 173

DELETE.CA . . . . . . . . . . . . . . . . . . . . . . . . . 173Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 173Example of Deleting a Run Record . . . . . . . . . . . . . . . . 173

DELETE.CAGRP . . . . . . . . . . . . . . . . . . . . . . . 174Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 174Example of Deleting CA Group Records . . . . . . . . . . . . . . 174

DELETE.DB . . . . . . . . . . . . . . . . . . . . . . . . . 174Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 174Example of Deleting Records from RECON . . . . . . . . . . . . . 175

DELETE.DBDS . . . . . . . . . . . . . . . . . . . . . . . . 175Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 175Example of Deleting Records for the DBDS . . . . . . . . . . . . . 175

DELETE.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . 175Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 176

vi DBRC Guide & Reference

Example of Deleting a DBDS Group Record . . . . . . . . . . . . 176DELETE.GSG. . . . . . . . . . . . . . . . . . . . . . . . . 176

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 176Example of Deleting a Global Service Group Record . . . . . . . . . 176

DELETE.IC . . . . . . . . . . . . . . . . . . . . . . . . . . 177Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 177Example of Deleting Information from an Image Copy Record . . . . . . 177

DELETE.LOG (for OLDS) . . . . . . . . . . . . . . . . . . . . 177Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 178Example of Deleting an Interim OLDS Record . . . . . . . . . . . . 178

DELETE.LOG (for RLDS and SLDS) . . . . . . . . . . . . . . . . 178Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 179Example of Deleting the Record of an RLDS and SLDS . . . . . . . . 180

DELETE.RECOV . . . . . . . . . . . . . . . . . . . . . . . 181Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 181Example of Deleting a Recovery Record of the DBDS . . . . . . . . . 181

DELETE.REORG . . . . . . . . . . . . . . . . . . . . . . . 182Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 182Example of Deleting a Reorganization Record of a DBDS . . . . . . . 182

DELETE.SG . . . . . . . . . . . . . . . . . . . . . . . . . 182Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 183Example of Deleting a Global Service Group Record . . . . . . . . . 183

DELETE.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . 183Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 183Example of Deleting a Specified SUBSYS Record . . . . . . . . . . 183

DELETE.UIC . . . . . . . . . . . . . . . . . . . . . . . . . 184Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 184Example of Deleting a Nonstandard Image Copy Data Set Record . . . . 184

Chapter 11. GENJCL Commands . . . . . . . . . . . . . . . . . 185GENJCL.ARCHIVE . . . . . . . . . . . . . . . . . . . . . . . 185

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 185Examples of Running the Log Archive Utility . . . . . . . . . . . . 188

GENJCL.CA . . . . . . . . . . . . . . . . . . . . . . . . . 189Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 189Examples of Running the Change Accumulation Utility . . . . . . . . . 192

GENJCL.CLOSE. . . . . . . . . . . . . . . . . . . . . . . . 193Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 193Examples of Running the Log Recovery Utility . . . . . . . . . . . . 195

GENJCL.IC. . . . . . . . . . . . . . . . . . . . . . . . . . 195Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 197Examples of Running the Database Image Copy Utility. . . . . . . . . 200

GENJCL.OIC . . . . . . . . . . . . . . . . . . . . . . . . . 202Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 203Examples of Running the Online Database Image Copy Utility . . . . . . 206

GENJCL.RECEIVE . . . . . . . . . . . . . . . . . . . . . . . 207Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 208Examples of Running the Database Recovery Utility to Receive an Image

Copy . . . . . . . . . . . . . . . . . . . . . . . . . . 210GENJCL.RECOV . . . . . . . . . . . . . . . . . . . . . . . 211

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 212Examples of Running the Database Recovery Utility. . . . . . . . . . 215

GENJCL.USER . . . . . . . . . . . . . . . . . . . . . . . . 216Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 217Example of Running DBRC . . . . . . . . . . . . . . . . . . . 220

Contents vii

Chapter 12. INIT Commands . . . . . . . . . . . . . . . . . . . 221INIT.ADS . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 221Example of Creating a Record That Defines an ADS . . . . . . . . . 222

INIT.CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 222Example of Creating a Record That Defines a CA Data Set . . . . . . . 223

INIT.CAGRP . . . . . . . . . . . . . . . . . . . . . . . . . 223Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 223Example of Creating a CA Group. . . . . . . . . . . . . . . . . 224

INIT.DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 225Example of Creating a SHARELVL 1 DB Record . . . . . . . . . . . 226

INIT.DBDS . . . . . . . . . . . . . . . . . . . . . . . . . . 227Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 227Example of Identifying the DBDS to Initiate DBRC’s Control Over Recovery 231

INIT.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . . . 231Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 232Example of Creating a Group of DBDSs . . . . . . . . . . . . . . 232

INIT.GSG . . . . . . . . . . . . . . . . . . . . . . . . . . 233Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 233Example of Creating a Global Service Group . . . . . . . . . . . . 233

INIT.IC . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 234Example of Creating a Record That Defines the ICDSN . . . . . . . . 235

INIT.PART . . . . . . . . . . . . . . . . . . . . . . . . . . 235Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 236

INIT.RECON . . . . . . . . . . . . . . . . . . . . . . . . . 239Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 239Example of Initializing the RECON . . . . . . . . . . . . . . . . 243

INIT.SG . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 243Examples of Creating Service Groups . . . . . . . . . . . . . . . 244

Chapter 13. LIST Commands . . . . . . . . . . . . . . . . . . 245LIST.BKOUT . . . . . . . . . . . . . . . . . . . . . . . . . 245

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 245Example of Running LIST.BKOUT . . . . . . . . . . . . . . . . 245

LIST.CAGRP . . . . . . . . . . . . . . . . . . . . . . . . . 245Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 246Example of Specifying the CA Group and CA Records via GRPNAME 246

LIST.DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 247Example of Displaying a Database and Its DBDS Records . . . . . . . 248

LIST.DBDS . . . . . . . . . . . . . . . . . . . . . . . . . . 248Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 249Example of Displaying AREA Parameters. . . . . . . . . . . . . . 249

LIST.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . . . 250Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 250Example of Displaying the Members of a DBDS Group. . . . . . . . . 251

LIST.GSG . . . . . . . . . . . . . . . . . . . . . . . . . . 251Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 251Example of Listing a Global Service Group . . . . . . . . . . . . . 252

LIST.HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 252Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 253Example of Displaying a DBDSs Activity History . . . . . . . . . . . 254

viii DBRC Guide & Reference

||||

LIST.LOG (for a PRILOG Family). . . . . . . . . . . . . . . . . . 254Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 255Example of Listing a PRILOG Family of Records . . . . . . . . . . . 255

LIST.LOG (for a Category of Records) . . . . . . . . . . . . . . . . 255Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 257Example of Displaying RECON Records Specified by STARTIME . . . . . 258Example of Displaying a Subsystem’s OLDS Records . . . . . . . . . 258

LIST.RECON . . . . . . . . . . . . . . . . . . . . . . . . . 258Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 259Examples of Displaying the RECONs . . . . . . . . . . . . . . . 259

LIST.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . . . 260Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 260Example of Displaying All Online Subsystem Records . . . . . . . . . 261

Chapter 14. NOTIFY Commands . . . . . . . . . . . . . . . . . 263NOTIFY.ALLOC . . . . . . . . . . . . . . . . . . . . . . . . 263

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 263Example of Adding Allocation Information to RECON . . . . . . . . . 264

NOTIFY.BKOUT . . . . . . . . . . . . . . . . . . . . . . . . 264Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 264Example of Adding a Backout Record to RECON . . . . . . . . . . . 265

NOTIFY.CA. . . . . . . . . . . . . . . . . . . . . . . . . . 265Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 266Example of Adding CADSN Information to RECON . . . . . . . . . . 268

NOTIFY.IC . . . . . . . . . . . . . . . . . . . . . . . . . . 268Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 269Example of Notifying DBRC of Concurrent Image Copy Completion . . . . 270

NOTIFY.PRILOG (for OLDS) . . . . . . . . . . . . . . . . . . . 271Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 271Examples of Using the NOTIFY.PRILOG (for OLDS) Command . . . . . 273

NOTIFY.PRILOG (for RLDS) . . . . . . . . . . . . . . . . . . . 274Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 275Examples of Using the NOTIFY.PRILOG (for RLDS) Command . . . . . 278

NOTIFY.PRILOG (for SLDS and TSLDS) . . . . . . . . . . . . . . . 279Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 279Example of Adding Primary SLDS Information to RECON. . . . . . . . 282

NOTIFY.RECOV . . . . . . . . . . . . . . . . . . . . . . . . 283Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 283Example of Adding DBDS Recovery Information to RECON . . . . . . . 285

NOTIFY.REORG . . . . . . . . . . . . . . . . . . . . . . . . 285Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 286Example Adding DBDS Reorganization Information to RECON . . . . . . 288

NOTIFY.SECLOG (for OLDS) . . . . . . . . . . . . . . . . . . . 288Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 288Examples of Using the NOTIFY.SECLOG (for OLDS) Command . . . . . 290

NOTIFY.SECLOG (for RLDS) . . . . . . . . . . . . . . . . . . . 291Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 291Examples of Using the NOTIFY.SECLOG (for RLDS) Command . . . . . 294

NOTIFY.SECLOG (for SLDS and TSLDS) . . . . . . . . . . . . . . 294Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 295Example of Adding Secondary SLDS Information to RECON . . . . . . 298

NOTIFY.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . 298Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 298Example of Adding a New Subsystem Record to RECON. . . . . . . . 299

NOTIFY.UIC . . . . . . . . . . . . . . . . . . . . . . . . . 299Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 300

Contents ix

Example of Adding Nonstandard ICDSN Information to RECON . . . . . 301

Chapter 15. RESET Command . . . . . . . . . . . . . . . . . . 303RESET.GSG . . . . . . . . . . . . . . . . . . . . . . . . . 303

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 303Example of the RESET.GSG Command . . . . . . . . . . . . . . 304

Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Appendix A. Introduction . . . . . . . . . . . . . . . . . . . . 307

Appendix B. Understanding Skeletal JCL . . . . . . . . . . . . . . 309Using the Commands to Generate JCL and User-Defined Output . . . . . . 309Using IBM-Supplied Skeletal JCL. . . . . . . . . . . . . . . . . . 310Writing Your Own Skeletal JCL . . . . . . . . . . . . . . . . . . 310Understanding the Skeletal JCL Data Set. . . . . . . . . . . . . . . 310Understanding Skeletal JCL Syntax . . . . . . . . . . . . . . . . . 311

Understanding Simple Keywords . . . . . . . . . . . . . . . . . 311Using Control Keywords . . . . . . . . . . . . . . . . . . . . 313Writing Control Keywords . . . . . . . . . . . . . . . . . . . 320Understanding Skeletal JCL Default Members . . . . . . . . . . . . 329

Understanding the Symbolic Keywords Recognized by DBRC . . . . . . . 331All Supported Utilities . . . . . . . . . . . . . . . . . . . . . 331Log Archive Utility (ARCHJCL). . . . . . . . . . . . . . . . . . 332Database Change Accumulation Utility (CAJCL) . . . . . . . . . . . 333Log Recovery Utility (LOGCLJCL) . . . . . . . . . . . . . . . . 334Database Image Copy Utility, Database Image Copy Utility 2, and Online

Database Image Copy Utility (ICJCL and OICJCL) . . . . . . . . . 335Database Recovery Utility- Receive (ICRCVJCL) . . . . . . . . . . . 336Database Recovery Utility-Recover (RECOVJCL). . . . . . . . . . . 338Understanding the IBM-Supplied Skeletal JCL Execution Members . . . . 340

Appendix C. Sample Listings of RECONs. . . . . . . . . . . . . . 367Sample Listing of LIST.HISTORY Output . . . . . . . . . . . . . . . 368Sample Listing of a RECON at the Active Site . . . . . . . . . . . . . 373

RECON Status Record . . . . . . . . . . . . . . . . . . . . 374Log Records . . . . . . . . . . . . . . . . . . . . . . . . 375GSG Record . . . . . . . . . . . . . . . . . . . . . . . . 382SSYS Record . . . . . . . . . . . . . . . . . . . . . . . . 383BACKOUT Record . . . . . . . . . . . . . . . . . . . . . . 383CAGRP and CA Records. . . . . . . . . . . . . . . . . . . . 384DBGRP, DBDSGRP, and RECOVGRP Records . . . . . . . . . . . 385DB (IMS) and Related Records . . . . . . . . . . . . . . . . . 386DB (HALDB and PART) and Related Records . . . . . . . . . . . . 388DB (FP) and Related Records . . . . . . . . . . . . . . . . . . 400

Sample Listing of a RECON at the Tracking Site . . . . . . . . . . . . 401RECON Status Record . . . . . . . . . . . . . . . . . . . . 401Log Records . . . . . . . . . . . . . . . . . . . . . . . . 402GSG Record . . . . . . . . . . . . . . . . . . . . . . . . 407SSYS Record . . . . . . . . . . . . . . . . . . . . . . . . 408BACKOUT Record . . . . . . . . . . . . . . . . . . . . . . 408CAGRP and CA Records. . . . . . . . . . . . . . . . . . . . 409DBDSGRP Records . . . . . . . . . . . . . . . . . . . . . 410DB (IMS) and Related Records . . . . . . . . . . . . . . . . . 410DB (FP) and Related Records . . . . . . . . . . . . . . . . . . 411IMS DB Records . . . . . . . . . . . . . . . . . . . . . . . 412

x DBRC Guide & Reference

Fields Present in a Listing of a RECON by Record Type . . . . . . . . . 416Fields Present in a RECON Record . . . . . . . . . . . . . . . . 417Fields Present in a THT Record . . . . . . . . . . . . . . . . . 420Fields Present in a Log Record . . . . . . . . . . . . . . . . . 421Fields Present in a LOGALL Record . . . . . . . . . . . . . . . 423Fields Present in an Online Log Record . . . . . . . . . . . . . . 423Fields Present in a GSG Record . . . . . . . . . . . . . . . . . 427Fields Present in a SSYS Record . . . . . . . . . . . . . . . . 428Fields Present in a BACKOUT Record . . . . . . . . . . . . . . . 429Fields Present in a CAGRP Record . . . . . . . . . . . . . . . . 430Fields Present in a CA Record. . . . . . . . . . . . . . . . . . 431Fields Present in a Data Group Record . . . . . . . . . . . . . . 433Fields Present in a DB (IMS) Record . . . . . . . . . . . . . . . 434Fields Present in a DB (HALDB) Record . . . . . . . . . . . . . . 436Fields Present in a DB (PART) and Related Records . . . . . . . . . 437Fields Present in a DB (Fast Path) Record . . . . . . . . . . . . . 440Fields Present in a DBDS (non-Fast Path) Record . . . . . . . . . . 441Fields Present in a DBDS (Fast Path) Record . . . . . . . . . . . . 443Fields Present in an ALLOC Record . . . . . . . . . . . . . . . 447Fields Present in an IMAGE Record . . . . . . . . . . . . . . . 448Fields Present in a REORG Record. . . . . . . . . . . . . . . . 450Fields Present in a RECOV Record . . . . . . . . . . . . . . . . 451

Appendix D. Considering IMS DBRC RECON Data Set Placement . . . . 453

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 455IMS Version 7 Library . . . . . . . . . . . . . . . . . . . . . . 455

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Contents xi

xii DBRC Guide & Reference

Figures

1. IMS Database Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52. DBRC JCL Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93. DBRC’s Role in Utility Execution . . . . . . . . . . . . . . . . . . . . . . . . . 154. DBRC’s Specific Place in a Utility Input Scheme. . . . . . . . . . . . . . . . . . . . 165. Making a Backup Copy with HISAM Unload . . . . . . . . . . . . . . . . . . . . . 316. What Change Accumulation Does with Data from Divergent Data Streams . . . . . . . . . 347. Non-Concurrent Data Set Update Information in Logs: Change Accumulation Not Required 358. Concurrent or Overlapping Data Set Update Information in Logs: Change Accumulation Required 369. RECON Three-Data-Set Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 45

10. Events Affecting PRILOG Records . . . . . . . . . . . . . . . . . . . . . . . . 5411. RECON Record Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5612. DBRC DL/I Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6013. RECON Record Structure for a HALDB . . . . . . . . . . . . . . . . . . . . . . 6014. DBRC Fast Path Database Records. . . . . . . . . . . . . . . . . . . . . . . . 6215. RECON Upgrade Utility Input and Output . . . . . . . . . . . . . . . . . . . . . . 7316. Database Requirements for the DBRC . . . . . . . . . . . . . . . . . . . . . . . 7517. Inputs and outputs of the DBRC Utility . . . . . . . . . . . . . . . . . . . . . . . 7618. Skeletal JCL Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31119. How Simple Keyword Values Are Set . . . . . . . . . . . . . . . . . . . . . . . 31320. IBM-Supplied Skeletal JCL for the Log Archive Utility . . . . . . . . . . . . . . . . . 34121. IBM-Supplied Skeletal JCL for the Database Change Accumulation Utility . . . . . . . . . 34722. IBM-Supplied Skeletal JCL for the Log Recovery Utility . . . . . . . . . . . . . . . . 35023. IBM-Supplied Skeletal JCL for the Database Image Copy Utility . . . . . . . . . . . . . 35224. IBM-Supplied Skeletal JCL for the Online Database Image Copy Utility . . . . . . . . . . 35525. IBM-Supplied Skeletal JCL for the Database Recovery Utility . . . . . . . . . . . . . . 35726. IBM-Supplied Skeletal JCL for the Database Recovery Utility . . . . . . . . . . . . . . 35927. IBM-Supplied Skeletal JCL for the HALDB Index/ILDS Rebuild Utility . . . . . . . . . . . 36528. Sample LIST.HISTORY Output . . . . . . . . . . . . . . . . . . . . . . . . . 36929. Sample Listing of a RECON at the Active Site - RECON Status . . . . . . . . . . . . . 37430. Sample Listing of a RECON at the Active Site - Log Records . . . . . . . . . . . . . . 37531. Sample Listing of a RECON at the Active Site - GSG Record . . . . . . . . . . . . . . 38232. Sample Listing of a RECON at the Active Site - SSYS Record . . . . . . . . . . . . . 38333. Sample Listing of a RECON at the Active Site - BACKOUT Record . . . . . . . . . . . . 38334. Sample Listing of a RECON at the Active Site - CAGRP and CA Records . . . . . . . . . 38435. Sample Listing of a RECON at the Active Site - DBGRP, DBDSGRP, and RECOVGRP Records 38536. Sample Listing of a RECON at the Active Site - DB (IMS) and Related Records . . . . . . . 38637. Sample Listing of a RECON at the Active Site - DB (FP) and Related Records . . . . . . . 40038. Sample Listing of a RECON at the Tracking Site - RECON Status Record . . . . . . . . . 40139. Sample Listing of a RECON at the Tracking Site - Log Records . . . . . . . . . . . . . 40240. Sample Listing of a RECON at the Tracking Site - GSG Record . . . . . . . . . . . . . 40741. Sample Listing of a RECON at the Tracking Site - SSYS Record. . . . . . . . . . . . . 40842. Sample Listing of a RECON at the Tracking Site - BACKOUT Record . . . . . . . . . . . 40843. Sample Listing of a RECON at the Tracking Site - CAGRP and CA Records . . . . . . . . 40944. Sample Listing of a RECON at the Tracking Site - DBDSGRP Records . . . . . . . . . . 41045. Sample Listing of a RECON at the Tracking Site - DB (IMS) and Related Records . . . . . . 41046. Sample Listing of a RECON at the Tracking Site - DB (FP) and Related Records. . . . . . . 41147. Sample Listing of a RECON at the Tracking Site - More IMS DB Records . . . . . . . . . 412

© Copyright IBM Corp. 1974, 2001 xiii

xiv DBRC Guide & Reference

Tables

1. Results of GENJCL.IC Processing when GENMAX and RECOVPD are Specified with REUSE 302. Results of GENJCL.IC Processing when GENMAX and RECOVPD are Specified with NOREUSE 303. RECON Records of Variable Size. . . . . . . . . . . . . . . . . . . . . . . . . 514. Determining Which RECONs Are Accessed . . . . . . . . . . . . . . . . . . . . . 555. Parameters of NOTIFY.PRILOG (for OLDS) Command for Open, Switch, and Close . . . . . 2716. Parameters of NOTIFY.PRILOG (for RLDS) Command for Open, EOV, and Close . . . . . . 2757. Parameters of NOTIFY.PRILOG (SLDS or TSLDS) Command for Open, EOV, and Close 2808. Parameters of NOTIFY.SECLOG (for OLDS) Command for Open, Switch, and Close . . . . . 2899. Parameters of NOTIFY.SECLOG (for RLDS) Command for Open, EOV, and Close . . . . . . 292

10. Parameters of NOTIFY.SECLOG (for SLDS or TSLDS) Command for Open, EOV, and Close 29511. What the GENJCL Commands Do . . . . . . . . . . . . . . . . . . . . . . . . 30912. Records That Can Be Selected Using the %SELECT Keyword . . . . . . . . . . . . . 31513. Symbolic Keywords in Skeletal JCL . . . . . . . . . . . . . . . . . . . . . . . 33114. Symbolic Keywords for Log Archive Utility . . . . . . . . . . . . . . . . . . . . . 33215. Symbolic Keywords for Database Change Accumulation Utility . . . . . . . . . . . . . 33316. Symbolic Keywords for Log Recovery Utility . . . . . . . . . . . . . . . . . . . . 33417. Symbolic Keywords for Database Image Copy and Online Database Image Copy Utility . . . . 33518. Symbolic Keywords for Database Recovery Utility . . . . . . . . . . . . . . . . . . 33619. Symbolic Keywords for Database Recovery Utility . . . . . . . . . . . . . . . . . . 33820. Fields Present in the RECON Record . . . . . . . . . . . . . . . . . . . . . . . 41721. Fields Present in the THT Record . . . . . . . . . . . . . . . . . . . . . . . . 42022. Fields Present in a Log Record . . . . . . . . . . . . . . . . . . . . . . . . . 42123. Fields Present in the LOGALL Record . . . . . . . . . . . . . . . . . . . . . . 42324. Fields Present in an Online Log Record . . . . . . . . . . . . . . . . . . . . . . 42325. Fields Present in a GSG Record . . . . . . . . . . . . . . . . . . . . . . . . 42726. Fields Present in a SSYS Record . . . . . . . . . . . . . . . . . . . . . . . . 42827. Fields Present in a BACKOUT Record . . . . . . . . . . . . . . . . . . . . . . 42928. Fields Present in a CAGRP Record . . . . . . . . . . . . . . . . . . . . . . . 43029. Fields Present in a CA Record . . . . . . . . . . . . . . . . . . . . . . . . . 43130. Fields Present in the DBDSGRP Record. . . . . . . . . . . . . . . . . . . . . . 43331. Fields Present in the DB (IMS) Record . . . . . . . . . . . . . . . . . . . . . . 43432. Fields Present in the DB (HALDB) Record . . . . . . . . . . . . . . . . . . . . . 43633. Fields Present in the DB (PART) Record . . . . . . . . . . . . . . . . . . . . . 43734. Fields Present in the DB (Fast Path) Record . . . . . . . . . . . . . . . . . . . . 44035. Fields Present in the DBDS (non-Fast Path) Record . . . . . . . . . . . . . . . . . 44136. Fields Present in the DBDS (Fast Path) Record . . . . . . . . . . . . . . . . . . . 44337. Fields Present in the ALLOC Record . . . . . . . . . . . . . . . . . . . . . . . 44738. Fields Present in the IMAGE Record . . . . . . . . . . . . . . . . . . . . . . . 44839. Fields Present in the REORG Record. . . . . . . . . . . . . . . . . . . . . . . 45040. Fields Present in the RECOV Record . . . . . . . . . . . . . . . . . . . . . . . 451

© Copyright IBM Corp. 1974, 2001 xv

xvi DBRC Guide & Reference

Notices

This information was developed for products and services offered in the U.S.A. IBMmay not offer the products, services, or features discussed in this document in othercountries. Consult your local IBM representative for information on the products andservices currently available in your area. Any reference to an IBM product, program,or service is not intended to state or imply that only that IBM product, program, orservice may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However,it is the user’s responsibility to evaluate and verify the operation of any non-IBMproduct, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the IBMIntellectual Property Department in your country or send inquiries, in writing, to:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIESOF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not apply toyou.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvements and/orchanges in the product(s) and/or the program(s) described in this publication at anytime without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of thoseWeb sites. The materials at those Web sites are not part of the materials for thisIBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believesappropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose ofenabling: (i) the exchange of information between independently created programs

© Copyright IBM Corp. 1974, 2001 xvii

and other programs (including this one) and (ii) the mutual use of the informationwhich has been exchanged, should contact:

IBM CorporationJ74/G4555 Bailey AvenueP.O. Box 49023San Jose, CA 95161-9023U.S.A.

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this information and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement, or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurement may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers of thoseproducts, their published announcements or other publicly available sources. IBMhas not tested those products and cannot confirm the accuracy of performance,compatibility or any other claims related to non-IBM products. Questions on thecapabilities of non-IBM products should be addressed to the suppliers of thoseproducts.

All statements regarding IBM’s future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information is for planning purposes only. The information herein is subject tochange before the products described become available.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrates programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment to IBM,for the purposes of developing, using, marketing or distributing application programsconforming to the application programming interface for the operating platform forwhich the sample programs are written. These examples have not been thoroughlytested under all conditions. IBM, therefore, cannot guarantee or imply reliability,serviceability, or function of these programs. You may copy, modify, and distribute

xviii DBRC Guide & Reference

these sample programs in any form without payment to IBM for the purposes ofdeveloping, using, marketing, or distributing application programs conforming toIBM’s application programming interfaces.

Each copy or any portion of these sample programs or any derivative work, mustinclude a copyright notice as follows:

© (your company name) (year). Portions of this code are derived from IBM Corp.Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rightsreserved.

If you are viewing this information softcopy, the photographs and color illustrationsmay not appear.

TrademarksThe following terms are trademarks of the IBM Corporation in the United States orother countries or both:

BookManager IBMCICS IMSCICS/ESA IMS/ESADB2 MVSDFSMS MVS/ESA

Product NamesIn this book, the licensed program “DB2 for MVS/ESA” is referred to as “DB2”.

Other company, product, and service names, which may be denoted by a doubleasterisk (**), may be trademarks or service marks of others.

Notices xix

xx DBRC Guide & Reference

Preface

This book describes the administrative and operational tasks associated with theIMS Database Recovery Control facility (DBRC). DBRC provides tools for trackinginformation used during database recovery. This book is for system and databaseadministrators who are responsible for design, operation, and recovery proceduresfor their installation.

Prerequisite KnowledgeIBM offers a wide variety of classroom and self-study courses to help you learnIMS. For a complete list of courses available, refer to the “How to Learn IMS”section of General Information from the Library page of the IMS home page on theWeb: http://www.ibm.com/ims.

Before using this book, you should understand:

v Basic IMS concepts

v The IMS environment

v Your installation’s IMS system

v Administration of the IMS system and databases

v MVS control programs

v VSAM file structure and VSAM Access Method Services (AMS)

How to Use This BookThis book is structured as both a guide and reference. You can read “Part 1. How toUse DBRC” on page 1 to familiarize yourself with how to use DBRC and the DBRCutilities. Then you can use “Part 2. Command Reference” on page 93 as a referencefor syntax and usage of the DBRC commands. The appendixes provide additionalreference material.

How to Read the Syntax DiagramsFor details, see “How to Read the Syntax Diagrams” on page 107.

Related ReadingThe following books in the IMS library contain information related to DBRC.

v For definitions of terminology used in this manual and references to relatedinformation in other manuals:

– IMS Version 7 Master Index and Glossary

v For more information on upgrading the RECON from previous releases of IMS:

– IMS Version 7 Release Planning Guide

v For installation and initialization topics:

– IMS Version 7 Installation Volume 1: Installation and Verification

– IMS Version 7 Installation Volume 2: System Definition and Tailoring

v For information on database and system administration:

IMS Version 7 Administration Guide: Database Manager

IMS Version 7 Administration Guide: System

v For information on operating procedures:

© Copyright IBM Corp. 1974, 2001 xxi

IMS Version 7 Operations Guide

v For information on system utilities:

IMS Version 7 Utilities Reference: System

v For information on the utilities used in database recovery:

IMS Version 7 Utilities Reference: Database and Transaction Manager

v For information on the RECON I/O exit:

IMS Version 7 Customization Guide

v For diagnostic information and messages:

IMS Version 7 Diagnosis Guide and Reference

IMS Version 7 Messages and Codes, Volume 1

How to Send Your CommentsYour feedback is important in helping us provide the most accurate and highestquality information. If you have any comments about this book or any other IMSdocumentation, you can do one of the following:

v Go to the IMS home page at: http://www.ibm.com/ims. There you will find anonline feedback page where you can enter and submit comments.

v Send your comments by e-mail to [email protected]. Be sure to include thename of the book, the part number of the book, the version of IMS, and, ifapplicable, the specific location of the text you are commenting on (for example,a page number or table number).

v Fill out one of the forms at the back of this book and return it by mail, by fax, orby giving it to an IBM representative.

xxii DBRC Guide & Reference

Summary of Changes

Changes to The Current Edition of This Book for IMS Version 7This edition includes technical and editorial changes.

New information in the following sections is included:

v “Registering Databases and Database Data Sets” on page 12

v “DELETE.DB” on page 174

v “DELETE.DBDS” on page 175

v “INIT.DB” on page 225

v “INIT.DBDS” on page 227

v “INIT.DBDSGRP” on page 231

v “INIT.PART” on page 235

Changes to This Book for IMS Version 7This book contains new technical information for Version 7, as well as editorialchanges.

New information on the following enhancements is also included:

v HALDB (High Availability Large Database)

v Concurrent RECON upgrade from DBRC Version 6 to DBRC Version 7

v Large RECON record support

v RECON loss notification

v RECON performance improvement

v Image Copy GENMAX processing

v DBRC serviceability enhancements

v DBRC support for PROCOPT=L

Library Changes for IMS Version 7The major change to the IMS Version 7 library is that it is available not only inhardcopy and in softcopy on BookManager, but also in softcopy Portable DocumentFormat (PDF). The complete library is available in BookManager and PDF on theIMS Version 7 product kit CD-ROM (LK3T-3526). The unlicensed IMS Version 7softcopy library is available on the Transaction Processing and Data CD-ROM(SK2T-0730) and the OS/390 Collection CD-ROM (SK2T-6700) in BookManager.The unlicensed IMS Version 7 softcopy library is available in BookManager andPDF on the Web at http://www.ibm.com/ims

Other changes include changes to these following books:

v IMS Version 7 Common Queue Server and Base Primitive Environment Guideand Reference

The book formerly titled IMS/ESA Common Queue Server Guide and Referencein the Version 6 library is called IMS Version 7 Common Queue Server and BasePrimitive Environment Guide and Reference.

The IMS Version 7 Common Queue Server and Base Primitive EnvironmentGuide and Reference is divided into two parts: ″Part 1: Common Queue Server,″and ″Part 2: Base Primitive Environment.″

© Copyright IBM Corp. 1974, 2001 xxiii

|

|

|

|

|

|

|

|

|

|

|

||||||||

The IMS Version 7 Common Queue Server and Base Primitive EnvironmentGuide and Reference is now an unlicensed book.

v IMS Version 7 Command Reference

The book formerly titled IMS/ESA Operator’s Reference in the Version 6 library iscalled IMS Version 7 Command Reference.

v IMS Version 7 Utilities Reference: Database and Transaction Manager

The books formerly titled IMS/ESA Utilities Reference: Database Manager andIMS/ESA Utilities Reference: Transaction Manager in the Version 6 library havebeen combined into one book called IMS Version 7 Utilities Reference: Databaseand Transaction Manager.

v IMS Version 7 Application Programming: Database Manager and IMS Version 7Customization Guide

The chapter titled ″IMS Adapter for REXX Exit Routine″ has been moved fromthe IMS Version 7 Application Programming: Database Manager to the IMSVersion 7 Customization Guide.

v IMS Version 7 Sample Operating Procedures

For IMS Version 7, this book is available only in BookManager and PDF softcopyon the product kit (LK3T-3526), the OS/390 Collection CD-ROM (SK2T-6700),and on the Web at: http://www.ibm.com/ims

The library includes a new book: IMS Version 7 IMS Java User’s Guide (IJUG). Asa new book, the IJUG is available only in PDF softcopy on the product kit(LK3T-3526) and on the Web at: http://www.ibm.com/ims

xxiv DBRC Guide & Reference

|||

Part 1. How to Use DBRC

Chapter 1. DBRC in the IMS Database Recovery Process . . . . . . . . 5What Is DBRC? . . . . . . . . . . . . . . . . . . . . . . . . . 5

DBRC Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 6DBRC Components . . . . . . . . . . . . . . . . . . . . . . 6

RECONs . . . . . . . . . . . . . . . . . . . . . . . . . 6Database Recovery Control Utility (DSPURX00) . . . . . . . . . . . 7Skeletal JCL . . . . . . . . . . . . . . . . . . . . . . . . 7RECON Upgrade Utility (DSPURU00) . . . . . . . . . . . . . . . 7

IMS Recovery utilities and functions . . . . . . . . . . . . . . . . 7Recording Recovery-Related Information . . . . . . . . . . . . . . . 8Generating JCL . . . . . . . . . . . . . . . . . . . . . . . . 8

When Should You Use DBRC? . . . . . . . . . . . . . . . . . . . 10Initializing DBRC . . . . . . . . . . . . . . . . . . . . . . . . 10

Specifying When DBRC Is to Be Used . . . . . . . . . . . . . . . 10The IMSCTRL Macro . . . . . . . . . . . . . . . . . . . . 10IMS.PROCLIB Execution-Parameter Members . . . . . . . . . . . 11IMS Procedures and DBRC . . . . . . . . . . . . . . . . . . 11DBRC Procedure . . . . . . . . . . . . . . . . . . . . . . 11Initializing the RECON . . . . . . . . . . . . . . . . . . . . 11

Registering Databases and Database Data Sets . . . . . . . . . . . 12Considerations for Using DBRC. . . . . . . . . . . . . . . . . . 12DBRC Functions . . . . . . . . . . . . . . . . . . . . . . . 13

Using DBRC to Record Log Information. . . . . . . . . . . . . . 13Using DBRC for Database Recovery . . . . . . . . . . . . . . . 14Using DBRC for Data Sharing . . . . . . . . . . . . . . . . . 20

Data Set Naming Conventions . . . . . . . . . . . . . . . . . . 21Naming Convention for Image Copy Data Sets . . . . . . . . . . . 21Naming Convention for Duplicate Image Copy Data Sets . . . . . . . 22Naming Convention for Change Accumulation Data Sets . . . . . . . 22

DBRC Support for Remote Site Recovery . . . . . . . . . . . . . . 22

Chapter 2. Considerations for a DBRC System . . . . . . . . . . . . 25Database Backup Copies . . . . . . . . . . . . . . . . . . . . . 25

The Image Copy Utilities (DFSUDMP0, DFSUICP0, DFSUDMT0) . . . . . 26Database Image Copy (DFSUDMP0). . . . . . . . . . . . . . . . 27Database Image Copy 2 (DFSUDMT0) . . . . . . . . . . . . . . . 27Online Database Image Copy (DFSUICP0) . . . . . . . . . . . . . 28Concurrent Image Copy . . . . . . . . . . . . . . . . . . . . 28Creating Image Copy Data Sets for Future Use and Reuse . . . . . . . 29Controlling the Number of Image Copies Managed. . . . . . . . . . . 29Recovery Period of Image Copy Data Sets and GENMAX . . . . . . . . 30Reusing Image Copy Data Sets. . . . . . . . . . . . . . . . . . 30HISAM Copies (DFSURUL0 and DFSURRL0) . . . . . . . . . . . . 31Nonstandard Image Copy Data Sets . . . . . . . . . . . . . . . . 32Frequency and Retention . . . . . . . . . . . . . . . . . . . . 32

Log Record Change Accumulation . . . . . . . . . . . . . . . . . . 33Condensing the Accumulated SLDS or RLDS (Change Accumulation). . . . 33When Is Change Accumulation Required? . . . . . . . . . . . . . . 35

Input to the Database Change Accumulation Utility. . . . . . . . . . 36Change Accumulation Groups . . . . . . . . . . . . . . . . . 37Defining Change Accumulation Data Sets for Future Use . . . . . . . 37

Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 38The Database Recovery Process . . . . . . . . . . . . . . . . . 38

© Copyright IBM Corp. 1974, 2001 1

How DBRC Helps in Recovery . . . . . . . . . . . . . . . . . . 39Generating Recovery JCL . . . . . . . . . . . . . . . . . . . 39Validating Utility JCL . . . . . . . . . . . . . . . . . . . . . 39Recording the Result. . . . . . . . . . . . . . . . . . . . . 39

Planning Recovery Procedures . . . . . . . . . . . . . . . . . . 39Setting Up Recovery Mechanisms . . . . . . . . . . . . . . . . . 39Recovery Facilities . . . . . . . . . . . . . . . . . . . . . . 40

Dynamic Backout . . . . . . . . . . . . . . . . . . . . . . 40Batch Support . . . . . . . . . . . . . . . . . . . . . . . 40Limitations of DBRC Backout Support . . . . . . . . . . . . . . 41Forward Recovery. . . . . . . . . . . . . . . . . . . . . . 41

Recovery without DBRC . . . . . . . . . . . . . . . . . . . . 42Restart after IMS Failure . . . . . . . . . . . . . . . . . . . . 42Restart after DBRC Failure . . . . . . . . . . . . . . . . . . . 42Recovery Involving IRLM Configurations . . . . . . . . . . . . . . 42Batch Backout . . . . . . . . . . . . . . . . . . . . . . . . 43Archiving Log Records . . . . . . . . . . . . . . . . . . . . . 43

Chapter 3. Initializing and Maintaining the RECON . . . . . . . . . . 45Planning Considerations for the RECON . . . . . . . . . . . . . . . 46

First-Time Users . . . . . . . . . . . . . . . . . . . . . . . 46Avoiding RECON Contention Problems . . . . . . . . . . . . . . . 46

Avoiding RECON Deadlock . . . . . . . . . . . . . . . . . . 47RECON Serialization. . . . . . . . . . . . . . . . . . . . . 47Allocating the RECONs . . . . . . . . . . . . . . . . . . . . 49Avoiding RECON Space Problems . . . . . . . . . . . . . . . 50Creating a RECON . . . . . . . . . . . . . . . . . . . . . 50Variable Size RECON Records . . . . . . . . . . . . . . . . . 51Security Considerations for RECON . . . . . . . . . . . . . . . 54

Initial RECON Access . . . . . . . . . . . . . . . . . . . . . 54Records in the RECON . . . . . . . . . . . . . . . . . . . . . 55

RECON Header Records . . . . . . . . . . . . . . . . . . . 56Log Data Set Records . . . . . . . . . . . . . . . . . . . . 56Database Recovery Records . . . . . . . . . . . . . . . . . . 57

Maintaining the RECONs . . . . . . . . . . . . . . . . . . . . 64Backing Up RECON . . . . . . . . . . . . . . . . . . . . . 64Deleting Unnecessary RECON Log Records . . . . . . . . . . . . 65Reorganizing RECON . . . . . . . . . . . . . . . . . . . . 66RECON Reorganization Procedure . . . . . . . . . . . . . . . 67Replacing Damaged RECONs . . . . . . . . . . . . . . . . . 67Recovering the RECON . . . . . . . . . . . . . . . . . . . 68Replacing a Discarded RECON . . . . . . . . . . . . . . . . . 69

Chapter 4. RECON Upgrade Utility (DSPURU00) . . . . . . . . . . . 71What Is the RECON Upgrade Utility?. . . . . . . . . . . . . . . . . 71Before You Start . . . . . . . . . . . . . . . . . . . . . . . . 71Upgrade Procedure . . . . . . . . . . . . . . . . . . . . . . . 71Input and Output . . . . . . . . . . . . . . . . . . . . . . . . 73JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . 73Upgrade Utility Return Codes and Message Information . . . . . . . . . . 73Example of RECON Upgrade Utility JCL . . . . . . . . . . . . . . . 74

Chapter 5. Database Recovery Control Utility (DSPURX00) . . . . . . . 75What Is the Database Recovery Control Utility (DSPURX00)? . . . . . . . 75Input and Output . . . . . . . . . . . . . . . . . . . . . . . . 75Example of DBRC Utility JCL . . . . . . . . . . . . . . . . . . . 76

2 DBRC Guide & Reference

JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 6. Hints and Tips for DBRC . . . . . . . . . . . . . . . . 79Locating the Last SLDS Stop Time in RECON . . . . . . . . . . . . . 79Adjusting GENMAX When It Is Reached or It Is Too High . . . . . . . . . 80

Solutions for Situation #1 . . . . . . . . . . . . . . . . . . . . 81Solution for Situation #2 . . . . . . . . . . . . . . . . . . . . 81

Getting PRILOG Compression to Work . . . . . . . . . . . . . . . . 82PRILOG Record Sizes . . . . . . . . . . . . . . . . . . . . . . 82Using NOTIFY.PRILOG to Close an Open Online PRILOG . . . . . . . . . 83Deleting Log Records . . . . . . . . . . . . . . . . . . . . . . 84Working with Subsystem Records (SSYS) . . . . . . . . . . . . . . . 84

Naming Conventions for SSIDs in RECON Subsystem Records . . . . . . 84Batch Backout . . . . . . . . . . . . . . . . . . . . . . . . 85Deleting a Subsystem Record . . . . . . . . . . . . . . . . . . 85Subsystem Record Size . . . . . . . . . . . . . . . . . . . . 85

Removing Authorization Inconsistency between the SSYS from DB/AREARecords . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Getting Change Accumulation to Start Processing Logs Again . . . . . . . 86Getting Change Accumulation Working When It States Nothing to Process . . . 86Moving Log Data Sets . . . . . . . . . . . . . . . . . . . . . . 87Reorganizing RECON to Increase Maximum RECORDSIZE . . . . . . . . 87Cataloging Data Sets . . . . . . . . . . . . . . . . . . . . . . 89Performing Multiple Cold Starts in a Test Environment . . . . . . . . . . 90Avoiding Some Causes of RECON Enqueue Problems . . . . . . . . . . 91

In a Shared DASD Environment . . . . . . . . . . . . . . . . . 92In a Non-Shared DASD Environment . . . . . . . . . . . . . . . . 92

Part 1. How to Use DBRC 3


Chapter 1. DBRC in the IMS Database Recovery Process

This chapter provides an overview of the IMS database recovery process and thendescribes DBRC’s (IMS Database Recovery Control facility) role in that process.

In This Chapter:

v “What Is DBRC?”

v “When Should You Use DBRC?” on page 10

v “Initializing DBRC” on page 10

v “Registering Databases and Database Data Sets” on page 12

v “Considerations for Using DBRC” on page 12

v “DBRC Functions” on page 13

v “Data Set Naming Conventions” on page 21

v “DBRC Support for Remote Site Recovery” on page 22

What Is DBRC?DBRC helps you control log and database recovery. It also controls the datasharing environment by allowing (or preventing) access to databases by variousIMS subsystems sharing those databases.

The recovery process for IMS databases can include these three basic steps,although the details of the process can vary with the type of database to berecovered:

1. Restore the database to the most current image copy.

2. Use the log data sets (or change accumulation data sets) to restore changesmade to the database since the image copy was made.

3. Back out any incomplete changes.

Figure 1 illustrates a simple database recovery.

Information for a database recovery can come from any or all of the followingsources:

v Image copies of the database

v Database reorganization data sets

Figure 1. IMS Database Recovery


v Log data sets (SLDSs and RLDSs) 1

v Change accumulation data sets

You can use DBRC to track all of these information sources, greatly simplifying thetask of database recovery.

Related Reading: Refer to IMS Version 7 Operations Guide for more informationon recovery.

DBRC TasksDBRC is responsible for the following tasks:

1. This first group of tasks are those performed automatically through theinteraction of DBRC and IMS (including utilities):

v Controlling logs for IMS

v Recording recovery information in the RECON

v Verifying that database utilities have the correct input

v Controlling the recovery of registered databases

v Controlling the data sharing environment by maintaining authorizationinformation for the control and serialization of access to shared databases

2. These tasks are performed when you request them by passing commands toDBRC:

v Recording recovery information in the RECON

v Generating JCL for various IMS utilities and generating user-defined output(Use GENJCL commands to perform these operations.)

v Listing the information in the RECONs; use LISTcommands to list thisinformation

Related Reading:

v See “Using DBRC to Record Log Information” on page 13 for additionalinformation about DBRC’s logging support.

v See “Using DBRC for Data Sharing” on page 20 for additional information aboutDBRC’s data sharing support.

DBRC ComponentsDBRC includes the following components which are discussed in this section:

v RECONs

v Database Recovery Control utility (DSPURX00)

v Skeletal JCL

v RECON Upgrade utility (DSPURU00)

RECONsDBRC stores recovery-related information in a set of VSAM KSDSs called theRECON (REcovery CONtrol) data sets.

Three RECONs should be defined when you install DBRC. The first two RECONsare active data sets, the third one is a spare. The second active data set is a copyof the first. For most purposes, you can think of the two active RECONs as if theywere a single data set, the RECON, or simply RECON.

1. system log data set (SLDS), recovery log data set (RLDS)

DBRC and Database Recovery


Related Reading: These data sets are described in detail in “Chapter 3. Initializingand Maintaining the RECON” on page 45.

Database Recovery Control Utility (DSPURX00)This utility provides a set of commands that allow you to specify the type ofinformation that is tracked for your IMS databases.

The DBRC commands allow you to perform all of the following tasks:

v List the information in RECON

v Update the information in RECON

v Use the information in RECON to generate jobs for the IMS utilities

Skeletal JCLDBRC also uses partitioned data set (PDS) members that contain skeletal JCL.

DBRC uses the skeletal JCL to generate the JCL and control statements that areneeded in order to run some of the recovery utilities. These PDS members aredistributed with DBRC. You must make any changes to the PDS members that arenecessary for your installation’s system configuration.

RECON Upgrade Utility (DSPURU00)This utility allows you to migrate the RECON from previous releases of IMS to thecurrent release.

Related Reading:

v “Chapter 4. RECON Upgrade Utility (DSPURU00)” on page 71 describesDSPURU00.

v “Chapter 5. Database Recovery Control Utility (DSPURX00)” on page 75describes DSPURX00.

v “Chapter 11. GENJCL Commands” on page 185 and “Appendix B. UnderstandingSkeletal JCL” on page 309 contain information on generating and using skeletalJCL.

IMS Recovery utilities and functionsRecovery utilities is a generic term for the following IMS utilities:

v Online Recovery Service (ORS)

v Database Change Accumulation (DFSUCUM0)

v Database Image Copy (DFSUDMP0)

v Database Image Copy 2 (DFSUDMT0)

v Online Database Image Copy (DFSUICP0)

v Batch Backout (DFSBBO00)

v Database Recovery (DFSURDB0)

v Log Archive (DFSUARC0)

v Log Recovery (DFSULTR0)

The data sets used by these utilities and recorded in the RECONs are image copy,change accumulation, and log data sets. Other recovery-related informationrecorded in RECON includes information about:

v Using IMS databases (for example, which IMS subsystems are using whichdatabases at any given time)

v Recovering database data sets (DBDSs)

v Reorganizing databases


Chapter 1. DBRC and Database Recovery 7

Recording Recovery-Related InformationDBRC automatically records information in RECON on the status of log data setsfor online subsystems. This includes the OLDS, the SLDS, and the RLDS that areproduced by the Log Archive utility. If you specify that DBRC be invoked for batchjobs, DBRC also records the status of the batch SLDS in RECON.

The information recorded for each log data set includes the data set name, volumeserial numbers, start and stop times, and status. DBRC records the archiving ofOLDS data sets, as well as the creation of the corresponding SLDSs and RLDSs. Italso records information about execution of the Log Recovery utility.

If you want DBRC to control database recovery, you must register the databases inRECON. DBRC then records information about when databases were updated andabout the corresponding log data sets that contain updated log records. DBRC alsorecords the creation of image copy and change accumulation data sets, andrecords database recoveries and reorganizations that affect registered databases.

Related Reading: See “Registering Databases and Database Data Sets” onpage 12 for information about registering databases and data sets.

You can use the commands of the Database Recovery Control utility (DSPURX00)or their online IMS equivalents (/RMxxxxxx) to manually add, delete, or changeinformation in RECON. This utility can also list the contents of RECON, generateJCL, and create a backup copy of the RECON. The utility can process thesecommands while running either in a batch environment or as a TSO foregroundprogram.

You can provide your own exit routine for DBRC (named DSPCEXT0), which is tobe called each time RECON records are changed or read. This exit routine, alsocalled the RECON I/O exit routine, allows you to keep track of changes to RECONin the form of a journal.

Related Reading:

v IMS Version 7 Program Directory

v See “Chapter 7. DBRC Commands” on page 99 for an overview of DBRC batchand online command syntax.

v See IMS Version 7 Customization Guide for detailed information on the exitroutine.

Generating JCLDBRC provides PDS members that contain skeletal JCL statements. These PDSmembers are called skeletal JCL execution members.

Figure 2 on page 9 shows the input DBRC uses to create JCL.



DBRC installation procedures place these skeletal JCL execution members from anIMS distribution library (IMS.SDFSISRC) into an IMS procedure library(IMS.PROCLIB). DBRC uses these members to generate jobs (JCL and controlstatements) for the IMS utilities listed in Table 11 on page 309. There is also askeletal JCL execution member, JOBJCL, that produces a JOB statement.

In addition, the GENJCL.USER command generates user-defined output, which caninclude JCL. No skeletal JCL execution members are supplied to support theGENJCL.USER command. If you want to enter GENJCL.USER commands, you mustsupply the members to support them.

Use the GENJCL command to request that DBRC generate JCL in batch or via the/RMGENJCL command online. When you enter this command, DBRC reads skeletalJCL and replaces symbolic parameters (performs symbolic substitution) based onthe information recorded in RECON to build the appropriate JCL. For example, ifyou request that DBRC generate JCL to recover a database, DBRC retrieves theskeletal JCL member from the library and completes the JCL information with thelatest image copy, change accumulation, and log data sets, if necessary. Yourdatabases must be registered in order for DBRC to generate JCL to process them.

The GENJCL process can significantly reduce the time and manual effort required torecover a database. It can also eliminate the causes of many recovery errors. Youcould spend much time during database recoveries determining which input datasets should be provided in what order to the Database Recovery utility. Whenchange accumulation or RLDS data sets are available, DBRC selects them ratherthan the SLDS for recovery. This results in quicker database recoveries if you runthe Database Change Accumulation regularly. DBRC knows which log data sets arerequired and ensures that IMS processes all volumes in the correct order. DBRCalso selects the most recent image copy for database recovery.

Related Reading:

v See IMS Version 7 Installation Volume 2: System Definition and Tailoring formore information about the tailoring actions for IMS.PROCLIB members, theDBRC procedure, and JCLOUT and JCLPDS DD statements.

v See “Appendix B. Understanding Skeletal JCL” on page 309 for details aboutcustomizing your own skeletal JCL and about the contents of IMS supplied JCL.

Figure 2. DBRC JCL Generation



When Should You Use DBRC?Most IMS configurations require DBRC, including:

v Online configurations: DB / DC, DCCTL, or DBCTL

v Data sharing environments, including IMS Sysplex configurations

v Configurations that use Extended Recovery Facility (XRF)

v Remote Site Recovery (RSR)

DBRC plays a key role in managing the log data needed to restart and recover IMSonline subsystems.

DBRC is not required for IMS batch jobs and for some offline utilities. However, ifbatch jobs and utilities that access registered databases are allowed to run withoutDBRC, the recoverability and integrity of the databases could be lost. Even if yourconfiguration does not require the use of DBRC (such as in a non-sharing,non-RSR batch environment), you can simplify your recovery process by usingDBRC to supervise recovery and protect your databases.

Related Reading:

v IMS Version 7 Operations Guide provides detailed descriptions of recoveryprocedures with and without DBRC.

v “Chapter 2. Considerations for a DBRC System” on page 25 further describeshow DBRC helps with database recovery.

Initializing DBRCYou initialize DBRC during IMS system generation. This section provides a briefoverview of the requirements for creating and executing a DBRC region.

Related Reading:

v Refer to IMS Version 7 Installation Volume 1: Installation and Verification andIMS Version 7 Installation Volume 2: System Definition and Tailoring for acomplete description of IMS installation procedures and requirements.

v See “Chapter 3. Initializing and Maintaining the RECON” on page 45 forinformation on creating and allocating the RECON.

Specifying When DBRC Is to Be UsedIMS online systems always use DBRC; you cannot override this.

You can choose whether IMS batch jobs use DBRC. But you must understand thatcertain functions, such as data sharing, cannot be used without DBRC.

The IMSCTRL MacroUse the DBRC= parameter to specify DBRC or no DBRC for all batch jobs. You canalso use this parameter to override DBRC=NO on all batch jobs except:

v If DBRC=FORCE is specified as the first parameter for the IMSCTRL macro,DBRC is active for batch and online environments. DBRC=FORCE cannot beoverridden except in these instances:

– A batch backout execution of IMS

– The execution of the System Log Recovery utility

– The execution of the IMS Log Archive utility



v If DBRC=NO is specified (or defaulted) for the first parameter DBRC is active foronline environments only.

v If DBRC=YES is specified for the first parameter, DBRC is active for bothenvironments unless it is overridden on IMS procedures.

DBRC for an online IMS subsystem resides in its own address space. Use theDBRCNM= parameter to request that IMS create a cataloged DBRC procedure. TheIMS control region initiates the DBRC address space with an MVS START command.

Copy the DBRC procedure that was created when the system was generated fromIMS.PROCLIB to SYS1.PROCLIB.

Place DBRC’s Load modules into a load library that is in the normal load librarysearch sequence for your IMS load modules; for example, IMS.SDFSRESL.

IMS.PROCLIB Execution-Parameter MembersYou can override the DBRC procedure name specified at system generation in theDFSPBIMS, DFSPBDBC, and DFSPBDCC members.

IMS Procedures and DBRCThe EXEC parameter, DBRC=, determines whether DBRC is used in a batchprocedure. It is ignored by an online IMS.

The DBRCNM= parameter may be used to override the DBRC procedure name foran online IMS execution.

DBRC ProcedureIMS automatically starts the DBRC procedure with an MVS START command duringcontrol region initialization. This procedure specifies parameters for the DBRCregion.

To include the DBRC procedure during system generation, you must copy theskeletal procedure that IMS generates in IMS.PROCLIB to SYS1.PROCLIB. Themember name must match the name specified on the DBRCNM parameter in theIMSCTRL macro or the applicable EXEC procedure. If DBRCNM is specified inmore than one place, or if DBRCNM is not explicitly specified, the following order ofprecedence applies:

v DBRCNM=DBRC is the default.

v DBRCNM=name in the IMSCTRL macro overrides the default.

v DBRCNM=name defined in a DFSPBxxx member in IMS.PROCLIB overrides theIMSCTRL macro setting.

v DBRCNM=name defined in a JCL EXEC parameter overrides the IMS.PROCLIBmember setting.

Related Reading: See IMS Version 7 Installation Volume 2: System Definition andTailoring for a complete description of the DBRC procedure and its parameters.

Initializing the RECONUse the Access Method Services (IDCAMS) DEFINE CLUSTER command to create theRECONs and then use the INIT.RECON command to initialize the RECONs asRECONs usable by DBRC.

If you do not intend to register databases, the INIT.RECON command is the onlycommand you need to issue in order to initialize the data set.

Related Reading:



v See “Chapter 3. Initializing and Maintaining the RECON” on page 45 forinformation on creating the RECON.

v See “Registering Databases and Database Data Sets” for information onregistering databases.

v See “Chapter 12. INIT Commands” on page 221 for information on theINIT.RECON command.

Registering Databases and Database Data SetsThe RECON must have a DB record for each database whose recovery DBRC is tocontrol.

For non-HALDBs (High Availability Large Databases), use the INIT.DB andINIT.DBDS commands to register databases in RECON and to define them asrecoverable or non-recoverable. For HALDBs, you can use the INIT.DB andINIT.PART commands, or the HALDB Partition Definition utility.

For each database that you have registered, issue the INIT.DBDS command toregister all its data sets or DEDB areas. For DEDBs, use the INIT.ADS command toidentify the data sets within each area. An area can have up to seven area datasets (ADSs).

A utility job for an INIT.DB command to register a HALDB, or any INIT.DBDScommand, must include a ddname for the IMS.DBDLIB data set that contains anentry for the HALDB DBD, or non-HALDB DBDS, for which you are issuing thecommand (a ddname for the IMS.DBDLIB is not needed for non-HALDB INIT.DBcommand).

Related Reading: See “Chapter 12. INIT Commands” on page 221 for specificsabout the INIT commands.

From a DBRC perspective, a HALDB consists of a HALDB master (TYPE=HALDB)and HALDB partitions (TYPE=PART).

To update or delete information about HALDBs in the RECON data set, you mustuse the HALDB Partition Definition utility. You can use the CHANGE.DB andCHANGE.DBDS commands, with some restrictions.

Related Reading:

v See the IMS Version 7 Administration Guide: Database Manager for an overviewof HALDBs and detailed information about how to create them.

v See the IMS Version 7 Utilities Reference: Database and Transaction Managerfor information about the HALDB Partition Definition utility.

v See “Chapter 9. CHANGE Commands” on page 113 for information about theCHANGE commands.

Considerations for Using DBRCBe aware of the following considerations when using DBRC:

v DBRC does not support main storage databases (MSDBs).

v DBRC plays no role in the processing of GSAM databases, so there is no reasonto register them.

v Logging is required for batch jobs that use DBRC and have update access.

v Never update RECON information (such as for DBDSs or log data sets) about adata set that is currently in use.



||||

|||||

v Be sure to set the time-of-day (TOD) clock value in the host processorsaccurately, or unpredictable results might occur in RECON.

DBRC FunctionsAfter you have initialized DBRC for your installation, DBRC automatically providescontrol for IMS log data sets. If you want DBRC to control the recovery of yourDBDSs, register them with DBRC. The following sections describe how DBRCtracks and controls logs, database recovery, and data sharing.

Using DBRC to Record Log InformationDBRC automatically records information about all log data sets that are producedby the online IMS subsystem and by log archiving jobs in the RECON. IMS usesthis information for database recovery jobs, if databases are registered, and also forIMS restart. DBRC also tracks the archiving requirements of the online data set(OLDS) and, if requested, generates and submits the JCL for archiving jobs.

It is not required that you use DBRC in order to control logs that are produced bybatch subsystems. However, for batch jobs that use DBRC, DBRC records all logdata sets that are produced by batch jobs and prevents any batch update job fromexecuting if you specify a dummy or null log data set.

Attention: If registered databases are updated without DBRC control, DBRCcannot correctly control recovery for the databases and database integrity can bejeopardized.

Changing RECON Log Records: You can use the CHANGE.PRILOG orCHANGE.SECLOG commands to change the information in the RECON about OLDS,RLDS, or SLDS records. Use these commands to indicate that errors have occurredon the data sets or that volume serial numbers have changed. You do not normallyneed to use these commands.

Archiving OLDS: Invoke the Log Archive utility to archive an OLDS to an SLDSso that IMS can reuse the OLDS. How frequently you should archive depends onthe load on the subsystem and the number of log records written to the OLDSs.

The archive utility always produces an SLDS. The SLDS contains all log recordsthat are required for both database recovery and for online IMS restart.

You can ask the utility to produce an RLDS in addition to an SLDS. The RLDScontains only those log records that are required for database recovery.

If you request an RLDS, the output RLDS data sets are recorded in the PRILOGRECON record, and the SLDS data sets in the PRISLD record. If you do notrequest an RLDS, the same SLDS data sets are recorded in both the PRILOG andPRISLD records.

If there is a secondary OLDS, or if you request that dual logs be produced from asingle OLDS, the secondary-log output is recorded in corresponding SECLOG andSECSLD records.

Important: Log data sets that are output from IMS batch jobs are recorded inPRILOG / SECLOG records even though they are technically SLDSs.

Invoke the archive utility by entering the GENJCL.ARCHIVE command. DBRC thendetermines which OLDSs are full, and generates the appropriate JCL.



Related Reading: See Member DFSVSMxx in the IMS Version 7 InstallationVolume 2: System Definition and Tailoring for more information on the ARCHDEFstatement and automatic archiving.

Whether you use automatic archiving or invoke archiving yourself, you should makesure the archive jobs run as quickly as possible. The online subsystem only reusesan OLDS after it has been archived. If the archive job is not run and all OLDSs areused, the online subsystem waits. One way to ensure that archive jobs run quicklyis to use an initiator that runs with a fairly high priority and is not used by manyother users. This ensures that the archive jobs do not remain on the internal readerqueue for too long.

If DBRC has marked an OLDS in RECON as having errors, the GENJCL functiondoes not submit it for archiving. If one of a pair of OLDSs has been destroyed or isunavailable, you can choose to mark it in RECON as having errors.

DBRC Log Related Commands: You can use the following commands, whichperform DBRC log-related functions, in your operational procedures:

INIT.RECON DELETE.LOG LIST.LOGCHANGE.PRILOG GENJCL.ARCHIVE NOTIFY.PRILOGCHANGE.RECON GENJCL.CLOSE NOTIFY.SECLOGCHANGE.SECLOG

Related Reading: Refer to the command chapters in “Part 2. CommandReference” on page 93 for descriptions of the commands.

Using DBRC for Database RecoveryIf you register recoverable databases in RECON, DBRC records the association ofthe databases to the log data sets containing database change records.

DBRC also records:

v Database image copies

v Reorganizations (except DEDB online reorganizations)

v Recoveries

v Change accumulations

v Backout

Because DBRC records this information in RECON, DBRC can generate JCL forexecuting a database recovery. Whether you use the GENJCL commands to generateJCL or provide the JCL yourself, DBRC uses information in the RECON todetermine exactly which data sets are required for input. The utility runs only ifDBRC verifies that the JCL is correct.

Figure 3 on page 15 shows where DBRC generally fits in utility execution.



Implement DBRC in phases, defining at first only a few recoverable databases inRECON. This allows you to gain experience in the use of DBRC, and gives you anopportunity to assess, make, and test any changes needed in your backup,recovery, and operational procedures.

Using the IMS Recovery Utilities: DBRC is invoked by the following IMS utilitiesand services to validate input and record the results:

v Index/ILDS Rebuild Utility (DFSPREC0)

v Database Image Copy utility (DFSUDMP0)

v Online Recovery Service (ORS)

v Database Image Copy 2 utility (DFSUDMT0)

v Online Database Image Copy utility (DFSUICP0)

v Database Change Accumulation utility (DFSUCUM0)

v Batch Backout utility (DFSBBO00)

v Database Recovery utility (DFSURDB0)

v Log Recovery utility (DFSULTR0)

v Log Archive utility (DFSUARC0)

v HD Reorganization Unload utility (DFSURGU0)

v HD Reorganization Reload utility (DFSURGL0)

v HISAM Reorganization Unload utility (DFSURUL0)

v HISAM Reorganization Reload utility (DFSURRL0)

v Database Prefix Update utility (DFSURGP0)

v DEDB Area Data Set Create utility (DBFUMRI0)

Figure 4 on page 16 shows where DBRC specifically fits in the input scheme.

Figure 3. DBRC’s Role in Utility Execution



DBRC checks that these utilities perform the correct processing with the correctinput data sets. This is true even if you do not use the GENJCL command. DBRCverifies the JCL for these utilities before execution.

Exception: For the HD and the HISAM reorganization utilities, DBRC only recordstheir execution in RECON.

DBRC always selects the optimum input for the Database Recovery utility by usingchange accumulation data sets whenever possible. If you have not used theDatabase Change Accumulation utility, or if that utility did not process some logdata sets, DBRC selects the required log data sets from the PRILOG (or SECLOG)records, which can contain RLDS, SLDS, or both RLDS and SLDS entries.

The DEDB Area Data Set Create utility increases availability by providing additionalusable copies of an online area. It does not provide backup copies for recovery. TheDEDB Area Data Set Create utility uses the DBRC RECON data set as part of itsinput.

DBRC verifies all logs that are input to the database Batch Backout utility(DFSBBO00) by determining the complete set of logs that are needed for aparticular backout job. In addition, DBRC manages information about the logs sothat backout and restart jobs can be easily coordinated.

DBRC also provides unit-of-recovery management for all attached subsystems.DBRC provides information about these units of recovery for batch backout,dynamic backout, partial backout, and restart.

Related Reading:

v See IMS Version 7 Utilities Reference: Database and Transaction Manager formore information on the IMS recovery utilities.

v See “NOTIFY.BKOUT” on page 264 for information about a related command,which manually creates a backout record in RECON.

Figure 4. DBRC’s Specific Place in a Utility Input Scheme.



Specifying Image Copy Requirements: If you use a supported image copy utility,DBRC records the image copies for registered databases. DBRC also generatesthe JCL for the utility if you enter the GENJCL.IC or GENJCL.OIC command.

If you use nonstandard image copy techniques, such as a pack dump, you mustcreate your own JCL and update RECON with a NOTIFY.UIC command.

When you register a DBDS in RECON, you specify the maximum number of imagecopy generations for DBRC to record with the GENMAX parameter of the INIT.DBDScommand. When this number is exceeded, DBRC discards the information relatingto the oldest image copy. For example, if you take image copies daily and want tokeep four days of back level image copies, specify a GENMAX of 4. However, insome emergency situations, you may take backup copies more frequently, possiblythree in one day. To prevent DBRC from discarding information relating to theearlier copies, specify the optional parameter RECOVPD to indicate the number ofdays you want information retained. If the GENMAX limit is reached, but theRECOVPD for the oldest image copy record has not expired, DBRC issues awarning message (DSP0065I), and does not discard the record. If the DSP0065Iwarning message appears frequently, you might need to tune the GENMAX orRECOVPD values with the CHANGE.DBDS command.

DBRC also provides an optional data set recycling capability for standard imagecopies. You can, for example, pre-allocate four DASD data sets to contain theimage copy, and request that DBRC reuse these data sets. The recycling capabilityis indicated using the REUSE keyword of the INIT.DBDS command. DBRC thengenerates JCL so that the oldest DASD data set is always used for output from theimage copy. DBRC has the same capability with tape volumes. However, you needto analyze your existing tape library techniques to make sure there is no conflict.

Concurrent Image Copy: The concurrent image copy process requires that adatabase be registered with DBRC. Information about a concurrent image copy dataset is recorded in the RECON data set. When concurrent image copy succeeds, atrue image exists and can be used for recovery.

You cannot take concurrent image copies of a nonrecoverable databases becausechanges to them are not logged, and the fuzzy (incomplete) copy remains fuzzy ifthe database is recovered.

HSSP Image Copy: The high speed sequential processing (HSSP) image copy(IC) process requires that a database be registered with DBRC and requires that anarea be registered with the REUSE attribute for recycling the predefined IC datasets. Image copies that are created by HSSP are concurrent image copies.

Database Image Copy 2: The Database Image Copy 2 utility requires thatdatabases and areas be registered with DBRC. You cannot take concurrent imagecopies of nonrecoverable databases.

Specifying Change Accumulation Requirements: If you decide to use theDatabase Change Accumulation utility for some or all of your recoverable registereddatabases, specify the change accumulation groups using the INIT.CAGRPcommand. You can, for example, divide the DBDSs into the following groups:

v Application-associated databases

v Physical database clusters

v Logical database clusters

v Volatile (critical data) databases



As with image copies, DBRC provides an optional data set recycling capability forchange accumulations. If you decide to use this capability, specify the data setinformation using the INIT.CA command.

You can add or delete members of a CA group after you have created it. Adatabase can be a member in only one CA group. To move a member from one CAgroup to another CA group, you must first delete it from its current CA group andthen add it to the new CA group.

Recommendation: When moving a member to a new CA group, it may bebeneficial to do so shortly after an image copy is done. The change accumulationutility processes all logs for the member that are needed for recovery, based on thelast good image copy.

Using DBDS Groups: A DBDS group is a named collection of DBDSs or DEDBareas. DBRC can perform various operations by DBDS group so that you do notneed to repeat the command for every member of the group.

You can specify DBDS groups on the following commands:

GENJCL.IC GENJCL.OICGENJCL.RECEIVE GENJCL.RECOVGENJCL.USER LIST.DBDSLIST.HISTORY

When you specify a DBDS group on a command, DBRC invokes that command foreach member of the DBDS group. For example, you might have a DBDS group fora particular application, like payroll. When performing a timestamp recovery, forexample, all DBDSs of a particular application of a database must be recovered tothe same point. If you specify a DBDS group on the GENJCL.RECOV command, youneed only invoke the command once to recover all DBDSs.

You can also specify a CA group as a DBDS group. DBRC then executes thecommand for each member of the CA group.

You can define as many DBDS groups as you want. Up to 2000 DBDSs can be in agroup. All DBDSs in a group must be registered in RECON. A DBDS can belong tomore than one DBDS group.

A database is an implied DBDS group for the GENJCL and LIST commands. It isunnecessary to define a DBDS group consisting of the DBDSs or areas of a singledatabase. Specify the database name and omit the DDNAME to operate on thewhole database.

The following commands affect the definition of a DBDS group:

v INIT.DBDSGRP

v CHANGE.DBDSGRP

v DELETE.DBDS

v DELETE.DBDSGRP

v LIST.DBDSGRP

DBDS groups can include ILDS (Indirect List Data Set) and index data sets.



Related Reading: See “Chapter 11. GENJCL Commands” on page 185 for theimpact of these data sets on the GENJCL commands.

Using DB Groups: A DB group is a named collection of databases or DEDBareas. A DB group name can be specified in the /START, /STOP, /DBRECOVERY, and/RECOVER commands, instead of issuing these commands separately for eachdatabase or area. Specifying a DB group name with these commands greatlyreduces the number of times these commands must be issued. Use theDATAGROUP keyword to specify the DB group name.

DB groups can also include HALDB master and HALDB partition names. Be awareof the effects of a command issued using a DB group that has a HALDB mastername and one or more of its partitions. See IMS Version 7 Command Reference formore information.

You can define as many DB groups as you want. Up to 2000 databases or areascan be in a group. A database or area can belong to more than one DB group andneed not be registered in RECON.

Recommendation: Use a database group whenever possible, even though aDBDS group can be used as a DB group. Processing a DBDS group as a DB groupentails increased overhead.

DB groups are a form of a DBDS group, so they are stored in RECON using theDBDS group record. The following commands affect the definition of a DB group:

v INIT.DBDSGRP

v CHANGE.DBDSGRP

v DELETE.DBDSGRP

v LIST.DBDSGRP

Opening a Database: After IMS opens a database, DBRC passes back theRECON initialization token (RIT) and any extended error queue elements (EEQEs)associated with each DBDS. The RIT allows IMS to determine whether thedatabase has been used without DBRC or whether the database has beencontrolled by a different RECON.

Related Reading: See IMS Version 7 Operations Guide for information onEEQEs.

Recording Allocations and De-allocations: DBRC records information inRECON about changes to DBDSs and areas. DBRC subsequently uses thisinformation to determine what log data sets might contain change records for agiven DBDS or area.

When a DBDS that is registered in RECON is first updated, IMS tells DBRC tocreate an ALLOC record. In the case of a DEDB area, the ALLOC record is createdwhen the area is first opened for update. This record identifies the DBDS or areaand contains the time stamp of the first update and the open time stamp of thecorresponding PRILOG.

When DBRC creates the ALLOC record, DBRC enters the name of the DBDS orarea being changed in the LOGALL record for the PRILOG that is active at the timeof the change.



When you de-allocate a DBDS or area using a /DBRECOVERY command from theoperator console of the online IMS subsystem, DBRC writes a de-allocation timestamp in the ALLOC record that was created when the DBDS or area wasallocated. If no de-allocation time is recorded, DBRC uses the closing time of theassociated log as the de-allocation time. Thus RECON contains a list of the namesof DBDSs or areas for which change records might exist on a given log data set(LOGALL record) and a list of the time ranges where changes could exist for aspecific DBDS or area (ALLOC records) and a list of the logs containing them.

Using DBRC for Data SharingData sharing requires that the databases be registered with DBRC. DBRC checksthat subsystems have authority to perform the requested task and that othersubsystems are not currently reserving the database.

Related Reading: See the IMS Version 7 Operations Guide and the IMS Version7 Administration Guide: System for more information on data sharing.

Levels of Data Sharing: DBRC supports the two levels of IMS data sharing:

Database level The entire database or DEDB area is a resourcethat can be accessed for update by a single IMSsystem at a time. For area resources this can alsobe called Area-level sharing.

Block level A database or DEDB area can be accessed bymultiple IMS subsystems concurrently. Dataintegrity is preserved for the IMS subsystems thataccess the shared data. Within a database or area,resources are reserved at the block level.

Definition:

v For OSAM databases, the block is a physical data block stored on DASD. ForVSAM databases and DEDBs, the block is a control interval (CI).

Sharing Information Recorded in RECON: DBRC records the following datasharing information in RECON for all registered databases:

v Sharing level allowed for each database

v Names of databases or areas currently authorized for processing

v Names of IMS subsystems that are involved

v Statuses of the IMS subsystems

v Database statuses from a recovery viewpoint

Assigning a Sharing Level with DBRC: The sharing level of a database orDEDB area determines whether a request for access is granted. DBRC allows youto establish one of four sharing levels using the INIT.DB or CHANGE.DB commands.

The following sharing levels are defined using the INIT.DB command.

SHARELVL 0 The database is not to be shared. The database can be authorizedfor use by one IMS system at a time. SHARELVL 0 is equivalent tospecifying ACCESS=EX on the /START command.

SHARELVL 1 Sharing is at the database level. One IMS system can beauthorized for update at one time; any sharing systems can only beauthorized for read-only processing. Otherwise, the data sharing isfor multiple readers.



SHARELVL 2 Sharing is at the block level but only within the scope of a singleIRLM and a single MVS. Sharing requires that IMS subsystemssharing a database use the same RECON. Multiple IMS systemscan be authorized for update or read processing.

SHARELVL 3 Sharing is at the block level by multiple IMS subsystems on multipleIRLMs. Multiple IMS systems can be authorized for non-exclusiveaccess. The IMSs can be on multiple MVSs using different IRLMs.

Data Set Naming ConventionsThe use of MVS catalog facilities for image copy and change accumulation datasets is optional, because DBRC always records volume serial information pertainingto these data sets in RECON. If you catalog image copy and change accumulationdata sets, they must have unique data set names.

DBRC provides a data set naming convention to help you generate unique data setnames for those image copy data sets (for HSSP image copies and concurrentimage copies, as well as standard image copies) and change accumulation datasets that you define for future use.

If you use this convention all the time, uniqueness of your data set names isassured. If you use the convention only occasionally, you are sent a message at theend of your job step that indicates that you did not follow the naming conventionand that duplicate data set names could exist in RECON. DBRC assumes that dataset names specified in quotation marks do not follow the name convention.Therefore, DBRC does not check data set names surrounded by quotation marks.

When you add records to RECON that create data sets for one of the recoveryutilities to use in the future and you are using this data set naming convention, youcan specify either the fully-qualified data set name or simply the abbreviationhigh-level-qualifier.*.low-level-qualifier (for example, ALPHA1.*.OMEGA). You canuse these abbreviated names on any INIT, CHANGE, DELETE, or NOTIFY.REORGcommand of DBRC when you are specifying the name of a data set that follows thenaming convention. DBRC expands the abbreviated name to its fully-qualified formbefore it accesses RECON.

Naming Convention for Image Copy Data SetsThe format for image copy data sets is:

high-level-qualifier.dbdname.ddname.IC.low-level-qualifier

where:

v high-level-qualifier is a the data character string of your choice from one to eightalphanumeric characters long. The first character must be alphabetic.

v dbdname is the database name of the DBDS for which the image copy data setis being recorded in RECON.

v ddname is the data set ddname of the DBDS for which the image copy data setis being recorded in RECON.

v IC indicates that this is the image copy data set.

v low-level-qualifier is a character string of your choice from one to eightalphanumeric characters long. It must be unique for each DBDS and the firstcharacter must be alphabetic.



Naming Convention for Duplicate Image Copy Data SetsThe format for duplicate image copy data sets is:

high-level-qualifier.dbdname.ddname.IC2.low-qualifier

This is identical to the convention for image copy data sets, except that the IC2 fieldindicates that this is a duplicate image copy data set.

Naming Convention for Change Accumulation Data SetsThe format for change accumulation data sets is:

high-level-qualifier.cagrpname.CA.low-level-qualifier

where:

v high-level-qualifier is a character string of your choice that can be from one toeight alphanumeric characters long. The first character must be alphabetic.

v cagrpname is the name of the CA group for which you are creating the changeaccumulation data set.

v CA indicates that this is a change accumulation data set.

v low-level-qualifier is a character string of your choice that can be from one toeight alphanumeric characters long and must be unique for each CA group. Thefirst character must be alphabetic.

DBRC Support for Remote Site RecoveryDBRC assists you in the installation of IMS DB and IMS TM, as well as with thedefinition and management of IMS components in the Remote Site Recovery (RSR)complex. In support of RSR, DBRC provides:

v Commands to define, update, and display the status of the RSR complex.

The RECON contains the definition of an RSR complex. You define the elementsof the RSR complex with DBRC commands, and you can modify and display theRSR complex definition with other DBRC commands.

Related Reading: See IMS Version 7 Operations Guide for more information onRSR.

v Services that are used by an active subsystem to identify the tracking subsystemand the databases covered by RSR.

An active subsystem obtains the identity of its tracking subsystem from DBRC.As databases are updated by the active subsystem, DBRC tells the databasecomponent whether the database is covered by RSR. And the active subsystemsends its log data to the tracking subsystem.

v Services used by a tracking subsystem to record information about log data thatis received from an active subsystem.

As logs are received and stored at the tracking site, DBRC records the receipt ofthe log data. When begin-update records are received for registered databases,DBRC records the database update.

v Tracking subsystem database support:

– Two types of tracking (called shadowing): DB level tracking (DBTRACK) orRecovery level tracking (RCVTRACK).

– Maintains log data set information for online forward recovery.

– Records which database change records have actually been applied to thecovered databases.

v Services to assist in the takeover process



During a remote takeover, DBRC changes the state of the registered databasesat the new active site to indicate that they are now the master databases.

Related Reading: See IMS Version 7 Administration Guide: System for moreinformation on controlling database recovery.




Chapter 2. Considerations for a DBRC System

This chapter discusses concepts under the following headings that might be helpfulfor you to consider for your DBRC system.

In This Chapter:

v “Database Backup Copies”

v “Log Record Change Accumulation” on page 33

v “Recovery” on page 38

v “Batch Backout” on page 43

v “Archiving Log Records” on page 43

This chapter also describes how to use DBRC to control these database-relatedand log-related processes:

v Creating backup copies of databases

v Creating DB change accumulation data sets

v Recovering databases

v Protecting databases that need backout

v Archiving OLDSs

Database Backup CopiesWhen IMS takes a regular system checkpoint, it records internal control informationfor DL/I (for Fast Path, IMS also records buffers and MSDBs), but it does not recordthe external contents of the database. If the database is lost, examining the lastsystem checkpoint does not help. The log can tell you what changes have occurred,but without a backup copy of the database, recovery is impossible.

Recommendation: Make a backup copy of the database after you initially load it,and make new backup copies at regular intervals. The more recent the backupcopy is, the fewer log change records need to be processed during recovery, thusreducing the time that is needed for recovery.

IMS enables you to make backup copies in these ways:

v The Database Image Copy utility (DFSUDMP0) runs offline and uses accessmethod services to make the copy.

v The Database Image Copy 2 utility runs offline and invokes DFSMS ConcurrentCopy to make the copy.

v The Online Database Image Copy utility (DFSUICP0) runs online and uses IMSservices to make the copy.

v The unloaded data that is output from the HISAM Reorganization Unload utility(DFSURUL0) can be used as a backup copy.

v HSSP processing can also create image copies of DEDB areas.

When these utilities run, they can (depending on installation parameters) call DBRCto update essential information in the RECON. You can also use various utilitiessupplied by the operating system to make your backup copies; however, these donot interact with DBRC, and so you need to take certain actions to notify DBRC ofyour non-standard image copies. See “Nonstandard Image Copy Data Sets” onpage 32 for a discussion of how to notify DBRC about these data sets.


Related Reading: See IMS Version 7 Administration Guide: Database Manager formore information on HSSP processing of DEDB areas.

The Image Copy Utilities (DFSUDMP0, DFSUICP0, DFSUDMT0)IMS enables you to “take a picture” of your database before and after changeshave been made to the database. The “pictures” are called image copies. The termrefers to the fact that the copy is an as-is image; the image copy utilities do notalter the physical format of the database as they copy it. Image copies are backupcopies of your data that help speed up the process of database recovery.

The Database Image Copy utility (DFSUDMP0), Database Image Copy 2 utility(DFSUDMT0), and Online Database Image Copy utility (DFSUICP0) create imagecopies of databases. All of the image copy utilities operate on data sets or areas, soif a database is composed of multiple data sets or areas, be sure to supply theutility with multiple specifications. You can request that one of the supported imagecopy utilities produce an image copy data set and a duplicate image copy data setin one run of the utility.

Recommendation: It is advisable to copy all data sets or areas belonging to adatabase at one time. If you perform multiple recoveries in order to reset adatabase to a prior state, recover all data sets belonging to the database and to alllogically related databases (including those related by application processing) to thesame point to avoid integrity problems.

Each of the image copy utilities provide the option to create backup copies withouttaking databases and areas offline. You can use this capability to provide increaseddatabase availability. Image copies taken while the database is available forconcurrent update processing by IMS applications are called concurrent imagecopies or ’fuzzy’ image copies. When the concurrent image copy option is not used,the database must be either taken offline or made available only for ’read’ accessand a consistent or ’clean’ image copy is taken. See “Concurrent Image Copy” onpage 28 for more information.

When using these utilities, you have the option of creating one to four output imagecopies. Only the Database Image Copy 2 utility allows three or four output copiesand only the first two output copies are recorded in RECON. The advantage ofmaking multiple copies is that if an I/O error occurs on one copy, the utilitycontinues to completion on the other copies. Also, if one copy cannot be read, youcan perform recovery using another. The trade-off in deciding whether to makemultiple copies, is that performance can be degraded because of the time requiredto write the additional copies.

DBRC works similarly with the three image copy utilities. The rules for pre-definitionand reuse of image copy data sets apply to all three. Each utility calls DBRC toverify the input to the utility (DBRC allows it to run only if the input is valid), and itcalls DBRC to record information in the RECON about the image copy data setsthat it creates. An image copy record in RECON has the same format whether itscorresponding image copy data set was created by the Database Image Copyutility, the Database Image Copy 2 utility, or by the Online Database Image Copyutility. Two different commands create image copy jobs:

v GENJCL.IC for the offline utilities Database Image Copy and Database ImageCopy 2

v GENJCL.OIC for the online utility Online Database Image Copy

Backup Considerations


When you run batch jobs without logging, take an image copy immediatelyafterwards; do not count on rerunning the batch jobs, as part of a subsequentrecovery, in combination with the Database Recovery utility. Since the batchprocessing is not guaranteed to be physically repeatable, the database could bedamaged by the combination.

Database Image Copy (DFSUDMP0)Database Image Copy (DFSUDMP0) copies data sets for HISAM, HIDAM, HDAM,PHDAM, PHIDAM, and PSINDEX databases, and areas for DEDBs. It runs offlineand supports a CIC (concurrent image copy) option that enables you to take animage copy while the database remains online.

Note: PHDAM (partitioned HDAM), PHIDAM (partitioned HIDAM), and PSINDEX(partitioned secondary index) are database organizations that are known asHALDBs (High Availability Large Databases). Unlike the other IMS database types,HALDBs are partitioned full function DL/I databases. See IMS Version 7Administration Guide: Database Manager for more information about IMS databasetypes, and a comparison of HALDBs with non-HALDBs.

When you run the Database Image Copy utility to take a consistent image copy(CIC option not specified), the use of DBRC is not required but is recommended.DBRC ensures that there is no update activity against the database or area whilethe utility is executing. If you run the utility without using DBRC you must makecertain that no updates occur to the database or area. You can issue a /DBDUMPcommand or a/STOP AREA command, for example, to prevent updating of thedatabase or area by transactions in the system previously doing updates.

To request a concurrent image copy, use the CIC keyword on the GENJCL.ICcommand. Alternatively, you can specify the CIC parameter on the EXEC statementfor image copy job. DBRC must be used by the utility and you can only take aconcurrent image copy of a database that has been registered with DBRC.

Using Database Image Copy, concurrent image copies of OSAM data sets andVSAM Entry Sequenced Data Sets (ESDSs) can be taken. VSAM Key SequencedData Set (KSDSs) are not supported for concurrent image copy by this utility.

Database Image Copy 2 (DFSUDMT0)The Database Image Copy 2 utility (DFSUDMT0) uses DFSMS Concurrent Copy totake an image copy. It invokes DFSMS to dump the input data set using theConcurrent Copy option. The output is recorded in the RECON and can be used fordatabase recovery in the same way as the output from either of the other imagecopy utilities. You can use this utility for HISAM, HIDAM, HDAM, PHDAM, PHIDAM,and PSINDEX databases and for DEDB areas. Database data sets that are to becopied by this utility must reside on hardware that supports the Concurrent Copyoption.

An optional COMPRESS parameter invokes the ″compress″ option in DFSMSConcurrent Copy. The ″compress″ option enables you to reduce the storage spacerequired to hold the image copy; however, using the compress option increases theCPU time that is required to perform the copy operation.

The Database Image Copy 2 utility provides greater database availability whentaking consistent or ’clean’ image copies. The database needs to unavailable forupdate processing for only a very short period of time while DFSMS establishes a


Chapter 2. Considerations for a DBRC System 27

concurrent copy session. Update processing can than be resumed while the imagecopy data sets are actually being written. The updates are not included in the imagecopy.

This utility can also copy the database while it is being updated by IMSapplications. The image copy created in this case is a ’fuzzy’ copy or a concurrentimage copy. The Database Image Copy 2 utility can copy all supported data settypes, including VSAM KSDSs, while the databases remain online.

The Database Image Copy 2 utility must use DBRC and the databases and areasbeing copied must be registered with DBRC. The utility can create up to 4 outputcopies, but only the primary and secondary copies are recorded in the RECON.

The image copy output from the Database Image Copy 2 utility is in DFSMS dumpformat, which is different than the format of the output of the other image copyutilities. It is, however, directly usable as input to the Online Recovery Service(ORS) and to the Database Recovery utility. The image copies are recorded inRECON with image copy type SMSCIC or SMSNOCIC. The Database Recoveryutility must use DBRC when recovering with these types of image copy data sets.

Online Database Image Copy (DFSUICP0)Online Database Image Copy (DFSUICP0) runs as a BMP program in the onlineIMS and DBCTL environments. You can use it for HISAM, HIDAM, HDAM, PHDAM,PHIDAM, and PSINDEX databases only; it does not support areas. A databasebeing copied by this utility is available for updating by the IMS subsystem in whichthe utility is executing. Other IMS subsystems cannot have concurrent updateaccess to the database.

If the database being copied is updated while the utility is running, a ’fuzzy’ imagecopy is produced. Recovery with this image copy requires all logs starting with thelog that was in use when the Online Database Image Copy utility was started.

Related Reading: See the IMS Version 7 Utilities Reference: Database andTransaction Manager for more information about specifying the CIC option on theEXEC statement.

Concurrent Image CopyIMS provides the capability to take an image copy of a database without taking thatdatabase offline. This means the database can be updated while the image copy isbeing taken and some, all, or none of the updates might appear in the image copy.This image copy is called ″fuzzy″ because the copy represents the state of thedatabase over a certain period of time rather than at one specific instant in time. Itis also called a ’concurrent image copy’ because the copy was taken while updateprocessing is happening.

The ability to take image copies while the databases are being updated by IMSapplications allows increased database availability. The offline image copy utilities,Database Image Copy and Database Image Copy 2, provide an option to take aconcurrent image copy. A database being copied by the Online Database ImageCopy utility can be concurrently updated by the IMS subsystem in which the utility isrunning (but not by other IMS subsystems). Image copies created by HSSPprocessing are also ’fuzzy’ copies because the areas are available for updateprocessing while HSSP is running.



When a consistent or ’clean’ image copy is input to database recovery, the recoveryonly requires logs from after the image copy job completed. A concurrent imagecopy, might not include updates that were made before the image copy processstarted or while it was executing. Therefore, when a concurrent image copy is inputto recovery, logs from before the image copy process was started might have to besupplied to database recovery.

You can only take a concurrent image copy of a database that is registered withDBRC. Also, the Database Image Copy utility (which can take consistent imagecopies without using DBRC) must use DBRC when taking a fuzzy copy. You cannottake a concurrent image copy of a non-recoverable database. Fuzzy copying ofnon-recoverable databases is not allowed because there is no log data to’complete’ the image copy.

Creating Image Copy Data Sets for Future Use and ReuseUse the REUSE parameter to inform DBRC that you want to be able to defineimage copy data sets and record them in RECON for future use. You define imagecopy data sets with the INIT.IC command. When processing the GENJCL.ICcommand, DBRC selects one of the image copy data sets for use by the imagecopy utility.

When the Database Image Copy utility uses an available image copy data set,DBRC updates its record in RECON with the time stamp of the run of the DatabaseImage Copy utility during which the image copy data set was used.

If you specify the NOREUSE parameter, you cannot predefine image copy data sets(This is the default). You need to supply the output data set name for the utility ineither the skeletal JCL member used in processing the GENJCL.IC command or inthe JCL that you produce yourself. When you specify NOREUSE, DBRCdynamically sets the unit type of the output image copy data set. DBRC sets it tothe default unit type for the device as specified in the INIT.RECON and CHANGE.RECONcommands. Specify NOREUSE when you want more than two DFSMS concurrentcopies (you can have up to four).

If you do not specify REUSE, every time the image copy utility is run DBRC deletesthe oldest image record that exceeds both the GENMAX and RECOVPD values.The image copy data set itself is not scratched-only its record in RECON isscratched. You must either scratch the data set or keep track of it yourself, becauseDBRC is no longer aware of its existence.

If you are using the image copy option of HSSP for a DEDB area, the area must bedefined with the REUSE parameter and the data sets you predefine must becataloged.

Controlling the Number of Image Copies ManagedYou can use the INIT.DBDS and the CHANGE.DBDS commands to specify how manyimage copies of the DBDS or area that DBRC is to maintain records of.

The GENMAX parameter specifies the maximum number of recovery generations(images) that DBRC maintains for the identified DBDS or DEDB area. Duplicateimage copy data sets are not included in this number.

Use the RECOVPD parameter to maintain data for a certain period.

Related Reading:



v See “Recovery Period of Image Copy Data Sets and GENMAX” for moreinformation about the RECOVPD parameter.

v See “INIT.DBDS” on page 227 for more information on the REUSE, NOREUSE,GENMAX, and RECOVPD.

Recovery Period of Image Copy Data Sets and GENMAXA recovery period is the minimum amount of time that image copy information ismaintained in RECON. For example, if the recovery period of a DBDS or DEDBarea is 14 days, image copies are maintained for at least 14 days.

If both GENMAX and RECOVPD have been specified for a DBDS or DEDB area,DBRC considers both when deciding whether to reuse or delete an image copydata set.

Table 1 shows the results of GENJCL.IC processing when both GENMAX andRECOVPD have been specified for a DBDS or area defined with the REUSEparameter.

Table 1. Results of GENJCL.IC Processing when GENMAX and RECOVPD are Specifiedwith REUSE

Number ofImage Data Sets

Number ofIn-Use ImageCopies

Age of OldestImage Copy

GENJCL Result

=GENMAX =GENMAX <RECOVPD Fail (DSP0063I)

>GENMAX =GENMAX <RECOVPD Avail IC DS used (DSP0065I)

=GENMAX =GENMAX >RECOVPD Oldest IC DS reused

Table 2 shows the results of running an image copy utility when both GENMAX andRECOVPD have been specified for a DBDS or area defined with the NOREUSEparameter.

Table 2. Results of GENJCL.IC Processing when GENMAX and RECOVPD are Specifiedwith NOREUSE

Number of Image Copies Age of Oldest ImageCopy

Utility EOJ Result

=GENMAX >RECOVPD Delete oldest image copy

=GENMAX <RECOVPD No delete (DSP0064I)

<GENMAX N/A No delete

If you issue a CHANGE.DBDS command and specify new GENMAX and RECOVPDvalues that are less than the existing values, any used image copy data sets thatare beyond the recovery period are deleted until the number of remaining imagecopy data sets equals the specified GENMAX value.

If you issue the DELETE.IC command, any specified image copy data set record isdeleted regardless of RECOVPD or GENMAX.

Reusing Image Copy Data SetsDBRC enables you to reuse old image copy data sets. The REUSE parameter ofthe INIT.DBDS command, in addition to enabling you to define image copy data sets



for future use, enables DBRC to reuse image copy data sets. To reuse the imagecopy data set means that the same name, volumes, and physical space are usedfor the new image copy.

A run of one of the IMS image copy utilities automatically reuses the oldest imagecopy data set for a DBDS or area with the REUSE attribute when all of thefollowing conditions are met:

v A number of image copy data sets equal to the current GENMAX value arerecorded in RECON. To see the current GENMAX value, use the LIST.DBDScommand.

v The Database Image Copy utility or Online Database Image Copy utility used allimage copy data sets for this DBDS. None of the image copy data sets isavailable.

v The oldest image copy is beyond the recovery period.

When you use a GENJCL.IC command to generate the job for the Database ImageCopy utility, the image copy data set that is to be reused is automatically selected.If the number of image copy data sets is less than the GENMAX value and allimage copy data sets have been used, more image copy data sets must be definedfor the DBDS or area before running the Database Image Copy utility. The numberof image copy data sets should be greater than the GENMAX value if you want touse a recovery period.

The Database Image Copy 2 utility can create up to four output image copy datasets. However, GENJCL.IC for a DBDS defined as REUSE generates JCL only oneor two output copies (because you can define image copy data sets for only one ortwo copies). If you use GENJCL.IC for the Database Image Copy 2 utility to processa DBDS defined as REUSE and you want more than two output copies, you haveto modify the generated JCL before you execute the job.

HISAM Copies (DFSURUL0 and DFSURRL0)Using the HISAM Reorganization Unload utility (DFSURUL0) to make backupcopies of a database lets you process an entire HISAM database in one pass (theimage copy utilities deal with single data sets or areas). The unload utility(DFSURUL0) also reorganizes the database as it copies it.

Because the unload utility (DFSURUL0) reorganizes the database, before resumingnormal online operations, the data set must be reloaded using the HISAMReorganization Reload utility (DFSURRL0), as shown in Figure 5. The logging,which is done between the unload and reload, reflects the old data set organization.

When using the HISAM utility to make a backup copy, reload immediately, or theactual database and the backup database are mismatched.

The reload utility (DFSURRL0) notifies DBRC. The unload utility creates areorganized copy of each data set. Then the reload utility reloads each data setfrom the reorganized copy, and through DBRC, creates a REORG and an IC record

Figure 5. Making a Backup Copy with HISAM Unload



in RECON for each data set. The IC record points to the data set that was outputfrom the Unload utility and input to the Reload utility. After a database has beenreorganized, a DBDS can be authorized only if an image copy of that data set hasbeen created.

Updates of the database between unload and reload operations must be prevented.Updates of the database made after an unload operation but before a reloadoperation are wiped-out by the reload operation. In addition, the change recordsthat are logged reflect the old organization, so that a subsequent recovery usingthose log records damages the database.

You can prevent access to a shared database during reorganization by using one ofthe following methods:

v From an online IMS subsystem, issue a global /DBRECOVERY command for thedatabase that is to be reorganized. This prevents any subsequent authorizationsexcept for reorganization and recovery. Ensure that recovery utilities do not runduring the reorganization.

v Manually update RECON by specifying the NOAUTH parameter of the CHANGE.DBcommand. This prevents any subsequent authorizations except for thereorganization and recovery utilities. Ensure that recovery utilities do not runduring the reorganization. After the reorganization process is complete, manuallyupdate RECON by specifying the AUTH parameter of the CHANGE.DB commandfor the database that was just reorganized.

Nonstandard Image Copy Data SetsYou can create backup copies of DBDSs by using some means other than theDatabase Image Copy utility. For example, you could make a copy of the volume onwhich a DBDS resides. DBRC does not record the existence of these nonstandardimage copy data sets in RECON automatically; use a NOTIFY.UIC command toinform RECON of these data sets. If this information is not recorded in RECON,DBRC might misinterpret subsequent information about changes to the DBDS. Youcannot issue the NOTIFY.UIC command for a DBDS that is defined with the REUSEoption.

Before recovering a DBDS or DEDB area with a nonstandard image copy data set,perform the following steps:

1. Close the database using /DBR (without NOFEOV). Load the data set from thenonstandard image copy (UIC) and record the event in RECON (by issuingNOTIFY.RECOV with RCVTIME specified).

2. Apply the change records from the logs that were produced since the UIC (byrunning DBRC with USEDBDS or USEAREA for the GENJCL.RECOV command orDFSDUMP DD DUMMY statement in the DBRC JCL).

Since an image copy is not used for Step 2, DBRC does not allow DBRC toprocess any log that contains changes outside the recovery range. The recoveryrange is defined by the timestamp recovery record RECOV TO (image copy time)and RUNTIME values.

Frequency and RetentionConsider the following questions when making backup copies of databases:

v How frequently should I make new copies?

v How long should I keep old (back-level) copies?



There are no precise answers to these questions. Generally, the more frequentlyyou copy, the less time recovery takes. The further back in time your old copies go,the further back in time you can recover. (Remember that program logic errors aresometimes not discovered for weeks.) Conversely, making each new copy requireswork, and each old copy that you save uses additional resources.

The only firm guidelines are these:

v If a database is composed of several data sets, be sure to copy all of the datasets at the same time.

v If you reorganize a database, immediately make a new backup copy of it. (This isnot necessary for online DEDBs or HISAM reorganizations.)

v If you create a new database, immediately make a backup copy of it.

v If you perform a timestamp recovery, make a backup copy for use in subsequentrecoveries.

Log Record Change AccumulationAs IMS runs, the number of stored SLDSs or RLDSs grows. You can use thesestored volumes to recover a lost or damaged database, but to use them in their rawform would be inefficient because:

v Each SLDS or RLDS contains a record of activities of the entire system and allthe data sets within all the databases. Yet when you are recovering a database,you are doing so for a single data set only. Thus, much of what is on the SLDSor RLDS does not apply.

v The SLDS or RLDS chronologically notes each change to any single record. If arecord were changed 100 times since the last backup copy of the data set, theSLDS or RLDS would include 100 such notations. Yet, in recovery, you are onlyinterested in the value the data had at the moment the data set was lost. Theprevious 99 changes are irrelevant.

DBRC requires that change records be input in chronological order, but if adatabase is shared, the change records might be distributed among different logdata sets in a way that makes their input to the utility impossible. A DBRCGENJCL.RECOV command or DBRC utility execution fails if this log data has not beenproperly merged. Such a failure is accompanied by a message informing you that aChange Accumulation should be run.

Condensing the Accumulated SLDS or RLDS (Change Accumulation)The Database Change Accumulation utility offers you a way of sorting through youraccumulated log data sets in advance, merging and condensing them. This utility:

v Merges updates from different subsystems

v Picks out only those log records relating to recovery of databases

v Sorts these records by data set within a database

v Saves only the most recent state of each changed part of each data set.

Figure 6 on page 34 illustrates how change accumulation merges data fromdivergent data streams.



Figure 6. What Change Accumulation Does with Data from Divergent Data Streams

Log Record Change Accumulation


When Is Change Accumulation Required?Running the Database Change Accumulation utility is not required if, during the timeperiod in question, only one system updated the database; using it periodicallyspeeds any database recovery that becomes necessary. Alternately, you can runthe Database Change Accumulation utility only when the need for recovery arises(just before running DBRC).

Figure 7 illustrates why change accumulation would not be required whennon-concurrent data set update information exists in various logs. The databasechanges are received in the correct order if the logs are input serially to DBRC.

Figure 8 on page 36 illustrates why change accumulation can be required whenconcurrent data set update information exists in various logs. The logs cannot beinput to DBRC in a way that the change records are seen in the correct order.

Figure 7. Non-Concurrent Data Set Update Information in Logs: Change Accumulation NotRequired



Related Reading: See the IMS Version 7 Utilities Reference: Database andTransaction Manager for detailed instructions on running the Database ChangeAccumulation utility.

Input to the Database Change Accumulation UtilityIn addition to stored SLDSs and RLDSs, you can use a previous changeaccumulation data set and other IMS log volumes as input. The utility writes theaccumulated changes in a new change accumulation data set.

You can specify all log volumes or a subset of log volumes as input to the DatabaseChange Accumulation utility. When you specify a subset of log volumes, DBRCdetermines whether the subset is complete for each DBDS or area. A subset of logvolumes is complete for a DBDS or area when all of the following conditions aretrue:

v The first volume in the subset is the earliest volume, that could possibly havechanges to the DBDS, that were not included in the last change accumulation orin the last image copy.

v The remaining volumes are in sequence.

v In a data sharing environment, logs from all updating subsystems containingchanges and any open data streams for a DBDS are included.

The DBRC LIST.CAGRP command indicates whether the log subset for each DBDSof the change accumulation group is complete.

Figure 8. Concurrent or Overlapping Data Set Update Information in Logs: ChangeAccumulation Required



You can use the change accumulation data set as input to a later run of theDatabase Change Accumulation utility whether your subset of log volumes iscomplete or incomplete; however, you can use a change accumulation data set asinput to DBRC only if it represents a complete log subset.

Recommendation: If DBRC is being used, it is recommended that the changeaccumulation process is performed using the GENJCL.CA command. This commandcreates the correct JCL and includes all unprocessed log data sets. If you use yourown JCL instead, verify the specifications for change accumulation beforeexecution.

An image copy of the specified database data set is needed and must be identifiedto RECON in order to create a valid starting point for change accumulation records.

All changes since the last valid image copy are collected by the utility. If atimestamp recovery has occurred since the last image copy, the changeaccumulation that is created is invalid for use in future recoveries. No errormessages are generated by GENJCL.CA or by the execution of the utility.

You can run the Change Accumulation utility with a valid log subset at any timeduring change accumulation to reduce data to a minimum.

Related Reading:

v Sample operating procedure 162 in IMS Version 7 Sample Operating Proceduresdescribes the task of running the Database Change Accumulation utility.

v See the IMS Version 7 Operations Guide for more information on the changeaccumulation process in general.

Change Accumulation GroupsA CA group can contain from one to 2000 members, which must be registeredDBDSs or areas. Use INIT.CAGRP to create your CA group. To modify your CAgroup, use CHANGE.CAGRP. A DBDS or area can belong to only one CA group.

DBRC supports the Change Accumulation utility only by CA group. Likewise,GENJCL.CA generates JCL only for a CA group. The DBRC verification exit routineverifies for a whole CA group.

You can run the CA utility for DBDSs that do not belong to a CA group even withDBRC=YES in effect. However, DBRC does not verify the input to the utility norrecord its output.

Defining Change Accumulation Data Sets for Future UseYou can use the REUSE keyword on the INIT.CAGRP command to inform DBRC thatyou want to define a ″pool″ of data sets to receive the output from the ChangeAccumulation utility. Define the data sets using the INIT.CA command. The numberof change accumulation data sets that you can define, can equal up to the value ofthe INIT.CAGRP command GRPMAX parameter that defined the group.

If you define a CA group with the REUSE parameter and also use a GENJCL.CAcommand to generate the job for the Database Change Accumulation utility, reusecan occur. When all these available change accumulation data sets for this CAgroup have been used and the maximum number of change accumulation data setshas been reached, the next run of the Database Change Accumulation utility for thisgroup reuses the change accumulation data set containing the oldest change



records. To reuse a change accumulation data set means that its data set name,volumes, and physical space are used as if they were for an empty changeaccumulation data set.

If you define the CA group with NOREUSE:

v You must specify the output data set name for the utility either in the skeletal JCLmember used for the GENJCL.CA command or in the JCL that you produce.

v When you run the CA utility and the number of data sets specified by GRPMAXhas been reached, DBRC deletes the RECON record of the changeaccumulation data set that contains the oldest change records. The data set itselfis not scratched. The data set must be manually scratched or monitored if youwant to keep it, because DBRC no longer recognizes its existence.

Related Reading: See “Database Change Accumulation Utility (CAJCL)” onpage 333 and “Database Change Accumulation Utility JCL (CAJCL)” on page 346for details on the Change Accumulation JCL specifications.

RecoveryThis section describes various aspects of database recovery, including methods ofrecovering databases with DBRC.

The Database Recovery ProcessRecovery of a database data set by the Online Recovery Service (ORS) or by theDatabase Recovery utility (DFSURDB0) consists of the following:

1. Loading (usually) the most recent image copy.

If the image copy is a UIC, you must perform this step yourself. ORS and therecovery utility do not load user image copies.

2. Applying all changes logged since the image copy was taken.

The changes can be recorded in log data sets, in change accumulation data sets,or in a combination of the two.

If the image copy was made while the database was not being accessed forupdate, only changes that were logged after the run time of the copy are required.

If the database was accessed for update at the time the copy was made, the imagecopy is said to be ″fuzzy″; that is, changes already made to the database by activeapplications might be missing from the copy because they had not yet beenphysically written to the data set. They had, however, been written to the log. In thiscase, to ensure that all changes are applied it is necessary to go back to someearlier point in the logs, how far depends on the type of database and which imagecopy utility was used.

Note that the input to the Change Accumulation utility, when the most recent imagecopy is ″fuzzy″, is subject to the same conditions. The point-in-time selected to startthe Change Accumulation utility is called the ″purge time.″

You can omit all logged changes after a certain time from the input by performing a″timestamp recovery.″ A timestamp recovery is equivalent to backing out the omittedchanges from the database. However, if you want to omit changes, it is not alwayspossible to do so without DBRC.



How DBRC Helps in RecoveryDBRC will use ORS and the recovery utility to help in recovery. For ORS, DBRCselects the recovery input (IC, CA, and logs) as part of the /RECOVERY STARTcommand processing but not for GENJCL. However, for the recovery utility, DBRCwill generate recovery JCL and validate utility JCL:

Generating Recovery JCLYou can use the GENJCL.RECOV command to generate the JCL that is necessary torecover a registered database data set. Using information recorded in RECON,DBRC selects the image copy data set to use for step 1, and selects the CA andlog data sets that are to be input to step 2. If Change Accumulation input is requiredbecause of data sharing, but it is not present or usable, DBRC informs you of thatfact and the command fails.

You can request a timestamp recovery, and DBRC selects the correct logs and, atexecution time, communicate to the utility where to stop processing the input tocorrectly perform your request.

Validating Utility JCLWhen the recovery utility runs against a registered database data set, the utilitypresents its input to DBRC for validation. Whether the recovery JCL was created byyou or by DBRC, DBRC verifies that the input for both step 1 and step 2 are correctaccording to the current RECON information. (It is possible, even if you created theJCL with the GENJCL command, that intervening events could invalidate it before itruns.)

Recording the ResultUpon successful conclusion of the recovery, DBRC records it in RECON, includingthe range of omitted changes if you did a timestamp recovery. If ORS timestamprecovery is used with the point in time recovery (PITR) option, you must make animmediate image copy to ensure a valid starting point for subsequent recoveries.DBRC then prevents the changes from being reapplied on any subsequentrecovery.

Planning Recovery ProceduresRecovery in a data sharing environment is similar to standard IMS recovery. Itinvolves you in these primary tasks:

v Setting up the mechanisms of recovery (logging, taking checkpoints, keepingrecords)

v Setting up the operational procedures for situations that require recovery

Setting Up Recovery MechanismsThe logging and checkpoint mechanisms of online IMS subsystems in anon-sharing environment are also active in a data sharing environment. Theseinclude:

v System log data sets and the use of the WADS and restart data sets

v Program, system, and message-queue checkpoints

v Making image copies of databases

The primary difference between non-sharing and data sharing environments is intheir degree of reliance on DBRC. DBRC helps control the data sharingenvironment; it does not merely keep records.

Recovery


Database reconstruction (forward recovery), program-level (dynamic) backout,database backout, and restart (with embedded recovery) in a data sharingenvironment, however, are different in a nonsharing environment.

Related Reading: See the IMS Version 7 Operations Guide for detailedinformation on recovery procedures in sharing and nonsharing environments.

Recovery FacilitiesThe following recovery facilities behave differently in data sharing and nonsharingenvironments:

v Dynamic backout

v Batch backout

v Forward recovery

Dynamic BackoutAn online IMS subsystem in a data sharing environment dynamically backs out theuncommitted database changes of an application program and discards itsuncommitted output messages under either of these conditions:

v The program fails.

v The program requests backout with a rollback call.

The same is true in a nonsharing environment. In a data sharing environment,however, IRLM locks and RECON status indicators ensure integrity by protectinguncommitted changes from sharing subsystems. Operation of the system and otherprograms continues uninterrupted.

Related Reading: See the IMS Version 7 Operations Guide for detailedinformation about dynamic backout.

Batch SupportDBRC improves database integrity by interfacing with IMS restart dynamic backout,and the Batch Backout utility to control access to databases in need of backout.DBRC creates a backout record (BKOUT) to track each unit-of-recovery (UOR) foreach database in need of backout. DBRC verifies logs that are input to the batchbackout utility.

Backout records are created for online subsystems. Backout records are notcreated for DL/I batch subsystems unless dynamic backout was being used and itfailed.

Prior to executing an emergency restart with the COLDSYS parameter (/ERESTARTCOLDSYS), run batch backout with either the COLDSTART or ACTIVE parameter.This creates a backout record (BKOUT) for all in-flight and indoubt UORs ascandidates for backout. The next IMS restart promotes candidate UORs tobackout-needed status. Backout-needed flags are set in database records inRECON.

When dynamic backout fails, a backout record is created with a UOR indicatingdynamic backout failure and the database record in RECON is flagged as needingbackout.

When the databases are backed out successfully, the flags in database records inRECON are reset appropriately and the backout records are updated. Whenbackouts for all of the UORs have been completed, the backout record is deletedfrom RECON.

Recovery


For DBCTL, if you choose not to back out an unresolved indoubt UOR, use theDELETE.BKOUT or CHANGE.BKOUT command to remove it from the RECON backoutrecord.

DBRC commands are also available to update backout records if needed. The needto make manual changes to the backout record should be minimal.

Recommendation: Use the DELETE.BKOUT or CHANGE.BKOUT commands withextreme caution.

DBRC provides batch backout input log verification. Log volumes input to the batchbackout utility are checked to ensure they are in the correct sequence, all logs areprovided, and properly closed. When ACTIVE or COLDSTART options are includedin the utility SYSIN statement, then an additional check is done to ensure allvolumes related to restart are included. For DL/I batch logs, a check is alsoperformed to ensure that the correct volumes are from the last batch execution.

Attention: If BYPASS LOGVER is included in the SYSIN statement of the batchbackout utility, then input log verification and notification of UORs is not done.Existing UORs are updated on successful completion of backouts.

Related Reading: See IMS Version 7 Operations Guide and IMS Version 7Utilities Reference: Database and Transaction Manager for more information onUOR and backout.

Limitations of DBRC Backout SupportAlthough this support protects databases from damage caused by the mostcommon errors in using backout, some possible sources of damage to databasesremain.

v If an IMS subsystem abends and an ERE COLDSYS is done before the in-flightand indoubt UORs have been identified to DBRC (by a Batch Backout run), thedatabases associated with those in-flights and indoubts are not protected fromerroneous updates until the first Batch Backout run using the COLDSTARTstatement (or the ACTIVE statement).

v Including logs from multiple runs of a batch job in the same log data set (byspecifying DISP=MOD) makes log verification unreliable.

v DBRC commands are provided for the modification of the RECON. Carelessnessin using these commands could lead to errors which would allow backouts thatshould not be done or allow other subsystems access to databases that are inneed of back out.

v The Batch Backout control statement BYPASS LOGVER is provided to allowbackouts to be done when RECON information indicates that the input log isinvalid or the backouts are not needed. Careless use of this control statementcan cause backouts to be performed that should not be.

v Unregistered databases are not protected from being used while backout isneeded.

v Backing out a normally terminated job (that did not use IRLM) after a timestamprecovery was performed (to recover the database to a point in time prior to thislog) makes log verification unreliable. Since the log being backed out is the lastlog for this SSID, it passes DBRC verification.

Forward RecoveryThe process of recovering a database in a data sharing environment has certainsimilarities to recovering a database in a nonsharing environment. In bothenvironments, use DBRC with either ORS or the Database Recovery utility

Recovery


(DFSURDB0) and provide it the most recent image copy of the lost database, andall pertinent system log data sets used since that copy was made.

If you are using DFSURDB0, block-level data sharing, however, might require theadditional step of Change Accumulation, if you are not using ORS for forwardrecovery.

Related Reading: See the IMS Version 7 Operations Guide for further discussionof forward recovery.

Recovery without DBRCIf you perform any recovery-related actions offline when DBRC is not running, suchas making database image copies, problems could arise because DBRC would notbe notified of the changes in status. Therefore, DBRC must be specifically informedof such changes. DBRC offers you several commands for this purpose.

Related Reading: See the IMS Version 7 Operations Guide for detailedinformation about recovery without DBRC and its related commands.

Because restart is required, the Utility Control Facility (UCF) might have to be usedwithout DBRC being active. If you use UCF for any recovery-related work, DBRCmust be informed of status changes afterward.

Restart after IMS FailureRestart an IMS subsystem in a data sharing environment in the same way as in anonsharing environment:

v If you can shut down the subsystem normally (a checkpoint shutdown/CHECKPOINT PURGE, /CHECKPOINT DUMPQ, or /CHECKPOINT FREEZE), you can restartit normally, using the /NRESTART command.

v If the subsystem failed, an emergency restart must be done using the /ERESTARTcommand.

In a data sharing environment, however, consider that if the associated IRLM alsostops or fails, you must first start IRLM before you start IMS in a block-levelenvironment.

Related Reading: See the IMS Version 7 Operations Guide for more informationon restart after IMS failure.

Restart after DBRC FailureBecause DBRC runs under the control of IMS, IMS knows whether its DBRC fails. Ifa DBRC failure occurs, IMS terminates abnormally, attempts to flush its buffers, andcloses the system log. After correcting the DBRC problem, you can restart IMSusing the /ERESTART command.

Recovery Involving IRLM ConfigurationsDBRC records IRLM status information in the subsystem record.

Related Reading: See “Appendix C. Sample Listings of RECONs” on page 367and IMS Version 7 Operations Guide for information on the IRLM status informationthat DBRC records in the subsystem record.

Recovery


Batch BackoutPrior to executing an emergency restart with the COLDSYS parameter (/ERESTARTCOLDSYS), run batch backout with either the COLDSTART or ACTIVE parameter.Provide DBRC with the names of the logs to protect registered databases (thatneed to be backed-out) from being accessed until their backouts are complete.

For DB level control, if you choose not to back out an unresolved in-doubt UOR,use the DELETE.BKOUT command to remove it from the RECON backout record.

Recommendation: Use the DELETE.BKOUT command with extreme caution. Itdeletes all backout information for a subsystem from the RECONs.

Archiving Log RecordsRelated Reading:

v See IMS Version 7 Operations Guide for more information on automatic, manualand custom archiving of log records.

v See IMS Version 7 Utilities Reference: System for more information aboutspecifying entry points and running the Log Archive utility.

v Refer to IMS Version 7 Customization Guide for more information about writingexit routines.

Recovery


Recovery


Chapter 3. Initializing and Maintaining the RECON

In This Chapter:

v “Planning Considerations for the RECON” on page 46

v “Initial RECON Access” on page 54

v “Records in the RECON” on page 55

v “Maintaining the RECONs” on page 64

DBRC records recovery-related information in a pair of key-sequenced data sets(KSDSs) called RECON (recovery control). DBRC uses dual recovery control(RECON) data sets to increase availability and recoverability. They contain identicalinformation. The data sets are identified by the DD names RECON1 and RECON2.

If you define only two RECONs and an error occurs on one of them duringoperation, the current jobs continue using the remaining one. New jobs start only ifyour RECON setting allows a start with only one active RECON. If you want tocontinue operations in dual mode, you can define a third RECON (RECON3).DBRC does not use this spare data set unless an error occurs on one of the twoactive RECONs. Then, DBRC copies the good RECON to the spare data set(RECON3), which then becomes active (thus maintaining RECON dual-modeoperation).

Figure 9 shows the normal three RECON operating configuration.

The RECON data sets are critical resources for both DBRC and IMS. If bothRECON data sets are lost, DBRC abnormally terminates rather than compromisingdatabase integrity. IMS cannot continue processing transactions without a RECONdata set, so it also abnormally terminates.

Figure 9. RECON Three-Data-Set Scheme


Planning Considerations for the RECONEach RECON is a VSAM KSDS with a 32-byte key.

Define your RECONs specifying VSAM SHAREOPTION(3,3). Ideally, each data setshould be on a different device, channel, control unit, and catalog. Data sets shouldalso be of different sizes (see “Avoiding RECON Space Problems” on page 50).

When defining the RECONs using VSAM Access Method Services (AMS), you mustuse the same index control interval (CI) size and data CI size for all the RECONs.Unequal index or data CI sizes cause DBRC to use virtual storage inefficiently.

Recommendations:

v Ensure that the data CI size specified exceeds the specified index CI size by atleast 2048 bytes. Failure to do so can seriously degrade your DBRCperformance.

v Specify the maximum record size for all RECONs when defining the RECONsusing AMS. DBRC initialization fails if the maximum record size of the two activeRECONs do not match.

First-Time UsersAfter allocating the RECONs, use the INIT.RECON command to initialize theRECON. This command is only valid for an empty, uninitialized RECON. If theinitialization job fails, delete and redefine the data sets before rerunning it.

Avoiding RECON Contention ProblemsMaximum RECON availability depends on the following:

v Eliminating deadlock

v Minimizing situations in which more than one RECON becomes simultaneouslyunavailable

For maximum availability, each RECON must:

v Have different space allocations. The spare data set must be at least as large asthe largest RECON.

v Be on different devices.

v Be on different channels.

v Be in different user catalogs.

For additional information on avoiding space problems, see “Avoiding RECONSpace Problems” on page 50.

Recommendation: To eliminate contention and facilitate recoverability it isrecommended that RECONs be the only type of data set on their respectivedevices.

To eliminate deadlocks, the RECONs must:

v Be the only objects cataloged in their respective catalogs.

v Be on the same device as their catalogs. When RECONs are accessed, anenqueue on the RECONs can result, followed by an enqueue on the catalog.When the RECONs and catalog are on the same device, the possibility ofconflicts with another job enqueueing the devices in reverse order is eliminated.

Maintaining the RECON


Avoiding RECON DeadlockTo avoid deadlock situations, give special consideration to the placement ofRECONs that are shared among multiple processors. During a physical open,DBRC reserves RECON1, RECON2, and RECON3. DBRC determines which areavailable and which are Copy1, Copy2, and spare. DBRC then closes anddequeues the spare (if it exists) and any unusable RECONs. So, during the use ofDBRC, two RECONs are reserved most of the time. DBRC always reserves bothRECONs in this order: RECON1 and RECON2. If RECON1 and RECON2 arespecified consistently throughout jobs, DBRC does not encounter deadlock.

However, other jobs that reserve multiple volumes can cause deadlock if any of thevolumes also contain a RECON.

Related Reading: The MVS/ESA System Programming Library: ApplicationDevelopment Guide explains deadlock situations and volume assignments further;refer to it when placing your RECONs.

RECON SerializationAccess to the RECONs must be controlled to avoid deadlock. The following macrosare used to control access to the RECONs: RESERVE, GRS, OBTAIN, and DEQ.DFP Record Management Services are also discussed, and RECON serializationstrategies are presented.

RESERVE: DBRC issues the MVS RESERVE macro to serialize access to eachRECON data set. DBRC keeps the RECONs reserved until it completes itsprocessing; the more RECON records it must examine or change, the longer itholds the RECONs. The RESERVE macro serializes access to a resource (a dataset on a shared DASD volume) by obtaining control of the volume on which theresource resides to prevent jobs on other systems from using any data set on theentire volume. This reserve is done under the major name DSPURI01 and has ascope of SYSTEMS.

Batch jobs will serialize on another resource name first, before issuing a RESERVEfor the RECON data sets. The resource name for batch is DSPURI02 and has ascope of SYSTEM. Each job gets control of the resource, based on the position ofthe task’s request and whether the request was exclusive or share control. Thequeue is not ordered by the priority of tasks. The effect of this serialization of batchjobs is that an IMS online region never has to wait for more than one batch job tocomplete before gaining access to the RECON.

GRS: Global Resource Serialization (GRS) provides a method of converting aRESERVE request into an ENQ request. The ENQ, DEQ, and RESERVE macrosidentify a resource by its symbolic name. The symbolic name has three parts:

v Major name (qname)

v Minor name (rname)

v Scope (which can be STEP, SYSTEM, or SYSTEMS)

For example, on an ENQ or DEQ macro, a resource might have a symbolic nameof APPL01,MASTER,SYSTEM. The major name (qname) is APPL01, the minorname (rname) is MASTER, and the scope is SYSTEM.

When an application uses the ENQ, DEQ, and RESERVE macros to serializeresources, global resource serialization uses resource name lists (RNLs) and thescope on the ENQ, DEQ, or RESERVE macro to determine whether a resource is alocal resource or a global resource. Global resource serialization identifies eachresource by its entire symbolic name. For example, a resource that is specified as


Chapter 3. Initializing and Maintaining the RECON 47

A,B,SYSTEMS is considered a different resource from A,B,SYSTEM or A,B,STEPbecause the scope of each resource is different. To ensure that resources aretreated as you want them to be without changes to your applications, globalresource serialization provides three resource name lists (RNLs):

v SYSTEMS EXCLUSION RNL

The SYSTEMS exclusion RNL contains a list of resources that are requestedwith a scope of SYSTEMS that you want global resource serialization to treat aslocal resources.

v RESERVE CONVERSION RNL

The RESERVE conversion RNL contains a list of resources that are requestedon RESERVE macros for which you want global resource serialization tosuppress the RESERVE.

v SYSTEM INCLUSION RNL

The SYSTEM inclusion RNL contains a list of resources that are requested with ascope of SYSTEM that you want global resource serialization to treat as globalresources.

Related Reading: See the following publications for more information about GRSand the MVS RESERVE, DEQ, and ENQ macros:

v OS/390 MVS Programming: Authorized Assembler Services Reference

v OS/390 MVS Planning: Global Resource Serialization

OBTAIN: DBRC uses a VSAM DADSM (Direct Access Device StorageManagement) OBTAIN request to the FORMAT-4 DSCB (the VTOC) to force an I/Othat insures that DBRC really has the RECON reserved in a multi-systemenvironment. For more information about the OBTAIN DADSM macro, see theMVS/DFP V3R3 System Program Reference Manual.

DEQ: DBRC releases the RECONs by using the MVS DEQ macro.

DFP Record Management Services: DBRC uses VSAM services to retrieve,manipulate, and store the RECON records. These RECON records have a 32 byterecord key.

RECON Serialization Strategies: The following items discuss several serializationimplementations and their effects:

v GRS SYSTEMS EXCLUSION RNL

If you implement GRS SYSTEMS EXCLUSION RNL, then GRS does not doglobal serialization, and the RESERVE is issued. This is the recommended wayto implement IMS with DBRC and it works well provided that the RECON dataset is located on a DASD volume which does not contain other data sets whichare needed by other MVS systems.

To implement this method follow these steps:

1. Add the RECON QNAME to the SYSTEMS EXCLUSION RNL

– RNLDEF RNL (EXCL) TYPE (GENERIC) QNAME (DSPURI01)

2. Carefully consider the placement of the following VSAM QNAMEs:

– SYSZVVDS

– SYSIGGV2

Related Reading: The MVS/ESA Planning: Global Resource SerializationGuide (publication number GC28-1450-01) provides more information aboutVSAM QNAMEs.



The performance (in terms of least CPU time used, least storage used, and leastelapsed time) is best for this option. It does require careful control of the contentsof the DASD volume holding the RECON (ideally a dedicated volume exists forthe RECON).

v RESERVE CONVERSION RNL

If you implement GRS RNL CONVERSION by adding the QNAME for theRECON, DSPURI01, to the conversion list, the hardware reserve is eliminatedand replaced by a GRS enqueue that is propagated to all sharing MVS systems.They all must be in the same GRS ring. This locks out access to the RECONdata set by IMS code that does the enqueue on the RECON. It does not lock outaccess by non-IMS code that does not issue an ENQUEUE for DSPURI01. Thus,there is a potential integrity exposure, but only for non-IMS products that shouldNOT access the RECON in any situation.

Other data sets on the same DASD volume can be used while the RECON is″reserved″; this is the benefit of performing the RNL conversion. GRS RNLconversion uses CPU and storage and can affect system performance.Conversion of a production IMS system is not recommended. It may bereasonable to do for a development IMS system, but the performance analysis isa decision for each specific environment.

Related Reading: There are a number of possible solutions to contention orperformance problems associated with the RECON data sets.

v See the Informational APAR II10915 for information on RECON contention andperformance problems.

v See the Informational APAR II10735 for information on performance and tuningdiagnostics.

Allocating the RECONsFor both online and batch DBRC jobs, you can allocate the RECON1, RECON2,and RECON3 data sets with JCL, or you can let DBRC dynamically allocate them.

When dynamically allocating the RECON, omit the DD statements for RECON1,RECON2, and RECON3.

Use the IMS DFSMDA dynamic allocation macro to establish three dynamicallocation parameter lists in IMS.SDFSRESL. When multiple processors access thesame RECONs, keep the IMS.SDFSRESL information pertaining to dynamicallocation parameters in synchronization on all processors.

Related Reading: See IMS Version 7 Utilities Reference: System for informationabout the DFSMDA macro.

DBRC always allocates RECONs with DISP=SHR.

Although JCL allocation and dynamic allocation are both valid methods forallocating RECONs, JCL allocation should be used only in a controlled test.

Recommendation: Use dynamic allocation for your production system and all othertest or development environments.

The principal advantages of dynamic RECON allocation are:

v All DBRC jobs automatically use the correct and current RECON data sets, andno JCL statements are left to become outdated.



v You can reorganize and restore RECONs, in case of error, without having to shutdown online IMS systems.

Avoiding RECON Space ProblemsAllocate the RECONs with different amounts of space so that if one becomes full,the system can continue using the other RECON while you provide a replacement.

If one RECON becomes full during online operation, IMS deallocates it. DBRCresponds by copying and reorganizing the good RECON to a spare RECON, if oneis available. If no spare RECON is available, the system runs in single RECONmode.

When all active subsystems have deallocated the failing RECON data set, you candelete and redefine it offline using VSAM AMS. If you are in single mode, and aspare RECON is available, the next time DBRC accesses the RECON, itautomatically enters dual RECON mode. You do not have to enter the CHANGE.RECONcommand with the DUAL or REPLACE option.

Creating a RECONThe DEFINE CLUSTER keywords that are recommended when defining a RECONVSAM KSDS are defined below. Information on all the keywords can be found inthe DFSMS/MVS V1R5 Access Method Services for VSAM catalog.

CONTROLINTERVALSIZEThe values used with this keyword affect the total amount of storage used byDBRC for VSAM buffers. DBRC uses the Local Shared Resources (LSR) optionof VSAM to process the RECONs. If the number of index and data bufferscreated by DBRC is allowed to default, the amount of storage used for RECONbuffers is (60·index_ci_size + 120·data_ci_size). This occurs when the indexand data CI sizes are the same for all RECONs. The amount of storage usedby DBRC for buffer space can be adjusted by changing the index or datacontrol interval (CI) size on this keyword.

Recommendations: Initially set your minimum CI size to a minimum of eightKB. The allowable CI size is affected by the value you select for RECORDSIZE.Also, ensure that the smallest data CI size specified exceeds the largest indexCI size specified by at least 2048 bytes. Failure to do so can seriously degradeyour DBRC performance. Alternately, you can change the default number ofindex or data buffers used by DBRC in an online or batch environment.

Related Reading: See IMS Version 7 Customization Guide for further detailsabout using the Buffer Size Specification Facility.

CYLINDERS

FREESPACEThe default values of FREESPACE(0 0) must not be used. While you areentering initial information in the RECON, you must specify a highcontrol-interval percentage (for example, 70%) as free space. Later, you canlower the percentage with an Access Method Services (AMS) ALTER command.

INDEXED

KEYSKEYS(32 0) is required.

NAME

NOERASE

NOREUSE



RECORDSIZEA minimum of RECORDSIZE(4086 524,288) is recommended. This is thedefault value when SPANNED is specified. The largest record size supported bythe AMS REPRO function with sequential output files is 32760.

For IMS subsystems that access many databases and operate for very longperiods between shutdowns, a very large record size might be required. A verylarge record size can help in minimizing unplanned outages that can result fromcertain RECON records becoming too large.

Depending on the configuration of your IMS environment, the number ofdatabases a subsystem might access and the elapsed time between IMSstartup and shutdown, you might want to increase the maximum record sizebeyond 32600.

Restriction: If you increase the maximum record size beyond 32600, youcannot use the DBRC BACKUP.RECON command to copy the RECON to asequential file because of the AMS REPRO function restriction.

Recommendation: Use the BACKUP.RECON command to copy the RECON to aKSDS, and then use the DFSMSdss DUMP command to copy the KSDS to asequential file.

Related Reading: See the IMS Version 7 Release Planning Guide for moreinformation on record size changes.

SHAREOPTIONSSHAREOPTIONS(3 3) must be specified. The first value is required withsingle-host processors. Both values are required with multiple-host processors.

SPANNED

SPEED

UNORDERED

UNIQUEIf ICF catalogs are used, this keyword is not necessary.

VOLUMES

Recommendation: Do not use authorization keywords because frequent operatorprompting results.

Avoid the use of WRITECHECK; it can degrade RECON I/O performance. The useof dual RECONs eliminates the need for WRITECHECK.

Variable Size RECON RecordsThe following table lists the variable length RECON records that have the possibilityof exceeding the RECON maximum record size.

DBRC warns you when any record exceeds a size threshold that you have set sothat you might have time to take corrective action before the maximum size isreached. See “CHANGE.RECON” on page 147.

Table 3. RECON Records of Variable Size

Record Type How exceedingRECORDSIZE canhappen

Result whenRECORDSIZE isexceeded

What to do

Records whose growth is event-driven and open-ended:



Table 3. RECON Records of Variable Size (continued)



What to do

PRILOG The record is filling upwith data set entriesbecause:

v Combination ofRECORDSIZE andImage Copyfrequency is notcorrect for thesubsystem’s loggingvolume.

v Something ispreventing PRILOGcompression.

IMS ABENDs v Stop subsystem,

v Increase RECONRECORDSIZE, -OR-

v Correct whatever ispreventing logcompression.

See “Getting PRILOGCompression to Work”on page 82 for moreinformation aboutcompressing thePRILOG.

DBDS/Area A database was notstopped after an I/Odevice failure so thatendless EEQEs arerecorded.

IMS ABENDs. /EREmight also fail ifbackout generatesmore EEQEs.

To prevent ABEND,/DBR the database;after ABEND increaseRECONRECORDSIZE.

BKOUT This is very unlikely; itwould require a smallRECORDSIZE and anabnormally highnumber of dynamicbackout failures.

Subsystem ABENDs. Increase RECONRECORDSIZE.

Records whose size is determined by the number of objects supported:

CAGRP RECORDSIZE isinsufficient for numberof members (2000members = 32052bytes).

CHANGE.CAGRPcommand fails.

Increase RECONRECORDSIZE.

CA RECORDSIZE isinsufficient for numberof CAGRP members(2000 members =72096 bytes).

CA utility fails. Increase RECONRECORDSIZE.

DBDSGRP RECORDSIZE isinsufficient for numberof members (2000members = 32052bytes).

CHANGE.DBDSGRPcommand fails.


SSYS RECORDSIZE isinsufficient for thenumber of databasesthe subsystem isattempting to access(2000 databases =64072 bytes).

Authorization failure. Increase RECONRECORDSIZE.



Table 3. RECON Records of Variable Size (continued)



What to do

PRIOLD This is very unlikely,since a RECORDSIZEof just 32760 wouldpermit recording 235OLDSs.

Online IMS ABENDs orNOTIFY.LOG commandfails.


Records that cannot exceed RECORDSIZE:

DB/AAuth 16 is the maximumnumber of SSYSs.

LOGALL The SSYS recordwould fill up first.

Record Size Warning Messages: Figure 10 on page 54 illustrates an example ofwhen the various warning messages would appear for the PRILOG record of onlineOLDS data set. For the purposes of this example, a small RECON record size of1000 is used, and the parameter values for the CHANGE.RECON command are:

CHANGE.RECON SIZALERT(4,1,50) LOGALERT(1,1)

Additional considerations to note for this example are:

v The fixed portion of the PRILOG record is 112 bytes.

v Assuming one volume per log data set entry, each data set entry is 160 byteslong. Each additional volume adds 40 bytes.



Security Considerations for RECONAll jobs that access the RECONs must have control-level authority to the RECONs.Control, rather than update-level authority, must be specified, because VSAMissues VERIFY macros. VERIFY uses control interval processing.

Even jobs with read intent for databases using DBRC must have control-levelauthority because even a job with read intent updates information on the RECONheader record.

Initial RECON AccessWhen a job needs to read the RECON, the RECON must be opened. When threeRECONs exist, DBRC determines which two are the active RECONs and which isthe spare data set. Table 4 on page 55 shows how this determination is made.

v RECONA, RECONB, and RECONC represent the RECON1, RECON2, andRECON3 DD statements in no particular sequence.

v Data Set Status indicates the status of the data set during open time.

v Data Set Use indicates how DBRC assigns the data set.

Figure 10. Events Affecting PRILOG Records



Table 4. Determining Which RECONs Are Accessed

Case DD Statement Data Set Status Data Set Use DBRC Selection Criteria

1 RECONARECONBRECONC

Create ModeCreate ModeCreate Mode

Copy1Copy2Spare

Specify INIT.RECON commandSpecify INIT.RECON command


RECONCreate ModeCreate Mode

Copy1Copy2Spare

Current copy of RECONProduced from Copy1


RECONRECONCreate Mode

Copy1Copy2Spare

Current copy of RECONCurrent copy of RECON


RECONRECONCreate Mode

Copy1UnusedCopy2

Current copy of RECONOlder copy than RECONAProduced from Copy1


RECONRECONRECON

Copy1UnusedUnused

Current copy of RECONOlder copy than RECONAOlder copy than RECONA


RECONRECONRECON

Copy1Copy2Unused

Current copy of RECONCurrent copy of RECONOlder copy than RECONA

7 RECONARECONB

RECONCreate Mode

Copy1Copy2

Current copy of RECONProduced from Copy1

8 RECONARECONB

Create ModeCreate Mode

Copy1Copy2

Specify INIT.RECON commandSpecify INIT.RECON command

9 RECONARECONB

RECONRECON

Copy1Copy2

Current copy of RECONCurrent copy of RECON

10 RECONARECONB

RECONRECON

Copy1Unused

Current copy of RECONOlder copy than RECONA

11 RECONA Create Mode None Discontinue processing

12 RECONA RECON Copy1 Current copy of RECON

Case 4 is the situation where two RECONs are available, but one is now out ofdate. DBRC does not use the out-of-date RECON. Instead, it copies the up-to-dateRECON to the spare data set.

Only one RECON is available in cases 5, 10, and 12. If you have specified theSTARTNEW parameter of the INIT.RECON or CHANGE.RECON command, processingcontinues with one RECON. Otherwise, processing ends.

Records in the RECONThe RECON contains many types of records. Some records, such as headerrecords, exist primarily to control RECON processing. Other records exist to definethe various data sets used in the recovery of DBDSs. Still others exist to recordevents related to the use of DBDSs.

Figure 11 on page 56 shows the major relationships of RECON record types.



Related Reading:

See “Appendix C. Sample Listings of RECONs” on page 367 for details of recordcontents.

RECON Header RecordsThe RECON has three record types that contain control information DBRC uses inits processing:

v RECON header

In addition to internal control information that DBRC creates and uses, theRECON header record contains information provided by you in the parameters ofthe INIT.RECON and CHANGE.RECON commands.

v RECON header extension

The RECON header extension record contains RECON configuration and statedata that DBRC uses to process the RECONs.

v RECON Time History Table (THT) Extension

The RECON THT extension contains a history of time-zone changes (such aswhen the system time was changed to and from Daylight Savings Time) duringthe period covered by the RECON. The THT is required for RECON migrationfrom pre-IMS/ESA Version 6 and must be maintained as long as pre-IMS/ESAVersion 6 systems share the RECON.

Log Data Set RecordsThree types of log data sets exist. Each type can have a primary log record,secondary log record, interim-primary log record, and interim-secondary log record.Log data set records for each log data set are:

v Recovery log data set

– PRILOG (primary log record)

– SECLOG (secondary log record)

– IPRI (interim primary log record)

– ISEC (interim secondary log record)

v System log data set

Figure 11. RECON Record Types



– PRISLD (primary system log data set)

– SECSLD (secondary system log data set)

– PRITSLDS (primary RSR tracking site log data set)

– SECTSLDS (secondary RSR tracking site log data set)

– IPRISL (interim primary system log data set)

– ISECSL (interim secondary system log data set)

– IPRITSLD (interim primary RSR tracking site log data set)

– ISECTSLD (interim secondary RSR tracking site log data set)

v Online log data set

– PRIOLDS (primary online log data set)

– SECOLDS (secondary online log data set)

– IPRIOL (interim primary online log data set)

– ISECOL (interim secondary online log data set)

Log records come in sets called ″PRILOG families.″ A PRILOG family consists of aPRILOG and one or more of the following: SECLOG, PRISLD, and SECSLD for agiven time period and IMS subsystem. All records in this set have the same startand end times and normally have matching data set entries. The same LOGALLrecord applies to all members of the set.

DBRC creates the PRILOG and PRISLD records whenever an online IMS opensthe first OLDS, and updates them each time an OLDS is archived. If you use dualarchiving, DBRC creates SECLOG and SECSLD records when the first OLDS isarchived and updates them each time an OLDS is archived.

Related Reading: See “Archiving Log Records” on page 43 for more informationabout DBRC and the archiving of online logs.

Log data sets output from IMS batch jobs are recorded in PRILOG / SECLOGrecords even though, technically, they are SLDSs. These records are createdwhenever the output log is opened and updated when volume switches occur.

In addition, during Log Recovery processing, DBRC creates an IPRISL or IPRIOLrecord for each interim primary-log data set and an interim secondary-log record foreach interim secondary-log data set whenever the Log Recovery utility runs. Aninterim log record is an internal record that is used to reflect intermediateprocessing of the DUP function of the Log Recovery utility.

Related Reading: See IMS Version 7 Operations Guide for more informationabout interim primary and interim secondary-log data sets.

Although not part of normal DBRC operation, you can use the following commandsto create log records (for example, to set up a test environment or for RECONrepair purposes):

v NOTIFY.PRILOG

v NOTIFY.SECLOG

Database Recovery RecordsIn addition to the log data set records, the following types of records containdatabase recovery information:

v Backout Record (BACKOUT)

v Change Accumulation Group Record (CAGRP)



v Change Accumulation Run Record (CA)

v Database Data Set Group Record (DBDSGRP)

v Database Records (DB)

– Database Record (DL/I and Fast Path)

– Fast Path Area Authorization Record

– DBDS (DL/I) / Area Recovery (FP) Record

v Global Service Group Record (GSG)

v Image Copy Record (IMAGE)

v Reorganization Record (REORG)

v Log Allocation Record (LOGALL)

v Database Allocation Record (ALLOC)

v Recovery Record (RECOV)

v Subsystem Record (SSYS)

Backout Record (BACKOUT): A BACKOUT record contains information aboutunits of recovery including time stamp, associated PSB name, recovery token, anddatabase name. The names of nonrecoverable databases are not stored in theBACKOUT record.

Change Accumulation Group Record (CAGRP): A CAGRP record identifies achange accumulation (CA) group. This record includes up to 2000 names of DBDSswhose change records are accumulated during one run of the Database ChangeAccumulation utility. Each DBDS (for which DBRC is controlling recovery) can be amember of only one CA group in order for the Database Change Accumulationutility to accumulate its changes. You specify this in the INIT.CAGRP command thatyou use to create a CAGRP record in the RECON.

The CAGRP record contains the name of a member of a partitioned data set. Thismember contains the skeletal JCL that is to be used to generate the JCL to run theDatabase Change Accumulation utility for this CA group. The CAGRP record alsocontains an indicator that specifies whether change accumulation data sets thatcorrespond to this group can be reused. It also contains an indication of themaximum number of change accumulation data sets that are to be maintained forthe group.

Change Accumulation Run Record (CA): For each CAGRP record, there can beup to 1024 CA records. A CA record contains information about a changeaccumulation data set and can be either available or in use.

An available CA record is created by an INIT.CA command. This CA recordcontains the volume serial numbers and the data set name of a data set that is tobe used for output from a subsequent run of the Database Change Accumulationutility. You can create available CA records only for those CA groups that aredefined with the REUSE parameter.

An in-use change accumulation record is created by a run of the Database ChangeAccumulation utility. It can be a formerly available CA record that was used during arun of the Database Change Accumulation utility, or it can be a new record withinformation obtained from the JCL. The information in an in-use changeaccumulation record includes:

v Data set name

v Volume serial numbers



v Run time of the Change Accumulation utility

v Stop time of the last log volume that the Database Change Accumulation utilityprocessed; or, if the CA processed a subset of logs, the start time of the first logthat should be processed on the next execution

You can use a NOTIFY.CA command to create a CA record.

Data Group Record (DBGRP, DBDSGRP, RECOVGRP): You can use aDBDSGRP record to define the following types of named groups:

v DBDSGRP, a group of DBDSs and DEDB areas

v DBGRP, a group of DL/I DBs and DEDB areas that can be named in theDATAGROUP parameter for the /STA, /STO, and /DBR commands

v RECOVGRP, a group of DL/I DBs and DEDB areas that are logically related forORS purposes

All groups must have unique names. For example, a DBDSGRP cannot have thesame name as a DBGRP.

You use the INIT.DBDSGRP, CHANGE.DBDSGRP, DELETE.DBDSGRP, and LIST.DBDSGRPcommands to manipulate all three data group types.

Recommendation: Although any type of group can be named in the DATAGROUPparameter for the /STA, /STO, and/DBR commands, the use of a DBDSGRP is notrecommended because it is inefficient.

Related Reading: See “Using DBDS Groups” on page 18 for more information onDBDS groups.

Database Records (DB): DBRC treats DL/I, Fast Path, and HALDB (HighAvailability Large Database) database records differently. These types of records,their treatment, and contents are explained in this section.

DL/I Database Records: A DB record identifies a database that is registered andwhose recovery is under the control of DBRC. This record contains informationabout the database and related recovery information including:

v Database name

v Database type

v Share level of database

v List of subsystems using the database

v Extended Error Queue Element (EEQE) counter

v IRLM identification of the first subsystem that authorized the database (if IRLM isused)

A DBDS record identifies a DBDS whose recovery DBRC is to control. This recordcontains information about the DBDS (such as its data set organization) and relatedrecovery information including:

v Name of the CA group to which the DBDS belongs

v Maximum number of image copy data sets to be maintained for this DBDS

v Indication of whether image copy data sets are to be reused

v Period of time that image copy data sets are to be maintained for this DBDS

v Name of the implied skeletal JCL default member

v Extended Error Queue Elements (EEQEs)



v Names of the members of the partitioned data set of skeletal JCL to be used inorder to generate JCL for utilities that are run for this DBDS

To describe DL/I databases and DBDSs, DBRC has a logical structure of records,as shown in Figure 12.

HALDB Records: From a RECON data set perspective, HALDBs consist of aHALDB master (TYPE=HALDB) and one or more HALDB partitions (TYPE=PART).

Figure 13 shows the relationship of the new or changed RECON data set recordsthat represent a HALDB.

HALDB Master (DSPDBHRC)

The RECON data set stores information pertaining to the entire HALDB by using aDB header record. The DB header record includes the following:

v HALDB master name

v TYPE=HALDB

v Partition Selection exit routine name

v Number of partitions in the HALDB

Figure 12. DBRC DL/I Records

Figure 13. RECON Record Structure for a HALDB



v Data Set Group count

v Current Partition ID

v Current change version number

v Global DMB number

v Share Level

v RSR Global Service Group Name and tracking level

v RECOVABL | NONRECOV

The TYPE=HALDB DB record stores information about the HALDB. Applicationsconduct DB activity at the HALDB master level; DBRC conducts the DB activity atthe HALDB partition level. A subsystem authorizes a HALDB partition, not a HALDBmaster.

HALDB Partition

Each partition of the HALDB consists of the following RECON data set records:

v Partition record (DSPPTNRC)

DSPPTNRC contains information that applies to the individual partition. TheHALDB Partition Definition utility displays the partition record information. TheLIST command does not display the partition record.

v Partition DB record (DSPDBHRC)

DSPDBHRC accesses the HALDB at the partition level. Like the TYPE=IMS DBrecord, the DB record for the HALDB partition records all sharing and recoveryinformation. The partition name sets the database name field in this record.TYPE=PART has been defined for this record. The following fields have the samesettings for each partition across the entire HALDB:

– Global DMB number

– Share Level

– RSR Global Service Group Name and tracking level

– RECOVABL | NONRECOV

– HALDB master name

v Partition DBDS records (DSPDSHRC)

Depending on the organization of the HALDB, there can be three types ofDBDSs for each HALDB partition: data, index, and ILDS data sets. Multiple dataDBDSs can exist, but only one of each of the others. Only data DBDSs can berecovered. The other DBDSs are rebuilt using the HALDB Index/ILDS Rebuildutility (DFSPREC0).

Related Reading: See IMS Version 7 Administration Guide: Database Managerfor information about the data set and DDN naming conventions for DBDSrecords.

Fast Path Database Records: To describe DEDBs, AREAs, and AREA Data Sets(ADSs), DBRC has a logical structure of records, as shown in Figure 14 onpage 62.

DBRC uses the DB and DBDS records to describe both DL/I databases andDEDBs; however, DBRC adds an ADS list to the Fast Path DBDS record givinginformation about each ADS. Each DEDB may contain multiple areas, and eacharea may contain up to seven ADSs.

The Fast Path DB record contains information similar to the information in a DL/IDB record, except that it describes a DEDB; and it does not contain a list of



authorized subsystems. For Fast Path, this list is in the DBDS record, which iscomposed of an area authorization record and an area recovery record. The FastPath DB record is displayed in the listing as the DBDS record.

Related Reading: See the sample listing in “Appendix C. Sample Listings ofRECONs” on page 367.

When an Area is registered in RECON, it ensures that:

v The area names in the DEDB are unique

v The ADS ddnames in an area are unique

v No more than seven ADSs are defined for an area

Global Service Group Record (GSG): GSG record defines a global service groupand the service groups that make up the GSG. An RSR service group is made upof two service groups: the active and the tracker.

GSG records are created by the INIT.GSG command and can be deleted by theDELETE.GSG command. The INIT.SG and DELETE.SG commands add and removeservice group definitions to and from the GSG record. The CHANGE.SG commandmodifies information about a service group.

Image Copy Record (IMAGE): An IMAGE record contains information about animage copy data set and can be either available or in-use.

An available IMAGE record is created by an INIT.IC command. It describes datasets that are to be used for output from a subsequent run of an image copy utility.You can create available IMAGE records only for those DBDSs that are defined withthe REUSE parameter.

An in-use IMAGE record is created by an execution of an image copy utility:

v If the DBDS or area is defined with REUSE, it is a formerly available IMAGErecord or a reused in-use record.

v If the DBDS or area is defined with NOREUSE, it is a new record with the dataset description that is obtained from the JCL.

In addition to the data set description, the in-use IMAGE record identifies the typeof copy operation and contains the copy operation’s run time and, depending on thetype of copy, the copy operation’s stop time.

Figure 14. DBRC Fast Path Database Records



If you request that the image copy utility create an image copy data set and aduplicate image copy data set, DBRC records information about both in the sameimage copy record. The first record is designated IC1, and the duplicate isdesignated IC2.

If you create a nonstandard image copy data set (one that the image copy utility didnot create), you must use a NOTIFY.UIC command to record its existence in theRECON.

Related Command: See the NOTIFY.UIC command for more information on theIMAGE COPY record.

Reorganization Record (REORG): DBRC creates a REORG record each timeyou run the HISAM Reorganization Reload utility or HD Reorganization Reloadutility for a registered DBDS. DBRC creates a REORG record in the RECON foreach DBDS that you reorganize.

Related Command: See the NOTIFY.REORG command for more information on theREORG record.

Log Allocation Record (LOGALL): DBRC creates a log allocation (LOGALL)record for each PRILOG record. A LOGALL record identifies the registered DBDSsthat were changed while the corresponding log data set was open.

Database Allocation Record (ALLOC): For Fast Path, DBRC creates an ALLOCrecord when the area is placed in OPEN-for-update status. For DL/I, DBRC createsan ALLOC record when IMS updates a DBDS the first time during a run of IMS orthe first time after you enter a /DBRECOVERY command. This record contains the timestamp of its creation and the time stamp of the opening of the corresponding log.This time stamp identifies the log data sets containing the database change recordsthat are needed for recovery. If the DBDS is subsequently deallocated, DBRC addsthe time stamp of the deallocation to the ALLOC record.

DBRC automatically deletes allocation records if they are older than the oldestimage copy record and if DBRC no longer needs them for database recovery. AsDBRC deletes an ALLOC record, it changes the associated LOGALL record. This ispart of the DBRC Image Copy utility exit routine processing. This automatic deletionof ALLOC records for a DBDS does not occur under either of the followingconditions:

v The ALLOC record has no deallocation time.

A deallocation time is recorded when the database or area has had the /DBRcommand run against it. Otherwise, the ALLOC record uses the log close time asan implicit deallocation time.

v The PRILOG record associated with the ALLOC record is open (it has aSTOPTIME of zero) but is not marked in error.

In cases such as these, you can use the DELETE.ALLOC command to deleteunwanted ALLOC records from RECON. DBRC automatically updates allocationtimestamps during online and concurrent image copy utility exit routine processingto move the allocation timestamps forward in time.

Related Command: See the DELETE.ALLOC and the NOTIFY.ALLOC commands formore information on the ALLOC record.



Recovery Record (RECOV): DBRC creates a RECOV record each time you runthe Database Recovery utility to recover a DBDS. The RECOV record can indicateone of these types of recovery:

v A full recovery of a DBDS where the RECOV record contains the time stamp ofthe recovery.

v A timestamp recovery where the RECOV record contains the time stamp of therun of the Database Recovery utility and the time stamp to which the DBDS wasrecovered.

Related Command: See the NOTIFY.RECOV command for more information on theRECOV record.

Subsystem Records (SSYS): RECON uses the subsystem (SSYS) record todescribe data sharing information.

An SSYS record is created when an IMS subsystem signs on to DBRC. This SSYSrecord contains information about the subsystem and related recovery informationincluding:

v Subsystem name and type (online or batch)

v IRLM identification

v Abnormal-end flag and the recovery-process start flag

v List of authorized databases

v Time stamp that correlates the subsystem entry with the appropriate log records

Related Command: See the NOTIFY.SUBSYS command for more information on theSSYS record.

Maintaining the RECONsYou should perform periodic maintenance on the RECONs to maintain data integrityand an acceptable level of performance. Maintenance of the RECONs falls intothese categories:

v Backing up copies

v Reorganizing the data sets

v Extending the data sets to obtain more space when necessary

v Deleting unnecessary RECON log records

v Compressing the PRILOG record

v Replacing a damaged RECON

v Replacing a discarded RECON

v Recovering the RECON

Backing Up RECONBack up the RECONs frequently. They are a critical resource. Always make backupcopies of RECON after performing any RECON record maintenance, such asregistering databases and adding or deleting change accumulation groups.

Use the BACKUP.RECON command to perform backup. This command issues thenecessary RESERVE commands (reserving the device during backup processing) toensure backup integrity. Then it invokes the AMS REPRO command to copy the dataset. The BACKUP.RECON command copies only the first copy of the RECON. Itsparameters determine whether it makes one or two copies.



Related Reading: See “Chapter 8. BACKUP Command” on page 111 for additionalinformation on the BACKUP.RECON command.

Deleting Unnecessary RECON Log RecordsYou can delete unnecessary RECON records using the following methods:

v Automatic deletion by RECON

v PRILOG compression

v Manual log record deletion

Automatic Deletion of Extraneous Records: Normally you should not need toperform much record maintenance for database-related records.

When RECON is notified of an image copy, it may delete or reuse the oldest in-useIMAGE record, and a later IMAGE record becomes the oldest IMAGE record.RECOV and REORG records with start times earlier than the (now) oldest IMAGErecord, and ALLOC records with DEALLOC times earlier than that, are nowextraneous, and are deleted from RECON. This is the image copy cleanup process.

At the same time that extraneous IMAGE records are deleted from RECON, allactive ALLOC records are updated to the time of the first log volume necessary forrecovery, based on the oldest image copy for the DBDS or area. When the cleanupprocess deletes an extraneous ALLOC record it changes the state of the associatedLOGALL records. Once all the ALLOC records associated with the LOGALL recordhave been deleted (this may take place over many image copies for manydatabases), the PRILOG record associated with the LOGALL record becomesinactive.

Compressing the PRILOG Record: PRILOG record compression is the deletionof all inactive data set entries in the PRILOG record. A data set entry is defined asbeing inactive when it is older than all of the following criteria:

v Log retention period

v Oldest allocation (ALLOC) for any database updated on that log

v Earliest restart checkpoint for the online IMS

PRILOG record compression deletes inactive data set entries up to the oldestALLOC on the log or the first gap in the data set entries. A gap occurs when anOLDS has not yet been archived.

When inactive data set entries are deleted from active PRILOGs, they arecompressed to a single dummy data set entry that has the same start time as thestart time of the log and the same stop time as the stop time of the last inactivedata set entry deleted.

Automatic PRILOG Compression: PRILOG record compression is attemptedautomatically after an OLDS has been archived or after a CICS log EOV call isused. At an RSR (remote site recovery) tracking site, automatic compression isattempted when a tracking log data set is opened by Log Router and recorded inRECON.

If the size of the PRILOG record exceeds a threshold percentage of the maximumRECON defined record size, then the PRILOG record is compressed. Thiscompression includes the deletion of all inactive data set entries in the PRILOGrecord. When applicable, corresponding entries in the SECLOG, PRISLD, andSECSLD records are also deleted.



Automatic PRILOG record compression occurs only if the size of the log exceedsthe threshold value. Two threshold values are used: 50% and 75% of the maximumRECON defined record size. If the log cannot be compressed to the currentthreshold value, the threshold value is increased to the 75% value. Likewise, if thelog can be compressed below the 75% threshold, PRILOG compression isattempted at every OLDS switch.

Manual Process for PRILOG Compression: You can initiate PRILOG recordcompression manually by using the DELETE.LOG INACTIVE command. This commanddeletes inactive data set entries from active PRILOG records and deletes entireinactive PRILOG records, regardless of whether the PRILOG record exceeds thecurrent threshold size.

Deleting Log Records: DBRC does not automatically delete RECON records thatdescribe log data sets (PRILOG and SECLOG records). This design gives youcontrol over which RECON records associated with log data sets are deleted. Youmust periodically delete PRILOG and SECLOG records that are no longer neededfor recovery.

Use the DELETE.LOG INACTIVE command to delete inactive PRILOG and SECLOGrecords.

Deleting log records does not prevent the RECONs from filling up because thespace freed by deletions may not be reused by VSAM. However, if you delete thelog records before backing up or reorganizing RECON, you are able to reclaim thespace during backup or reorganization.

Related Reading:

v See “DELETE.LOG (for OLDS)” on page 177 for more information on LIST.LOG.

v See “LIST.LOG (for a PRILOG Family)” on page 254 for more information onDELETE.LOG.

Reorganizing RECONYou need to reorganize the RECONs periodically. Many of the record keys inRECON include the date and time. DBRC recording of IMS log and databaseactivity can cause CI and CA splits, that can degrade performance. In addition,deleting unnecessary records may not prevent RECON from filling up becauseVSAM does not always reuse the space freed.

You can reorganize a RECON online if you are using dynamic allocation for theRECON. A spare RECON must be available. In this situation, you can issue theCHANGE.RECON command with the REPLACE option. This causes DBRC to copy andreorganize the active RECON specified on the CHANGE command to the spare dataset. VSAM removes all CI and CA splits, and restores the original FREESPACEattributes.

The CHANGE command also deallocates the old RECON (the one that neededreorganization). However, before you can delete and redefine this data set, youmust wait for all other subsystems that are using it to deallocate it. If you redefinethe data set with the same name it originally had, it is available to the online systemfor use as a spare data set. You can repeat this process to reorganize the secondactive RECON. If you use JCL in order to allocate data sets, dynamic deallocationdoes not occur.



If you do not use dynamic allocation or if a spare RECON is not available, you mustwait for the online subsystem and all other subsystems that access RECON todeallocate it before you can reorganize.

Recommendation: Back up RECONs before and after reorganizing, using thefollowing procedure:

1. Copy the RECONs to temporary data sets with different data set names.

2. Verify that the copied data sets are uncorrupted.

3. Delete the original data sets.

4. Redefine the original data sets using the same data set names.

5. Copy the temporary data sets back to these original data sets.

RECON Reorganization ProcedureTo clean up your logs and reorganize your RECONs, following this procedure. Thisprocess assumes that you are running DBRC in dual mode with RECON1 (asCopy1), RECON2 (as Copy2), and a spare.

1. Issue a LIST.LOG OPEN command to identify any open logs. Determine which ofthe identified logs should be open, and which should be closed or deleted.Close any logs that should be closed or deleted.

2. Issue a DELETE.LOG INACTIVE command to delete any inactive or unused logs.You are now ready for the RECON reorganization.

3. Issue a CHANGE.RECON with the REPLACE option for RECON1. DBRC signals thestart of RECON reconfiguration with message DSP0380I, identifies thesubsystems that are ″active″ at reconfiguration with message DSP0388I, andsignals that the process has completed with message DSP0381I.

4. Issue either an /RMLIST DBRC=’RECON STATUS’ or /DISPLAY OLDS command on allof the IMS subsystems that are sharing the RECON. Issuing this command willcause the IMS subsystems to detect that a RECON reconfiguration hasoccurred and to deallocate RECON1. If the CHANGE.RECON REPLACE wasissued as an online command, the IMS subsystem that processed the commandhas already reconfigured and does not need a /RMLIST or /DISPLAY OLDScommand.

5. Run IDCAMS DELETE and DEFINE CLUSTER procedures for RECON1.

6. Repeat steps 3, 4, and 5 for RECON2.

7. Repeat steps 3, 4, and 5 for the spare RECON.

Your log clean up has been performed, and your RECONs have now beenreorganized.

Replacing Damaged RECONsIf an I/O error occurs in the current RECON that is the only one remaining, DBRCstops the job. Any other jobs that are currently using the RECON continue to run ifno other I/O error is encountered.

If an I/O error occurs in a RECON and two RECONs exist, DBRC attempts tolocate a spare data set. If a spare is available, DBRC copies the RECON withoutthe I/O error to the spare RECON. DBRC then establishes the spare as the Copy2RECON.

After the spare RECON replaces the RECON that has the error, redefine thediscarded RECON as quickly as possible. If you immediately replace the RECONwith the I/O error, you are unlikely to experience a subsystem failure due to loss ofall RECONs.



If DBRC cannot locate a spare RECON and you have specified the STARTNEWparameter of the INIT.RECON command, DBRC continues processing with oneRECON. Otherwise, DBRC completes the current job but does not start new jobsuntil you define a spare RECON.

Recovering the RECONIf an I/O error occurs on a RECON and a spare data set is available, DBRC copiesthe good RECON to the spare, and then activates the spare. As soon as othersubsystems that are still using the failed RECON (identified in message DSP0388I)have completed their processing, you can delete and redefine the RECON with theerror so that it can be used as a spare. If, however, you want to analyze theRECON error, you should allocate new space for the RECON, rather than deletingand redefining it.

If a spare RECON is not available, all currently executing jobs continue processingusing the RECON in single mode. If you specified the STARTNEW parameter in theINIT.RECON or CHANGE.RECON command, DBRC allows new jobs to start with onlyone RECON. This is not recommended as it jeopardizes the integrity of the system.

If one of the data sets in the set of RECONs becomes unusable by DBRC, youneed to deallocate the RECON that is unusable and allocate a new spare.

In an RSR environment, the isolated log sender (ILS) starts its own copy of DBRC.You might need to stop ILS to terminate the DBRC in the transport manageraddress space. This causes the ILS’s DBRC to deallocate the RECONs so you canreplace the unusable RECON. Issue STOP ILS(gsg) for each started ILS instance.Then issue START ILS(gsg) to bring up ILS and DBRC again.

What to Do If Both RECONs Are Unusable:

It is unlikely that both RECONs would be unusable; however, if both RECONs everbecome unusable, follow this procedure:

1. Stop all jobs that require access to the RECON.

2. Use the AMS REPRO command to back the RECONs up if you can access bothof them. This step is optional. You should do it, though, so that regardless ofwhat happens, you are no worse off than you were at the start of thisprocedure.

3. Use the AMS utility to delete and redefine your RECONs.

4. Use the AMS REPRO command to restore one of the RECONs.

5. Use the AMS REPRO command to restore the other RECON from the first.

6. Use the LIST.RECON command to list one of the RECONs. Evaluate the list anddetermine which DBDSs have been updated since you made the backup in step2. If you cannot determine which DBDSs have been updated, assume that allhave been updated.

7. Use the CHANGE.IC command with the INVALID parameter to mark all imagecopy records that are in error for all applicable DBDSs in step 6.

8. Make an image copy of all applicable DBDSs in step 6.

9. Use the BACKUP.RECON command to make a backup copy of the RECONs.

The RECONs are now restored and resynchronized with the databases.

If you do not control an excessive number of databases, it may be easier to followthis procedure:

1. Stop all jobs that require access to the RECON.



2. Define new RECONs.

3. Initialize these RECONs.

4. Register the environment (always keep a backup copy of the most recentlyinitialized, but not-yet-used, RECON available).

5. Take image copies of all databases.

Finally, before you proceed with your regular operations, clean up the new RECONby, for example, closing any open, out-of-date OLDSs with the NOTIFY.PRILOGcommand.

Replacing a Discarded RECONDBRC detects that a RECON is discarded only when some activity occurs thatcauses DBRC to access the RECONs. You can have multiple instances of DBRCwhenever you have multiple IMS subsystems, online or batch. You cannot deleteand redefine a discarded RECON until all instances of DBRC detect that a changehas occurred and they deallocate the discarded data set. DBRC lists thesubsystems that are ″active″ at reconfiguration in message DSP0388I. Thismessage enables you to identify the subsystems that might need your help indetecting the status change of the RECONs.

To redefine a RECON after an I/O error has occurred, or in conjunction with theCHANGE.RECON REPLACE command, follow this procedure:

1. Allow all batch jobs using DBRC to finish.

2. Issue LIST.RECON STATUS in all online subsystems. This causes the onlinesubsystems to obtain the same Copy1 and Copy2 RECONs and to deallocatethe discarded RECON.

3. Use the AMS DELETE command to delete the discarded RECON.

4. Use the AMS DEFINE command to recreate the RECON as an empty VSAMKSDS data set. Use the same procedure that you used originally to create theRECON. See “Creating a RECON” on page 50.





Chapter 4. RECON Upgrade Utility (DSPURU00)

In This Chapter:

v “Before You Start”

v “Upgrade Procedure”

v “JCL Requirements” on page 73

v “Upgrade Utility Return Codes and Message Information” on page 73

What Is the RECON Upgrade Utility?The RECON Upgrade utility converts a RECON from IMS/ESA Year 2000 LocalDL/I or Version 5 to the format required for Version 7.

To convert a RECON from IMS/ESA Version 6 to the format required for Version 7,use the CHANGE.RECON UPGRADE command.

Related Reading: See section “CHANGE.RECON” on page 147 and the for moreinformation about Version 6 to Version 7 RECON conversion.

Before You StartThe steps listed below must be performed while no other subsystems, batch jobs,or utility jobs are accessing the RECON. All such jobs must be completed orterminated before the upgrade process is initiated.

Requirement: In order for pre-Version 7 subsystems and jobs to access theupgraded RECON, the coexistence SPE must be applied.

Related Reading: Refer to the chapters on migration and coexistence in theIMSVersion 7 Release Planning Guide for more information on the coexistence SPE.

The RECON Upgrade utility does not upgrade a RECON if any of the followingconditions exist:

v The RECOVCTL option is in effect. This option must be changed to SHARECTLbefore the RECON can be upgraded.

v Any local subsystem record exists in the RECON. In this case, the utilityassumes that the RECON is in use and terminates with a message. (At atracking site, the RECON might contain SSYS records representing activesubsystems at another site; it can still be upgraded.)

v A multiple-update operation failed leaving the RECON in a non-updatedcondition. The condition must be corrected before the RECON Upgrade utilitycan be run again. Issuing a LIST.RECON command normally corrects it.

Attention: The operation being attempted at the time of failure might not havecompleted. It is necessary to examine the LIST.RECON output to determine if thecommand must be repeated.

Upgrade ProcedureFollow this procedure to convert a RECON to Version 7 format:

1. Quiesce all current jobs and subsystems accessing the RECON.


2. Use your current release of IMS to issue a LIST.SSYS command. If any SSYSrecords are listed, determine why they exist and take the appropriate action toremove them before proceeding.

3. Make a backup copy of the RECON. Using your current release of IMS, issuethe BACKUP.RECON BOTH command, ensuring that the data set is KSDS format.This copy is input to the Upgrade utility and can be used to restore the originalRECON in case of a failure in the following steps.

Attention: If you have old PRILOG/SECLOG records in RECON, your upgrademay fail with a DSP03431 time conversion failure message. You can delete oldPRILOG/SECLOG records prior to doing the upgrade.

4. Install the new version of IMS.

5. Delete and redefine the RECON1, RECON2, and RECON3 data sets as emptydata sets, each with a 32-byte key, using AMS.

6. Issue the following DBRC command to initialize the RECONs (defined in thepreceding step) and create the Time History Table (THT).

Attention: The THT is required for RECON migration and must be maintainedas long as pre-IMS Version 6 systems share the RECON.

The INIT.RECON command requires the two empty RECONs to run successfully.INIT.RECON UPGRADE

The UPGRADE parameter allows the new RECON to be used only by theRECON Upgrade utility until the upgrade has successfully completed.

Related Reading: See the Migrating DBRC section in the IMS Version 7Release Planning Guide for more information on THT migrationrecommendations.

7. Run the RECON Upgrade utility to convert the RECON. If the utility runssuccessfully, continue to the next step. If the utility fails, see the return code.

Code Meaning

8 The upgrade process could not be started; the new RECON has not yetbeen changed.

v Correct the problem.

v Repeat this step.

12 The upgrade process completed but one or more records hadtimestamp fields containing invalid data. To identify the invalid data seethe text of messages DSP0343I and DSP0350I.

v Determine the necessary corrective action and whether to use thenew RECON or correct the old one. If you choose to correct the oldRECON, do so, then repeat this process from 5.

16 The new RECON has been partially written.

v Correct the problem.

v Repeat the process beginning at Step 5.

Attention: RECON records have increased in length. Consequently, theRECON Upgrade utility might fail with a “RECON RECORD TOO LONG”message. If so, return to Step 5, specifying a larger RECORDSIZE value forRECON1.

Related Reading: See section “Creating a RECON” on page 50 for moreinformation on RECORDSIZE recommendations.

RECON Upgrade


8. Delete and redefine RECON2 and RECON3 data sets as empty data sets, eachwith a 32-byte key, using AMS. The next time DBRC accesses the upgradedRECON1 data set, DBRC copies its contents to one of these empty data sets,identifying the new copy as COPY2. The other defined data set is available as aspare. A batch job that issues the LIST.RECON STATUS command can be used toperform the copy operation.

Input and OutputFigure 15 shows input to and output from the RECON Upgrade utility.

JCL RequirementsThe RECON Upgrade utility runs as a standard MVS job. A job statement, whichyou define, an EXEC statement, and DD statements are required:

EXECSpecifies the utility DSPURU00 and a region size of at least 4096 KB.

The following DD statements are used to define inputs and outputs that arerequired:

SYSPRINT DDSpecifies a sequential message data set. The data set can reside on a tape,DASD volume, or printer, or it can be routed through the output stream.

BACKUP1 DDSpecifies the copy of the old RECON created at Step 3 on page 72.

RECON1 DDSpecifies the redefined RECON (from Step 5 on page 72) which is to beupdated. Neither a RECON2 nor RECON3 DD statement can be specified.

Upgrade Utility Return Codes and Message InformationThe RECON Upgrade utility issues the following return codes:

Code Meaning

0 The operation completed successfully. The RECON is upgraded.

8 The operation was not performed. Possible reasons:

Figure 15. RECON Upgrade Utility Input and Output

RECON Upgrade

Chapter 4. RECON Upgrade Utility (DSPURU00) 73

v The input BACKUP1 data set could not be upgraded, so the output dataset has not been changed. Refer to the message log that was written tothe SYSPRINT data set for information on the cause of the error.

v The output RECON1 data set was not suitable for upgrade. The data setmay have been left in an unacceptable state following a previousupgrade attempt. Refer to the message log that was written to theSYSPRINT data set for information on the cause of the error.

12 The upgrade process completed, but one or more records had timestampfields containing invalid data that is identified by messages DSP0343I andDSP0350I.

16 The RECON1 data set was left in a partially upgraded state; an erroroccurred while upgrading it. Refer to the message log that was written tothe SYSPRINT data set for information on the cause of the error.

Related Reading: See the IMS Version 7 Messages and Codes, Volume 1 formore information on RECON Upgrade utility messages.

Example of RECON Upgrade Utility JCL

The RECON Upgrade utility processes the RECON IMS.RECON1. An example of ajob to execute the RECON Upgrade utility with a JOBLIB statement is shown://UPGRADE JOB (place your job parameters here)//JOBLIB DD DSN=IMS71.SDFSRESL,DISP=SHR//DOIT EXEC PGM=DSPURU00,REGION=4096K//SYSPRINT DD SYSOUT=A//BACKUP1 DD DSN=IMS.RECONX,DISP=OLD//RECON1 DD DSN=IMS.RECON1,DISP=OLD

The RECON Upgrade utility processes the RECON IMS.RECON1. The followingexample is for a job which can be used to execute the RECON Upgrade utility witha STEPLIB statement://UPGRADE JOB (place your job parameters here)//DOIT EXEC PGM=DSPURU00,REGION=4096K//STEPLIB DD DSN=IMS71.SDFSRESL,DISP=SHR//SYSPRINT DD SYSOUT=A//BACKUP1 DD DSN=IMS.RECONX,DISP=OLD//RECON1 DD DSN=IMS.RECON1,DISP=OLD

RECON Upgrade


Chapter 5. Database Recovery Control Utility (DSPURX00)

In This Chapter:

v “Input and Output”

v “Example of DBRC Utility JCL” on page 76

v “JCL Requirements” on page 76

What Is the Database Recovery Control Utility (DSPURX00)?The DBRC utility supports commands that build and maintain the RECON, addinformation to the RECON, and generate jobs for utilities.

Commands submitted to the DBRC utility have the same general format. Eachcommand is composed of a verb and a modifier, separated by a period andfollowed by parameters.

Related Reading: See “Chapter 7. DBRC Commands” on page 99 for informationabout command syntax.

Input and OutputFigure 16 shows the I/O requirements for DBRC. Notes on the figure follow.

Notes to Figure 16:

The input to DBRC is:

1. The DBRC command

2. The RECON

3. The PDS, which contains the JCL and control statements for the utility thatDBRC uses to generate a job

Figure 16. Database Requirements for the DBRC


4. The data set that contains the database descriptions for the databases that areto be placed under the control of DBRC

The output from DBRC is:

5. Jobs created by GENJCL commands

6. The RECON, which may have been updated by the utility

7. One or more of the following:

v A listing of the input commands

v Informational messages associated with their execution or diagnosticmessages explaining any failures and return codes

v A listing of each job that was created in the case of GENJCL commands

Example of DBRC Utility JCLThis sample job initializes the RECON and registers one database with two DBDSs:

JCL RequirementsThe DBRC utility runs as a standard MVS job. The numbers below refer to the JCLstatements illustrated in the previous example.

1. EXEC Indicates the program to be executed.

2. STEPLIB Points to IMS.SDFSRESL, which contains the IMS nucleus and therequired action modules.

//INITRCON JOB1 //INIT04 EXEC PGM=DSPURX002 //STEPLIB DD DSN=IMS.SDFSRESL3 //SYSPRINT DD SYSOUT=A4 //*5 //IMS DD DSN=IMS.DBDLIB6 //JCLPDS DD DSN=IMS.JCLPDS7 //JCLOUT DD DSN=IMS.JCLOUT8 //SYSIN DD *9 INIT.RECON SSID(IMS3)10 INIT.DB DBD(DBDESDS1) SHARELVL(2)11 INIT.DBDS DBD(DBDESDS1) DDN(DDNESDSA) GENMAX(3) -

REUSE DSN(IMS.DBDESDS1.DDNESDSA.DSN) -ICJCL(MYIC) RECOVJCL(MYRECOV) -

12 INIT.IC DBD(DBDESDS1) DDN(DDNESDSA) -ICDSN(IMS.*.ICDSN1)

INIT.IC DBD(DBDESDS1) DDN(DDNESDSA) -ICDSN(IMS.*.ICDSN2) ICDSN2(IMS.*.ICDSN2)

INIT.IC DBD(DBDESDS1) DDN(DDNESDSA) -ICDSN(IMS.*.ICDSN3)

//*13 INIT.DBDS DBD(DBDESDS1) DDN(DDNESDSB) GENMAX(4) -

NOREUSE DSN(IMS.DBDESDS1.DDNESDSB.DSN)//*

14 INIT.CAGRP GRPNAME(CAGRP1) GRPMAX(2) REUSE -GRPMEM((DBDESDS1,DDNESDSA),(DBDESDS1,DDNESDSB))

15 INIT.CA GRPNAME(CAGRP1) CADSN(IMS.*.CADSN1) -VOLLIST(CAVOL1,CAVOL2,CAVOL3) FILESEQ(4)

INIT.CA GRPNAME(CAGRP1) CADSN(IMS.*.CADSN2) -VOLLIST(CAVOL4)

/*

Figure 17. Inputs and outputs of the DBRC Utility

Database Recovery Control Utility


3. SYSPRINT Defines the destination of DBRC diagnostic messages and thelisting output. The destination can be a tape or DASD data set, aprinter, or it can be routed through the output stream (SYSOUT).

4. RECON DD statements for RECON1, RECON2, and RECON3 are omittedso that RECON is allocated dynamically.

5. IMS Defines the IMS DBDLIB data set. It is required only for theINIT.PART commands; the INIT.DBDS commands; the NOTIFY.REORGcommands; the INIT.DB command, if you are initializing a HALDB;and the CHANGE.DBDS commands, if you change a DBDS ddname orarea name.

6. JCLPDS, or the DD name you supply with the JCLPDS parameterDefines the PDS containing skeletal JCL members. It is requiredonly for the GENJCL commands.

7. JCLOUT, or the DD name you supply with the JCLOUT parameterDefines the data set which is to receive generated JCL. It isrequired only for the GENJCL commands.

8. SYSIN Defines the source of input commands. SYSIN can be a tape orDASD data set, a card reader, or it can be routed through the inputstream (DD * or DD DATA.)

Following are the input command statements:

9. INIT.RECONInitializes the RECON with control information and a defaultsubsystem name of IMS3.

10. INIT.DB Registers a database with sharing level 2.

11. INIT.DBDS Identifies a DBDS for the database. It is to have a maximum ofthree image copy data sets, which are to be predefined and are tobe reused when the GENMAX value is exceeded. GENJCL.IC andGENJCL.RECOV commands issued for this DBDS uses theuser-specified skeletal JCL members of the JCLPDS instead of thedefault members ICJCL and RECOVJCL.

12. INIT.IC Commands identify data sets to receive image copies of the DBDSthat was just defined. The data set names are specified using thenaming convention described in “Data Set Naming Conventions” onpage 21. The ICDSN2 parameter on the second INIT.IC commandidentifies a duplicate image copy data set.

13. INIT.DBDS Identifies a second DBDS for the database, for which a maximumof four image copies is to be maintained. Image copy data sets arenot reused, but are deleted when the GENMAX value is exceeded.

14. INIT.CAGRPDefines a change accumulation group that includes the two DBDSsjust defined. A maximum of two change accumulation data sets is tobe maintained for this group, which are to be predefined andreused when the GRPMAX value is exceeded.

15. INIT.CA Commands identify change accumulation data sets that areavailable for future use by the CA group just defined. They arenamed according to the naming convention described in “Data SetNaming Conventions” on page 21.


Chapter 5. Database Recovery Control Utility (DSPURX00) 77

||||||



Chapter 6. Hints and Tips for DBRC

This chapter provides task-oriented instructions for frequently-used procedures,including the following topics:

In This Chapter:

v “Locating the Last SLDS Stop Time in RECON”

v “Adjusting GENMAX When It Is Reached or It Is Too High” on page 80

v “Getting PRILOG Compression to Work” on page 82

v “PRILOG Record Sizes” on page 82

v “Using NOTIFY.PRILOG to Close an Open Online PRILOG” on page 83

v “Deleting Log Records” on page 84

v “Working with Subsystem Records (SSYS)” on page 84

v “Removing Authorization Inconsistency between the SSYS from DB/AREARecords” on page 86

v “Getting Change Accumulation to Start Processing Logs Again” on page 86

v “Getting Change Accumulation Working When It States Nothing to Process” onpage 86

v “Moving Log Data Sets” on page 87

v “Reorganizing RECON to Increase Maximum RECORDSIZE” on page 87

v “Cataloging Data Sets” on page 89

v “Performing Multiple Cold Starts in a Test Environment” on page 90

v “Avoiding Some Causes of RECON Enqueue Problems” on page 91

Locating the Last SLDS Stop Time in RECONFollow this procedure to find the last SLDS stop time in RECON using theGENJCL.USER command. This can be done when IMS is still running and also worksif the PRISLD is already closed.

1. Create a skeletal JCL execution member first. Here is an example of a membernamed USER01:%SELECT SLDS(%USSID,LAST)%ENDSELSLDSDD BEG=%SLDSTIM

END=%SLDETIMVOL=%SLDVOLSUNT=%SLDUNITDSN=%SLDSDSN

2. Issue the GENJCL.USER command indicating the execution member to run with.Below is a sample of the GENJCL.USER command indicating that the command isto be run with member USER01:

GENJCL.USER MEMBER(USER01),-NOJOB, USERKEYS((%USSID,'SYS3')),-JCLOUT(SYSPRINT)

3. Below is the SLDS listing:PRISLDSTART = 96.296 11:51:21.8 * SSID=SYS3 VERSION=6.1STOP = 96.296 13:08:18.4 #DSN=4GSGNAME=**NULL**FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0


DSN=IMSVS.SLDSP.SYS3.D96296.T1151218.V06 UNIT=SYSDASTART = 96.296 11:51:21.8 FIRST DS LSN= 0000000000000001STOP = 96.296 11:52:08.7 LAST DS LSN= 00000000000002B5FILE SEQ=0001 #VOLUMES=0001

VOLSER=000000 STOPTIME = 96.292 11:52:08.7CKPTCT=1 CHKPT ID = 96.292 11:51:26.8

DSN=IMSVS.SLDSP.SYS3.D96296.T1152087.V00 UNIT=SYSDASTART = 96.296 11:52:08.7 FIRST DS LSN= 00000000000002B6STOP = 96.296 11:52:51.6 LAST DS LSN= 000000000000036DFILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.SLDSP.SYS3.D96296.T1152516.V00 UNIT=SYSDASTART = 96.296 11:52:51.6 FIRST DS LSN= 000000000000036ESTOP = 96.296 13:08:16.9 LAST DS LSN= 00000000000004E5FILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.SLDSP.SYS3.D96296.T1152516.V01 UNIT=SYSDASTART = 96.296 13:08:16.9 FIRST DS LSN= 00000000000004E6STOP = 96.296 13:08:18.4 LAST DS LSN= 0000000000000571FILE SEQ=0001 #VOLUMES=0001


Below is the output that results from issuing the previous sample GENJCL.USERcommand:SLDSDD BEG=962961308169

END=962961308184VOL=000000UNT=SYSDADSN=IMSVS.SLDSP.SYS3.D96296.T1152516.V01

Adjusting GENMAX When It Is Reached or It Is Too HighPrior to image copy utility execution, verification exit processing may determine thatone of the following situations is true when image copy data sets are being reused:

v Situation 1- GENMAX Value is Too Low

– The GENMAX value was reached.

– The oldest image copy cannot be reused because it is within the recoveryperiod.

– No available image copies exist that can be used.

– Message DSP0063I was displayed.

See “Solutions for Situation #1” on page 81 on how to correct this.

v Situation 2 - GENMAX Value is Too High

– GENMAX has not been reached so the inuse image copy data sets cannot beused.

– No available image copy data sets exist that can be used.

– Message DSP0084I was displayed.

Hints and Tips


– No recovery preiod is defined.

See “Solution for Situation #2” on how to correct this.

Solutions for Situation #1Either of the following will solve situation number one above:

v Increase GENMAX and define additional image copy data sets.

v Change the recovery period to allow the oldest image copy data set to be used.

Issue the CHANGE.DBDS to increase the GENMAX and INIT.IC parameters to definethe additional image copy data sets:

1. Create a JCL job similar to one of the following jobs. These examples assumethat your DBD name is THISDB, that your area name is AREA1, and that yourprevious GENMAX value was 2.

//CHNGDBDS JOB

//SYSIN DD *CHANGE.DBDS DBD(THISDB) AREA(AREA1) -

GENMAX(4)/*

//INITIC JOB

//SYSIN DD *INIT.IC DBD(THISDB) DDN(DDN1) -

ICDSN(IMS.*.NEWICDSN)INIT.IC DBD(THISDB) DDN(DDN1) -

(IMS.*.NEWICDSN2)/*

Issue CHANGE.DBDS RECOVPD to reduce the recovery period.//CHNGDBDS JOB//SYSIN DD*

CHANGE.DBDS DBD(THISDB) AREA(AREA1) RECOVPD(10)/*

2. Run the job.

3. Check the JES log to ensure that the job ran successfully.

4. Run a LIST command to see the new GENMAX value (optional).

5. Run your image copy job.

Solution for Situation #2v Issue an INIT.IC command to define a new image copy data set for the

identified database data set or area data set

-OR-

v Issue a CHANGE.DBDS command to lower the GENMAX value.

Attention: If GENMAX is lowered using the CHANGE.DBDS command, the newGENMAX value is recorded regardless of whether the oldest image copies areundeletable, because they are within the recovery period.

Hints and Tips

Chapter 6. Hints and Tips for DBRC 81

Getting PRILOG Compression to WorkIf your PRILOG is not getting compressed, do the following:

v Check the EARLIEST CHECKPOINT time stamp listed in the PRILOG.

If this time stamp is within the first DSN entry in the PRILOG, then compressionis not possible. Most often, the oldest checkpoint needed for restart causing theproblem is the checkpoint to rebuild the message queues. If so, take a SNAPQcheckpoint. When the OLDS that records this SNAPQ checkpoint is archived, theearliest checkpoint time stamp is updated.

v Review the allocation records for all databases listed in the LOGALL record thatis associated with this PRILOG.

If the oldest allocation time stamp is within the first DSN entry of the PRILOG,then it is preventing compression.

Concurrent image copies (CICs) and Online image copies (OICs) update theallocation time to reflect the earliest log that is needed for recovery. Thecheckpoint IDs and checkpoint counts on the logs prior to the start of the CIC areused to determine where the new allocation time is set. If the allocation times arenot being moved forward-in-time, ensure that checkpoint IDs and counts arebeing recorded in the DSN entries.

Old allocations for any databases in the LOGALL record can cause compressionto fail. Image copy databases on a regular basis to allow old allocations to bedeleted.

PRILOG Record SizesDBRC ABENDs when the PRILOG record exceeds the maximum record sizedefined for the RECONs. DBRC issues warning messages indicating that aPRILOG record is approaching its maximum size. You can control the timing ofthose messages, taking into account the typical rate at which your system fillsOLDSs and the average number of volumes in each archive data set.

Related Reading: See “Variable Size RECON Records” on page 51 and“CHANGE.RECON” on page 147 for more information about PRILOG recordwarning messages, and how to change the RECON record sizes.

You can calculate the size of a PRILOG record using the following formula:lrecl = (PRILOG_header_length)2 +

(Number_of_DS_entries × DS_entry_length)3 +(Total_number_of_volumes × Volume_entry_length)4

Using the DSPLOGRC DSECT for the PRILOG record, the formula would read likethis:

lrecl = (LOGFXLEN) +(LOGDSNCT × LOGPRLEN) +(LOGVOLCT × LOGVRLEN) <- once for each DS entry

2. PRILOG_header_length = 112 bytes

3. DS_entry_length = 120 bytes

4. Volume_entry_length = 40 bytes

Hints and Tips


Using NOTIFY.PRILOG to Close an Open Online PRILOGDuring timestamp recoveries, when DBRC reports that there are open allocationsthat are not needed for the recovery, it may be easier to close the open PRILOGrather than deleting the individual allocations.

If an open PRILOG record is found for an online IMS subsystem, and the PRILOGrecord is not for the current run of IMS, it indicates that the last OLDS for this onlineIMS has not yet been archived. If the OLDS is no longer available and you need toclose the open PRILOG record, the following command may be used to create adummy DSN entry in the PRILOG:

NOTIFY.PRILOG DSN(DUMMY) STARTIME(960011314544) FIRSTREC(011) -VOLSER(SC3390) SSID(IMSA)NOTIFY.PRILOG STARTIME(960011314544) LASTREC(015) -

SSID(IMSA) RUNTIME(960021315001)CHANGE.PRILOG STARTIME(960011314544) ERROR -DSSTART(960021315000)

Below is the PRILOG as it appears in RECON prior to issuing the NOTIFY.PRILOGcommand to close it:PRILOGSTART = 96.001 13:14:54.4 * SSID=IMSA VERSION=6.1STOP = 00.000 00:00:00.0 #DSN=2GSGNAME=**NULL**FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0EARLIEST CHECKPOINT = 96.001 13:14:54.9

DSN=LOG1 UNIT=3400START = 96.001 13:14:54.4 FIRST DS LSN= 0000000000000001STOP = 96.001 13:15:00.0 LAST DS LSN= 0000000000000005FILE SEQ=0001 #VOLUMES=0001

VOLSER=SC3390 STOPTIME = 96.001 13:15:00.0CKPTCT=0 CHKPT ID = 00.000 00:00:00.0

DSN=LOG2 UNIT=3400START = 96.001 13:15:00.0 FIRST DS LSN= 0000000000000006STOP = 96.002 13:15:00.0 LAST DS LSN= 000000000000000AFILE SEQ=0001 #VOLUMES=0001


Below is the PRILOG as it appears in RECON after issuing the NOTIFY.PRILOGcommand to close it (differences are highlighted):PRILOGSTART = 96.001 13:14:54.4 * SSID=IMSA VERSION=6.1STOP = 96.002 13:15:00.1 #DSN=3GSGNAME=**NULL**FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0EARLIEST CHECKPOINT = 96.001 13:14:54.9

DSN=LOG1 UNIT=3400START = 96.001 13:14:54.4 FIRST DS LSN= 0000000000000001STOP = 96.001 13:15:00.0 LAST DS LSN= 0000000000000005FILE SEQ=0001 #VOLUMES=0001


DSN=LOG2 UNIT=3400

Hints and Tips


START = 96.001 13:15:00.0 FIRST DS LSN= 0000000000000006STOP = 96.002 13:15:00.0 LAST DS LSN= 000000000000000AFILE SEQ=0001 #VOLUMES=0001


DSN=DUMMY ERROR UNIT=3400START = 96.002 13:15:00.0 FIRST DS LSN= 000000000000000BSTOP = 96.002 13:15:00.1 LAST DS LSN= 000000000000000FFILE SEQ=0001 #VOLUMES=0001


Deleting Log RecordsAs time passes, the RECON accumulates old records associated with IMS log datasets. You can use the DELETE.LOG command to eliminate unnecessary PRILOGfamilies and their associated LOGALL records.

Related Reading: See “DELETE.LOG (for OLDS)” on page 177 and“DELETE.LOG (for RLDS and SLDS)” on page 178 for descriptions of the availableDELETE.LOG commands and their parameters.

Use the DELETE.LOG INACTIVE command periodically to keep the RECON free ofunnecessary PRILOG family records. Refer to the description of the DELETE.LOGcommand INACTIVE parameter for the conditions that must be met before DBRCdeletes a PRILOG family of records. The DELETE.LOG command, specified witheither the INACTIVE or the TOTIME parameter, does not delete active log records.

Common problems are old open (nonzero stop time) PRILOG records that werecreated by jobs that terminated abnormally. These jobs abended without closingtheir logs. You can find these open logs by issuing the LIST.LOG command with theOPEN parameter. You can use the DELETE.LOG command with the STARTIMEparameter to remove old, unnecessary, open PRILOG family records.

Here is a list of some other factors that can affect the PRILOG family of records:

v GENMAX

v Frequency of creating DB Image copies

v RECOVPD

v Log Retention Period

Working with Subsystem Records (SSYS)Have you ever wondered what those subsystem names represent in RECON? Ifauthorization for a database fails and you list the database and all the subsystemrecords in the RECON, you may wonder how the subsystem names (SSIDs) werecreated. The next section explains the naming conventions for the subsystemrecords.

Naming Conventions for SSIDs in RECON Subsystem RecordsThe SSYS record is created when a signon call is issued to DBRC. The SSID mustbe unique. Normal conventions for creating the subsystem name are:

Hints and Tips


IMS and DBCTL subsystems = IMSID value from IMSCTRL SYSGEN macro(four characters)

BATCH and UTILITY SUBSYSTEMS = JOBNAME

XRF = RSENAME (Recovery Service Element) of the IMS systems(active and alternate)

Exceptions include the following:ONLINE IMAGE COPY - XXXTZZZZ where

XXXT is the DMB number of the database + DCB number translatedto 0-9,A-ZZZZZ is the control region IMSID

Online image copy is the only BMP that creates its own subsystem record inRECON.

Batch BackoutIf batch backout is processing a log created by a batch subsystem, the SSID that isused is the job name of the subsystem that is being backed out. The job name ofthe batch backout utility job is not used.

If batch backout is processing a log that was created by an online subsystem, thejob name of the backout utility job is used as the SSID.

Deleting a Subsystem RecordWhen you no longer need a particular subsystem record in RECON, the followingcommands can be used to delete the SSYS:

CHANGE.SUBSYS SSID(XXXXX) STARTRCVCHANGE.SUBSYS SSID(XXXXX) ENDRECOV <---(removes auth from DB)DELETE.SUBSYS SSID(XXXXX)

Subsystem Record SizeThe subsystem record grows in size, so maximum LRECL in the VSAM definecluster should be large enough to hold the maximum SSYS size. If the maximumLRECL is too small to hold the maximum SSYS size, IMS abends.

The record size for the subsystem record can be calculated using the followingformula:

72 + (number_of_db_authorized × 32)

Note: 72 = fixed portion of record32 = information for each database authorized(All numbers in decimal)

Hints and Tips


Removing Authorization Inconsistency between the SSYS fromDB/AREA Records

To change database authorization or if authorization fails, a LIST.DB shows that theDB or area is authorized to a non-existent subsystem and backout is not required.Use the command below to remove the authorization. You can also use thecommand below to remove a database/area name from the list in a subsystemrecord when a LIST.SUBSYS shows it authorized and a LIST.DB does not show itauthorized.

CHANGE.DB DBD(dbname) SSID(XXXX) UNAUTH (or)CHANGE.DB DBD(dbname) AREA(areaname) SSID(XXXX) UNAUTH

Getting Change Accumulation to Start Processing Logs AgainChange accumulation erroneously stops processing logs and the source of theproblem is traced to an OLDS left in the ARC STARTED state. An IPL of MVS isdone on the CPU where the archive job was run and the status of the OLDSremains in this state. GENJCL.ARCHIVE jobs do not include any OLDS in ARCSTARTED status. The online IMS that created the OLDS is not running on thisCPU.

If the online IMS is run on the same CPU as the archive job when IMS is restarted,it resets the status of all OLDS in ARC STARTED status to ARC NEEDED. TheOLDS is included in the next archive job. To avoid this problem, run archive jobs onthe same CPU as their corresponding IMS systems.

In cases where manual intervention is required, use the following command tochange the status of the OLDS to archive needed (ARNEEDED):

CHANGE.PRILOG OLDS(DFSOLPXX) ARNEEDED SSID(XXXX)

Getting Change Accumulation Working When It States Nothing toProcess

Change accumulation has issued a message stating that it found no logs toprocess. A review of the listing reveals that there are many logs that need to beprocessed.

DBRC selects all logs needed to satisfy the allocations for each DBDS since theeffective image copy time. The logs are put in log volume start time order as a wayfor DBRC to keep track of which logs it has processed. DBRC processes allavailable logs and truncates the list of log volumes when it encounters a log inerror, an open log, or when it detects an unarchived OLDS. A message indicatingthe condition that was encountered (such as an open log) is issued.

If the last change accumulation execution record shows that a SUBSET of logs wasinput to it last, the STOPTIME reflects the start time of the first unavailable logvolume. Find this log volume time stamp in the RECON listing. If no log volumeexists with this start time, there is an unarchived OLDS.

The following time line illustrates this open OLDS condition:T1--T2---T3--T4-T5--------T6--------T7---------T8----T9---

Hints and Tips


|---A1---D1--|--------------------A4-----------------// (open)Log1 (DSN1) (OPEN OLDS)

|--A2--| |--A3-|Log2 Log3

If GENJCL.CA is run at T7, it includes Log1(DSN1) and has a STOPTIME of T4 andis a SUBSET. T4 is the start time of the first unavailable log. After this JCL isexecuted, any attempts to run GENJCL.CA result in issuing two messages; onestating that an unarchived OLDS exists and another stating that there are no logs toprocess until the open OLDS is closed and archived.

Moving Log Data SetsDBRC records information about an IMS log in the RECON. This informationincludes the log data set name (DSN), its starting and ending times, and the volumeserial (VOLSER).

The best way to avoid lost logs is to use cataloged log data sets and the DBRCCATDS option.

For non-cataloged log data sets, inform DBRC about changes by using theCHANGE.PRILOG or CHANGE.SECLOG command.

Related Reading: See the CHANGE.PRILOG commands starting with“CHANGE.PRILOG (for OLDS)” on page 137 and the CHANGE.SECLOG commandsstarting with “CHANGE.SECLOG (for OLDS)” on page 156.

Reorganizing RECON to Increase Maximum RECORDSIZEThe following actions may result in the need to increase the maximumRECORDSIZE in your AMS (Access Method Services) format RECONs:

v Registering additional databases with DBRC or a change in workload that maycause the number of databases authorized to a subsystem to increase. This maycause the subsystem to grow beyond the current maximum RECORDSIZE.

v PRILOG compression is unable to compress the online PRILOG to keep it withinthe current maximum RECORDSIZE.

A new instance of DBRC cannot be started if the RECORDSIZE for two RECONsdo not match. All batch activity must be quiesced. The online IMS subsystems canremain active if the RECONs are dynamically allocated, otherwise they must beshutdown.

Determine the status of the RECONs using one of the following methods:

v From online IMS, enter:/RML DBRC='RECON STATUS'

v In batch, execute program DSPURX00 to do a LIST.RECON STATUS.Example of current status: RECON1 Copy1

RECON2 Copy2RECON3 Spare

If the online IMS subsystems are shut down, follow this procedure:

Hints and Tips


v Use the DBRC BACKUP.RECON command or Access Method Services (IDCAMS)REPRO command (or both) to backup RECON1. If you are reorganizing theRECON because message DSP0029I was received, you must use the IDCAMSREPRO command to take the backup. The DFSMSdss (DFDSS) utility can beused in place of REPRO.

v Delete and redefine RECON1, RECON2, and RECON3 with the larger maximumRECORDSIZE.

v Copy the backup RECON into RECON1 and RECON2 using IDCAMS REPRO.

If the online IMS subsystems are active, follow this procedure:

v Delete and redefine the spare RECON using IDCAMS with a larger maximumRECORDSIZE.

Example: RECON1 = Copy1 (RECORDSIZE 32K)RECON2 = Copy2 (RECORDSIZE 32K)RECON3 = Spare (RECORDSIZE 64K)

v Issue the online command to force a copy of the RECON2 to the spare RECON:/RMC DBRC='RECON REPLACE(RECON1)'

RECON1 is discarded and deallocated.

v Issue the following command for ALL other online IMS subsystems that areactive:

/RML DBRC='RECON STATUS'

Status of RECONs RECON1 = discarded (RECORDSIZE 32K)RECON2 = Copy1 (RECORDSIZE 32K)RECON3 = Copy2 (RECORDSIZE 64K)

This forces all the online subsystems to deallocate RECON1.

v Delete and redefine RECON1 with the larger RECORDSIZE.

v Issue the following online command to force a copy of RECON3 to the spareRECON:

/RMC DBRC='RECON REPLACE(RECON2)'


v For ALL other online IMS subsystems that are active, issue the followingcommand:


Status of RECONs: RECON1 = Copy2 (RECORDSIZE 64K)RECON2 = discarded (RECORDSIZE 32K)RECON3 = Copy1 (RECORDSIZE 64K)


v Delete and redefine RECON2 with the larger RECORDSIZE.

v Check the status of the RECONs by issuing the following command:


Hints and Tips


Status of RECONs: RECON1 = Copy2 (RECORDSIZE 64K)RECON2 = spare (RECORDSIZE 64K)RECON3 = Copy1 (RECORDSIZE 64K)

Your reorganization is complete.

If you choose to reset the status of the RECONs so that RECON1 is Copy1,RECON2 is Copy2 and RECON3 is the spare; do the following:

v Issue this online command to force a copy of RECON1:/RMC DBRC='RECON REPLACE(RECON3)'


v For ALL other online IMS subsystems that are active, issue this command:


Status of RECONs: RECON1 = Copy1 (RECORDSIZE 64K)RECON2 = Copy2 (RECORDSIZE 64K)RECON3 = discarded (RECORDSIZE 64K)


v Delete and redefine RECON3 with the RECORDSIZE (64 KB).

v Check the status of the RECONs again by issuing the following command:


Status of RECONs: RECON1 = Copy1 (RECORDSIZE 64K)RECON2 = Copy2 (RECORDSIZE 64K)RECON3 = spare (RECORDSIZE 64K)

Cataloging Data SetsYou can indicate whether image copy, change accumulation, and log data sets arecataloged by using the CATDS or NOCATDS keywords on the CHANGE.RECON orINIT.RECON command.

The CHANGE.RECON and INIT.RECON commands update the RECON header recordaccordingly if you specify either CATDS or NOCATDS. The only difference betweenthe two commands in respect to cataloging is that INIT.RECON can be issued onlyonce per RECON.

To specify that these data sets are cataloged specify://CHGRECON JOB

...

//SYSIN DD *CHANGE.RECON CATDS

/*

-OR-

Hints and Tips


//INITRCON JOB

...

//SYSIN DD *INIT.RECON CATDS

/*

The data set must have been initialized as cataloged for CATDS to be effective withthe CHANGE.RECON command.

Specifying NOCATDS on the CHANGE.RECON or INIT.RECON command establishesthat these data sets, regardless of their cataloged status, are not to be treated ascataloged.

To specify that these data sets are not to be treated as cataloged specify://CHGRECON JOB

...

//SYSIN DD *CHANGE.RECON NOCATDS

/*

-OR-//INITRCON JOB

...

//SYSIN DD *INIT.RECON NOCATDS

/*

Related Reading: See “INIT.RECON” on page 239 and “CHANGE.RECON” onpage 147 for more information.

Performing Multiple Cold Starts in a Test EnvironmentMany times in a test environment, you may want to cold start IMS. In order to coldstart IMS the last OLDS must be closed. If you have no need to close the OLDS,you can use the following commands to close the OLDS and mark it archived inRECON so it may be reused:NOTIFY.PRILOG STARTIME(960031314544) RUNTIME(960031314545) -LASTREC(015) OLDS(DFSOLP02) SSID(IMSA)CHANGE.PRILOG OLDS(DFSOLP02) ARCHIVED SSID(IMSA)

The entries for each OLDS (such as: DFSOLP00, DSPOLP01, and DSPOLD02) inthe PRIOLD record are built when the OLDSs are used (if they do not already existin RECON). If you also need to delete the OLDS from RECON, the followingcommands can be used:DELETE.LOG OLDS(DFSOLP00) SSID(IMSA)DELETE.LOG OLDS(DFSOLP01) SSID(IMSA)DELETE.LOG OLDS(DFSOLP02) SSID(IMSA) LASTCLOS

Hints and Tips


Note that the LASTCLOS is necessary to delete the last OLDS used by IMS. ThePRIOLD record is also deleted when the last DDNAME entry is removed.

The PRIOLD record before issuing the commands:PRIOLDSSID=IMSA # DD ENTRIES=3EARLIEST CHECKPOINT = 96.001 14:22:22.2

DDNAME=DFSOLP00 DSN=IMSA.OLDP00START = 96.001 13:14:54.4 FIRST DS LSN= 0000000000000001STOP = 96.002 13:14:54.4 LAST DS LSN= 0000000000000005STATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=96.001 13:14:54.4 ARCHIVE JOB NAME=JT185209VERSION=6.1

DDNAME=DFSOLP01 DSN=IMSA.OLDP01START = 96.002 13:14:54.4 FIRST DS LSN= 0000000000000006STOP = 96.003 13:14:54.4 LAST DS LSN= 000000000000000ASTATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=96.001 13:14:54.4 ARCHIVE JOB NAME=JT185210VERSION=6.1

DDNAME=DFSOLP02 DSN=IMSA.OLDP02START = 96.003 13:14:54.4 FIRST DS LSN= 000000000000000BSTOP = 00.000 00:00:00.0 LAST DS LSN= 0000000000000000STATUS=ACTIVE FEOV=NO AVAILPRILOG TIME=96.001 13:14:54.4 ARCHIVE JOB NAME=JT185211VERSION=6.1

The PRIOLD record after issuing the commands to close and mark DFSOLP02 asarchived (with the differences highlighted):PRIOLDSSID=IMSA # DD ENTRIES=3EARLIEST CHECKPOINT = 96.001 14:22:22.2

DDNAME=DFSOLP00 DSN=IMSA.OLDP00START = 96.001 13:14:54.4 FIRST DS LSN= 0000000000000001STOP = 96.002 13:14:54.4 LAST DS LSN= 0000000000000005STATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=96.001 13:14:54.4 ARCHIVE JOB NAME=JT185209VERSION=6.1

DDNAME=DFSOLP01 DSN=IMSA.OLDP01START = 96.002 13:14:54.4 FIRST DS LSN= 0000000000000006STOP = 96.003 13:14:54.4 LAST DS LSN= 000000000000000ASTATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=96.001 13:14:54.4 ARCHIVE JOB NAME=JT185210VERSION=6.1

DDNAME=DFSOLP02 DSN=IMSA.OLDP02START = 96.003 13:14:54.4 FIRST DS LSN= 000000000000000BSTOP = 96.003 13:14:54.5 LAST DS LSN= 000000000000000FSTATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=96.001 13:14:54.4 ARCHIVE JOB NAME=JT185211VERSION=6.1

Avoiding Some Causes of RECON Enqueue ProblemsThe following section describes some reasons that you may experience RECONenqueue problems and things to watch out for to avoid them.

Related Reading: See “RECON Serialization” on page 47 for more information.

Hints and Tips


In a Shared DASD EnvironmentOperating in a shared DASD environment, the most common cause of RECONenqueue problems is failing to follow the recommendation to catalog each RECONin its own ICF catalog on the same volume as the RECON.

If you catalog each RECON in its own ICF catalog on the same volume as theRECON and still have problems; examine your GRS, (or equivalent) RESERVEconversion list, to determine how you process SYSIGGV2 and DSPURI01QNAMEs. A couple of combinations may lead to deadlocks.

In a Non-Shared DASD EnvironmentIf you are operating in a non-shared DASD environment and are having problems,this is probably not caused by deadlock but rather by contention and slowperformance. Here are a few things to look at in this situation:

1. Minimize the amount of time any job holds the RECON.

One way to minimize that time is to tune the LSR buffer pool DBRC uses whenaccessing the RECONs. There is a CSECT, DSPBUFFS, that contains thevalues used for online, batch, and a procedure in the IMS Version 7Customization Guide on how to zap it to change the values. The defaults maybe low for your usage.

2. Analyze the other contents of the RECON volumes. Consider isolating theRECON volumes, to prevent interference from other I/O activity (and viceversa). Consider placing the RECONs on high performance cached DASD, orperhaps solid state DASD.

Hints and Tips


Part 2. Command Reference

Chapter 7. DBRC Commands . . . . . . . . . . . . . . . . . . . 99Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . 99

Separators . . . . . . . . . . . . . . . . . . . . . . . . . 100Continuation Characters . . . . . . . . . . . . . . . . . . . . 100Comments . . . . . . . . . . . . . . . . . . . . . . . . . 100Commands . . . . . . . . . . . . . . . . . . . . . . . . . 100Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 100DBRC Time Stamps . . . . . . . . . . . . . . . . . . . . . 101

Standard Time Stamp Format . . . . . . . . . . . . . . . . . 101Specifying Zero Time Stamp Values. . . . . . . . . . . . . . . 105Extrapolation of Two-digit Year Input . . . . . . . . . . . . . . 105Time Stamp Conversions and Examples . . . . . . . . . . . . . 105Standard Default Settings for Timestamp Values . . . . . . . . . . 106DBRC Commands Affected by the Time Stamp Format . . . . . . . 106Use of Time History Table (THT) . . . . . . . . . . . . . . . . 107

Using the Commands in This Book . . . . . . . . . . . . . . . . 107Notational Conventions . . . . . . . . . . . . . . . . . . . . 107How to Read the Syntax Diagrams . . . . . . . . . . . . . . . . 107

DBRC Online Command Syntax . . . . . . . . . . . . . . . . . . 110

Chapter 8. BACKUP Command . . . . . . . . . . . . . . . . . . 111BACKUP.RECON . . . . . . . . . . . . . . . . . . . . . . . 111

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 111Example of Creating Backups of a RECON . . . . . . . . . . . . . 111

Chapter 9. CHANGE Commands . . . . . . . . . . . . . . . . . 113CHANGE.ADS . . . . . . . . . . . . . . . . . . . . . . . . 113

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 113Example of Changing an ADS Record . . . . . . . . . . . . . . . 113

CHANGE.BKOUT . . . . . . . . . . . . . . . . . . . . . . . 114Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 114Example of Using the CHANGE.BKOUT Command . . . . . . . . . . 116

CHANGE.CA . . . . . . . . . . . . . . . . . . . . . . . . . 116Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 116Example of Changing a Change Accumulation Run Record . . . . . . . 117

CHANGE.CAGRP . . . . . . . . . . . . . . . . . . . . . . . 118Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 118Examples of Using the CHANGE.CAGRP Command . . . . . . . . . 119

Example of Adding DBDSs to the Existing CA Group CAGRP1 . . . . . 119Example of Deleting DBDSs from the CA Group CAGRP1 . . . . . . 120Example of Changing a CA Group Record . . . . . . . . . . . . 120

CHANGE.DB . . . . . . . . . . . . . . . . . . . . . . . . . 120Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 121Example of Changing a Record for a DB Identified with the DBD Parm 125

CHANGE.DBDS . . . . . . . . . . . . . . . . . . . . . . . . 126Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 127Example of Changing a Record for a Fast Path DEDB . . . . . . . . . 132

CHANGE.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . 132Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 133Example of Changing a Group of DBDSs. . . . . . . . . . . . . . 134

CHANGE.IC . . . . . . . . . . . . . . . . . . . . . . . . . 134Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 135Example of Changing an Image Copy Record . . . . . . . . . . . . 136


CHANGE.PRILOG (for OLDS) . . . . . . . . . . . . . . . . . . . 137Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 137Example of Renaming an OLDS . . . . . . . . . . . . . . . . . 138

CHANGE.PRILOG (for RLDS) . . . . . . . . . . . . . . . . . . . 139Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 140Examples of Using the CHANGE.PRILOG (for RLDS) Command . . . . . 142

Example of Changing Volume Serial Numbers . . . . . . . . . . . 142Example of Marking Primary RLDS for Errors . . . . . . . . . . . 143

CHANGE.PRILOG (for SLDS and TSLDS) . . . . . . . . . . . . . . 143Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 144Examples of Using CHANGE.PRILOG (for SLDS and TSLDS) . . . . . . 147

Example of Changing Volume Serial Numbers and Stop Time . . . . . 147Example of Marking Primary SLDS as Normal . . . . . . . . . . . 147

CHANGE.RECON . . . . . . . . . . . . . . . . . . . . . . . 147Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 148Suggestions for Time Zone Label Table Management . . . . . . . . . 155Example of Updating the RECON Header Record . . . . . . . . . . 155

CHANGE.RECON (for THT or REPTHT) . . . . . . . . . . . . . . . 156Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 156Example of Specifying a Replacement THT Entry. . . . . . . . . . . 156

CHANGE.SECLOG (for OLDS) . . . . . . . . . . . . . . . . . . 156Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 157Example Showing a SECOLDS Error . . . . . . . . . . . . . . . 158

CHANGE.SECLOG (for RLDS) . . . . . . . . . . . . . . . . . . 158Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 159Examples of Using CHANGE.SECLOG (for RLDS) . . . . . . . . . . 161

Example of Changing Volume Serial Numbers . . . . . . . . . . . 161Example of Changing Volume Stop Times . . . . . . . . . . . . 162

CHANGE.SECLOG (for SLDS and TSLDS) . . . . . . . . . . . . . . 162Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 163Examples of Using CHANGE.SECLOG (for SLDS and TSLDS) . . . . . 166

Example of Changing Volume Serial Numbers and Stop Time . . . . . 166Example of Marking the Secondary SLDS as Normal . . . . . . . . 166

CHANGE.SG . . . . . . . . . . . . . . . . . . . . . . . . . 167Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 167Example of Changing the Status of a Service Group . . . . . . . . . 167

CHANGE.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . 168Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 168Example of Identifying the IRLM . . . . . . . . . . . . . . . . . 169

CHANGE.UIC . . . . . . . . . . . . . . . . . . . . . . . . . 170Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 170Example of Changing the Nonstandard ICDSN in RECON . . . . . . . 170

Chapter 10. DELETE Commands . . . . . . . . . . . . . . . . . 171DELETE.ADS . . . . . . . . . . . . . . . . . . . . . . . . . 171

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 171Example of Deleting an ADS Record . . . . . . . . . . . . . . . 171

DELETE.ALLOC . . . . . . . . . . . . . . . . . . . . . . . . 171Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 172Example of Deleting an Allocation Record . . . . . . . . . . . . . 172

DELETE.BKOUT. . . . . . . . . . . . . . . . . . . . . . . . 172Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 172Example of Using the DELETE.BKOUT Command . . . . . . . . . . 173

DELETE.CA . . . . . . . . . . . . . . . . . . . . . . . . . 173Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 173Example of Deleting a Run Record . . . . . . . . . . . . . . . . 173


DELETE.CAGRP . . . . . . . . . . . . . . . . . . . . . . . 174Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 174Example of Deleting CA Group Records . . . . . . . . . . . . . . 174

DELETE.DB . . . . . . . . . . . . . . . . . . . . . . . . . 174Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 174Example of Deleting Records from RECON . . . . . . . . . . . . . 175

DELETE.DBDS . . . . . . . . . . . . . . . . . . . . . . . . 175Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 175Example of Deleting Records for the DBDS . . . . . . . . . . . . . 175

DELETE.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . 175Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 176Example of Deleting a DBDS Group Record . . . . . . . . . . . . 176

DELETE.GSG. . . . . . . . . . . . . . . . . . . . . . . . . 176Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 176Example of Deleting a Global Service Group Record . . . . . . . . . 176

DELETE.IC . . . . . . . . . . . . . . . . . . . . . . . . . . 177Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 177Example of Deleting Information from an Image Copy Record . . . . . . 177

DELETE.LOG (for OLDS) . . . . . . . . . . . . . . . . . . . . 177Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 178Example of Deleting an Interim OLDS Record . . . . . . . . . . . . 178

DELETE.LOG (for RLDS and SLDS) . . . . . . . . . . . . . . . . 178Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 179Example of Deleting the Record of an RLDS and SLDS . . . . . . . . 180

DELETE.RECOV . . . . . . . . . . . . . . . . . . . . . . . 181Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 181Example of Deleting a Recovery Record of the DBDS . . . . . . . . . 181

DELETE.REORG . . . . . . . . . . . . . . . . . . . . . . . 182Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 182Example of Deleting a Reorganization Record of a DBDS . . . . . . . 182

DELETE.SG . . . . . . . . . . . . . . . . . . . . . . . . . 182Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 183Example of Deleting a Global Service Group Record . . . . . . . . . 183

DELETE.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . 183Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 183Example of Deleting a Specified SUBSYS Record . . . . . . . . . . 183

DELETE.UIC . . . . . . . . . . . . . . . . . . . . . . . . . 184Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 184Example of Deleting a Nonstandard Image Copy Data Set Record . . . . 184

Chapter 11. GENJCL Commands . . . . . . . . . . . . . . . . . 185GENJCL.ARCHIVE . . . . . . . . . . . . . . . . . . . . . . . 185

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 185Examples of Running the Log Archive Utility . . . . . . . . . . . . 188

Example with Primary OLDS Defined by the OLDS Parameter . . . . . 188Example of the SSID IMSB OLDS Parameter Defining the Primary OLDS 188Example for Unarchived Default Subsystem OLDSs . . . . . . . . . 188

GENJCL.CA . . . . . . . . . . . . . . . . . . . . . . . . . 189Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 189Examples of Running the Change Accumulation Utility . . . . . . . . . 192

Example for the GRPNAME CA Group. . . . . . . . . . . . . . 192Example of CAJCLA Generated Skeletal JCL . . . . . . . . . . . 192Example of CAJCLB Generated Skeletal JCL . . . . . . . . . . . 192

GENJCL.CLOSE. . . . . . . . . . . . . . . . . . . . . . . . 193Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 193Examples of Running the Log Recovery Utility . . . . . . . . . . . . 195

Part 2. Command Reference 95

Example When a Host Operating System Failed and /ERE Is NotPossible . . . . . . . . . . . . . . . . . . . . . . . . 195

Example Using the CLOSE1 JCLPDS Member . . . . . . . . . . 195GENJCL.IC. . . . . . . . . . . . . . . . . . . . . . . . . . 195

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 197Examples of Running the Database Image Copy Utility. . . . . . . . . 200

Example for DBDS Defined by the DBD and DDN Parameters . . . . . 200Example for All DBDSs in a Group with NOCIC . . . . . . . . . . 201Example of Running the Database Image Copy 2 Utility with SMSCIC 201Example of Running the Database Image Copy 2 Utility with SMSNOCIC 202

GENJCL.OIC . . . . . . . . . . . . . . . . . . . . . . . . . 202Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 203Examples of Running the Online Database Image Copy Utility . . . . . . 206

Example Using JCLPDS Member OICJCL . . . . . . . . . . . . 206Example Using JCLPDS Member OICJCL2 . . . . . . . . . . . . 207

GENJCL.RECEIVE . . . . . . . . . . . . . . . . . . . . . . . 207Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 208Examples of Running the Database Recovery Utility to Receive an Image

Copy . . . . . . . . . . . . . . . . . . . . . . . . . . 210Example for the DBDS Identified by the DBD and DDN Parameters 210Example for All DBDSs in a Group . . . . . . . . . . . . . . . 210

GENJCL.RECOV . . . . . . . . . . . . . . . . . . . . . . . 211Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 212Examples of Running the Database Recovery Utility. . . . . . . . . . 215

Example for the DBDS Identified in the DBD and DDN Parameters . . . 216Example for All DBDSs in a Group . . . . . . . . . . . . . . . 216

GENJCL.USER . . . . . . . . . . . . . . . . . . . . . . . . 216Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 217Example of Running DBRC . . . . . . . . . . . . . . . . . . . 220

Chapter 12. INIT Commands . . . . . . . . . . . . . . . . . . . 221INIT.ADS . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 221Example of Creating a Record That Defines an ADS . . . . . . . . . 222

INIT.CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 222Example of Creating a Record That Defines a CA Data Set . . . . . . . 223

INIT.CAGRP . . . . . . . . . . . . . . . . . . . . . . . . . 223Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 223Example of Creating a CA Group. . . . . . . . . . . . . . . . . 224

INIT.DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 225Example of Creating a SHARELVL 1 DB Record . . . . . . . . . . . 226

INIT.DBDS . . . . . . . . . . . . . . . . . . . . . . . . . . 227Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 227Example of Identifying the DBDS to Initiate DBRC’s Control Over Recovery 231

INIT.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . . . 231Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 232Example of Creating a Group of DBDSs . . . . . . . . . . . . . . 232

INIT.GSG . . . . . . . . . . . . . . . . . . . . . . . . . . 233Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 233Example of Creating a Global Service Group . . . . . . . . . . . . 233

INIT.IC . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 234Example of Creating a Record That Defines the ICDSN . . . . . . . . 235

INIT.PART . . . . . . . . . . . . . . . . . . . . . . . . . . 235


||

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 236INIT.RECON . . . . . . . . . . . . . . . . . . . . . . . . . 239

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 239Example of Initializing the RECON . . . . . . . . . . . . . . . . 243

INIT.SG . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 243Examples of Creating Service Groups . . . . . . . . . . . . . . . 244

Chapter 13. LIST Commands . . . . . . . . . . . . . . . . . . 245LIST.BKOUT . . . . . . . . . . . . . . . . . . . . . . . . . 245

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 245Example of Running LIST.BKOUT . . . . . . . . . . . . . . . . 245

LIST.CAGRP . . . . . . . . . . . . . . . . . . . . . . . . . 245Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 246Example of Specifying the CA Group and CA Records via GRPNAME 246

LIST.DB . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 247Example of Displaying a Database and Its DBDS Records . . . . . . . 248

LIST.DBDS . . . . . . . . . . . . . . . . . . . . . . . . . . 248Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 249Example of Displaying AREA Parameters. . . . . . . . . . . . . . 249

LIST.DBDSGRP . . . . . . . . . . . . . . . . . . . . . . . . 250Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 250Example of Displaying the Members of a DBDS Group. . . . . . . . . 251

LIST.GSG . . . . . . . . . . . . . . . . . . . . . . . . . . 251Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 251Example of Listing a Global Service Group . . . . . . . . . . . . . 252

LIST.HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 252Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 253Example of Displaying a DBDSs Activity History . . . . . . . . . . . 254

LIST.LOG (for a PRILOG Family). . . . . . . . . . . . . . . . . . 254Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 255Example of Listing a PRILOG Family of Records . . . . . . . . . . . 255

LIST.LOG (for a Category of Records) . . . . . . . . . . . . . . . . 255Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 257Example of Displaying RECON Records Specified by STARTIME . . . . . 258Example of Displaying a Subsystem’s OLDS Records . . . . . . . . . 258

LIST.RECON . . . . . . . . . . . . . . . . . . . . . . . . . 258Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 259Examples of Displaying the RECONs . . . . . . . . . . . . . . . 259

Example of Displaying the RECONs . . . . . . . . . . . . . . 259Example of Displaying RECON Header and Status Information. . . . . 259

LIST.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . . . 260Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 260Example of Displaying All Online Subsystem Records . . . . . . . . . 261

Chapter 14. NOTIFY Commands . . . . . . . . . . . . . . . . . 263NOTIFY.ALLOC . . . . . . . . . . . . . . . . . . . . . . . . 263

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 263Example of Adding Allocation Information to RECON . . . . . . . . . 264

NOTIFY.BKOUT . . . . . . . . . . . . . . . . . . . . . . . . 264Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 264Example of Adding a Backout Record to RECON . . . . . . . . . . . 265

NOTIFY.CA. . . . . . . . . . . . . . . . . . . . . . . . . . 265Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 266Example of Adding CADSN Information to RECON . . . . . . . . . . 268

Part 2. Command Reference 97

||

NOTIFY.IC . . . . . . . . . . . . . . . . . . . . . . . . . . 268Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 269Example of Notifying DBRC of Concurrent Image Copy Completion . . . . 270

NOTIFY.PRILOG (for OLDS) . . . . . . . . . . . . . . . . . . . 271Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 271Examples of Using the NOTIFY.PRILOG (for OLDS) Command . . . . . 273

Example of Creating a PRIOLDS for an Online Subsystem OLDS. . . . 273Example of Adding Information about Two Primary OLDSs to RECON 274Example of Creating a PRILOG to Record 2 OLDSs Opening and Closing 274

NOTIFY.PRILOG (for RLDS) . . . . . . . . . . . . . . . . . . . 274Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 275Examples of Using the NOTIFY.PRILOG (for RLDS) Command . . . . . 278

Example of Adding Primary RLDS Information to RECON. . . . . . . 278Example of Adding Interim-Primary RLDS Information to RECON . . . . 278Example of Creating a PRILOG Record for 2 Tracking Log DSs . . . . 279

NOTIFY.PRILOG (for SLDS and TSLDS) . . . . . . . . . . . . . . . 279Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 279Example of Adding Primary SLDS Information to RECON. . . . . . . . 282

NOTIFY.RECOV . . . . . . . . . . . . . . . . . . . . . . . . 283Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 283Example of Adding DBDS Recovery Information to RECON . . . . . . . 285

NOTIFY.REORG . . . . . . . . . . . . . . . . . . . . . . . . 285Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 286Example Adding DBDS Reorganization Information to RECON . . . . . . 288

NOTIFY.SECLOG (for OLDS) . . . . . . . . . . . . . . . . . . . 288Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 288Examples of Using the NOTIFY.SECLOG (for OLDS) Command . . . . . 290

Example of Creating the ISECOLDS Record That Corresponds to theOLDS . . . . . . . . . . . . . . . . . . . . . . . . . 290

Example of Creating a SECOLDS Record for 2 Secondary OLDSs . . . 290NOTIFY.SECLOG (for RLDS) . . . . . . . . . . . . . . . . . . . 291

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 291Examples of Using the NOTIFY.SECLOG (for RLDS) Command . . . . . 294

Example of Adding Secondary RLDS Information to RECON . . . . . 294Example of Adding Interim Secondary RLDS Information to RECON 294

NOTIFY.SECLOG (for SLDS and TSLDS) . . . . . . . . . . . . . . 294Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 295Example of Adding Secondary SLDS Information to RECON . . . . . . 298

NOTIFY.SUBSYS . . . . . . . . . . . . . . . . . . . . . . . 298Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 298Example of Adding a New Subsystem Record to RECON. . . . . . . . 299

NOTIFY.UIC . . . . . . . . . . . . . . . . . . . . . . . . . 299Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 300Example of Adding Nonstandard ICDSN Information to RECON . . . . . 301

Chapter 15. RESET Command . . . . . . . . . . . . . . . . . . 303RESET.GSG . . . . . . . . . . . . . . . . . . . . . . . . . 303

Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 303Example of the RESET.GSG Command . . . . . . . . . . . . . . 304


Chapter 7. DBRC Commands

This section contains a description of the DBRC commands. Use these commandsto add to, change, and delete information in the RECON and to generate the JCLand the control statements you need to run the various IMS utilities used indatabase recovery.

In This Chapter:

v “Command Syntax”

v “DBRC Online Command Syntax” on page 110

v “Using the Commands in This Book” on page 107

Here is a summary of the DBRC commands:

v Use the BACKUP.RECON command to create a backup copy of the RECON.

v Use the CHANGE commands to modify information in the RECON.

v Use the DELETE commands to delete information from the RECON.

v Use the GENJCL commands to generate jobs for the various IMS recovery utilities.

v Use the INIT commands to create records in the RECON.

v Use the LIST commands to produce a formatted printout of all or selected partsof the RECON.

v Use the NOTIFY commands to add to the RECON information that is normallywritten there automatically.

v Use the RESET.GSG command after an unplanned RSR takeover to removeobsolete recovery information about RSR-covered databases and areas from theoriginal active site RECONs.

You can also execute these commands online with the /RMxxxxxx command.

CICS users can execute DBRC commands using the CICS-supplied transactionCDBM, that provides a command interface to DBCTL.

Related Reading:

v See the command chapters for valid parameters and usage notes for eachcommand. See IMS Version 7 Command Reference for online command syntax.

v See CICS/ESA-CICS Supplied Transactions for a description of CDBM, andCICS/ESA-CICS IMS Database Control Guide for details of the DBCTL andDBRC commands you can use with the CDBM transaction.

v See “Using the Commands in This Book” on page 107 for information the syntaxdiagrams and notation used in this book.

v See “Data Set Naming Conventions” on page 21 for information on namingconventions.

Command Syntax

All DBRC commands adhere to the syntax described here. This syntax is standard,command-language syntax and is similar to that of TSO and Access MethodServices.

You can enter commands in uppercase, lowercase, or mixed case format. DBRCtranslates most command input into uppercase format before processing, regardless


of the format that is used. However, DBRC does not translate keyword values andstring values into uppercase format. For example, the ’value’ portion of theUSERKEYS parameter on GENJCL commands, and the UDATA parameter on theNOTIFY.UIC and CHANGE.UIC commands are processed in the exact format inwhich they are entered.

SeparatorsA blank, a comma, or a comment can be interchanged in a command wherever aseparator is needed. More than one separator can be used between parameters.

Continuation CharactersContinuation characters are used to continue commands and comments that do notfit on a single line of input.

The two continuation characters used by DBRC are the minus sign (−) and the plussign (+):

+ Deletes the leading separators from the continued line.

− Does not delete the leading separators from the continued line.

CommentsComments consist of alphanumeric character strings beginning with the symbols (/*)and ending with the symbols (*/).

A comment is assumed to have ended if the end of a line is reached before thecharacter string (*/) is encountered and if the last character in the line is not acontinuation character.

CommandsA command consists of a verb, a modifier, and, in most cases, a list of parameters.Exactly one period (.) follows the verb, with no other characters between the verband the modifier.

Commands can be entered anywhere in columns 1 through 72 of the DBRC SYSINinput stream. Commands can be continued on multiple lines by entering acontinuation character as the last non-blank character of the command line.

Columns 73 through 80 of the SYSIN input stream are ignored.

ParametersThere are no positional parameters in DBRC commands. The keyword parametersare of the following types:

A keyword by itself

A keyword with a value:keyword(v)

A keyword with a list of values:keyword(v1,v2..)

A keyword with a repeating list of values:keyword((v1,v2..),(v1,v2..)..)

Command Syntax


When you enter a repeating list of values only once for this type of keyword, youcan omit the outer set of parentheses like this:

keyword(v1,v2)

Restrictions: For DBRC parameters:

v Certain keywords require values in a specific form.

v The format for hexadecimal input is X'xxx', where X'x' can be any of thecharacters 0-9 and A-F.

v Any character can be part of a character string.

v A character string that contains special characters must be enclosed inapostrophes.

v Data set names, data set ddnames, and volume serial numbers can includehyphens.

v Data set names follow the conventions specified in the MVS JCL manuals.

A character string enclosed in single quotation marks (for example, ('c...c') can becontinued only with a minus continuation character, because separators aremeaningful in a character string between single quotation marks. Such a characterstring is assumed to be ended if the end of a line is reached before the endingquotation mark is encountered and the last non-blank character in the line is not aminus continuation character. The maximum length of a character string is 255characters.

Except where otherwise noted, optional keywords with values have the followingdefaults.

Numeric values 0

Character values blank

If a particular parameter is encountered more than once within a command, the lastoccurrence of the parameter is used. If mutually exclusive parameters areencountered within a command, the last occurrence is used.

DBRC Time StampsTime stamps are points in time recorded in the RECON. Correctly interpreting timestamp formats found in RECON listings, messages, and dumps will help you enterthe appropriate time stamp in commands.

Standard Time Stamp FormatCertain parameters require a time stamp, which may be entered in one of thefollowing formats:

Compressed: yydddhhmmsst [offset]

Punctuated: [yy]yy|ddd|hh|mm|ss|t [offset]

where:

yyyy Is the year (0000 to 9999)

ddd Is the day (000 to 366)

hh Is the hour (0 to 23)

mm Is the minute (0 to 59)

ss Is the second (0 to 59)

Command Syntax

Chapter 7. DBRC Commands 101

t Is the tenth of a second (0 to 9)

| Can be any non-numeric character delimiter including blankexcept the single quotation mark. If the time stampcontains any blanks, commas, or parentheses, it must beenclosed in single quotation marks. For example,LIST.LOG STARTIME('94.252 08:24:45.7 -8')

orLIST.LOG STARTIME('94,252 08:24:45.7 PST')

offset Can be one of the following:

1. Omitted. The current TIMEZIN value is used.

Related Reading: See “CHANGE.RECON” onpage 147 for more information on the TIMEZINparameter.

2. A numeric offset in the form ±h[h[:mm]] or ±h[h[mm]]that, when added to UTC, gives local time. h[h] is anumeric value from 0 to 14. For the compressed formatif mm is specified, then hh must also be specified. mmis a value from the set {00, 15, 30, 45}.

±hh:mm is valid only between the values -11:45 to+14:45.

±hhmm is valid only between the values -1145 to+1445.

3. A symbolic time zone label.

The time stamp value might have elements truncated on the right, in which case theomitted element’s digits are assumed to be zeros.

You can truncate the input at the beginning of any element after ddd; so, yyyy|dddis acceptable, as is yyyy|ddd|hh. Part of an element cannot be entered: forexample, yyyy|ddd|h is invalid.

If only two digits are entered for the year, the two high order digits are extrapolatedby using the sliding-window method described in “Extrapolation of Two-digit YearInput” on page 105.

The same time stamp value could be entered in the following ways:942520824457942520824457-080094.252/08:24:45.7

or with blank, commas, or parentheses:'94.252 08:24:45.7 -8' '94/252-08.24.45.7 -8:00''94,252 08:24:45.7 PST' '94/252-16.24.45.7 UTC''1994 252 16.24.45.7 +0'

TIMEFMT Parameter Sublist:

TIMEFMT(sublist)An optional parameter you use to define the form in which time stamps appearin messages, displays, and listings from DBRC. The five values are positional.Each is optional and can be omitted by including only the comma.

Command Syntax


The format of the TIMEFMT parameter sublist is as follows:

If items of the sublist are omitted, the current values from the RECON header areused.

offsetSpecifies the offset that is to be applied to the UTC internal time before display.

U None-that is, display UTC when the event occurred.

O Offset of origin-that is, display local time when and where the eventoccurred.

L Current local offset-that is, display the current-local-time equivalent.

offset_displaySpecifies the display format of the offset that is appended to the time

L Specifies that the offset is to be displayed in label format, if a label hasbeen defined for it. If no label is defined, the offset is displayed in numericformat.

O Specifies that the offset is to be displayed in the numeric (+|- HH:MM)format.

N Specifies that no time zone information is to be displayed.

formSpecifies whether the time stamp is to be displayed in punctuated orcompressed form.

P Specifies that the time stamp is to be displayed in punctuated form.

C Specifies that the time is to be displayed in compressed form.

year_sizeSpecifies whether all four digits of the year are to be displayed or only the twolow-order digits.

2 Only the units and tens digits of the year are displayed.

4 All four digits of the year are to be displayed.

durationSpecifies the scope of these choices to be either limited to the current job orused as global overrides to the system defaults. The duration subparametercan only be specified on a CHANGE.RECON command.

PERMIndicates that the specified options are to be in effect for any subsequent

OO TIMEFMT ( ),

offset , Aoffset_display

OP

A:

form ,,

year_size ,duration precision

Command Syntax


DBRC utility job running with the same RECON; that is, these valuesbecome the defaults for subsequent jobs.

TEMPIndicates that the specified options are in effect only for the job in which thecommand is entered. If neither PERM nor TEMP is coded, TEMP isassumed.

Besides its use on the CHANGE.RECON command, the TIMEFMT parameter canbe coded on any LIST.xxx or GENJCL.xxx DBRC command. It can also bespecified in a skeletal JCL member as:

%SET TIMEFMT(....)

Here is an example of the %SET keyword in skeletal JCL.%SET TIMEFMT(,N)%SELECT RLDS(%SSID,LAST)LOGEND =%LOGETIM%ENDSEL

And here is what the output from the preceding example of %SET would render:LOGEND =960111315000

Related Reading: See “Using the %SET TIMEFMT Keyword” on page 318 formore examples of %SET output specifications.

precisionCoded only on a %SET statement in skeletal JCL as a number from 1 to 6. Youcan use it to control the number of low-order digits contained in time stampsthat are output by GENJCL. The default is 1, which gives tenths of seconds.DBRC normally ignores digits of a lower order than tenths of seconds. Fulltimestamp precision is not required nor accepted for IMS utility JCL; it is onlyintended for GENJCL output generated for user-specified purposes (normallyGENJCL.USER).

(As with other parameters, coding a null value causes the correspondingTIMEFMT value to be reset to the GENJCL default. TIMEFMT() resets all values.)

TIMEFMT Subparameter Order of Precedence: The order of precedence of theTIMEFMT subparameters, from lowest to highest, is as follows:

1. RECON defaults

The RECON defaults are established by the INIT.RECON command. Thesedefaults can be reset using the PERM option of the CHANGE.RECON command.

2. Job-level override

The RECON defaults can be overridden for the following commands in a SYSINcommand stream using either PERM or TEMP options of the CHANGE.RECONcommand.

3. %SET statements in skeletal JCL members

The TIMEFMT settings in a %SET statement override the GENJCL defaultsettings, as well as settings from a previous %SET statement in the samemember.

4. Command override

The TIMEFMT settings in a DBRC command override all of the above settingswithin the scope of that command invocation. For example, a GENJCL.xxxcommand TIMEFMT setting overrides the TIMEFMT settings on any %SETstatement in the applicable skeletal JCL member.

Command Syntax


When coded on any command other than CHANGE.RECON, the last parameter,duration, has no meaning; any TIMEFMT values coded override the values that arecurrently in effect only for the duration of the command. For any omitted values, thevalues currently in effect from the most recent CHANGE.RECON command with aPERM duration, which override the INIT.RECON defaults, remain in effect.

Default Settings:

The values set in the RECON by INIT.RECON or the upgrade utility areTIMEFMT(O,N,P,2).

The defaults used by GENJCL commands are TIMEFMT(O,O,C,2,1).

Recommendation: If your installation operates multiple IMS systems with differenttime zones and they share data and a RECON; use UTC or LOC for RECON listings,at least, so that all the time stamps listed have a common base.

Specifying Zero Time Stamp ValuesA zero time stamp is valid only where explicitly allowed for a command keywordvalue. A zero time stamp value, where permitted, can be entered in eitherpunctuated or compressed format, or can be condensed into a single digit. Forexample, you can specify a zero time stamp in the following ways:

000000000000'00 000 00:00:00.0'0

If an offset value is given, it is ignored.

Extrapolation of Two-digit Year InputInput time stamps on DBRC commands are accepted with the two-digit yearnotation. In this case the century digits are derived for the use of the internal timestamp. The century digits in the internal time stamp are determined from the twoentered digits by the following process:

The entered year digits are compared to a sliding window of 100 years. Thelower limit of the window is the current year minus 70. The upper limit is thecurrent year plus 29. A “breakpoint” is defined as the two low-order digits of thelower limit.

If the entered digits are equal to, or greater than, the breakpoint; the centurydigits of the lower limit are used. Otherwise, the century digits of the upper limitare used. The upper and lower limits of the window and the breakpoint areestablished when IMS is initialized. When the year changes, these values arerecomputed.

Time Stamp Conversions and ExamplesAssume that local time is PST, offset -08:00, for the examples below:

An event occuring at 1998.030 10:00:0.1 -08:00 (punctuated format) yyyy ddd hhmm ss t or 98030100001 -0800 (compressed format) yydddhhmmsst is recorded in12 bytes in RECON as1998030F|18000012|3456032d|

yyyyddd hhmmsstx xxxxfqqs

hh UTC, 8 hours later than local time

x xxxxLow-order digits ignored by DBRC (except for GENJCL.USER output withprecision)

Command Syntax


fqqs Offset:

f Flag bits, normally 0

qq Quarter hours (32/4=8)

s Sign (D is negative, C is positive)

Note: Offset is always added to UTC to obtain local time. To botain UTC from localtime, reverse the sign and add. Timestamp from a record in RECON, that isPRILOG, lists as:’1998.030 10:0:00.1 -08:00’

When the timestamp above is entered in a command with the quotes, DBRC findsthe record in RECON with the recorded timeas :1998030F 18000012 3456032D

DBRC ignores the low-order time digits and the offset when searching. The UTCdate and time is determined.

If no offset is supplied in the timestamp, DBRC uses the TIMEZIN value which maynot be correct if a clock change has occurred since the time when the record waswritten in RECON.

With the wrong offset supplied in a command, DBRC does not find the record.

Timestamp supplied and wrong offset is used:’1998.030 16:00:00.1 -02:00’

DBRC determines an incorrect search time:1998030F 18000012 3456008D

Timestamps from different RECON listings, even with timestamps displayed indifferent formats, may be used freely, so long as the offsets are included.

Standard Default Settings for Timestamp ValuesThe RECON dataset timestamp formats are the standard default.

From the RECON header:TIMEZIN=%SYS

OUTPUT FORMAT: DEFAULT = LOCORG NONE PUNC YY No user-defined labelsare defined.

Listing an allocation record without offset values lists the timestamp as:99.027 19:03:47.0

The allocation record was written prior to daylight savings change. The timestamp isentered on a command to list the record without an offset. With TIMEZIN=%SYSset in RECON, the offset is obtained from current MVS clock which has changed.The record is not found in RECON.

DBRC Commands Affected by the Time Stamp FormatThese DBRC commands have time stamps as part of their syntax.

Related Reading: See “Standard Time Stamp Format” on page 101 for moreinformation on the standard time stamp format.

Command Syntax


CHANGE.BKOUT CHANGE.CA CHANGE.ICCHANGE.PRILOG CHANGE.SECLOG CHANGE.UICDELETE.ALLOC DELETE.CA DELETE.ICDELETE.LOG DELETE.RECOV DELETE.REORGDELETE.UIC GENJCL.CA GENJCL.RECOVGENJCL.USER LIST.HISTORY LIST.LOGNOTIFY.ALLOC NOTIFY.BKOUT NOTIFY.CANOTIFY.IC NOTIFY.PRILOG NOTIFY.RECOVNOTIFY.REORG NOTIFY.SECLOG NOTIFY.UIC

Use of Time History Table (THT)DBRC uses the time history table to calculate time stamp offsets when lowerreleases that do not contain offsets in their time stamps access a RECON that usestime stamp offsets. If a time history table exists in RECON and DBRC already usesoffsets in its timestamps, the time history table is not used to calculate time stampoffsets.

Using the Commands in This BookThe following sections describe how the commands are presented in this book.

Notational ConventionsDBRC commands generally have both required and optional parameters.

The following list of symbols is used to define the format of the DBRC commands.The symbols, however, should not be used in an actual command unless indicated:

v A vertical bar (|) separates a pair of mutually exclusive parameters in acommand; the last one is used by DBRC.

v An ellipsis (...) indicates that multiple entries of the type immediately precedingthe ellipsis are allowed.

v Other punctuation (parentheses, commas, and spaces) must be entered exactlyas shown.

v Boldface type indicates the exact characters to be entered. Such items must beentered exactly as shown.

v Lowercase words (for example, name) indicate parameters for which you supplythe value.

v A default value is indicated in one of two ways. In a syntax diagram, the defaultappears above the horizontal line. In text, the default parameter is indicated byunderscored text and may be noted in a separate paragraph. If the parameter isomitted, the default is assumed.

How to Read the Syntax DiagramsThe following rules apply to the syntax diagrams used in this book:

Arrow symbolsRead the syntax diagrams from left to right, from top to bottom, followingthe path of the line.

))─── Indicates the beginning of a statement.

───) Indicates that the statement syntax is continued on the next line.

)─── Indicates that a statement is continued from the previous line.

───)+ Indicates the end of a statement.

Command Syntax


Diagrams of syntactical units other than complete statements start with theO─── symbol and end with the ───O symbol.

Conventions

v Keywords, their allowable synonyms, and reserved parameters, appear inuppercase for MVS and OS/2 operating systems, and lowercase forUNIX operating systems. These items must be entered exactly as shown.

v Variables appear in lowercase italics (for example, column-name). Theyrepresent user-defined parameters or suboptions.

v When entering commands, separate parameters and keywords by atleast one blank if there is no intervening punctuation.

v Enter punctuation marks (slashes, commas, periods, parentheses,quotation marks, equal signs) and numbers exactly as given.

v Footnotes are shown by a number in parentheses, for example, (1).

v A � symbol indicates one blank position.

Required itemsRequired items appear on the horizontal line (the main path).

OO REQUIRED_ITEM OP

Optional ItemsOptional items appear below the main path.

OO REQUIRED_ITEMoptional_item

OP

If an optional item appears above the main path, that item has no effect onthe execution of the statement and is used only for readability.

OOoptional_item

REQUIRED_ITEM OP

Multiple required or optional itemsIf you can choose from two or more items, they appear vertically in a stack.If you must choose one of the items, one item of the stack appears on themain path.

OO REQUIRED_ITEM required_choice1required_choice2

OP

If choosing one of the items is optional, the entire stack appears below themain path.

OO REQUIRED_ITEMoptional_choice1optional_choice2

OP

Command Syntax


Repeatable itemsAn arrow returning to the left above the main line indicates that an item canbe repeated.

OO REQUIRED_ITEM S repeatable_item OP

If the repeat arrow contains a comma, you must separate repeated itemswith a comma.

OO REQUIRED_ITEM S

,

repeatable_item OP

A repeat arrow above a stack indicates that you can specify more than oneof the choices in the stack.

Default keywordsIBM-supplied default keywords appear above the main path, and theremaining choices are shown below the main path. In the parameter listfollowing the syntax diagram, the default choices are underlined.

OO REQUIRED_ITEMdefault_choice

optional_choiceoptional_choice

OP

IMS-specific syntax information

FragmentsSometimes a diagram must be split into fragments. The fragmentsare represented by a letter or fragment name, set off like this: | A |.The fragment follows the end of the main diagram. The followingexample shows the use of a fragment.

OO STATEMENT item 1 item 2 A OP

A:

item 3item 4

KEYWORDitem 5

item 6

Substitution-blockSometimes a set of several parameters is represented by asubstitution-block such as <A>. For example, in the imaginary/VERB command you could enter /VERB LINE 1, /VERB EITHERLINE 1, or /VERB OR LINE 1.

Command Syntax


OO /VERB<A>

LINE line# OP

where <A> is:

OO EITHEROR

OP

Parameter endingsParameters with number values end with the symbol '#', parametersthat are names end with 'name', and parameters that can begeneric end with '*'.

OO /MSVERIFY MSNAME msnameSYSID sysid#

OP

The MSNAME keyword in the example supports a name value andthe SYSID keyword supports a number value.

DBRC Online Command SyntaxRelated Reading: See IMS Version 7 Command Reference for details on DBRCcommands that can be entered online.

Command Syntax


Chapter 8. BACKUP Command

The BACKUP command creates backup copies of the RECON.

BACKUP.RECON

OO BACKUP.RECONRECON1

RECON2BOTH

OP

Use the BACKUP.RECON command to create backup copies of the RECON from theCopy1 RECON. The command first opens the RECON and any needed cleanup isdone. The command then invokes the IDCAMS REPRO command, using its normaldefaults, to create the backup copy. Any restrictions applicable to the normal use ofthe REPRO command apply to this command. The data set receiving the backup copymust be empty.

If your RECON RECORDSIZE is greater than 32 KB, the BACKUP.RECONcommand will fail if the back up is to a sequential data set. Do the following to backup a sequential file (on tape for instance):

1. Create a backup KSDS using the BACKUP.RECON command

2. Use DFSMSdss to copy the backed-up KSDS to the sequential file

first create a backup KSDS using the BACKUP.RECON command

ParametersRECON1 | RECON2 | BOTH

A required parameter that specifies the backup data set to which the RECON iscopied.

RECON1Copies RECON to the backup data set specified by the BACKUP1 DDstatement of your JCL.

RECON2Copies RECON to the backup data set specified by the BACKUP2 DDstatement of your JCL.

BOTHCopies RECON to the data sets specified by the BACKUP1 and BACKUP2DD statements of your JCL.

Example of Creating Backups of a RECONIn this example, two backup copies of the Copy1 RECON are created.//BKUP JOB//BACKUP1 DD . . .//BACKUP2 DD . . .

...

//SYSIN DD *BACKUP.RECON BOTH

/*


To create a sequential backup, the BACKUPx DD statement must includeappropriate DCB parameters. The BLKSIZE specified must be larger than themaximum RECORDSIZE defined in the RECON, but less than 32K. For example,DCB=(RECFM=VB,LRECL=32756,BLKSIZE=32760).

BACKUP


Chapter 9. CHANGE Commands

Use the CHANGE commands to change information in the RECON.

CHANGE.ADS

OO CHANGE.ADS ADDN(name) AREA(name) DBD(name)ADDNNEW(name)

O

OADSN(name)

UNAVAIL

AVAILOP

Use the CHANGE.ADS command to change DEDB ADS information in RECON. TheCHANGE.ADS command fails if you issue it while the area is in use.

To create an ADS entry see “INIT.ADS” on page 221.

ParametersADDN(name)

Required parameter you use to specify the area data set ddname of the ADSbeing changed.

AREA(name)Required parameter you use to identify the ADS being changed, by area name.

DBD(name)Required parameter you use to identify the ADS being changed, by databasename

ADDNNEW(name)Optional parameter you use to identify the ADS being changed, by newddname.

ADSN(name)Optional parameter you use to identify the ADS being changed, by new data setname.

AVAIL | UNAVAILMutually exclusive, optional parameters you use to change the ADS record toindicate its availability.

AVAILIndicates that the ADS is available. The CHANGE.ADS AVAIL command fails ifthe area needs to be recovered.

UNAVAILIndicates that the ADS is unavailable.

If neither AVAIL nor UNAVAIL is specified but ADSN is specified, the valuedefaults to UNAVAIL.

Example of Changing an ADS RecordIn this example, an ADS record in RECON is being changed.


//CHGADS JOB

...

//SYSIN DD *CHANGE.ADS DBD(DBD001) AREA(AREA002) -

ADSN(ADSN004) ADDN(ADDN004)/*

CHANGE.BKOUT

OO CHANGE.BKOUT SSID(name) UOR(uor) UORTIME(time stamp) O

O

S

DELETE( UOR )ALL

,

name

PSB(name)

S

,

DBD( name )

O

O

S

,

BKO( name )

OP

Use the CHANGE.BKOUT command to add, change, or delete a unit of recovery (UOR)in the backout record that is associated with a specified subsystem.

Recommendation: Use the CHANGE.BKOUT command when a dynamic backoutfailure has occurred and certain known backout records are invalid. Using theCHANGE.BKOUT command incorrectly can result in a loss of recovery integrity.

ParametersSSID(name)

Required parameter that specifies the subsystem for which the backout recordis to be changed. The name is an alphanumeric string, with up to eightcharacters, that represents any valid subsystem name.

UOR(uor)Required parameter that you use in conjunction with the UORTIME parameterto identify a unit of recovery in the backout record. The recovery token (uor) is16-byte field that describes a specific UOR in the backout record. The value forthis parameter must be expressed as 32 hexadecimal digits.

This parameter can specify a unit of recovery that currently exists in thebackout record or one that is to be added to the record.

UORTIME(time stamp)Required parameter that specifies the time of the UOR described above. Thevalue is the beginning time of the UOR (found in the X'5607' log record). Thetime stamp must be in standard form.

DELETE(UOR | ALL | name...)Optional parameter used to delete some or all of the information related to theunit of recovery that is specified by the required parameters described above.

CHANGE.ADS


UORDeletes the entire UOR defined by the required UOR and UORTIMEparameters described above. If you do not specify DELETE(UOR),CHANGE.BKOUT assumes you are changing an existing UOR or adding a UORthat is not currently in the backout record.

If you specify DELETE(UOR), all other optional parameters are ignored.

If the UOR does not exist in the backout record, the command fails.

ALLSpecifies that the database entries for the specified UOR and UORTIMEare deleted, but that the UOR prefix information is left intact, if you alsospecify database names in the DBD parameter, the BKO parameter, orboth. If you do not specify database names in DBD or BKO, CHANGE.BKOUTacts as if DELETE(UOR) is specified. You can use the ALL option to replace,or substantially alter, a database list within a UOR entry of a backout recordwithout disturbing the control data in the UOR’s prefix. You can also use theALL option to delete all database entries in the UOR except those that arelisted in the DBD or BKO parameters.

nameSpecifies up to eight database names for use with the DELETE parameter.Use a comma to separate each specified name. If you list all of thedatabases associated with the specified unit of recovery, CHANGE.BKOUT actsas if DELETE(ALL) is specified.

If any listed database name is not in the specified UOR, the command fails.

The following optional parameters can only be used if you do not specifyDELETE(UOR). If the UOR already exists in the backout record, you must provide atleast one of the optional parameters. If the UOR does not exist in the backoutrecord, it is added. In this case, you must specify the PSB and either the DBDparameter or the BKO parameter.

You can specify either the BKO parameter, the DBD parameter, or both. However,the same database name cannot appear in both the BKO and the DBD parameters,because a database cannot be both backed out and require a backout at the sametime.

PSB(name)Optional parameter that identifies the PSB associated with the UOR. To add aUOR to the backout record, you must specify PSB(name). If the UOR definedby the required parameters already exists in the backout record, the specifiedPSB name replaces the current PSB name.

DBD(name...)Optional parameter that identifies databases associated with the specified UOR.Up to eight database names can be listed with the DBD parameter. Thedatabase names listed here identify the databases that require backout for thisunit of recovery. This parameter can be used to change the status of an existingdatabase entry to backout required.

BKO(name...)Optional parameter that identifies databases to which the UOR applies. UseBKO to identify databases that have already been backed out from this UOR.Up to eight database names can be specified with the BKO parameter. Thisparameter can be used to change the status of an existing database entry tobackout completed.

CHANGE.BKOUT

Chapter 9. CHANGE Commands 115

Example of Using the CHANGE.BKOUT Command//CHGBKOUT JOB

...

//SYSIN DD *CHANGE.BKOUT SSID(SYS3)—

UOR(E2E8E2F34040400000000600000003)—UORTIME(930931345027) DELETE(ALL)—DBD(DATA1,DATA2,DATA3C)—BKO(DATA4,DATA5,DATA3A)

/*

CHANGE.CA

OO CHANGE.CA GRPNAME(name) RECTIME(time stamp)CADSN(name)

O

OFILESEQ(value) INVALID

VALID3400

UNIT( unittype )

O

O

S

,

VOLLIST( volser )

COMPSUBSET

OP

Use the CHANGE.CA command to change information about a specified run of theChange Accumulation (CA) utility for an identified CA group in RECON.

ParametersGRPNAME(name)

Required parameter you use to specify the name of the CA group for whichinformation is to be changed.

RECTIME(time stamp)Required parameter you use to identify the change accumulation run record thatyou are changing.

Use the STOP time marked with an asterisk (*) from the listing of the CArecord. The time stamp must be in standard form (see “Standard Time StampFormat” on page 101).

CADSN(name)Optional parameter you use to specify the new name of the changeaccumulation data set in the identified record.

FILESEQ(value)Optional parameter you use to specify a new file sequence number that is to berecorded in the identified record.

INVALID | VALIDMutually exclusive, optional parameters you use to specify whether a changeaccumulation data set is to be used as input for a subsequent run of changeaccumulation or database recovery.

CHANGE.BKOUT


INVALIDSpecifies that the change accumulation data set is not to be used as inputfor a subsequent run of change accumulation or database recovery. If aninvalidated change accumulation data set is subsequently reused for outputby change accumulation, it is automatically marked as valid and is used.See “INIT.CAGRP” on page 223 for an explanation of the REUSEparameter.

VALIDSpecifies that the previously invalidated change accumulation data set isavailable for use as input to a subsequent run of change accumulation ordatabase recovery. Use this parameter only if the change accumulationdata set was previously marked as invalid and is now valid.

Specifying the INVALID parameter causes the STOPTIME and RUNTIME of thechange accumulation record to be swapped. This prevents duplicate records inthe RECON. Specifying the VALID parameter causes the STOPTIME andRUNTIME to be swapped back.

UNIT(3400 | unittype)Optional parameter you use to change the unit type of the volumes on whichthe change accumulation data set resides. The unit type can be up to eightalphanumeric characters long.

VOLLIST(volser)Optional parameter that can be listed, that you use to replace the volume serialnumbers of the change accumulation data set in the specified changeaccumulation run record. You can substitute up to 255 volume serial numbers inthe variable field; each can be up to six alphanumeric characters long.

SUBSET | COMPMutually exclusive, optional parameters you use to indicate the changeaccumulation status.

SUBSETIndicates that when the CA was created, a subset of logs were processedand the CA’s stop time is the start time of the first unprocessed log volume.

COMPIndicates that when the CA was created, a complete set of logs wereprocessed and the CA’s stop time is the stop time of the last log volumethat was processed.

You do not need to use this parameter under normal conditions. Checking is notdone to verify that the use of this parameter is consistent with the value of theCA stop time. This parameter value is used by the GENJCL.CA and GENJCL.RECOVprocesses. Incorrect use can result in invalid generated JCL.

Example of Changing a Change Accumulation Run RecordIn this example, a change accumulation run record in RECON is being changed.The INVALID parameter indicates that the identified data set is not to be used asinput to a subsequent run of a utility. The VOLLIST, FILESEQ, and CADSNparameters indicate additional fields in the record that are to be changed.//CHGCA JOB

...

//SYSIN DD *

CHANGE.CA


CHANGE.CA GRPNAME(CAGRP2) RECTIME(820650204335) -INVALID CADSN(IMS.CAGRP2.CA.CADSN2) -VOLLIST(VOLCA1) FILESEQ(4)

/*

CHANGE.CAGRP

OO CHANGE.CAGRP GRPNAME(name)

S

S

,

ADD( (dbname,ddname) ),

DELETE( (dbname,ddname) )

O

OCAJCL(member) DEFLTJCL(member)

NODEFLTGRPMAX(value) NOREUSE

REUSE

OP

Use a CHANGE.CAGRP command to modify information contained in a specified CAgroup record in RECON. You can change the names of DBDSs that are membersof a CA group with this command.

Restriction: Index and ILDS DBDSs are not recoverable, and changes to themare not logged. The CHANGE.CAGRP command does not support these data sets.


Required parameter you use to specify the name of the CA group whose recordyou want to modify.

ADD(dbname,ddname) | DELETE(dbname,ddname)Mutually exclusive, optional parameters you use to specify the member youwant to add to or delete from the specified CA group.

ADDSpecifies members you are adding to the identified CA group. A groupcannot have more than 2000 members.

DELETESpecifies members you are deleting from the identified CA group. Whenyou have deleted a member from a CA group, DBRC has no knowledge ofprevious change accumulation activities on that DBDS.

Specify a list of one or more members in the variable field; each member is apair of names enclosed in parentheses. dbname is the member’s databasename. ddname is the symbolic name of the DD statement.

If you delete all the members of a group, the record of that group is deletedfrom RECON.

CAJCL(member)Optional parameter you use to change the name of a member of a partitioned

CHANGE.CA


data set of skeletal JCL. The member is used to generate the JCL for a run ofthe Change Accumulation utility when you issue a GENJCL.CA command for thespecified CA group.

DEFLTJCL(member) | NODEFLTMutually exclusive, optional parameters you use to specify the implicit skeletalJCL default member for the CA group.

DEFLTJCLSpecifies an implicit skeletal JCL default member for the CA group.GENJCL.CA uses the default member you specify in order to resolvekeywords you have defined. For more information, see “GENJCL.CA” onpage 189.

NODEFLTSpecifies that no skeletal JCL default member is to be used for the CAgroup.

GRPMAX(value)Optional parameter you use to modify the number of change accumulation datasets to be maintained for the specified CA group. The value you substitute inthe variable field must be a decimal number from 2 to 1024.

If you are increasing the GRPMAX value and REUSE is specified, you shoulduse the INIT.CA command to add additional change accumulation data sets. Ifthe number of data sets does not equal GRPMAX, reuse does not take placeand you eventually run out of available data sets for the utility.

NOREUSE | REUSEMutually exclusive, optional parameters you use to indicate whether changeaccumulation data sets should be reused.

NOREUSEIndicates that change accumulation data sets that were already used for thespecified CA group cannot be reused as output data sets in subsequentruns of the Change Accumulation utility. Any existing, unused changeaccumulation run records for the specified CA group are deleted when youspecify the NOREUSE keyword.

REUSEIndicates that change accumulation data sets that were already used for thespecified CA group can be reused as output data sets in subsequent runsof the Change Accumulation utility.

If GRPMAX is higher than the number of existing data sets for the group,you should use the INIT.CA command to add additional data sets;otherwise reuse does not take place. See the explanation for GRPMAX onpage 119.

For additional information about reusing change accumulation data sets, seethe explanation of the REUSE parameter “INIT.CAGRP” on page 223.

Examples of Using the CHANGE.CAGRP CommandHere are several examples of things you can do using the CHANGE.CAGRP command.

Example of Adding DBDSs to the Existing CA Group CAGRP1In this example, the DBDSs identified by the dbname and ddname parameters areto be added to the existing CA group, CAGRP1.

CHANGE.CAGRP


//CHGCAGRP JOB

...

//SYSIN DD *CHANGE.CAGRP GRPNAME(CAGRP1) ADD((DB1,DD1),(DB2,DD2))

Example of Deleting DBDSs from the CA Group CAGRP1In this example, the DBDSs identified by the dbname and ddname parameters areto be deleted from the CA group, CAGRP1.//CHGCAGRP JOB

...

//SYSIN DD *CHANGE.CAGRP GRPNAME(CAGRP1) DELETE((DB3,DD3),(DB4,DD4))

Example of Changing a CA Group RecordIn this example, a CA group record in RECON is being changed. The changes aremade to prevent the reuse of CA data sets by the Change Accumulation utility. Italso renames the member of the partitioned data set of skeletal JCL that is used forgenerating the JCL that is needed for the Change Accumulation utility for this CAgroup.//CHGCAGRP JOB

...

//SYSIN DD *CHANGE.CAGRP GRPNAME(CAGRP3) NOREUSE CAJCL(JCLCA)

/*

CHANGE.DB

OO CHANGE.DBALLDBD(name)

AUTHNOAUTH

NOBACKBACKOUT(value) SSID(name)

O

OPINITNOPINIT

READONREADOFF

SHARELVL( 0 )123

NONRECOVRECOVABL

TYPEFPTYPEIMS

O

OGSGNAME(gsgname)NOTCOVER

RCVTRACKDBTRACK

OP

Or:

OO CHANGE.DB UNAUTH DBD(name)AREA(name)

SSID(name)ACTIVE

TRACKINGOP

CHANGE.CAGRP


Use a CHANGE.DB command to change the information about a database or a FastPath DEDB area. This information is contained in a database record or area recordin RECON. If you specify the parameters SHARELVL, TYPEFP, or TYPEIMS whilethe database or an area of the DEDB is in use, the command fails.

You can also use CHANGE.DB to remove a rare authorization inconsistency betweenthe subsystem (SSYS) record and the data base or area (DB/AREA) record. Thisinconsistency occurs when either the SSYS record still has an entry for theDB/AREA in its authorized data bases/areas list but the DB/AREA record no longercontains the SSID entry in its associated subsystem information list or the SSIDentry is still in the DB/AREA but the SSYS record either no longer exists in RECONor no longer contains an entry for the DB/AREA. Use the AUTH parameter with thesyntax shown above.

Restrictions: The following restrictions apply when you use the UNAUTHparameter:

v Only the DBD, AREA, SSID, and ACTIVE | TRACKING parameters are valid withUNAUTH. If any other parameters are specified, the command fails.

v If AREA, ACTIVE, or TRACKING is specified without UNAUTH, the commandfails.

v If the inconsistency between the SSYS and DB/AREA records as describedabove does not exist then the command fails.

v The ACTIVE or TRACKING parameter must match the SS ROLE field in theassociated subsystem information entry of the specified database or area. Ifthese do not match, the command fails.

ParametersDBD(name) | ALL

Mutually exclusive, required parameters you use to identify the database forwhich the record is to be changed.

DBDSpecifies that you are changing the record of a single database.

For HALDBs, specifies the name of a HALDB partition or the HALDBmaster (if you want to change all partitions of the HALDB master). ForHALDBs, you can use the CHANGE.DB command only as follows:

CHANGE.DB TYPE=HALDB TYPE=PARTAUTH | NOAUTH No YesNOBACK | BACKOUT No YesREADON | READOFF No YesSHARELVL No NoNORECOV | RECOVABL No NoTYPEFP | TYPEIMS No NoGSGNAME | NOTCOVER No NoRCVTRACK | DBTRACK No NoUNAUTH No YesPINIT | NOPINIT Yes Yes

Restriction: If you specify the UNAUTH parameter, you must specify theDBD name. The ALL parameter is not valid with UNAUTH.

ALLSpecifies that you are changing all the databases registered in RECON.

CHANGE.DB


If any of the DBs are HALDB masters or partitions, and you have specifiedany of the restricted parameters (for example, the PINIT or NOPINITparameters), a warning message is issued and command processingcontinues.

AUTH | NOAUTHMutually exclusive, optional parameters you use to specify whether thedatabase is authorized to participate in data sharing.

AUTHIndicates that authorization processing for data sharing is permitted for thedatabase.

NOAUTHIndicates that authorization processing for data sharing is prohibited for thedatabase.

GSGNAME(gsgname) | NOTCOVERMutually exclusive, optional parameters you use to assign the remote siterecovery attributes of a DL/I database.

GSGNAMEAssigns the database to a global service group (GSG).

NOTCOVERDiscontinues remote site recovery for the database.

You cannot use CHANGE.DB to change the state of a database fromnon-RSR-covered to RSR-covered. Message DSP1044I is issued if you attemptto change the covered state of the database with this command. In order tochange a database from not covered to covered, issue the following twocommands for the database:

v DELETE.DB

v INIT.DB

Neither GSGNAME nor NOTCOVER can be specified for Fast Path DEDBs. ForDL/I databases, neither GSGNAME nor NOTCOVER can be specified while thedatabase is in use. A non-recoverable database cannot be assigned to a GSG.

NOBACK | BACKOUT(value)Mutually exclusive, optional parameters you use to specify whether thedatabase needs backout by any subsystem. Do not use these parameters for aDEDB.

NOBACKIndicates that the specified subsystem does not need to back out thedatabase. You use this parameter to delete backout information in thespecified database record.

If the held AUTH state and ENCODED state are zero, and if theBACKOUT-NEEDED flag is on, using the NOBACK parameter causes theassociated subsystem information to be deleted from the database record.

BACKOUTIndicates that the specified subsystem needs to back out the database thespecified number of times. You need to specify the subsystem name withthe SSID parameter. If you do not specify the SSID parameter with theBACKOUT parameter, this command fails.

CHANGE.DB


SSID(name)Required parameter specifying which subsystem encountered the backouterrors.

name is any valid subsystem name.

With UNAUTH, SSID indicates which entry is to be removed from theassociated subsystem information list of the database specified with theDBD parameter, or which SSYS record is to be changed by removing thespecified DB/AREA from the authorized data bases/areas list.

SSID is required with either the BACKOUT or UNAUTH parameters Ifcoded without either BACKOUT or UNAUTH, the command fails.

NONRECOV | RECOVABLMutually exclusive, optional parameters used to specify whether update logs ofthe specified database are recorded in the RECON. These parameters workwith a specified DBD(name) and do not work if ALL is specified.

If the database is registered as RECOVABL, VIO data sets cannot be used forthe output log (IEFRDER) in any job that updates the database. Temporary logdata sets, such as VIO, are deleted at job termination. Therefore, they are notusable for recovery.

NONRECOVSpecifies that no recovery is to be performed on the database. Theseparameters are meaningful for TYPEIMS databases only, and are rejectedfor TYPEFP databases.

NONRECOV cannot be specified for an RSR-covered database.

RECOVABLSpecifies that the database is recoverable and all updates performed for theDBDSs are to be registered in the RECON.

PINIT | NOPINITMutually exclusive, optional parameters used to specify whether a HALDBpartition needs to be initialized. Use this parameter after deleting and redefiningone or more partition data sets without changing the database definition.

If the database specified by DBD parameter is a HALDB master, the change ismade to all partitions. Otherwise, only the partition that is specified is changed.

Restriction: The PINIT|NOPINIT parameters are not valid with ALL.

PINITIndicates that the partition needs to be initialized using the DBPrereorganization utility or the HALDB Partition Data Set Initialization utility.

NOPINITIndicates that the partition does not need to be initialized.

RCVTRACK | DBTRACKMutually exclusive, optional parameters you use to specify the type of RSRtracking (shadowing) for a database that is assigned to a GSG.

RCVTRACKIndicates recovery-readiness tracking.

DBTRACKIndicates database-readiness tracking.

CHANGE.DB


Neither RCVTRACK nor DBTRACK can be specified for Fast Path DEDBs. ForDL/I databases, RCVTRACK or DBTRACK can only be specified if thedatabase is assigned to a GSG and is not currently in use.

READON | READOFFMutually exclusive, optional parameters you use to specify whether thedatabase can be restricted to read only processing only. Do not use eitherparameter for a DEDB.

READONSpecifies that the database can be authorized only for read processing.

READOFFSpecifies that the database can be authorized for both read processing andupdate processing.

SHARELVL(0 | 1 | 2 | 3)Optional parameter you use to specify the level of data sharing for whichauthorized subsystems can share a database. You cannot specify thisparameter for authorized DL/I databases.

The numbers 0, 1, 2, and 3 define the four types of data sharing levels.

0 Indicates that the database cannot be shared.

1 Indicates that the database can be shared by one IMS subsystemauthorized for update and other IMS subsystems authorized only forread processing (no integrity processing). 1 can also indicate that thedatabase can be shared by multiple IMS subsystems that have beenauthorized only for read processing. Level 1 is known as database-levelsharing.

2 Indicates that the database can be shared by multiple, concurrentsubsystems that have been authorized for update in a single-hostprocessor environment. Level 2 is known as intrahost, block-levelsharing.

3 Indicates that the database can be shared by multiple, concurrentsubsystems that have been authorized for update in a multiple-hostprocessor environment. Level 3 is known as interhost, block-levelsharing.

For more information on data sharing levels and dynamic allocation, see IMSVersion 7 Utilities Reference: System.

Restrictions:

v The SHARELVL parameter must be greater than 0 for concurrent imagecopies.

v If you are using IRLM, and have specified SHARELVL 2 or 3, ensure that theVSAM SHAREOPTIONS (3 3) parameter is also specified.

For more information on coordinating VSAM data set definitions with shareoptions, see IMS Version 7 Administration Guide: System.

v The SHARELVL parameter applies to all areas in the DEDB.

v If you change a DEDB from level 0 or 1 to level 2 or 3, the first couplingfacility structure name (CFSTR1) for all VSO areas in the DEDB is set to thename of the area. If you change a DEDB from level 2 or 3 to level 0 or 1,DBRC resets any specified coupling facility structure names to zeros and

CHANGE.DB


resets the LKASID parameter to NOLKASID. See “CHANGE.DBDS” onpage 126 for explanations of the CFSTR1, LKASID, and NOLKASIDparameters.

TYPEFP | TYPEIMSMutually exclusive, optional parameters you use to change the RECON recordstructure to a Fast Path DEDB or a DL/I database.

TYPEFPSpecifies that the database is a Fast Path DEDB and that the recordstructure in RECON must be changed from IMS to Fast Path. TYPEFPcannot be specified for an RSR-covered DL/I database.

TYPEIMSSpecifies that the database is a DL/I database and that the record structurein RECON must be changed from Fast Path to IMS. TYPEIMS cannot bespecified if any area of a DEDB is covered by RSR.

UNAUTHRemoves an entry from the associated subsystem information list in thedatabase specified by the DBD parameter, or removes an entry from theauthorized data bases/areas list in the SSYS record specified by the SSIDparameter. You must specify the following parameters when you use UNAUTH:

DBD(name) For the database name

AREA If the database is a Fast Path DEDB

SSID(name) For the IMS subsystem ID

TRACKING If the IMS subsystem is an RSR tracking subsystem

AREA(name)Required when UNAUTH is specified for a Fast Path DEDB. The name is thename of the DEDB area. If you specify AREA without UNAUTH, the commandfails.

ACTIVE | TRACKINGIndicates the role of the specified subsystem when UNAUTH is specified. Theseparameters are ignored unless UNAUTH is specified.

ACTIVESpecifies that the subsystem is an RSR active subsystem.

TRACKINGSpecifies that the subsystem is an RSR tracking subsystem.

Example of Changing a Record for a DB Identified with the DBD Parm

This example specifies changes to be made to a record in RECON for the databaseidentified with the DBD parameter. The level of data sharing is specified, and thedatabase needs one backout.//CHGDB JOB

...

//SYSIN DD *CHANGE.DB DBD(THISDBD) NOAUTH READOFF SHARELVL(2) -

BACKOUT(1) SSID(IMSID1)/*

CHANGE.DB


CHANGE.DBDS

OO CHANGE.DBDS DBD(name) DDN(name)AREA(name)

S

S

,

ADDEQE( value ),

DELEQE( value )

O

OCFSTR1(name) CFSTR2(name)

NOCFSTR2AUTHNOAUTH

DDNNEW(name)AREANEW(name)

O

ODEFLTJCL(member)NODEFLT

DSN(name) GENMAX(value) GSGNAME(gsgname)NOTCOVER

O

OICJCL(member) ICON

ICOFFNOREUSEREUSE

OICJCL(member) LKASIDNOLKASID

O

OPRELOADNOPREL

O

OPREOPENNOPREO

RCVTRACKDBTRACK

RECOVNORECOV

RECOVJCL(member)O

ORECOVPD(value) RECVJCL(member) VSO

NOVSO

OP

Use a CHANGE.DBDS command to change the information about a DBDS. Thisinformation is contained in a DBDS record in RECON. If you specify DSN,DDNNEW, or AREANEW while the database or an area of a DEDB is in use, thecommand fails.

Restrictions for HALDBs: For HALDBs, you can use this command only asfollows:

CHANGE.DBDS TYPE=PART DataDBDS

TYPE=PART Index/ILDSDBDS

ADDEQE | DELEQE Yes YesCFSTR1 N/A N/ACFSTR2 | NOCFSTR2 N/A N/AAUTH | NOAUTH N/A N/ADDNEW | AREANEW No NoDEFLTJCL | NODEFLT Yes No

CHANGE.DBDS


CHANGE.DBDS TYPE=PART DataDBDS

TYPE=PART Index/ILDSDBDS

DSN No NoGENMAX Yes NoGSGNAME | NOTCOVER N/A N/AICJCL Yes NoICON | ICOFF Yes NoNOREUSE | REUSE Yes NoOICJCL Yes NoLKASID | NOLKASID N/A N/APRELOAD | NOPREL N/A N/APREOPEN | NOPREO N/A N/ARCVTRACK | DBTRACK N/A N/ARECOV | NORECOV Yes YesRECOVJCL Yes NoRECOVPD Yes NoRECVJCL Yes NoVSO | NOVSO N/A N/A

ParametersDBD(name)

Required parameter you use to identify by its database name the DBDS orDEDB area whose record is to be changed.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the DBDS or DEDBarea whose record is to be changed. When you specify DDN, you specify theddname of the DBDS. When you specify AREA, you specify the name of thearea.

ADDEQE(value) | DELEQE(value)Mutually exclusive, optional parameters you use to change the error queueelements of a DBDS.

ADDEQEAdds error queue elements to a DBDS. Error queue elements indicate thatan I/O error occurred on the data set and that the data set therefore needsto be recovered. Processing continues except for that part of the data setdescribed by the error queue element. Error queue elements can be addedonly when the DBDS is not in use. The value specified in the variable fieldis one or more 4-byte hexadecimal values enclosed in quotes; for example,ADDEQE(X'00002345', X'00012345', ...).

DELEQEDeletes error queue elements from a DBDS. Deletion of error queueelements indicates that recovery processing has occurred on that data set.Error queue element deletions can be done only when the DBDS is not inuse. The value specified in the variable field is one or more 4-bytehexadecimal values enclosed in quotes; for example, DELEQE(X'00002345',X'00012345', ...).

When you add an EQE to a database, the RECOV-NEEDED flag isautomatically turned on. When you delete an EQE, and no other EQE flagsexist for the database, the RECOV needed flag is turned off. Do not specifyRECOV or NORECOV when specifying the ADDEQE or DELEQE parameters.

CHANGE.DBDS


CFSTR1(name)Optional parameter you specify to change the name of the first coupling facilitystructure for the identified VSO area. Adhere to the MVS coupling facilitystructure naming conventions. This parameter is valid only for VSO areas ofDEDBs that are defined with SHARELVL(2 | 3). The area name is the default ifthe area is changed to VSO and the DEDB is SHARELVL(2 | 3). CFSTR1 is notallowed if the area is authorized, unless it is also being changed from NOVSOto VSO.

CFSTR2(name) | NOCFSTR2Mutually exclusive, optional parameters you use to update or remove the nameof the second coupling facility structure for the identified VSO area. Theseparameters are valid only for VSO areas of DEDBs that are defined withSHARELVL(2 | 3). These parameters are allowed for an authorized area only ifit is being changed from NOVSO to VSO.

CFSTR2(name)Specifies the new name of the second coupling facility structure. Adhere tothe MVS coupling facility structure naming conventions.

Related Reading: See IMS Version 7 Administration Guide: DatabaseManager for details on coupling facility structure naming conventions.

NOCFSTR2Removes the name of the second coupling facility structure (CFSTR2).

AUTH | NOAUTHMutually exclusive, optional parameters you use to specify whether the area isavailable for authorization processing. The AUTH and NOAUTH parameters arevalid only if you have specified the AREA parameter.

AUTHSpecifies that the area is available for authorization processing.

NOAUTHSpecifies that authorization processing is prohibited for the area.

If you specify the CHANGE.DBDS AREA(name) RECOV command, all ADSs thatbelong to that area are set to unavailable status at the same time.

DDNNEW(name) | AREANEW(name)Mutually exclusive, optional parameters you use to change either the databaseddname of the specified DBDS or the area name of the specified Fast PathDEDB area in RECON.

When you specify this parameter, the new ddname replaces the existingddname for all records in RECON that correspond to the specified DBDS.

You must supply a ddname for the IMS DBDLIB data set in the JCL for theCHANGE.DBDS command. The new ddname must be defined in the IMS DBDlibrary and its numeric data set identifier must be unchanged; it also cannotalready exist in RECON.

AREANEW is valid only if you have specified the AREA parameter.

DEFLTJCL(member) | NODEFLTMutually exclusive, optional parameters you use to specify an implicit skeletalJCL default member for the DBDS.

DEFLTJCLSpecifies the new implicit skeletal JCL default member for the DBDS. The

CHANGE.DBDS


specified member is used by the GENJCL.IC, GENJCL.OIC, and GENJCL.RECOVcommands to resolve keywords you have defined.

NODEFLTRemoves the default JCL name from the DBDS record when you do are notusing a default JCL member.

DSN(name)Optional parameter you use to change the data set name of the identifiedDBDS. You cannot use this parameter for a DEDB area.

GENMAX(value)Optional parameter you use to change the maximum number of image copydata sets DBRC is to maintain for the specified DBDS or DEDB area. valuemust be a decimal number from 2 to 255.

If the value you specify is smaller than the number of image copy data setscurrently existing for the specified DBDS, records of image copy data sets thatare beyond the recovery period are deleted from RECON until the numberreaches the specified GENMAX value. Records of image copy data sets withthe oldest time stamps are deleted until the number that remains equals thespecified GENMAX value.

If you are increasing the GENMAX value and REUSE is specified, you shoulduse the INIT.IC command to create additional image copy records in RECON.If the number of data sets does not equal GENMAX, reuse does not take placeand you eventually run out of available data sets for the utility.

GSGNAME(gsgname) | NOTCOVERMutually exclusive, optional parameters you use to assign the remote siterecovery attributes of a DEDB area.

GSGNAMEAssigns the area to a global service group (GSG).

NOTCOVERDiscontinues remote site recovery for the area.

GSGNAME and NOTCOVER are only valid if AREA is specified.

You cannot use CHANGE.DBDS to change the state of an area fromnon-RSR-covered to RSR-covered. Message DSP1044I is issued if you attemptto change the covered state of the area with this command. In order to changean area from non-RSR-covered to RSR-covered, issue the following twocommands for the area:

v DELETE.DBDS

v INIT.DBDS

ICJCL(member)Optional parameter you use to change the name of the member of thepartitioned data set of skeletal JCL. The GENJCL.IC command uses this name togenerate the JCL for a run of the Database Image Copy utility for the specifiedDBDS or DEDB area.

ICON | ICOFFMutually exclusive, optional parameters you use to specify whether a databaseneeds an image copy.

CHANGE.DBDS


ICONSpecifies that a DBDS needs to have an image copy taken. In theassociated database record, a counter increases to indicate how manyDBDSs need an image copy.

ICOFFSpecifies that a DBDS does not need an image copy. In the associateddatabase record, a counter decreases to indicate the number of DBDSsthat need an image copy.

NOREUSE | REUSEMutually exclusive, optional parameters you use to indicate whether image copydata sets can be reused for subsequent image copy jobs.

NOREUSEIndicates that image copy data sets already used for the specified DBDS orDEDB area are not to be reused for subsequent image copies. Any existing,unused image copy data set records for the specified DBDS or DEDB areaare deleted.

REUSEIndicates that image copy data sets already used for the specified DBDS orDEDB area can be made available for reuse by subsequent image copies.You cannot specify REUSE if RECON contains any nonstandard imagecopy data set records for the DBDS or DEDB area.

If GENMAX is higher than the number of existing data sets for the group,you should use the INIT.IC command to add additional data sets;otherwise reuse does not take place. See the explanation for 129.

For additional information about reusing image copy data sets, see “INIT.DBDS”on page 227 for an explanation of the REUSE parameter.

OICJCL(member)Optional parameter you use to change the name of the partitioned data setmember of skeletal JCL. You cannot use this parameter for a DEDB area. TheGENJCL.OIC command uses this name to generate the JCL for a run of theOnline Database Image Copy utility for the specified DBDS.

LKASID | NOLKASIDMutually exclusive optional parameters you use to specify whether local datacaching for the specified area is to be used for buffer lookaside on readrequests. The LKASID option is valid only for VSO areas that are specified asSHARELVL(2 | 3). These parameters are allowed for an authorized area only ifit is being changed from NOVSO to VSO.

LKASIDIndicates that buffer lookaside is to be performed on read requests for thisarea.

NOLKASIDIndicates that buffer lookaside is not to be performed on read requests forthis area.

PRELOAD | NOPRELMutually exclusive, optional parameters you use to specify whether a VSODEDB area is to be loaded the next time it is opened.

PRELOADIndicates that the area is to be loaded into the data space the next time it isopened. Selecting this option also causes the area to be preopened.

CHANGE.DBDS


NOPRELIndicates that the VSO area is not to be loaded into the data space the nexttime it is opened. CIs are copied into a data space when they are read forthe first time.

PREOPEN | NOPREOMutually exclusive, optional parameters you use to specify whether a VSODEDB area is to be opened either, after the first checkpoint following the nextcontrol region initialization, or when the next /STA AREA command is processed.

PREOPENIndicates that the area is to be opened the next time the control region isstarted or a /STA AREA command is processed. This option is valid for bothVSO and non-VSO areas.

NOPREOIndicates that the area is not to be preopened the next time the controlregion is started or a /STA AREA command is processed. You cannot specifythis parameter with the PRELOAD parameter.

RCVTRACK | DBTRACKMutually exclusive, optional parameters you use to specify the type of RSRtracking (shadowing) for an area assigned to a GSG.



Restriction:

RCVTRACK and DBTRACK can only be specified if AREA is specified and thearea is assigned to a GSG.

RECOV | NORECOVMutually exclusive, optional parameters you use to specify whether a DBDS orDEDB area needs to be recovered.

RECOVSpecifies that the DBDS or area needs to be recovered. ARECOVER-NEEDED counter in the associated database record isincreased to indicate the number of DBDSs that need to be recovered.

NORECOVSpecifies that the DBDS or DEDB area does not need to be recovered. ARECOVERY-NEEDED counter in the associated database record isdecreased to indicate the number of DBDSs that have been recovered.

RECOVJCL(member)Optional parameter you use to change the name of a member of the partitioneddata set of skeletal JCL. The GENJCL.RECOV command uses the member togenerate the JCL for a run of DBRC for the specified DBDS or DEDB area.

RECOVPD(value)Optional parameter you use to change the recovery period of the image copiesfor a specified DBDS or DEDB area.

value must be a number from 0 to 999 that represents the number of days theimage copies are to be kept in RECON. A 0 indicates no recovery period.

CHANGE.DBDS


RECVJCL(member)Optional parameter you use to specify the name of the skeletal JCL member tobe used for the GENJCL.RECEIVE command.

RECVJCL can be specified for both RSR-covered and non-RSR-covered DL/IDBDSs and Fast Path areas.

VSO | NOVSOMutually exclusive, optional parameters you use to specify whether an arearesides in virtual storage the next time the control region is initialized or whenthe next /STA AREA command is processed.

VSOIndicates that the area is to reside in virtual storage. Areas defined withSHARELVL(0 | 1) are read into and written from an MVS data space. Areasdefined with SHARELVL(2 | 3) use the coupling facility to share databetween connected subsystems.

NOVSOIndicates that this area is not to reside in virtual storage.

If an area was previously specified as SHARELVL(2 | 3), changing the areato NOVSO clears the coupling facility structure names and resets theLKASID setting to NOLKASID. NOVSO cannot be specified if the area is inuse.

Example of Changing a Record for a Fast Path DEDB

This example specifies changes to be made to the record in RECON for the FastPath DEDB that is identified by the DBD and AREA parameters. The image copydata sets for the specified DEDB area are not reused, and the maximum number ofimages that DBRC maintains is two. In addition, the image copy data sets for thespecified DBDS are kept in RECON for at least 15 days.//CHGDBDS JOB

...

//SYSIN DD *CHANGE.DBDS DBD(DB3) AREA(DD3) NOREUSE -

GENMAX(2) RECOVPD(15)/*

CHANGE.DBDSGRP

OO CHANGE.DBDSGRP GRPNAME(name) O

CHANGE.DBDS


O S

S

S

S

S

S

,

ADDDB( dbname ),

DELDB( dbname ),

ADDMEM( (dbname,ddname) ),

DELMEM( (dbname,ddname) ),

ADDRECOV( (dbname ) ),areaname

,

DELRECOV( (dbname ) ),areaname

OP

Use a CHANGE.DBDSGRP command to change the information about a DBDS ordatabase group. This information is contained in a DBDS group record in RECON.


Required parameter you use to identify the DBDSGRP to be changed. A recordwith that name must already exist.

ADDDB(dbname)

DELDB(dbname)

ADDMEM(dbname,ddname)

DELMEM(dbname,ddname)

ADDRECOV(dbname,areaname)

DELRECOV(dbname,areaname)Mutually exclusive, optional parameters you use to identify the member ormembers to be added to or deleted from the group. A member can belong toany number of DBGRPs and DBDSGRPs, but can belong to only oneRECOVGRP.

ADDDB

DELDBIdentifies one or more databases or DEDB areas by name. The group musthave been defined as a database group.

ADDMEM

DELMEMIdentifies one or more DBDSs or DEDB areas, each by a pair of namesenclosed in parentheses, where dbname is the database name andddname is the DD statement name or the DEDB name. The group musthave been defined as a DBDS group.

CHANGE.DBDSGRP


ADDRECOV(dbname,areaname)Identifes one or more DBs or DEDB areas, where dbname is the databasename, and areaname is the DD statement name or the DEDB name, to beadded to a recovery group. A recovery group is a group of full-functiondatabases or DEDB areas that you consider to be related. If you use theORS (Online Recovery Service) to perform a TSR (Time Stamp Recovery)on one of the members of the group, ORS requires you to recover allmembers of the group to the same time. A recovery group can otherwise beused like a DB group.

Related Reading: See IMS Version 7 Administration Guide: DatabaseManager for complete information about ORS, its components, and how itworks.

If a DEDB area is to be added to the recovery group, both dbname andareaname must be specified. If the group specified is not a recovery group,the command fails with message DSP0077I.

A database or area can belong to only one recovery group. If any of themembers specified by ADDRECOV already belong to another recoverygroup, the command fails with message DSP0078I.

DELRECOV(dbname,areaname)Identifies one or more DBs or DEDB areas to be deleted from a recoverygroup. If a DEDB area is to be deleted from the recovery group, bothdbname and areaname must be specified. If the group specified is not arecovery group, the command fails with message DSP0077I.

If you delete all the members of a group, the record of that group is deleted fromRECON.

Example of Changing a Group of DBDSsIn this example, a group of DBDSs is changed.//CHGDBGRP JOB

...

//SYSIN DD *CHANGE.DBDSGRP GRPNAME(GRP1) -

ADDMEM((DB1,DD1),(DB2,DD2))/*

CHANGE.IC

OO CHANGE.IC DBD(name) DDN(name)AREA(name)

RECTIME(time stamp) O

OFILESEQ(value) FILESEQ2(value) ICDSN(name) ICDSN2(name)

O

OINVALIDVALID

INVALID2VALID2

RECDCT(value) 3400UNIT( unittype )

O

CHANGE.DBDSGRP


O3400

UNIT2( unittype )S

,

VOLLIST( volser )

O

O

S

,

VOLLIST2( volser )

STOPTIME(time stamp)OP

Use a CHANGE.IC command to modify information contained in an image copyrecord in RECON.

ParametersDBD(name)

Required parameter you use to identify the database name of the DBDS whoseimage copy record is to be modified.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the name of theDBDS or DEDB area to which the image copy record being modified is related.

RECTIME(time stamp)Required parameter you use to identify the specific image copy data set recordto be changed.

Use the Run time marked with an asterisk (*) from the listing of the IMAGErecord. The time stamp must be in standard form (see “Standard Time StampFormat” on page 101

FILESEQ(value)Optional parameter you use to change the file sequence number in the recordof the identified image copy data set.

FILESEQ2(value)Optional parameter you use to change or add the file-sequence number in therecord of the identified duplicate image copy data set.

ICDSN(name)Optional parameter you use to change the data set name of the identifiedimage copy data set.

ICDSN2(name)Optional parameter you use to change or add the data set name of theidentified duplicate image copy data set in an image copy record.

To change the name of the duplicate image copy data set, a record of the firstimage copy data set must exist in RECON.

INVALID | VALIDMutually exclusive, optional parameters you use to prevent or permit the use ofan image copy data set as input to a subsequent run of an image copy job orDBRC.

INVALIDPrevents the use of the specified image copy data set as input to asubsequent run of DBRC or an image copy job. If the invalidated image

CHANGE.IC


copy data set is reused, it is automatically marked as valid. (See“INIT.DBDS” on page 227 for an explanation of the REUSE parameter.)

VALIDPermits the use of a previously invalidated image copy data set as input toa subsequent run of DBRC or an image copy job.

INVALID2 | VALID2Mutually exclusive, optional parameters you use to prevent or permit the use ofa duplicate image copy data set as input to a subsequent run of the DatabaseImage Copy utility or DBRC.

INVALID2Prevents the use of the specified, duplicate image copy data set as input toa subsequent run of the Database Image Copy utility or DBRC. If theinvalidated, duplicate image copy data set is subsequently reused, it isautomatically marked as valid. (See “INIT.DBDS” on page 227 for anexplanation of the REUSE parameter.)

VALID2Permits the use of a previously invalidated, duplicate image copy data setas input to a subsequent run of the Database Image Copy utility or DBRC.

If both INVALID2 and VALID2 are specified, the last one specified is used.

RECDCT(value)Optional parameter you use to change the count of the records in thecorresponding image copy data set in the specified image copy record.CHANGE.ICvalue must be a decimal number up to 2 147 483 647.

UNIT(3400 | unittype)Optional parameter you use to change the unit type that is recorded in thespecified image copy record. The unit type can be up to eight alphanumericcharacters.

UNIT2(3400 | unittype)Optional parameter you use to change the unit type that is recorded in thespecified duplicate image copy record. The unit type can be up to eightalphanumeric characters.

VOLLIST(volser)Optional parameter you use to change, in the image copy record, the volumeserial numbers of the volumes on which the identified image copy data setresides.

VOLLIST2(volser)Optional parameter you use to change or add, in the image copy record, thevolume serial numbers of the volumes on which the identified duplicate imagecopy data set resides.

STOPTIME(time stamp)Optional parameter you use to specify the time when an image copy hascompleted. The time stamp must be in standard form (see “Standard TimeStamp Format” on page 101) and cannot be less than the image copy starttime. If this is an HSSP CIC that is in progress, specifying a valid stop timeterminates the HSSP CIC and resets the in-progress indicators in the IC recordand the DBDS record.

Example of Changing an Image Copy RecordIn this example, information in an image copy record that is identified by the DBD,DDN, and RECTIME parameters is to be changed in RECON. The new data set

CHANGE.IC


names of both image copy data sets (specified in the ICDSN and ICDSN2parameters) follow the default naming convention. The volume serial numbers onwhich the image copy data sets reside are also to be changed as specified in theVOLLIST and VOLLIST2 parameters.//CHGIC JOB

...

//SYSIN DD *CHANGE.IC DBD(DBDKSDS1) DDN(DDNKSDS1) -

ICDSN(IMS.DBDKSDS1.DDNKSDS1.IC.ICDSN02) -ICDSN2(IMS.DBDKSDS1.DDNKSDS1.IC2.ICDSN02) -VOLLIST(ICVOL1,ICVOL2,ICVOL3) FILESEQ2(2) -VOLLIST2(ICVOL4) RECTIME(820921314143)

/*

CHANGE.PRILOG (for OLDS)

OO CHANGE.PRILOG OLDS(ddname)ARNEEDEDARSCHEDARSTARTARCHIVED

AVAILUNAVAIL

DSN(name)O

OERRORNORMAL

SSID(name)OP

Use a CHANGE.PRILOG (for OLDS) command to change information in the RECONabout a PRIOLDS. You cannot change the archive status after an OLDS has beenarchived.

ParametersOLDS(ddname)

Required parameter you use to specify the OLDS for which the RECON recordis to be changed.

ARNEEDED | ARSCHED | ARSTART | ARCHIVEDMutually exclusive, optional parameters you use to change the archive status ofan OLDS.

ARNEEDEDIndicates that the OLDS was closed by IMS and needs to be archived.

ARSCHEDIndicates that the GENJCL.ARCHIVE command has been issued for the OLDS.

ARSTARTIndicates that the Log Archive utility is currently archiving the OLDS.

ARCHIVEDIndicates that the OLDS has been archived and is available for reuse.

AVAIL | UNAVAILMutually exclusive, optional parameters you use to change the PRIOLDS toindicate its availability.

CHANGE.IC


AVAILIndicates that the OLDS contains valid data and can be used as input to theLog Archive utility.

UNAVAILIndicates that the OLDS contains invalid data and should not be used asinput to the Log Archive utility.

DSN(name)Optional parameter you use to change the name of a primary OLDS. name canbe up to 44 characters long.

ERROR | NORMALMutually exclusive, optional parameters you use to change the specifiedPRIOLDS to indicate whether it contains errors.

ERRORChanges the RECON record to indicate that a specified OLDS containserrors, so IMS is unable to close the OLDS properly. Close the OLDSbefore it is used as input to the Log Archive utility.

If you use dual logging, the subsystem uses the data in the error-free OLDS(in other words, the SECOLDS) to close the OLDS marked in error.

If you do not use dual logging, the subsystem uses the next-OLDS to closethe OLDS that is marked in error.

NORMALChanges the record of the PRIOLDS, which was previously marked ascontaining errors, to indicate that the data set is now available for use asinput to any log utility. When you specify NORMAL for an OLDS, the recordimmediately indicates that neither the secondary OLDS nor the next-OLDSis needed in order to close the specified OLDS.

DBRC selects the required log data sets from the PRILOG (or SECLOG)records. These can contain RLDS entries, SLDS entries, or both. If you issue aCHANGE.PRILOG RLDS ERROR command, DBRC automatically uses thecorresponding SECLOG entry, if one exists. If a SECLOG entry does not exist,or if it is marked in error, the GENJCL commands that require log data for thistime frame fail.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the OLDS for which the RECON record is to be changed. The SSID isan eight—character string consisting of any alphanumeric characters thatrepresent a valid IMS subsystem identification name.

If you do not specify SSID, DBRC uses the default subsystem identifier in theRECON header record. Use the INIT.RECON or CHANGE.RECON command to setthe default subsystem identifier in the RECON header record. If you have notspecified a default in the RECON header record, you must specify SSID.

Example of Renaming an OLDSIn this example, the IMS online subsystem, IMSA, that creates the PRIOLDS,renames an OLDS.//CHGPRILG JOB

...



//SYSIN DD *CHANGE.PRILOG OLDS(DFSOLP02) -

DSN(IMS.NEWLOG) SSID(IMSA)/*

CHANGE.PRILOG (for RLDS)

OO CHANGE.PRILOG RLDS STARTIME(time stamp)DSN(name)

O

O

S

,

CHKPTCT( value ) S

,

CHKPTID( chkptid )

O

ODSSTART(time stamp) ERROR

NORMALFILESEQ(value) GAP( ON )

OFF

O

OGSG(gsgname)

S

,

NEWTIME( time stamp )

O

O

S

,

NEWVOL( volser ) S

,

OLDVOL( volser )

O

OPREVGAP( ON )

OFFS

,

RUNTIMES( time stamp )

O

O3400

UNIT( unittype )S

,

VOLLIST( volser )

OP

You can use the CHANGE.PRILOG (for RLDS) command to change information in theRECON about a primary RLDS (or an SLDS that a batch subsystem created). Usethe NOTIFY.PRILOG (for RLDS) command to add a PRILOG record or to add data setentries to an existing PRILOG record.

With the exception of the GSG name and the gap information, all the informationyou can change resides in a data set entry of the PRILOG record. EachCHANGE.PRILOG command you issue changes only one data set entry. If the loghas multiple data sets, you must use the DSSTART parameter to identify the dataset entry to be changed. (Note that if you are only changing the GSG or the gapinformation, you must still specify DSSTART if the log has more than one data set.)



If the PRILOG record represents log data which was received by an RSR trackingsite from an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,NEWVOL, OLDVOL, RUNTIMES, CHKPTID, UNIT, or VOLLIST can be specified.Log data sets received at a tracking site must be cataloged.

ParametersRLDS

Optional parameter you use to specify that a PRILOG record is to be changed.

STARTIME(time stamp)Required parameter you use to specify the starting time stamp of the PRILOGrecord that is to be changed. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

DSN(name)Optional parameter you use to change data set name. name can be up to 44characters.

CHKPTCT(value)Optional parameter you use to change the number of checkpoints completed oneach volume of the data set. Specify a value for each volume designated in theOLDVOL or NEWVOL parameters. If OLDVOL is specified without NEWVOL,the number of values for CHKPTCT equals the number of volume serialnumbers that appear with OLDVOL. If NEWVOL is specified, the number ofvalues for CHKPTCT equals the number of volume serial numbers that appearin NEWVOL.

The values for CHKPTCT are:

0 No checkpoints on the volume

1 A single checkpoint on the volume

2 More than one checkpoint on the volume

CHKPTID(chkptid)Optional parameter you use to change the oldest checkpoint ID for any activePST on each volume of the data set. Specify one checkpoint ID for eachvolume listed in OLDVOL or NEWVOL. If OLDVOL is specified withoutNEWVOL, the number of checkpoint IDs equals the number of volumes listed inOLDVOL. If NEWVOL is specified, the number of checkpoint IDs equals thenumber of volumes listed in NEWVOL.

The checkpoint ID must be in standard form for a time stamp (see “StandardTime Stamp Format” on page 101). You can specify a zero time value.

DSSTART(time stamp)is a parameter you use to specify the starting time of the data set entry to bechanged. The DSSTART parameter is required if the PRILOG has multiple dataset entries; it is optional if the PRILOG has only one data set entry. The timestamp must be in standard form (see “Standard Time Stamp Format” onpage 101).

ERROR | NORMALMutually exclusive, optional parameters you use to change the data set entry toindicate whether it contains errors.

ERRORchanges the data set to indicate that it contains errors and should not beused as input to any DBRC-controlled run of a recovery utility.



NORMALchanges a data set which was previously marked as containing errors toindicate that it is now available for use as input to any recovery utility.

FILESEQ(value)Optional parameter you use to specify the file sequence number on the volume.Specify this parameter only if you specify a VOLLIST parameter. The value yousubstitute in the variable field must be a decimal number from 1 to 9999.

GAP(ON | OFF)Optional parameter you use to set (ON) or reset (OFF) the GAP flag in atracking PRILOG record.

GSG(gsgname)Optional parameter you use to change the global service group (GSG) name inthe PRILOG record.

NEWTIME(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. If you specify NEWTIME, you must also specify OLDVOL andNEWVOL. The parameter sets NEWTIME OLDVOL NEWVOL and RUNTIMESVOLLIST are mutually exclusive.

If you specify NEWTIME, you must specify one less time stamp than thenumber of volume serial numbers specified in NEWVOL. This is because thestop time of the last volume specified in NEWVOL cannot be changed with thiscommand. (See “NOTIFY.PRILOG (for RLDS)” on page 274 to see how tospecify the stop time of the final volume.) Each time stamp is used as thevolume stop time of the corresponding volume serial number specified byNEWVOL. If not specified, the stop time of the new volume is the same as thestop time of the last-specified old volume.

Each time stamp you specify must be greater than the previous time stamp.The first time stamp in NEWTIME must be greater than or equal to the stoptime of the volume immediately preceding the changed volumes. Each timestamp must be in standard form (see “Standard Time Stamp Format” onpage 101).

NEWVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the data set. If you specify NEWVOL, you must also specifyOLDVOL (described below).

The volume serial numbers you specify in NEWVOL replace the correspondingvolume serial numbers specified in the OLDVOL parameter. You do not need tospecify the same number of volume serial numbers in NEWVOL and OLDVOL.You cannot specify a volume serial number in NEWVOL that is the same asone which already exists in the PRILOG record.

You can specify from 1 to 255 volume serial numbers.

Use the NEWTIME parameter to change the time stamps as well as the serialnumbers of the volumes.

OLDVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the data set. If you specify OLDVOL, you must also specifyNEWVOL, CHKPTCT, or CHKPTID.

The volume serial numbers you specify are those of the volumes beingchanged. Each volume serial number specified in OLDVOL must match avolume serial number in the PRILOG record.



|||||

||||||||

|||||


PREVGAP(ON | OFF)Optional parameter you use to set (ON) or reset (OFF) the PREV-GAP flag in atracking PRILOG record.

RUNTIMES(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. This parameter is provided for compatibility with previousreleases of DBRC. You should use the new parameter set, NEWTIME OLDVOLNEWVOL, to change the stop times of log volumes. If you do specifyRUNTIMES, you must also specify VOLLIST. The parameter sets, NEWTIMEOLDVOL NEWVOL and RUNTIMES VOLLIST, are mutually exclusive.

You can specify up to 255 time stamps on the RUNTIMES parameter. Eachtime stamp must be in standard form (see “Standard Time Stamp Format” onpage 101).

Each time stamp in the variable field must correspond to a volume in thevariable field of the VOLLIST parameter. The variable fields of the RUNTIMESand VOLLIST keywords must each contain the same number of entries. Eachtime stamp in the variable field of the RUNTIMES parameter must be greaterthan the previous time stamp.

The first time stamp in the variable field of the RUNTIMES parameter must begreater than the time stamp specified for the STARTIME parameter. The lasttime stamp in the variable field of the RUNTIMES parameter must be equal tothe stop time of the corresponding primary RLDS as specified in the recordbeing changed. You cannot use this command to change the stop time of theprimary RLDS. For information about closing open recovery logs, see“NOTIFY.PRILOG (for RLDS)” on page 274.

UNIT(3400 | unittype)Optional parameter you use to change the unit type of the device on which thedata set resides. The unit type can be up to eight alphanumeric characters long.

VOLLIST(volser)Optional parameter you use to change the record of the volume serial numbersof the volumes that contain the data set. This parameter is provided forcompatibility with previous releases of DBRC. Use the new parameter setNEWTIME OLDVOL NEWVOL to change the volume serial numbers of volumesin the data set.

If you specify the VOLLIST parameter, you must also specify the RUNTIMESparameter. See the description of the RUNTIMES parameter under“Parameters” on page 140 for an explanation of how the two parametersinteract. The parameter sets, NEWTIME OLDVOL NEWVOL and RUNTIMESVOLLIST, are mutually exclusive.

Examples of Using the CHANGE.PRILOG (for RLDS) CommandHere are some examples of using the CHANGE.PRILOG (for RLDS) command.

Example of Changing Volume Serial NumbersIn this example, some volume serial numbers are changed for a log which containsa single data set. The example PRILOG record in RECON has sixvolumes—VOL001, VOL002, VOL003, VOL004, VOL005, and VOL006—and a starttime of 842331243299. The serial numbers of the third and fourth volumes can bechanged with the following command:



//CHGPRILG JOB

...

//SYSIN DD *CHANGE.PRILOG RLDS STARTIME(842331243299) -

OLDVOL(VOL003,VOL004) -NEWVOL(VOL007,VOL008,VOL009)

/*

Example of Marking Primary RLDS for ErrorsIn this example, one data set of a log is being marked as containing errors.//CHGPRILG JOB

...

//SYSIN DD *CHANGE.PRILOG RLDS STARTIME(840541212120) -

DSSTART(840541212120) ERROR/*

CHANGE.PRILOG (for SLDS and TSLDS)

OO CHANGE.PRILOG SLDSTSLDS

STARTIME(time stamp)DSN(name)

O

O

S

,

CHKPTCT( value ) S

,

CHKPTID( chkptid )

O


NORMALFILESEQ(value) GSG(gsgname)

O

O

S

,

NEWTIME( time stamp ) S

,

NEWVOL( volser )

O

O

S

,

OLDVOL( volser ) S

,


O

OSSID(name) 3400

UNIT( unittype )S

,

VOLLIST( volser )

OP

You can use the CHANGE.PRILOG (for SLDS) command to change information in theRECON about a primary SLDS for an online system. You can use theCHANGE.PRILOG (for TSLDS) command to change information in the RECON about a



primary SLDS for an RSR tracking subsystem. Use CHANGE.PRILOG (for RLDS) tochange information about an SLDS that a batch subsystem created, because DBRCconsiders such data to be an RLDS. Use the NOTIFY.PRILOG (for SLDS) commandto add a PRISLD record or to add data set entries to an existing PRISLD record.

With the exception of the GSG name, all the information you can change resides ina data set entry of the PRISLD record. Each CHANGE.PRILOG command youissue changes only one data set entry. If the log has multiple data sets, you mustuse the DSSTART parameter to identify the data set entry to be changed. (Notethat if you are only changing the GSG, you must still specify DSSTART if the loghas more than one data set.)

If the PRISLD record represents log data that was received by an RSR tracking sitefrom an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,NEWVOL, OLDVOL, RUNTIMES, CHKPTID, UNIT, or VOLLIST can be specified.Log data sets received at a tracking site must be cataloged.

ParametersSLDS

Required parameter you use to specify that an PRISLD record is to bechanged.

TSLDSRequired parameter you use to specify that a PRITSLDS record is to bechanged at an RSR tracking subsystem. If you do not specify SLDS or TSLDS,the default is RLDS.

STARTIME(time stamp)Required parameter you use to specify the starting time stamp of the PRISLDrecord that is to be changed. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).











DSSTART(time stamp)is a parameter you use to specify the starting time of the data set entry to bechanged. The DSSTART parameter is required if the PRISLD or PRITSLDS hasmultiple data set entries. The parameter is optional if the PRISLD or PRITSLDShas only one data set entry. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).


ERRORis used to change the data set entry to indicate that it contains errors.

NORMALis used to change a data set entry which was previously marked ascontaining errors to indicate that it is normal.


GSG(gsgname)Optional parameter you use to change the global service group (GSG) name inthe PRISLD record. GSG cannot be specified for PRITSLDS records.

NEWTIME(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. When you specify NEWTIME, you must also specify OLDVOLand NEWVOL. The parameter sets, NEWTIME OLDVOL NEWVOL andRUNTIMES VOLLIST, are mutually exclusive.

When you specify NEWTIME, you must specify one less time stamp than thenumber of volume serial numbers specified in NEWVOL. This is because thestop time of the last volume specified in NEWVOL cannot be changed with thiscommand. (See “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 279 to learnhow to specify the stop time of the final volume.) Each time stamp is used asthe volume stop time of the corresponding volume serial number specified byNEWVOL. If not specified, the stop time of the new volume is the same as thestop time of the last—specified old volume.

Each time stamp you specify must be greater than the previous time stamp.The first time stamp in NEWTIME must be greater than or equal to the stoptime of the volume prior to the changed volumes. Each time stamp must be instandard form (see “Standard Time Stamp Format” on page 101).

NEWVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the data set. When you specify NEWVOL, you must also specifyOLDVOL.

The volume serial numbers you specify in NEWVOL replace the correspondingvolume serial numbers specified in the OLDVOL parameter. You do not need tospecify the same number of volume serial numbers in NEWVOL and OLDVOL.You cannot specify a volume serial number in NEWVOL that is the same asone that already exists in the PRISLD or PRITSLDS record.




|||||

||||||||

||||

Use the NEWTIME parameter if you want to change the time stamps as well asthe serial numbers of the volumes.

OLDVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the primary SLDS or TSLDS. When you specify OLDVOL, you mustalso specify NEWVOL, CHKPTCT, or CHKPTID (all described above).

The volume serial numbers you specify are those of the volumes to bechanged. Each volume serial number specified must match a volume serialnumber in the PRISLD or PRITSLDS record.


RUNTIMES(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. This parameter is provided for compatibility with previousreleases of DBRC. You should use the new parameter set NEWTIME OLDVOLNEWVOL to change the stop times of log volumes. If you do specifyRUNTIMES, you must also specify VOLLIST. The parameter sets, NEWTIMEOLDVOL NEWVOL and RUNTIMES VOLLIST, are mutually exclusive.

You can specify up to 255 time stamps on the RUNTIMES parameter. Eachtime stamp must be in standard form. (See “Standard Time Stamp Format” onpage 101).


The first time stamp in the variable field of the RUNTIMES parameter must begreater than the time stamp specified for the STARTIME parameter. The lasttime stamp in the variable field of the RUNTIMES parameter must be equal tothe stop time of the corresponding primary SLDS or TSLDS as specified in therecord being changed. You cannot use this command to change the stop timeof the primary SLDS or TSLDS. For information about closing open systemlogs, see “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 279.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the SLDS or TSLDS for which the RECON record is to be changed.

The SSID is an eight-character string consisting of any alphanumeric charactersthat describe a valid IMS subsystem identification name. If you do not specifySSID, DBRC uses the default subsystem identifier in the RECON headerrecord. Use the INIT.PRILOG or CHANGE.PRILOG command to set the defaultsubsystem identifier in the RECON header record. If you have not specified adefault in the RECON header record, you must specify SSID.


VOLLIST(volser)Optional parameter you use to change the record of the volume serial numbersof the volumes that contain the data set. This parameter is provided forcompatibility with previous releases of DBRC. You should use the newparameter set, NEWTIME OLDVOL NEWVOL, to change the volume serialnumbers of volumes in the data set.



If you specify the VOLLIST parameter, you must also specify the RUNTIMESparameter. See the above description of the RUNTIMES parameter for anexplanation of how the two parameters interact. The parameter sets, NEWTIMEOLDVOL NEWVOL and RUNTIMES VOLLIST, are mutually exclusive.

Examples of Using CHANGE.PRILOG (for SLDS and TSLDS)Here are some examples of using the CHANGE.PRILOG (for SLDS and TSLDS)command.

Example of Changing Volume Serial Numbers and Stop TimeIn this example, some volume serial numbers and a volume stop time for a logwhich contains a single data set. The example PRISLD record in RECON has astart time of 832331243299 and six volumes (VOL001, VOL002, VOL003, VOL004,VOL005, and VOL006). The fourth volume has been copied to new volumesVOL007 and VOL008, with the new volume stop time 832331248325 for VOL007.The PRISLD record could be updated with the following command://CHGPRILG JOB

...

//SYSIN DD *CHANGE.PRILOG SLDS STARTIME(832331243299) -

OLDVOL(VOL004) -NEWVOL(VOL007,VOL008) -NEWTIME(832331248325)

/*

Example of Marking Primary SLDS as NormalIn this example, the first data set of a primary SLDS is marked as normal.//CHGPRILG JOB

...

//SYSIN DD *CHANGE.PRILOG SLDS STARTIME(820541212120) -

DSSTART(820541212120) NORMAL/*

CHANGE.RECON

OO CHANGE.RECONCATDSNOCATDS

DASDUNIT( unittype )O

ODUALREPLACE(RECONn)

FORCERNOFORCER

NOCHECKCHECK17CHECK44

LISTDLNOLISTDL

O

OLOGALERT( dsnum,volnum ) LOGRET(’time_interval’) NOCOEX

COEX

O



OSSID(name) SIZALERT( dsnum,volnum,percent ) STARTNEW

NONEW

O

OTAPEUNIT(unittype) TRACEON

TRACEOFF

O

O

S

,

TIMEZONE( (label ),offset )

O

OTIMEZIN(offset_rep ,duration) TIMEFMT(sublist)

O

OUPGRADE

OP

Notes:

1 The offset subparameter of the TIMEZONE parameter must be omitted inorder to delete an entry.

Use a CHANGE.RECON command to update options in the RECON status record.

ParametersCATDS | NOCATDS

Mutually exclusive, optional parameters you use to modify the status of whetherimage copy, change accumulation, and log data sets are cataloged.

CATDSSpecifies that these data sets are cataloged. If the data set is allocated bythe catalog and the CATDS option is used, DBRC bypasses volume serialand file sequence verification for the data set.

For CATDS option to be effective, the data set must be cataloged, andVOLSER information for the data set must be omitted from the JCL. If thedata set is cataloged, CATDS is specified, and VOLSER information isincluded in the JCL, DBRC ignores CATDS and allocates the data set bythe JCL. Normal VOLSER and file sequence checking occurs.

If the data set is not cataloged, CATDS is not effective, and DBRC allocatesthe data set by the JCL, with VOLSER and file sequence checking.

Attention: The CATDS option affects restart of IMS from SLDS data sets.Since the CATDS option indicates the SLDS are under the control of acatalog management system, the VOLSER is not passed back to IMS fordata set allocation. If the SLDS data sets are not cataloged, IMS restartfails.

NOCATDSSpecifies that these data sets, regardless of their cataloged status, are not

CHANGE.RECON


to be treated as cataloged. In addition to data set name checking, DBRCverifies that the volume serial and file sequence numbers specified in theJCL are the same as the information recorded in the RECON.

DASDUNIT(unittype)Optional parameter you use to change the unit type of the DASD device thatholds the records for log data sets. The unit type can be up to eightalphanumeric characters long.

DUAL | REPLACE(RECONn)Mutually exclusive, optional parameters you use to reestablish dual mode or toreplace an active RECON data set with the spare RECON:

DUALCauses DBRC to enter dual-RECON mode. If DBRC is already using twoRECONs, the dual parameter is ignored. If DBRC is using one RECON, itattempts to use a spare RECON. If no spare RECON is available, dualmode is not entered; however, any other optional parameters areprocessed.

You are not required to use the DUAL parameter to cause DBRC to enterdual-RECON mode. If as a result of a permanent I/O error on a RECON,for example, DBRC is reduced to the use of a single RECON, itautomatically reenters dual-RECON mode as soon as it becomes aware ofthe existence of a spare RECON. However, in installations that use DBRCfor log control only, it can be some time before DBRC becomes aware of arecently created spare RECON. Use the CHANGE.RECON command with theDUAL parameter to cause DBRC to enter dual-RECON mode immediately.

REPLACECauses DBRC to replace an active RECON with a spare RECON. Whenyou specify this parameter, you can reorganize the RECON data setsonline.

Related Reading: See “Chapter 3. Initializing and Maintaining theRECON” on page 45 for more information about using REPLACE.

For RECONn, specify the DD statement of the RECON you want replaced.For n, you can specify 1, 2, or 3. If you specify a RECON that is not activeor if no spare RECON is available, the replace does not take place;however, any other optional parameters that are specified on the commandare executed.

FORCER | NOFORCERMutually exclusive, optional parameters you use to specify whether alldatabases must be registered in RECON.

FORCERSpecifies that all databases must be registered in RECON. If a job tries toaccess an unregistered database, the database authorization call from IMSto DBRC fails.

NOFORCERSpecifies that databases do not have to be registered in RECON.

DBRC checks this parameter during initialization and it remains in effect for aslong as the subsystem runs. If you change this parameter while the controlregion is active, the change does not take effect until restart or initialization,although the change appears in a listing of the RECON.

CHANGE.RECON


LISTDL | NOLISTDLMutually exclusive, optional parameters you use to specify whether data setnames that are deleted from the RECON (by the DELETE.LOG command or by anarchive job log compression) are listed in the job output. The setting specifiedon this command can be overridden by the DELETE.LOG command. There is noway to override the setting for log compression during an archive job.

LISTDLSpecifies that deleted data set names are to be listed in the job output.

NOLISTDLSpecifies that deleted data set names are not to be listed in the job output.

There is no default for this parameter. If neither is specified, the current settingis unchanged.

NOCHECK | CHECK17 | CHECK44Mutually exclusive, optional parameters you use to change the type ofcomparison of log data set names that is done by DBRC.

NOCHECKSpecifies that the data set name you specify as input to DBRC has a newhigh-level qualifier and is longer than 17 characters. With NOCHECK,DBRC does not compare the log data set name that is recorded in RECONwith the name on the appropriate DD statement.

CHECK17Verifies that the last 17 characters of a log data set name are consistentwith RECON. If the name in RECON does not match the name on theappropriate DD statement, the utility stops.

CHECK44Verifies the 44-character log data set name is consistent with RECON. Ifthe name in RECON does not match the name on the appropriate log DDstatement, the utility stops.

LOGALERT(dsnum,volnum)Optional parameter you use to define the threshold that triggers the DSP0287Wmessage. Message DSP0287W displays when you just have time to shut downan online IMS subsystem before it terminates abnormally because the PRILOGrecord size exceeds the maximum RECORDSIZE (as specified on the DEFINECLUSTER command when the RECON data set was created).

dsnum,volnumThese values apply only to PRILOG-family records. The message isissued when both of the following conditions are true:

v A new OLDS data set opens.

v When there will no longer be room in the PRILOG record tosuccessfully archive all OLDSs currently needing to be archived(including the new one) plus dsnum more, assuming each OLDSuses volnum volumes.

The values that you enter, based on your knowledge of the rate atwhich the subsystem normally fills OLDSs, should be calculated to giveyou sufficient time to effect a normal shutdown of the online IMSsubsystem.

All values must be supplied. A zero (0) in any position means that the existingvalue in the RECON record is not to be changed.

CHANGE.RECON


See Figure 10 on page 54 for an illustration of how LOGALERT affects thePRILOG record.

The default values in a new RECON or one that has been upgraded from anearlier release are (3,16), and are set during INIT.RECON command processing.

LOGRET(time interval)Optional parameter you use to change the retention period for log data sets.

Definitions:

v The retention period is the minimum amount of time in which a logbecomes inactive after it is opened. (It is then eligible to be deleted.)

v The time interval is a partial, punctuated time stamp representing a timeinterval (days, hours, minutes, seconds and tenths of a second) instead ofdate and time. The time stamp for this command follows the format describedin “Standard Time Stamp Format” on page 101 except that the yearsubparameter element is omitted. Valid intervals range from a tenth of asecond to 365 days.

Because the time interval is treated as a time stamp, the message DSP0106Ican be issued for incorrect values. Some examples of valid time intervalsinclude:LOGRET(365)LOGRET('030 12.00')LOGRET('000 00:00:08.0')LOGRET('000 00,00,00,1')

The following shows two different formats for equivalent time stampspecifications. Both are valid.LOGRET(030) LOGRET('030') = 30 daysLOGRET('010 12,30') LOGRET('010 12:30') = 10 days, 12 hours, 30 seconds

Related Reading:

v See “DELETE.LOG (for RLDS and SLDS)” on page 178 for a moreinformation on deleting inactive logs.

NOCOEX | COEXMutually exclusive, optional parameters you use to specify whether pre-version6 and version 7 RECONs may coexist.

NOCOEXUse this keyword if you no longer intend to run any pre-version 6 jobsagainst the RECON. It disables coexistence with pre-version 6 IMS,removing limitations when the local clock is changed (such as for daylightsavings time). You should be sure that the decision to use the NOCOEXkeyword is appropriate. It is possible to reverse this decision but, see theAttention description below.

COEXAllows you to reverse the effect of the NOCOEX keyword, again enablingcoexistence with pre-version 6 RECONs.

Attention: Use this keyword with extreme caution. If the local clock hasbeen changed since coexistence was disabled, or if you have used theNOCOEX keyword to recover from an ABEND U2475, in version 6 orversion 7 (not recommended), endless loops and other unpredictablemalfunctions in your pre-version 6 systems may result.

CHANGE.RECON


SSID(name)Optional parameter you use to change the name of the IMS subsystem to beused as the subsystem ID for the following commands:

v CHANGE.PRILOG

v CHANGE.SECLOG

v DELETE.LOG

v GENJCL.ARCHIVE

v GENJCL.CLOSE

v NOTIFY.PRILOG

v NOTIFY.SECLOG

The SSID is an eight-character string of any alphanumeric characters thatcomprise a valid IMS subsystem identification name.

SIZALERT(dsnum,volnum,percent)Optional parameter you use to define thresholds that trigger messages to warnyou that a record has grown unusually large. The decimal threshold values thatyou supply for SIZALERT are:

dsnum,volnumThese values apply only to PRILOG-family records. The messageDSP0387I is issued when both of the following conditions are true:

v When a new OLDS data set opens.

v All currently open OLDSs, including the new one, have beenarchived, there will no longer be room in the record for dsnum dataset entries of volnum volumes each, or the record size will exceedpercent percent of the defined RECORDSIZE.

The values you that enter, based on your knowledge of the rate atwhich the subsystem normally fills OLDSs, should be calculated to giveyou sufficient time to take corrective action and avoid a shutdown of theonline IMS subsystem.

percentThis value applies to all records. The threshold is reached when arecord exceeding percent percentage of the defined RECORDIZE iswritten to the RECON.

The messages that are triggered by these threshold values are:

v DSP0387I for PRILOG-family records. This message is issued at OLDS openor switch when, after all open OLDSs have been archived, the log recordsize would reach one of the thresholds.

v DSP0007I for all records. This message is issued when a record has beenwritten that exceeds the percent threshold.

The default values (for example, from the INIT.RECON command) in a newRECON or one that has been upgraded from an earlier release are (15,16,95).

All values must be supplied. A zero (0) in any position means that the existingvalue in the RECON record is not to be changed.

See Figure 10 on page 54 for an illustration of how SIZALERT affects thePRILOG record.

CHANGE.RECON


STARTNEW | NONEWMutually exclusive, optional parameters you use to specify whether new jobsare to be started when fewer than two RECONs are available.

STARTNEWSpecifies that new jobs are to be started.

NONEWSpecifies that new jobs are not to be started.

TAPEUNIT(unittype)Optional parameter you use to specify the unit type of the tape device thatholds the records for log data sets. The unit type can be up to eightalphanumeric characters long.

TRACEON | TRACEOFFMutually exclusive, optional parameters you use to specify whether to start orstop external tracing.

TRACEONStarts external tracing. If you specify this parameter, the specifiedGeneralized Trace Facility (GTF) must be active for USR-type records.

TRACEOFFStops external tracing. If you specify this parameter, DBRC only doesinternal tracing.

TIMEZONE((label offset),(label offset))Optional parameter that alters the time zone label table. This parameter is usedto define one or more symbolic time zone labels. Because most people do notreadily associate a numeric offset with a time zone, TIMEZONE allows you todefine symbolic labels, like PST (Pacific Standard Time), for numeric offsets,such as -8.

The time zone label table can contain up to 32 entries, each of which iscomposed of a label and an offset.

Related Reading: See “Suggestions for Time Zone Label Table Management”on page 155 for more information about the TIMEZONE parameter.

labelAn alphanumeric value of up to five characters, the first of which must bealphabetic. Lower-case characters are translated to upper case.

offsetA signed-decimal value in the form of ± [h]h[:mm] that meets therequirements of a valid time stamp offset. See “Standard Time StampFormat” on page 101 for a description of valid offset formats. The offset isthe value that, when added to UTC, gives local time. For example, thevalue to use for PST (Pacific Standard Time) is -8. The value for JST(Japan Standard Time) is +9.

Adding, replacing, and deleting entries from the stored list is supported asfollows:

v Adding an entry to the stored table is accomplished when an input listentry contains both a label that does not exist in the RECON and a validoffset value.

v Replacing an entry to the stored table is accomplished when the inputentry contains both a label that matches an existing label in the table anda valid offset value.

CHANGE.RECON


v Deleting an entry to the stored table is accomplished when the inputentry is a label that matches an existing label in the table and no offsetvalue was specified. If the offset is omitted, and the label is not found inthe table, the table is not altered.

The labels in the table must be unique. Information about the use of labelsversus offsets is presented in, “Suggestions for Time Zone Label TableManagement” on page 155.

TIMEZIN(offset_rep [,duration])Optional parameter you use to define a default time zone value for time stampsthat are entered without time zone information on subsequent DBRCcommands.

offset_repThe default time zone value. It may be one of the following choices:

labelA Time Zone label that has been previously defined using theTIMEZONE parameter.

offsetA numeric offset value in the same form as defined above for theTIMEZONE parameter.

%SYSA keyword used to designate that the offset is to be derived from thecurrent offset found in the MVS CVT control block. This is the initialdefault for DBRC.

durationSpecifies the duration of the offset_rep choice

PERMIndicates that the label or offset default is to be in effect for anysubsequent DBRC command running with the same RECON.

TEMPIndicates that the label or offset default is in effect only for the job inwhich the command is entered.

TIMEFMT(sublist)Optional parameter you use to define the form in which time stamps appearfrom DBRC in messages, displays, and listings. See “Standard Time StampFormat” on page 101 for examples of the different output forms. The five valuesare positional. Each is optional and can be omitted by including only thecomma.

The format of the TIMEFMT parameter sublist is presented in detail in“TIMEFMT Parameter Sublist” on page 102.

UPGRADEOptional parameter that you use to upgrade all IMS Version 6 RECON recordsduring excecution of the CHANGE.RECON command. You do not need to shut downother IMS subsystems that share the RECON, although they might have to waitfor the command to complete.

Restriction: You can issue the CHANGE.RECON UPGRADE command only in thebatch command utility. You cannot issue it from an online IMS.

CHANGE.RECON UPGRADE upgrades the RECON in two stages: first, Copy 1 andthen Copy 2.

CHANGE.RECON


Message DSP0250l indicates the beginning of the first stage. Any failure duringthis stage causes DBRC to reconfigure the RECONs, discarding Copy 1. If afailure occurs during the first stage, you need to rerun the CHANGE.RECONUPGRADE command.

After successful completion of the first stage, message DSP0251l indicates thatthe second stage is beginning. Any failure during this stage causes DBRC toreconfigure the RECONs, discarding Copy 2. However, if there is a failureduring the second stage, you do NOT need to rerun the CHANGE.RECON UPGRADEcommand.

You can use the CHANGE.RECON UPGRADE command in either nonconcurrent orconcurrent mode. The mode is determined by the environment at the time youissue the command.

NonconcurrentNo other jobs are currently accessing the RECON.

Before issuing the CHANGE.RECON UPGRADE command, you mightwant to create a backup copy of the RECON in case the upgrade andthe RECON recovery procedures fail, which can happen if you have notallocated two RECONs and a spare.

ConcurrentOther jobs are currently accessing the RECON. These jobs can beeither pre-version 6 or Version 6, and must have the respective Version7 SPE applied. Two RECONs plus a spare must be allocated for aconcurrent upgrade.

Suggestions for Time Zone Label Table ManagementThe same offset should not be designated by more than one label because DBRCalways uses the first occurrence in the in the table when outputting a time stamp.

The practicality of using the label format is affected by the scope of the IMSinstallation. For those operating solely in a single time zone, use of labelseliminates the need for the operator to know the exact offset to UTC at all timesduring the year. For multiple time zone operation, the use of offsets rather thanlabels, is suggested (though not mandatory). The time zone label table may not bepractical if offsets are not unique from one zone to the next when daylight savingtime adjustments are taken into account. Changing the table when daylight savingtime switches are made, would add to the confusion, so in that case, use numericoffset values for cross time zone operation.

Example of Updating the RECON Header RecordIn this example, you are:

v Forcing all databases to be registered

v Changing the default subsystem ID to IMSB

v And changing the log retention period to 7 days//CHGRECON JOB

...

//SYSIN DD *CHANGE.RECON SSID(IMSB) FORCER LOGRET(’007’)

/*

CHANGE.RECON


CHANGE.RECON (for THT or REPTHT)

OO CHANGE.RECONTHTREPTHT

OP

Use a CHANGE.RECON (for THT or REPTHT) command to specify whether anadditional new time history table (THT) is created or the existing entry is replaced.

These parameters are mutually exclusive with one another and all otherCHANGE.RECON parameters and subparameters. So, to affect the time history tablewith CHANGE.RECON, enter only THT or REPTHT.

ParametersTHT | REPTHT

Mutually exclusive, optional parameters you use to specify whether anadditional new Time history table is created or the existing entry is replaced,when the current THT entry differs from the current MVS offset.

THTGenerates a new THT entry if the current MVS offset from UTC differs fromthe current THT entry.

REPTHTReplaces the current THT entry. Use this keyword only if you havepreviously changed the clock incorrectly and generated a new THT entry,then corrected the clock. This keyword can only be used if neither of thefollowing are true:

v The RECON has been updated by Version 6 DBRC (except by yourcommand)

v The RECON has been accessed by a pre-Version 6 version since yougenerated the current THT entry

Otherwise, you must use the THT keyword to create a new THT entry.

Related Reading: See “RECON Header Records” on page 56 for information onthe time history table (THT).

Example of Specifying a Replacement THT EntryIn this example, you replace the THT entry that you created after an incorrect clockchange.//CHGRECON JOB

...

//SYSIN DD *CHANGE.RECON REPTHT

/*

CHANGE.SECLOG (for OLDS)

CHANGE.RECON (for THT or REPTHT)


OO CHANGE.SECLOG OLDS(ddname)AVAILUNAVAIL

DSN(name) ERRORNORMAL

O

OSSID(name)

OP

Use a CHANGE.SECLOG (for OLDS) command to change information in RECON abouta secondary OLDS.


Required parameter you use to specify the OLDS for which the RECON recordis to be changed. Failure to specify this parameter results in an RLDS beingchanged.

AVAIL | UNAVAILMutually exclusive, optional parameters you use to change the SECOLDS toindicate its availability.

AVAILIndicates that the OLDS contains valid data and that it can be used as inputto the Log Archive utility.

UNAVAILIndicates that the OLDS contains invalid data and it should not be used asinput to the Log Archive utility.

DSN(name)Optional parameter you use to change the name of a secondary OLDS. Thename you substitute in the variable field can be up to 44 characters long.

ERROR | NORMALMutually exclusive, optional parameters you use to change the specifiedSECOLDS record to indicate whether it contains errors.

ERRORChanges the RECON record to indicate that a specified OLDS containserrors, so IMS is unable to close the OLDS properly. The OLDS must beclosed before it can be used as input to the Log Archive utility.

When you use dual logging, you use ERROR to change a specifiedSECOLDS record to indicate that it contains errors. The subsystem usesthe data in the error-free OLDS to close the OLDS that is marked ERROR.

NORMALChanges the SECOLDS record, which was previously marked as containingerrors, to indicate that the data set is now available for use as input to anylog utility. When you specify NORMAL for a secondary OLDS, the recordimmediately indicates that the next primary OLDS is no longer needed inorder to close the corresponding primary OLDS.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the OLDS for which the RECON record is to be changed.

The SSID is an eight-character string consisting of any alphanumeric charactersthat comprise a valid IMS subsystem identification name. If you do not specify



SSID, DBRC uses the default subsystem identifier in the RECON headerrecord. Use the INIT.RECON or CHANGE.RECON command to set the defaultsubsystem identifier in the RECON header record. If you have not specified adefault in the RECON header record, you must specify SSID.

Example Showing a SECOLDS ErrorIn this example, a SECOLDS that IMS online subsystem IMSA created is known tobe in error.//CHGSECLG JOB

...

//SYSIN DD *CHANGE.SECLOG OLDS(DFSOLS02) -

SSID(IMSA) ERROR/*

CHANGE.SECLOG (for RLDS)

OORLDS

CHANGE.SECLOG STARTIME(time stamp)DSN(name)

O

O

S

,

CHKPTCT( value ) S

,

CHKPTID( chkptid )

O


NORMALFILESEQ(value) GSG(gsgname)

O

O

S

,

NEWTIME( time stamp ) S

,

NEWVOL( volser )

O

O

S

,

OLDVOL( volser ) S

,


O

O3400

UNIT( unittype )S

,

VOLLIST( volser )

OP

You can use the CHANGE.SECLOG (for RLDS) command to change information in theRECON about a primary RLDS (or an SLDS that a batch subsystem created). Usethe NOTIFY.SECLOG (for RLDS) command to add a SECLOG record or to add dataset entries to an existing SECLOG record.



With the exception of the GSG name, all the information you can change resides ina data set entry of the SECLOG record. Each CHANGE.SECLOG command youissue changes only one data set entry. If the log has multiple data sets, you mustuse the DSSTART parameter to identify the data set entry to be changed. (Notethat if you are only changing the GSG you must still specify DSSTART if the log hasmore than one data set.)

If the SECLOG record represents log data that was received by an RSR trackingsite from an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,NEWVOL, OLDVOL, RUNTIMES, CHKPTID, UNIT, or VOLLIST can be specified.Log data sets received at a tracking site must be cataloged.

ParametersRLDS

Is the parameter you can use to specify that a SECLOG record is to bechanged. Since RLDS is the default, if you do not specify a record type as thefirst parameter for CHANGE.SECLOG, RLDS is assumed.

STARTIME(time stamp)Required parameter you use to specify the starting time stamp of the SECLOGrecord that is to be changed. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).









DSSTART(time stamp)Is a parameter you use to specify the starting time of the data set entry to bechanged. The DSSTART parameter is required if the SECLOG has multiple



data set entries; it is optional if the SECLOG has only one data set entry. Thetime stamp must be in standard form (see “Standard Time Stamp Format” onpage 101).


ERRORchanges the data set to indicate that it contains errors and should not beused as input to any DBRC-controlled run of a recovery utility.

NORMALchanges a data set which was previously marked as containing errors toindicate that it is now available for use as input to any recovery utility.


GSG(gsgname)Optional parameter you use to change the global service group (GSG) name inthe SECLOG record.

NEWTIME(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. If you specify NEWTIME, you must also specify OLDVOL andNEWVOL. The parameter sets NEWTIME OLDVOL NEWVOL and RUNTIMESVOLLIST are mutually exclusive.

If you specify NEWTIME, you must specify one less time stamp than thenumber of volume serial numbers specified in NEWVOL. This is because thestop time of the last volume specified in NEWVOL cannot be changed with thiscommand. (See “NOTIFY.PRILOG (for RLDS)” on page 274 to see how tospecify the stop time of the final volume.) Each time stamp is used as thevolume stop time of the corresponding volume serial number specified byNEWVOL. If not specified, the stop time of the new volume is the same as thestop time of the last-specified old volume.

Each time stamp you specify must be greater than the previous time stamp.The first time stamp in NEWTIME must be greater than or equal to the stoptime of the volume immediately preceding the changed volumes. Each timestamp must be in standard form (see “Standard Time Stamp Format” onpage 101).

NEWVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the data set. If you specify NEWVOL, you must also specifyOLDVOL (described below).

The volume serial numbers you specify in NEWVOL replace the correspondingvolume serial numbers specified in the OLDVOL parameter. You do not need tospecify the same number of volume serial numbers in NEWVOL and OLDVOL.You cannot specify a volume serial number in NEWVOL that is the same asone which already exists in the SECLOG record.


Use the NEWTIME parameter to change the time stamps as well as the serialnumbers of the volumes.



|||||

OLDVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the data set. If you specify OLDVOL, you must also specifyNEWVOL, CHKPTCT, or CHKPTID.

The volume serial numbers you specify are those of the volumes beingchanged. Each volume serial number specified in OLDVOL must match avolume serial number in the SECLOG record.


RUNTIMES(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. This parameter is provided for compatibility with previousreleases of DBRC. You should use the new parameter set, NEWTIME OLDVOLNEWVOL, to change the stop times of log volumes. If you do specifyRUNTIMES, you must also specify VOLLIST. The parameter sets, NEWTIMEOLDVOL NEWVOL and RUNTIMES VOLLIST, are mutually exclusive.

You can specify up to 255 time stamps on the RUNTIMES parameter. Eachtime stamp must be in standard form (see “Standard Time Stamp Format” onpage 101).


The first time stamp in the variable field of the RUNTIMES parameter must begreater than the time stamp specified for the STARTIME parameter. The lasttime stamp in the variable field of the RUNTIMES parameter must be equal tothe stop time of the corresponding secondary RLDS as specified in the recordbeing changed. You cannot use this command to change the stop time of thesecondary RLDS. For information about closing open recovery logs, see“NOTIFY.PRILOG (for RLDS)” on page 274.


VOLLIST(volser)Optional parameter you use to change the record of the volume serial numbersof the volumes that contain the data set. This parameter is provided forcompatibility with previous releases of DBRC. Use the new parameter setNEWTIME OLDVOL NEWVOL to change the volume serial numbers of volumesin the data set.

If you specify the VOLLIST parameter, you must also specify the RUNTIMESparameter. See the description of the RUNTIMES parameter under“Parameters” on page 140 for an explanation of how the two parametersinteract. The parameter sets, NEWTIME OLDVOL NEWVOL and RUNTIMESVOLLIST, are mutually exclusive.

Examples of Using CHANGE.SECLOG (for RLDS)Here are some examples of using the CHANGE.SECLOG (for RLDS) command.

Example of Changing Volume Serial NumbersIn this example, some volume serial numbers are changed. The example SECLOGrecord in RECON has one data set with six volumes—VOL001, VOL002, VOL003,



VOL004, VOL005, and VOL006—and a start time of 832331243299. The serialnumbers of the third and fourth volumes are replaced with three others by thefollowing command://CHGSECLG JOB

...

//SYSIN DD *CHANGE.SECLOG RLDS STARTIME(832331243299) -

OLDVOL(VOL003,VOL004) -NEWVOL(VOL007,VOL008,VOL009)

/*

Example of Changing Volume Stop TimesIn this example, STARTIME identifies the SECLOG record and DSSTART identifiesits first data set entry, of which the data set name and the stop times of threevolumes are to be changed.//CHGSECLG JOB

...

//SYSIN DD *CHANGE.SECLOG RLDS STARTIME(840541212120) -

DSSTART(840541212120) -DSN(IMS.SECLOG.SEC001.DSN) -VOLLIST(VOL001,VOL002,VOL993) -

RUNTIMES(840541212122,840541313133,840541515150)/*

CHANGE.SECLOG (for SLDS and TSLDS)

OO CHANGE.SECLOG SLDSTSLDS

STARTIME(time stamp)DSN(name)

O

O

S

,

CHKPTCT( value ) S

,

CHKPTID( chkptid )

DSSTART(time stamp)O

OERRORNORMAL

FILESEQ(value) GSG(gsgname)

S

,

NEWTIME( time stamp )

O

O

S

,

NEWVOL( volser ) S

,

OLDVOL( volser )

O

O

S

,


SSID(name) 3400UNIT( unittype )

O



O

S

,

VOLLIST( volser )

OP

You can use the CHANGE.SECLOG (for SLDS) command to change information in theRECON about a secondary SLDS for an online system. You can use theCHANGE.SECLOG (for TSLDS) command to change information in the RECON about asecondary SLDS for an RSR tracking subsystem. Use CHANGE.SECLOG (for RLDS) tochange information about an SLDS that a batch subsystem created, because DBRCconsiders such data to be an RLDS. Use the NOTIFY.SECLOG (for SLDS) commandto add a SECSLD record or to add data set entries to an existing SECSLD record.

With the exception of the GSG name, all the information you can change resides ina data set entry of the SECSLD record. Each CHANGE.SECLOG command youissue changes only one data set entry. If the log has multiple data sets, you mustuse the DSSTART parameter to identify the data set entry to be changed. (Notethat if you are only changing the GSG, you must still specify DSSTART if the loghas more than one data set.)

If the SECSLD record represents log data that was received by an RSR trackingsite from an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,NEWVOL, OLDVOL, RUNTIMES, CHKPTID, UNIT, or VOLLIST can be specified.Log data sets received at a tracking site must be cataloged.

ParametersSLDS

Required parameter you use to specify that an SECSLD record is to bechanged.

TSLDSRequired parameter you use to specify that a SECTSLDS record is to bechanged at an RSR tracking subsystem. If you do not specify SLDS or TSLDS,the default is RLDS.

STARTIME(time stamp)Required parameter you use to specify the starting time stamp of the SECSLDrecord that is to be changed. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).











DSSTART(time stamp)Is a parameter you use to specify the starting time of the data set entry to bechanged. The DSSTART parameter is required if the SECSLD or SECTSLDShas multiple data set entries. The parameter is optional if the SECSLD orSECTSLDS has only one data set entry. The time stamp must be in standardform (see “Standard Time Stamp Format” on page 101).


ERRORIs used to change the data set entry to indicate that it contains errors.

NORMALIs used to change a data set entry which was previously marked ascontaining errors to indicate that it is normal.


GSG(gsgname)Optional parameter you use to change the global service group (GSG) name inthe SECSLD record. GSG cannot be specified for SECTSLDS records.

NEWTIME(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. When you specify NEWTIME, you must also specify OLDVOLand NEWVOL. The parameter sets, NEWTIME OLDVOL NEWVOL andRUNTIMES VOLLIST, are mutually exclusive.

When you specify NEWTIME, you must specify one less time stamp than thenumber of volume serial numbers specified in NEWVOL. This is because thestop time of the last volume specified in NEWVOL cannot be changed with thiscommand. (See “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 279 to learnhow to specify the stop time of the final volume.) Each time stamp is used asthe volume stop time of the corresponding volume serial number specified byNEWVOL. If not specified, the stop time of the new volume is the same as thestop time of the last—specified old volume.

Each time stamp you specify must be greater than the previous time stamp.The first time stamp in NEWTIME must be greater than or equal to the stoptime of the volume prior to the changed volumes. Each time stamp must be instandard form (see “Standard Time Stamp Format” on page 101).



||||

NEWVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the data set. When you specify NEWVOL, you must also specifyOLDVOL.

The volume serial numbers you specify in NEWVOL replace the correspondingvolume serial numbers specified in the OLDVOL parameter. You do not need tospecify the same number of volume serial numbers in NEWVOL and OLDVOL.You cannot specify a volume serial number in NEWVOL that is the same asone that already exists in the SECSLD or SECTSLDS record.


Use the NEWTIME parameter if you want to change the time stamps as well asthe serial numbers of the volumes.

OLDVOL(volser)Optional parameter you use to change the volume serial number of one or morevolumes of the secondary SLDS or TSLDS. When you specify OLDVOL, youmust also specify NEWVOL, CHKPTCT, or CHKPTID (all described above).

The volume serial numbers you specify are those of the volumes to bechanged. Each volume serial number specified must match a volume serialnumber in the SECSLD or SECTSLDS record.


RUNTIMES(time stamp)Optional parameter you use to change the stop times of any but the last volumeof the data set. This parameter is provided for compatibility with previousreleases of DBRC. You should use the new parameter set NEWTIME OLDVOLNEWVOL to change the stop times of log volumes. If you do specifyRUNTIMES, you must also specify VOLLIST. The parameter sets, NEWTIMEOLDVOL NEWVOL and RUNTIMES VOLLIST, are mutually exclusive.

You can specify up to 255 time stamps on the RUNTIMES parameter. Eachtime stamp must be in standard form. (See “Standard Time Stamp Format” onpage 101).


The first time stamp in the variable field of the RUNTIMES parameter must begreater than the time stamp specified for the STARTIME parameter. The lasttime stamp in the variable field of the RUNTIMES parameter must be equal tothe stop time of the corresponding secondary SLDS or TSLDS as specified inthe record being changed. You cannot use this command to change the stoptime of the secondary SLDS or TSLDS. For information about closing opensystem logs, see “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 279.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the SLDS or TSLDS for which the RECON record is to be changed.

The SSID is an eight-character string consisting of any alphanumeric charactersthat describe a valid IMS subsystem identification name. If you do not specifySSID, DBRC uses the default subsystem identifier in the RECON headerrecord. Use the INIT.SECLOG or CHANGE.SECLOG command to set the default



subsystem identifier in the RECON header record. If you have not specified adefault in the RECON header record, you must specify SSID.


VOLLIST(volser)Optional parameter you use to change the record of the volume serial numbersof the volumes that contain the data set. This parameter is provided forcompatibility with previous releases of DBRC. You should use the newparameter set, NEWTIME OLDVOL NEWVOL, to change the volume serialnumbers of volumes in the data set.

If you specify the VOLLIST parameter, you must also specify the RUNTIMESparameter. See the above description of the RUNTIMES parameter for anexplanation of how the two parameters interact. The parameter sets, NEWTIMEOLDVOL NEWVOL and RUNTIMES VOLLIST, are mutually exclusive.

Examples of Using CHANGE.SECLOG (for SLDS and TSLDS)Here are some examples of using the CHANGE.SECLOG (for SLDS and TSLDS)command.

Example of Changing Volume Serial Numbers and Stop TimeIn this example, some volume serial numbers and a volume stop time of anSECSLD are changed. The example SECSLD record in RECON has six volumes(VOL001, VOL002, VOL003, VOL004, VOL005, and VOL006) and a start time of832331243299. The fourth volume has been copied to new volumes VOL007 andVOL008 with the new volume stop time 832331248325 for VOL007. The SECSLDrecord is updated with the following command://CHGPRILG JOB

...

//SYSIN DD *CHANGE.SECLOG SLDS STARTIME(832331243299) -

OLDVOL(VOL004) -NEWVOL(VOL007,VOL008) -NEWTIME(832331248325)

/*

Example of Marking the Secondary SLDS as NormalIn this example, the first and only data set of a secondary SLDS is being marked asnormal.//CHGPRILG JOB

...

//SYSIN DD *CHANGE.SECLOG SLDS STARTIME(840541212120) -

DSSTART(840541212120) NORMAL/*



CHANGE.SG

OO CHANGE.SG SGNAME(sgname) GSGNAME(gsgname)ACTIVETRACKING

LOCALNONLOCAL

NORTAOP

Use a CHANGE.SG command to change the role of a service group (SG). The role ofa service group cannot be changed while a subsystem is signed on to its globalservice group.

This command fails if RSRFEAT=NO is specified in the IMSCTRL macro.

If two SG entries are present at the time this command is issued, the other SG isassigned the complementary attributes of the SG that is named in the command.

Example:

This command changes SG1 to a tracking role:CHANGE.SG SGNAME(SG1) GSGNAME(GSG1) TRACKING

In this case, SG2 is automatically changed to an active role.

ParametersSGNAME(sgname)

Required parameter you use to specify the service group name.

GSGNAME(gsgname)Required parameter you use to specify the global service group name.

ACTIVE | TRACKINGOptional parameter you use to specify the new role of the service group. Thisparameter is sometimes referred to as the STATUS parameter.

LOCAL | NONLOCALOptional parameter you use to specify whether the service group is local ornonlocal for this set of RECONs. This parameter is sometimes referred to asthe LOCALE parameter.

NORTAOptional parameter you use to specify that you do not want to continue aremote takeover that is currently in progress. This parameter turns off takeoverindicators in the RECON. This parameter is valid for either the active or trackingsubsystem.

When you specify the NORTA parameter, you must specify the appropriateSTATUS parameter (either ACTIVE or TRACKING), and you cannot specify theLOCALE parameter (LOCAL | NONLOCAL).

If you use NORTA when no remote takeover is in progress, message DSP0144Iis issued. You should wait to receive a takeover-in-progress message beforeusing NORTA.

Example of Changing the Status of a Service GroupIn this example, the Service Group’s role or status is changed to ACTIVE.

CHANGE.SG


//CHGSG JOB...

//SYSIN DD *CHANGE.SG SGNAME() GSGNAME(GSG1) ACTIVE/*

CHANGE.SUBSYS

OO CHANGE.SUBSYSALLSSID(name)

BACKIRLM(name)NOBACKUP

IRLMID(name) NORMALABNORMAL

O

OSTARTRCVENDRECOV

TRACKINGOP

Use a CHANGE.SUBSYS command to modify information that is contained in asubsystem record in RECON.

ParametersSSID(name) | ALL

Required parameter you use to specify the subsystem you are using. The SSIDis an eight-character string consisting of any alphanumeric characters thatcomprise a valid MVS or IMS subsystem identification name. If you specify ALL,the requested processing is done for every subsystem that communicates withthe specified Internal Resource Lock Manager (IRLM).

BACKIRLM(name) | NOBACKUPMutually exclusive, optional parameters you use to change the specification ofthe alternate subsystem.

BACKIRLMAdds an alternate subsystem IRLM ID to the active subsystem record.When you specify BACKIRLM, you must also specify IRLMID. DBRClocates the specified subsystem record and adds or changes the IRLM IDof the alternate subsystem.

NOBACKUPDeletes the IRLM ID of the alternate subsystem from the active subsystemrecord. This also resets the flags in the subsystem record to indicate thatthe alternate subsystem is signed on. This command might be requiredprior to restarting the alternate subsystem.

Restriction: You cannot use NORMAL or ABNORMAL, or STARTRCV orENDRECOV with this parameter.

IRLMID(name)Optional parameter you use to specify the name of the IRLM with which thesubsystem is communicating. The IRLMID is a five-character string consisting ofany alphanumeric characters.

Restriction: You cannot change the IRLM ID. Specify the IRLM ID in order tochange processing mode of a subsystem.

CHANGE.SG


NORMAL | ABNORMALMutually exclusive, optional parameters you use to specify the status of thesubsystem.

NORMALSpecifies that normal processing is to continue for the subsystem.

ABNORMALIndicates that the subsystem has abnormally ended. When ABNORMAL isspecified, DBRC does the following:

v Removes authorization for any databases that have not been updatedbut are authorized for the specified subsystem

v Flags the identified subsystem entry as having been abnormally ended

v Turns off the recovery-processing-started flag

v If the subsystem is batch and no databases were updated, then thesubsystem record is deleted.

Restriction: If you specify STARTRCV or ENDRECOV, you cannot specifyABNORMAL.

STARTRCV | ENDRECOVMutually exclusive, optional parameters you use to specify whether a signonrecovery has completed successfully.

STARTRCVIndicates a signon recovery start.

ENDRECOVremoves authorization for all databases that the specified subsystemauthorized.

If you want to delete all database authorizations from a subsystem, you mustissue the CHANGE.SUBSYS STARTRCV command and then issue theCHANGE.SUBSYS ENDRECOV command. These two commands simulate thesignon recovery start and signon recovery complete calls.

Recommendation: Do not use this sequence of commands unless anabnormal end occurred. Otherwise, you remove authorization for the databasesthat an active subsystem is currently using.

If, after using STARTRCV | ENDRECOV and DELETE.SUBSYS commands,subsystem information is still associated with the database, a CHANGE.DBcommand with the NOBACK parameter is required in order to clear theremaining subsystem ID from the database record.

TRACKINGSpecifies that information about the RSR tracking subsystem is to be changed.

Attention: If you specify TRACKING, do not specify STARTRCV orENDRECOV.

Example of Identifying the IRLMIn this example, IRLMID identifies the IRLM that is communicating with thesubsystem identified in the SSID parameter. In addition, ABNORMAL indicates thatthis subsystem abnormally ended.

CHANGE.SUBSYS


//CHGSBSYS JOB

...

//SYSIN DD *CHANGE.SUBSYS IRLMID(IRLM2) SSID(ISM34) ABNORMAL

/*

CHANGE.UIC

OO CHANGE.UIC DBD(name) DDN(name)AREA(name)

RECTIME(time stamp) UDATA('string') OP

Use a CHANGE.UIC command to modify information in the image copy record inRECON that corresponds to a nonstandard image copy data set.

ParametersDBD(name)

Required parameter you use to identify the database name of the DBDS forwhich a nonstandard image copy data set exists.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the name of theDBDS or area for which the nonstandard image copy data set exists.

RECTIME(time stamp)Required parameter you use to identify the specific image copy record of thenonstandard image copy data set that is to be modified. Use the time stampwith an adjacent asterisk (*) in a listing of the IMAGE record. The time stampmust be in standard form (see “Standard Time Stamp Format” on page 101).

UDATA('string')Required parameter you use to change the user data in the identified imagecopy record. string can be up to 80 characters and must appear in singlequotation marks.

Example of Changing the Nonstandard ICDSN in RECONIn this example, information in RECON about the nonstandard image copy data setidentified by the RECTIME parameter is to be changed. The UDATA parameterspecifies the new information that is to be recorded for the specified image copydata set.//CHGUIC JOB

...

//SYSIN DD *CHANGE.UIC DBD(DBDKSDS1) AREA(AREA003) -

RECTIME(840651010100) -UDATA('DUMP OF VOLUME VOL001 AT 840651010100')

/*

CHANGE.SUBSYS


Chapter 10. DELETE Commands

DELETE.ADS

OO DELETE.ADS ADDN(name) AREA(name) DBD(name) OP

Use a DELETE.ADS command to delete an ADS from its associated area in theRECON record structure. An area can consist of a maximum of seven ADSs. TheADS that is to be deleted must have been registered by an INIT.ADS command.

The DELETE.ADS command fails if you issue it while the area is authorized and theADS is in AVAILABLE status. The command can be used if the ADS is inUNAVAILABLE status, provided that the ADS Create utility is not running.


Required parameter you use to identify the area name of the ADS to bedeleted.

AREA(name)Required parameter you use to identify the name of the area that contains theADS to be deleted.

DBD(name)Required parameter you use to identify the database name of the area that is tobe deleted.

Example of Deleting an ADS RecordIn this example an ADS record is deleted from RECON for the DEDB area that isidentified by the DBD, AREA, and ADDN parameters.//DELADS JOB ('LEOPARD,IMS'),'LEOPARD',REGION=880K,

...

//SYSIN DD *DELETE.ADS DBD(DBD00001) AREA(AREA0001) -

ADDN(AREA0002)/*

DELETE.ALLOC

OO DELETE.ALLOC DBD(name) DDN(name)AREA(name)

RECTIME(timestamp) OP

Use a DELETE.ALLOC command to delete from RECON an allocation record that isrelated to a specified DBDS or DEDB area. An allocation record can be deletedonly when it contains a deallocation time or when its associated log has a stoptime. Except for deleting allocation records that precede the oldest image copy dataset for a DBDS or DEDB area, deleting an allocation record should be done with


caution, and is not normally required. Deleting an allocation record that represents aperiod of time during which you changed the specified DBDS or area can cause afuture recovery to be incorrect.

ParametersDBD(name)

Required parameter you use to identify the database name of the DBDS orarea for which the allocation record is to be deleted.

DDN(name) | AREA(name)Mutually exclusive, optional parameters you use to identify the data set ddnameof the DBDS or DEDB area for which the allocation record is to be deleted.

RECTIME(timestamp)Required parameter you use to identify the specific allocation record to bedeleted for a specified DBDS or DEDB area. Use the time stamp with anadjacent asterisk (*) in a listing of the ALLOC record. The time stamp must bein standard form (see “Standard Time Stamp Format” on page 101).

Example of Deleting an Allocation RecordIn this example, an allocation record is deleted from RECON for the DBDS that isidentified by the DBD and DDN parameters. The RECTIME parameter identifies thespecific allocation record that is to be deleted.//DELALLOC JOB

...

//SYSIN DD *DELETE.ALLOC DBD(DBDKSDS1) DDN(DDNKSDS1) -

RECTIME(840231102234)/*

DELETE.BKOUT

OO DELETE.BKOUT SSID(name) OP

Use a DELETE.BKOUT command to delete backout records from the RECON.

Use this command, for example, following the successful restore of a recent imagecopy. The backout information held in RECON at the time of the copy ismeaningless, but DBRC is not aware of this fact, and DBRC does not delete thebackout records automatically.

Attention: Use the DELETE.BKOUT command with extreme caution. It deletes allbackout information for a subsystem from the RECON; this is information thatDBRC uses to help IMS maintain database integrity.


Required parameter you use to identify the subsystem for which a backoutrecord is to be deleted. The subsystem name is an eight-character,

DELETE.ALLOC


alphanumeric string that represents any valid subsystem. You can specify onesubsystem each time you issue the command.

For each database entry in the record that is marked as backout required, thebackout count in its associated database header record for this subsystem(SSID) is reduced by one. If this results in a zero backout count for this SSID,the SSID entry is removed from the database header record.

Example of Using the DELETE.BKOUT CommandThis example uses the DELETE.BKOUT command to backout subsystem IMS3.//DELBKOUT JOB

...

//SYSIN DD *DELETE.BKOUT SSID(IMS3)

/*

DELETE.CA

OO DELETE.CA GRPNAME(name) RECTIME(timestamp) OP

Use a DELETE.CA command to delete from RECON a change accumulation runrecord for a specified CA group.


Required parameter you use to specify the CA group. The CA run record that isto be deleted is a member of this CA group.

RECTIME(time stamp)Required parameter you use to specify the change accumulation run record thatis to be deleted.

Use the RECTIME marked with an asterisk (*) from the listing of the CA record.The timestamp must be in standard form (see “Standard Time Stamp Format”on page 101).

Example of Deleting a Run RecordIn this example, a run record is deleted from RECON for the CA group identified bythe GRPNAME parameter. The RECTIME parameter identifies the record to bedeleted.//DELCA JOB

...

//SYSIN DD *DELETE.CA GRPNAME(CAGRP1) RECTIME(821220909540)

/*

DELETE.BKOUT

Chapter 10. DELETE Commands 173

DELETE.CAGRP

OO DELETE.CAGRP GRPNAME(name) OP

Use a DELETE.CAGRP command to delete a CA group record and all associated CArun records from RECON.


Required parameter you use to specify the name of the CA group whoserecords that are to be deleted.

Example of Deleting CA Group RecordsIn this example, CA group records are deleted from RECON. The CA group forwhich the record is being deleted is identified by the GRPNAME parameter.//DELCAGRP JOB

...

//SYSIN DD *DELETE.CAGRP GRPNAME(CAGRP2)

/*

DELETE.DB

OO DELETE.DB DBD(name) OP

Use a DELETE.DB command to delete from RECON a database record and all itsassociated DBDS records. If any subsystem is authorized to use the specifieddatabase, the command fails and none of the RECON records are deleted.

Restriction for HALDBs: You must use the HALDB Partition Definition utility toupdate or delete information about HALDBs in the RECON data set. The DELETE.DBcommand cannot be used to delete a HALDB master or partition.

ParametersDBD(name)

Required parameter you use to identify the name of the database whoserecords are to be deleted.

All database, DBDS, allocation, image copy, recovery, and reorganizationrecords that have the same database name as name are deleted. In addition,all CA group and DBDS group records are scanned in order to delete anyentries for which the corresponding DBDS records have been deleted. All logallocation records are also scanned in order to delete any entries in theallocation list for which the corresponding DBDS records have been deleted.

DELETE.CAGRP


|||

Example of Deleting Records from RECONIn this example, records are deleted from RECON for the database and itscorresponding DBDSs identified by the DBD parameter.//DELDB JOB

...

//SYSIN DD *DELETE.DB DBD(THISDB)

/*

DELETE.DBDS

OO DELETE.DBDS DBD(name) DDN(name)AREA(name)

OP

Use a DELETE.DBDS command to delete from RECON all records that are related toa specified DBDS or DEDB area. If the DBDS for which the records are to bedeleted belongs to a CA group or to a DBDS group, its name is removed from thegroup record. The DELETE.DBDS command fails if the DL/I database or Fast PathDEDB area is in use.

Restriction for HALDBs: You must use the HALDB Partition Definition utility toupdate or delete information about HALDBs in the RECON data set. TheDELETE.DBDS command cannot be used to delete any DBDSs of a HALDB partition.

ParametersDBD(name)

Required parameter you use to specify the database name of the DBDS orDEDB area for which all records to be deleted.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to specify the ddname of theDBDS or area for which all records are to be deleted from RECON.

Example of Deleting Records for the DBDS

In this example, records are deleted from RECON for the DBDS identified by theDBD and DDN parameters.//DELDBDS JOB

...

//SYSIN DD *DELETE.DBDS DBD(DBDESDSA) DDN(DDNESDSA)

/*

DELETE.DBDSGRP

OO DELETE.DBDSGRP GRPNAME(name) OP

DELETE.DB


|||

Use a DELETE.DBDSGRP command to delete the record of a specified DBDS groupfrom RECON.


Required parameter you use to specify the name of the DBDS group that isbeing deleted. The specified name must be that of a group that is identified inRECON.

Example of Deleting a DBDS Group RecordIn this example, a DBDS group record is deleted from RECON.//DELDBDGP JOB

...

//SYSIN DD *DELETE.DBDSGRP GRPNAME(DBDSGRP1)

/*

DELETE.GSG

OO DELETE.GSG GSGNAME(gsgname) OP

Use a DELETE.GSG command to delete a global service group record from theRECON. The GSG must not have any subsystem assigned to it.

Databases assigned to this GSG are reset to uncovered status as part of theprocessing of the DELETE.GSG command. The GSG names and log tokens of allRECON log records that are associated with this GSG are reset.


ParametersGSGNAME(gsgname)

Required parameter you use to specify the name of the global service group tobe deleted.

Example of Deleting a Global Service Group RecordIn this example, a global service group record is deleted from RECON.//DELDBDGP JOB

...

//SYSIN DD *DELETE.GSG GSGNAME(GSGNM1)

/*

DELETE.DBDSGRP


DELETE.IC

OO DELETE.IC DBD(name) DDN(name)AREA(name)

RECTIME(timestamp) ICDSN2(name) OP

Use a DELETE.IC command to delete an image copy record or the information abouta second image copy data set. If you specify the ICDSN2 parameter, only theinformation about a second image copy data set is deleted; otherwise, both theentire image copy record and the information about the second image copy data setare deleted.

ParametersDBD(name)

Required parameter you use to identify the image copy record to be deleted.name is the database name of the DBDS or DEDB area to which it is related.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the image copyrecord to be deleted. name is the name of the DBDS or DEDB area to which itis related.

RECTIME(timestamp)Required parameter you use to identify the specific image copy record that is tobe deleted. Use the RUN time marked with an asterisk (*) in a listing of theIMAGE record. The time stamp must be in standard form (see “Standard TimeStamp Format” on page 101).

ICDSN2(name)Optional parameter you use to specify the name of a duplicate image copy dataset for which information is to be deleted from an image copy record. (Therecord of the first image copy data set remains in RECON.)

Example of Deleting Information from an Image Copy RecordIn this example, information about a duplicate image copy data set is deleted froman image copy record in RECON. The parameters DBD, AREA, ICDSN2, andRECTIME identify the information to be deleted. The asterisk (*) in the ICDSN2parameter is to be expanded by DBRC according to the default-naming conventionfor image copy data sets.//DELIC JOB

...

//SYSIN DD *DELETE.IC DBD(DBDKSDS1) AREA(AREA006) -

RECTIME(841231223221) ICDSN2(IMS.*.ICDSN5)/*

DELETE.LOG (for OLDS)

OO DELETE.LOG OLDS(ddname)INTERIM LASTCLOS SSID(name)

OP

DELETE.IC


Use this command to delete a data set entry from an OLDS record.


Required parameter you use to specify the ddname of the primary OLDS.DBRC deletes the RECON records of the primary and secondary OLDS for thespecified subsystem with the specified ddname. You can delete the record of anOLDS only if the OLDS has been archived.

INTERIMOptional parameter you use to specify that an interim OLDS record is to bedeleted.

LASTCLOSOptional parameter you use to specify that the OLDS specified in the OLDSparameter is the last OLDS in the PRIOLDS record and should be deleted. Usethis parameter with caution. Normally, the last OLDS in the PRIOLDS record isthe last OLDS that was closed, and you should not delete it. Close the firstOLDS in a subsequent restart if the first OLDS is empty because of an error.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the log data set for which the RECON record is to be deleted.

The SSID is an eight-character string of any alphanumeric characters thatcomprise a valid IMS subsystem identification name. If you do not specify SSID,DBRC uses the default subsystem identifier in the RECON header record. Usethe INIT.RECON or CHANGE.RECON command to set the default subsystemidentifier in the RECON header record. If you have not set a default in theRECON header record, you must specify SSID.

Example of Deleting an Interim OLDS RecordIn this example, an interim OLDS record is deleted from RECON.//DELLOG JOB

...

//SYSIN DD *DELETE.LOG SSID(IMSA) OLDS(DFSOLP03) -

INTERIM/*

DELETE.LOG (for RLDS and SLDS)

OO DELETE.LOGINACTIVE

STARTIME(timestamp)DSN(name)

INTERIMTOTIME(timestamp)

LISTDLNOLISTDL

TRACKINGOP

With this command you can delete the following records:

v A PRILOG family of records

v One data set entry from a PRILOG family

DELETE.LOG (for OLDS)


v Some or all inactive PRILOG families

v SLDSs produced by RSR tracking subsystems (TPSLD, TSSLD, TIPSL TISSL)

Use this command to prevent the PRILOG records from exceeding the maximumRECON record size.

You can also delete records of SLDSs created by RSR tracking IMS subsystems. Inaddition, you can delete single data set entries from RLDS and SLDS records.

ParametersINACTIVE | STARTIME(timestamp) | TOTIME(timestamp)

Mutually exclusive, optional parameters you use to specify the records that areto be deleted.

For a log to be considered inactive, all of the following conditions must be met:

v The log does not contain any DBDS change records more recent than theoldest image copy data set that is known to DBRC (empty LOGALL record).

v The log exceeds the log retention period specified in the INIT.RECON orCHANGE.RECON command.

v The log has either been terminated (nonzero stop time) or has the ERRORflag in the PRILOG or SECLOG record set on.

INACTIVEDeletes an inactive PRILOG and its associated log records.

INACTIVE does not delete PRILOG and SECLOG records for logs that donot satisfy all three conditions. Most logs satisfy the conditions. UseSTARTIME(timestamp) for those logs that do not satisfy all three conditions.

Active PRILOG records are also examined to determine whether theyshould be compressed, and to delete any inactive data set entries in therecords. A data set entry is defined as inactive if all of the following threeconditions are met:

v It is older than the log retention period specified in the INIT.RECON orCHANGE.RECON command.

v It is older than the earliest log volume required for recovery of any DBthat is registered in the RECON.

v It is older than the earliest checkpoint that is required for system restart.

See “Deleting Log Records” on page 84 and “Getting PRILOG Compressionto Work” on page 82 for more information about deleting log records andcompression.

STARTIMESpecifies the START time of the log records to be deleted. Use the timestamp with an adjacent asterisk (*) in a list of the PRILOG or SECLOGrecord.

DSN(name)Optional parameter you use to specify the data set name of a particularlog data set whose entry in the RLDS or SLDS record is to be deleted.The specified data set name can exist in one or more of the primaryand secondary RLDS and SLDS records; all entries having the samelog sequence number range as the specified data set are deleted.



If the data set to be deleted is the last in the log record and if it isclosed, the log stop time is set to zeros to indicate that a data set gapexists at the end of the record.

STARTIME is required with DSN. If DSN is not specified, the entireRLDS or SLDS record is deleted. You cannot specify TOTIME,INTERIM, or TRACKING with DSN.

Only log data at the tracking site is eligible for deletion.

INTERIMOptional parameter you use to specify the interim RLDS record andinterim SLDS record to be deleted.

Restrictions:

v You cannot specify INTERIM if DSN is specified.

v STARTIME must be specified in conjunction with INTERIM.

TOTIMESpecifies that the records of all inactive RLDSs and SLDSs that have astart time older than the time specified with the TOTIME parameter deleted.You must specify a time that is less than the current time, minus the logretention period. The time stamp must be in standard form (see “StandardTime Stamp Format” on page 101). If the PRILOG is older than TOTIME butit is still active, it will be examined to delete all of the inactive data setentries in the record.

Restriction:

You cannot specify TOTIME if DSN is specified.

LISTDL | NOLISTDLMutually exclusive, optional parameters you use to specify whether the namesof the data sets deleted from the RECON are to be listed in the job output.These parameters override the default, which is set by the INIT.RECON orCHANGE.RECON command.

LISTDLSpecifies that the names of deleted data sets are to be listed in the joboutput.

NOLISTDLSpecifies that the names of deleted data sets are not to be listed in the joboutput.

The default is the value specified by the INIT.RECON or CHANGE.RECON command.

TRACKINGOptional parameter you use to specify that only records of SLDSs created byRSR tracking subsystems are to be deleted. These are the TPSLD, TSSLD,TIPSL, and TISSL records. This parameter must be specified with SSID,STARTIME, and TOTIME.

If TRACKING is specified, neither DSN nor INACTIVE can be specified.

If INTERIM is specified, only the TIPSL and TISSL records are deleted.

Example of Deleting the Record of an RLDS and SLDSIn this example, the interim RLDS and interim SLDS records that are identified bythe STARTIME parameter are deleted from RECON.



//DELLOG JOB

...

//SYSIN DD *DELETE.LOG STARTIME(840541212120)-

INTERIM/*

DELETE.RECOV

OO DELETE.RECOV DBD(name) DDN(name)AREA(name)


Use a DELETE.RECOV command to delete a specified recovery run record fromRECON. Specifying DELETE.RECOV for the recovery run record of a timestamprecovery implies that the DBDS or DEDB area that is related to the record has beenrestored. It has been restored to the state it was in just before the timestamprecovery that created the recovery run record that you are deleting. Such a deletionalso implies that no allocations of the DBDS or DEDB area took place thatgenerated change records on IMS log data sets after the timestamp recoveryoccurred.

ParametersDBD(name)

Required parameter you use to identify the recovery record to be deleted; nameis the database name of the related DBDS or DEDB area.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the recovery recordto be deleted; name is the name of the related DBDS or DEDB area.

RECTIME(timestamp)Required parameter you use to specify the time stamp of the recovery runrecord to be deleted. Use the time stamp with an adjacent asterisk (*) in a list ofthe RECOV record. The time stamp must be in standard form (see “StandardTime Stamp Format” on page 101).

Example of Deleting a Recovery Record of the DBDSThis example shows the deletion from RECON of the record of a recovery of theDBDS identified by the DBD and DDN parameters. The record to be deleted isidentified by the RECTIME parameter.//DELRECOV JOB

...

//SYSIN DD *DELETE.RECOV DBD(DBDESDSB) DDN(DDNESDSB) -

RECTIME(930891919190)/*



DELETE.REORG

OO DELETE.REORG DBD(name) DDN(name) RECTIME(timestamp) OP

Use a DELETE.REORG command to delete a database reorganization record for aspecified DBDS from RECON. When you specify the DELETE.REORG command, youare implying that the DBDS and the IMS DBD library have been restored to thestate they were in before the reorganization that created the databasereorganization record. By using the DELETE.REORG command, you are also implyingthat no allocations of the reorganized database that generated records in IMS logdata sets took place.

ParametersDBD(name)

Required parameter you use to identify the reorganization record to be deleted;name is the database name of the related DBDS.

DDN(name)Required parameter you use to identify the reorganization record to be deleted;name is the data set ddname of the related DBDS.

RECTIME(timestamp)Required parameter you use to identify the specific database reorganizationrecord to be deleted. Use the time stamp with an adjacent asterisk (*) in a list ofthe REORG record. The time stamp must be in standard form (see “StandardTime Stamp Format” on page 101).

Example of Deleting a Reorganization Record of a DBDSIn this example, a record of the reorganization of a DBDS is deleted from RECON.//DELREORG JOB

...

//SYSIN DD *DELETE.REORG DBD(DBDESDSB) DDN(DDNESDSB) -

RECTIME(840231102234)/*

DELETE.SG

OO DELETE.SG GSGNAME(gsgname) SGNAME(sgname) OP

Use a DELETE.SG command to delete a service group entry within a global servicegroup record in the RECON. The service group cannot be deleted while asubsystem is signed on to the global service group.


DELETE.REORG



Required parameter you use to specify the name of the global service group towhich the service group belongs.

SGNAME(sgname)Required parameter you use to specify the name of the service group to bedeleted.

Example of Deleting a Global Service Group RecordIn this example, a service group entry within a global service group record isdeleted from RECON.//DELDBDGP JOB

...

//SYSIN DD *DELETE.SG GSGNAME(GSGNM1) SGNAME(SGNM1)

/*

DELETE.SUBSYS

OO DELETE.SUBSYS SSID(name) OP

Use a DELETE.SUBSYS command to delete the subsystem entry in RECON after it isverified that the specified subsystem is not authorized to use any database.

For more information about deleting subsystem entries, see “CHANGE.SUBSYS” onpage 168.

To close the subsystem log, issue the NOTIFY.PRILOG command, and then issue theDELETE.SUBSYS command.


Required parameter you use to identify the subsystem for which the entry isdeleted from RECON if no database is authorized by the subsystem.

When you issue this command online, the IMS control region under which thecommand was issued cannot be the subsystem being deleted.

Example of Deleting a Specified SUBSYS RecordIn this example, the specified SUBSYS record is deleted if no database isauthorized by the subsystem.//DELSBSYS JOB

...

//SYSIN DD *DELETE.SUBSYS SSID(IMS34)

/*

DELETE.SG


DELETE.UIC

OO DELETE.UIC DBD(name) DDN(name)AREA(name)


Use a DELETE.UIC command to delete the record of a nonstandard image copy dataset from RECON.

ParametersDBD(name)

Required parameter you use to identify the nonstandard image copy record tobe deleted; name is the database name of the related DBDS or area.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the nonstandardimage copy record to be deleted; name is the name of the related DBDS orDEDB area.

RECTIME(timestamp)Required parameter you use to specify the timestamp of the nonstandard imagecopy record to be deleted. Use the timestamp with an adjacent asterisk (*) in alist of the IMAGE record. The timestamp must be in standard form (see“Standard Time Stamp Format” on page 101).

Example of Deleting a Nonstandard Image Copy Data Set RecordThis example shows the deletion of a record of a nonstandard image copy data setfrom RECON.

//DELUIC JOB

...

//SYSIN DD *DELETE.UIC DBD(DBDESDSB) AREA(AREAESD2) -

RECTIME(840871212120)/*

DELETE.UIC


Chapter 11. GENJCL Commands

GENJCL.ARCHIVE

OO GENJCL.ARCHIVE S

ALL,

OLDS( ddname )SLDSTOTIME(timestamp)

S

,

DEFAULTS( member )

O

OJCLOUT

JCLOUT( ddname )JCLPDS

JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST

LISTO

OMAXOLDS(n) MEMBER(member) SSID(name)

O

O

S

,

USERKEYS( ( %key1 , 'value' ) )%key2

OP

Use the GENJCL.ARCHIVE command to generate the JCL and utility controlstatements that run the Log Archive utility. For the IBM-supplied skeletal JCLexecution member that is used by GENJCL.ARCHIVE, see “Using the Commands toGenerate JCL and User-Defined Output” on page 309.

ParametersALL | OLDS(ddname) | SLDS

Mutually exclusive, required parameters you use to specify which OLDS isbeing archived or to request the archive of tracking SLDSs.

Attention:

Ensure that the RSR tracking IMS subsystem has completed the processing ofthe SLDS before you run a batch archive. If a tracking IMS process (such asonline forward recovery (OFR), log truncation, or catch up) needs to read froman SLDS that is being processed by batch archive, allocation of the SLDS bythe tracking IMS fails, and the tracking IMS might terminate abnormally.

ALLGenerates JCL to archive all OLDSs that have not been archived. Amultiple-step job can be produced if either of the following conditions exist:

v The specified subsystem has non-contiguous OLDSs.

v A force-EOV condition occurred after you entered /DBRECOVERY .

OLDSSpecifies the ddname of the primary OLDS you are archiving.

SLDSGenerates JCL to archive all tracking SLDSs which are associated with thespecified subsystem that have not been archived. A multiple-step job can be


produced if the PRISLD or SECSLD (or both) have non-contiguous data setentries that need to be archived, or if they have more unarchived DSNsthan the specified MAXOLDS value.

TOTIME(timestamp)Specifies that only tracking log data sets with start times older than orequal to timestamp are to be archived. This parameter is optional and isvalid only when SLDS is also specified. Otherwise it is ignored. Thetime stamp must be in standard format.

DEFAULTS(member)Optional parameter you use to specify up to 10 skeletal JCL default members tobe used when generating JCL. Default members are searched to resolvekeywords in the order in which the members are specified on this parameter.

If a keyword is assigned a value in both the DEFAULTS and USERKEYSparameters, the value specified in USERKEYS is used.

JCLOUT(JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with thisddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set (PDS) as long asit is not the same data set used for the default JCLOUT.

JCLPDS(JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to beused for input when generating JCL. The data set that is specified by ddname.A JCL DD statement with this ddname must be included in the job stepcontaining the GENJCL command.

JOB | JOB(member) | NOJOBMutually exclusive, optional parameters you use to specify whether to producethe job statement in the generated JCL.

JOBSpecifies that the job statement is to be produced. When JOB is specifiedwithout a member name, the IBM-supplied execution member JOBJCLproduces the job statement. When JOB(member) is specified, the specifiedexecution member produces the job statement.

NOJOBSpecifies that the job statement is not produced in the generated JCL.

LIST | NOLISTMutually exclusive, optional parameters you use to specify whether to print thegenerated JCL using the SYSPRINT data set.

LISTPrints the generated JCL.

NOLISTSuppresses printing of the generated JCL.

MAXOLDS(n)Optional parameter you use to specify the maximum number of OLDSs orSLDSs to be archived in a single job. n can be any decimal number from 1 to100.

If MAXOLDS is specified and more OLDSs need archiving than are specified inn, multiple jobs are generated. Each generated job archives no more than nOLDSs.

GENJCL.ARCHIVE


This parameter functions somewhat differently for SLDSs than for OLDSs. IfMAXOLDS is specified and more SLDSs need archiving than are specified in n,multiple job steps are generated. Each generated job step archives no morethan n SLDSs.

MAXOLDS applies only to the primary data sets. If dual logging is in effect,each job can have DD statements for the secondary and primary data sets (thatis, DD statements for 2 x n data sets).

If you do not specify MAXOLDS, a single job is generated for all OLDSs orSLDSs.

MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember to be used. If this parameter is not specified, the IBM-suppliedexecution member for the GENJCL.ARCHIVE command is used. For a descriptionof this execution member, see “Using the Commands to Generate JCL andUser-Defined Output” on page 309.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the OLDSs or SLDSs that are to be archived.

The SSID is an eight-character string of any alphanumeric characters thatcomprise a valid IMS subsystem identification name. If you do not specify SSID,DBRC uses the default subsystem identifier in the RECON header record. Usethe INIT.RECON or CHANGE.RECON command to set the default system identifier inthe RECON header record. If you have not set a default in the RECON headerrecord, you must specify SSID.

USERKEYS(%key1,'value' | %key2)Optional parameter you use to set the value of keywords you have defined. Upto 32 keywords can be specified.

%key1User-defined keyword being assigned a value. The maximum length of thekeyword is eight characters, including the percent sign. The first characterafter the percent sign must be alphabetic (A-Z). The remaining charactersmust be alphanumeric (A-Z, 0-9).

'value'Value assigned to the user-defined keyword when it is encountered. valuecan be any character string enclosed in single quotes. The maximum lengthof value is 132 characters (excluding the quotes). If value contains a quote,use two single quotes. value can be a null string (''). If value is a timestamp, it can be zero.

%key2Any simple keyword that was previously assigned a value, includingDBRC-defined and user-defined keywords.

Any keyword can be assigned a value with the USERKEYS parameter.However, if you assign a value to DBRC-defined keywords, the value is ignored.DBRC-defined keywords are shown in “Understanding Simple Keywords” onpage 311.

If a keyword is assigned a value in both the USERKEYS and DEFAULTSparameter, the value specified in USERKEYS is used.

GENJCL.ARCHIVE

Chapter 11. GENJCL Commands 187

Examples of Running the Log Archive UtilityHere are some examples of using the GENJCL.ARCHIVE command.

Example with Primary OLDS Defined by the OLDS ParameterIn this example, a GENJCL.ARCHIVE command generates the JCL and controlstatements required to run the Log Archive utility for the primary OLDSs that aredefined by the OLDS parameter. When this command is issued, the PRIOLDSrecord in RECON is updated to indicate that an archive has been scheduled for theOLDS. Default skeletal member ARCHJCL is taken from the data set that isidentified in the JCLPDS DD statement. The generated JCL goes to the data setidentified in the JCLOUT DD statement. Skeletal member JOBJCL produces a jobstatement.//GENJAR JOB//JCLOUT DD . . .//JCLPDS DD . . .

...

//SYSIN DD *GENJCL.ARCHIVE SSID(IMSA) -

OLDS(DFSOLP01,DFSOLP02)/*

As part of the archive process, the PRIOLDS record in RECON is updated toindicate that the archive has completed. RECON is updated with the PRISLD andSECSLD records that identify the created SLDSs. In addition, RECON is updatedwith the PRILOG and SECLOG records that identify the created RLDSs.

Example of the SSID IMSB OLDS Parameter Defining the PrimaryOLDSIn this example, a GENJCL.ARCHIVE command generates JCL to archive the primaryOLDS that is defined in the OLDS parameter for SSID IMSB. JCL executionmember ARCHJCLA is taken from the JCLPDS data set that is identified in thePDSJCL DD statement. The generated JCL goes to SYSOUT=A, which is identifiedin the OUTJCL DD statement. Skeletal member JOBJCL produces a job statement.//GENJAR1 JOB//OUTJCL DD SYSOUT=A//PDSJCL DD DSN=dsname//SYSIN DD *GENJCL.ARCHIVE SSID(IMSB) OLDS(DFSOLP01) MEMBER(ARCHJCLA) -JCLPDS(PDSJCL) JCLOUT(OUTJCL)

Example for Unarchived Default Subsystem OLDSsIn this example, the GENJCL.ARCHIVE command generates JCL and controlstatements to archive all unarchived OLDSs for the default subsystem ID.

JCL execution member ARCHJCLB is taken from the JCLPDS data set that isidentified by the JCLPDS DD statement. Member DEFARC01 from the JCLPDSdata set (identified in the JCLPDS DD statement) contains values to resolveuser-defined keywords in ARCHJCLB. %SSPACE is a user-defined keyword inmember ARCHJCLB which is assigned a value of 'CYL,1'. %RSPACE is a user-definedkeyword in member ARCHJCLB, which is assigned a value of 'TRK,4'.

The values specified in the USERKEYS parameter for a keyword overrides thevalues found in the DEFAULTS member. JOB1 is a member in the JCLPDS thatproduces a job statement.

GENJCL.ARCHIVE


//GENJAR2 JOB//JCLPDS DD . . .//JCLOUT DD . . .//SYSIN DD *GENJCL.ARCHIVE MEMBER(ARCHJCLB) DEFAULTS(DEFARC01) -USERKEYS((%SSPACE,'CYL,1'),(%RSPACE,'TRK,4')) JOB(JOB1)

GENJCL.CA

OO GENJCL.CA GRPNAME(name)

S

,

DEFAULTS( member )

JCLOUTJCLOUT( ddname )

O

OJCLPDS

JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST

LIST MEMBER(member)O

ONODEFLT 3400

UNIT( unittype )

O

O

S

,


S

,

VOLLIST( volser )

O

OVOLNUM(value)CATIME(time)

OP

Use the GENJCL.CA command to generate the JCL and utility control statements torun the Change Accumulation utility for a specified CA group. For information on theIBM-supplied skeletal JCL execution member used by GENJCL.CA, see “Using theCommands to Generate JCL and User-Defined Output” on page 309.


Required parameter you use to specify the name of the CA group for which youare running the Change Accumulation utility.

DEFAULTS (member)Optional parameter you use to specify the names of up to 10 skeletal JCLdefault members that are used when generating JCL. Default members aresearched to resolve keywords in the order in which the members are specifiedon this parameter.


JCLOUT (JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with this

GENJCL.ARCHIVE


ddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set as, but only if it isnot the same data set that is used for the default, JCLOUT.

JCLPDS(JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to beused for input when generating JCL. The data set is specified by ddname. AJCL DD statement with this ddname must be included in the job step containingthe GENJCL command.

JOB | JOB(member) | NOJOBMutually exclusive, optional parameters you use to specify whether to producethe first job statement in the generated JCL.

JOBSpecifies that the job statement is to be produced. When JOB is specifiedwithout a member name, the IBM-supplied execution member JOBJCLproduces the job statement.

JOB(member)Specified execution member produces the job statement.

NOJOBSpecifies that the job statement is not produced in the generated JCL.

LIST | NOLISTMutually exclusive, optional parameters you use to specify whether you wantthe generated JCL to be written to the SYSPRINT data set.


NOLISTSuppresses the printing of the generated JCL.

MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember that is to be used. If this parameter is not specified, the defaultspecified for the CA group is used. For a description of the IBM-suppliedexecution member, see “Using the Commands to Generate JCL andUser-Defined Output” on page 309.

NODEFLTOptional parameter you use to specify that the implicit skeletal JCL defaultmember, if any, for the CA group is not to be used.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the output changeaccumulation data set. This parameter is valid only when both of the followingconditions are true:

v The VOLLIST parameter is specified.

v The CA group for which the JCL is being generated is defined with theNOREUSE parameter.


%key1User-defined keyword being assigned a value. The maximum length of the

GENJCL.CA


keyword is eight characters, including the percent sign. The first characterafter the percent sign must be alphabetic (A-Z). The remaining charactersmust be alphanumeric (A-Z, 0-9).





VOLLIST(volser)Optional parameter you use to specify the volumes that are to contain thechange accumulation data set. This parameter is valid only if the CA group forwhich the JCL is being generated was defined with the NOREUSE parameter.

VOLNUM(value) | CATIME(time)Mutually exclusive, optional parameters you use to specify the log volumes thatare used by the Change Accumulation utility.

VOLNUMSpecifies the number of log volumes that are to be used in each changeaccumulation job step. DBRC generates a multiple-step job that invokes theChange Accumulation utility in each step (unless you specify VOLLIST),and limits the number of log volumes in each step to the specified number.If another volume is needed to complete subset processing, VOLNUM maybe overridden by DBRC. DBRC may also override VOLNUM for thefollowing reasons:

v CATDS is specified and a data set entry spans multiple volumes.

v Log volumes have identical start times.

v Log volumes have identical start times and stop times.

For value, specify the number of log volumes. You can specify a decimalnumber from 1 to 255.

Each job step except the first one uses the change accumulation data set(that was generated in the previous step) as the beginning point of theaccumulation in that step.

CATIMESpecifies the time after which no log volumes for the specified CA groupare to be included. The time stamp does not need to be the stop time ofany log volume. DBRC uses the time stamp as the ending delimiter for thelog volume subset. Therefore, all log volumes that have start times less

GENJCL.CA


than or equal to the specified time stamp are included in the subset ofvolumes. The time stamp must be in standard form (see “Standard TimeStamp Format” on page 101).

Examples of Running the Change Accumulation UtilityHere are some examples of using the GENJCL.CA command.

Example for the GRPNAME CA GroupIn this example, a GENJCL.CA command generates the JCL and control statementsrequired to run the Change Accumulation utility for the CA group identified in theGRPNAME parameter. CAGRP1 is defined as REUSE. If the INIT.CAGRP commandfor CAGRP1 is specified without a CAJCL(member) parameter, default skeletalmember CAJCL from the data set identified in the JCLPDS DD statement is used. IfINIT.CAGRP is specified with the CAJCL(member) parameter, that member is used.The generated JCL goes to the data set that is identified in the JCLOUT DDstatement. Skeletal member JOBJCL produces a job statement.//GENJCA JOB//JCLPDS DD . . .//JCLOUT DD . . .

...

//SYSIN DD *GENJCL.CA GRPNAME(CAGRP1)

/*

Example of CAJCLA Generated Skeletal JCLIn this example, the GENJCL.CA command is generated with skeletal JCL executionmember CAJCLA, which was taken from the JCLPDS data set identified by thePDSJCL DD statement. Output from the generated JCL goes to SYSOUT=A,identified in the OUTJCL DD statement. CAGRP2 is defined with the NOREUSEparameter. Skeletal member JOBJCL produces a job statement.//GENJCA1 JOB//OUTJCL DD SYSOUT=A//PDSJCL DD DSN=dsname//SYSIN DD *GENJCL.CA GRPNAME(CAGRP2) VOLLIST(VOL001) MEMBER(CAJCLA) -JCLPDS(PDSJCL) JCLOUT(OUTJCL)

Example of CAJCLB Generated Skeletal JCLIn this example, the GENJCL.CA command generates JCL and control statements torun the Change Accumulation utility for CAGRP3, which is defined as REUSE. JCLexecution member CAJCLB is taken from the JCLPDS data set identified by theJCLPDS DD statement.

DEFAULTS(DEFCA01) is a member in the JCLPDS data set which contains valuesto resolve user defined keywords in member CAJCLB. The default member for theCAGRP, if initialized in the INIT.CAGRP DEFLTJCL(MEMBER) command, is alsoused to resolve keywords. %DISP is a user-defined keyword in member CAJCLBwhich is assigned a value of 'SHR'. %OUTCLS is a user-defined keyword in memberCAJCLB which is assigned a value of 'B'.

The values in the explicitly defined DEFAULTS member overrides values in thepredefined DEFLTJCL member. The values specified in the USERKEYS parameterfor a keyword overrides the values found in the DEFAULTS member. JCL isgenerated with no job statement. All volumes that have stop times less than orequal to the specified time stamp are included in the subset of volumes that is usedas input to the Change Accumulation utility. Generated JCL is listed.

GENJCL.CA


//GENJCA3 JOB//JCLPDS DD//JCLOUT DD//SYSIN DD *GENJCL.CA GRPNAME(CAGRP3) MEMBER(CAJCLB) DEFAULTS(DEFCA01) -USERKEYS((%DISP,'SHR'),(%OUTCLS,'B')) NOJOB LIST -CATIME(861020202111)

GENJCL.CLOSE

OO GENJCL.CLOSE

S

,

DEFAULTS( member )


O

OJCLPDS

JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST


OOLDS(ddname) SSID(name)

S

,


OP

Use the GENJCL.CLOSE command to generate the JCL and utility control statementsthat run the Log Recovery utility to close an OLDS using the WADS. For informationabout the IBM-supplied skeletal JCL execution member used by GENJCL.CLOSE, see“Using the Commands to Generate JCL and User-Defined Output” on page 309.

ParametersDEFAULTS(member)

Optional parameter you use to specify up to 10 names of skeletal JCL defaultmembers used when generating JCL. Default members are searched to resolvekeywords in the order in which the members are specified on this parameter.


JCLOUT(JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with thisddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set, but only if it is notthe same data set that is used for the default, JCLOUT.

JCLPDS(JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set to be used forinput when generating JCL. The data set is specified by ddname. A JCL DDstatement with this ddname must be included in the job step containing theGENJCL command.

JOB | JOB(member)|NOJOBMutually exclusive, optional parameters you use to specify whether to producethe job statement in the generated JCL.

GENJCL.CA


JOBSpecifies that the job statement is produced. When JOB is specified withouta member name, the IBM-supplied execution member JOBJCL producesthe job statement.

JOB(member)Specified execution member produces the job statement.

NOJOBSpecifies that no job statement is to be produced in the generated JCL.

LIST | NOLISTMutually exclusive, optional parameters you use to specify whether you wantthe generated JCL to be written to the SYSPRINT data set.



MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember to be used. If this parameter is not specified, the IBM-suppliedexecution member for the GENJCL.CLOSE command is used. For a description ofthis execution member, see “Using the Commands to Generate JCL andUser-Defined Output” on page 309.

OLDS(ddname)Optional parameter you use to specify which OLDS is to be closed. You specifythe name of the DD statement that was used when the online IMS subsystemcreated the log data. The ddname of the primary OLDS must be specified. Ifyou do not specify the OLDS, DBRC generates JCL to close the OLDS thatwas most recently opened.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the OLDSs being closed.

The SSID is an eight-character alphanumeric string that comprises a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses thedefault subsystem identifier in the RECON header record. Use the INIT.RECONor CHANGE.RECON command to set the default system identifier in the RECONheader record. If you have not set a default in the RECON header record, youmust specify SSID.


%key1User-defined keyword that is being assigned a value. The maximum lengthof the keyword is eight characters, including the percent sign. The firstcharacter after the percent sign must be alphabetic (A-Z). The remainingcharacters must be alphanumeric (A-Z, 0-9).


GENJCL.CLOSE





Examples of Running the Log Recovery UtilityHere are some examples of using the GENJCL.CLOSE command.

Example When a Host Operating System Failed and /ERE Is NotPossibleIn this example, a GENJCL.CLOSE command generates the JCL and controlstatements that are required to run the Log Recovery utility for the IMS onlinesubsystem with subsystem ID IMSA, which was using a primary OLDS when a hostoperating system failed and /ERE could not be performed. Default skeletal memberLOGCLJCL is taken from the data set identified in the JCLPDS DD statement.Output from the generated JCL goes to the data set identified in the JCLOUT DDstatement. Skeletal member JOBJCL produces a job statement.//GENJCL JOB//JCLOUT DD//JCLPDS DD

...

//SYSIN DD *GENJCL.CLOSE SSID(IMSA)

/*

After the close job runs, the PRIOLDS record in RECON that corresponds to theOLDS is updated to indicate the successful close.

Example Using the CLOSE1 JCLPDS MemberIn this example, the GENJCL.CLOSE command is generated with a skeletal JCLexecution member CLOSE1, which is taken from the JCLPDS data set identified inthe PDS DD statement. Output from the generated JCL goes to the data setidentified in the OUT DD statement. MEMBER DEFCL1 from the JCLPDS DDstatement contains values to resolve user-defined keywords in member CLOSE1.Skeletal member JOBJCL produces a job statement. Generated JCL is listed.//GENJCL1 JOB//OUT DD . . .//PDS DD . . .//SYSIN DD *GENJCL.CLOSE MEMBER(CLOSE1) OLDS(DFSOLP01) -JCLPDS(PDS) JCLOUT(OUT) DEFAULTS(DEFCL1) LIST

GENJCL.IC

OO GENJCL.IC DBD(name)GROUP(name) COPIES( 1 )

234

DDN(ddname)AREA(name)

O

GENJCL.CLOSE


OCIC

NOCICSMSCIC

COMPRESSSMSNOCIC

COMPRESS

LDBREL( P )

S

,

DEFAULTS( member )

O

OJCLOUT


JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST

LISTO

OMEMBER(member)

MULTIJOB

ONEJOB NODEFLT 3400UNIT( unittype )

O

O3400

UNIT2( unittype )3400

UNIT3( unittype )3400

UNIT4( unittype )

O

O

S

,


S

,

VOLLIST( volser )

O

O

S

,

VOLLIST2( volser ) S

,

VOLLIST3( volser )

O

O

S

,

VOLLIST4( volser )

OP

Use the GENJCL.IC command to generate the JCL and utility control statementsneeded to run the Database Image Copy utility or the Database Image Copy 2utility. For information about the IBM-supplied skeletal JCL execution member usedby GENJCL.IC, see “Using the Commands to Generate JCL and User-DefinedOutput” on page 309.

Important: For HALDB partitions, the GENJCL.IC command treats ILDS and indexdata sets differently than data DBDSs. The GENJCL.IC command skips these datasets in groups, regardless of whether the groups are explicit or implicit. If youexplicitly specify one of these data sets, the GENJCL.IC command fails.

Related Reading:

v See “HALDB Records” on page 60 for detailed information about how HALDBsare represented in the RECON data set.

v See IMS Version 7 Administration Guide: Database Manager for an overview ofHALDBs and information about how to create them.

GENJCL.IC


ParametersDBD(name) | GROUP(name)

Mutually exclusive, required parameters you use to specify the DBDS or DEDBarea to be copied.

DBDSpecifies the name of the database that contains the DBDS or area to becopied.

For HALDBs (High Availability Large Databases), you can specify either aHALDB master name or a HALDB partition name.

GROUPSpecifies that all DBDSs of a DBDS group are to be copied. If GROUP isspecified, the GENJCL.IC command executes repeatedly for each DBDS ofthe named DBDS group.

COPIES(1 | 2 | 3 | 4)Optional parameter you use to specify how many two image copy data sets areto be produced for the specified DBDS.

If the specified DBDS is identified in RECON with the NOREUSE attribute, youcan specify the COPIES parameter if you want two or more image copy datasets; otherwise, one image copy data set is produced.

If the specified DBDS is identified in RECON with the REUSE attribute, youmust specify the COPIES parameter if you want two or more image copy datasets; otherwise only one image copy data set is produced. COPIES(3 | 4) canonly be specified if either SMSCIC or SMSNOCIC is also specified. The thirdand fourth copies are not recorded in RECON.

DDN(name) | AREA(name)Mutually exclusive, optional parameters you use to identify the DBDS ddnameor DEDB area name that is to be copied.

Specify the DDN or AREA parameter only if you specify the DBD parameter. Ifyou do not specify DDN or AREA, the GENJCL.IC command executesrepeatedly, once for each DBDS or area of the specified database. If youspecify a HALDB master name, the GENJCL.IC command is performed for alldata DBDSs for each partition in the HALDB master database. If you specify aHALDB partition name, the GENJCL.IC command is performed for all dataDBDSs of the identified partition.

For HALDBs, you must specify a partition database name with the DBDparameter in order to use the DDN parameter. The DDN parameter value is thepartition DDN. The GENJCL.IC command is performed for the identified DBDS ofthe partition. The GENJCL.IC command fails if DDN does not identify a dataDBDS in the partition.

CIC | NOCIC | SMSCIC | SMSNOCICOptional, mutually exclusive, parameters you use to indicate how the imagecopy is to be taken.

CICSpecifies that the Database Image Copy (DFSUDMP0) utility is to be usedto take an image copy concurrent with update processing.

NOCICSpecifies that the Database Image Copy (DFSUDMP0) utility is to be usedto take an image copy while the database is unavailable for updateprocessing.

GENJCL.IC


SMSCICIndicates that the Database Image Copy 2 utility is to be used to take animage copy concurrent with update processing. The Database Image Copy2 utility invokes DFSMS Concurrent Copy.

The optional COMPRESS parameter invokes the ″compress″ option inDFSMS Concurrent Copy. The compress option enables you to reduce thestorage space required to hold the image copy; however, using thecompress option increases the CPU time that is required to perform thecopy operation.

SMSNOCICIndicates that the Database Image Copy 2 utility is to be used to take animage copy while the database is unavailable for update processing. TheDatabase Image Copy 2 utility invokes DFSMS Concurrent Copy.

The optional COMPRESS parameter invokes the ″compress″ option inDFSMS Concurrent Copy. The compress option enables you to reduce thestorage space required to hold the image copy; however, using thecompress option increases the CPU time that is required to perform thecopy operation.

DBREL(L | P)Applicable only when SMSNOCIC is also specified and it indicates when thedatabase is to be made available for update processing. It is ignored whenSMSNOCIC is not specified.

L L indicates that updates are to be allowed after the image copy is logicallycomplete (after DFSMS has initialized a concurrent copy session). Updateprocessing can occur (or be resumed) before the image copy is physicallycomplete.

P P indicates that updates are not to be allowed until the image copy isphysically complete.

DEFAULTS(member)Optional parameter you use to specify up to 10 names of skeletal JCL defaultmembers to be used when generating JCL. Default members are searched toresolve keywords in the order in which the members are specified on thisparameter.

If a keyword is assigned a value in both the DEFAULTS and USERKEYSparameter, the value specified in USERKEYS is used.

JCLOUT(JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with thisddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set, but only if it is notthe same data set that is used for the default, JCLOUT.

JCLPDS(JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to beused for input when generating JCL. The data set is specified by ddname. AJCL DD statement with this ddname must be included in the job step containingthe GENJCL command.


GENJCL.IC



NOJOBSpecifies that the job statement is not to be produced in the generated JCL.

LIST | NOLISTMutually exclusive, optional parameters you use to specify whether to write thegenerated JCL to the SYSPRINT data set.



MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember to be used. For a description of the IBM-supplied execution member,see “Using the Commands to Generate JCL and User-Defined Output” onpage 309. If this parameter is not specified, the default specified on theINIT.DBDS command is used.

MULTIJOB | ONEJOBMutually exclusive, optional parameters you use to control how many JOBstatements are to be generated when a DBDS group is specified either explicitlyor implicitly.

MULTIJOBProduces one job for each group member.

ONEJOBProduces one multi-step job for the whole group.

These parameters are invalid if the NOJOB subparameter is specified on theJOB parameter, or if a DBDS group is not specified.

NODEFLTOptional parameter you use to specify that the implicit skeletal JCL defaultmember, if any, for the DBDS is not to be used.

UNIT(3400 | unittype)

UNIT2(3400 | unittype)

UNIT3(3400 | unittype)

UNIT4(3400 | unittype)Optional parameter you use to specify the unit type of the first, second, third, orfourth output image copy data sets. These parameters are valid only if both ofthe following conditions are true:

v The corresponding VOLLIST parameter is specified

v The DBDS for which the JCL is being generated was defined with theNOREUSE option


GENJCL.IC







VOLLIST(volser)

VOLLIST2(volser)

VOLLIST3(volser)

VOLLIST4(volser)Optional parameters you use to specify the volumes on which the image copydata set copies are to reside. These parameters are valid only if:

v The DBDS for which the JCL is being generated is defined with theNOREUSE option.

v DBD is specified with DDN or AREA.

Examples of Running the Database Image Copy UtilityHere are some examples of using the GENJCL.IC command.

Example for DBDS Defined by the DBD and DDN ParametersIn this example, a GENJCL.IC command generates the JCL and control statementsrequired to run the Database Image Copy utility for the DBDS identified in the DBDand DDN parameters. The default Concurrent Image Copy (CIC) is used. Thedatabase is defined as REUSE. If the INIT.DBDS command for the DBDS for whichJCL is being generated is specified with ICJCL(member), that skeletal member isused from the data set that is identified in the JCLPDS DD statement. If not, thedefault skeletal member ICJCL from the JCLPDS data set is used. Output from thegenerated JCL goes to the data set identified in the JCLOUT DD statement.Skeletal member JOBJCL produces a job statement.//GENJIC1 JOB//JCLOUT DD . . .//JCLPDS DD . . .

...

//SYSIN DD *GENJCL.IC DBD(DBDKSDS1) DDN(DDNKSDS1)

GENJCL.IC


The EXEC and SYSIN statements for the generated JCL are shown below:

...

//IC1 EXEC PGM=DFSUDMP0,REGION=nnnK,// PARM='CIC,GSGNAME='

...

//SYSIN DD *D1 DBDKSDS1 DDNKSDS1 DATAOUT1/*

Example for All DBDSs in a Group with NOCICIn this example, the GENJCL.IC command generates JCL and control statements torun the Image Copy utility for all DBDSs of GROUP1 and batch image copies(NOCIC) are also taken. The skeletal member used is ICJCL1 from the data setidentified in PDS4. The keyword, %DEFIC, is a user-defined value in ICJCL1 that isresolved to '1ST USERKEYS PARM'. The default member for the databaseinitialized in INIT.DBDS DEFLTJCL(MEMBER) is not used to resolve keywords. Skeletalmember JOBJCL produces a job statement.//GENJIC2 JOB//JCLOUT DD . . .//PDS4 DD . . .//SYSIN DD *

GENJCL.IC GROUP(GROUP1) JOB MEMBER(ICJCL1) JCLPDS(PDS4) ONEJOB -NOCIC USERKEYS((%DEFIC,'1ST USERKEYS PARM')) NODEFLT

The following statements are examples of one of the EXEC statements and one ofthe SYSIN statements for the generated JCL:

...

//IC1 EXEC PGM=DFSUDMP0,REGION=nnnK,// PARM=',GSGNAME='

...

//SYSIN DD *D1 DBD1GRP1 DDN1GRP1 DATAOUT1/*//IC2 EXEC PGM=DFSUDMP0,REGION=nnnK,// PARM=',GSGNAME='

...

Example of Running the Database Image Copy 2 Utility withSMSCICIn this example, a GENJCL.IC command generates the JCL and control statementsrequired to run the Database Image Copy 2 utility in shared database mode(SMSCIC) for the DBDS that is identified in the DBD and DDN parameters. Thedatabase is defined as NOREUSE and four copies are requested. The defaultskeletal member ICJCL from the JCLPDS data set is used. Output from thegenerated JCL goes to the data set identified in the JCLOUT DD statement.Skeletal member JOBJCL produces a job statement.//GENJIC3 JOB//JCLOUT DD . . .//JCLPDS DD . . .

...

GENJCL.IC


//SYSIN DD *GENJCL.IC DBD(DBDVSAM1) DDN(DDNVSAM1) COPIES(4) SMSCIC -

VOLLIST(IC2001) VOLLIST2(IC2002) VOLLIST3(IC2003) -VOLLIST4(IC2004)

/*


...

//IC1 EXEC PGM=DFSRRC00,REGION=nnnK,// PARM='ULU,DFSUDMT0,,,,,,,,,,,,Y,,,,,,,,'

...

//SYSIN DD *4 DBDVSAM1 DDNVSAM1 DATAOUT1 DATAOUT2 DATAOUT3 DATAOUT4 S/*

Example of Running the Database Image Copy 2 Utility withSMSNOCICIn this example, the GENJCL.IC command generates JCL and control statements torun the Database Image Copy 2 utility with exclusive database usage (SMSNOCIC)for the DBDS that is identified in the DBD and DDN parameters. The database isdefined as REUSE and the default, one copy, is requested. The global servicegroup name for DBDVSAM2 is GSGN4IC2. The default skeletal member ICJCLfrom the JCLPDS data set is used. Output from the generated JCL goes to the dataset identified in the JCLOUT DD statement. Skeletal member JOBJCL produces ajob statement. The database is to be unlocked after the physical copy completes.//GENJIC4 JOB//JCLOUT DD . . .//JCLPDS DD . . .

...

//SYSIN DD *GENJCL.IC DBD(DBDVSAM2) DDN(DDNVSAM2) DBREL(P) SMSNOCIC

/*


...

//IC1 EXEC PGM=DFSRRC00,REGION=nnnK,// PARM='ULU,DFSUDMT0,,,,,,,,,,,,Y,,,,,,,,GSGN4IC2'

...

//SYSIN DD *1 DBDVSAM2 DDNVSAM2 DATAOUT1 XP/*

GENJCL.OIC

OO GENJCL.OIC DBD(name)GROUP(name)

PSB(name)CHKINT(value) COPIES( 1 )

2

O

GENJCL.IC


ODDN(ddname)

S

,

DEFAULTS( member )


O

OJCLPDS

JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST


OMULTIJOB

ONEJOB NODEFLT 3400UNIT( unittype )

3400UNIT2( unittype )

O

O

S

,


S

,

VOLLIST( volser )

O

O

S

,

VOLLIST2( volser )

OP

Use the GENJCL.OIC command to generate the JCL and utility control statementsneeded to run the Online Database Image Copy utility. For information about theIBM-supplied skeletal JCL execution member used by GENJCL.OIC, see “Using theCommands to Generate JCL and User-Defined Output” on page 309.

Important: For HALDB partitions, the GENJCL.OIC command treats ILDS and indexdata sets differently than data DBDSs. The GENJCL.OIC command skips these datasets in groups, regardless of whether the groups are explicit or implicit. If youexplicitly specify one of these data sets, the GENJCL.OIC command fails.

The GENJCL.OIC command and online image copy cannot be used on databases atan RSR-tracking site.


Mutually exclusive, required parameters you use to specify the DBDS or DEDBarea that is to be copied.

DBDSpecifies the name of the DBDS or DEDB area that is to be copied.


GROUPSpecifies that all DBDSs of a DBDS group are to be copied. If GROUP isspecified, the GENJCL.IC command executes repeatedly, once for eachDBDS of the DBDS group.

GENJCL.OIC


PSB(name)Required parameter you use to specify the name of the PSB that is required fora run of the Online Database Image Copy utility.

If you specify GROUP, the same PSB name is used for all members of thegroup.

CHKINT(value)Optional parameter you use to specify the checkpoint interval for the OnlineDatabase Image Copy utility. value must be a decimal number from 1 to 9999.If this keyword is omitted, the Online Database Image Copy utility uses its owndefault value for the checkpoint interval.

COPIES(1 | 2)Optional parameter you use to request that the Online Database Image Copyutility in order to produce one or two image copy data sets for the specifiedDBDS.

If the specified DBDS is identified in RECON with the NOREUSE attribute, youmust specify the COPIES parameter in order to produce two image copy datasets; otherwise, one image copy data set is produced.

If the specified DBDS is identified in RECON with the REUSE attribute, youcannot specify a COPIES parameter; the number of image copy data sets thatare produced for this DBDS is determined by parameters in the INIT.ICcommand.

DDN(name)Optional parameter you use to identify the DBDS that is to be copied.

The DDN parameter can be specified only if the DBD parameter is specified. IfDDN is not specified, the GENJCL.OIC command executes repeatedly, once foreach DBDS of the specified database. If you specify a HALDB master name,the GENJCL.OIC command is performed for all data DBDSs for each partition inthe HALDB master. If you specify a HALDB partition name, the GENJCL.OICcommand is performed for all data DBDSs of the identified HALDB partition.

For HALDBs, you must specify a partition database name with the DBDparameter in order to use the DDN parameter. The DDN parameter value is thepartition DDN. The GENJCL.OIC command is performed for the identified DBDSof the partition. The GENJCL.OIC command fails if DDN does not identify a dataDBDS in the partition.

DEFAULTS (member)Optional parameter you use to specify up to 10 names of skeletal JCL defaultmembers to be used when generating JCL. Default members are searched inorder to resolve keywords in the order in which the members are specified onthis parameter.


JCLOUT ( JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with thisddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set, but only if it is notthe same data set used for the default, JCLOUT.

JCLPDS (JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to be

GENJCL.OIC


used for input when generating JCL. The data set is specified by ddname. AJCL DD statement with this ddname must be included in the job step thatcontains the GENJCL command.







MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember that is to be used. For a description of the IBM-supplied executionmember, see “Using the Commands to Generate JCL and User-Defined Output”on page 309. If this parameter is not specified, the default specified on theINIT.DBDS command is used.

MULTIJOB | ONEJOBMutually exclusive, optional parameters you use to control how many JOBstatements are to be generated when a DBDS group is specified either explicitlyor implicitly.

MULTIJOBProcesses the skeletal JCL JOB member for each group member (multipleJOB statements are to be produced).

ONEJOBProcesses the skeletal JCL JOB member only for the first group member.

These parameters are invalid if NOJOB is specified or if a DBDS group is notspecified.


UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the primary output dataset. This parameter is valid only if:

v The VOLLIST parameter was specified.

v The DBDS for which the JCL is being generated was defined with theNOREUSE option.

GENJCL.OIC


UNIT2(3400 | unittype)Optional parameter you use to specify the unit type of the secondary outputdata set. This parameter is valid only if:

v The VOLLIST2 parameter was specified.

v The DBDS for which the JCL is being generated was defined with theNOREUSE option.







VOLLIST(volser)Optional parameter you use to specify the volumes on which the image copydata set is to reside. This parameter is valid only if the DBDS for which the JCLis being generated is defined with the NOREUSE option, and if the DBDS isbeing used with DBDs, not with groups.

VOLLIST2(volser)Optional parameter you use to specify the volumes on which the duplicateimage copy data set is to reside. This parameter is valid only if the DBDS forwhich the JCL is being generated is defined with the NOREUSE option, and ifthe DBDS is being used with DBDs, not with groups.

Examples of Running the Online Database Image Copy UtilityHere are some examples of using the GENJCL.OIC command.

Example Using JCLPDS Member OICJCLIn this example, a GENJCL.OIC command generates the JCL and control statementsrequired to run the Online Database Image Copy utility for the DBDS identified inthe DBD and DDN parameters. The database is defined as REUSE. If theINIT.DBDS command for the DBDS for which the JCL is being generated is specifiedwith OICJCL(member), that member is used and is found in the data set identifiedin the JCLPDS DD statement. If not, default skeletal member OICJCL from the

GENJCL.OIC


JCLPDS data set is used. Output from the generated JCL goes to the data setdefined in the JCLOUT DD statement. Skeletal member JOBJCL produces a jobstatement.//GENJOIC JOB//JCLPDS DD . . .//JCLOUT DD . . .

...

//SYSIN DD *GENJCL.OIC DBD(DBDKSDS1) DDN(DDNKSDS1) -

PSB(MYJOB)/*

Example Using JCLPDS Member OICJCL2In this example, the GENJCL.OIC command generates JCL and control statements torun the Online Image Copy utility for all DBDSs of GROUP1. The skeletal memberused is OICJCL2 from the data set identified in the OICPDS DD statement. One jobstatement for each group member is generated from the JOBCARD member foundin the data set identified in the OICPDS DD statement. %DEFDBDS is a user-definedvalue in OICJCL2 and is resolved with 'DATABASE DEFINED HERE'. MembersDEF1, DEF2, and DEF3 are used to resolve user-defined keywords in OICJCL2.The default member for the database initialized in INIT.DBDS DEFLTJCL(MEMBER)is not used to resolve keywords. The values specified in the USERKEYS parameterfor a keyword override the values found in the DEFAULTS member.//GENJOIC1 JOB//OICOUT DD . . .//OICPDS DD . . .//SYSIN DD *

GENJCL.OIC GROUP(GROUP1) JOB(JOBCARD) MEMBER(OICJCL2) -NODEFLT JCLPDS(OICPDS) JCLOUT(OICOUT) PSB(PCBOIC6) -USERKEYS((%DEFDBDS,'DATABASE DEFINED HERE')) -

DEFAULTS(DEF1,DEF2,DEF3)

GENJCL.RECEIVE

OO GENJCL.RECEIVE DBD(name)GROUP(name)

S

,

DEFAULTS( member )


O

OJCLOUT


JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST

LISTO

OMEMBER(member)

S

,


OP

Use the GENJCL.RECEIVE command to apply an image copy from an RSR active siteto a database data set or area at an RSR tracking site. This command generatesthe JCL and utility control statements required to run the database recovery utilityfor image copy receive. If more than one image copy data set is registered in the

GENJCL.OIC


RECON for a given DBDS or area, the most recent usable image copy data set isreceived. A usable image copy is one that meets all of the following requirements:

v Is not flagged as being in error

v Was created by the IMS Batch Image Copy utility or the Database Image Copy 2utility while the database was unavailable for update processing

v Was created after any updates were received at the tracking site

The GENJCL.RECEIVE command can only be used for RSR-covered databases. Also,the local service group of the covering global service group must be a trackingservice group.

Important: For HALDB partitions, the GENJCL.RECEIVE command treats ILDS andindex data sets differently than data DBDSs. The GENJCL.RECEIVE command skipsthese data sets in groups, regardless of whether the groups are explicit or implicit. Ifyou explicitly specify one of these data sets, the GENJCL.RECEIVE command fails.

For information about the IBM-supplied skeletal JCL execution member that is usedby GENJCL.RECEIVE, see “Using the Commands to Generate JCL and User-DefinedOutput” on page 309.


Mutually exclusive, required parameters you use to specify the database that isto be received.

DBDSpecifies the name of the database to be received. The database must beRSR-covered.


GROUPSpecifies that image copies for all DBDSs of a DBDS or CA group are to bereceived. If GROUP is specified, the GENJCL.RECEIVE command executesrepeatedly, once for each DBDS of the DBDS or CA group. If you attemptan implicit or explicit group execution with recoverable and nonrecoverableDBDSs, JCL is not generated for the nonrecoverable DBDSs.

If GROUP is specified, all DBDS areas of the group must be covered by thesame global service group.

DEFAULTS (member)Optional parameter you use to specify up to 10 names of skeletal JCL defaultmembers that are to be used when generating JCL. Default members aresearched to resolve keywords in the order in which the members are specifiedon this parameter.

If a keyword is assigned a value in both the DEFAULTS and the USERKEYSparameters, the value specified in USERKEYS is used.

DDN(name) | AREA(name)Mutually exclusive, optional parameters you use to identify the DBDS ddnameor DEDB area to be received.

The DDN or AREA parameter is specified only if the DBD parameter isspecified.

GENJCL.RECEIVE


For HALDBs, you must specify a partition database name with the DBDparameter in order to use the DDN parameter. The DDN parameter value is thepartition DDN. The GENJCL.RECEIVE command is performed for the identifiedDBDS of the partition. The GENJCL.RECEIVE command fails if DDN does notidentify a data DBDS in the partition.

If DDN or AREA is not specified, the GENJCL.RECEIVE command executesrepeatedly, once for each DBDS or area of the specified database. If youspecify a HALDB master name, the GENJCL.RECEIVE command is performed forall data DBDSs for each HALDB partition in the HALDB master. If you specify aHALDB partition name, the GENJCL.RECEIVE command is performed for all dataDBDSs of the identified partition.

JCLOUT (JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with thisddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set, but only if it is notthe same data set that is used for the default (JCLOUT).

JCLPDS (JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to beused for input when generating JCL. The data set is specified by ddname. AJCL DD statement with this ddname must be included in the job step containingthe GENJCL command.


JOBSpecifies that the job statement is to be produced. When JOB is specifiedwithout a member name, the IBM-supplied execution member ICRCVJCLproduces the job statement. When JOB(member) is specified, the specifiedexecution member produces the job statement.





MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember that is to be used. For a description of the IBM-supplied executionmember, see “Using the Commands to Generate JCL and User-Defined Output”on page 309. If this parameter is not specified, the default specified on theINIT.DBDS command is used.


%key1User-defined keyword that is being assigned a value. The maximum length

GENJCL.RECEIVE


of the keyword is eight characters, including the percent sign. The firstcharacter after the percent sign must be alphabetic (A-Z). The remainingcharacters must be alphanumeric (A-Z, 0-9).





Examples of Running the Database Recovery Utility to Receive anImage Copy

Here are some examples of using the GENJCL.RECEIVE command.

Example for the DBDS Identified by the DBD and DDNParametersIn this example, a GENJCL.RECEIVE command generates the JCL and controlstatements that are required to run the database recovery utility to receive an imagecopy for the DBDS that is identified in the DBD and DDN parameters.

If the INIT.DBDS command for the DBDS, for which the JCL is being generated, isspecified with RECVJCL(member), that member is used and is found in the data setthat is identified in the JCLPDS DD statement. If not, default skeletal memberRECVJCL, from the JCLPDS data set is used. Output from the generated JCL goesto the data set that is identified in the JCLOUT DD statement. Skeletal memberJOBJCL produces a job statement.//GENJRCVE JOB//JCLPDS DD . . .//JCLOUT DD . . .

...

//SYSIN DD *GENJCL.RECEIVE DBD(DBESDSA) DDN(DDESDSA)

/*

Example for All DBDSs in a GroupIn this example, the GENJCL.RECEIVE command generates JCL and controlstatements to run the database recovery utility to receive image copies for allDBDSs of GROUP1.

The skeletal member used is RCVJCL2 from the data set identified in the PDS DDstatement. Skeletal member JOBJCL produces a job statement for each member ofthe group. %DEFDBD1 and %DEFDBD2 are user-defined values in member RCVJCL2,which resolve to 'DEFINE DB1' and 'DEFINE DB2'. Default members DEF1, DEF2,

GENJCL.RECEIVE


and DEF3 are used to resolve user-defined keywords in RECJCL2. The defaultmember for the DBDS, if initialized in the INIT.DBDS DEFLTJCL(MEMBER)command, is also used to resolve keywords. The values in the explicitly definedDEFAULTS members override values in the predefined DEFLTJCL member. Thevalues specified in the USERKEYS parameter for a keyword override the valuesfound in the DEFAULTS members.//GENJRCV1 JOB//OUT DD . . .//PDS DD . . .//SYSIN DD *

GENJCL.RECEIVE GROUP(GROUP1) MEMBER(RCVJCL2) -JCLPDS(PDS) JCLOUT(OUT) -USERKEYS((%DEFDBD1,'DEFINE DB1'),(%DEFDBD2,'DEFINE DB2')) -DEFAULTS(DEF1,DEF2,DEF3)

GENJCL.RECOV

OO GENJCL.RECOV DBD(name)GROUP(name)

S

,

DEFAULTS( member )


O

OJCLOUT


JCLPDS( ddname )

JOB

JOB(member)NOJOB

NOLIST

LISTO

OMEMBER(member)

MULTIJOB

ONEJOB NODEFLT RCVTIME(timestamp) RESTOREO

OUSEIC

USEDBDSUSEAREA

S

,


OP

Use the GENJCL.RECOV command to generate the JCL and utility control statementsrequired to run the database recovery utility. You can request the JCL and utilitycontrol statements for a full recovery or a timestamp recovery of a specified DBDSor area. All log data must be archived; otherwise the GENJCL.RECOV command fails.

Restriction: A nonstandard image copy data set cannot be used as input to thedatabase recovery utility. The procedure for recovering a database with anonstandard image copy is slightly different depending on whether the IMS systemis an active or tracking subsystem.

Active subsystem

1. Restore the DBDS from the nonstandard image copy.

2. Record this restoration by entering a NOTIFY.RECOV command with theimage copy run time as the RCVTIME parameter.

3. Complete the recovery, applying changes made since the image copy,by entering a GENJCL.RECOV command with the USEDBDS parameter.

Tracking subsystem

GENJCL.RECEIVE


1. Restore the DBDS from the nonstandard image copy. This must be thelatest recorded image copy.

2. Record this restoration by entering a NOTIFY.RECOV command with theimage copy run time as the RUNTIME parameter and the USID fromthe image copy as the RUNUSID parameter.

3. Issue a /START command for the database. Online forward recovery(OFR) automatically completes, applying changes made since theimage copy.

For information about the IBM-supplied skeletal JCL execution member used byGENJCL.RECOV, see “Using the Commands to Generate JCL and User-DefinedOutput” on page 309.

Use the RESTORE parameter to recover DBDSs that were designated asnonrecoverable.

Important: For HALDB partitions, the GENJCL.RECOV command treats ILDS andindex data sets differently than data DBDSs. The GENJCL.RECOV command skipsthese data sets in groups, regardless of whether the groups are explicit or implicit. Ifyou explicitly specify one of these data sets, the GENJCL.RECOV command fails.

Restriction: The GENJCL.RECOV command does not support ILDS and index datasets. To generate JCL for the HALDB Index/ILDS Rebuild Utility (DFSPREC0), usethe GENJCL.USER command. See “Sample JCL for HALDB INDEX/ILDS RebuildUtility (DSPUPJCL)” on page 364 for information about IBM-supplied sample JCLthat you can use.


Mutually exclusive, required parameters you use to specify the DBDSs that areto be recovered.

DBDSpecifies the database name of the DBDSs to be recovered.

For HALDBs, you can specify either a HALDB master name or a HALDBpartition name.

GROUPSpecifies that all DBDSs of a DBDS or CA group are to be recovered. IfGROUP is specified, the GENJCL.RECOV command executes repeatedly foreach DBDS of the DBDS or CA group. If you attempt an implicit or explicitgroup execution with recoverable and nonrecoverable DBDSs (andRESTORE is not specified), JCL is not generated for the nonrecoverableDBDSs.

DEFAULTS (member)Optional parameter you use to specify up to 10 names of skeletal JCL defaultmembers to be used when generating JCL. Default members are searched toresolve keywords in the order in which the members are specified on thisparameter.

If a keyword is assigned a value in both the DEFAULTS and the USERKEYSparameters, the value specified in USERKEYS is used.

DDN(name) | AREA(name)Mutually exclusive, optional parameters you use to identify the DBDS ddnameor DEDB area to be recovered.

GENJCL.RECOV


The DDN or AREA parameter is specified only if the DBD parameter isspecified.

For HALDBs, you must specify a partition database name with the DBDparameter in order to use the DDN parameter. The DDN parameter value is thepartition DDN. The GENJCL.RECOV command is performed for the identifiedDBDS of the partition. The GENJCL.RECOV command fails if DDN does notidentify a data DBDS in the partition.

If DDN or AREA is not specified, the GENJCL.RECOV command executesrepeatedly for each DBDS or area of the specified database. If you specify aHALDB master name, the GENJCL.RECOV command is performed for all dataDBDSs for each HALDB partition in the HALDB master. If you specify a HALDBpartition name, the GENJCL.RECOV command is performed for all data DBDSs ofthe identified partition.

JCLOUT (JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL. The data set is specified by ddname. A JCL DD statement with thisddname must be included in the job step containing the GENJCL command. Thespecified data set can be a member of a partitioned data set, but only if it is notthe same data set used for the default (JCLOUT).

JCLPDS (JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to beused for input when generating JCL. The data set is specified by ddname. AJCL DD statement with this ddname must be included in the job step containingthe GENJCL command.







MEMBER(member)Optional parameter you use to specify the name of the skeletal JCL executionmember to be used. For a description of the IBM-supplied execution member,see “Using the Commands to Generate JCL and User-Defined Output” onpage 309. If this parameter is not specified, the default specified on theINIT.DBDS command is used.

GENJCL.RECOV


MULTIJOB | ONEJOBMutually exclusive, optional parameters you use to control how many JOBstatements are generated when a DBDS group is specified either explicitly orimplicitly.

MULTIJOBProcesses the skeletal JCL JOB member for each group member (multipleJOB statements are produced).

ONEJOBProcesses the skeletal JCL JOB member only for the first group member.

These parameters are invalid if NOJOB is specified or a DBDS group is notspecified.


RCVTIME(timestamp)Optional parameter you use to specify a time stamp recovery, which is a partialrecovery of a DBDS or area to a point in time earlier than its most recent state.If you omit this parameter, you are requesting a full recovery to the most recentstate.

A valid time stamp for a partial recovery is any point at which there are noallocations of the DBDS or area and there is not a merge of logs needed thatcannot be resolved by running the change accumulation utility.

Attention: An allocation that has no de-allocation time recorded persists untilthe stop time of the current log.

Related Reading:

v See “Using the %SET TIMEFMT Keyword” on page 318 for more informationon full recovery.

v See IMS Version 7 Operations Guide for more information on time stamprecovery.

RESTOREOptional parameter used to generate JCL for a database data set that isdesignated as nonrecoverable. If the last image copy was taken before theDBDS was designated as nonrecoverable, normal recovery JCL is generated torecover the DBDS up to the point of the recovery-status change. If the lastimage copy was taken after the DBDS was designated as nonrecoverable, thegenerated JCL uses only the image copy for recovery.

If you attempt an implicit or explicit group execution with recoverable andnonrecoverable DBDSs (and RESTORE is specified), JCL is generated only forthe nonrecoverable DBDSs.

Do not specify RESTORE for a recoverable DBDS.

USEIC | USEDBDS | USEAREAMutually exclusive, optional parameters you use to specify the starting point ofthe requested recovery action.

USEICStarts the recovery with an image copy data set. You can then applysubsequent changes that occurred in the DBDS.

USEIC is the default.

GENJCL.RECOV


USEDBDSRecovery is performed using only the changes that have occurred to theDBDS in its current state. An image copy data set is not used as input tothis recovery. You can specify the USEDBDS parameter only if you alsospecify the DBDS parameter, and only after performing a timestamprecovery in which an image copy data set is used as input.

USEAREARecovery is performed using only the changes that have occurred to theDEDB area in its current state. An image copy data set is not used as inputto this recovery. You can specify USEAREA only if you also specify theAREA parameter, and only after performing a timestamp recovery in whichan image copy data set is used as input.

You can use these parameters to recover a DBDS or area to a specified timestamp using an image copy data set and then apply the changes that haveoccurred since the image copy by specifying an additional recovery using theUSEDBDS or USEAREA parameter.

Restriction: If this required time stamp recovery restored the DBDS or DEDBarea to a time that falls within an existing time stamp recovery’s range (the timebetween the RECOV TO and RUN times), then the USEDBDS or USEAREAparameter is invalid.







Examples of Running the Database Recovery UtilityHere are some examples of using the GENJCL.RECOV command.

GENJCL.RECOV


Example for the DBDS Identified in the DBD and DDN ParametersIn this example, a GENJCL.RECOV command generates the JCL and controlstatements required to run the database recovery utility for the DBDS identified inthe DBD and DDN parameters. The USEIC parameter indicates that the time stamprecovery starts with an image copy data set and ends with the log data set that hasthe stop time stamp specified in the RCVTIME parameter.

If the INIT.DBDS command for the DBDS for which the JCL is being generated isspecified with RECOVJCL(member), that member is used and is found in the dataset identified in the JCLPDS DD statement. If not, default skeletal memberRECOVJCL from the JCLPDS data set is used. Output from the generated JCLgoes to the data set identified in the JCLOUT DD statement. Skeletal memberJOBJCL produces a job statement.//GENJRCOV JOB//JCLPDS DD . . .//JCLOUT DD . . .

...

//SYSIN DD *GENJCL.RECOV DBD(DBESDSA) DDN(DDESDSA) USEIC -RCVTIME(821001212130)

/*

Example for All DBDSs in a GroupIn this example, the GENJCL.RECOV command generates JCL and control statementsto run the database recovery utility for all DBDSs of GROUP1. The skeletal memberthat is used is RECJCL2 from the data set identified in the PDS DD statement.

Skeletal member JOBJCL produces a job statement for each member of the group.%DEFDBD1 and %DEFDBD2 are user-defined values in member RECJCL2 which resolveto 'DEFINE DB1' and 'DEFINE DB2'. Default members DEF1, DEF2, and DEF3 areused to resolve user-defined keywords in RECJCL2. The default member for theDBDS, if initialized in the INIT.DBDS DEFLTJCL(MEMBER)command, is also used toresolve keywords. The values in the explicitly defined DEFAULTS members overridevalues in the predefined DEFLTJCL member. The values specified in theUSERKEYS parameter for a keyword override the values found in the DEFAULTSmembers.//GENJRCV1 JOB//OUT DD . . .//PDS DD . . .//SYSIN DD *

GENJCL.RECOV GROUP(GROUP1) MEMBER(RECJCL2) -JCLPDS(PDS) JCLOUT(OUT) -USERKEYS((%DEFDBD1,'DEFINE DB1'),(%DEFDBD2,'DEFINE DB2')) -

DEFAULTS(DEF1,DEF2,DEF3)

GENJCL.USER

OO GENJCL.USER MEMBER(name)DBD(name)GROUP(name)

DDN(ddname)O

GENJCL.RECOV


O

S

,

DEFAULTS( member )


JCLPDSJCLPDS( ddname )

O

OJOB

JOB(member)NOJOB

NOLIST

LIST

MULTIJOB

ONEJOB NODEFLT PSB(name)O

OSSID(name) TIMEFMT(sublist)

O

O

S

,


OP

Use the GENJCL.USER command to generate JCL or any kind of user output. Youmust provide the skeletal JCL execution member that is needed for the GENJCL.USERcommand. For more information, see “Using the Commands to Generate JCL andUser-Defined Output” on page 309.

ParametersMEMBER(name)

Required parameter you use to specify the name of the skeletal JCL executionmember that is used to generate output. You must have already supplied theexecution member.

The name can be any valid member name for a partitioned data set. If thespecified member does not exist in the skeletal JCL data set, the commandfails.

DBD(name) | GROUP(name)Mutually exclusive, optional parameters you use to set the value of the %dbnamekeyword.

DBD

If you specify DBD without the DDN parameter, the GENJCL.USER commandexecutes repeatedly for each DBDS or the specified database. ForHALDBs, you can use this parameter to set the value of the %dbnamekeyword to be either a HALDB master name or a HALDB partition name. Ifyou use a HALDB master name, the GENJCL.USER command is performedfor all data DBDSs for each HALDB partition in the HALDB master. If youuse a HALDB partition name, the GENJCL.USER command is performed forall DBDSs of the identified partition.

GROUPIf you specify GROUP, the GENJCL.USER command executes repeatedly,once for each DBDS of the specified DBDS group. For each repeatedexecution, the DBD and DDN parameters are set to the correspondinggroup member.

GENJCL.USER


If you specify neither DBD nor GROUP, the value of the %dbname keyword is nullunless a value is assigned in the USERKEYS parameter or a skeletal JCLdefault member.

DDN(name)Optional parameter you use to set the value of the %ddname keyword. If you donot specify DDN, the value of the %ddname keyword is null unless a value isassigned in the USERKEYS parameter or a skeletal JCL default member.

For HALDBs, you must specify a partition database name with the DBDparameter in order to use the DDN parameter. In this case, the DDN is thepartition DDN. The GENJCL.USER command is performed for the identified DBDSof the partition. The GENJCL.USER command fails if DDN does not identify aDBDS in the partition.

You cannot specify DDN if you also specify GROUP.

DEFAULTS(member)Optional parameter you use to specify up to 10 names of skeletal JCL defaultmembers to be used when generating JCL or other user-defined output. Defaultmembers are searched to resolve keywords in the order in which the membersare specified on this parameter.


JCLOUT(JCLOUT | ddname)Optional parameter you use to specify the output data set for the generatedJCL or other user-defined output. The data set is specified by ddname. A JCLDD statement with this ddname must be included in the job step containing theGENJCL.USER command. The specified data set can be a member of apartitioned data set, but only if it is not the same data set that is used for thedefault (JCLOUT).

JCLPDS(JCLPDS | ddname)Optional parameter you use to specify the skeletal JCL data set that is to beused for input when generating the JCL or other user-defined output. The dataset is specified by ddname. A JCL DD statement with this ddname must beincluded in the job step containing the GENJCL.USER command.







GENJCL.USER


MULTIJOB | ONEJOBMutually exclusive, optional parameters you use to control how many JOBstatements are generated when a DBDS group is specified either explicitly orimplicitly.

MULTIJOBProcesses the skeletal JCL JOB member for each group member (multipleJOB statements are produced).

ONEJOBOnly processes the skeletal JCL JOB member for the first group member.

These parameters are invalid if NOJOB is specified or if a DBDS group is notspecified.

NODEFLTOptional parameter you use to specify that the implicit skeletal JCL defaultmember, if any, for the DBDS is not to be used. If you do not specify GROUPor DBD, this parameter is ignored.

PSB(name)Optional parameter you use to set the value of the %PSB keyword.

name can be any character string. It does not need to be an actual PSBddname. The maximum length of the name is eight characters.

If you do not specify PSB, the value of the %PSB keyword is null unless a valueis assigned in the USERKEYS parameter or a skeletal JCL default member.

TIMEFMT(sublist)Optional parameter you use to define the form in which time stamps appear inuser-defined output. This specification overrides both the GENJCL default valuesand any values set on %SET statements in the input skeletal JCL.

The default for the GENJCL output time format is compressed, with a two-digityear, and the offset in numeric form: 960021315001 +0700. If you want theoutput time stamps to appear without offsets, for example, you can override thedefault with TIMEFMT(,N).

The override is good only for the duration of a single GENJCL command.

Related Reading:

v The TIMEFMT parameter sublist format is described in “TIMEFMT ParameterSublist” on page 102.

v See “TIMEFMT Subparameter Order of Precedence” on page 104 forinformation on the precedence of the subparameters.

v See “Standard Time Stamp Format” on page 101 for examples of thedifferent output forms.

SSID(name)Optional parameter used to set the value of the %SSID keyword.

name can be any character string. It does not need to be an actual IMSsubsystem ID. The maximum length of the name is eight characters.

If the SSID parameter is not specified, the value of the %SSID keyword is null,unless a value is assigned in the USERKEYS parameter or a skeletal JCLdefault member.


GENJCL.USER


%key1User-defined keyword being assigned a value. The maximum length of thekeyword is eight characters, including the percent sign. The first characterafter the percent sign must be alphabetic (A-Z). The remaining charactersmust be alphanumeric (A-Z, 0-9).





Example of Running DBRCIn this example, the GENJCL.USER command generates JCL from member USER4 inthe data set that is identified in DD statement MYJCLPDS. Output from thegenerated JCL goes to the data set identified in DD statement JCLOUT.Substitutions for %SSID, %DBNAME and %DDNAME should be made. Skeletal memberJOBJCL produces a job statement.//GENUSER JOB//JCLOUT DD//MYJCLPDS DD//SYSIN DD *

GENJCL.USER MEMBER(USER4) JCLPDS(MYJCLPDS) DBD(DHONTZ04) -SSID(IMSA) DDN(HIDAM)

The following example shows the member USER4 that is to be executed:/ ADD LIST=ALL,NAME=USER4,LEVEL=01,SOURCE=0/ NUMBER NEW1=00000100,INCR=100//*******************************************************//* MEMBER NAME = USER4 *//* (SSID) SHOULD BE SUBSTITUTED IN LIST.SUBSYS COMMAND *//* (DBNAME) SHOULD BE SUBSTITUTED IN LIST.DBDS COMMAND *//* (DDNAME) SHOULD BE SUBSTITUTED IN LIST.DBDS COMMAND *//*******************************************************//USER4 EXEC PGM=DSPURX00//SYSPRINT DD SYSOUT=A//SYSIN DD *

LIST.SUBSYS SSID(%SSID) /* (SSID) SHOULD BE SUBSTITUTED */LIST.DBDS DBD(%DBNAME) DDN(%DDNAME) -

/* (DBNAME) and (DDNAME) SHOULD BE SUBSTITUTED *//*

GENJCL.USER


Chapter 12. INIT Commands

INIT.ADS

OO INIT.ADS ADDN(name) ADSN(name) AREA(name) DBD(name)UNAVAIL

AVAILOP

Use an INIT.ADS command to create an entry in RECON that defines an ADS (areadata set) that belongs to an area. An area can consist of a maximum of seven datasets.

Before you issue the INIT.ADS command, you must create the area and databaserecords in RECON. If the ADDN or ADSN names are not unique for this area, theINIT.ADS command fails. In addition, the INIT.ADS command fails if the specifiedarea is not registered in RECON.

When you register the area with an INIT.DBDS command, the area status is set as“recovery needed” to prevent inadvertent use by the IMS online system before youhave completed registration of the required ADSs. You can create the ADS recordsin RECON, but only if you use the INIT.ADS command with the default UNAVAILparameter. You must to first issue a CHANGE.DBDS command for the area, specifyingthe NORECOV option to make the status of the ADS immediately available (withINIT.ADS with the AVAIL parameter).


Required parameter you use to identify the ADS that is being identified toDBRC by its ddname.

ADSN(name)Required parameter you use to identify the ADS that is being identified toDBRC by its data set name.

AREA(name)Required parameter you use to identify the area name for which an ADS isbeing identified to DBRC.

DBD(name)Required parameter you use to identify that area by database name for whichan ADS is being identified to DBRC.

AVAIL | UNAVAILMutually exclusive, optional parameters you use to indicate whether the ADSrecord is available.

AVAILMakes the ADS status available. The INIT.ADS AVAIL command fails if youissue it when the area is in use or if the area needs to be recovered.

UNAVAILMakes the ADS status unavailable.


Example of Creating a Record That Defines an ADSIn this example, a record is created in RECON that identifies an ADS.//INITADS JOB

...

//SYSIN DD *INIT.ADS DBD(DBD03) AREA(AREA03) -

ADDN(AREADDN1) ADSN(AREADSN2)/*

INIT.CA

OO INIT.CA CADSN(name) GRPNAME(name) S

,

VOLLIST( volser ) O

O1

FILESEQ( value )3400

UNIT( unittype )

OP

Use an INIT.CA command to create a record in RECON that identifies a changeaccumulation data set that is available for future use by the Change Accumulationutility in processing the specified CA group. You can create such changeaccumulation records only for those CA groups that have been defined with theREUSE option of the INIT.CAGRP command. You can create change accumulationrecords in RECON up to the number specified in the GRPMAX parameter of theINIT.CAGRP command that you used to define the CA group.

ParametersCADSN(name)

Required parameter you use to specify the name of the change accumulationdata set for which you are creating a record in RECON. The name yousubstitute in the variable field can be up to 44 characters. You can use thedefault naming convention for change accumulation data sets to assign thisname.

GRPNAME(name)Required parameter you use to specify the name of the CA group for which youare creating the record. The GRPNAME keyword must specify the name of aCA group that is already defined in RECON.

VOLLIST(volser)Required parameter you use to specify the volume serial numbers of thevolumes on which the change accumulation data set being defined are toreside. You can substitute from 1 to 255 volume serial numbers in the variablefield; each can be up to six alphanumeric characters long, and they must followMVS JCL conventions for volume serial numbers.

FILESEQ(1 | value)Optional parameter you use to specify the file-sequence number of the changeaccumulation data set that is being defined.

value must be a decimal number from 1 to 9999.

INIT.ADS


UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the volumes on which thechange accumulation data sets are to reside. The unit type can be up to eightalphanumeric characters.

Example of Creating a Record That Defines a CA Data SetIn this example, a record is created in RECON that identifies a changeaccumulation data set (identified by the CADSN parameter). This changeaccumulation data set is being created for use by a subsequent run of the ChangeAccumulation utility for the CA group identified in the GRPNAME parameter.Creation of this record implies that the identified CA group was defined with aREUSE parameter.//INITCA JOB

...

//SYSIN DD *INIT.CA GRPNAME(CAGRP1) -

CADSN(IMS.CAGRP1.CA.CA001) -VOLLIST(VOL001) FILESEQ(4)

/*

INIT.CAGRP

OO INIT.CAGRP GRPMAX(value) S

,

GRPMEM( (dbdname,ddname) ) GRPNAME(name) O

OCAJCL

CAJCL( member )DEFLTJCL( DEFLTJCL )

member

NOREUSE

REUSEOP

Use an INIT.CAGRP command to specify the DBDSs that are to belong to aspecified CA group. You must have created a record in RECON with an INIT.DBDScommand for each DBDS in the CA group before you assign it to a CA group. EachDBDS can belong to only one CA group.

Restriction: Index and ILDS DBDSs are not recoverable, and changes to themare not logged. The INIT.CAGRP command does not support these data sets.

ParametersGRPMAX(value)

Required parameter you use to specify the maximum number of changeaccumulation data sets that DBRC is to maintain for the specified CA group.value must be a decimal number from 2 to 1024.

When the number of times you run the Change Accumulation utility for thespecified group exceeds the GRPMAX value, the record of the earliest changeaccumulation run for the group is deleted if you specify the NOREUSE keywordfor this CA group. The record of the earliest change accumulation run is reusedif you specify the REUSE keyword for this CA group.

INIT.CA

Chapter 12. INIT Commands 223

GRPMEM(dbdname,ddname)Required parameter you use to specify the names of the DBDSs that are to bemembers of the CA group you are defining.

There can be from 1 to 2000 members in a CA group. The names yousubstitute in the variable field must be pairs of names enclosed in parentheses,where dbdname is the database name of the DBDS, and ddname is its data setddname.

GRPNAME(name)Required parameter you use to specify the name of the CA group beingcreated. name can be up to eight alphanumeric characters, and it must not bethe same as the name of a CA group that already exists in RECON.

CAJCL(CAJCL | member)Optional parameter you use to specify the name of a member of a partitioneddata set of skeletal JCL. You create this member to be used to generate theJCL required to run the Change Accumulation utility for the CA group beingcreated.

DEFLTJCL(DEFLTJCL | member)Optional parameter you use to specify an implicit skeletal JCL default memberfor the CA group. The specified member is used by the GENJCL.CA command toresolve keywords you have defined.

NOREUSE | REUSEMutually exclusive, optional parameters you use to specify whether the changeaccumulation data sets for the CA group being defined can be reused.

REUSEIndicates that the Change Accumulation utility is to reuse the oldest changeaccumulation data set and record (for the group being defined) when theGRPMAX value for the group is exceeded. Reuse means that the ChangeAccumulation utility uses the same physical space, volumes, data set name,and record in RECON for the new change accumulation data set as wereused for the oldest change accumulation data set in the group.

NOREUSEIndicates that the change accumulation data sets in this group are not to bereused by the Change Accumulation utility.

Example of Creating a CA GroupIn this example, a CA group is being created. A maximum of 15 changeaccumulation data sets are to be maintained for this group. (This is indicated in theGRPMAX parameter.) The NOREUSE parameter indicates that changeaccumulation data sets for this group are not to be reused by the ChangeAccumulation utility when the GRPMAX value has been reached. That parameteralso implies that empty change accumulation data sets cannot be defined for thisgroup for use in future runs of the Change Accumulation utility.//INITCAGP JOB

...

//SYSIN DD *INIT.CAGRP GRPNAME(CAGRP1) GRPMAX(15) NOREUSE -

GRPMEM((DB1,DD1) (DB2,DD2) (DB3,DD3) -(DB4,DD4) (DB5,DD5) (DB6,DD6) (DB7,DD7) -(DB8,DD8) (DB9,DD9) (DB10,DD10))

/*

INIT.CAGRP


INIT.DB

OO INIT.DB DBD(name)RECOVABL

NONRECOV

0SHARELVL( 1 )

23

TYPEIMS

TYPEFP

TYPHALDB

O

OGSGNAME(gsgname)

DBTRACK

RCVTRACK PARTSEL(pgmname)OP

Use an INIT.DB command to register a database with DBRC and specify the levelof database sharing. A database must be registered with DBRC before you caninitialize a new DBDS, HALDB partition, or DEDB area with the INIT.DBDScommand or INIT.PART.

When registering a TYPHALDB, the IMS DBDLIB data set must be identified in thejob stream for the Recovery Control utility with a ddname of IMS.

Restriction for HALDBs: You must use the HALDB Partition Definition utility toupdate or delete information about HALDBs in the RECON data set. The IMSDBDLIB data set must be identified in the job stream for the RECOVERY Controlutility with a ddname of IMS.

ParametersDBD(name)

Required parameter you use to specify the database name of the database tobe registered in RECON.

DBTRACK | RCVTRACKMutually exclusive, optional parameters that specify the type of tracking(shadowing) for a database that is assigned to a global service group.

Restrictions:

v Neither RCVTRACK nor DBTRACK can be specified without GSGNAME.

v Neither RCVTRACK nor DBTRACK can be specified if a TYPEFP isspecified.

v Specifying DBTRACK has no effect if the tracking subsystem is a recoveryreadiness level (RLT) subsystem.

DBTRACKIndicates database readiness tracking.

RCVTRACKIndicates recovery readiness tracking.

GSGNAME(gsgname)Optional parameter used to specify to which global service group a database isto be assigned.

GSGNAME cannot be specified if TYPEFP is specified.

NONRECOV | RECOVABLMutually exclusive, optional parameters used to specify whether DBRC can

INIT.DB


||||

||

||||

record the updates in the RECON for the data sets of the specified databases.These parameters are meaningful for TYPEIMS databases only, and they arerejected for TYPEFP databases.

If the database is registered as RECOVABL, VIO data sets cannot be used forthe output log (IEFRDER) in any job that updates the database. Temporary logdata sets, such as VIO data sets, are deleted at job termination, so they are notusable for recovery.

NONRECOVSpecifies that no record of the updates for the data sets of the specifieddatabase are to be kept in the RECON.

RECOVABLSpecifies that the update allocations on the database are to be written inthe RECON.

Restrictions:

v NONRECOV cannot be specified if GSGNAME is specified.

v Fast Path DEDBs are never registered as nonrecoverable.

v You cannot make concurrent image copies of nonrecoverable databases.

PARTSEL (pgname)Optional parameter that identifies a user Partition Selection Exit program namefor TYPHALDB. Specified as a value up to 8 characters long that is a validprogram name. If not specified, the Partition Selection Exit name is obtainedfrom the DBD (if one was specified).

SHARELVL(0 | 1 | 2 | 3)Optional parameter you use to specify the level of data sharing for whichauthorized subsystems can share a database. For a description of the levels ofdata sharing, see “Assigning a Sharing Level with DBRC” on page 20.

Restriction:

v You must specify a SHARELVL of 1, 2, or 3 for concurrent image copies.

v If you are using IRLM, and have specified SHARELVL 2 or 3, ensure that theVSAM SHAREOPTIONS (3 3) parameter is also specified.

For more information on coordinating VSAM data set definitions with shareoptions, see IMS Version 7 Administration Guide: System.

TYPEFP | TYPEIMS | TYPEHALDBMutually exclusive, optional parameters you use to specify whether thedatabase is a Fast Path DEDB or a HALDB.

TYPEFPSpecifies that the database is Fast Path DEDB.

TYPEIMSSpecifies that the database is a DL/I database (non-HALDB).

TYPEHALDBSpecifies that the database is a DL/I database (HALDB).

Example of Creating a SHARELVL 1 DB RecordIn this example, a new database record is created in RECON. This database has ashare level of 1.

INIT.DB


|||||

|||

||

||

||

|

//INITDB JOB

...

//SYSIN DD *INIT.DB DBD(THISDB) SHARELVL(1) TYPEFP

/*

INIT.DBDS

Use an INIT.DBDS command to register a DBDS or DEDB area. The DBDS mustexist for any of the other commands to work for a given DBDS or DEDB area. Inorder to register the DBDS, DBRC examines the IMS DBDLIB data set to:

v Verify that the DBDS or DEDB area exists.

v Obtain the DBDS’s data set identifier (DSID), its data set organization, and itsdatabase organization.

The IMS DBDLIB data set must be identified in the job stream for the RecoveryControl utility with a ddname of IMS.

The INIT.DBDS command fails if you issue it while the database is in use.

After registering the database data set, use the Image Copy utility to create abackup copy.

Restriction for HALDBs: You must use the HALDB Partition Definition utility toupdate or delete information about HALDBs in the RECON data set. You cannotuse the INIT.DBDS command to register DBDSs of HALDBs.

ParametersDBD(name)

Required parameter you use to specify the database name of the DBDS orDEDB area being identified to DBRC.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to specify the ddname of theDBDS or DEDB area being identified to DBRC.

OO INIT.DBDS DBD(name) DDN(name)AREA(name)

DSN(name) GENMAX(value)DBTRACK

RCVTRACK DEFLTJCL(member)O

OGSGNAME(gsgname) ICJCL

ICJCL( member )

NOREUSE

REUSE OICJCLOICJCL( member )

NOPREO

PREOPENO

ORECOVJCL

RECOVJCL( member )0

RECOVPD( value )RECVJCL

RECVJCL( member )

O

ONOVSO

NOLKASID NOPRELVSO

CFSTR1(name) CFSTR2(name) LKASID PRELOAD

OP

INIT.DB


|||

DSN(name)Required parameter you use with the DDN(name) parameter to specify the dataset name of the DBDS being identified to DBRC. You cannot use this parameterwith a DEDB area.

If the DBDS is an ADS that is registered to DBRC, do not specify thisparameter. Instead specify the data set name in the INIT.ADS command.

GENMAX(value)Required parameter you use to specify the maximum number of image copiesthat DBRC is to maintain for the identified DBDS.

Each time you run the Database Image Copy utility for the DBDS that is beinginitiated, a new image copy is defined in RECON. If you identified the DBDSwith the NOREUSE parameter, the oldest image copy for the DBDS beyond therecovery period is deleted when the number of image copies exceeds theGENMAX value. If you identify the DBDS with the REUSE parameter, the oldestimage copy beyond the recovery period is reused.


DBTRACK | RCVTRACKMutually exclusive, optional parameters you use to specify the type of RSRtracking (shadowing) for an area that is assigned to a global service group.Neither RCVTRACK nor DBTRACK can be specified without GSGNAME andAREA.

Specifying DBTRACK has no effect if the tracking subsystem is arecovery-readiness level (RLT) subsystem.



DEFLTJCL(member)Optional parameter you use to specify an implicit skeletal JCL default memberfor the DBDS. The specified member is used by the GENJCL.IC, GENJCL.OIC,and GENJCL.RECOV commands in order to resolve keywords you have defined.

GSGNAME(gsgname)Optional parameter used to specify to which global service group a database isto be assigned.

GSGNAME can only be specified if AREA is specified.

ICJCL(ICJCL | member)Optional parameter you use to specify the name of a member of a partitioneddata set that contains skeletal JCL. When you issue a GENJCL.IC command,DBRC uses this member to generate the JCL to run the Database Image Copyutility for the DBDS or DEDB area being identified.

NOREUSE | REUSEMutually exclusive, optional parameters you use to specify whether thesupported image copy utilities are to reuse previously used image copy datasets.

REUSEAllows the GENJCL.IC command or the GENJCL.OIC command to generate ajob that causes the supported image copy utilities to reuse the oldest imagecopy data set (for the DBDS being defined) when the GENMAX value forthe DBDS is exceeded. REUSE requires that you create empty image copy

INIT.DBDS


data sets for future use by the supported image copy utilities. In addition,you must use INIT.IC commands to record their existence in RECON. TheNOREUSE parameter prohibits such actions.

NOREUSEPrevents the automatic reuse of image copy data sets for this DBDS by thesupported image copy utilities.

If the NOREUSE option is specified for the HISAM database, theimage-copy-needed flag is not turned on at the end of the HISAM Reloadutilities. The input data set that is used while the HISAM database is beingreloaded is used as an image copy data set.

If you want HSSP image copy processing, you must specify REUSE. Reusemeans that the image copy job uses the same volumes, data set name, andrecord in RECON for the new image copy data set as those of the oldest DBDSimage copy data set.

OICJCL(OICJCL | member)Optional parameter you use to specify the name of a member of a partitioneddata set that contains skeletal JCL. You cannot use this parameter with a DEDBarea. When you issue a GENJCL.OIC command, DBRC uses this member togenerate the JCL to run the Online Database Image Copy utility for the DBDSbeing identified.

PREOPEN | NOPREOMutually exclusive, optional parameters you use to specify whether an area isto be opened after the first checkpoint following the next control regioninitialization or when the next /START AREA command is processed. NOPREO isthe default, except if you specify PRELOAD, in which case PREOPEN is thedefault.

PREOPENIndicates that the area is to be opened the next time the control region isstarted or a /STA AREA command is processed. This option is valid for bothVSO and non-VSO areas.

NOPREOIndicates that the area is not to be pre-opened the next time the controlregion is started or a /START AREA command is processed. You cannotspecify NOPREO with PRELOAD.

RECOVJCL(RECOVJCL | member)Optional parameter you use to specify the name of a member of a partitioneddata set of skeletal JCL. When you issue the GENJCL.RECOV command, DBRCuses this member to generate the JCL that runs the Database Recovery utilityfor the DBDS or area being identified.

RECOVPD(0 | value)Optional parameter you use to specify the recovery period of the image copiesfor a specified DBDS or DEDB area.

The recovery period is the current date minus the date of the oldest imagecopy. If the image copies are dated within the days specified in theRECOVPD(value), DBRC keeps them in the RECON.

For value, specify a decimal number from 0 to 999 that represent the number ofdays the image copies are to be kept in RECON. If you specify 0 (the default),there is no recovery period.

Related Reading:

INIT.DBDS


See IMS Version 7 Operations Guide for more information about the recoveryperiod of image copy data sets.

RECVJCL(RECVJCL | member)Optional parameter you use to specify the name of the skeletal JCL member tobe used by the GENJCL.RECEIVE command.

RECVJCL can be specified for both RSR-covered and non-covered DL/I DBDSsand Fast Path areas.

VSO | NOVSOMutually exclusive, optional parameters you use to specify whether an area isto reside in virtual storage the next time the control region is initialized or whenthe next /STA AREA command is processed.

VSOIndicates that the area is to reside in virtual storage. Areas that are definedwith SHARELVL(0 | 1) are read into and written from an MVS data space.Areas defined with SHARELVL(2 | 3) use the coupling facility to share databetween connected subsystems.

NOVSOIndicates that this area is not to reside in virtual storage.

CFSTR1(name)Optional parameter you use to specify the name of the first couplingfacility structure for the identified area. MVS coupling facility structurenaming conventions must be adhered to. This parameter is valid onlyfor VSO areas of DEDBs that are defined with SHARELVL(2 | 3). Thearea name is the default if VSO is specified and the DEDB isSHARELVL(2 | 3).

CFSTR2(name)Optional parameter you use to specify the name of the second couplingfacility structure for the identified area. MVS coupling facility structurenaming conventions must be adhered to. This parameter is valid onlyfor VSO area of DEDBs defined with SHARELVL(2 | 3). There is nodefault, and the name cannot be the area name if the CFSTR1 keywordis not specified.

Related Reading: See IMS Version 7 Administration Guide: DatabaseManager for details on CFSTR (coupling facility structure) namingconventions.

LKASID | NOLKASIDMutually exclusive optional parameters you use to specify whether localdata caching for the specified area is to be used for buffer lookaside onread requests. The LKASID option is valid only for SHARELVL(2 | 3)VSO areas.

LKASIDIndicates that buffer lookaside is to be performed on read requestsfor this area.

NOLKASIDIndicates that buffer lookaside is not to be performed on readrequests for this area.

PRELOAD | NOPRELMutually exclusive, optional parameters you use to specify whether aVSO area is to be loaded the next time it is opened.

INIT.DBDS


PRELOADIndicates that the area is to be loaded into an MVS data space thenext time it is opened. Selecting this option also causes the area tobe pre-opened.

NOPRELIndicates that the area is not to be loaded into an MVS data spacethe next time it is opened. For VSO areas, CIs are copied into adata space when they are read for the first time.

Example of Identifying the DBDS to Initiate DBRC’s Control OverRecovery

In this example, a DBDS is registered with DBRC. The IMS DD statement isrequired to allow access to the IMS DBDLIB data set to obtain the data setidentifier, data set organization, and database organization of the DBDS. The DBDSis identified by the DBD, DDN, and DSN parameters and it is accessed only by anIMS system, its image copy data sets can be reused, and the maximum number ofimages that DBRC is to maintain for it is 2. The ICJCL parameter specifies themember of the partitioned data set of skeletal JCL that is to be used for thegeneration of JCL for the Database Image Copy utility. The RECOVJCL parameterdoes the same for the Database Recovery utility.//INITDBDS JOB

...

//IMS DD DSN=IMS.DBDLIB,DISP=SHR//SYSIN DD *

INIT.DBDS DBD(DBD002) DDN(DDN003) GENMAX(2) REUSE -ICJCL(ICJCLX) RECOVJCL(RECOVJCX) DSN(DSN003)

/*

INIT.DBDSGRP

OO INIT.DBDSGRP GRPNAME(name) S

S

S

,

MEMBERS( (dbname,ddname) ),

DBGRP( dbname ),

RECOVGRP( (dbname ) ),areaname

OP

Use an INIT.DBDSGRP command to define a group of these types:

v DBDS group (DBDSs or DEDB areas)

v DB group (DL/I databases or DEDB areas)

v Recovery group (DL/I databases or DEDB areas)

A DBDS group can be used anywhere that a DB group can be used, such as forthe /DBR command, but this usage is inefficient. Preferably define a separate DBgroup for such use.

INIT.DBDS


A recovery group is used with ORS recoveries. It can also be used anywhere that aDB group can be used.


Required parameter you use to identify the DBDSGRP to be created. The namecan be from one to eight alphanumeric characters, and must not be the nameof an existing DBDSGRP or CAGRP record.

MEMBERS(dbname,ddname) | DBGRP(dbname) |RECOVGRP(dbname,areaname)

Mutually exclusive, required parameters that identify the members to beincluded in the new group. A group can contain up to 2000 members.

MEMBERS(dbname,ddname)Indicates that the group is a DBDS group. This parameter identifies one ormore DBDSs or DEDB areas, each by a pair of names enclosed inparentheses, where dbname is the database name and ddname is the DDstatement name or the DEDB area name.

Any member can belong to more than one DBDS group.

DBGRP(dbname)Indicates that the group is a DB group, and identifies one or moredatabases or area names. Any member can belong to more than one DBgroup.

RECOVGRP(dbname,areaname)Indicates that the group is a recovery group. A recovery group is a group offull-function databases, HALDB databases, or DEDB areas that youconsider to be related. Partition databases and Fast Path databases cannotbelong to a recovery group. If you use Online Recovery Service (ORS) toperform a TSR (Time Stamp Recovery) on one of the members of thegroup, ORS requires you to recover all members of the group to the sametime. A recovery group otherwise can be used like a DB group.

RECOVGRP identifies one or more DBs or DEDB areas. If a DEDB area isto be added to the recovery group, both dbname and areaname must bespecified. Otherwise, areaname must not be specified. A database or areacan belong to only one recovery group. If any of the members specified byRECOVGRP already belongs to another recovery group, the commandfails.

Example of Creating a Group of DBDSsIn this example, a group of DBDSs is defined.//INITDBGRP JOB

...

//SYSIN DD *INIT.DBDSGRP GRPNAME(DBDSG1) -

MEMBERS((DB1,DD1),(DB2,DD2),(DB3,DD3))/*

INIT.DBDSGRP


||||||||

||||||

INIT.GSG

OO INIT.GSG GSGNAME(gsgname)SEQNUM(number)

OP

Use an INIT.GSG command to define a global service group (GSG). The GSG mustbe defined in every RECON which is to be used by any IMS subsystem in theGSG.



Required parameter you use to specify the name of the GSG you want tocreate.

SEQNUM(number)Optional parameter you use to specify the initial DSN sequence number for theGSG you want to create. If you do not specify a SEQNUM parameter, the GSGDSN SEQ NUMBER is set to zero (0). This value is used to create uniquetracking log data set names. If you have deleted an old GSG and are nowcreating a new GSG with the same name, specify a SEQNUM equal to thevalue of the last DSN SEQ NUMBER of the old GSG. Otherwise, the trackermight create logs that have data set duplicate names of previously created logs.

Example of Creating a Global Service GroupHere is an example of using the INIT.GSG command.//INITGSG JOB...

//SYSIN DD *INIT.GSG GSGNAME(IMSGSG1)/*

INIT.ICUse an INIT.IC command to create image copy records in RECON. These image

copy records define image copy data sets that are available for use duringsubsequent runs of the supported image copy utilities.

OO INIT.IC DBD(name) DDN(name)AREA(name)

ICDSN(name)1

FILESEQ( value )1

FILESEQ2( value )

O

OICDSN2(name) 3400

UNIT( unittype )3400

UNIT2( unittype )S

,

VOLLIST( volser )

O

O

S

,

VOLLIST2( volser )

OP

INIT.GSG


Each INIT.IC command creates one image copy record. You can define imagecopy data sets for subsequent use only if you have specified a REUSE parameterfor the corresponding DBDS or DEDB area when it was identified in RECON withan INIT.DBDS command. The maximum number of image copy records that are tobe used for a given DBDS or DEDB area is determined by the value of GENMAXfor the specified DBDS or DEDB area.

ParametersDBD(name)

Required parameter you use to identify the image copy data set being createdby the database name of its related DBDS or DEDB area.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify the image copy dataset being created; nameis the data set ddname of the related DBDS or DEDBarea.

ICDSN(name)Required parameter you use to specify the name of the image copy data set forwhich the image copy record is being created. name can be up to 44characters. You can use the default-naming convention for image copy datasets for this name.

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of the imagecopy data set for which the image copy record is being created. You can specifythis parameter only if you specify a VOLLIST parameter, and only if the filesequence number is not 1. value must be a decimal number from 1 to 9999.

FILESEQ2(1 | value)Optional parameter you use to specify the file-sequence number of theduplicate image copy data set for which the image copy record is being created.You can specify this parameter only if you are creating a duplicate image copydata set, if you specify a VOLLIST2 parameter, and if the file-sequence numberis not 1. The value you substitute in the variable field must be a decimalnumber from 1 to 9999.

ICDSN2(name)Optional parameter you use to specify the name of the duplicate image copydata set for which the image copy record is being created. name can be up to44 characters. You can use the default naming convention for duplicate imagecopy data sets for this name.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the image copy data setbeing defined. The unit type can be up to eight alphanumeric characters long.

If you specify the UNIT parameter, you must also specify the VOLLISTparameter.

UNIT2(3400 | unittype)Optional parameter you use to specify the unit type of the duplicate image copydata set being defined. The unit type can be up to eight alphanumericcharacters.

VOLLIST(volser)Optional parameter you use to specify the list of volumes on which the imagecopy data set resides when it is used by the supported image copy utilities.

INIT.IC


Each volume serial number you substitute in the variable field can be up to sixalphanumeric characters. The volume serial list can contain from 1 to 255volume serial numbers.

VOLLIST2(volser)Optional parameter you use to specify the list of volumes on which the duplicateimage copy data set (identified with the ICDSN2 parameter) resides when it isused by the supported image copy utilities. Each volume serial number yousubstitute in the variable field can be up to six alphanumeric characters. Thevolume serial list can contain from 1 to 255 volume serial numbers.

Example of Creating a Record That Defines the ICDSNIn this example, a record is created in RECON that defines an image copy data setthat is to be used for creating an image copy of the DBDS. The name of the imagecopy data set is specified in the ICDSN parameter; in this example, the defaultnaming convention is used to generate the fully qualified data set name. Thevolume on which the image copy data set is to reside is specified by the VOLLISTparameter. and its file-sequence number is specified by the FILESEQ parameter.//INITIC JOB...

//SYSIN DD *INIT.IC DBD(DB1) DDN(DD1) -

ICDSN(IMS.*.ICDSN2) -VOLLIST(VOL003) FILESEQ(5)

/*

INIT.PART

OO INIT.PART DBD(name) PART(name)KEYSTRING string

hex_string

O

O DSNPREFX(string)RANDOMZR(name) ANCHOR(value) HIBLOCK(value)

O

OBYTES(value) 0

FBFF( value )0

FSPF( value )

O

O

S

,

BLOCKSIZE ( 4096 )value

2GENMAX( value )

O

ODEFLTJCL(member) ICJCL

ICJCL( member )OICJCL

OICJCL( member )

O

INIT.IC


|

||||||||||||||||||||||||

||||||||||||||||||||||||||||

||||||||||||||||||||||||||||||||||||||||||||

|||||||||||||||||||||||||||||||||||||||||||||

||||||||||||||||||||||||||||||||||||||||||||

||

ONOREUSE

REUSE RECOVJCLRECOVJCL( member )

O

O0

RECOVPD( value )RECVJCL

RECVJCL( member )

OP

Use an INIT.PART command to register a HALDB Partition. The INIT.PARTcommand creates the RECON HALDB partition structure (a PART record, thepartition DB record and one or more DBDS records according to the DBDspecification). The INIT.PART command will fail if the HALDB is being used by theHALDB Partition Definition utility. The IMS DBDLIB data set must be identified in thejob stream for the Recovery Control utility with a ddname of IMS.

Some parameters (identified below in the parameter description) apply to all thepartition DBDSs created as a result of this command. This differs from the HALDBPartition Definition utility where these parameters may be specified separately foreach partition DBDS being created. These parameters can later be changedindividually with the CHANGE.DBDS command.

ParametersDBD (name)

Required parameter used to identify the HALDB for which the partition is to bedefined.

PART (name)Required parameter used to identify a HALDB partition name. Specified as analphanumeric value, up to 7 characters long, with the first character beingalphabetic.

KEYSTRNG (char value or hex value)Optional parameter you use to specify a HALDB partition high key value or aselection string for use by a partition selection exit. Specified as a charactervalue up to 256 characters long or a hexadecimal value up to 512 characterslong. Character values must be alphanumeric (with no embedded blanks orcommas unless the string is enclosed by single quotes). Unless enclosed bysingle quotes, the character string will be folded to uppercase. Hexadecimalvalues must be enclosed by single quotes and preceded by the letter X, forexample: KEYSTRING(X’D7C1D9E3D2C5E8’).

If no partition selection routine was specified in the HALDB master definition,KEYSTRING defines the Partition high key and is required. The high key lengthcannot be longer than the root key length. If the high key length is less than thedefined root key length, the high key value is padded with hex ’FF’s up to thedefined root key length. The partition high key values must be unique for eachpartition within a HALDB.

If a partition selection routine was specified in the HALDB master definition,KEYSTRING defines a Partition Selection String which is passed to the partitionselection routine. Your installation partition selection routine may or may notrequire a Partition Selection String. If required, the content of the string isdetermined by your installation. It can be up to 256 bytes long and consist of

INIT.IC


|||||||||||||||||||||||||||||||

|

|||||||||||||||||||||||||||||||||||||

|

||||||

|||||

|

|||

||||

|||||||||

||||||

|||||

simple character information. If it contains non-printable characters, it must beidentified using hex notation. A hex character string is enclosed by singlequotation marks and prefixed with an X.

DSNPREFX (string)Required parameter you use to specify the data set name prefix for the partitiondata sets contained in a HALDB. Specified as a value, up to 37 characters long,that is a valid JCL data set name.

RANDOMZR (name)Optional parameter used to specify the name of the randomizing module forHALDB PHDAM databases only. If RANDOMIZR is omitted, the name of therandomizing module is obtained from the DBD. A randomizing module controlsroot segment placement in, or retrieval from, the PHDAM HALDB.

ANCHOR (value)Optional parameter used to specify the number of root anchor points (RAPs)desired in each control interval or block in the root addressable area of aPHDAM HALDB. The value specified must be between 1 and 255. Typicalvalues are from 1 to 5. If ANCHOR is omitted, the value is obtained from theDBD. This parameter is for PHDAM HALDBs only.

HIBLOCK (value)Optional parameter used to specify the maximum relative block number valuethat the user wishes to allow a randomizing module to produce for this HALDB.This value determines the number of control intervals or blocks in the rootaddressable area of an PHDAM HALDB. The value may range between 1 and16,777,215(2**24-1). If BYTES is omitted, the value is obtained from the DBD.This parameter is for PHDAM HALDBs only.

FBFF (0|value)Optional parameter used to specify the free block frequency factor (fbff) whichspecifies that every nth control interval or block in this data set group is left asfree space during database load or reorganization (where FBFF=n). The rangeof FBFF includes all integer values from 0 to 100 except 1. The default valuefor FBFF is 0.

FSPF (0|value)Optional parameter used to specify the free space percentage factor. It specifiesthe minimum percentage of each control interval or block that is to be left asfree space in this data set group. Value may be any number between 0 and 99.The default value for FSPF is 0.

BLOCKSIZE (4096|nnnnn)Optional parameter you use to specify the block size for OSAM data sets.Specify an even number no greater than 32,766. The block size value is usedfor OSAM only. The default is 4096. You may specify up to 10 values, one foreach data set group defined in the DBD. See the SIZE keyword on theDATASET statement in the chapter on Database Description (DBD) Generationin the IMS Version 7 Utilities Reference: Database and Transaction Manager forfurther information on specifying the block size for OSAM data sets (althoughDBDGEN is not used to define HALDB partitions).

GENMAX (2|value)Optional parameter you use to specify the maximum number of image copiesthat DBRC is to maintain for the partition DBDSs. If you identify a partitionDBDS with the NOREUSE parameter, the oldest image copy beyond therecovery period is deleted when the number of image copies exceeds theGENMAX value. If you identify it with the REUSE parameter, the oldest imagecopy beyond the recovery period is reused. Specified as a numeric value from 2

INIT.IC


|||

||||

|||||

||||||

|||||||

||||||

|||||

|||||||||

|||||||

to 255. All partition DBDSs will be created with this GENMAX value. TheCHANGE>DBDS command can be used to change this for individual partitionDBDSs. The default value for GENMAX is 2.

DEFLTJCL (member)Optional parameter you use to specify an implicit skeletal JCL default memberfor a HALDB Partition DBDS. The specified member is used by the GENJCL.IC,GENJCL.OIC, and GENJCL.RECOV commands in order to resolve keywordsyou have defined. All partition DBDSs will be created with this DEFLTJCLmember. The CHANGE.DBDS command can be used to change this forindividual partition DBDSs.

ICJCL (ICJCL|member)Optional parameter you use to specify the name of a member of a partitioneddata set that contains skeletal JCL. When you issue a GENJCL.IC command,DBRC uses this member to generate the JCL to run the Database Image Copyutility (or the Database Image Copy 2 utility) for the partition DBDS specified onthe GENJCL command. All partition DBDSs will be created with this ICJCLmember. The CHANGE.DBDS command can be used to change this forindividual partition DBDSs.

NOREUSE | REUSEMutually exclusive, optional parameters you use to specify whether thesupported image copy utilities are to reuse previously used image copy datasets.

NOREUSEREUSE allows the GENJCL.IC command or the GENJCL.OIC command togenerate a job that causes the supported image copy utilities to reuse theoldest image copy data set (for the DBDS specified on the GENJCLcommand) when the GENMAX value for it is exceeded. REUSE requiresthat you create empty image copy data sets for future use by the supportedimage copy utilities. In addition you must use an INIT.IC command to recordtheir existence in RECON.

NOREUSENOREUSE parameter prohibits such actions. All partition DBDSs will becreated with the parameter specified. The CHANGE.DBDS command canbe used to change this for individual partition DBDSs.

OICJCL (OICJCL| member)Optional parameter you use to specify the name of a member of a partitioneddata set that contains skeletal JCL. When you issue a GENJCL.OIC command,DBRC uses this member to generate the JCL to run the Online DatabaseImage Copy utility for the partition DBDS specified on the GENJCL command.All partition DBDSs will be created with this OICJCL member. TheCHANGE.DBDS command can be used to change this for individual partitionDBDSs.

RECOVJCL (RECOVJCL| member)Optional parameter you use to specify the name of a member of a partitioneddata set that contains skeletal JCL. When you issue the GENJCL.RECOVcommand, DBRC uses this member to generate the JCL to run the DatabaseRecovery utility for the partition DBDS specified on the GENJCL command. Allpartition DBDSs will be created with this RECOVJCL member. TheCHANGE.DBDS command can be used to change this for individual partitionDBDSs.

RECOVPD (0| value)Optional parameter you use to specify the recovery period of the image copies

INIT.IC


|||

|||||||

||||||||

||||

||||||||

||||

||||||||

||||||||

||

for a specified partition DBDS. Specify a numeric value from 0 to 999 thatrepresents the number of days the image copies are to be kept in RECON. Thedefault is 0 which means there is no recovery period. All partition DBDSs will becreated with this RECOVPD value. The CHANGE.DBDS command can be usedto change this for individual partition DBDSs.

RECVJCL(RECVJCL| member)Optional parameter you use to specify the name of the skeletal JCL member tobe used by the GENJCL.RECEIVE command. RECVJCL can be specified forboth RSR-covered and non-covered HALDB DBDSs. All partition DBDSs will becreated with this RECVJCL member. The CHANGE.DBDS command can beused to change this for individual partition DBDSs.

INIT.RECON

OO INIT.RECONNOCATDS

CATDS

COEX

NOCOEX

DASDUNIT(3400)

DASDUNIT ( unittype )O

ONOFORCER

FORCER

CHECK17

CHECK44NOCHECK

NOLISTDL

LISTDL

LOGRET(001)

LOGRET ( ’time_interval’ )O

OSSID(name)

NONEW

STARTNEW

TAPEUNIT(3400)

TAPEUNIT ( unittype ) UPGRADEOP

Use the INIT.RECON command to initialize the RECON for use by DBRC.

The RECON data sets must first be created using the AMS DEFINE CLUSTERcommand, and must be empty.

ParametersCATDS | NOCATDS

Mutually exclusive, optional parameters you use to indicate whether imagecopy, change accumulation, and log data sets are cataloged.

CATDSSpecifies that these data sets are cataloged. If the data set is allocated bythe catalog and the CATDS option is used, DBRC bypasses volume serialand file sequence verification for the data set.

In order for CATDS option to be effective, the data set must be cataloged,and volume serial information for the data set must be omitted from theJCL. If the data set is cataloged, CATDS is specified, and volume serialinformation is included in the JCL, DBRC ignores CATDS and allocates thedata set by the JCL. Normal volume serial and file sequence checkingoccurs.

If the data set is not cataloged, CATDS is not effective, and DBRC allocatesthe data set by the JCL, with volume serial and file sequence checking.

Attention: The CATDS option affects that restart of IMS from SLDS datasets. Because the CATDS option indicates the SLDSs are under the control

INIT.IC


|||||

||||||

|

of a catalog management system, the VOLSER is not passed back to IMSfor data set allocation. If the SLDS data sets are not cataloged, IMS restartfails.

NOCATDSSpecifies that these data sets, regardless of if they are cataloged, are not tobe treated as cataloged. DBRC verifies that the volume serial and filesequence numbers appearing in the job file control block are the same asthe information recorded in the RECON.

COEX | NOCOEXMutually exclusive, optional parameters you use to specify whether pre-version6 IMS can access a Version 7 RECON.

COEXEnables the access of the Version 7 RECON by pre-version 6 IMS, andimposes the same processing limitations on Version 7 as on pre-version 6when the local clock is changed (for example, as for daylight savings time).

Attention: CHANGE.RECON COEX enables you to reverse the setting ofNOCOEX. There is no harm done as long as the local time has notchanged since coexistence was disabled. Otherwise, serious malfunctionscould occur in your pre-version 6 systems. IMS makes no attempt to protectyou from the harm done by a local time change.

NOCOEXUsed if you never intend to run any pre-version 6 jobs against the RECON(including fall back to pre-version 6 after encountering a problem withVersion 7). NOCOEX disables coexistence so that there are no limitationson Version 7 processing when the local clock is changed. You should besure of the appropriateness of your decision to use the NOCOEX keyword.It is possible to reverse but see the attention statement above.

DASDUNIT(unittype)Optional parameter you use to specify the unit type of the DASD device holdingthe records for log data sets. The unit type can be up to eight alphanumericcharacters long.

If you do not use this parameter to specify a DASD device, then the INIT.RECONcommand defaults to DASD unit type 3400.

FORCER | NOFORCERMutually exclusive, optional parameters you use to specify whether all IMSdatabases must be registered in RECON.

FORCERSpecifies that all databases must be registered. If you specify FORCER anda job attempts to access an unregistered database, the databaseauthorization call from IMS to DBRC fails.

NOFORCERSpecifies that databases need not be registered.

CHECK17 | CHECK44 | NOCHECKMutually exclusive, optional parameters you use to change the type of log dataset name comparison that DBRC does.

CHECK17Verifies that the last 17 characters of a log data set name are consistentwith RECON. If the name in RECON does not match the names on theappropriate ddname, the utility stops.

INIT.RECON


CHECK44Verifies that the 44-character log data set name is consistent with RECON.If the name in RECON does not match the name on the appropriate logddname, the utility is stops.

NOCHECKUsed if the data set name specified as input to the Database Recoveryutility is longer than 17 characters and has a new high-level qualifier. DBRCdoes not compare the log data set name recorded in RECON with thename on the appropriate ddname.

LOGRET(time_interval)Optional parameter you use to specify the retention period for log data sets.

Definitions:

v The retention period is the minimum amount of time in which a log becomesinactive after it is opened. (It is then eligible to be deleted.)

v The time_interval is a partial, punctuated time stamp representing a timeinterval (days, hours, minutes, and seconds) rather than a date and time. Thetime stamp has the following format:ddd|hh|mm|ss|t

ddd Number of days (000 to 365)

hh Number of hours (0 to 23)

mm Number of minutes (0 to 59)

ss Number of seconds (0 to 59)

t Tenths of a second (0 to 9)

The punctuation for the time stamp (shown in the above format as a vertical bar(|)) can be any non-numeric character, such as a period (.) or a comma (,). Thetime stamp must be enclosed in single quotes (’) if it contains any blanks orspecial characters. The number of days must include any leading zeros, but youcan omit trailing zeros. Valid intervals range between a tenth of a second and365 days. The default value, 001, is 24 hours.

Because the time interval is treated as a time stamp, message DSP0106I canbe issued for incorrect values. Some examples of valid time intervals include:LOGRET(365)LOGRET('030 12.00')LOGRET('000 00:00:08.0')LOGRET('000 00,00,00,1')

Two different valid formats for equivalent time stamp specifications are shown.LOGRET(030) LOGRET('030') = 30 daysLOGRET('010 12,30') LOGRET('01 12:30') = 10 days, 12 hours, 30 seconds

If you do not use this parameter to specify a retention period, then theINIT.RECON command defaults to a period of 001 (24 hours).

Related Reading:

v See “DELETE.LOG (for RLDS and SLDS)” on page 178 for more informationon deleting inactive logs.

INIT.RECON


v See “Standard Time Stamp Format” on page 101 for more information ontime stamps.

LISTDL | NOLISTDLMutually exclusive, optional parameters you use to specify whether data setnames deleted from the RECON (by DELETE.LOG command or by an archive joblog compression) are listed in the job output. The setting specified on thiscommand can be overridden by the DELETE.LOG command. There is no way tooverride the setting for log compression during an archive job.

LISTDLSpecifies that names of deleted data sets are to be listed in the job output.

NOLISTDLSpecifies that names of deleted data sets are not to be listed in the joboutput.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem that is tobe used as the default subsystem ID for the following commands:

CHANGE.PRILOG

CHANGE.SECLOG

DELETE.LOG

GENJCL.ARCHIVE

GENJCL.CLOSE

NOTIFY.PRILOG

NOTIFY.SECLOG

name is an eight-character alphanumeric string that identifies a valid IMSsubsystem ID.

STARTNEW | NONEWMutually exclusive, optional parameters you use to specify whether new jobsare to be started when only one RECON is available.

STARTNEWSpecifies that new jobs are to be started.

NONEWSpecifies that new jobs are not to be started.

TAPEUNIT(unittype)Optional parameter you use to specify the unit type of the tape device that isholding the records for log data sets. The unit type can be up to eightalphanumeric characters long.

If you do not use this parameter to specify a tape device, then the INIT.RECONcommand defaults to unit type 3400.

UPGRADEOptional parameter you use when initializing the new Version 7 RECON duringthe process of upgrading a pre-version 6 RECON. For more information on theupgrade process, see “Upgrade Procedure” on page 71. This parameter sets asafety switch that makes the new RECON unusable until the Upgrade utility isrun. The Upgrade utility does not run if this switch has not been set.

Related Reading: See “Chapter 4. RECON Upgrade Utility (DSPURU00)” onpage 71 for more information on the upgrade process.

INIT.RECON


Example of Initializing the RECONIn this example, the RECON data sets are identified by the RECON1 and RECON2DD statements.//INITRCON JOB

...

//RECON1 DD DSN=RECON7,DISP=SHR//RECON2 DD DSN=RECON8,DISP=SHR//SYSIN DD *

INIT.RECON NOCHECK SSID(IMSB) LOGRET('007 00:00:30.0')/*

INIT.SG

OO INIT.SG GSGNAME(gsgname) SGNAME(sgname) ACTIVETRACKING

NONLOCAL

LOCALOP

Use an INIT.SG command to define a service group as a member of a GSG. Everyservice group in the GSG must be defined in every RECON that is to be used byany IMS subsystem in the GSG. This command also specifies the initial role of theservice group.


ParametersACTIVE | TRACKING

Mutually exclusive, required parameters you use to specify the initial role of theservice group.

ACTIVEIndicates that the service group is an active subsystem. ACTIVE can onlybe specified for one service group of a GSG.

TRACKINGIndicates that the service group is a tracking subsystem. TRACKING canonly be specified for one service group of a GSG.

GSGNAME(gsgname)Required parameter you use to specify the name of the GSG to which theservice group belongs.

SGNAME(sgname)Required parameter you use to specify the name of the service group you wantto create.

LOCAL | NONLOCALMutually exclusive, optional parameters you use to specify whether the servicegroup is local or nonlocal.

LOCALIndicates that this is the local service group for this set of RECONs.

NONLOCALIndicates that this is the nonlocal service group for this set of RECONs.

INIT.RECON


Examples of Creating Service GroupsIn this example, the ACTIVE Service Group named STLSITE1 is added to the GSGIMSGSG1, and a LOCAL TRACKING SG named STLSITE2 is added to the sameGSG.//INITSG JOB...

//SYSIN DD *INIT.SG GSGNAME(IMSGSG1) SGNAME(STLSITE1) ACTIVEINIT.SG GSGNAME(IMSGSG1) SGNAME(STLSITE2) TRACKING LOCAL/*

INIT.SG


Chapter 13. LIST Commands

LIST.BKOUT

OO LIST.BKOUTALL

SSID(name) TIMEFMT(sublist)OP

Use a LIST.BKOUT command to list information about the backout record for theselected subsystem or to list all backout records in RECON. For the format of therecords listed by this command, see the “Appendix C. Sample Listings of RECONs”on page 367.

ParametersALL | SSID(name)

Mutually exclusive, optional parameters that identify the backout records thatare to be displayed.

ALLSpecifies that all the backout records in the RECON are to be displayed.

SSID(name)Specifies that only one backout record is to be displayed. name is aneight-character alphanumeric string that identifies a valid subsystem ID.

TIMEFMT(sublist)Optional parameter you use to define the form in which time stamps appear inmessages, displays, and listings from DBRC.

Related Reading:

v See “TIMEFMT Parameter Sublist” on page 102 for a description of theTIMEFMT parameter sublist format.


The LIST commands get the TIMEFMT default from what is specified in theRECON header record.

Example of Running LIST.BKOUTHere is an example of running the LIST.BKOUT command.//LISTBKOUT JOB

...

//SYSIN DD *LIST.BKOUT SSID(IMS1)

/*

LIST.CAGRP


OO LIST.CAGRPALL

GRPNAME(name) TIMEFMT(sublist)OP

Use a LIST.CAGRP command to list information in the Copy1 RECON about either aspecified CA group or all CA groups. For the format of the records listed by thiscommand, see the “Appendix C. Sample Listings of RECONs” on page 367.

ParametersALL | GRPNAME(name)

Mutually exclusive, optional parameters you use to specify the name of the CAgroup for which information is to be displayed.

ALLProduces a list of the CA group record and corresponding changeaccumulation run records for each CA group in RECON.

GRPNAME(name)Produces a list of the CA group record and the change accumulation runrecords for the group that you request in name.

TIMEFMT(sublist)Optional parameter you use to define the form in which time stamps appear inmessages, displays, and listings from DBRC. The five values are positional.Each is optional and can be omitted by including only the comma.

Related Reading:



The TIMEFMT default for LIST commands is obtained from what is specified inthe RECON header record.

Example of Specifying the CA Group and CA Records via GRPNAMEIn this example, the CA group record and the associated CA records are specifiedby the GRPNAME parameter.//LISTCAGP JOB

...

//SYSIN DD *LIST.CAGRP GRPNAME (MYGROUP)

/*

LIST.CAGRP


LIST.DB

OO LIST.DBALL

TYPEIMSTYPEFPTYPHALDBDBD(dbname)

COVEREDGSG(gsgname)

DBDS TIMEFMT(sublist)OP

Use a LIST.DB command to receive a list of databases registered in RECON. Youcan list one or all database records, with or without their associated DBDS records.

For the format of the records listed by this command, see the “Appendix C. SampleListings of RECONs” on page 367.

The LIST.DB command displays the recoverable or nonrecoverable status of thefull-function database.

Related Reading:

v See “HALDB Records” on page 60 for detailed information about how HALDBsare represented in the RECON data set.

v See IMS Version 7 Administration Guide: Database Manager for an overview ofHALDBs and information about how to create them.

ParametersALL | TYPEIMS | TYPEFP | TYPHALDB | DBD(dbname)

Mutually exclusive, optional parameters you use to specify which databases inRECON are to be displayed.

ALLSpecifies that all database records in RECON are to be displayed. ForHALDBs, the partition database records are listed under the master record.

TYPEIMSSpecifies that all database records in RECON that describe a DL/I databaseare to be displayed.

TYPEFPSpecifies that all database records in RECON that describe a Fast PathDEDB are to be displayed.

TYPHALDBSpecifies that all database records that represent HALDBs are to bedisplayed, including the HALDB master database records (TYPE=HALDB)along with their associated HALDB partition database records(TYPE=PART).

DBD(dbname)Displays a specific database record or recovery group for a database.

For HALDBs, specifying the HALDB master name lists the HALDB masterrecord and all of its partition database records. Specifying the partitiondatabase name lists only the partition database record.

LIST.DB

Chapter 13. LIST Commands 247

COVERED | GSG(gsgname)Mutually exclusive, optional parameters you use to qualify the database recordsin RECON that are to be displayed. Neither COVERED nor GSG(gsgname) canbe specified if DBD is specified.

COVEREDSpecifies that all RSR-covered databases are to be displayed.

GSG(gsgname)Specifies that only databases covered by the specified global service groupare to be displayed.

DBDSOptional parameter you use to display those DBDSs or areas in RECON thatare associated with the specified database. DBDS information includesrecovery-related records (ALLOC, IC, RECOV, REORG). If you do not specifythis parameter, no DBDS records or area records are displayed.


Related Reading:




Example of Displaying a Database and Its DBDS RecordsIn this example, database HDAMVSAM and its associated DBDS records aredisplayed.//LISTDB

...

//SYSIN DD *LIST.DB DBD(HDAMVSAM) DBDS

/*

LIST.DBDS

OO LIST.DBDS DBD(name)GROUP(name) DDN(name)

AREA(name)TIMEFMT(sublist)

OP

Use a LIST.DBDS command to display a list of all records in RECON that containinformation about a specific DBDS or DEDB area. For the format of the recordslisted by this command, see the “Appendix C. Sample Listings of RECONs” onpage 367.

LIST.DB



Mutually exclusive, required parameters you use to identify the DBDS or DEDBarea being listed.

DBDSpecifies the database name of the DBDS or DEDB area being displayed.


GROUPSpecifies that all DBDSs or DEDB areas of the named DBDS group are tobe displayed. If GROUP is specified, the LIST.DBDS command is executedfor each member of the identified group.

DDN(name) | AREA(name)Mutually exclusive, optional parameters you use to identify the DBDS or DEDBarea to be displayed. You specify one of these parameters only when youspecify the DBD parameter.

DDN(name)Specifies the name of the DBDS to display.

For HALDBs, you must specify a HALDB partition name (not a HALDBmaster name) with the DBD parameter in order to use the DDN parameter.The DDN parameter value is the HALDB partition DDN. The LIST.DBDScommand is performed for the identified DBDS of the partition. TheLIST.DBDS command fails if DDN does not identify a DBDS in the partition.

AREA(name)Specifies the name of the DEDB area to display.

If neither DDN nor AREA is specified, the LIST.DBDS command is executed foreach DBDS or DEDB area of the specified database. If you specify a HALDBmaster name, the LIST.DBDS command is performed for each DBDS for eachHALDB partition in the HALDB master. If you specify a HALDB partition name,the LIST.DBDS command is performed for each DBDS of the identified partition.


Related Reading:




Example of Displaying AREA ParametersIn this example, information about the DEDB area specified in the DBD and AREAparameters is displayed.

LIST.DBDS


//LISTDBDS JOB

...

//SYSIN DD *LIST.DBDS DBD(FPEDBD02) AREA(AREA01)

/*

LIST.DBDSGRP

OO LIST.DBDSGRPA

GRPNAME(name) TIMEFMT(sublist)OP

A:

S

ALL,

( (dbname ) ),areaname,ddname

Use a LIST.DBDSGRP command to display a list of any of the following:

v All three kinds of data group records (DB groups, DBDS groups, and recoverygroups) in RECON

v The members of a single data group record

v All data group records containing a specified member or members

Related Commands:

v “INIT.DBDSGRP” on page 231

v “CHANGE.DBDSGRP” on page 132

ParametersGRPNAME(name) | ALL

Mutually exclusive, optional parameters you use to specify the groups to belisted.

GRPNAMEProduces a list of the members of the specified group. The named groupmust exist in RECON.

ALL(dbname[,areaname][,ddname])Produces a list of all the DBDS, DB, and recovery groups identified inRECON. The optional parameters (dbname[,areaname][,ddname]) can beused to limit the number of records listed. A group is listed only if it containsone or more of the databases, DBDSs, or areas specified.


LIST.DBDS


Related Reading:




Example of Displaying the Members of a DBDS GroupIn this example, the members of a specified DBDS group are displayed.//LISTDBGP JOB

...

//SYSIN DD *LIST.DBDSGRP GRPNAME(DBDSG1)

/*

LIST.GSG

OO LIST.GSGALL

GSGNAME(gsgname) TIMEFMT(sublist)OP

Use a LIST.GSG command to receive a list of the global service group records inRECON. This command fails if RSRFEAT=NO is specified in the IMSCTRL macro.For the format of the records listed by this command, see the “Appendix C. SampleListings of RECONs” on page 367.

ParametersALL | GSGNAME(name)

Mutually exclusive, optional parameters you use to specify which GSG recordsin RECON are to be displayed.

ALLSpecifies that all GSG records in RECON are to be displayed.

GSGNAME(name)Displays a specific GSG record.


Related Reading:



LIST.DBDSGRP



Example of Listing a Global Service GroupIn this example a single GSG record is displayed.//LISTGSG JOB...

//SYSIN DD *LIST.GSG GSGNAME(GSG1)/*

LIST.HISTORY

OO LIST.HISTORY DBD(name)GROUP(name) DDN(name)

AREA(name)FROMTIME(timestamp)

O

OTOTIME(timestamp) TIMEFMT(sublist)

OP

Use the LIST.HISTORY command to produce a history-of-activity listing for DBDSs orDEDB areas. The output of the LIST.HISTORY command consists of:

v The database record listing.

v The DBDS record listing. (For a DEDB area, the area authorization and arearecovery records are combined to form a DBDS record listing.)

v The following records (if present), listed in time sequence order under eachDBDS or area:

– ALLOC records.

– IMAGE records.

– CA execution records, showing the purge time only for the current DBDS orarea.

– RECOV records.

– REORG records.

v The PRILOG records associated with all ALLOC records listed.

v A time line summary that interrelates all the events represented by the recordslisted above.

You can use the FROMTIME and/or TOTIME parameters to define a time rangethat excludes these records:

v ALLOC records for USIDs that are not active within the range. If any ALLOCrecord is active within the time range, all ALLOCs for the same USID are listed.

v IMAGE records with RUN times (or for CICs, an effective purge time) outside therange.

v CA execution records with STOP and PURGE times outside the range.

v RECOV records with RUN and RECOV TO times outside the range.

v REORG records with RUN times outside the range.

See “Sample Listing of LIST.HISTORY Output” on page 368 for an illustration ofsample output produced by the LIST.HISTORY command.

LIST.GSG



Mutually exclusive, required parameters you use to identify the DBDS or DEDBarea to list.

DBDSpecifies the database name of the DBDS or DEDB area to be listed.


GROUPSpecifies that all the DBDSs or DEDB areas of a DBDS group are to belisted. If GROUP is specified, the LIST.HISTORY command is executed foreach member of the identified group.

DDN(name) | AREA(name)Mutually exclusive, optional parameters you use to identify the DBDS or DEDBarea to be listed. You specify one of these parameters only when you specifythe DBD parameter.

DDNSpecifies the name of the DBDS to list.

For HALDBs, you must specify a partition database name with the DBDparameter in order to use the DDN parameter. The DDN parameter value isthe partition DDN. The LIST.HISTORY command is performed for theidentified DBDS of the partition. The LIST.HISTORY command fails if DDNdoes not identify a DBDS in the partition.

AREASpecifies the name of the DEDB area to list.

If neither DDN nor AREA is specified, the LIST.HISTORY command is executedfor each DBDS or DEDB area of the specified database. If you specify aHALDB master name, the LIST.HISTORY command is performed for each DBDSfor each partition in the HALDB master. If you specify a HALDB partition name,the LIST.HISTORY command is performed for each DBDS of the identifiedpartition.

FROMTIME(timestamp)Optional parameter you use to specify the time stamps of the DBDS or DEDBarea records that are to be listed in time sequence order. The time stamp mustbe in standard form (see “Standard Time Stamp Format” on page 101). Thoserecords that are not listed in time-sequence order are listed regardless ofwhether FROMTIME or TOTIME are specified. FROMTIME specifies the timestamp of the oldest record to be listed. If you specify only FROMTIME, allsubsequent, pertinent records in RECON are listed.

You can combine the FROMTIME and TOTIME parameters in order to specify arange of records to display.

If you specify neither FROMTIME nor TOTIME, all the records that exist inRECON for the specified DBDSs or DEDB areas are listed.

TOTIME(timestamp)Optional parameter you use to specify the time stamps of the DBDS or DEDBarea records to be listed in time-sequence order. The time stamp must be instandard form (see “Standard Time Stamp Format” on page 101). Thoserecords not listed in time-sequence order are listed regardless of whether

LIST.HISTORY


FROMTIME or TOTIME are specified. TOTIME specifies the time stamp of thelast record to be listed. If you specify only TOTIME, that record plus all prior,pertinent records in RECON are listed.

You can combine the FROMTIME and TOTIME parameters in order to specify arange of records to display.

If you specify neither FROMTIME nor TOTIME, all the records that exist inRECON for the specified DBDSs or DEDB areas are listed.


Related Reading:




Example of Displaying a DBDSs Activity HistoryIn this example, the activity history of a specified DBDS is displayed.//LISTHIST JOB

...

//SYSIN DD *LIST.HISTORY DBD(DB1) DDN(NAME1)

/*

LIST.LOG (for a PRILOG Family)

OO LIST.LOGSTARTIME(timestamp) SSID(name) GSG(gsgname)

O

OTIMEFMT(sublist)

OP

This command displays the PRILOG record and any of the following records havingthe specified start time.

v LOGALL

v SECLOG

v PRISLD

v SECSLD

LIST.HISTORY


ParametersSTARTIME(timestamp)

Required parameter you use to specify the start time of the records that youwant displayed.

SSID(name)Optional parameter that limits the display of log records or OLDS entries tothose associated with the specified subsystem.

GSG(gsgname)Optional parameter that limits the display of log records to those associatedwith the specified GSG.

If the name in any of the records listed does not match the specified name,message DSP0144 is issued and processing continues.


Related Reading:




Attention: If the ERROR, OPEN, or UNARCH parameters are coded, messageDSP0141I is issued and the command fails.

If the FROMTIME, TOTIME, INTERIM, or TRACKING parameters are coded,STARTIME is ignored and the command defaults to ALL processing as describedunder the next section.

Example of Listing a PRILOG Family of RecordsIn the example, all PRILOG, SECLOG, PRISLD, SECSLD, and LOGALL recordsthat have the specified start time are listed.//LISTLOG JOB...

//SYSIN DD *LIST.LOG STARTIME('97.023 12:12:12.1 PST')/*

LIST.LOG (for a Category of Records)Each command form is followed by a list of the records it displays.

OO LIST.LOGALL

OP

v PRILOG

v LOGALL

LIST.LOG (for a PRILOG family)


v SECLOG

v PRISLD

v SECSLD

v PRIOLD

v SECOLD

OO LIST.LOGALL

INTERIM OP

v IPRI

v ISEC

v IPRISL

v ISECSL

v IPRIOL

v ISECOL

OO LIST.LOGALL

TRACKING OP

v PRITSLDS

v SECTSLDS

OO LIST.LOGALL

TRACKING INTERIM OP

v IPRITSLD

v ISECTSLD

OO LIST.LOG ALLOLDS OP

v PRIOLD

v SECOLD

OO LIST.LOG ALLOLDS INTERIM OP

v IPRIOL

v ISECOL

OO LIST.LOG OLDS(ddname)SSID(name)

OP

v PRIOLD

v SECOLD

LIST.LOG OLDS displays only the data set entries with matching DD names andsubsystem names. If SSID is omitted, processing is the same as for ALLOLDS.

LIST.LOG (for a category of records)


Optional parameters for LIST.LOG ALL, ALLOLDS, and OLDS are:

OOFROMTIME(timestamp) TOTIME(timestamp)

SSID(name)GSG(gsgname)

O

OOPEN ERROR UNARCH

OP

The command can be further qualified with one or more of the following optionalparameters. For example, combining SSID and OPEN limits the display to logs andOLDS entries that belong to a specified subsystem, and to those that are notclosed.

ParametersFROMTIME(timestamp)

Optional parameter that limits the display to log records or OLDS entriesstarting at, or after, this time. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

TOTIME(timestamp)Optional parameter that limits the display to log records or OLDS entriesstarting at, or after, this time. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

SSID(name)Optional parameter that limits the display to log records or OLDS entriesassociated with the specified subsystem.

GSG(gsgname)Optional parameter that limits the display of log records to those associatedwith the specified GSG.

OPENOptional parameter that limits the display to log records or OLDS entries thatare not closed.

ERROROptional parameter that limits the display to log records having one or moredata set entries marked in error, and to OLDS entries marked in error.

UNARCHOptional parameter that limits the display of OLDS entries to those that are notarchived.

Attention: Specifying UNARCH without the ERROR or OPEN parameterscauses ALL to be processed like ALLOLDS; that is, no log records are listed,only unarchived OLDS entries are listed.

The following parameter can be used on all forms of the command.

OOTIMEFMT(sublist)

OP

TIMEFMT(sublist)Optional parameter you use to define the form in which time stamps appear in



messages, displays, and listings from DBRC. The five values are positional.Each is optional and can be omitted by including only the comma.

Related Reading:




Attention: If the ERROR, OPEN, or UNARCH parameters are coded, messageDSP0141I is issued and the command fails.

If the FROMTIME, TOTIME, INTERIM, or TRACKING parameters are coded,STARTIME is ignored and the command defaults to ALL processing as describedunder the next section.

Example of Displaying RECON Records Specified by STARTIMEIn this example, the RLDSs, SLDS, and corresponding LOGALL record with thetime stamp specified in the STARTIME parameter are to be displayed.//LISTRCON JOB

...

//SYSIN DD *LIST.LOG STARTIME(840311313130)

/*

Example of Displaying a Subsystem’s OLDS RecordsIn this example, the OLDS records from subsystem IMSA are to be displayed.//LISTRCON JOB

...

//SYSIN DD *LIST.LOG ALLOLDS SSID(IMSA)

/*

LIST.RECON

OO LIST.RECONSTATUS TIMEFMT(sublist)

OP

Use the LIST.RECON command to obtain a display of the RECON’s current statusand a formatted display of all records it contains.

Use the STATUS keyword to display RECON status only.

RECON status information includes the following items:

v The contents of the Time Zone Label Table.



v The TIMEZIN and TIMEFMT settings.

v Whether coexistence of this RECON with pre-V6 IMS is enabled.

v If coexistence is enabled, the contents of the Time History Table.

v The status of each of the three RECONs.

RECON status Meaning

COPY1 PRIMARY ACTIVE RECON

COPY2 BACKUP RECON

SPARE AVAILABLE RECON

UNAVAILABLE UNAVAILABLE RECON

DISCARDED UNUSABLE RECONS

The RECON is unavailable when the resource is allocated in another system.

ParametersSTATUS

Optional parameter you use to request the RECON header record informationand the status of all RECONs. If you specify this parameter the listing of theremainder of the records is suppressed.


Related Reading:




Examples of Displaying the RECONsHere are some examples of using the LIST.RECON command.

Example of Displaying the RECONsIn this example, the status and contents of RECON are displayed.//LISTRCON JOB

...

//SYSIN DD *LIST.RECON

/*

For a sample of RECON, see the “Appendix C. Sample Listings of RECONs” onpage 367.

Example of Displaying RECON Header and Status InformationIn this example, only RECON header status information is displayed.

LIST.RECON


//LISTRCON JOB

...

//SYSIN DD *LIST.RECON STATUS

/*

Only the first segment of output shown in the “Appendix C. Sample Listings ofRECONs” on page 367 is produced in this case.

Related Reading: See “Chapter 3. Initializing and Maintaining the RECON” onpage 45 for an explanation of the possible RECON states.

LIST.SUBSYS

OO LIST.SUBSYSONLINE

SSID(name)ALLBATCH

TIMEFMT(sublist) TRACKINGOP

Use a LIST.SUBSYS command to receive a formatted list of the subsystemsregistered in RECON. For the format of the records listed by this command, see the“Appendix C. Sample Listings of RECONs” on page 367.

ParametersSSID(name) | ALL | ONLINE| BATCH

Mutually exclusive, optional parameters you use to specify which subsysteminformation is to be displayed.

SSID(name)Specifies the name of the subsystem for which information is to bedisplayed.

ALLSpecifies that all subsystem information, both batch and online, is to bedisplayed.

ONLINESpecifies that all online subsystem information is to be displayed.

BATCHSpecifies that all batch subsystem information is to be displayed.


Related Reading:



LIST.RECON



TRACKINGSpecifies that all RSR tracking subsystem information is to be displayed.

Example of Displaying All Online Subsystem RecordsIn this example, all online subsystem records are displayed.//LISTSS JOB

...

//SYSIN DD *LIST.SUBSYS

/*

LIST.SUBSYS


LIST.SUBSYS


Chapter 14. NOTIFY Commands

NOTIFY.ALLOC

OO NOTIFY.ALLOC ALLTIME(timestamp) DBD(name) DDN(name)AREA(name)

DEALTIME(timestamp)STARTIME(timestamp)

O

ODSSN(value) USID(value)

OP

Use a NOTIFY.ALLOC command to add information to RECON about either a specificdatabase allocation or a specific database deallocation of a DBDS or DEDB area.This addition of information is required only when RECON was not updated duringa run of IMS that resulted in an allocation of the DBDS or DEDB area for updates.You should not need to use this command under normal operating conditions.

The NOTIFY.ALLOC command fails if the DBDS or DEDB area is nonrecoverable orin use.

Restriction: This command is not allowed for ILDS or Index DBDSs of HALDBpartitions.

ParametersALLTIME(timestamp)

Required parameter you use to specify the time stamp of the allocation of thedatabase that contains the DBDS or DEDB area that is specified in thiscommand. The time stamp must be in standard form (see “Standard TimeStamp Format” on page 101).

When used with the STARTIME parameter, ALLTIME causes a new allocationrecord to be written in RECON. When used with a DEALTIME parameter, itidentifies the allocation record in RECON for which a deallocation time is beingadded.

DBD(name)Required parameter you use to specify the database name of the DBDS orDEDB area for which you are adding allocation information to RECON.

DDN(name) | AREA(name)Required parameter you use to specify the data set ddname of the DBDS orDEDB area for which you are adding allocation information to RECON.

DEALTIME(timestamp) | STARTIME(timestamp)Mutually exclusive, required parameters. The time stamp must be in standardform (see “Standard Time Stamp Format” on page 101).

DEALTIMESpecifies the time stamp of the deallocation of the database for thespecified DBDS or DEDB area. This addition to RECON is required only ifthe database is allocated for updates and explicitly deallocated before theend of an IMS run.


STARTIMESpecifies the starting time stamp of the log data set that was active at thetime of the allocation specified in the ALLTIME parameter.

DSSN(value)Optional parameter you use to specify which data set sequence number isplaced in the allocation record to be created. If you do not specify the DSSNparameter, the data set sequence number for the new allocation record is 0,indicating no data sharing. If you are using data sharing, you must specify theappropriate DSSN. You use this parameter for log-merge processing.

USID(value)Optional parameter you use to specify the update set identifier of the databaseor area when the update occurred.

USID is required if the database or area is assigned to a GSG. If the databaseor area is not assigned to a GSG, USID cannot be specified.

Example of Adding Allocation Information to RECONIn this example, information about an allocation of a specified DBDS is to be addedto RECON. The ALLTIME parameter specifies the time stamp of the allocation ofthe DBDS or DEDB area; the STARTIME parameter specifies the time stamp of thestart of the log data set that was active at the time of the allocation.//NFYALLOC JOB

...

//SYSIN DD *NOTIFY.ALLOC DBD(DB1) DDN(DD1) -

STARTIME(820670201010) -ALLTIME(820670308200)

/*

NOTIFY.BKOUT

OO NOTIFY.BKOUT SSID(name) UOR(uor) UORTIME(timestamp) PSB(name) O

O

S

,

DBD( name ) S

,

BKO( name )

OP

Use the NOTIFY.BKOUT command to create a backout record for a specifiedsubsystem and to add a single unit of recovery (UOR) entry to the record that iscreated. Additional UOR entries can be added to the backout record by using theCHANGE.BKOUT command.


Required parameter you use to specify the subsystem for which the backoutrecord is to be created. The name is an eight-character, alphanumeric stringthat represents any valid subsystem name.

NOTIFY.ALLOC


UOR(uor)Required parameter you use in conjunction with the UORTIME parameter toidentify a unit of recovery in the backout record. The recovery token (uor) is a16-byte field that describes a specific UOR that is to be included with thebackout record. uor must be 32 hexadecimal digits expressed as a characterstring; for example, UOR(E2E8E2F3404040400000000600000003).

The recovery token is intended to be a unique identifier, but it can be duplicatedacross restarts. When you include UORTIME, you eliminate the problem ofpossible duplication.

UORTIME(timestamp)Required parameter you use to specify the time of the UOR to be added to thebackout record. The value is the time stamp of the beginning of the UOR (foundin the X'5607' log record). The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

PSB(name)Required parameter you use to identify the PSB associated with the UOR.

DBD(name)Optional parameter you use to identify up to eight databases having changesassociated with the unit of recovery that require backout.

BKO(name)Optional parameter you use to identify up to eight databases having changesassociated with the unit of recovery that have already been backed out.

Use BKO to identify databases that have already been backed out from thisUOR-UORTIME combination. You can specify either the BKO parameter, theDBD parameter, or both. A database name can appear in either BKO or DBD,but not both. (A database cannot both be backed out and require a backout atthe same time.)

Example of Adding a Backout Record to RECONIn this example, a backout record for subsystem SYS3 is added to the RECON.//NFYBKOUT JOB

...

//SYSIN DD *NOTIFY.BKOUT SSID(SYS3)

UOR(E2E8E2F3404040400000000600000003)UORTIME(930931345027) PSB(APPL34)DBD(DATA1,DATA2,DATA3C)BKO(DATA4,DATA5,DATA3A)

/*

NOTIFY.CA

OO NOTIFY.CA CADSN(name) GRPNAME(name) RUNTIME(timestamp) STOPTIME(timestamp) O

O S

,

VOLLIST( volser )1

FILESEQ( value )

O

NOTIFY.BKOUT

Chapter 14. NOTIFY Commands 265

O

S

,NO COMPLETE

PURGLIST( ( timestamp, YES , INCOMPLETE ) )

O

O3400

UNIT( unittype )

COMP

SUBSETOP

Use a NOTIFY.CA command to add information about a run of the Database ChangeAccumulation utility for a specified CA group.

ParametersCADSN(name)

Required parameter you use to specify the data set name of the changeaccumulation data set in the identified record. If the CA group is defined asreusable, the data set name must be unique. DBRC does not check forduplicate data set names.

GRPNAME(name)Required parameter you use to specify the name of the CA group for whichinformation is to be added.

RUNTIME(timestamp)Required parameter you use to identify the specific change accumulation runrecord to be added. The time stamp represents the time at which the DatabaseChange Accumulation utility was run, and it must be in standard form (see“Standard Time Stamp Format” on page 101).

STOPTIME(timestamp)Required parameter you use to specify the time stamp of the changeaccumulation run record for which information is to be added. The time stamp isthe stop time of the last log volume that was processed by the specified run ofthe Change Accumulation utility, and it must be in standard form (see “StandardTime Stamp Format” on page 101).

VOLLIST(volser)Required parameter you use to specify the volume serial numbers of thechange accumulation data set in the specified change accumulation run record.You can specify a maximum of 255 volume serial numbers for volser. Eachvolume serial number can be a maximum of six alphanumeric characters.

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of theidentified change accumulation data set.


PURGLIST(timestamp,YES | NO,COMPLETE | INCOMPLETE)Optional parameter you use to specify the purge time, which is the point in timein the input log records where change accumulation started and to specifywhether the logs form a complete subset.

The time stamp must be in standard form (see “Standard Time Stamp Format”on page 101). If you do not specify a time stamp, the time is set to 0.

If you are using the accumulated changes as input to recovery, you mustchoose a purge time that satisfies the DBRC input requirements for recovery.

NOTIFY.CA


Recovery first chooses an image copy and then uses a change accumulationwhose purge time for that DBDS matches the run time of the image copy.

YES | NOMutually exclusive subparameters you use to specify whether any changesfor the corresponding DBDS have been accumulated.

YESSpecifies that some changes have been accumulated for thecorresponding DBDS.

NOSpecifies that no changes have been accumulated for thecorresponding DBDS.

COMPLETE | INCOMPLETEMutually exclusive subparameters you use to specify whether the logs forma complete subset. To determine whether a log subset is complete, use theLIST.CAGRP command. See “LIST.CAGRP” on page 245 for moreinformation.

COMPLETESpecifies that the logs form a complete subset. When you specifyCOMPLETE, the time stamp of the STOPTIME parameter is the stoptime of the last log input to the Change Accumulation utility.

INCOMPLETESpecifies that the logs form an incomplete subset. When you specifyINCOMPLETE, the time stamp of the STOPTIME parameter is the starttime of the earliest unselected (open) log volume. This volume shouldbe the first one that is selected at a later run.

If you specify the PURGLIST parameter, the order of the time stamp and thechange indicator in the purge list corresponds to the order of the DBDS namesspecified in the GRPMEM parameter of the INIT.CAGRP command. For example,the third purge time and change indicator is the purge time for the third DBDSthat is specified in the GRPMEM parameter of the INIT.CAGRP command.

If you specify fewer subparameters with the PURGLIST parameter than youspecified with the GRPMEM parameter of the INIT.CAGRP command, DBRCuses the defaults of NO and COMPLETE for each DBDS that you omit.Similarly, if you do not specify the PURGLIST parameter, DBRC uses thedefaults of NO and COMPLETE for each DBDS specified with the GRPMEMparameter of the INIT.CAGRP command. To use a default of NO for certainDBDSs, use commas to indicate which DBDSs are subject to the default.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the volumes on which thechange accumulation data set resides. unittype can be up to eight alphanumericcharacters.

COMP | SUBSETMutually exclusive, optional parameters you use to indicate that the changeaccumulation record’s stop time is a log volume start time.

COMPIndicates that when the CA was created, a complete set of logs wasprocessed and that the CA’s stop time is the stop time of the last logvolume processed.

NOTIFY.CA


SUBSETIndicates that when the CA was created, a subset of logs was processedand the CA’s stop time is the start time of the first unprocessed log volume.Specifying INCOMPLETE in the PURGLIST parameter does notautomatically cause SUBSET to be set.

You do not need to use this parameter under normal conditions. Checking is notdone to verify that the use of this parameter is consistent with the value of theCA stop time. This parameter value is used by the GENJCL.CA and GENJCL.RECOVprocesses. Incorrect use of this parameter can result in invalid generated JCL.

Example of Adding CADSN Information to RECONIn this example, information about a change accumulation data set is to be addedto RECON.//NFYCA JOB

...

//SYSIN DD *NOTIFY.CA GRPNAME(CAGRP2) -

STOPTIME(840240202020) -RUNTIME(840250305029) CADSN(CADSN06) -VOLLIST(VOL005) -PURGLIST((840240302005,YES),,(840250420256,))

/*

NOTIFY.IC

OO NOTIFY.IC DBD(name) DDN(name)AREA(name)

ICDSN(name) RUNTIME(timestamp) O

O1

FILESEQ( value )1

FILESEQ2( value )ICDSN2(name)

BATCH

ONLINECICSMSCICSMSNOCIC

O

ORECDCT(value) STOPTIME(timestamp) 3400

UNIT( unittype )

O

O3400

UNIT2( unittype )S

,

VOLLIST( volser )

O

O

S

,

VOLLIST2( volser )

USID(value)OP

Use a NOTIFY.IC command to add information about an image copy.

NOTIFY.CA



ParametersDBD(name)

Required parameter you use to specify the database name of the DBDS or areafor which an image copy run record is to be added.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to specify the data set ddnameof the DBDS (use DDN) or DEDB area (use AREA) for which an image copyrun record is to be added.

ICDSN(name)Required parameter you use to specify the data set name of the image copydata set that contains the image copy whose run record is being added. namecan be a maximum of 44 characters.

RUNTIME(timestamp)Required parameter you use to specify the time the image copy utility was run.The time stamp must be in standard form (see “Standard Time Stamp Format”on page 101).

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of theidentified image copy data set. value must be a decimal number from 1 to 9999.

FILESEQ2(1 | value)Optional parameter you use to specify the file sequence number of theidentified duplicate image copy data set. value can be a decimal number from 1to 9999.

You can specify this parameter only if you specify the VOLLIST2 parameter. Ifthe VOLLIST2 parameter is specified, then FILESEQ2(1) is the default for thisparameter.

ICDSN2(name)Optional parameter you use to specify the data set name of the duplicate imagecopy data set that is to contain the image copy whose run record is beingadded. name can be a maximum of 44 characters.

BATCH| ONLINE | CIC | SMSCIC | SMSNOCICMutually exclusive, optional parameters you use to specify the type of imagecopy that the data set contains.

BATCHIndicates that the Database Image Copy (DFSUDMP0) utility was used tocreate the image copy while the database was unavailable for updateprocessing (the CIC parameter was not specified). BATCH may also bespecified to record the output of the HISAM Reorganization Unload utilityimage copy.

ONLINESpecifies that the image copy data set was obtained by executing theOnline Database Image Copy utility. You must use the STOPTIMEparameter when you specify ONLINE.

CICIndicates that a concurrent image copy was taken. A concurrent image copy

NOTIFY.IC


is a “fuzzy” copy, so the data set uses logs in order to complete the image.STOPTIME must be used if CIC is specified. CIC cannot be used to copyVSAM KSDS databases.

SMSCICIndicates that the Database Image Copy 2 was used to create the imagecopy while the database was available for update processing (’S’ wasspecified on the utility control statement). The image copy is in DFSMSdump format. The image copy is a “fuzzy” copy so logs must be applied torecover the data set to a usable state. The STOPTIME parameter must bespecified when you specify SMSCIC.

SMSNOCICIndicates that the Database Image Copy 2 utility was used to create theimage copy while the database was unavailable for update processing (’X’was specified on the utility control statement). The image copy is in DFSMSdump format.

RECDCT(value)Optional parameter you use to specify the count of the records in the imagecopy data set. value must be a decimal number from 1 to 2147483647.

STOPTIME(timestamp)Optional parameter you use to specify the stop time of the online or concurrentimage copy. You must specify this parameter when online, CIC, or SMSCIC isspecified. The time stamp must be in standard form (see “Standard Time StampFormat” on page 101).

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the image copy data set.The unit type can be up to eight alphanumeric characters.

UNIT2(3400 | unittype)Optional parameter you use to specify the unit type of the duplicate image copydata set. The unit type can be up to eight alphanumeric characters long.

VOLLIST(volser)Optional parameter you use to specify (in the batch or online image copyrecord) the volume serial numbers of the volumes on which the specified imagecopy data set resides. This parameter is required when either ONLINE orBATCH parameters are specified.

VOLLIST2(volser)Optional parameter you use to specify the volume serial numbers (in the imagecopy record) of the volumes on which the specified duplicate image copy dataset resides. This parameter is required if ICDSN2 is specified, and when eitheronline or batch parameters are specified.

USID(value)Optional parameter you use to specify the update set identifier of the databaseor area when the reorganization occurred.

USID is required if the database or area is assigned to a GSG. If the databaseor area is not assigned to a GSG, USID is optional.

Example of Notifying DBRC of Concurrent Image Copy CompletionIn this example, DBRC is notified of the successful completion of a concurrentimage copy for the area specified. RUNTIME refers to the time the image copystarted. STOPTIME refers to the time the image copy ended.

NOTIFY.IC


//NFYIC JOB

...

//SYSIN DD *NOTIFY.IC DBD(DBD001) AREA(AREA1)

RUNTIME(8520002020)STOPTIME(8520004040)ICDSN(IC0005) CIC

/*

NOTIFY.PRILOG (for OLDS)

OO NOTIFY.PRILOG OLDS(ddname) DSN(name)RUNTIME(timestamp)

STARTIME(timestamp) O

OFIRSTREC(number) GSG(gsgname) INTERIM LASTREC(number)

O

OLOGTOKEN(number) NXTOLDS(ddname) SSID(name)

OP

Use a NOTIFY.PRILOG command to add information about a primary OLDS toRECON and to manually create interim PRILOG in RECON. You would do this in acase where the log processing exit routines of the IMS system failed to do so.


Required parameter you use to specify that a record is to be created in RECONfor an OLDS. If you do not specify OLDS, the default is RLDS (see“NOTIFY.PRILOG (for RLDS)” on page 274). ddname is the DD statement thatthe IMS online control region used when it used the OLDS.

DSN(name) | RUNTIME(timestamp)Mutually exclusive, required parameters.

DSNSpecifies the data set name of the primary OLDS for which a log record isbeing created in RECON.

RUNTIMESpecifies the time stamp of a close operation for the specified primaryOLDS. The time stamp must be in standard form (see “Standard TimeStamp Format” on page 101).

These two parameters are used in conjunction with the STARTIME andNXTOLDS parameters to identify what type of primary OLDS entry is to beadded to RECON. Table 5 indicates which parameter combinations are requiredfor each type of primary OLDS entry:

Table 5. Parameters of NOTIFY.PRILOG (for OLDS) Command for Open, Switch, and Close

Type of Log Entry Required Keywords

OLDS Open STARTIME, DSN, FIRSTREC

NOTIFY.IC


Table 5. Parameters of NOTIFY.PRILOG (for OLDS) Command for Open, Switch, andClose (continued)


OLDS Switch STARTIME, DSN, FIRSTREC, NXTOLDS

OLDS Close LASTREC, STARTIME, RUNTIME

For each primary OLDS, you must issue a separate NOTIFY.PRILOG commandfor open, switch, and close.

STARTIME(timestamp)Required parameter you use to specify the starting time of a primary OLDS.The time stamp must be in standard form, see “Standard Time Stamp Format”on page 101.

See Table 5 on page 271 for a description of the use of this parameter withother parameters in the NOTIFY.PRILOG command.

FIRSTREC(number)Optional parameter you use to specify the log record sequence number of thefirst log record of the OLDS. For the first OLDS of the PRILOG, it correspondsto the first log record that was written during initialization of the IMS subsystem.

FIRSTREC is required for OLDS OPEN and SWITCH commands. It specifies thefirst log record sequence number on the OLDS that is being opened. It is invalidfor a CLOSE command.

The log record sequence number can be one of the following:

v A hexadecimal number

This number is 1 to 16 characters, enclosed in single quotes and precededby the letter, X. For example: FIRSTREC(X'10B9C').

v A decimal number

This number is a decimal number from 0 to (2**64)-1, without delimiters. Forexample: FIRSTREC(68508).

In either case, leading zeros can be omitted.

GSG(gsgname)Optional parameter you use to specify the GSG name of the IMS subsystemthat produced the OLDS.

GSG is required if LOGTOKEN is specified.

INTERIMOptional parameter you use to specify that an interim log data set record is tobe created.

Before you specify NOTIFY.PRILOG INTERIM, a corresponding primary log recordmust exist.

LASTREC(number)Optional parameter you use to specify the log record sequence number of thelast log record of the OLDS.

LASTREC is required for the OLDS CLOSE command. It is optional for theSWITCH command; if it is omitted, the FIRSTREC value minus 1, is recorded forthe OLDS that is being closed. It is invalid for an OPEN command.





This number is 1 to 16 characters, enclosed in single quotes and precededby the letter, X. For example: LASTREC(X'10B9C').

v A decimal number

This number is a decimal number from 0 to (2**64)-1, without delimiters. Forexample: LASTREC(68508).


LOGTOKEN(number)Optional parameter you use to specify the log token to be inserted into thePRILOG record and, if necessary, into the GSG record. It is valid only on anOLDS Open command.

Log tokens are numeric, assigned sequentially within PRILOG records for thesame GSG, and used during recovery to ensure that all logs produced bymembers of the GSG have been included. The highest token assigned to anyPRILOG is recorded in the GSG record.

The log token must satisfy all of the following conditions:

v Must be greater than that contained in the previous PRILOG record for thesame GSG, if any.

v Must be less than that contained in the next PRILOG record for the sameGSG, if any.

v Must not be more than one greater than the high PRILOG token contained inthe specified GSG record.

NXTOLDS(ddname)Optional parameter you use when RECON is to be updated to reflect an OLDSswitch. The current OLDS is closed and an IMS online control region opens anew OLDS. ddname is the DD statement of the OLDS being opened. Youspecify the OLDS being closed with the OLDS(ddname) parameter. Use theDSN(name) parameter to specify the data set name of the OLDS being opened.Use the STARTIME(timestamp) parameter to specify the close time of theOLDS being closed and the open time of the OLDS being opened.

SSID(name)Optional parameter you use to specify the name of the IMS subsystem thatcreated the log data set.

The SSID is an eight-character, alphanumeric string that represents a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses thedefault subsystem identifier in the RECON header record. You use theINIT.RECON or CHANGE.RECON command to set the default subsystem identifier inthe RECON header record. If you have not specified a default in the RECONheader record, you must specify SSID.

Examples of Using the NOTIFY.PRILOG (for OLDS) CommandHere are some examples of using the NOTIFY.PRILOG (for OLDS) command.

Example of Creating a PRIOLDS for an Online Subsystem OLDSIn this example, you create a PRIOLDS for an OLDS that belongs to IMS onlinesubsystem IMSA.//NFYPRILG JOB

...

//SYSIN DD *NOTIFY.PRILOG STARTIME(831230554321) -



DSN(IMS.OLDSP13) OLDS(DFSOLP13) -FIRSTREC(001) -SSID(IMSA)

/*

Example of Adding Information about Two Primary OLDSs toRECONIn this example, you create a PRIOLDS for two OLDSs that belong to the IMSonline subsystem IMSA. Both OLDSs are closed. The first STARTIME parameterspecifies the time stamp of the opening of the primary OLDS. The DSN parameterindicates that information that is added relates to the opening of the OLDS.NXTOLDS indicates an OLDS switch. The second STARTIME parameter andsecond DSN indicate the start time and DSN of the next OLDS. The thirdSTARTIME parameter indicates the start time of the OLDS to be closed. TheRUNTIME parameter is the time stamp of the closing volume.NOTIFY.PRILOG SSID(IMSA) STARTIME(812171212120) OLDS(DFSOLP01) -

DSN(IMS.OLDP01) LASTREC(4999)NOTIFY.PRILOG SSID(IMSA) STARTIME(812181212120) OLDS(DFSOLP01) -

DSN(IMS.OLDP02) NXTOLDS(DFSOLP02)NOTIFY.PRILOG SSID(IMSA) STARTIME(812181212120) OLDS(DFSOLP02) -

RUNTIME(932191010101)/*

Example of Creating a PRILOG to Record 2 OLDSs Opening andClosingIn this example, you create a PRILOG to record the opening and closing of twoOLDSs. The new PRILOG follows an existing PRILOG record for GSG OURGRP,which contains a log token of 1. The three commands are, respectively, OPEN,SWITCH, and CLOSE.NOTIFY.PRILOG SSID(IMSA) +

OLDS(OLDS001) DSN(IMS.OLDS.A01) STARTIME(930140830000) FIRSTREC(1) +GSG(OURGRP) LOGTOKEN(2)

NOTIFY.PRILOG SSID(IMSA) +OLDS(OLDS001) LASTREC(4999)+

NXTOLDS(OLDS002) DSN(IMS.OLDS.A02) STARTIME(930140930000) FIRSTREC(5000)

NOTIFY.PRILOG SSID(IMSA) +OLDS(OLDS002) STARTIME(930140930000) +

RUNTIME(930141030000) LASTREC(9999)

NOTIFY.PRILOG (for RLDS)

OO NOTIFY.PRILOG DSN(name)RUNTIME(timestamp)


O0

CHKPTCT( value )CHKPTID(chkptid) 1

FILESEQ( value )

O


O



OLOGTOKEN(number)

LOCAL

NONLOCAL

RLDS

SSID(name)O

O3400

UNIT( unittype )VOLSER(volser)

OP

Use a NOTIFY.PRILOG command to add information about a primary RLDS (or aprimary SLDS that a batch subsystem created) to RECON and to manually createinterim-primary log data set records in RECON.

This is information that could not be added to RECON from the IMS system logprocessing exit routines. If you are processing DBDSs with IMS, you should notneed to use this command under normal operating conditions. You must specify aNOTIFY.ALLOC command for each DBDS for which change records might exist onthe primary RLDS being added.

This command adds or completes a data set entry in a PRILOG record. If you aremodifying an existing completed data set entry, you should use theCHANGE.PRILOG(RLDS) command.

ParametersDSN(name) | RUNTIME(timestamp)

Mutually exclusive, required parameters.

DSNSpecifies the data set name of the primary RLDS for which a log record isbeing created in RECON.

RUNTIMESpecifies the time stamp of a close or end-of-volume (EOV) operation forthe specified primary RLDS. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

These two parameters are used in conjunction with the STARTIME andVOLSER parameters to identify what type of primary-recovery-log-data set entryis to be added to RECON.

Table 6 indicates which parameter combinations are required for each type ofprimary-recovery-log-data-set entry:

Table 6. Parameters of NOTIFY.PRILOG (for RLDS) Command for Open, EOV, and Close


RLDS Open STARTIME, DSN, VOLSER, FIRSTREC

RLDS EOV STARTIME, VOLSER, RUNTIME

RLDS Close STARTIME, RUNTIME, LASTREC

For each primary RLDS, you must issue a separate NOTIFY.PRILOG commandfor open, zero or more EOVs, and close.

STARTIME(timestamp)Required parameter you use to specify the starting time of a primary RLDS.



The time stamp must be in standard form, see “Standard Time Stamp Format”on page 101.

See Table 6 on page 275 for a description of the use of this parameter withother parameters in the NOTIFY.PRILOG command.

CHKPTCT(0 | value)Optional parameter you use to specify the number of checkpoints completed onthe RLDS volumes.

The valid values for CHKPTCT are:

0 No checkpoints in the RLDS volume

1 A single checkpoint in the RLDS volume

2 More than one checkpoint in the RLDS volume

IMS uses the value of CHKPTCT to determine which logs are necessary torecover a Fast Path area with concurrent image copy.

CHKPTID(chkptid)Optional parameter you use to specify the oldest checkpoint ID for an activepartition specification table (PST) on an RLDS volume. The checkpoint ID mustbe in the standard form for a time stamp (see “Standard Time Stamp Format”on page 101).

FILESEQ( 1 | value)Optional parameter you use to specify the file sequence number of the primaryRLDS that is identified. You can specify this parameter only if you havespecified the VOLSER parameter.

FIRSTREC(number)Optional parameter you use to specify the log record sequence number of thefirst log record of the RLDS. For the first RLDS of the PRILOG, it correspondsto the first log record that was written during initialization of the IMS subsystem.

FIRSTREC is required if DSN is specified and is invalid if RUNTIME isspecified.




v A decimal number



GSG(gsgname)Optional parameter you use to specify the GSG name of the IMS subsystemthat produced the RLDS.

GSG is required if NONLOCAL or LOGTOKEN is specified.

INTERIMOptional parameter you use to specify that an interim log data set record is tobe created. Before you issue the NOTIFY.PRILOG INTERIM command, you mustcreate a corresponding primary recovery log record.



LASTREC(number)Optional parameter you use to specify the log record sequence number of thelast log record of the RLDS.

LASTREC is required if RUNTIME is specified and VOLSER is not specified(that is, on a CLOSE call). LASTREC is invalid if DSN is specified.




v A decimal number



LOGTOKEN(number)Optional parameter you use to specify the log token that is to be inserted intothe PRILOG record and, if necessary, into the GSG record. It is valid only on anRLDS OPEN command; otherwise, it is ignored.

Log tokens are numeric, assigned sequentially within PRILOG records for thesame GSG, and used during recovery to ensure that all logs produced bymembers of the GSG have been included. The highest token assigned to anyPRILOG is recorded in the GSG record.

The log token must satisfy all of the following conditions:

v Must be greater than that contained in the previous PRILOG record for thesame GSG, if any.

v Must be less than that contained in the next PRILOG record for the sameGSG, if any.

v Must not be more than one greater than the high PRILOG token contained inthe specified GSG record.

LOCAL | NONLOCALMutually exclusive, optional parameters you use to specify where the RLDSdata was originally created. LOCAL is used if the RLDS was created by anactive IMS subsystem of the local service group. NONLOCAL is used if theRLDS was originally created by an active IMS subsystem of the non-localservice group and transported to the tracking site.

LOCAL or NONLOCAL need only be specified when creating the PRILOGrecord. The LOCAL and NONLOCAL keywords are ignored on subsequentNOTIFY.PRILOG invocations for the PRILOG record.

If NONLOCAL is specified, none of the keywords CHKPTID, FILESEQ, UNIT, orVOLSER can be specified (the data sets must be cataloged) on anyNOTIFY.PRILOG invocation for the PRILOG record.

RLDSOptional parameter you use to specify that an RLDS record is to be created orupdated.


The SSID is an eight-character alphanumeric string that represents a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses the



default subsystem identifier in the RECON header record. You use theINIT.RECON or CHANGE.RECON command to set the default subsystem identifier inthe RECON header record. If you have not specified a default in the RECONheader record, you must specify SSID.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the RLDSs. You onlyspecify the UNIT parameter if you specify the DSN parameter. The unit typecan be up to eight alphanumeric characters long.

VOLSER(volser)Optional parameter you use to specify the volume serial number of the logvolume being recorded for the identified primary RLDS. For an EOV notification,this volume serial number is that of the volume being started.

You must use the VOLSER parameter during RLDS open and EOV processing.

Examples of Using the NOTIFY.PRILOG (for RLDS) CommandHere are some examples of using the NOTIFY.PRILOG (for RLDS) command.

Example of Adding Primary RLDS Information to RECONIn this example, information about a primary RLDS is to be added to the RECON.The VOLSER and DSN parameters indicate that the information to be added relatesto the opening of the primary RLDS. The STARTIME parameter specifies the timestamp of the opening of the primary RLDS. The first RUNTIME parameter specifiesthe time stamp of the EOV of the first volume of the primary RLDS. The secondRUNTIME parameter specifies the time stamp of the closing volume of the primaryRLDS.//NFYPRILG JOB

...

//SYSIN DD *NOTIFY.PRILOG RLDS STARTIME(820670201010) -

VOLSER(VOL001) DSN(PRILOG1) FIRSTREC(001)NOTIFY.PRILOG RLDS STARTIME(820670201010) -

VOLSER(VOL002) RUNTIME(820670202020)NOTIFY.PRILOG RLDS STARTIME(820670201010) -

LASTREC(9999) RUNTIME(820670303030)/*

Example of Adding Interim-Primary RLDS Information to RECONIn this example, information about the interim-primary RLDS is to be added toRECON. The STARTIME parameter specifies the time stamp of the opening of theinterim primary RLDS.//NFYPRILG JOB

...

//SYSIN DD *NOTIFY.PRILOG RLDS STARTIME(822541234561) -

DSN(DSNIRLDS) -VOLSER(VOL008) -FIRSTREC(077) -INTERIM

/*



Example of Creating a PRILOG Record for 2 Tracking Log DSsIn this example, the sequence of NOTIFY.PRILOG commands create a PRILOGrecord for two log data sets that were received at a tracking site.NOTIFY.PRILOG RLDS DSN(RECEIVED.DSN1) STARTIME(911230405235) -

NONLOCAL SSID(IMSA) GSG(MYGSG) FIRSTREC(1) -VOLSER(VOL003)

NOTIFY.PRILOG RLDS RUNTIME(911230500000) STARTIME(911230405235) -LASTREC(2376)

NOTIFY.PRILOG RLDS DSN(RECEIVED.DSN2) STARTIME(911230405235) -FIRSTREC(2377) VOLSER(VOL002)

NOTIFY.PRILOG RLDS RUNTIME(911230700000) STARTIME(911230405235) -LASTREC(4378)

NOTIFY.PRILOG (for SLDS and TSLDS)

OO NOTIFY.PRILOG SLDSTSLDS

DSN(name)RUNTIME(timestamp)


OCHKPTCT(value) CHKPTID(chkptid) 1

FILESEQ( value )

O


LOCAL

NONLOCALO

OSSID(name) 3400


OP

Use a NOTIFY.PRILOG command to add information about a primary SLDS or TSLDSto RECON and to manually create interim-primary log data set records in RECON.This is information that could not be added to RECON from the IMS system logprocessing exit routines.

If you are processing DBDSs with IMS, you should not need to use this commandunder normal operating conditions. You must specify a NOTIFY.ALLOC command foreach DBDS for which change records might exist on the primary SLDS beingadded.

This command adds or completes a data set entry in the PRISLD or PRITSLDSrecord. If you are modifying an existing completed data set entry, you should usethe CHANGE.PRILOG (for SLDS) or CHANGE.PRILOG (for TSLDS) command.

When you issue a NOTIFY.PRILOG for a SLDS, a PRILOG record must exist for thecorresponding RLDS. Use NOTIFY.PRILOG (for RLDS) to add information about aSLDS that a batch subsystem creates, because DBRC considers such a data set tobe an RLDS.

ParametersSLDS

Required parameter you use to specify that a record is to be created or updatedfor a SLDS.



Important: If you do not specify SLDS or TSLDS, the default is RLDS (see“NOTIFY.PRILOG (for RLDS)” on page 274).

TSLDSRequired parameter you use to specify that a record is to be created or updatedfor a SLDS on an RSR tracking subsystem.

Important: If you do not specify SLDS or TSLDS, the default is RLDS (see“NOTIFY.PRILOG (for RLDS)” on page 274)


DSNSpecifies the data set name of the primary SLDS or TSLDS for which a logrecord is being created in RECON.

RUNTIMESpecifies the time stamp of a close or EOV operation for the specifiedprimary SLDS or TSLDS. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

These two parameters are used in conjunction with the STARTIME andVOLSER parameters to identify what type of primary-system-log-data-set entryis to be added to RECON. Table 7 indicates which parameter combinations arerequired for each type of primary-system-log-data set entry.

Table 7. Parameters of NOTIFY.PRILOG (SLDS or TSLDS) Command for Open, EOV, andClose


SLDS Open STARTIME, DSN, VOLSER, FIRSTREC

SLDS EOV STARTIME, VOLSER, RUNTIME

SLDS Close STARTIME, RUNTIME, LASTREC

For each primary SLDS or TSLDS, you must issue a separate NOTIFY.PRILOGcommand for open, zero or more EOVs, and close.

STARTIME(timestamp)Required parameter you use to specify the starting time of a primary SLDS orTSLDS. Use the log start time from the subsystem record or the PRILOGrecord. The time stamp must be in standard form (see “Standard Time StampFormat” on page 101).

See Table 7 for a description of the use of this parameter with other parametersin the NOTIFY.PRILOG command.

CHKPTCT(value)Optional parameter you use to change the number of checkpoints completed onthe SLDS or TSLDS volumes. You specify a value for each SLDS or TSLDSvolume that is designated


0 No checkpoints in the SLDS or TSLDS volume

1 A single checkpoint in the SLDS or TSLDS volume

2 More than one checkpoint in the SLDS or TSLDS volume




CHKPTID(chkptid)Optional parameter you use to specify the oldest checkpoint ID for an activePST on an SLDS or TSLDS volume. The checkpoint ID must be in the standardform for a time stamp (see “Standard Time Stamp Format” on page 101).

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of the primarySLDS or TSLDS that is identified. You specify this parameter only if you havealso specified the VOLSER parameter.

FIRSTREC(number)Optional parameter you use to specify the log record sequence number of thefirst log record of the SLDS or TSLDS. For the first SLDS of the PRISLD orTSLDS of the PRITSLDS, FIRSTREC corresponds to the first log record thatwas written during initialization of the IMS subsystem.





v A decimal number



GSG(gsgname)Optional parameter you use to specify the GSG name of the IMS subsystemthat produced the SLDS or TSLDS.

GSG is required if NONLOCAL is specified.


LASTREC(number)Optional parameter you use to specify the log record sequence number of thelast log record of the SLDS or TSLDS.

LASTREC is required if RUNTIME is specified and VOLSER is not specified(that is, on a CLOSE call). LASTREC is invalid if DSN is specified.




v A decimal number





LOCAL | NONLOCALMutually exclusive, optional parameters you use to specify where the SLDS orTSLDS data was originally created. LOCAL is used if the SLDS or TSLDS wascreated by an active IMS subsystem of the local service group. NONLOCAL isused if the SLDS or TSLDS was originally created by an active IMS subsystemof the non-local service group and transported to the tracking site.

LOCAL or NONLOCAL need only be specified when creating the PRISLDS orPRITSLDS record. The LOCAL and NONLOCAL keywords are ignored onsubsequent NOTIFY.PRILOG invocations for the PRISLD or PRITSLDS record.

If NONLOCAL is specified, none of the keywords CHKPTID, FILESEQ, UNIT, orVOLSER can be specified (the data sets must be cataloged) on anyNOTIFY.PRILOG invocation for the PRISLD or PRITSLDS record.


The SSID is an eight-character, alphanumeric string that represents a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses thedefault subsystem identifier in the RECON header record. You use theINIT.RECON or CHANGE.RECON command to set the default subsystem identifier inthe RECON header record. If you have not specified a default in the RECONheader record, you must specify SSID.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the SLDSs or TSLDSs.You only specify the UNIT parameter if you specify the DSN parameter. Theunit type can be up to eight alphanumeric characters.

VOLSER(volser)Optional parameter you use to specify the volume serial number of the logvolume being recorded for the identified primary SLDS or TSLDS. For an EOVnotification, this volume serial number is that of the volume being started.

Note: You must use the VOLSER parameter during SLDS or TSLDS open andEOV.

Example of Adding Primary SLDS Information to RECONIn this example, information about a primary SLDS is to be added to RECON. TheVOLSER and DSN parameters indicate that the information to be added relates tothe opening of the primary SLDS. The STARTIME parameter specifies the timestamp of the opening of the primary SLDS. The first RUNTIME parameter specifiesthe time stamp of the EOV of the first volume of the primary SLDS. The secondRUNTIME parameter specifies the time stamp of the closing volume of the primarySLDS.//NFYPRILG JOB

...

//SYSIN DD *NOTIFY.PRILOG SLDS STARTIME(820670201010) -

VOLSER(VOL004) DSN(PRILOG4) FIRSTREC(7000)NOTIFY.PRILOG SLDS STARTIME(820670201010) -

VOLSER(VOL005) RUNTIME(820670202020)NOTIFY.PRILOG SLDS STARTIME(820670201010) -

RUNTIME(820670303030) LASTREC(8889)/*



NOTIFY.RECOV

OO NOTIFY.RECOV DBD(name) DDN(name)AREA(name) RCVTIME(timestamp) RCVUSID(usid)

O

ORUNUSID(usid) ADDN(name)

CURRENT

RUNTIME(timestamp)PITR

DBDS

TRACKOP

Use a NOTIFY.RECOV command to add information about recovery of a specifiedDBDS or DEDB area to RECON. You must use this command whenever youperform the recovery of a DBDS or DEDB area in any way other than using theDatabase Recovery utility (for example, by restoring the DASD volume on which theDBDS or area resides). In addition, you can notify DBRC when you recover aDBDS or DEDB area using the Database Recovery utility.

When specifying the RCVTIME parameter to inform DBRC of a time stamprecovery, RECON must contain a record of the image copy data set that you usedto restore the DBDS or DEDB area. The image copy record can be either astandard or a nonstandard image copy. If it is a nonstandard image copy, then itstime stamp cannot fall within the range of an existing time stamp recovery (the timebetween the RECOV TO and RUN times). The time stamp of the image copy recordmust be equal to that specified in the RCVTIME parameter of the NOTIFY.RECOVcommand.

In a data sharing environment, after you notify DBRC of a nonstandard recovery oran IMS recovery, DBRC turns off the recovery-needed flag and decreases thecounter in the appropriate DBDS and DB records in RECON.

Related Reading: See IMS Version 7 Operations Guide for more informationabout recovery in a data sharing environment.


ParametersDBD(name)

Required parameter you use to specify the database name of the DBDS orDEDB area.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to specify the ddname of theDBDS or DEDB area for which DBRC is to add the database recovery record toRECON.

ADDN(name)Optional parameter you use to specify the ADS DD name of the ADS for whicha Fast Path DEDB area recovery record is being added to RECON.

You can specify this parameter only when you specify the AREA(name)parameter.

NOTIFY.RECOV


CURRENT | RUNTIME(timestamp)PITRMutually exclusive, optional parameters you use to specify the time stamp atwhich the DBDS or DEDB area was recovered.

CURRENTSpecifies that the current time stamp is to be used as the time stamp of therecovery. You can add the recovery information to RECON in a later step ofthe same job that performs the recovery if you specify CURRENT.

RUNTIMESpecifies the actual time stamp of a recovery of the DBDS or DEDB area.The time stamp must be in standard form (see “Standard Time StampFormat” on page 101).

The optional PITR parameter specifies a point-in-time recovery. You mustuse the RCVTIME parameter if you use PITR.

DBDS | TRACKMutually exclusive, optional parameters you use to specify the type of IMSrecovery that was done on a DBDS or DEDB area.

DBDSSpecifies that the recovery was a full recovery or a timestamp recovery.

TRACKSpecifies that the recovery was a track recovery.

If you specify this parameter and the RCVTIME parameter, the command fails.

RCVTIME(timestamp)Optional parameter you use to specify the point in time to which the DBDS orDEDB area was restored. It can be any time when the DBDS or area was notbeing updated, that is, a time that is not covered by an active ALLOC record inRECON.

If you do not specify the RCVTIME parameter, you are notifying DBRC of a fullrecovery.

If you specify RCVTIME and the database or DEDB area is covered by RSR,you must also specify RCVUSID.

You must use RCVTIME if you use the RUNTME parameter with the PITRparameter.

Restriction: Do not use the RCVTIME parameter when recovering from anonstandard image copy at a tracking subsystem.

See 211 for more information on the RCVTIME parameter.

RCVUSID(usid)Optional parameter you use to specify the effective update set identifier (USID)to which the DBD or DEDB area was recovered.

This parameter must be specified if the database or DEDB area is covered byRSR and RCVTIME was specified; it is not allowed if RCVTIME is not specified.The usid you use is the one in the listing of the IMAGE record.

RUNUSID(usid)Optional parameter you use to specify the current update set identifier (usid) atthe time the database or DEDB area was recovered. If this is a receive,RUNUSID is the usid of the image copy that was used for recovery.

RUNUSID must be specified for recovery of an RSR-covered database orDEDB area.

NOTIFY.RECOV


Example of Adding DBDS Recovery Information to RECONIn this example, information about recovery of a specified DBDS is to be added toRECON. The RUNTIME parameter specifies the time stamp of the recovery of theDBDS. The PITR parameter specifies a point-in-time recovery. The RCVTIMEparameter specifies the time stamp to which the specified DBDS was recovered.//NFYRECOV JOB

...

//SYSIN DD *NOTIFY.RECOV DBD(DB1) DDN(DDN1) -

RUNTIME(971351015366) -RCVTIME(971350905297) -PITR

/*

After the command is executed, a listing of the RECON shows the RECOV record,as illustrated below.

RECOVRUN = 1997.135 10:15:36.6 -08:00 * RUN USID = 0000000005RECOV TO= 1997.135 09:05:29.7 -08:00 RECOV TO USID = 0000000004POINT-IN-TIME

NOTIFY.REORG

OO NOTIFY.REORG DBD(name) DDN(name)CURRENT

RUNTIME(timestamp)O

O1

FILESEQ( value )1

FILESEQ2( value )ICDSN(name)

O

OICDSN2(name) RECDCT(value) 3400

UNIT( unittype )

O

O3400

UNIT2( unittype )S

,

VOLLIST( volser )

O

O

S

,

VOLLIST2( volser )

USID(value)OP

Use a NOTIFY.REORG command to add a record to RECON about the reorganizationof the database to which an identified DBDS belongs.

NOTIFY.RECOV


The information in the reorganization record is used by DBRC to determine whichimage copy data sets, change accumulation data sets, and log data sets are validas input to a subsequent recovery of the identified DBDS.

Restrictions:

v This command should not be used following the reorganization of a Fast PathDEDB. Such data bases can be recovered across a reorganization.

v This command turns on the flag needed by the image copy process in the DBDSrecord. You must either run an image copy or issue the CHANGE.DBDS ICOFFcommand to turn off the flag.

v This command can also be used to record in RECON the equivalent of an imagecopy data set that was created for the HISAM Reorganization Reload utility. Usethis command only if you are using these logs as an image copy data set.

v All optional parameters except CURRENT or RUNTIME apply only to the imagecopy data set that was created as part of the processing by the HISAMReorganization Reload utility.

v You must specify a NOTIFY.REORG command for each DBDS in the database thatwas reorganized. A DD statement for the IMS DBDLIB data set must be providedin the job stream of the NOTIFY.REORG command.

v The NOTIFY.REORG command, and database reorganization in general, are invalidfor databases at an RSR tracking site.

v The NOTIFY.REORG command is not allowed for ILDS or Index DBDSs of HALDBpartitions.

ParametersDBD(name)

Required parameter you use to identify the database name of the DBDS thatwas reorganized.

DDN(name)Required parameter you use to identify the data set ddname of the DBDS thatwas reorganized.

CURRENT | RUNTIME(timestamp)Mutually exclusive, optional parameters you use to specify the time stamp ofthe reorganization of the identified DBDS.

CURRENTSpecifies that the current time stamp is to be placed in the reorganizationrecord. You can specify a NOTIFY.REORG command as a later step in thesame job that performs the reorganization if you specify CURRENT.

RUNTIMESpecifies that the actual time stamp of the reorganization is to be placed inthe reorganization record. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of theidentified DBDS that was included in the logs that were used as input to a runof the HISAM Reorganization Reload utility. The description of the ICDSNparameter contains information about the log data set with which this parameteris associated. You use this parameter only when the VOLLIST parameter hasalso been specified.

NOTIFY.REORG


FILESEQ2(1 | value)Optional parameter you use to specify the file sequence number of theidentified DBDS when it was included in the logs that were used as input to theHISAM Reorganization Reload utility. The description of the ICDSN2 parametercontains information about the log data set with which this parameter isassociated. You use this parameter only when the VOLLIST2 parameter hasalso been specified.

ICDSN(name)Optional parameter you use to specify the data set name of the image copydata set that was created as part of a HISAM reorganization of a database. (Ifyou reorganized your database using the HISAM Reorganization Reload utility,the logs that were used as input to that utility can be used as image copy datasets.)

You can specify an ICDSN parameter only if the corresponding DBDS wasidentified to RECON with the NOREUSE attribute in an INIT.DBDS command.

ICDSN2(name)Optional parameter you use to specify the data set name of the duplicate imagecopy data set that was created as part of a HISAM reorganization of adatabase. (If you reorganized your database using the HISAM ReorganizationReload utility, the logs that were used as input to that utility can be used asimage copy data sets.)

You can specify an ICDSN2 parameter only if you have specified an ICDSNparameter.

RECDCT(value)Optional parameter you use to specify the number of records that are containedin the identified DBDS. value must be a decimal number from 1 to2 147 483 647.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the volumes on which theimage copy data set resides. The unit type can be up to eight alphanumericcharacters.

UNIT2(3400 | unittype)Optional parameter you use to specify the unit type of the volumes on which theduplicate image copy data set resides. The unit type can be up to eightalphanumeric characters.

VOLLIST(volser)Optional parameter you use to specify the volume serial numbers of thevolumes on which the image copy data set identified by the ICDSN keywordresides. You can specify up to 255 volume serial numbers for volser; eachvolser can be up to six alphanumeric characters.

VOLLIST2(volser)Optional parameter you use to specify the volume serial numbers of thevolumes on which the duplicate image copy data set, identified by the ICDSN2parameter, resides. You can specify up to 255 volume serial numbers for volser;each can be up to six alphanumeric characters.

USID(value)Optional parameter you use to specify the update set identifier of the databaseor area when the reorganization occurred.

USID is required if the database or area is assigned to a global service group. Ifthe database or area is not assigned to a GSG, USID is optional.

NOTIFY.REORG


Example Adding DBDS Reorganization Information to RECONIn this example, information about a reorganization of a specified DBDS is to beadded to RECON. The DBDLIB data set is specified, because DBRC requests asearch of it to verify that the reorganization occurred. The names of two image copydata sets for the reorganized DBDS are given. They both follow the data setnaming convention, and a list of volumes is provided for both image copy data sets.//NFYREORG JOB

...

//IMS DD DSN=IMS.DBDLIB,DISP=SHR//SYSIN DD *

NOTIFY.REORG DBD(DB1) DDN(DD1) -ICDSN(IMS.DB1.DD1.IC.ICDSN) -VOLLIST(VOL001,VOL002,VOL003) FILESEQ(4) -ICDSN2(IMS.DB1.DD1.IC2.ICDSN2) -VOLLIST2(VOL004,VOL005,VOL006,VOL007) -FILESEQ2(4) RECDCT(12345)

/*

NOTIFY.SECLOG (for OLDS)

OO NOTIFY.SECLOG OLDS(ddname) DSN(name)RUNTIME(timestamp)



O

ONXTOLDS(ddname) SSID(name)

OP

Use a NOTIFY.SECLOG command to add information about a secondary OLDS toRECON and to manually create an ISECOLDS record in RECON. RECON mustalready contain a PRIOLDS record with the same SSID and STARTIME. This isinformation that could not be added from the IMS log data exit routines. Thiscommand is not normally required.


Required parameter you use to specify that a record is to be created or updatedin RECON for the OLDS.

ddname is the ddname that the IMS online control region used when it used theOLDS.


DSNSpecifies the data set name of the secondary OLDS for which an online logrecord is being created in RECON.

NOTIFY.REORG


RUNTIMESpecifies the time stamp of an open or close operation of the specifiedsecondary OLDS. The time stamp must be in standard form (see “StandardTime Stamp Format” on page 101).

DSN and RUNTIME are used in conjunction with the STARTIME and NXTOLDSparameters to identify which type of secondary-online-log-data-set entry is to beadded to RECON. Table 8 indicates the keyword combinations that correspondto the type of secondary-online-log data-set entry:

Table 8. Parameters of NOTIFY.SECLOG (for OLDS) Command for Open, Switch, and Close

Type of Online Log Entry Required Keywords

OLDS Open STARTIME, DSN, FIRSTREC

OLDS Switch FIRSTREC, STARTIME, DSN, NXTOLDS

OLDS Close LASTREC, STARTIME, RUNTIME

For each secondary OLDS, you must issue a separate NOTIFY.SECLOGcommand for open, switch, and close operations.

STARTIME(timestamp)Required parameter you use to specify the starting time of a secondary OLDS.The time stamp must be in standard form (see “Standard Time Stamp Format”on page 101).

See Table 8 for a description of the use of this parameter with other parametersin the NOTIFY.SECLOG command.

FIRSTREC(number)Optional parameter you use to specify the log record sequence number of thefirst log record of the OLDS. For the first OLDS of the SECLOG, FIRSTRECcorresponds to the first log record that was written during initialization of theIMS subsystem.

FIRSTREC is required for OLDS OPEN and SWITCH commands. It specifies thefirst log record sequence number on the OLDS being opened. It is invalid for aCLOSE command.




v A decimal number



GSG(gsgname)Optional parameter you use to specify the GSG name of the IMS subsystemthat produced the OLDS.

GSG is required if LOGTOKEN is specified.

INTERIMOptional parameter you use to specify that an interim log data set record is tobe created. Before you create an interim log data set, you must create asecondary OLDS.



LASTREC(number)Optional parameter you use to specify the log record sequence number of thelast log record of the OLDS.

LASTREC is required for the OLDS CLOSEcommand. It is optional for the SWITCHcommand; if it is omitted, the FIRSTREC value minus 1, is recorded for theOLDS being closed. It is invalid for an OPEN command.




v A decimal number



NXTOLDS(ddname)Optional parameter you use when RECON is to be updated to reflect an OLDSswitch. The current OLDS is closed and an IMS online control region opens anew OLDS. ddname is the DD statement of the OLDS being opened. Youspecify the OLDS being closed with the OLDS(ddname) parameter. Use theDSN parameter to specify the data set name of the OLDS being opened. Usethe STARTIME parameter to specify the close time of the OLDS being closedand the open time of the OLDS being opened.


The SSID is an eight-character alphanumeric string that represents a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses thedefault subsystem identifier in the RECON header record. You use theINIT.RECON or CHANGE.RECON command to set the default subsystem identifier inthe RECON header record. If you have not specified a default in the RECONheader record, you must specify SSID.

Examples of Using the NOTIFY.SECLOG (for OLDS) CommandHere are some examples of using the NOTIFY.SECLOG (for OLDS)command.

Example of Creating the ISECOLDS Record That Corresponds tothe OLDSIn this example, an ISECOLDS record corresponding to the OLDS is created.//NFYSECLG JOB

...

//SYSIN DD *NOTIFY.SECLOG SSID(IMSA) OLDS(DFSOLS03) -

DSN(IMS.INTERIM.LOG) -STARTIME(823220522348) -INTERIM

/*

Example of Creating a SECOLDS Record for 2 Secondary OLDSsIn this example, you create a SECOLDS record for two secondary OLDSs thatbelong to IMS online subsystem IMSA. Both secondary OLDSs are closed. The first



STARTIME parameter specifies the time stamp of the opening of the primary OLDS.The DSN parameter indicates that information added relates to the opening of theOLDS. NXTOLDS indicates an OLDS switch. The second STARTIME parameterand second DSN indicate the start time and DSN of the next OLDS. The thirdSTARTIME parameter indicates the start time of the OLDS to be closed. TheRUNTIME parameter is the time stamp of the closing volume.NOTIFY.SECLOG SSID(IMSA) STARTIME(812171212120) OLDS(DFSOLS01)-

DSN(IMS.OLSS01)NOTIFY.SECLOG SSID(IMSA) STARTIME(812181212120) OLDS(DFSOLS01)-

DSN(IMS.OLSS02) NXTOLDS(DFSOLS02)NOTIFY.SECLOG SSID(IMSA) STARTIME(812181212120) OLDS(DFSOLS02)-

RUNTIME(932191010101)

NOTIFY.SECLOG (for RLDS)

OO NOTIFY.SECLOG DSN(name)RUNTIME(timestamp)


O0


FILESEQ( value )

O


LOCAL

NONLOCALO

ORLDS SSID(name) 3400


OP

Use a NOTIFY.SECLOG command to add information about a secondary RLDS toRECON and to manually create an ISECLOG record in RECON. RECON mustalready contain a PRILOG with the same SSID and STARTIME. This is informationthat could not be added from the IMS log data exit routines. This command is notnormally required.

This command adds or completes a data set entry in the Primary Log record. If youare modifying an existing completed data set entry, you should use theCHANGE.SECLOG (RLDS)command.

ParametersDSN(name) | RUNTIME(timestamp)

Mutually exclusive, required parameters.

DSNSpecifies the data set name of the secondary RLDS for which a recoverylog record is being created in RECON.

RUNTIMESpecifies the time stamp of an open, close, or EOV operation of thespecified secondary RLDS. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).



DSN and RUNTIME are used in conjunction with the STARTIME and VOLSERparameters to identify which type of secondary recovery log data set entry is tobe added to RECON. Table 9 indicates the keyword combinations thatcorrespond to the type of secondary recovery log data set entry.

Table 9. Parameters of NOTIFY.SECLOG (for RLDS) Command for Open, EOV, and Close

Type of Recovery Log Entry Required Keywords

RLDS Open STARTIME, DSN, VOLSER

RLDS EOV STARTIME, VOLSER, RUNTIME

RLDS Close STARTIME, RUNTIME

For each secondary RLDS, you must issue a separate NOTIFY.SECLOG commandfor open, zero or more ends-of-volume, and close processing.

STARTIME(timestamp)Required parameter you use to specify the starting time of a secondary RLDS.The time stamp must be in standard form (see “Standard Time Stamp Format”on page 101).

If you issue a subsequent STARTIME parameter, that time is the start time ofthe volume. See Table 9 for a description of the use of this parameter with otherparameters in the NOTIFY.SECLOG command.

CHKPTCT(0 | value)Optional parameter you use to change the number of checkpoints completed onthe RLDS volumes.


0 No checkpoints in the RLDS volume

1 A single checkpoint in the RLDS volume

2 More than one checkpoint in the RLDS volume


CHKPTID(chkptid)Optional parameter you use to specify the oldest checkpoint ID for an activePST on an RLDS volume. The checkpoint ID must be in standard form for atime stamp (see “Standard Time Stamp Format” on page 101).

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of thesecondary RLDS that is identified. You specify this parameter only if you havealso specified the VOLSER parameter.

FIRSTREC(number)Optional parameter you use to specify the log record sequence number of thefirst log record of the RLDS. For the first RLDS of the SECLOG, it correspondsto the first log record that was written during initialization of the IMS subsystem.







v A decimal number



GSG(gsgname)Optional parameter you use to specify the GSG name of the IMS subsystemthat produced the RLDS.



LASTREC(number)Optional parameter you use to specify the log record sequence number of thelast log record of the RLDS.

LASTREC is required if RUNTIME is specified and VOLSER is not specified(that is, on a Close call). LASTREC is invalid if DSN is specified.




v A decimal number



LOCAL | NONLOCALMutually exclusive, optional parameters you use to specify where the RLDSdata was originally created. LOCAL is used if the RLDS was created by anactive IMS subsystem of the local service group. NONLOCAL is used if theRLDS was originally created by an active IMS subsystem of the non-localservice group and transported to the tracking site.

LOCAL or NONLOCAL need only be specified when creating the SECLOGrecord. The LOCAL and NONLOCAL keywords are ignored on subsequentNOTIFY.SECLOG invocations for the SECLOG record.

If NONLOCAL is specified, none of the keywords CHKPTID, FILESEQ, UNIT, orVOLSER can be specified (the data sets must be cataloged) on anyNOTIFY.SECLOG invocation for the SECLOG record.

RLDSOptional parameter you use to specify that a record is to be created or updatedin RECON for an IMS RLDS.


The SSID is an eight-character alphanumeric string that represents a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses thedefault subsystem identifier in the RECON header record. You use the



INIT.RECON or CHANGE.RECON command to set the default subsystem identifier inthe RECON header record. If you have not specified a default in the RECONheader record, you must specify SSID.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the volumes on which thesecondary RLDSs reside. You only specify the UNIT parameter if you specifythe DSN parameter. The unit type can be up to eight alphanumeric characters.

VOLSER(volser)Optional parameter you use to specify the volume serial number of the recoverylog volume that is being recorded for the identified secondary RLDS. For anEOV notification, this volume serial number is that of the volume being started.Table 9 on page 292 identifies when you use the VOLSER parameter.

Examples of Using the NOTIFY.SECLOG (for RLDS) CommandHere are some examples of using the NOTIFY.SECLOG (for RLDS) command.

Example of Adding Secondary RLDS Information to RECONIn this example, information about a secondary RLDS is to be added to RECON.The STARTIME parameter identifies the secondary RLDS by its opening timestamp. The VOLSER and DSN parameters indicate that the information to be addedrelates to the opening of the primary RLDS. The first RUNTIME parameter specifiesthe time stamp of the EOV of the secondary RLDS. The second RUNTIMEparameter specifies the time stamp of the closing of the secondary RLDS.//NFYSECLG JOB

...

//SYSIN DD *NOTIFY.SECLOG RLDS STARTIME(820670201010) -

DSN(DSN003) VOLSER (VOL001)NOTIFY.SECLOG RLDS STARTIME(820670201010) -

RUNTIME(820680204500) VOLSER(VOL002)NOTIFY.SECLOG RLDS STARTIME(820670201010) -

RUNTIME(820682030000)/*

Example of Adding Interim Secondary RLDS Information toRECONIn this example, information about the interim secondary RLDS is to be added toRECON. The STARTIME parameter specifies the time stamp of the opening of theinterim-secondary RLDS, and the RUNTIME parameter specifies the time stamp ofthe closing of the interim-secondary RLDS.//NFYSECLG JOB

...

//SYSIN DD *NOTIFY.SECLOG RLDS RUNTIME(822561630000)-

STARTIME(822541234561) INTERIM/*

NOTIFY.SECLOG (for SLDS and TSLDS)

OO NOTIFY.SECLOG SLDSTSLDS

DSN(name)RUNTIME(timestamp)




O0


FILESEQ( value )

O


LOCAL

NONLOCALO

OSSID(name) 3400


OP

Use a NOTIFY.SECLOG command to add information about a secondary SLDS orTSLDS to RECON and to manually create an ISECSLDS record in RECON.RECON must already contain a primary log data set record with the same SSIDand STARTIME. This is information that could not be added from the log data existsof the IMS system. This command is not normally required.

This command adds or completes a data set entry in the Primary or Secondary Logrecord. If you are modifying an existing completed data set entry, use theCHANGE.SECLOG (for SLDS) command or the CHANGE.SECLOG (for TSLDS) command.

ParametersSLDS

Required parameter you use to specify that an SLDS record is to be created.

If you do not specify SLDS or TSLDS, the default is RLDS. See“NOTIFY.PRILOG (for RLDS)” on page 274 for more information on the RLDSparameter.

TSLDSRequired parameter you use to specify that a TSLDS record is to be created.

If you do not specify SLDS or TSLDS, the default is RLDS. See“NOTIFY.PRILOG (for RLDS)” on page 274 for more information on the RLDSparameter.


DSNSpecifies the data set name of the secondary SLDS or TSLDS for which asystem log record is being created in RECON.

RUNTIMESpecifies the time stamp of an open, close, or EOV operation of thespecified secondary SLDS. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

DSN and RUNTIME are used in conjunction with the STARTIME and VOLSERparameters to identify which type of secondary system log data set entry is tobe added to RECON. Table 10 indicates the keyword combinations thatcorrespond to the type of secondary system log data set entry.



Table 10. Parameters of NOTIFY.SECLOG (for SLDS or TSLDS) Command for Open, EOV,and Close

Type of System Log Entry Required Keywords

SLDS Open STARTIME, DSN, VOLSER

SLDS EOV STARTIME, VOLSER, RUNTIME

SLDS Close STARTIME, RUNTIME

For each secondary SLDS or TSLDS, you must issue a separate NOTIFY.SECLOGcommand for open, zero or more ends-of-volume, and close processing.

STARTIME(timestamp)Required parameter you use to specify the starting time of a secondary SLDSor TSLDS. The time stamp must be in standard form (see “Standard TimeStamp Format” on page 101).

See Table 10 for a description of the use of this parameter with otherparameters in the NOTIFY.SECLOG command.

CHKPTCT(0 | value)Optional parameter you use to change the number of checkpoints completed onthe SLDS or TSLDS volumes.


0 No checkpoints in the SLDS or TSLDS volume

1 A single checkpoint in the SLDS or TSLDS volume

2 More than one checkpoint in the SLDS or TSLDS volume


CHKPTID(chkptid)Optional parameter you use to specify the oldest checkpoint ID for an activePST on an SLDS or TSLDS volume. The checkpoint ID must be in standardform for a time stamp (see “Standard Time Stamp Format” on page 101).

FILESEQ(1 | value)Optional parameter you use to specify the file sequence number of thesecondary SLDS or TSLDS that is identified. You specify this parameter only ifyou specify the VOLSER parameter.

FIRSTREC(number)Optional parameter you use to specify the log record sequence number of thefirst log record of the SLDS or TSLDS. For the first SLDS or TSLDS of theSECSLD or SECTSLDS, FIRSTREC corresponds to the first log record thatwas written during initialization of the IMS subsystem.





v A decimal number





GSG(gsgname)Optional parameter you use to specify the GSG name of the IMS subsystemthat produced the SLDS or TSLDS.



LASTREC(number)Optional parameter you use to specify the log record sequence number of thelast log record of the SLDS.

LASTREC is required if RUNTIME is specified and VOLSER is not specified(that is, on a close call). LASTREC is invalid if DSN is specified.




v A decimal number



LOCAL | NONLOCALMutually exclusive, optional parameters you use to specify where the SLDS orTSLDS data was originally created. LOCAL is used if the SLDS or TSLDS wascreated by an active IMS subsystem of the local service group. NONLOCAL isused if the SLDS or TSLDS was originally created by an active IMS subsystemof the non-local service group and transported to the tracking site.

LOCAL or NONLOCAL need only be specified when creating the SECSLD orSECTSLDS record. The LOCAL and NONLOCAL keywords are ignored onsubsequent NOTIFY.SECLOG invocations for the SECSLD or SECTSLDS record.

If NONLOCAL is specified, none of the keywords CHKPTID, FILESEQ, UNIT, orVOLSER can be specified (the data sets must be cataloged) on anyNOTIFY.SECLOG invocation for the SECSLD or SECTSLDS record.


The SSID is an eight-character alphanumeric string that represents a valid IMSsubsystem identification name. If you do not specify SSID, DBRC uses thedefault subsystem identifier in the RECON header record. You use theINIT.RECON or CHANGE.RECON command to set the default subsystem identifier inthe RECON header record. If you have not specified a default in the RECONheader record, you must specify SSID.

UNIT(3400 | unittype)Optional parameter you use to specify the unit type of the volumes on which thesecondary SLDSs reside. You only specify the UNIT parameter if you specifythe DSN parameter. The unit type can be up to eight alphanumeric characters.



VOLSER(volser)Optional parameter you use to specify the volume serial number of the systemlog volume that is being recorded for the identified secondary SLDS. For anEOV notification, this volume serial number is that of the volume being started.Table 10 on page 296 identifies when you use the VOLSER parameter.

Example of Adding Secondary SLDS Information to RECONIn this example, information about a secondary SLDS is to be added to RECON.The STARTIME parameter identifies the secondary SLDS by its opening timestamp. The VOLSER and DSN parameters indicate that the information to be addedrelates to the opening of the secondary SLDS. The first RUNTIME parameterspecifies the time stamp of the EOV of the secondary SLDS or TSLDS. The secondRUNTIME parameter specifies the time stamp of the closing of the secondary SLDSor TSLDS.//NFYSECLG JOB

...

//SYSIN DD *NOTIFY.SECLOG SLDS STARTIME(820670201010) -

SSID(IMSC) DSN(DSN006) VOLSER(VOL009)NOTIFY.SECLOG SLDS STARTIME(820670201010) -

RUNTIME(820680204500) VOLSER(VOL003)NOTIFY.SECLOG SLDS STARTIME(820670201010) -

RUNTIME(820682030000)/*

NOTIFY.SUBSYS

OO NOTIFY.SUBSYS SSID(name)BACKIRLM(name) IRLMID(name)

NORMAL

ABNORMALO

OONLINE

BATCH

ENDRECOV

STARTRCVOP

Use a NOTIFY.SUBSYS command to create a subsystem entry in RECON. A check ismade to ensure that a subsystem entry for the specified subsystem does not existin RECON. This command is not normally required.

If you specify this command when you are in a recovery-only environment, thecommand fails.


Required parameter you use to specify the name of the subsystem for whichinformation is to be added. The SSID is an eight-character alphanumeric stringthat represents a valid MVS and IMS subsystem identification name.

BACKIRLM(name)Optional parameter you use to specify the name of the alternate subsystem



IRLM. name is a five-character alphanumeric string. When you specifyBACKIRLM, you must also specify IRLMID.

IRLMID(name)Optional parameter you use to specify the name of the IRLM with which thesubsystem is communicating. The IRLMID is a five-character alphanumericstring.

If IRLMID is not specified, the subsystem is not using an IRLM.

NORMAL | ABNORMALMutually exclusive, optional parameters you use to specify the status of thesubsystem.

NORMALSpecifies that the previous run of the subsystem ended normally and thatthe subsystem is to continue normal processing.

ABNORMALSpecifies that the previous run of the subsystem ended abnormally andrecovery processing is required.

ONLINE | BATCHMutually exclusive, optional parameters you use to specify the type ofsubsystem from which notification is made.

ONLINESpecifies that notification is made from an online subsystem.

BATCHSpecifies that notification is made from a batch subsystem.

STARTRCV | ENDRECOVMutually exclusive, optional parameters you use to specify the sign-on state ofthe subsystem.

STARTRCVSpecifies that the subsystem has signed on for recovery-start processing.

ENDRECOVSpecifies that the subsystem has signed on normally or that a sign-onrecovery-complete call was successful.

Example of Adding a New Subsystem Record to RECONIn this example, a new subsystem record identified by the SSID parameter is addedto RECON. In addition, the subsystem record is marked as online.//NOTIFYSS JOB

...

//SYSIN DD *NOTIFY.SUBSYS SSID(IMS34) ONLINE

/*

NOTIFY.UIC

OO NOTIFY.UIC DBD(name) DDN(name)AREA(name)

CURRENT

RUNTIME(timestamp) UDATA(string)O

NOTIFY.SUBSYS


OUSID(number)

OP

Use a NOTIFY.UIC command to add information to RECON about a nonstandardimage copy data set related to the DBDS or DEDB area that is identified in thecommand. A nonstandard image copy data set is one that was not created by thesupported image copy utility such as, one created via a tape dump of the DASDvolume that contains the identified DBDS or DEDB area. Using the NOTIFY.UICcommand is the only way you can record in RECON the existence of nonstandardimage copy data sets.

You cannot issue this command for a DBDS defined with the REUSE attribute.

Restrictions:

v A nonstandard image copy data set cannot be used as input to the DatabaseRecovery utility (see page 211 for more information).

v This command is not allowed for ILDS or Index DBDSs of HALDB partitions.

ParametersDBD(name)

Required parameter you use to specify the database name of the DBDS orDEDB area for which the nonstandard image copy data set was created.

DDN(name) | AREA(name)Mutually exclusive, required parameters you use to identify, by its name, theDBDS or DEDB area for which the nonstandard image copy data set wascreated.

CURRENT | RUNTIME(timestamp)Mutually exclusive, optional parameters you use to specify the time stamp ofthe creation of the nonstandard image copy data set.

CURRENTSpecifies that the current time stamp is to be used as the time stamp of thecreation of the specified image copy data set. You can create thenonstandard image copy data set and record its creation in RECON asseparate steps of a single job if you specify CURRENT.

RUNTIMESpecifies the actual time stamp of the creation of the identified nonstandardimage copy data set. The time stamp must be in standard form (see“Standard Time Stamp Format” on page 101).

UDATA(string)Optional parameter you use to specify up to 80 bytes of information about theidentified, nonstandard image copy data set. You can use the variable field ofthis parameter to describe how the nonstandard image copy data set wascreated. string must be in character format in order to be visible in a listing ofRECON. It must be enclosed in parentheses.

USID(number)Optional parameter you use to specify the value of the update set identifier ofthe database or area when the image copy data set was created.

USID is required if the database or area is assigned to a GSG.

NOTIFY.UIC


Example of Adding Nonstandard ICDSN Information to RECONIn this example, information about a nonstandard image copy data set is to beadded to RECON. The RUNTIME parameter specifies the time stamp of thecreation of the nonstandard image copy data set. The UDATA parameter specifiesthe user data to be recorded in the record in RECON that is updated by thiscommand.//NFYUIC JOB

...

//SYSIN DD *NOTIFY.UIC DBD(DB1) DDN(DD1) -

RUNTIME(820670201010) -UDATA('DUMP OF VOLUME VOL001 AT 820670201010')

/*

NOTIFY.UIC


NOTIFY.UIC


Chapter 15. RESET Command

RESET.GSG

OO RESET.GSG GSGNAME(gsgname) BOTHRECON1RECON2

OP

Use a RESET.GSG command after an unplanned RSR takeover to remove obsoleterecovery information about RSR-covered databases from the original active siteRECON. For each database or area that is assigned to the specified global servicegroup (GSG), all IC, UIC, ALLOC, RECOV, and REORG records are deleted. Inaddition, all subsystem records of the GSG and related database authorizationinformation along with all OLDS, RLDS, or SLDS records are deleted. Affected CArecords are cleaned up, made available, or deleted as needed.

Before deleting the obsolete information a backup copy of the RECON is created(RESET.GSG issues an internal BACKUP.RECON command). BACKUP.RECON invokes theMVS AMS REPRO command, with its normal defaults, in order to create the backupcopy. Any restrictions applicable to the normal use of the REPRO command applyalso to this command.

Attention: Note that if your RECON RECORDSIZE is greater than 32K thatIDCAMS REPRO can handle the RECORDSIZE as long as the output data set isNOT a sequential file (such as a tape file). Keeping the RECONs on DASD workswell.

If any failure occurs while the RESET.GSG command is processing, but after thebackup copy has been created (as indicated by the REPRO Completion message),use the following procedure:

1. Correct the condition that caused the failure.

2. Restore the RECON from the backup data set.

3. Delete and re-allocate the backup data set.

4. Reissue the RESET.GSG command.

If RESET.GSG fails before the backup copy is complete, follow the same procedure,omitting the third step.



Required parameter you use to specify the GSGNAME.

BOTH | RECON1 | RECON2Mutually exclusive, required parameters you use to specify which copy of theRECON to use.

BOTHIndicates that the RECON is to be copied to the data sets specified by theBACKUP1 and BACKUP2 DD statements.


RECON1Indicates that the RECON is to be copied to the data set specified by theBACKUP1 DD statement.

RECON2Indicates that the RECON is to be copied to the data set specified by theBACKUP2 DD statement.

Example of the RESET.GSG CommandIn the example, the RECON is copied to the BACKUP1 data set, and then theobsolete information is deleted.// JOB...

//BACKUP1 DD . . .//SYSIN DD *RESET.GSG GSGNAME(IMSGSG1) RECON1/*

RESET.GSG


Part 3. Appendixes



Appendix A. Introduction

The following appendixes are reference materials that may be helpful to you inusing DBRC.

In These Appendixes:

v “Appendix B. Understanding Skeletal JCL” on page 309

– “Using the Commands to Generate JCL and User-Defined Output” onpage 309

– “Using IBM-Supplied Skeletal JCL” on page 310

– “Writing Your Own Skeletal JCL” on page 310

– “Understanding the Skeletal JCL Data Set” on page 310

– “Understanding Skeletal JCL Syntax” on page 311

- “Understanding Simple Keywords” on page 311

- “Using Control Keywords” on page 313

- “Writing Control Keywords” on page 320

- “Understanding Skeletal JCL Default Members” on page 329

– “Understanding the Symbolic Keywords Recognized by DBRC” on page 331

- “All Supported Utilities” on page 331

- “Log Archive Utility (ARCHJCL)” on page 332

- “Database Change Accumulation Utility (CAJCL)” on page 333

- “Log Recovery Utility (LOGCLJCL)” on page 334

- “Database Image Copy Utility, Database Image Copy Utility 2, and OnlineDatabase Image Copy Utility (ICJCL and OICJCL)” on page 335

- “Database Recovery Utility- Receive (ICRCVJCL)” on page 336

- “Database Recovery Utility-Recover (RECOVJCL)” on page 338

– “Understanding the IBM-Supplied Skeletal JCL Execution Members” onpage 340

- “The JOB Statement” on page 340

- “Log Archive Utility JCL (ARCHJCL)” on page 340

- “Database Change Accumulation Utility JCL (CAJCL)” on page 346

- “Log Recovery Utility JCL (LOGCLJCL)” on page 349

- “Database Image Copy Utility JCL (ICJCL)” on page 351

- “Online Database Image Copy Utility JCL (OICJCL)” on page 354

- “Database Recovery Utility JCL-Image Copy Receive-Tracking Site(ICRCVJCL)” on page 356

- “Database Recovery Utility JCL (RECOVJCL)” on page 358

v “Appendix C. Sample Listings of RECONs” on page 367

– “Sample Listing of a RECON at the Active Site” on page 373

– “Sample Listing of a RECON at the Tracking Site” on page 401

– “Fields Present in a Listing of a RECON by Record Type” on page 416

v “Appendix D. Considering IMS DBRC RECON Data Set Placement” on page 453


Introduction to the Appendixes


Appendix B. Understanding Skeletal JCL

Using the Commands to Generate JCL and User-Defined OutputEight GENJCL commands are part of the DBRC utility. Seven of these commandsgenerate the JCL and control statements necessary to run various IMSrecovery-related utilities. You can use the remaining command, GENJCL.USER, togenerate user-defined output, including JCL.

Table 11 lists the eight GENJCL commands and what they do.

Table 11. What the GENJCL Commands DoCommand (PDS Member) What the Command GeneratesGENJCL.ARCHIVE (ARCHJCL) Log Archive utility JCL and control statementsGENJCL.CA (CAJCL) Database Change Accumulation utility JCL and control

statementsGENJCL.CLOSE (LOGCLJCL) Log Recovery utility JCL and control statementsGENJCL.IC (ICJCL) Database Image Copy or Database Image Copy 2

utility JCL and control statementsGENJCL.OIC (OICJCL) Online Database Image Copy utility JCL and control

statementsGENJCL.RECEIVE (ICRCVJCL) Database Recovery utility JCL and control statementsGENJCL.RECOV (RECOVJCL) Database Recovery utility JCL and control statementsGENJCL.USER ( ) User-defined output, including JCL and control

statements

Note: DSPUPJCL is provided and can be used with GENJCL.USER, but othertypes of JCL can be used as well. No default is defined.

When you issue a GENJCL command, it uses a skeletal JCL execution member. Theexecution member is a model of the JCL or user output that you are producing. Theexecution member contains symbolic keywords. DBRC substitutes currentinformation for the symbolic keywords. The substituted information comes fromRECON and from skeletal JCL default members, and from your USERKEY values.Typical of the information DBRC substitutes for symbolic keywords are data setnames and volume information. DBRC performs the keyword substitution and thengenerates the JCL or user output you requested by issuing the GENJCL command.

IBM supplies a JOB statement execution member that is used by all GENJCLcommands. If the IBM-supplied skeletal JCL execution members meet your generalrequirements, you can modify them slightly to provide installation-specificinformation. Information on what needs to be modified is contained in “UsingIBM-Supplied Skeletal JCL” on page 310.

If the IBM-supplied skeletal JCL does not meet your general requirements or if youplan to use the GENJCL.USER command, you must write your own skeletal JCLmembers or define new keywords to include in the IBM-supplied skeletal JCL.Information on these topics is in “Writing Your Own Skeletal JCL” on page 310.


Using IBM-Supplied Skeletal JCLIf you are generating JCL for the IMS recovery-related utilities using theIBM-supplied skeletal JCL execution members, the process is simple. It involvesmodifying the IBM-supplied skeletal JCL execution members. For the skeletal JCLexecution members, see “Understanding the IBM-Supplied Skeletal JCL ExecutionMembers” on page 340. Before you use them:

v Add two DD statements (JCLPDS and JCLOUT) to the DBRC dependentaddress space procedure used for online IMS. JCLPDS identifies the partitioneddata set containing the skeletal JCL execution members. JCLOUT identifies thedata set to which the generated job is to be written. Output is in card imageformat. The output data set can be a punch file, a DASD data set that you planto examine before submitting the job for execution, or directly to the MVS internalreader.

These two ddnames can be specified on the GENJCL command. When GENJCL isused, the two specified data sets are in effect for the GENJCL command only, andnot for the life of the job. The JCLOUT data set is opened at the start of thecommand execution and closed at the end of the command execution.Consequently, if multiple GENJCL commands are concatenated in the job stream,the JCLOUT data set (if other than the MVS internal reader) only contains theresults from the last command that was processed.

v Add any STEPLIB and STEPCAT DD names, and job accounting information thatyour installation requires to the skeletal JCL execution member. Except for theskeletal JCL member for the JOB statement, do not add any JOBCAT, JOBLIB,and JES control statements to your skeletal JCL; doing so causes errors ifmultiple steps are generated.

v Change the default value for the REGION parameter on the skeletal JCL EXECstatement if the existing one is not correct for your installation.

v If you plan to generate JCL to run the Log Recovery utility (member LOGCLJCL),replace the DFSWADS0 DD statement.

Recommendation: Exercise care when modifying the skeletal JCL, becauseDBRC does not verify any of the JCL that is generated.

Writing Your Own Skeletal JCL

This section describes the things you need to know before writing your own skeletalJCL or developing simple keywords to modify the IBM-supplied skeletal JCL. Youmust write your own skeletal JCL or simple keywords if the IBM-supplied skeletalJCL execution members do not meet your requirements or if you plan to use theGENJCL.USER command. IBM provides no skeletal JCL execution member for theGENJCL.USER command.

Understanding the Skeletal JCL Data SetAs shown in Figure 18 on page 311, the skeletal JCL data set contains the skeletalJCL members used by the GENJCL command processor to generate output. The twotypes of skeletal JCL members are execution members and default members.

Execution members are models of the output you are generating. Executionmembers can be IBM supplied (as described in the previous section) or supplied byyou. Execution members contain symbolic keywords, which represent informationDBRC provides.

Skeletal JCL


Default members specify default values for symbolic keywords in the executionmembers. The use of default members is optional. You provide the defaultmembers. To use a default member, you specify the member on the GENJCLcommand. Or, in the case of DBDS and CA groups, you can implicitly specify thedefault member (explained in detail later).

Understanding Skeletal JCL Syntax

Skeletal JCL execution members are models of the output to be produced.Typically, execution members contain symbolic keywords. The symbolic keywordsrepresent information that DBRC is to provide. The two types of symbolic keywordsare simple keywords and control keywords. Simple keywords are keywords forwhich DBRC substitutes a value in the output stream (for example, data setnames). Control keywords control what output is generated (for example, whatRECON records are to be used for keyword substitution).

Simple keywords and control keywords are explained in the following sections.

The keywords in skeletal JCL members must be in uppercase.

Understanding Simple KeywordsWhen JCL is generated, simple keywords in the skeletal JCL execution membersare replaced with the current keyword value. For example, the IBM-supplied skeletal

Figure 18. Skeletal JCL Data Set

Skeletal JCL

Appendix B. Understanding Skeletal JCL 311

JCL execution members use %TIME as a simple keyword. When DBRC encounters%TIME, it replaces it with the time of day. Keyword substitution occurs each timeDBRC encounters a simple keyword. Multiple simple keywords can exist in askeletal JCL execution member.

Simple keywords must be assigned a value before you use them. Keyword valuesare assigned (or set) in several different ways, as shown in Figure 19 on page 313.

v The GENJCL command specifies values for some of the simple keywords inskeletal JCL execution or default members. User-defined keywords are assigneda value in the USERKEYS parameter in the command. Other keyword values areset by various parameters on the command. For example, the SSID parametersets the value for the %SSID keyword (the subsystem ID).

v Skeletal JCL default members set default values for keywords in skeletal JCLexecution members.

v The RECON also provides keyword values. For example, when theGENJCL.ARCHIVE command is issued, the ddnames and data set names for theOLDS are obtained from the PRIOLDS and SECOLDS records.

v Some keyword values are implicitly known, for example the time of day.

If during the JCL generation process, a keyword is encountered that has not beenassigned a value, no substitution takes place. Instead, DBRC issues a warningmessage.

When writing your own skeletal JCL execution members, you can define your ownsimple keywords as well as use the simple keywords already recognized by DBRC.For a list of the simple keywords that DBRC recognizes, see “Understanding theSymbolic Keywords Recognized by DBRC” on page 331. You can also define yourown simple keywords and add them to the IBM-supplied skeletal JCL executionmembers.

Here are some conventions, restrictions, and other detail you should know whenwriting simple keywords:

v Keywords must begin with a percent (%) sign.

v The minimum keyword length is two characters, including the percent sign. Themaximum length is eight characters, including the percent sign.

v Keywords must be written using uppercase letters only (A rather than a).

v The first character after the percent sign must be alphabetic (A-Z); the remainingcharacters must be alphanumeric (A-Z, 0-9). Keywords are delimited by anon-alphanumeric character or when the maximum length is reached.

v DBRC does not use any keywords beginning with %W, %X, %Y, or %Z. You can,therefore, use these characters for your own keywords without conflicting withpredefined keywords.

v User-defined simple keywords must be assigned a value with the USERKEYSparameter on the GENJCL command or with a skeletal JCL default member.

v Keyword substitution is performed on columns 1-71 of the skeletal JCL records.Columns 72-80 are not modified. If the keyword value is shorter than thekeyword, the remaining data on the record is shifted to the left and filled withblanks. If the keyword value is longer than the keyword, the remaining data isshifted to the right. If any non-blank characters are shifted beyond column 71, aJCL continuation statement is generated. In some cases (for example, when theoutput is not a JCL statement), it might not be possible to generate a JCL

Skeletal JCL Syntax


continuation statement, because a comma or blank must exist in the outputrecord for DBRC to split it. When DBRC cannot find a break in the statement, itsplits the statement at column 71.

Using Control KeywordsUse control keywords to regulate what JCL (or other output) is generated. Thecontrol keywords are:

v %SELECT

v %ENDSEL

v %DELETE

v %ENDDEL

v %SET MEMBER

v %SET TIMEFMT

The %SELECT keyword selects the RECON records that are needed in order toresolve simple keywords. The %ENDSEL keyword indicates the end of the recordsselected by the %SELECT keyword. These control keywords always occur in pairs. A%SELECT keyword is followed by one or more execution member records, which isfollowed by the %ENDSEL keyword. This sequence of records is called a control groupor, more specifically, a select group.

The %DELETE keyword deletes records from the generated output stream. Deletionoccurs based on a specific condition. The %ENDDEL keyword delimits the scope ofthe %DELETE keyword. These control keywords always occur in pairs. A %DELETEkeyword is followed by one or more execution member records, which is followedby the %ENDDEL keyword. This sequence of records is called a control group or,more specifically, a delete group.

Figure 19. How Simple Keyword Values Are Set

Skeletal JCL Syntax


The %SET MEMBER keyword specifies a different skeletal JCL execution member thatis to be used in the next step of a multi-step job.

The %SET TIMEFMT keyword is used to specify a form for time stamps that appear inGENJCL output.

Using the %SELECT and %ENDSEL KeywordsUse the %SELECT keyword to select one or more records from RECON. The selectedrecords identify IMS data sets or events tracked by DBRC. Information from theselected records is used to resolve simple keywords in the select group. Simplekeywords can occur in the execution member records or in the %SELECT keyworditself.

The format for a select group follows:%SELECT record_type(selection_criteria)execution_member_record(s)%ENDSEL

Select groups can be nested within select groups.%SELECT record_type(selection_criteria)%SELECT record_type(selection_criteria)execution_member_record(s)%ENDSEL%ENDSEL

The record_type is the type of RECON record to be selected. You can select any ofthe following record_types:

v OLDS (PRIOLD)

v SLDS (PRISLD)

v RLDS (PRILOG)

v IC (IMAGE)

v CA (CA)

v ALLOC (ALLOC)

v DBDS (DBDS)

The selection_criteria depend on the type of record you select, and can be timeranges and ddnames.

Both the record_type and selection_criteria can be simple keywords.

As RECON records are selected, information from them is used to set the values ofsimple keywords. The keyword set depend on the type of record being selected andare described in following sections.

Any values assigned to a keyword before the select group is processed areoverridden when the select group is processed. The keyword values in effect afterthe select group is processed are the values set from the last selected record.Keyword values remain unchanged if no records are selected. In this case, therecords in the select group are not processed. The next records to be processedare those that appear just after the %ENDSEL statement. A select group can occurwithin a delete group. When this occurs and the delete group is deleted, the selectgroup is not processed, and no keyword values are set (or changed).

Skeletal JCL Syntax


The selection_criteria for a select group can cause one or more RECON recordsto be selected. One execution member can be output more than once dependingupon the type of records that have been selected.

When the output stream is JCL, a select group can generate either concatenated orrepeated DD statements. The first execution member record of the select groupdetermines which is to be generated. Repeated DD statements are generated if thisrecord is a JCL DD statement and the ddname is a simple keyword. Otherwise, aconcatenated DD statement is generated.

Example:

Assume that the first record is://DDNAME DD DSN= . . .

In this case, concatenated DD statements are generated. Alternatively, the firstrecord might be:

//%DDNAME DD DSN= . . .

In this case, repeated DD statements are generated. When repeated DDstatements are generated, you must provide some mechanism to ensure that therepeated ddnames are unique. When selecting OLDSs, DBRC uses the OLDSddname, which is in the OLDS RECON record. DBRC does not track ddnames forany other type of data set. Therefore, DBRC might not be able to generate uniqueddnames for data sets that are not OLDSs.

The two sections that follow explain the record_type and selection_criteriaparameters in more detail.

Specifying the Record Type ParameterThe types of records that can be specified on the %SELECT keyword are shown inTable 12.

Table 12. Records That Can Be Selected Using the %SELECT Keyword

record_type What Is Selected

OLDS Specifies that OLDSs are to be selected. If dual logging is in effect,both PRIOLDS and SECOLDS can be selected.

SLDS Specifies that PRISLDs are to be selected. The PRISLD is selectedunless the SLDS record in RECON shows the SLDS has an error. Inthis case, the SECSLD is selected. The SLDS is the one created bythe Log Archive utility when archiving OLDSs, not the one createdby an IMS batch region. To select an IMS batch SLDS, specifyRLDS.

SSLDS Specifies that SECSLDs are to be selected.

RLDS Specifies that RLDSs are to be selected. The PRIRLDS is selectedunless the PRILOG record in RECON indicates the RLDS has anerror. In this case, the SECRLDS is selected. RLDS refers to boththe RLDS created by the Log Archive utility and the SLDS createdby an IMS batch region.

SRLDS Specifies that SECRLDSs are to be selected.

IC Specifies that image copy data sets are to be selected.

CA Specifies that change accumulation data sets are to be selected.

Skeletal JCL Syntax


Table 12. Records That Can Be Selected Using the %SELECT Keyword (continued)

ALLOC Specifies that DBDS allocation records are to be selected.

DBDS Specifies that DBDS records are to be selected.

Understanding the Selection Criteria ParameterThe selection criteria depend on the record type you select. Selection criteria aredescribed under the sections on selecting individual record types.

The following common terms, used for selection criteria, are used in the remainderof this chapter.

dbds qualifierSpecifies the DBDS with which the selected records are to be associated. TheDBDS can be specified as dbname, ddname, or CA group name. When a CAgroup name is specified, all DBDSs in the CA group are used for selection. TheDBDS qualifier is used when selecting:

v RLDSs

v Change accumulation data sets

v Image copy data sets

v ALLOC records

v DBDSs

time qualifierSpecifies a time stamp or a range of time stamps.

DBRC selects RECON records by their record key. Many records contain a timestamp and the time that is contained in the record key is signified by anadjacent asterisk (*) in a listing. The time qualifier that is specified in aFROMTIME or TOTIME parameter determines what records DBRC selects.

Some records such as PRILOG or PRISLD records consist of multiple DSNentries, each of which has a start time and stop time. DBRC cannot selectspecific DSN entries without first selecting the entire log record. TheFROMTIME and TOTIME values must be specified such that the entire logrecord that contains desired DSN entries is selected based on the time stampthat is in the record key.

For example, if you specify a FROMTIME of 12:00, DSN entries with timestamps later than 12:00 (but that are included in a PRISLDS record with a starttime of 11:00) would not be selected and displayed by DBRC, because thePRISLDS record itself has a time stamp earlier than the specified FROMTIME.You can specify a zero time value. The time qualifier can be specified in theforms described in “Standard Time Stamp Format” on page 101 in “Chapter 7.DBRC Commands” on page 99.

FIRSTSpecifies that the oldest record is to be selected.

LASTSpecifies that the most recent record is to be selected.

(FROM(time),TO(time)) or (FROM(time)) or FROM(time) or (TO(time)) orTO(time)

Specifies that all records with time greater than or equal to the FROM timeand less than or equal to the TO time are to be selected.

ALLSpecifies that all records are to be selected.

Skeletal JCL Syntax


Using the %DELETE and %ENDDEL KeywordsUse the %DELETE and %ENDDEL keywords to delete records from the output streambased on a specific condition. The syntax of a delete group follows:

OO %DELETE S

,

(relational expression) execution_member_record(s) O

O %ENDDEL OP

%DELETE statements cannot be nested. Each %DELETE keyword must be followed bya corresponding %ENDDEL before another %DELETE keyword is encountered.

The relational expression must be of the form %keyword op 'value' or %keyword op'%userkey' where:

v %keyword is any simple keyword.

v 'value' is any character string enclosed in single quotes. A null string ('') canbe specified for the value. You can specify a zero time value. The time qualifiercan be specified in the forms described in “Standard Time Stamp Format” onpage 101 in “Chapter 7. DBRC Commands” on page 99.

v %userkey is any keyword defined via the USERKEYS parameter in the GENJCLcommand. The %userkey must be enclosed in quotes and the %userkey valuemust exclude leading zeros.

v op is one of the following operators:

EQ Equal

NE Not equal

LT Less than

LE Less than or equal

GT Greater than

GE Greater than or equal

When a %DELETE keyword is encountered in a skeletal JCL execution member, therelational expression is evaluated. If the expression is true, the delete group isdeleted from the output stream. If the expression is false, the applicable records arecopied to the output stream after keywords are resolved. If a value has not beenassigned to a keyword, the value is the null string (''). If an undefined keyword isencountered in the skeletal JCL, an error message is received and no substitutiontakes place.

Specifying Complex Expressions: You can specify complex expressionsconsisting of multiple relational expressions joined by connectives

Definitions: A connective is one of the following logical functions:

& AND function

| OR function

The following is an example of a complex expression:

Skeletal JCL Syntax


%DELETE (relexp1 | relexp2 & relexp3)

The DELETE group is deleted when the entire complex expression is logically true.Complex expressions should have the following characteristics:

v The entire DELETE statement (including the %DELETE) is limited to 80 characters,within which up to five expressions are allowed.

v A connective must be the first character following a relational expression (blanksare optional).

v The statement is processed from left to right with no connective priority and nobracketing.

where:relexpx = relational expression

This complex expression takes the results of the OR operation between relexp1 andrelexp2 and performs the AND operation with relexp3.

Using the %SET MEMBER KeywordThe %SET MEMBER keyword can be used when you are generating multi-step jobs(such as GENJCL.CA with the VOLNUM parameter specified). You use %SET MEMBER tospecify a different skeletal JCL execution member than the one that is executed forthe first step of the job. The execution member you specify is used in all job stepsafter the first. You can explicitly code various %keywords in the execution memberthat is used in job steps after the first one. For example, you can explicitly code the%CAODSN keyword, which is the name of the input change accumulation data set.

The syntax of the %SET MEMBER keyword is:

OO %SET_MEMBER=newmbrname OP

The %SET MEMBER keyword can be placed anywhere in the current skeletal JCLexecution member. However, it takes effect only after processing of the currentexecution member is complete. If you specify more than one %SET MEMBER keyword,the last one specified is the one that is used. In the new member, you can place a%SET statement that specifies any member name.

newmbrname is the name of the skeletal JCL execution member that is to be used forall job steps after the first job step. newmbrname must reside in the library named inthe JCLPDS DD statement. newmbrname is not used until it is necessary to beginprocessing of the new member. It is possible to specify an incorrect member nameand not have an error condition occur until a GENJCL command is issued that causesenough steps to be generated to cause the member to be read.

Using the %SET TIMEFMT KeywordThe %SET TIMEFMT keyword is used to specify a format for time stamps that appearin GENJCL output.

For GENJCL.USER, the default is:TIMEFMT(O,O,C,2,1)

Skeletal JCL Syntax


Note that the GENJCL TIMEFMT default values have been chosen to produce correctoutput with IBM-supplied skeletal JCL. If you use the %SET statement to change theTIMEFMT values in a way that affects the values substituted into the IBM-suppliedJCL statements, the results are unpredictable.

Example:

Here is an example of the %SET TIMEFMT keyword in skeletal JCL.%SET TIMEFMT(,N)%SELECT RLDS(%SSID,LAST)LOGEND =%LOGETIM%ENDSEL

And here is what the output from the preceding example of %SET would render:LOGEND =960111315000

The subsequent four examples are based on the following skeletal JCL member(called USER01) that is used with GENJCL.USER.%SELECT RLDS(%SSID,LAST)LOGETIM=%LOGETIM%ENDSEL

v This sample output format was obtained by using the USER01 JCL, specifyingSSID(XXXX) and using the default for TIMEFMT which is:TIMEFMT(O,O,C,2,1)

LOGETIM=960021315001-0700

v This sample output format was obtained by using the USER01 JCL, specifyingSSID(XXXX) and using the default for TIMEFMT on an open log.

LOGETIM=000000000000+0000

v This sample output format was obtained by using the USER01 JCL, specifyingSSID(XXXX) and using the specification, TIMEFMT(,N).

LOGETIM=960111314544

v This sample output format was obtained by using the USER01 JCL, specifyingSSID(XXXX) and using the specification, TIMEFMT(,,P,4).

LOGETIM=1996.011 13:15:00.0 -07:00

Restriction: The %SET TIMEFMT keyword affects GENJCL output only if it is issuedvia the GENJCL command or from a %SET statement in the skeletal JCL.

The syntax of the %SET TIMEFMT keyword is:

OO %SET_TIMEFMT(subparm,[subparm],...) OP

Related Reading: For detailed information about the TIMEFMT keyword, itsparameters, and format, see “TIMEFMT Parameter Sublist” on page 102 butremember that the TIMEFMT keyword affects GENJCL output only if it is issued via theGENJCL command or from a %SET statement in the skeletal JCL.

Skeletal JCL Syntax


Writing Control KeywordsWhen writing control keywords, you need to observe the following conventions andrestrictions:

v Control keywords must begin in column 1 of a skeletal JCL execution memberrecord.

v Everything specified for the keyword must be contained on one record. Any datafollowing the control statement is ignored.

v Any number of skeletal JCL execution member records can be contained in acontrol group.

v Delete groups and select groups cannot be nested. However, a select group canbe contained within a delete group, or a delete group can be contained within aselect group.

v Execution member records containing control keywords are not copied to theoutput stream.

Selecting OLDSsThe syntax of the %SELECT keyword to select OLDSs is as follows:

OO %SELECT OLDS(ssid,olds_qualifier) OP

ssidSubsystem ID of the IMS online control region that created the OLDS.

olds_qualifierSpecifies the OLDSs that are to be selected as follows:

INUSESpecifies that the OLDS that is currently in use by the specified subsystemis to be selected. If dual logging is in effect, both the primary and secondaryOLDSs are selected.

LATESTSpecifies that the OLDS that was most recently opened by the specifiedsubsystem is to be selected. If dual logging is in effect, both the primaryand secondary OLDSs are selected.

UNARCHSpecifies that all unarchived OLDSs for the specified subsystem are to beselected. If dual logging is in effect, both the primary and secondary OLDSsare selected.

(DDNAME)Specifies one or more OLDSs by ddname. If dual logging is in effect andboth the primary and secondary OLDS are to be selected, both ddnamesshould be specified.

ALLSpecifies that all OLDSs for the specified subsystem are to be selected.

In the execution member records following the %SELECT keyword, you use simplekeywords to specify the type of information to be gathered for each OLDS recordthat is selected. The types of information you can gather are:

%OLDSDDN The ddname of the OLDS.

%OLDSDSN The data set name of the OLDS.

Skeletal JCL Syntax


%OLDSTYP The OLDS type. DBRC sets the %OLDSTYP to P for primary OLDS orS for secondary OLDS.

%OLDOTIM The time the OLDS was opened. DBRC sets %OLDOTIM in the formyydddhhmmsst{offset}.

%OLDCTIM The time the OLDS was closed. DBRC sets %OLDCTIM in the formyydddhhmmsst{offset}. If the OLDS has not been closed, DBRCsets the time to 000000000000+0000.

%OLDSSEL Set to YES if any OLDS was selected. Otherwise, set to NO.

%OLDFRID The log record sequence number of the first log record of theOLDS.

%OLDLRID The log record sequence number of the last log record of theOLDS.

Example 1: The following select group generates repeated DD statements for allunarchived OLDSs belonging to subsystem IMSA.%SELECT OLDS(IMSA,UNARCH)//%OLDSDDN DD DSN=%OLDSDSN,DISP=SHR%ENDSEL

The JCL generated by this select group might be://DFSOLP00 DD DSN=IMS.OLDSP00,DISP=SHR//DFSOLS00 DD DSN=IMS.OLDSS00,DISP=SHR//DFSOLP01 DD DSN=IMS.OLDSP01,DISP=SHR//DFSOLS01 DD DSN=IMS.OLDSS01,DISP=SHR

Example 2: The following select group generates a list of all OLDSs belonging tosubsystem IMSA:%SELECT OLDS(IMSA,ALL)%OLDSTYPOLDS DD NAME=%OLDSDDN

DSN=%OLDSDSNCLOSE TIME=%OLDSCTIM

%ENDSEL

The output generated by this select group might be:POLDS DD NAME=DFSOLP00

DSN=IMS.POLDS00CLOSE TIME=842351638193+0012

POLDS DD NAME=DFSOLP01DSN=IMS.POLDS01CLOSE TIME=842351712246+0055

POLDS DD NAME=DFSOLP02DSN=IMS.POLDS02CLOSE TIME=000000000000+0000

Selecting SLDSsThe syntax of the %SELECT keyword to select SLDS is:

OO %SELECT slds_type(ssid,time_qualifier) OP

slds_typeCan be specified as SLDS (for the PRISLD) or SSLDS (for the SECSLD). This

Skeletal JCL Syntax


keyword selects the entire RECON record, not individual data sets. Therefore,all data sets identified in the SLDS record are selected.

If the selected PRILOG data set is marked in error, DBRC selects theassociated secondary data set if one that is not also in error exists. If theassociated data set exists but is also in error, DBRC selects the original record.If SSLDS is specified, the SECLOG data set is selected regardless of if whether itis marked in error. An SLDS record might not contain a DSN entry. In this case,the values for %SLDSDSN(%LOGDSN), %SLDUNIT (%LOGUNIT), and %SLDVOLS (%LOGVOLS)are null. You must use the %DELETE statement in order to ensure that DBRCsubstitutes valid data in the generated JCL. See “Example 4” on page 323.

ssidThe subsystem ID (of the IMS online control region) that created the OLDSsthat were archived to become SLDSs.

time_qualifierThe time qualifier as specified in the section “Understanding the SelectionCriteria Parameter” on page 316.

In the execution member records following the %SELECT keyword, you specify (usingsimple keywords) the type of information to be gathered for each SLDS record thatis selected. The types of information you can gather are:

%SLDSDSN The data set name of the SLDS.

%SLDUNIT The unit type of the SLDS.

%SLDVOLS The volume serial number of the SLDS.

%SLDFSEQ The file sequence number of the SLDS.

%SLDSTIM The start time of the SLDS. DBRC sets the %SLDSTIM in the formyydddhhmmsst{offset}.

%SLDETIM The stop time of the SLDS. DBRC sets the %SLDETIM in the formyydddhhmmsst{offset}.

%SLDSSEL Set to YES if any SLDS was selected. Otherwise, set to NO.

%SLDRMT Set to YES if the SLDS was created at the tracking site. Otherwise,set to NULL.

%SLDFRID The log record sequence number of the first log record of theSLDS.

%SLDLRID The log record sequence number of the first log record of theSLDS.

Example 3: The following select group generates the most recent SLDS forsubsystem IMSA.%SELECT SLDS(IMSA,LAST)LATEST SLDS: DSN=%SLDSDSN

STOP TIME=%SLDETIM%ENDSEL

The output generated by this select group might be:LATEST SLDS: DSN=IMS.SLDS

STOP TIME=841230812339

Skeletal JCL Syntax


If the SLDS record has more than one data set, then all the data sets to beselected and your output may look like this:LATEST SLDS: DSN=IMS.IMSA.SLDSP.D97107.T1405235.V06

STOP TIME=971071420469+0100LATEST SLDS: DSN=IMS.IMSA.SLDSP.D97107.T1420469.V03

STOP TIME=971071420579+0100LATEST SLDS: DSN=IMS.IMSA.SLDSP.D97107.T1420579.V00

STOP TIME=971071430087+0100

Example 4: The following select group generates a concatenated DD statementfor all SLDSs for subsystem IMSA that have an open time greater than or equal to840031903298.%SELECT SLDS(IMSA,FROM(840031903298))%DELETE (%SLDSDSN EQ '')//SLDS DD DSN=%SLDSDSN,DISP=OLD,// UNIT=%SLDUNIT,// VOL=SER=(%SLDVOLS),// LABEL=(1,SL)%ENDDEL%ENDSEL

The generated DD statements might be://SLDS DD DSN=IMS.SLDS1,DISP=OLD,// UNIT=3400,// VOL=SER=(VOLUM1,VOLUM2,VOLUM3),// LABEL=(1,SL)// DD DSN=IMS.SLDS2,DISP=OLD,// Unit=3400,// VOL=SER=(VOLUM4,VOLUM5,VOLUM6,// VOLUM7, C// VOLUM8,VOLUM9),// LABEL=(1,SL)

Attention: In this example, a JCL continuation card was generated. This isbecause the volume serial number list was longer than the output record.

The %DELETE statement prevents the JCL statement from being generated for anSLDS record that does not contain a DSN entry.

Selecting RLDSsThe syntax of the %SELECT keyword to select RLDSs can be specified in one of thefollowing ways:

OO %SELECT RLDS(ssid,time_qualifier ),max_volumes

OP

OO %SELECT SRLDS(ssid,time_qualifier ),max_volumes

OP

OO %SELECT RLDS(dbds_qualifier,time_qualifier ),max_volumes

OP

Skeletal JCL Syntax


Use SRLDS to request that secondary RLDS records be selected. Secondary RLDSrecords can be specifically requested only when you specify SSID. When youspecify dbds_qualifier, you are specifically requesting primary RLDS records. Ifthe primary RLDS is marked in error, DBRC selects the associated secondary dataset if one that is not also in error exists. If no associated data set exists or if it isalso in error, DBRC selects the original record.

ssidThe subsystem ID of the IMS online control region or an IMS batch region.PRILOG (or SECLOG) records corresponding to the specified SSID areselected to satisfy the specified search criteria. Because RECON records areselected, all data sets identified by the record are selected.

time_qualifierTime qualifier as specified in the section “Understanding the Selection CriteriaParameter” on page 316.

dbds_qualifierDBDS qualifier as specified in the section “Understanding the Selection CriteriaParameter” on page 316. When a dbds_qualifier is specified, only RLDSs thatcontain log records corresponding to the specified DBDS are selected. (In otherwords, those RLDSs for which an ALLOC record exists in RECON.) Onlyprimary RLDSs can be selected when the dbds_qualifier is specified.

max_volumesThe maximum number of log volumes to be selected. If max_volumes isspecified, processing of the select group terminates when the specified numberof log volumes is reached. If max_volumes is specified and a log merge situationexists, more than the specified number of volumes can be selected. This is toensure that a valid subset of logs is selected.

In the execution member records following the %SELECT keyword, you use simplekeywords to specify the type of information to be gathered for each RLDS recordthat is selected. The types of information you can gather are:

%LOGDSN The data set name of the RLDS.

%LOGFSEQ The file sequence number of the RLDS.

%LOGUNIT The unit type of the RLDS.

%LOGVOLS The volume serial number of the RLDS.

%LOGSTIM The start time of the RLDS. DBRC sets %LOGSTIM in the formyydddhhmmsst{offset}.

%LOGETIM The stop time of the RLDS. DBRC sets %LOGETIM in the formyydddhhmmsst{offset}. If the data set is still open, the time is set to000000000000+0000.

%LOGSEL Set to YES if any log data sets were selected. Otherwise, set to NO.

%LOGMERG Set to YES if a log merge is required. Otherwise, set to NO. %LOGMERGis always set to NO if SSID is specified.

%LOGONL Set to YES if the RLDS is associated with an online region. Set to NOfor batch logs.

%LOGRMT Set to YES if the RLDS was created at the tracking site. Otherwise,set to NULL.

%LOGFRID The log record sequence number of the first log record of theRLDS.

Skeletal JCL Syntax


%LOGLRID The log record sequence number of the last log record of theRLDS.

Example 5: The following select group generates a DD statement for themost-recent RLDS for subsystem BATCHJOB. This example assumes the RLDS isstill open.%SELECT RLDS(BATCHJOB,LAST)%DELETE (%LOGETIM NE '000000000000+0000')//LOGDD DD DSN=%LOGDSN,DISP=OLD,// UNIT=%LOGUNIT,// VOL=SER=(%LOGVOLS),// LABEL=(%LOGFSEQ,SL)%ENDDEL%ENDSEL

If no RLDS is recorded in RECON for the subsystem or if the most-recent RLDShas been closed, no DD statement is generated. Otherwise, the generated DDstatement might be://LOGDD DD DSN=IMS.RLDS,DISP=OLD,// UNIT=3400,// VOL=SER=(VOLUM1,VOLUM2)// LABEL=(1,SL)

Selecting Image Copy Data SetsThe syntax of the %SELECT keyword to select image copy data sets is:

OO %SELECT IC(dbds_qualifier,time_qualifier) OP

dbds_qualifier and time_qualifierDBDS qualifier and time qualifier are as specified in “Understanding theSelection Criteria Parameter” on page 316.

In the execution member records following the %SELECT keyword, you specify (usingsimple keywords) the type of information to be gathered for each image copy recordthat is selected. If the duplicate image copy is marked in error, the DBRC selectsthe primary image copy. The types of information you can gather are:

%ICDSN The data set name of the image copy data set.

%ICTYPE The image copy’s type: BATCH, ONLINE, CIC, SMSCIC, orSMSNOCIC.

%ICFSEQ The file sequence number of the image copy data set if it is aNONHSSP type; otherwise, ICFSEQ is null.

%ICSEL Set to YES if any image copy data set was selected. Otherwise,ICSEL is set to NO.

%ICSTOP The stop time of the image copy data set ID that is present;otherwise ICSTOP is null.

%ICTIME The run time of the image copy. DBRC sets %ICTIME in the formyydddhhmmsst{offset}.

%ICUNIT The unit type of the image copy data set if it is a NONHSSP type;otherwise, ICUNIT is null.

Skeletal JCL Syntax


%ICVCNT The number of volumes of the image copy data set if it is aNONHSSP type; otherwise, ICVCNT is null.

%ICVOLS The volume serial number list of the image copy data set if it is aNONHSSP type; otherwise, ICVOLS is null.

%ICUSID The update set identifier (USID).

%ICCAT Set to YES if the image copy is cataloged (HSSP CICs only).Otherwise, ICCAT is set to NO.

%IC2SEL Set to YES if a duplicate image copy data set is associated with theselected image copy data set. Otherwise, IC2SEL is set to NO.

The following keywords are set only when a duplicate image copy data set exists;otherwise, they are null:

%IC2DSN The data set name of the duplicate image copy data set.

%IC2FSEQ The file sequence number of the duplicate image copy data set. Ifthe IC was created by HSSP, IC2FSEQ is set to null.

%IC2UNIT The unit type of the duplicate image copy data set. If the IC wascreated by HSSP, IC2UNIT is set to null.

%IC2VCNT The number of volumes of the duplicate image copy data set. If theIC was created by HSSP, IC2VCNT is set to null.

%IC2VOLS The volume serial number list of the duplicate image copy data set.If the IC was created by HSSP, IC2VOLS is set to null.

Example 6: The following select group generates a DD statement for the oldestimage copy data set for the DBDS with a database name of SHISAMDB and addname of SHISAMDD.%SELECT IC((SHISAMDB,SHISAMDD),FIRST)//ICDD DD DSN=%ICDSN,DISP=OLD,// VOL=SER=(%ICVOLS),// UNIT=%ICUNIT,// LABEL=(%ICFSEQ,SL)%ENDSEL

The generated DD statement might be://ICDD DD DSN=SHISAMDB.SHISAMDD.IC,DISP=OLD,// VOL=SER=(VOLUM1),// UNIT=3400,// LABEL=(1,SL)

Selecting Change Accumulation Data SetsThe syntax of the %SELECT keyword to select change accumulation data sets is:

OO %SELECT CA(dbds_qualifier,time_qualifier) OP

dbds_qualifier and time_qualifierDBDS qualifier and time qualifier are as specified in the section “Understandingthe Selection Criteria Parameter” on page 316.

In the execution member records following the %SELECT keyword, you use simplekeywords to specify the type of information to be gathered for each changeaccumulation record that is selected. The types of information you can gather are:

Skeletal JCL Syntax


%CADSN The change accumulation data set name.

%CAFSEQ The file sequence number of the change accumulation data set.

%CAUNIT The unit type of the change accumulation data set.

%CAVCNT The number of volumes of the change accumulation data set.

%CAVOLS The volume serial number list of the change accumulation data set.

%CALGTM The volume stop time of the last log volume that was used as inputto the change accumulation data set. DBRC sets %CALGTM in theform yydddhhmmsst{offset}.

%CATIME The change accumulation data set time in the formyydddhhmmsst{offset}.

%CASEL Set to YES if any change accumulation data sets are selected.Otherwise, set to NO.

Example 7: The following select group lists all change accumulation data setscreated since time 842310000000+0000 for CA group CAGRP1.%SELECT CA((CAGRP1),FROM(842310000000+0000))

DSNAME=%CADSNVOLUMES=%CAVOLSRUNTIME=%CATIMELOGTIME=%CALGTM

%ENDSEL

The generated output might be:DSNAME=CAGRP1.DSN1

VOLUMES=VOLUM1,VOLUM2,VOLUM3,VOLUM4, C

// VOLUM5,VOLUM6RUNTIME=842310618230LOGTIME=842302315557

DSNAME=CAGRP1.DSN2VOLUMES=VOLUM1,VOLUM2RUNTIME=842361824443LOGTIME=842360934519

In this example, the volume serial number list for the first data set does not fit onthe output record. Therefore, a JCL continuation statement is generated (eventhough JCL is not being generated).

Selecting DBDS Allocation (ALLOC) RecordsThe syntax of the %SELECT keyword to select ALLOC records can be one of thefollowing:

OO %SELECT ALLOC(dbds_qualifier,time_qualifier) OP

OO %SELECT ALLOC(PRILOG,time_qualifier) OP

dbds_qualifier and time_qualifierDBDS qualifier and time qualifier are as specified in the section “Understandingthe Selection Criteria Parameter” on page 316. When a dbds_qualifier is

Skeletal JCL Syntax


specified, ALLOC records corresponding to the specified DBDSs are selected.All ALLOC records for the specified DBDS with allocation times within thebounds of the specified time_qualifier are selected. When PRILOG is specified,all ALLOC records corresponding to PRILOG records within the specified timebounds are selected.

In the execution member records following the %SELECT keyword, you use simplekeywords to specify the type of information to be gathered for each ALLOC recordthat is selected. The types of information you can gather are:

%DBNAME The database name.

%DBDDN The database ddname or area name.

%ALLTIME The allocation time stamp in the form yydddhhmmsst{offset}.

%DALTIME The deallocation time stamp in the form yydddhhmmsst{offset}. Setto 000000000000+0000 if there is no deallocation time stamp.

%ALLDSSN The data set sequence number.

%PLGTIME The start time of the corresponding PRILOG record.

%ALLSEL Set to YES if any ALLOC records are selected. Otherwise, ALLSEL isset to NO.

%ALLUSID The update set identifier (USID)

Example 8: The following select group generates a list of information about allALLOC records for the DBDS with a database name of SHISAMDB and ddname ofSHISAMDD:%SELECT ALLOC((SHISAMDB,SHISAMDD),ALL)

DBNAME %DBNAMEDDNAME %DBDDNALLOC time %ALLTIMEDEALL time %DALTIMEPRILOG time %PLGTIME

The generated output might be:DBNAME SHISAMDDNAME SHISAMALLOC TIME 832560800000+0000DEALL TIME 000000000000+0000PRILOG TIME 832560630000+0000

Selecting DBDS RecordsThe syntax of the %SELECT keyword to select DBDS records is:

OO %SELECT DBDS(dbds_qualifier) OP

dbds_qualifierDBDS qualifier is as specified in the section “Understanding the SelectionCriteria Parameter” on page 316. For DEDBs, the select group is processedonce for each defined area data set (ADS) for each specified area. For othertypes of databases, the select group is processed once for each specifiedDBDS.

Skeletal JCL Syntax


In the execution member records following the %SELECT keyword, you use simplekeywords to specify the type of information to be gathered for each DBDS recordthat is selected. The types of information you can gather are:

%DBNAME The database name.

%DBDDN The DBDS ddname or DEDB area name.

%DBTYPE Set to FP when the selected DBDS is an area of a Fast Pathdatabase. Set to DLI for DBDSs of non-HALDBs. Set to PDATA fordata DBDSs of HALDBs. Set to PINDEX for primary index DBDSs ofHALDBs. Set to PILDS for ILDS DBDSs of HALDBs.

%DBDSN The data set name of the DBDS or ADS.

%DBADDN For DEDBs, the ddname of the ADS. For other types of databases,DBADDN is set to null.

%DBADSAV For DEDBs, set to AVAIL if the ADS is indicated as available inRECON. Set to UNAVAIL if the ADS is unavailable. For other typesof databases, DBADSAV is set to null.

%DBDSSEL Set to YES if any DBDS records are selected. Otherwise, DBDSDEL isset to NO.

%DBUSID For DEDBs, the update set identifier (USID) of the area. For othertypes of databases, DBUSID is set to NULL.

%DBDSNRV Set to YES if the DBDS is non-recoverable. Otherwise, DBDSNRV isset to NO.

Example 9: The following select group generates a series of DD statements foravailable area data sets for the area named DBHVSAM1. This area is in the DEDBnamed DIVNTZ04.%SELECT DBDS((DIVNTZ04,DBHVSAM1))%DELETE (%DBADSAV ne 'AVAIL')//%DBADDN DD DSN=%DBDSN,DISP=OLD%ENDDEL%ENDSEL

The generated output might be://FP1ADD1 DD DSN=IMS.FP1ADD1,DISP=OLD//FP1ADD2 DD DSN=IMS.FP1ADD2,DISP=OLD

Understanding Skeletal JCL Default MembersSkeletal JCL default members are used to set default values for keywords you havedefined in the skeletal JCL execution members. The use of default members isoptional. You must supply any default members to be used.

Writing Default MembersDefault members can have two types of records: assignment records or commentrecords. Assignment records assign default values to user-defined keywords.Assignment records must contain a percent sign (%) in column 1. If a record doesnot contain a percent sign in column 1, it is a comment record, which DBRCignores.

OO %user defined keyword='value' OP

Skeletal JCL Syntax


The value assigned to the keyword can be any text string, including the null string(''). If the value contains a single quote, you must use two single quotes. Theentire value must be contained on one record. Any data following the closing singlequote is ignored. A closing single quote is required. If a closing single quote ismissing, an error message is generated and the GENJCL command fails.

Example 10: A default member contains these records:%DEDBNAM = 'DIVNTZ04'%AREANAM = 'DBHVSAM1'

A skeletal JCL member contains:DATABASE NAME = %DEDBNAMAREA NAME = %AREANAM

Using the DEFAULTS parameter and assuming the values are not overridden, theGENJCL command generates the following:DATABASE NAME = DIVNTZ04AREA NAME = DBHVSAM1

Specifying Default MembersYou can specify default members either explicitly or implicitly.

Members are explicitly specified using the DEFAULTS parameter on the GENJCLcommand. Up to 10 default members can be specified.

Implicit specification can be used for the GENJCL commands that apply to a DBDS(GENJCL.IC, GENJCL.OIC, and GENJCL.RECOV) or CA group (GENJCL.CA). In addition,implicit specification can be used on the GENJCL.USER command. The defaultmembers to be implicitly used are specified using the DEFLTJCL parameter on theINIT.DBDS, CHANGE.DBDS, INIT.CAGRP, and CHANGE.CAGRP commands. Only onedefault member is allowed per DBDS or CA group.

The use of an implicit default member can be overridden with the NODEFLTparameter on the GENJCL command. When both explicitly and implicitly specifieddefault members are used, explicitly specified members have precedence. That is, ifa keyword is assigned a value in both members, the value assigned by the explicitlyspecified member is used.

If a keyword is assigned a value both in a default member and in the USERKEYSparameter of the GENJCL command, the latter value is used. USERKEYS parametervalues override default member values.

Using User-Supplied or Modified Skeletal JCLBefore using your skeletal JCL execution or default members, you must do thefollowing:

v Add the JCLPDS and JCLOUT ddnames to the JCL required to run DBRC. JCLPDSidentifies the partitioned data set containing the skeletal JCL execution members.JCLOUT identifies the data set to which the generated job is to be written. Outputis in card image format. The output data set can be a punch file, a DASD dataset that you plan to examine before submitting the job for execution, or directly tothe MVS internal reader.

v Add to the skeletal JCL execution member any STEPLIB and STEPCAT ddnamesand job accounting information that your installation requires. If the DDstatements contain comments or continuation characters, they are ignored when

Skeletal JCL Syntax


the JCL is generated. Except for the skeletal JCL member for the JOB statement,do not add to your skeletal JCL any JOBCAT, JOBLIB, and JES control statements;doing so causes errors if multiple steps are generated.

Understanding the Symbolic Keywords Recognized by DBRCTable 13 through Table 19 on page 338 show the symbolic keywords that DBRCrecognizes in the IBM-supplied skeletal JCL execution members.

Table 13 shows the keywords that all supported utilities recognize.

Table 14 on page 332 through Table 19 on page 338 show the keywords that eachindividual utility recognizes.

These figures and the figures in “Understanding the IBM-Supplied Skeletal JCLExecution Members” on page 340 are presented in the order of the GENJCLcommands:

v GENJCL.ARCHIVE (Log Archive utility; see “GENJCL.ARCHIVE” on page 185 fordetails of the command usage.)

v GENJCL.CA (Database Change Accumulation utility; see “GENJCL.CA” onpage 189 for details of the command usage.)

v GENJCL.CLOSE (Log Recovery utility; see “GENJCL.CLOSE” on page 193 fordetails of the command usage.)

v GENJCL.IC and GENJCL.OIC (Database Image Copy utility, and Database ImageCopy 2 utility; Online Database Image Copy utility; see “GENJCL.IC” onpage 195 and “GENJCL.OIC” on page 202 for details of the commands usage.)

v GENJCL.RECEIVE (Database Recovery utility; see “GENJCL.RECEIVE” onpage 207 for details of the command usage.)

v GENJCL.RECOV (Database Recovery utility; see “GENJCL.RECOV” on page 211 fordetails of the command usage.)

All Supported UtilitiesTable 13 explains the symbolic keywords recognized by all the supported utilities.

Table 13. Symbolic Keywords in Skeletal JCL

Keyword Description

%RCNDSN1 Name of the RECON1 data set if RECONs are allocated by JCL. Set to null ifRECONs are dynamically allocated.



Skeletal JCL Syntax


Table 13. Symbolic Keywords in Skeletal JCL (continued)

Keyword Description

%STPNO The current step number. The step number is set to 0 if the JOB parameterwas specified on the GENJCL command. The step number is increased by 1when DBRC first encounters it in a skeletal JCL execution member. The stepnumber remains at that value while the execution member is processed. Asthe keyword is encountered in the remaining skeletal JCL, the current value issubstituted.

The JCL execution member can be processed again because of a multi-stepgeneration, or because the subsequent GENJCL command specifies NOJOB.When it is processed again the step number is increased by 1 from its currentvalue when the keyword is first encountered in the next skeletal JCLexecution member. This increase takes place before the keyword value issubstituted.

%TIME The time of day, in the form hhmmss.

%GRPINDX The DBDS group member index. This keyword is set only when a DBDSgroup is specified, implicitly or explicitly, on the GENJCL command. (A DBDSgroup can be specified on the GENJCL.IC, GENJCL.OIC, GENJCL.RECOV, andGENJCL.USER commands.)

When you specify a DBDS group, the keyword is initialized to 1. It is thenincreased by 1 as each successive group member is processed.

%CNTR A counter controlled by DBRC. The counter is set to 0 whenever the firstGENJCL command is issued or a JOB statement is reproduced from the skeletalJCL execution member JOBJCL. DBRC increases the counter by 1 each timethe keyword is encountered in a skeletal JCL execution member.

The JCL execution member can be processed again because of a multi-stepgeneration, or because the subsequent GENJCL command specifies NOJOB. Ifso, the counter continues to increase from its current value when the keywordis encountered in next skeletal JCL execution member. This increase takesplace before the keyword value is substituted.

%DATE The day of the year, in the form yyddd.

%DATE7 The day of the year, in the form yyyyddd.

Log Archive Utility (ARCHJCL)Table 14 explains the symbolic keywords recognized by the Log Archive utility.

Table 14. Symbolic Keywords for Log Archive Utility

Keyword Description

%SSID The subsystem ID, which is set from the SSID parameter on theGENJCL.ARCHIVE command. If the SSID parameter is not specified, the defaultsubsystem ID is used. The default subsystem ID is set by you in theINIT.RECON or CHANGE.RECON command. If no default subsystem ID wasspecified, the command fails.

%DDNAMES The ddnames of the OLDSs that are to be archived. If ALL is specified orused as the default on the GENJCL.ARCHIVE command, the ddnames of allunarchived OLDSs are determined from RECON. Otherwise, the ddnamesspecified on the command are used.

%OLDSDDN The ddname of one or more specific OLDS.

%OLDSDSN The data set name of the one or more OLDS.

Symbolic Keywords


Table 14. Symbolic Keywords for Log Archive Utility (continued)

Keyword Description

%ARDATE The date (from the open time stamp) of the first OLDS that is to be archived.The date is in the form yyddd where:

yy is the year

ddd is the day

%ARDATE7 The date (from the open time stamp) of the first OLDS that is to be archived.The date is in the form yyyyddd where:

yyyy is the 4-digit year

ddd is the Julian day

%ARTIME The time (from the open time stamp) of the first OLDS that is to be archived.The time is in the form hhmmsst where:

hh is the hour

mm is the minute

ss is the second

t is the tenth of a second

%ARVERS The archive version number of the first OLDS to be archived.

%ARCSLDS Set to YES when the SLDS parameter is specified.

Database Change Accumulation Utility (CAJCL)Table 15 explains the symbolic keywords recognized by the Database ChangeAccumulation utility.

Table 15. Symbolic Keywords for Database Change Accumulation Utility

Keyword Description

%CAGRP The CA group name.

%DSLLGTM The start time for selecting input log data. If an input change accumulationdata set is used, %DSLLGTM is set to the volume stop time of thelast-accumulated log volume.

%CAODSN The data set name of the input change accumulation data set. This keywordis set to null if no existing change accumulation data set is defined in RECONfor the CA group.

%CAOUNIT The unit type of the input change accumulation data set. This keyword is setto null if no existing change accumulation data set is defined in RECON forthe CA group.

%CAOVOLS The volume serial number list of the input change accumulation data set. Thiskeyword is set to null if there is no existing change accumulation data set isdefined in RECON for the CA group.

%CAOFSEQ The file sequence number of the input change accumulation data set. Thiskeyword is set to null if no existing change accumulation data set is defined inRECON for the CA group.

%CANDSN The data set name of the output change accumulation data set. If REUSE isspecified for the CA group, the keyword is set from information in RECON. IfNOREUSE is specified, DBRC generates a data set name. The generated nameis:

IMS.cagrpname.CA.CAhhmmss

where cagrpname is the CA group name, and hhmmss is the current time of day.

Symbolic Keywords


Table 15. Symbolic Keywords for Database Change Accumulation Utility (continued)

Keyword Description

%CANUNIT The unit type of the output change accumulation data set. If REUSE is specifiedfor the CA group, the keyword is set from information in RECON. If NOREUSE isspecified, this keyword is set from the UNIT parameter on the GENJCL.CAcommand. If UNIT is not specified, the keyword is set to 3400.

%CANVCNT The number of volumes in the output change accumulation data set. If REUSEis specified for the CA group, the keyword is set from information in RECON.If NOREUSE is specified, this keyword is set from the VOLLIST parameter on theGENJCL.CA command.

%CANVOLS The volume serial number list of the output change accumulation data set. IfREUSE is specified for the CA group, the keyword is set from information inRECON. If NOREUSE is specified, this keyword is set from the VOLLISTparameter on the GENJCL.CA command.

%CABFSEQ The file sequence number of the output change accumulation data set. IfREUSE is specified for the CA group, the keyword is set from information inRECON. If NOREUSE is specified, this keyword is set to 1.

%LOGDSN The data set name of the log data set.

%LOGUNIT The unit type of the log data set.

%LOGVSEQ The volume sequence number of the log data set.

%LOGVOLS The volume serial numbers of the log data set.

%LOGFSEQ The file sequence number of the log data set.

%LOGSEL Set to YES if any log data sets were selected. Otherwise, set to NO.

%CADB0 This keyword generates the DB0 control statements for the Database ChangeAccumulation utility.

Log Recovery Utility (LOGCLJCL)Table 16 explains the symbolic keywords recognized by the Log Recovery utility.

Table 16. Symbolic Keywords for Log Recovery Utility

Keyword Description

%SSID The subsystem ID, which is set from the SSID parameter on the GENJCL.CLOSEcommand. If the SSID parameter is not specified, the default subsystem ID isused. The default subsystem ID is set by you in the INIT.RECON orCHANGE.RECON command. If no default subsystem ID is specified, thecommand fails.

%CDDNAME The ddname of the OLDS to be closed. This keyword is set from the OLDSparameter on the GENJCL.CLOSE command. If GENJCL.CLOSE did not specify anOLDS, the most recent open OLDS for the specified subsystem is used.

%OLDSTYP The type of OLDS, primary or secondary (set to P or S, respectively).

%OLDSDSN The data set name of the OLDS.

%WADS If the OLDS to be closed is currently open, this keyword is set to YES.Otherwise, this keyword is set to NO.

%NDDNAME The ddname of the 'next OLDS' to be used to close the OLDS. If %WADS is setto NO, this keyword is set to the ddname of the OLDS used immediately afterthe OLDS being closed. If %WADS is set to YES, this keyword is set to null.

%PDDNAME The ddname of the immediately prior OLDS to be used to close the OLDS byproviding a last block sequence number for base point information.

Symbolic Keywords


Database Image Copy Utility, Database Image Copy Utility 2, andOnline Database Image Copy Utility (ICJCL and OICJCL)

Table 17 explains the symbolic keywords recognized by the Database Image Copyutilities.

Table 17. Symbolic Keywords for Database Image Copy and Online Database Image CopyUtility

Keyword Description

%PSB The PSB name, which is set from the PSB parameter on the GENJCLcommand.This keyword is applicable only for the Database Online Image Copy utility.

%DBNAME The database name, which is set from the DBD parameter on the GENJCLcommand.

%DBDDN The DBDS ddname, which is set from the DDN parameter on the GENJCLcommand.

%DBDSN The DBDS data set name, which is set from the DBDS record in RECON.

%DBDSAM This keyword is set to VSAM for VSAM DBDS. Otherwise, it is set to null.

%DBADDN For DEDBs, the ddname of the ADS. Otherwise, set to null. This keyword isapplicable only for the Database Image Copy utility.

%DBADSAV For DEDBs, set to AVAIL if RECON indicates that the ADS is available, orUNAVAIL if the ADS is unavailable. For other types of databases, this keyword isset to null. This keyword is applicable only for the Database Image Copy utility.

%COPIES The number of image copy data sets to be produced. This keyword is set to 1 or2 from the COPIES parameter on the GENJCL command.

%MDBNAME The HALDB master name, if this is a DBDS of a HALDB partition. This keywordis set to NULL for non-HALDBs.

%SMS Indicates whether a Database Image Copy 2 (DFSUMDT0) image copy data setis being used for the requested utility execution. If used, the keyword is set to 1;otherwise, the keyword is set to 0.

%ICSYSIN The Database Image Copy utility control statement. Columns in the statement areset as follows:

Column Setting

1 D

2 Number of image copy data sets to be produced (either 1 or 2)

4-11 Database name

13-20 ddname of the DBDS

22-30 ddname of the primary image copy data set

31-38 ddname of the duplicate image copy data set, if one isproduced.

40-43 Checkpoint interval (applicable only for Online Database ImageCopy utility).

All other columns are set to blanks.

Symbolic Keywords


Table 17. Symbolic Keywords for Database Image Copy and Online Database Image CopyUtility (continued)

Keyword Description

%ICDSN1,%ICDSN2,%ICDSN3,%ICDSN4

The data set name of the image copy data set is %ICDSN1. If NOREUSE is specifiedfor the DBDS, DBRC generates the following data set name:

IMS.dbname.ddname.IC.IChhmmss

where:

v dbname is the database name of the DBDS

v ddname is the ddname of the DBDs

v hhmmss is the current time of day

If multiple image copy data sets are to be produced, %ICDSN3, or %ICDSN4 are setsimilarly.

%ICUNIT1,%ICUNIT2,%ICUNIT3,%ICUNIT4

The unit type of the image copy data set. If NOREUSE is specified for the DBDS,%ICUNIT1 is set from the UNIT parameter on the command. If multiple image copydata sets are to be produced, %ICUNIT2, %ICUNIT3, or %ICUNIT4 are set similarly.

%ICFSEQ1,%ICFSEQ2,%ICFSEQ3,%ICFSEQ4

The file sequence number of the image copy data set. If NOREUSE is specified forthe DBDS, %ICFSEQ1 is set to 1. If multiple image copy data sets are to beproduced, %ICFSEQ2, %ICFSEQ3, or %ICFSEQ4 are set similarly.

%ICVOLS1,%ICVOLS2,%ICVOLS3,%ICVOLS4

The volume serial number of the image copy data set. If NOREUSE is specified forthe DBDS, %ICVOLS1 is set from the VOLLIST parameter on the command. Ifmultiple image copy data sets are to be produced, %ICVOLS2, %ICVOLS3, or%ICVOLS4 are set similarly.

%ICVCNT1,%ICVCNT2,%ICVCNT3,%ICVCNT4

The number of volumes of the image copy data set. If NOREUSE is specified for theDBDS, %ICVCNT1 is set to the number of volumes specified on the VOLLISTparameter on the command. If multiple image copy data sets are to be produced,%ICVCNT2, %ICVCNT3, or %ICVCNT4 is set similarly.

Database Recovery Utility- Receive (ICRCVJCL)Table 18 explains the symbolic keywords recognized by the Database Recovery(Receive) utility.

Table 18. Symbolic Keywords for Database Recovery Utility

Keyword Description

%DBNAME The database name of the DBDS to be covered. %DBNAME is set from the DBDparameter on the GENJCL.RECEIVE command.

%DBDDN The ddname of the DBDS, %DBDDN is set from the DDN parameter on theGENJCL.RECEIVE command.

%DBDSN The data set name of the DBDS, %DBDSN is set from the DBDS record in RECON.

%DBDSAM Set to VSAM for a VSAM DBDS. Otherwise, set to null.

%DBUSID The update set identifier for the DBDS.

%ALLUSID The update set identifier of the most-recent ALLOC record for the DBDS.


%DSLLGTM The start time for selecting input log data. If an input change accumulation dataset is used, %DSLLGTM is set to the volume stop time of the last-accumulated logvolume. Otherwise, the keyword value is set to image copy time.

Symbolic Keywords


Table 18. Symbolic Keywords for Database Recovery Utility (continued)

Keyword Description

%ICDSN The data set name of the image copy data set. Set to null if the USEDBDSparameter is specified on the GENJCL.RECEIVE command. Otherwise set from theimage copy record for the DBDS.

%ICUNIT The unit type of the image copy data set. Set to null if the USEDBDS parameter isspecified on the GENJCL.RECEIVE command. Otherwise set from the image copyrecord for the DBDS.

%ICVOLS The volume serial number list of the image copy data set. Set to null if theUSEDBDS parameter is specified on the GENJCL.RECEIVE command. Otherwise setfrom the image copy record for the DBDS.

%ICFSEQ The file sequence number of the image copy data set. Set to null if the USEDBDSparameter is specified on the GENJCL.RECEIVE command. Otherwise set from theimage copy record for the DBDS.

%ICUSID The update set identifier for the image copy.

%CADSN The data set name of the change accumulation data set. Set to null if no changeaccumulation is available for the DBDS. Otherwise set from the changeaccumulation record.

%CAUNIT The unit type of the change accumulation data set. Set to null if no changeaccumulation is available for the DBDS. Otherwise set from the changeaccumulation record.

%CAVOLS The volume serial number list of the change accumulation data set. Set to null ifno change accumulation is available for the DBDS. Otherwise set from thechange accumulation record.

%CAFSEQ The file sequence number of the change accumulation data set. Set to null if nochange accumulation is available for the DBDS. Otherwise set from the changeaccumulation record.

%OLDFLRID The log record sequence number (log record ID) of the first log record in theOLDS.

%OLDLLRID The log record sequence number (log record ID) of the last log record in theOLDS. If the OLDS has not been closed, %OLDLLRID is set to null.

%SLDFLRID The log record sequence number (log record ID) of the first log record in theSLDS.

%SLDFSEQ The file sequence number of the SLDS.

%SLDLLRID The log record sequence number (log record ID) of the last log record in theSLDS. If the SLDS has not been closed, %SLDLLRID is set to null.

%SLDREMOT Set to YES if the SLDS data was created by an active IMS subsystem at atracking site. That is, the SLDS was received and written locally by the log router.%SLDREMOT is set to null if the SLDS was created locally by an active IMSsubsystem.

%SLDUNIT Set to null if the SLDS data was created by an active IMS subsystem at atracking site. SLDSs received from an active site are always cataloged.

%SLDVOLS Set to null if the SLDS data was created by an active IMS subsystem at atracking site. SLDSs received from an active site are always cataloged.


%LOGUNIT The unit type of the log data set. Set to null if the RLDS data was created by anactive IMS subsystem at a tracking site. RLDSs received from an active site arealways cataloged.


Symbolic Keywords



Keyword Description

%LOGVOLS The volume serial numbers of the log data set. Set to null if the RLDS data wascreated by an active IMS subsystem at a tracking site. RLDSs received from anactive site are always cataloged.


%LOGSEL Set to YES if any log data sets are selected by the select group; in this case, thedelete group following the select group is deleted. Otherwise, the %LOGSELkeyword is set to NO, and a DD DUMMY statement is generated.

%LOGFLRID The log record sequence number (log record ID) of the first log record in theRLDS.

%LOGLLRID The log record sequence number (log record ID) of the last log record in theRLDS. If the RLDS has not been closed, %LOGLLRID is set to null.

%LOGREMOT Set to YES if the RLDS data was created by an active IMS subsystem at atracking site. That is, the RLDS was received and written locally by the log router.%LOGREMOT is set to null if the RLDS was created locally by an active IMSsubsystem.

%RVSYSIN The Database Recovery utility control statement. Columns in the statement areset as follows:

Column Setting

1 S

4-11 Database name

13-20 Data set or area ddname

22-29 DFSUDUMPAll other columns are set to blanks.

Database Recovery Utility-Recover (RECOVJCL)Table 19 explains the symbolic keywords recognized by the Database Recovery(Recover) utility.

Table 19. Symbolic Keywords for Database Recovery Utility

Keyword Description

%DBNAME The database name of the DBDS to be RSR-covered. %DBNAME is set from the DBDparameter on the GENJCL.RECOV command.

%DBDDN The ddname of the DBDS; %DBDDN is set from the DDN parameter on theGENJCL.RECOV command.

%DBDSN The data set name of the DBDS; %DBDSN is set from the DBDS record of theDBDSs.

%DBDSAM Set to VSAM for a VSAM DBDS. Otherwise, set to null.


%DSLLGTM The start time for selecting input log data. If an input change accumulation dataset is used, %DSLLGTM is set to the volume stop time of the last-accumulated logvolume. Otherwise, the keyword value is set to image-copy time.

%SMS Indicates whether or not an Image Copy 2 image copy data set is being used forthe requested utility execution. Set to 1 if yes; otherwise, set to 0.

Symbolic Keywords



Keyword Description

%ICDSN The data set name of the image copy data set. Set to null if the USEDBDSparameter is specified on the GENJCL.RECOV command. Otherwise set from theimage copy record for the DBDS.

%ICUNIT The unit type of the image copy data set. Set to null if the USEDBDS parameter isspecified on the GENJCL.RECOV command. Otherwise set from the image copyrecord for the DBDS.

%ICVOLS The volume serial number list of the image copy data set. Set to null if theUSEDBDS parameter is specified on the GENJCL.RECOV command. Otherwise setfrom the image copy record for the DBDS.

%ICFSEQ The file sequence number of the image copy data set. Set to null if the USEDBDSparameter is specified on the GENJCL.RECOV command. Otherwise set from theimage copy record for the DBDS.

%CADSN The data set name of the change accumulation data set. Set to null if no changeaccumulation is available for the DBDS. Otherwise set from the changeaccumulation record.

%CAUNIT The unit type of the change accumulation data set. Set to null if no changeaccumulation is available for the DBDS. Otherwise set from the changeaccumulation record.

%CAVOLS The volume serial number list of the change accumulation data set. Set to null ifno change accumulation is available for the DBDS. Otherwise set from thechange accumulation record.

%CAFSEQ The file sequence number of the change accumulation data set. Set to null if nochange accumulation is available for the DBDS. Otherwise set from the changeaccumulation record.


%LOGUNIT The unit type of the log data set.


%LOGVOLS The volume serial numbers of the log data set.


%LOGSEL Set to YES if any log data sets are selected by the select group; in this case, thedelete group following the select group is deleted. Otherwise, the %LOGSELkeyword is set to NO, and a DD DUMMY statement is generated.

%RCSYSIN The Database Recovery utility control statement. Columns in the statement areset as follows:

Column Setting

1 S

4-11 Database name

13-20 Data set ddname

31-42 The specified time stamp if the RCVTIME parameter wasspecified on the GENJCL.RECOV command. Otherwise, blank.

44 C, if the USEDBDS parameter was specified on the GENJCL.RECOVcommand. Otherwise, blank.

All other columns are set to blanks.

%RCVFULL Indicates whether full recoveries are to be generated. When set to YES, fullrecoveries are generated. If the RCVTIME parameter was specified on theGENJCL.RECOV command, %RCVFULL is set to NO.

Symbolic Keywords


Understanding the IBM-Supplied Skeletal JCL Execution Members

This section lists and describes each of the skeletal JCL execution members thatare provided by IBM. This skeletal JCL generates executable JCL for running theapplicable utilities.

Related Reading: Instructions on what you must do before using the skeletal JCLexecution members are in “Using IBM-Supplied Skeletal JCL” on page 310.

The JOB StatementThe IBM-supplied skeletal JCL execution member for the JOB statement is namedJOBJCL. JOBJCL is invoked when any GENJCL command is issued.

JOBJCL consists of a single statement, as follows://JT%TIME JOB

You need to modify JOBJCL to add job accounting information that is required byyour installation. In addition, you can add JOBLIB, STEPLIB, and JES controlstatements to JOBJCL. The default job name can be modified. If you use thissupplied JOB statement, the job name is generated as JThhmmss, where hhmmss isthe time (hour, minute, second) it took for the GENJCL command to be executed.

Log Archive Utility JCL (ARCHJCL)The IBM-supplied skeletal JCL execution member for the Log Archive utility isnamed ARCHJCL. ARCHJCL is used when the GENJCL.ARCHIVE command is issued.

A description of the statements in ARCHJCL follows Figure 20 on page 341.

IBM-Supplied Skeletal JCL


Note: The following is the OLDS archive EXEC statement.%DELETE (%ARCSLDS EQ 'YES')//AR%STPNO EXEC PGM=DFSUARC0,PARM='%SSID'%ENDDELNote: The following is the SLDS archive EXEC statement.%DELETE (%ARCSLDS EQ 'NO')//AR%STPNO EXEC PGM=DFSUARC0,PARM='DBRC=Y'%ENDDEL//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/ESA DATABASE RECOVERY CONTROL FEATURE.//*//* JCL FOR ARCHIVE UTILITY//*//STEPLIB DD DSN=IMSVS.RESLIB,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDELNote: The following lines are used to archive OLDS.%DELETE (%ARCSLDS EQ 'YES')%SELECT OLDS(%SSID,(%ddnames))//%OLDSDDN DD DSN=%OLDSDSN,DISP=SHR%ENDSEL//DFSSLOGP DD DSN=IMS.SLDSP.%SSID.D%ARDATE.T%ARTIME.V%ARVERS,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,KEEP),LABEL=(1,SL)//DFSSLOGS DD DSN=IMS.SLDSS.%SSID.D%ARDATE.T%ARTIME.V%ARVERS,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,KEEP),LABEL=(1,SL)//RLDSDD1 DD DSN=IMS.RLDSP.%SSID.D%ARDATE.T%ARTIME.V%ARVERS,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,KEEP),LABEL=(1,SL)//RLDSDD2 DD DSN=IMS.RLDSS.%SSID.D%ARDATE.T%ARTIME.V%ARVERS,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,KEEP),LABEL=(1,SL)%ENDDEL

Figure 20. IBM-Supplied Skeletal JCL for the Log Archive Utility (Part 1 of 3)



Note: The following lines are used to archive primary SLDSs.%DELETE (%ARCSLDS EQ 'NO')%SELECT SLDS(%SSID,ALL)//DFSSLDSP DD DSN=%SLDSDSN,DISP=(OLD,PASS)%ENDSEL%ENDDEL%DELETE (%ARCSLDS EQ 'NO' | %SLDSSEL EQ 'NO')//DFSSLOGP DD DSN=IMSVS.ARCH1.%SSID.D%ARDATE.T%ARTIME,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,PASS),LABEL=(1,SL)//RLDSDD1 DD DSN=IMSVS.RLDS1.%SSID.D%ARDATE.T%ARTIME,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,PASS),LABEL=(1,SL)%ENDDELNote: The following lines are used to archive secondary SLDSs.%DELETE (%ARCSLDS EQ 'NO')%SELECT SSLDS(%SSID,ALL)//DFSSLDSS DD DSN=%SLDSDSN,DISP=(OLD,PASS)%ENDSEL%ENDDEL%DELETE (%ARCSLDS EQ 'NO' | %SLDSSEL EQ 'NO')//DFSSLOGS DD DSN=IMSVS.ARCH2.%SSID.D%ARDATE.T%ARTIME,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,PASS),LABEL=(1,SL)//RLDSDD2 DD DSN=IMSVS.RLDS2.%SSID.D%ARDATE.T%ARTIME,// UNIT=3400,VOL=(,,,99),// DISP=(NEW,PASS),LABEL=(1,SL)%ENDDELNote: The following lines are common to both processes.//SYSIN DD *SLDS FEOV(08000)COPY DDNOUT1(RLDSDD1) DDNOUT2(RLDSDD2) DBRECOV/*




You can modify this JCL to suit your needs. It is important to maintain the positionof the output DD statements (DFSSLOGP and RLDSDD1) or (DFSSLOGS andRLDSDD2) with respect to the correct %SELECT group. So, the DD statements for theprimary output data sets (DFSSLOGP and RLDSDD1) must follow the %SELECTSLDS(%SSID,ALL) select group and precede the %SELECT SSLDS(%SSID,ALL) selectgroup.

Restriction: The %ARVERS keyword is not supported for the SLDS archive processand must not be used.

EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1. The %SSID keyword is replaced with the ID ofthe IMS subsystem that created the OLDSs.

The DD Statements:

STEPLIB DD StatementDBRC makes no changes to this statement.

SYSPRINT DD StatementDBRC makes no changes to this statement.

RECONn DD StatementsThe RECON DD statements identify the RECONs.

Each of these statements is within a delete group that is controlled by a%RCNDSN keyword. The %RCNDSN keyword values are set from the RECON namesthat are used when the GENJCL command is executed.

Note: The following lines are used for the SLDSs process%DELETE (%ARCSLDS EQ 'NO')//****************************************************************//* *//* The following optional steps are used to manage the data *//* sets used in the previous SLDS archive step. If the previous *//* step completed successfully, the input data sets will be *//* deleted and the output data sets will be cataloged. The *//* output data sets will be deleted if the previous step *//* failed. *//* *//****************************************************************//GOODRC%STPNO EXEC PGM=IEFBR14,COND=(0,NE,AR%STPNO)%SELECT SLDS(%SSID,ALL)//PSLDS1 DD DSN=%SLDSDSN,DISP=(OLD,DELETE)%ENDSEL%SELECT SSLDS(%SSID,ALL)//SSLDS1 DD DSN=%SLDSDSN,DISP=(OLD,DELETE)%ENDSEL//DD1 DD DSN=*.AR%STPNO.DFSSLOGP,DISP=(OLD,CATLG)//DD2 DD DSN=*.AR%STPNO.DFSSLOGS,DISP=(OLD,CATLG)//DD3 DD DSN=*.AR%STPNO.RLDSDD1,DISP=(OLD,CATLG)//DD4 DD DSN=*.AR%STPNO.RLDSDD2,DISP=(OLD,CATLG)/*//BADRC%STPNO EXEC PGM=IEFBR14,COND=(0,EQ,AR%STPNO)//DD1 DD DSN=*.AR%STPNO.DFSSLOGP,DISP=(OLD,DELETE)//DD2 DD DSN=*.AR%STPNO.DFSSLOGS,DISP=(OLD,DELETE)//DD3 DD DSN=*.AR%STPNO.RLDSDD1,DISP=(OLD,DELETE)//DD4 DD DSN=*.AR%STPNO.RLDSDD2,DISP=(OLD,DELETE)/*%ENDDEL




v If RECONs are allocated dynamically, the %RCNDSN keywords are set to null,and the RECONn DD statements are deleted.

v If RECONs are allocated with JCL, the %RCNDSN keywords are set to thename of the corresponding RECON in the GENJCL command.

v If a RECON is not used when the GENJCL command is executed (for example,no spare RECON exists), the keyword is set to null, and the DD statement isdeleted.

OLDS DD StatementsThe DD statements for the OLDSs that are to be archived are generated with aselect group. The %SSID keyword identifies the subsystem ID. The %DDNAMESkeyword identifies the OLDSs. A DD statement is generated for each specifiedOLDS. The OLDS ddname replaces the %OLDSDDN keyword. The data set namereplaces the %OLDSDSN keyword.

DFSSLOGP DD StatementThis DD statement defines the primary SLDS to be created. The subsystem IDreplaces the %SSID keyword. The %ARDATE and %ARTIME keywords are replacedwith the date (yyddd) and time (hhmmsst) from the open time stamp of the oldestOLDS being archived. The %ARVERS keyword is replaced with the archive versionnumber (nn) of the oldest OLDS being archived.

DFSSLOGS DD StatementThis DD statement defines the secondary SLDS that is to be created. Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open time stampof the oldest OLDS that is being archived. The %ARVERS keyword is replacedwith the archive version number (nn) of the oldest OLDS that is being archived.

If you are not using dual SLDS logging, delete this DD statement from theskeletal JCL execution member.

RLDSDD1 DD StatementThis DD statement defines the primary RLDS that is to be created. Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open time stampof the oldest OLDS that is being archived. The %ARVERS keyword is replacedwith the archive version number (nn) of the oldest OLDS that is being archived.

If you are not using an RLDS, delete this statement and the RLDSDD2 DDstatement from the execution member. If this statement is deleted, the utilitycontrol COPY statement must be deleted from the SYSIN data. DBRC does notverify that the SYSIN data matches the DD statements.

RLDSDD2 DD StatementThis DD statement defines the secondary RLDS that is to be created. Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open time stampof the oldest OLDS that is being archived. The %ARVERS keyword is replacedwith the archive version number (nn) of the oldest OLDS being archived.

If you are not using RLDS logging, delete this statement from the executionmember. If this statement is deleted, the DDNOUT2(RLDSDD2) parameter must bedeleted from the utility control COPY statement in the SYSIN data. DBRC doesnot verify that the SYSIN data matches the DD statements.

SYSIN DD StatementDBRC makes no changes to the SYSIN DD statement or to the utility controlstatements in the SYSIN data.



DFSSLDSP DD StatementsThe DD statements for the primary SLDSs that are to be archived aregenerated with a select group. The %SSID keyword identifies the subsystem ID.A DD statement is generated for each unarchived SLDS. The SLDS data setname replaces the %SLDSDSN keyword.

DFSSLDSS DD StatementsThe DD statements for the secondary SLDSs that are to be archived aregenerated with a select group. The %SSID keyword identifies the subsystem ID.A DD statement is generated for each unarchived SLDS. The SLDS namereplaces the %SLDSDSN keyword.

DFSSLOGP DD StatementThis DD statement defines the primary SLDS that is to be created. Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open timestamp of the oldest OLDS or SLDS that is being archived. The %ARVERS keywordis replaced with the archive version number (nn) of the oldest OLDS beingarchived.

DFSSLOGS DD StatementThis DD statement defines the secondary SLDS that is to be created Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open timestamp of the oldest OLDS or SLDS that is being archived. The %ARVERS keywordis replaced with the archive version number (nn) of the oldest OLDS that isbeing archived.

If you are not using dual SLDS logging, delete these DD statements and theDD2 DD statements from the skeletal JCL execution member.

RLDSDD1 DD StatementThis DD statement defines the primary RLDS that is to be created. Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open timestamp of the oldest OLDS or SLDS being archived. The %ARVERS keyword isreplaced with the archive version number (nn) of the oldest OLDS beingarchived.

If you are not using an RLDS, delete these statements, the RLDSDD2 DDstatements, and the DD3 and DD4 DD statements from the execution member.If these statements are deleted, the utility control COPY statement must bedeleted from the SYSIN data. DBRC does not verify that the SYSIN datamatches the DD statements.

RLDSDD2 DD StatementThis DD statement defines the secondary RLDS that is to be created. Thesubsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywordsare replaced with the date (yyddd) and time (hhmmsst) from the open timestamp of the oldest OLDS or SLDS that is being archived. The %ARVERS keywordis replaced with the archive version number (nn) of the oldest OLDS that isbeing archived.

If you are not using dual logging, delete these statements and the DD4 DDstatements from the execution member. If these statements are deleted, theDDNOUT2(RLDSDD2) parameter must be deleted from the utility control COPYstatement in the SYSIN data. DBRC does not verify that the SYSIN datamatches the DD statements.



Database Change Accumulation Utility JCL (CAJCL)The IBM-supplied skeletal JCL execution member for the Database ChangeAccumulation utility is named CAJCL. CAJCL is used when the GENJCL.CAcommand is issued. You can specify an execution member other than CAJCL byusing the CAJCL parameter on the INIT.CAGRP or CHANGE.CAGRP commands.

A description of the statements in CAJCL follows Figure 21 on page 347.



EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1.

The DD Statements:

//CA%STPNO EXEC PGM=DFSUCUM0,PARM='CORE=100000',REGION=800K//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/ESA DATABASE RECOVERY CONTROL FEATURE.//*//* JCL FOR CHANGE ACCUMULATION//*//STEPLIB DD DSN=IMS.RESLIB,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSNl EQ '')//RECON1 DD DSN=%RCNDSNl,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL//IMS DD DSN=IMS.DBDLIB,DISP=SHR//SYSOUT DD SYSOUT=A//SORTLIB DD DSN=SYS1.SORTLIB,DISP=SHR//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(2),,CONTIG)//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(2),,CONTIG)//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(2),,CONTIG)//SORTWK04 DD UNIT=SYSDA,SPACE=(CYL,(2),,CONTIG)//SORTWK05 DD UNIT=SYSDA,SPACE=(CYL,(2),,CONTIG)//SORTWK06 DD UNIT=SYSDA,SPACE=(CYL,(2),,CONTIG)%DELETE (%CAODSN EQ '')//DFSUCUMO DD DSN=%CAODSN,UNIT=%CAOUNIT,// VOL=(PRIVATE,,,,SER=(%CAOVOLS)),// LABEL=(%CAOFSEQ,SL),// DISP=OLD%ENDDEL%DELETE (%CAODSN NE '')//DFSUCUMO DD DUMMY,DCB=BLKSIZE=100%ENDDEL//DFSUCUMN DD DSN=%CANDSN,UNIT=%CANUNIT,// VOL=(PRIVATE,,,%CANVCNT,SER=(%CANVOLS)),// LABEL=(%CANFSEQ,SL),// DISP=(NEW,KEEP)%SELECT RLDS((%CAGRP),(FROM(%DSLLGTM)))//DFSULOG DD DSN=%LOGDSN,UNIT=%LOGUNIT,// VOL=(PRIVATE,,%LOGVSEQ,,SER=(%LOGVOLS)),// LABEL=(%logfseq,SL),// DCB=RECFM=VB,// DISP=OLD%ENDSEL%DELETE (%LOGSEL EQ 'YES')//DFSULOG DD DUMMY,DCB=BLKSIZE=100%ENDDEL//DFSUDD1 DD DUMMY//SYSIN DD *%CADB0/*

Figure 21. IBM-Supplied Skeletal JCL for the Database Change Accumulation Utility










IMS DD StatementDBRC makes no changes to this statement.

SYSOUT DD StatementDBRC makes no changes to this statement.

SORTLIB DD StatementDBRC makes no changes to this statement.

SORTWKn DD StatementsDBRC makes no changes to these statements.

DFSUCUMO DD StatementThis statement identifies a previously created change accumulation data setthat is used as input.

Two delete groups are used to generate this DD statement. If no existingchange accumulation data set is defined in RECON for the CA group, the valueof the %CAODSN keyword is null. Thus, the first delete group is deleted, and theDFSUCUMO DD statement is generated as DUMMY,DCB=BLKSIZE=100.

If an input change accumulation data set is defined in RECON, the %CAODSNkeyword is set to the data set name. Thus, the second delete group is deleted,and the DFSUCUMO DD statement identifies the input data set. Other keywordsrelating to the output data set are replaced as follows:

%CAODSN Data set name

%CAOUNIT Unit type

%CAOVOLS Volume serial number list

%CAOFSEQ File sequence number

DFSUCUMN DD StatementThis DD statement identifies the output change accumulation data set. Otherkeywords relating to the output data set are replaced as follows:

%CANDSN Data set name

%CANUNIT Unit type

%CANVCNT Volume count

%CANVOLS Volume serial numbers



%CANFSEQ File sequence number

DFSULOG DD StatementThis DD statement identifies the IMS log data sets that are to be used as inputto the Database Change Accumulation utility. A select group selects the requiredlog data sets. %CAGRP identifies the CA group for which log data sets are to beselected. All log volumes that are not previously processed for the CA group areselected. Other keywords for the selected data sets are replaced as follows:

%LOGDSN Data set name

%LOGUNIT Unit type

%LOGVSEQ Volume sequence number

%LOGVOLS Volume serial numbers

%LOGFSEQ File sequence numbers

If any log data sets are selected by the select group, the value of the %LOGSELkeyword in the next delete group is YES; this causes the delete group to bedeleted. Otherwise, the %LOGSEL keyword is set to NO, and a DD DUMMY statementis generated.

DFSUDD1 DD StatementDBRC makes no changes to this statement.

The DFSUDD1 DD statement identifies the optional output log data set that isproduced by the Database Change Accumulation utility. DBRC does not recordthe optional output log data set; therefore, the skeletal JCL execution memberspecifies the DFSUDD1 DD statement as DUMMY.

SYSIN DD StatementDBRC makes no changes to this statement.

DB0 Control StatementsA DB0 control statement is generated for each DBDS in the CA group. Eachgenerated DB0 control statement has:

columns 1-3 DB0

columns 4-11 The database name

columns 12-20 The image-copy time stamp (in the formyydddhhmm)

columns 21-28 The database ddname

Log Recovery Utility JCL (LOGCLJCL)The IBM-supplied skeletal JCL execution member for the Log Recovery utility isnamed LOGCLJCL. LOGCLJCL is used when the GENJCL.CLOSE command isissued.

A description of the statements in LOGCLJCL follows Figure 22 on page 350.



EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1. The %SSID keyword is replaced with the ID ofthe IMS subsystem that created the OLDS that is to be closed.







//CL%STPNO EXEC PGM=DFSULTR0,PARM='IMSID=%SSID'//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/ESA DATABASE RECOVERY CONTROL FEATURE.//*//* JCL FOR LOG RECOVERY UTILITY//*//STEPLIB DD DSN=IMS.RESLIB,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSNl EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL%SELECT OLDS(%SSID,(%CDDNAME))//DFSOL%OLDSTYP DD DSN=%OLDSDSN,DISP=SHR%ENDSEL%DELETE (%WADS EQ 'NO')//DFSWADS0 DD DSN=IMS.WADS0,DISP=OLD%ENDDEL%DELETE (%WADS EQ 'YES')%SELECT OLDS(%SSID,(%NDDNAME))//DFSNOL%OLDSTYP DD DSN=%OLDSDSN,DISP=SHR%ENDSEL%ENDDEL%DELETE (%PDDNAME EQ '')%SELECT OLDS(%SSID, (%PDDNAME))//DFSPOL%OLDSTYP DD DSN=%OLDSDSN,DISP=SHR%ENDSEL%ENDDEL//SYSIN DD *CLS/*

Figure 22. IBM-Supplied Skeletal JCL for the Log Recovery Utility




OLDS DD StatementThis DD statement identifies the OLDS that is to be closed. A select group isused to select the OLDS. The %SSID keyword identifies the subsystem ID, andthe %CDDNAME identifies the OLDS by its DD name. The OLDS type, primary orsecondary, replaces the %OLDSTYP keyword. The resulting ddname is DFSOLP orDFSOLS. The %OLDSDSN keyword is replaced with the data set name of the OLDS.

WADS DD StatementThis statement is provided only as a model. You must change it before usingthe skeletal JCL execution member.

The supplied DFSWADS0 DD statement must be replaced with DD statementsDFSWADS0 through DFSWADSn. n+1 is the number of WADSs that the online IMScontrol region uses. The WADS DD statements are contained in a select groupthat is controlled by the keyword %WADS. The GENJCL.CLOSE command processorsets the value of the %WADS keyword to YES if the OLDS is to be closed using theWADS. The command processor sets the value to NO if the OLDS is to beclosed using the next OLDS. The WADS DD statements are, therefore, deleted ifthe OLDS is to be closed using the next OLDS.

Next OLDS DD StatementsIf the OLDS is to be closed using the next OLDS, these DD statements identifythe next OLDSs. These statements are contained in a delete group that iscontrolled by the %WADS keyword. Thus, if the OLDS is to be closed using theWADS, these statements are deleted. A select group is used in order to selectthe next OLDSs. The %SSID keyword identifies the subsystem ID. The %NDDNAMEkeyword identifies the next OLDS by ddname. The OLDS type, primary orsecondary, replaces the %OLDSTYP keyword. The resulting ddname is DFSNOLP orDFSNOLS. The %OLDSDSN keyword is replaced with the data set name of theOLDS.

Prior OLDS DD StatementsIf an immediately prior OLDS exists, the corresponding DD statement identifiesthe immediately prior OLDS. These statements are contained in a delete groupthat is controlled by the %PDDNAME keyword. If its value is not null, a select groupis used in order to select the immediately prior OLDS. The resulting ddname isDFSPOLP or DFSPOLS. Processing of the other keywords is as described underNext OLDS DD Statements, above.

SYSIN DD StatementDBRC makes no changes to the SYSIN DD statement or to the utility controlstatements in the SYSIN data.

Database Image Copy Utility JCL (ICJCL)The IBM-supplied skeletal JCL execution member for the Database Image Copyand Database Image Copy 2 utility is named ICJCL.

ICJCL is used when the GENJCL.IC command is issued. You can specify anexecution member other than ICJCL by using the ICJCL parameter on the INIT.DBDSor CHANGE.DBDS commands.

A description of the statements in ICJCL follows Figure 23 on page 352.



//IC%STPNO EXEC PGM=%PGMIC,REGION=800K,// PARM='%PARMX'//*//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/ESA DATA BASE RECOVERY CONTROL FEATURE.//*//* JCL FOR IMAGE COPY.//*//STEPLIB DD DSN=IMSVS.RESLIB,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL//IMS DD DSN=IMSVS.DBDLIB,DISP=SHR%SELECT DBDS((%DBNAME,%DBDDN))%DELETE (%DBADSAV NE 'AVAIL')//%DBADDN DD DSN=%DBDSN,DISP=%CICDISP%ENDDEL%DELETE (%DBADSAV NE '')//%DBDDN DD DSN=%DBDSN,DISP=%CICDISP%ENDDEL%ENDSEL//DATAOUT1 DD DSN=%ICDSN1,UNIT=%ICUNIT1,// VOL=(PRIVATE,,,%ICVCNT1,SER=(%ICVOLS1)),// LABEL=(%ICFSEQ1,SL),%DELETE (%SMS EQ '1')// DISP=(NEW,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%SMS NE '1')// DISP=(NEW,KEEP)%ENDDEL

Figure 23. IBM-Supplied Skeletal JCL for the Database Image Copy Utility (Part 1 of 2)



EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1.







%DELETE (%COPIES EQ '1' | %SMS EQ '1')//DATAOUT2 DD DSN=%ICDSN2,UNIT=%ICUNIT2,// VOL=(PRIVATE,,,%ICVCNT2,SER=(%ICVOLS2)),// LABEL=(%ICFSEQ2,SL),// DISP=(NEW,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%COPIES EQ '1' | %SMS NE '1')//DATAOUT2 DD DSN=%ICDSN2,UNIT=%ICUNIT2,// VOL=(PRIVATE,,,%ICVCNT2,SER=(%ICVOLS2)),// LABEL=(%ICFSEQ2,SL),// DISP=(NEW,KEEP)%ENDDEL%DELETE (%COPIES LE '2' | %SMS EQ '1')//DATAOUT3 DD DSN=%ICDSN3,UNIT=%ICUNIT3,// VOL=(PRIVATE,,,%ICVCNT3,SER=(%ICVOLS3)),// LABEL=(%ICFSEQ3,SL),// DISP=(NEW,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%COPIES LE '2' | %SMS NE '1')//DATAOUT3 DD DSN=%ICDSN3,UNIT=%ICUNIT3,// VOL=(PRIVATE,,,%ICVCNT3,SER=(%ICVOLS3)),// LABEL=(%ICFSEQ3,SL),// DISP=(NEW,KEEP)%ENDDEL%DELETE (%COPIES LE '3' | %SMS EQ '1')//DATAOUT4 DD DSN=%ICDSN4,UNIT=%ICUNIT4,// VOL=(PRIVATE,,,%ICVCNT4,SER=(%ICVOLS4)),// LABEL=(%ICFSEQ4,SL),// DISP=(NEW,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%COPIES LE '3' | %SMS NE '1')//DATAOUT4 DD DSN=%ICDSN4,UNIT=%ICUNIT4,// VOL=(PRIVATE,,,%ICVCNT4,SER=(%ICVOLS4)),// LABEL=(%ICFSEQ4,SL),// DISP=(NEW,KEEP)%ENDDEL//SYSIN DD *%ICSYSIN/*

Figure 23. IBM-Supplied Skeletal JCL for the Database Image Copy Utility (Part 2 of 2)





%DBADDN DD StatementThis statement identifies the available ADS that is to be used. The %DBADDNkeyword is replaced with the ddname of the ADS. The %DBDSN keyword isreplaced with the ADS name.

%DBDNN DD StatementThis statement identifies the DBDS that is to be copied. The %DBDDN keyword isreplaced with the ddname of the DBDS. The %DBDSN keyword is replaced by thedata set name of the DBDS.

DATAOUT1 DD StatementThis statement identifies the first image copy data set that is produced by anImage Copy utility. Other keywords relating to the image copy data set arereplaced as follows:

%ICDSN1 Data set name

%ICVCNT1 Volume count

%ICVOLS1 Volume serial number list

%ICUNIT1 Unit type

%ICFSEQ1 File sequence number

DATAOUT2 | 3 | 4 DD StatementThese statement identifies the subsequent images that are produced by theImage Copy utility. This DD statement is within a delete group that is controlledby the %COPIES keyword. The %COPIES keyword is set to 1 if a single image copydata set is to be produced or to a 2, 3, or 4 if multiple image copy data setsare to be produced. If %COPIES is 1, the group is deleted.

The %ICDSNx, %ICVCNTx, %ICVOLSx, %ICUNITx, and %ICFSEQx keywords arereplaced with the same type of information as is shown under the %DATAOUT1 DDstatement just preceding. x can be either 2, 3 or 4.


%ICSYSIN StatementThe Image Copy utility control statement replaces the %ICSYSIN keyword.

The %ICSYSIN statement is required. If the %ICSYSIN statement is deleted, theGENJCL.IC command fails.

Online Database Image Copy Utility JCL (OICJCL)The IBM-supplied skeletal JCL execution member for the Online Image Copy utilityis named OICJCL. OICJCL is used when the GENJCL.OIC command is issued. Youcan specify an execution member other than OICJCL by using the OICJCLparameter on the INIT.DBDS or CHANGE.DBDS commands.

A description of the statements in OICJCL follows Figure 24 on page 355.



EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1. The PSB name that is specified on theGENJCL.OIC command replaces the %PSB keyword.








//OIC%STPNO EXEC PGM=DFSRRC00,PARM='BMP,DFSUICP0,%PSB,,MASTER',// REGION=700K//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/ESA DATABASE RECOVERY CONTROL FEATURE.//*//* JCL FOR ONLINE IMAGE COPY//*//STEPLIB DD DSN=IMS.RESLIB,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL//IMS DD DSN=IMS.DBDLIB,DISP=SHR//DATAOUT1 DD DSN=%ICDSN1,UNIT=%ICUNIT1,// VOL=(PRIVATE,,,%ICVCNT1,SER=(%ICVOLS1)),// LABEL=(%ICFSEQ1,SL),// DISP=(NEW,KEEP)%DELETE (%COPIES, EQ '1')//DATAOUT2 DD DSN=%ICDSN2,UNIT=%ICUNIT2,// VOL=(PRIVATE,,,%ICVCNT2,SER=(%ICVOLS2)),// LABEL=(%ICFSEQ2,SL),// DISP=(NEW,KEEP)%ENDDEL//DFSUCKPT DD DSN=IMS.%DBNAME.%DBDDN.CHECKPT.IC%time,// UNIT=SYSDA,SPACE=(TRK,1),DISP=(NEW,CATLG)//SYSIN DD *%ICSYSIN/*

Figure 24. IBM-Supplied Skeletal JCL for the Online Database Image Copy Utility




DATAOUT1 DD StatementThis statement identifies the first image copy data set that is produced by theImage Copy utility. Other keywords relating to the online image copy data setare replaced as follows:

%ICDSN1 Data set name

%ICVCNT1 Volume count

%ICVOLS1 Volume serial number list

%ICUNIT1 Unit type

%ICFSEQ1 File sequence number

DATAOUT2 DD StatementThis statement identifies the duplicate image copy data set that produced by theImage Copy utility. This DD statement is within a delete group controlled by the%COPIES keyword. The %COPIES keyword is set to 1 if a single image copy dataset is to be produced or to 2 if duplicate image copy data sets are to beproduced. If %COPIES is 1, the group is deleted.

The %ICDSN2, %ICVCNT2, %ICVOLS2, %ICUNIT2, and %ICFSEQ1 keywords arereplaced with the same type of information as is shown under the %DATAOUT1 DDstatement just preceding.

DFSUCKPT DD StatementThe DFSUCKPT DD statement identifies the optional online image copy checkpointdata set. Keywords relating to this optional data set are replaced as follows:

%DBNAME Database name

%DBDDN ddname

%TIME Current time of day (in the form hhmmss)

The volume serial number and device type for the checkpoint data set are notspecified in the IBM-supplied skeletal JCL. You must supply these if checkpointdata sets are to be used.

The DFSUCKPT DD statement is optional. If checkpoint data sets are not to beused by the Online Image Copy utility, the statement can be deleted.


%ICSYSIN StatementThe Image Copy utility control statement replaces the %ICSYSIN keyword.

Database Recovery Utility JCL-Image Copy Receive-Tracking Site(ICRCVJCL)The IBM-supplied skeletal JCL execution member for the Database Recovery utility(as used at the tracking site to receive the image copy) is named ICRCVJCL.ICRCVJCL is used when the GENJCL.RECEIVE command is issued. You can specifyan execution member other than ICRCVJCL by using the RECVJCL parameter on theINIT.DBDS or CHANGE.DBDS commands.

A description of the statements in ICRCVJCL follows Figure 25 on page 357.



EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1. The %DBNAME keyword is replaced with thedatabase name of the DBDS or area that is being received.

The DD Statements:



//RCV%STPNO EXEC PGM=DFSRRC00,REGION=1300K,// PARM='UDR,DFSURDB0,%DBNAME',,,,,,,,,,,,,,,,,,,,,%GSGNAME'//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/VS DATA BASE RECOVERY CONTROL FEATURE.//*//* JCL FOR IMAGE COPY RECEIVE//*//STEPLIB DD DSN=IMSVS.RESLIB,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL//IMS DD DSN=IMSVS.DBDLIB,DISP=SHR//%DBDDN DD DSN=%DBDSN,%DELETE (%DBDSAM EQ 'VSAM')// UNIT=SYSDA,// VOL=SER=VOLSER,// SPACE=(CYL,(20,2)),// DISP=(NEW,KEEP),// DCB=BUFNO=10%ENDDEL%DELETE (%DBDSAM NE 'VSAM')// DISP=OLD%ENDDEL//DFSUDUMP DD DSN=%ICDSN,UNIT=%ICUNIT,// VOL=(PRIVATE,,,,SER=(%ICVOLS)),// LABEL=(%ICFSEQ,SL),// DISP=(OLD,KEEP),DCB=BUFNO=10%DELETE (%LOGSEL EQ 'YES')//DFSULOG DD DUMMY%ENDDEL%DELETE (%CADSN NE '')//DFSUCUM DD DUMMY%ENDDEL//DFSVSAMP DD *1024,44096,4//SYSIN DD *%RVSYSIN/*

Figure 25. IBM-Supplied Skeletal JCL for the Database Recovery Utility









%DBDDN DD StatementThe %DBDDN keyword is replaced by the ddname of the DBDS that is beingreceived. The %DBDSN keyword is replaced by the data set name of the DBDS orarea.

Delete groups control the remainder of the %DBDDN DD statement. The accessmethod of the DBDS controls the content of the delete groups. If the accessmethod is VSAM, DISP=OLD is generated. Otherwise, the UNIT, VOL, SPACE, DISP,and DCB parameters are generated.

DFSUDUMP DD StatementThis DD statement identifies the image copy data set that is to be received. The%ICDSN, %ICUNIT, %ICVOLS, and %ICFSEQ keywords are set from the appropriatefields in the image copy RECON record.

DFSUCUM DD StatementThis DD statement is always listed as DUMMY at the tracking site.

DFSULOG DD StatementThis DD statement is always listed as DUMMY at the tracking site.

DFSVSAMP DD StatementThe DFSVSAMP DD statement identifies information that is required by the DL/Ibuffer handler. DBRC makes no changes to these statements.

SYSIN DD StatementThis DD statement contains database recovery statements that control theprocessing.

%RVSYSIN StatementDBRC replaces the %RVSYSIN keyword.

Database Recovery Utility JCL (RECOVJCL)The IBM-supplied skeletal JCL execution member for the Database Recovery utilityis named RECOVJCL. RECOVJCL is used when the GENJCL.RECOV command isissued. You can specify an execution member other than RECOVJCL by using theRECOVJCL parameter on the INIT.DBDS or CHANGE.DBDS commands.

A description of the statements in RECOVJCL follows:



%DELETE (%MDBNAME NE ’’)//RCV%STPNO EXEC PGM=DFSRRC00,REGION=1300K,// PARM='UDR,DFSURDB0,%DBNAME,,,,,,,,,,,,,,,,,,,%GSGNAME'%ENDDEL%DELETE (%MDBNAME EQ ’’)//RCV%STPNO EXEC PGM=DFSRRC00,REGION=1300K,// PARM=’UDR,DFSURDB0,%MDBNAME,,,,,,,,,,,,,,,,,,%GSGNAME’%ENDDEL//*//*//* THIS JCL ORIGINIATES FROM THE USER’S ’JCLPDS’ LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION OF//* THE IMS/VS DATA BASE RECOVERY CONTROL FEATURE.//*//* JCL FOR RECOVERY.//*//STEPLIB DD DSN=IMSVS.SDFSRESL,DISP=SHR//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL//IMS DD DSN=IMSVS.DBDLIB,DISP=SHR//%DBDDN DD DSN=%DBDSN,%DELETE (%DBDSAM EQ 'VSAM' | %SMS EQ '1')// UNIT=SYSDA,// VOL=SER=VOLSER,// SPACE=(CYL,(20,2)),// DISP=(NEW,KEEP),// DCB=BUFNO=10%ENDDEL%DELETE (%DBDSAM EQ 'VSAM' | %SMS EQ '0')// UNIT=SYSDA,// VOL=SER=VOLSER,// SPACE=(CYL,(20,2)),// DISP=(NEW,KEEP)%ENDDEL%DELETE (%DBDSAM NE 'VSAM')// DISP=OLD%ENDDEL%DELETE (%ICDSN EQ '')//DFSUDUMP DD DSN=%ICDSN,%ENDDEL

Figure 26. IBM-Supplied Skeletal JCL for the Database Recovery Utility (Part 1 of 3)



%DELETE (%ICCAT EQ ’YES’)// UNIT=%ICUNIT,// VOL=(PRIVATE,,,,SER=(%ICVOLS)),// LABEL=(%ICFSEQ,SL),%ENDDEL%DELETE (%ICDSN EQ ’’ | %SMS EQ ’1’)// DISP=(OLD,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%ICDSN EQ ’’ | %SMS EQ ’0’// DISP=(OLD,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (ICDSN EQ ’’ | %SMS EQ ’0’)// DISP=(OLD,KEEP)%ENDDEL%DELETE (%AICDSN NE ’’)//DFSUDUMP DD DUMMY%ENDDEL//DFSVDUMP DD DUMMY%DELETE (%CADSN EQ ’’)//DFSUCUM DD DSN=%CADSN,UNIT=%CAUNIT,// VOL=(PRIVATE,,,,SER=(%CAVOLS)),// LABEL=(%CAFSEQ,SL),// DISP=(OLD,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%CADSN NE ’’)//DFSUCUM DD DUMMY%ENDDEL%SELECT RLDS((%DBNAME,%DBDDN),FROM(%DSLLGTM))%DELETE (%LOGVOLS EQ ’’)//DFSULOG DD DSN=%LOGDSN,UNIT=%LOGUNIT,// VOL=(PRIVATE,,%LOGVSEQ,,SER=(%LOGVOLS)),// LABEL=(%LOGFSEQ,SL),// DCB=RECFM=VB,// DISP=OLD%ENDDEL%DELETE (%LOGVOLS NE ’’)//DFSULOG DD DSN=%LOGDSN,DISP=OLD%ENDDEL%ENDSEL%DELETE (%LOGSEL EQ ’YES’)//DFSULOG DD DUMMY%ENDDEL%DELETE (%TRACK EQ ’NO’)//DFSTRCV DD DSN=??????,// DISP=OLD%ENDDEL//DFSVSAMP DD *1024,44096,4//SYSIN DD *%RCSYSIN/*%DELETE (%ICCAT EQ 'YES')// UNIT=%ICUNIT,// VOL=(PRIVATE,,,,SER=(%ICVOLS)),// LABEL=(%ICFSEQ,SL),%ENDDEL%DELETE (%ICDSN EQ '' | %SMS EQ '1')// DISP=(OLD,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%ICDSN EQ '' | %SMS EQ '0')// DISP=(OLD,KEEP)%ENDDEL%DELETE (%ICDSN NE '')




EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1. For HALDB, the HALDB master name,%MDBNAME, of the DBDs being recovered is used in the EXEC statement. For allothers, the database name, %DBNAME, is used.

The DD Statements:






//DFSUDUMP DD DUMMY%ENDDEL//DFSVDUMP DD DUMMY%DELETE (%CADSN EQ '')//DFSUCUM DD DSN=%CADSN,UNIT=%CAUNIT,// VOL=(PRIVATE,,,,SER=(%CAVOLS)),// LABEL=(%CAFSEQ,SL),// DISP=(OLD,KEEP),DCB=BUFNO=10%ENDDEL%DELETE (%CADSN NE '')//DFSUCUM DD DUMMY%ENDDEL%SELECT RLDS((%DBNAME,%DBDDN),FROM(%DSLLGTM))%DELETE (%LOGVOLS EQ '')//DFSULOG DD DSN=%LOGDSN,UNIT=%LOGUNIT,// VOL=(PRIVATE,,%LOGVSEQ,,SER=(%LOGVOLS)),// LABEL=(%LOGFSEQ,SL),// DCB=RECFM=VB,// DISP=OLD%ENDDEL%DELETE (%LOGVOLS NE '')//DFSULOG DD DSN=%LOGDSN,DISP=OLD%ENDDEL%ENDSEL%DELETE (%LOGSEL EQ 'YES')//DFSULOG DD DUMMY%ENDDEL%DELETE (%TRACK EQ 'NO')//DFSTRCV DD DSN=??????,// DISP=OLD%ENDDEL//DFSVSAMP DD *1024,44096,4//SYSIN DD *%RCSYSIN/*







%DBDDN DD StatementThe %DBDDN keyword is replaced by the ddname of the DBDS that is beingrecovered. The %DBDSN keyword is replaced by the data set name of the DBDS.

Delete groups control the remainder of the %DBDDN DD statement. The accessmethod of the DBDS controls the content of the delete groups. If the accessmethod is VSAM, DISP=OLD is generated. Otherwise, the UNIT, VOL, SPACE, DISP,and DCB parameters are generated.

DFSUDUMP DD StatementThis DD statement identifies the image copy data set, if any, that is to be usedfor recovery. Delete groups, which are controlled by the %ICDSN keyword, areused to generate this DD statement.

If the USEIC parameter was specified or if it was the default, on theGENJCL.RECOV command, the %ICDSN keyword is set to its data set name. Thus,the first delete group for DFSUDUMP is used, and the second delete group isdeleted. Other keywords within the first delete group are unchanged.

If the USEDBDS or USEAREA keyword was specified on the GENJCL.RECOVcommand, the DFSUDUMP DD statement is generated as DUMMY.

DFSVDUMP DD StatementThe DFSVDUMP DD statement is always generated as DUMMY.

DFSUCUM DD StatementThis DD statement identifies the change accumulation data set, if any, to beused as input to recovery. Delete groups, which are controlled by the %CADSNkeyword, are used to generate the DFSUCUM DD statement. If the DBDS belongsto a CA group, the %CADSN keyword is set to the data set name of themost-recent change accumulation data set. If the DBDS does not belong to aCA group or if no usable change accumulation data set exists, the %CADSNkeyword is set to null.

v If the %CADSN keyword is null, the DFSUCUM DD statement is generated asDUMMY.

v If the %CADSN keyword is not null, the DFSUCUM DD statement identifies thechange accumulation data set.

Other keywords relating to the change accumulation data set are replaced asfollows:

%CAVOLS Volume serial number list

%CAUNIT Unit type

%CAFSEQ File sequence number

DFSULOG DD StatementThis DD statement identifies the log data sets that are to be used as input tothe Database Recovery utility.

A select group selects the required log data sets. The %DBNAME and %DBDDNkeywords identify the DBDS for which log data sets are to be selected. All log



volumes that contain change records for the DBDS, that are not included in thechange accumulation data sets, are selected. Other keywords relating to the logdata sets are replaced as follows:

%LOGDSN Log data set name

%LOGUNIT Unit type

%LOGVSEQ Volume sequence number

%LOGVOLS Volume serial numbers

%LOGFSEQ File sequence number

If any log data sets are selected, the value of the %LOGSEL keyword is YES, andthe following delete group is deleted. Otherwise, the %LOGSEL keyword is NO, anda DD DUMMY statement is generated.

DFSTRCV DD StatementThe DFSTRCV DD statement identifies the DBDS for which one or more tracks isbeing recovered. If the TRACK parameter was not specified on the GENJCLcommand, this statement does not appear in the generated JCL.

You must modify the DFSTRCV DD statement to include in it the appropriate dataset name and unit information. You can modify it in either the skeletal JCL orgenerated JCL.

DFSVSAMP DD StatementThe DFSVSAMP DD statement identifies information required by the DL/I bufferhandler. DBRC makes no changes to these statements.


%RCSYSIN StatementDBRC replaces the %RCSYSIN keyword.

%RCVFULLThe %RCVFULL keyword indicates what type of recovery is being generated. It isset to NO when the RCVTIME parameter (timestamp recovery) is specified on theGENJCL.RECOV command. It is set to YES to indicate full recoveries.

This keyword is useful if, for example, you want to turn ON the IC-NEEDED flagin the DBDS record following a time stamp recovery. You could add thefollowing JCL to the end of your RECOVJCL skeletal JCL member toaccomplish this.

%DELETE (%RCVFULL EQ 'YES')//RCV%STPNO EXEC PGM=DSPURX00//STEPLIB DD DSN=IMS.RESLIB,DISP=SHR%ENDDEL%DELETE (%RCVFULL EQ 'YES' | %RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCVFULL EQ 'YES' | %RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCVFULL EQ 'YES' | %RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL%DELETE (%RCVFULL EQ 'YES')//SYSIN DD *



CHANGE.DBDS DBD(%DBNAME) DDN(%DBDDN) ICON/*%ENDDEL

Sample JCL for HALDB INDEX/ILDS Rebuild Utility (DSPUPJCL)DFSPREC0 is used to rebuild the ILDS and/or prime index datasets of a HALDBpartition.

The DB Recovery utility and the image copy utilities cannot be used on ILDS andprime index datasets. The GENJCL commands RECOV, RECEIVE, IC, and OIC failwhen attempted specifically for one of them. GENJCL commands on groups, eitherexplicit (using the GROUP keyword) or implicit (DBD with no DDN keyword), do notgenerate any JCL for ILDS or prime index datasets. They are skipped over.GENJCL.USER can specify ILDS and prime index datasets. They are not skippedover for this command.

After the timestamp recovery of a HALDB partition (i.e., the data DBDSs of theHALDB partition), the applicable ILDS and/or prime index datasets must be rebuilt.There is no specific GENJCL support for these datasets, but GENJCL.USER can beused. The IBM-supplied skeletal JCL execution member is named DSPUPJCL.Here is a suggestion for implementation:GENJCL.USER MEMBER (DSPUPJCL) -

USERKEYS ((%MDBNAME, 'DBHDOJ01'),(%DBDNAME,'PART1'), -(%RCVTYP, 'ILE')

A description of the statements in DSPUPJCL follows Figure 27 on page 365.



EXEC StatementThe %STPNO keyword is replaced with the current step number; then the currentstep number is increased by 1. The %MDBNAME keyword is replaced with theHALDB master name of the DBDS that is being recovered.

The DD Statements:







//UPREC%STPNO EXEC PGM=DFSRRC00,REGION=1300K,// PARM='ULU,DFSPREC0,%MDBNAME,,,,,,,,,,,,,,,,,,,Y,N'//*//***************************************************************************************//**//* Licensed Materials - Property of IBM*//**//* "Restricted Materials of IBM"*//**//* 5655-158 (C) Copyright IBM Corp. 1974,1999//**//***************************************************************************************//*//* THIS JCL ORIGINATES FROM THE USER'S 'JCLPDS' LIBRARY.//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION.//*//* User JCL for rebuilding the Index and/or ILDS data//* sets for a Partition of a HALDB.//*//SYSPRINT DD SYSOUT=A%DELETE (%RCNDSN1 EQ '')//RECON1 DD DSN=%RCNDSN1,DISP=SHR%ENDDEL%DELETE (%RCNDSN2 EQ '')//RECON2 DD DSN=%RCNDSN2,DISP=SHR%ENDDEL%DELETE (%RCNDSN3 EQ '')//RECON3 DD DSN=%RCNDSN3,DISP=SHR%ENDDEL//IMS DD DSN=IMS.DBDLIB,DISP=SHR//DFSVSAMP DD DSN=IMS.VSAM.PARM(OPTIONS),DISP=SHR//SYSIN DD *PARTITION=%DBNAME,RECOVTYP=%RCVTYP/*

Figure 27. IBM-Supplied Skeletal JCL for the HALDB Index/ILDS Rebuild Utility




DFSVSAMP DD StatementThe DFSVSAMP DD statement identifies information required by the DL/I bufferhandler. DBRC makes no changes to these statements.


PARTITION=%DBNAMEThis statement indicates the HALDB partition name of the ILDS or prime indexdata sets being rebuilt. For a description of the %DBNAME keyword values, seethe IMS Version 7 Utilities Reference: Database and Transaction Manager.

RECOVTYP=%RCVTYPThis statement indicates which type of data sets (ILDS or prime index) arebeing rebuilt. For a description of the %RCVTYP keyword values, see the IMSVersion 7 Utilities Reference: Database and Transaction Manager.



Appendix C. Sample Listings of RECONs

The following listings show the format and content of various records of RECONsas they were listed by LIST.RECON commands.

In This Appendix:

v “Sample Listing of a RECON at the Active Site” on page 373

v “Sample Listing of a RECON at the Tracking Site” on page 401

v “Fields Present in a Listing of a RECON by Record Type” on page 416

Figure 29 on page 374 begins a listing of a RECON from an active site in an RSRenvironment. Figure 38 on page 401 is a listing of a RECON from a tracking site inan RSR environment.

The LIST command causes the RECON to be read.

The sample listings illustrate:

v These records: PRILOG, PRISLD, PRIOLD, LOGALL, GSG, SSYS, andBACKOUT

v DBDS group records including DBDSs, CAGRPs and DEDB areas

v DB records showing various share levels and authorization states

v DBDS records, including area data sets that support DEDB areas

v Information corresponding to the database activity regarding:

– image copy data set information

– change accumulation information

– reorganization information

– recovery information

– and depending upon database activity:

- ALLOC records

- IMAGE records

- CA records

- REORG records

- nd RECOV records

To find the DSECTS defining the formats of the RECON records in DBRC inADFSMAC and SDFSMAC, run the generate job with SDFSMAC=ALL. The membernames are:

DSPALLRC ALLOC record

DSPBKORC BACKOUT record

DSPCAGRC CAGRP record

DSPCHGRC CA record

DSPDBHRC DB record

DSPDGRC DBDSGRP record

DSPGSGRC Global Service Group record

DSPDSHRC DBDS record

DSPIMGRC IC record


DSPLGARC LOGALL record

DSPLOGRC PRILOG / SECLOG record

DSPOLDRC PRIOLD / SECOLD record

DSPTHTRC THT record

DSPRCR1 HEADEREXT record

DSPRCNRC HEADER record

DSPRCVRC RECOV record

DSPRRGRC REORG record

DSPSLDRC PRISLD / SECSLD / PRITSLDS / SECTSLDS record

DSPSSRC SUBSYS record

Sample Listing of LIST.HISTORY OutputYou use the LIST.HISTORY command to produce a history of activity for DBDSs orDEDB areas. You can produce a RECON listing using LIST.HISTORY from either anactive or a remote site. Figure 28 on page 369 is an example of LIST.HISTORYoutput that includes a time line.

Sample RECON Listing Active Site


IMS/ESA VERSION 7 RELEASE 1 DATA BASE RECOVERY CONTROL PAGE 0001LIST.HISTORY DBD(DEDBDD01) AREA(DD01AR0)

99.365 16:22:58.7 LISTING OF RECON PAGE 0002-------------------------------------------------------------------------------DBDBD=DEDBDD01 DMB#=2 TYPE=FPSHARE LEVEL=3FLAGS: COUNTERS:

RECOVERY NEEDED COUNT =0IMAGE COPY NEEDED COUNT =0

PROHIBIT AUTHORIZATION=OFF AUTHORIZED AREAS =0RECOVERABLE =YES EEQE COUNT =0

--------------------------------------------------------------------------------------------------------------------------------------------------------------DBDSDBD=DEDBDD01 AREA=DD01AR0 TYPE=FPSHARE LEVEL=3 DSID=001 DBORG=DEDB DSORG=VSAMGSGNAME=**NULL** USID=0000000004AUTHORIZED USID=0000000004 RECEIVE USID=0000000004 HARD USID=0000000004RECEIVE NEEDED USID=0000000000CAGRP=CAGRP1 GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000003NOREUSE RECOVPD=0 NOVSO NOPREOPEN NOPRELOADCFSTR1=**NULL** CFSTR2=**NULL** NOLKASIDDEFLTJCL=**NULL** ICJCL=ICJCL RECVJCL=ICRCVJCL RECOVJCL=RECOVJCLFLAGS: COUNTERS:

PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =0HELD AUTHORIZATION STATE=0

IC NEEDED =OFF ADS AVAIL # =1RECOV NEEDED =OFF REGISTERED ADS # =1

EEQE COUNT =0RECEIVE NEEDED =OFFOFR REQUIRED =NOTRACKING SUSPENDED =NOHSSP CIC IN PROGRESS =NO

ADS LIST:CREATE

-ADS DDN--ADS DSN- -STAT- -RUNNING-DD01AR0 DD01AR0 AVAIL NO

--------------------------------------------------------------------------------------------------------------------------------------------------------------IMAGERUN = 99.365 15:49:12.0 * RECORD COUNT =84STOP = 00.000 00:00:00.0 BATCH USID=0000000002

IC1DSN=IMSVS.DEDBDD01.DD01AR0.IC.IC154909 FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

ALLOCALLOC =99.365 15:50:15.3 * ALLOC LRID =0000000000000000DSSN=0000000002 USID=0000000003 START = 99.365 15:41:20.4DEALLOC =99.365 16:14:59.9 DEALLOC LRID =0000000000000000

Figure 28. Sample LIST.HISTORY Output (Part 1 of 5)

LIST.HISTORY Sample

Appendix C. Sample Listings of RECONs 369

99.365 16:22:58.7 LISTING OF RECON PAGE 0003

ALLOCALLOC =99.365 15:50:15.8 * ALLOC LRID =0000000000000000DSSN=0000000002 USID=0000000003 START = 99.365 15:44:10.4DEALLOC =99.365 16:15:00.4 DEALLOC LRID =0000000000000000

CADSN=IMSVS.CAGRP1.CA.CA001301 FILE SEQ=1CAGRP=CAGRP1 STOP = 99.365 16:12:44.9 *

UNIT=SYSDA VOLS DEF=1 VOLS USED=1VOLSER=222222

RUN = 99.365 16:13:34.7 SUBSETDBD=DEDBDD01 DDN=DD01AR0 PURGETIME = 99.365 15:49:12.0

CHANGES ACCUMULATED=YES COMPLETE CA=NO INDOUBT EEQES=NOLSN = 000000000000 DSSN = 0000000002LRID = 0000000000001596 USID = 0000000000

CADSN=IMSVS.CAGRP1.CA.CA001501 FILE SEQ=1CAGRP=CAGRP1 STOP = 99.365 16:15:02.0 *


RUN = 99.365 16:15:29.1DBD=DEDBDD01 DDN=DD01AR0 PURGETIME = 99.365 15:49:12.0

CHANGES ACCUMULATED=YES COMPLETE CA=YES INDOUBT EEQES=NOLSN = B3611B99C9C4 DSSN = 0000000002LRID = 000000000000162B USID = 0000000003

RECOVRUN = 99.365 16:16:31.6 * RUN USID = 0000000003

ALLOCALLOC =99.365 16:17:29.9 * ALLOC LRID =0000000000000000DSSN=0000000003 USID=0000000004 START = 99.365 15:41:20.4


DSP0181I NO REORG RECORD FOUND


LIST.HISTORY Sample


99.365 16:22:58.7 LISTING OF RECON PAGE 0004-------------------------------------------------------------------------------PRILOGSTART = 99.365 15:41:20.4 * SSID=SYS3 VERSION=7.1STOP = 99.365 16:22:02.3 #DSN=3GSGNAME=**NULL**FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0EARLIEST CHECKPOINT = 99.365 15:41:22.6

DSN=IMSVS.RLDSP.SYS3.D99365.T1541204.V00 UNIT=SYSDASTART = 99.365 15:41:20.4 FIRST DS LSN= 0000000000000001STOP = 99.365 16:12:44.9 LAST DS LSN= 000000000000178AFILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.RLDSP.SYS3.D99365.T1612449.V00 UNIT=SYSDASTART = 99.365 16:12:44.9 FIRST DS LSN= 000000000000178BSTOP = 99.365 16:15:00.8 LAST DS LSN= 0000000000001826FILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.RLDSP.SYS3.D99365.T1615008.V00 UNIT=SYSDASTART = 99.365 16:15:00.8 FIRST DS LSN= 0000000000001827STOP = 99.365 16:22:02.3 LAST DS LSN= 0000000000002749FILE SEQ=0001 #VOLUMES=0001



LIST.HISTORY Sample


-------------------------------------------------------------------------------99.365 16:22:58.7 LISTING OF RECON PAGE 0005-------------------------------------------------------------------------------PRILOGSTART = 99.365 15:44:10.4 * SSID=IMS2 VERSION=7.1STOP = 99.365 16:22:11.2 #DSN=4GSGNAME=**NULL**FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0EARLIEST CHECKPOINT = 99.365 15:44:13.4

DSN=IMSVS.RLDSP.IMS2.D99365.T1544104.V00 UNIT=SYSDASTART = 99.365 15:44:10.4 FIRST DS LSN= 0000000000000001STOP = 99.365 16:13:13.5 LAST DS LSN= 0000000000001612FILE SEQ=0001 #VOLUMES=0001






DSN=IMSVS.RLDSP.IMS2.D99365.T1615020.V01 UNIT=SYSDASTART = 99.365 16:15:02.0 FIRST DS LSN= 0000000000001662STOP = 99.365 16:22:11.2 LAST DS LSN= 000000000000252BFILE SEQ=0001 #VOLUMES=0001



LIST.HISTORY Sample


Related Reading: See “LIST.HISTORY” on page 252 for more information aboutthe LIST.HISTORY command.

Sample Listing of a RECON at the Active SiteBeginning with Figure 29 on page 374, the following figures comprise a listing of aRECON from an active site in an RSR environment. “Fields Present in a Listing of aRECON by Record Type” on page 416 describes the fields that can be present in alisting of the RECON.

-------------------------------------------------------------------------------99.365 16:22:58.7 LISTING OF RECON PAGE 0006+------------------------------------------------------------------------------+|Timeline for AREA: DEDBDD01 DD01AR0 Ref || USID=00000000 AUTHORIZED=00000000 Page|| RECEIVE=00000000 HARD=00000000 0002|+-Time------------+Events----+---+--+------------------------------------------+| |IC | | | || |REORG | |US|Subsystem || |RECOV |CA |ID|Logs and Allocs |+-----------------+----------+---+--+------------------------------------------+99.365 15:41:20.4 SYS3 000499.365 15:44:10.4 | IMS2 000599.365 15:49:12.0 B < 2 | | 000299.365 15:50:15.3 | 3 A | 000299.365 15:50:15.8 | | | A 000299.365 16:12:44.9 S | s |99.365 16:13:13.5 | | | s99.365 16:13:34.7 Ryi | | | 000399.365 16:14:59.9 | | D |99.365 16:15:00.4 | 3 | D99.365 16:15:00.6 | s99.365 16:15:00.8 s |99.365 16:15:02.0 S | s99.365 16:15:29.1 Ryc | | 000399.365 16:16:31.6 R | | 000399.365 16:17:29.9 4 A | 000399.365 16:18:25.4 | | A 000399.365 16:22:02.3 | C |99.365 16:22:11.2 4 C+-----------------+----------+---+--+------------------------------------------+In the timeline, only the last digit of USID is shown.

IC: B = Batch, U = UIC, O = OIC, C = CIC, s = StopRECOV: R = Run time, * = RECOVTO time (if any)

CA: R = Run time, S = Stop time, < = Purge timey/n = CHANGES ACCUMULATED, i/c = (IN)/COMPLETE

Logs: SSID = Open time, C = Log Close,v = Vol close, s = DS close

Allocs: D = Dealloc time, A = Alloc time+------------------------------------------------------------------------------+DSP0180I NUMBER OF RECORDS LISTED IS 12DSP0203I COMMAND COMPLETED WITH CONDITION CODE 00DSP0220I COMMAND COMPLETION TIME 99.365 16:22:59.5


LIST.HISTORY Sample


RECON Status Record

IMS/ESA VERSION 7 RELEASE 1 DATA BASE RECOVERY CONTROL/* LIST IN LOCAL TIME */LIST.RECON TIMEFMT(L,O,P,4)1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------RECONRECOVERY CONTROL DATA SET, IMS/ESA V7R1DMB#=9 INIT TOKEN=99251F1858079FNOFORCER LOG DSN CHECK=CHECK17 STARTNEW=NOTAPE UNIT=3400 DASD UNIT=SYSDA TRACEOFF SSID=**NULL**LIST DLOG=YES CA/IC/LOG DATA SETS CATALOGED=NOLOG RETENTION PERIOD=00.000 00:15:00.0SIZALERT DSNUM=15 VOLNUM=16 PERCENT= 95LOGALERT DSNUM=3 VOLNUM=16

TIME STAMP INFORMATION:

TIMEZIN = %SYS -LABEL- -OFFSET-PDT -07:00PST -08:00

OUTPUT FORMAT: DEFAULT = LOCORG NONE PUNC YYCURRENT = LOCAL OFFSET PUNC YYYY

-DDNAME- -STATUS- -DATA SET NAME-RECON1 COPY1 IMSTESTL.IMS.RECON1RECON2 COPY2 IMSTESTL.IMS.RECON2RECON3 SPARE IMSTESTL.IMS.RECON3

Figure 29. Sample Listing of a RECON at the Active Site - RECON Status



Log Records

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:16:52.6 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:35:06.5 -08:00 #DSN=4GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 2EARLIEST CHECKPOINT = 1999.251 11:18:46.7 -08:00

DSN=**** COMPRESSED DATA SET **** UNIT=START = 1999.251 11:16:52.6 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:17:52.9 -08:00 LAST DS LSN= 00000000000002DEFILE SEQ=0000 #VOLUMES=0000

DSN=IMSVS.RLDSP.SYS3.D99251.T1217529.V01 UNIT=SYSDASTART = 1999.251 11:17:52.9 -08:00 FIRST DS LSN= 00000000000002DFSTOP = 1999.251 11:18:30.3 -08:00 LAST DS LSN= 0000000000000493FILE SEQ=0001 #VOLUMES=0001

VOLSER=000000 STOPTIME = 1999.251 11:18:30.3 -08:00CKPTCT=1 CHKPT ID = 1999.251 11:17:53.1 -08:00LOCK SEQUENCE#= 000000000000

DSN=IMSVS.RLDSP.SYS3.D99251.T1218303.V00 UNIT=SYSDASTART = 1999.251 11:18:30.3 -08:00 FIRST DS LSN= 0000000000000494STOP = 1999.251 11:18:52.8 -08:00 LAST DS LSN= 0000000000000596FILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.RLDSP.SYS3.D99251.T1218528.V01 UNIT=SYSDASTART = 1999.251 11:18:52.8 -08:00 FIRST DS LSN= 0000000000000597STOP = 1999.251 11:35:06.5 -08:00 LAST DS LSN= 000000000000078BFILE SEQ=0001 #VOLUMES=0001


LOGALLSTART = 1999.251 11:16:52.6 -08:00 *DBDS ALLOC=1 -DBD- -DDN- -ALLOC-

DBVHDJ05 CJVHDG1E 1

Figure 30. Sample Listing of a RECON at the Active Site - Log Records (Part 1 of 8)



1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0336-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:16:52.6 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:35:06.5 -08:00 #DSN=4GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 2

DSN=**** COMPRESSED DATA SET **** UNIT=START = 1999.251 11:16:52.6 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:17:52.9 -08:00 LAST DS LSN= 00000000000002DEFILE SEQ=0000 #VOLUMES=0000

DSN=IMSVS.SLDSP.SYS3.D99251.T1217529.V01 UNIT=SYSDASTART = 1999.251 11:17:52.9 -08:00 FIRST DS LSN= 00000000000002DFSTOP = 1999.251 11:18:30.3 -08:00 LAST DS LSN= 0000000000000493FILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.SLDSP.SYS3.D99251.T1218303.V00 UNIT=SYSDASTART = 1999.251 11:18:30.3 -08:00 FIRST DS LSN= 0000000000000494STOP = 1999.251 11:18:52.8 -08:00 LAST DS LSN= 0000000000000596FILE SEQ=0001 #VOLUMES=0001


DSN=IMSVS.SLDSP.SYS3.D99251.T1218528.V01 UNIT=SYSDASTART = 1999.251 11:18:52.8 -08:00 FIRST DS LSN= 0000000000000597STOP = 1999.251 11:35:06.5 -08:00 LAST DS LSN= 000000000000078BFILE SEQ=0001 #VOLUMES=0001





1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0337-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:35:37.8 -08:00 * SSID=BATCH1 VERSION=7.1STOP = 1999.251 11:35:40.2 -08:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 3

DSN=BATCH1.UPDATEF.LOG UNIT=SYSDASTART = 1999.251 11:35:37.8 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:35:40.2 -08:00 LAST DS LSN= 000000000000009CFILE SEQ=0001 #VOLUMES=0001

VOLSER=000000 STOPTIME = 1999.251 11:35:40.2 -08:00CKPTCT=0 CHKPT ID = 0000.000 00:00:00.0 +00:00LOCK SEQUENCE#= 000000000000


DHVNTZ02 HIDAM 1DXVNTZ02 XDLBT04I 1DIVNTZ02 DBHVSAM1 1

1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0338-------------------------------------------------------------------------------SECLOGSTART = 1999.251 11:35:37.8 -08:00 * SSID=BATCH1 VERSION=7.1STOP = 1999.251 11:35:40.2 -08:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 3

DSN=IMSTESTL.IMS01.OLDSP1 UNIT=SYSDASTART = 1999.251 11:35:37.8 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:35:40.2 -08:00 LAST DS LSN= 000000000000009CFILE SEQ=0001 #VOLUMES=0001

VOLSER=USER03 STOPTIME = 1999.251 11:35:40.2 -08:00CKPTCT=0 CHKPT ID = 0000.000 00:00:00.0 +00:00LOCK SEQUENCE#= 000000000000




1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0339-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:35:59.2 -08:00 * SSID=BATFPC VERSION=7.1STOP = 1999.251 11:36:08.0 -08:00 #DSN=1GSGNAME=**NULL**FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0

DSN=IMSTESTM.BAT01.DBLOG1 UNIT=SYSDASTART = 1999.251 11:35:59.2 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:36:08.0 -08:00 LAST DS LSN= 00000000000000E2FILE SEQ=0001 #VOLUMES=0001



DBOVLFPC VLOSAM01 11999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0340-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:36:24.5 -08:00 * SSID=BATFPC VERSION=7.1STOP = 1999.251 11:36:25.8 -08:00 #DSN=1GSGNAME=**NULL** BBOFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0

DSN=IMSTESTM.BBOFPC.BB1 UNIT=SYSDASTART = 1999.251 11:36:24.5 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:36:25.8 -08:00 LAST DS LSN= 000000000000002EFILE SEQ=0001 #VOLUMES=0001



DBOVLFPC VLOSAM01 1




1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0341-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:37:33.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:40:49.9 -08:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 4EARLIEST CHECKPOINT = 1999.251 11:18:46.7 -08:00




DEDBDD01 DD01AR0 1DHVNTZ02 HIDAM 1DXVNTZ02 XDLBT04I 1DIVNTZ02 DBHVSAM1 1DBOHIDK5 CKOHIG1O 1DXVHIDK5 CKVHIIXK 1DBVHDJ05 CJVHDG1E 1

1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0342-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:37:33.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:40:49.9 -08:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 4






1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0343-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:40:50.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 0000.000 00:00:00.0 +00:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000221 PRILOG TOKEN= 5EARLIEST CHECKPOINT = 1999.251 11:40:54.1 -08:00




DEDBDD01 DD01AR0 11999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0344-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:40:50.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 0000.000 00:00:00.0 +00:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000221 PRILOG TOKEN= 5






1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0345-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:44:49.0 -08:00 * SSID=IMS2 VERSION=7.1STOP = 1999.251 11:45:29.9 -08:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 6EARLIEST CHECKPOINT = 1999.251 11:44:57.8 -08:00

DSN=IMSVS.RLDSP.IMS2.D99251.T1144490.V00 UNIT=SYSDASTART = 1999.251 11:44:49.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:45:29.9 -08:00 LAST DS LSN= 00000000000001BBFILE SEQ=0001 #VOLUMES=0001


LOGALLSTART = 1999.251 11:44:49.0 -08:00 *DBDS ALLOC=0

1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0346-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:44:49.0 -08:00 * SSID=IMS2 VERSION=7.1STOP = 1999.251 11:45:29.9 -08:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 6

DSN=IMSVS.SLDSP.IMS2.D99251.T1144490.V00 UNIT=SYSDASTART = 1999.251 11:44:49.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:45:29.9 -08:00 LAST DS LSN= 00000000000001BBFILE SEQ=0001 #VOLUMES=0001


1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0347-------------------------------------------------------------------------------PRIOLDSSID=IMS2 # DD ENTRIES=1EARLIEST CHECKPOINT = 1999.251 11:44:57.8 -08:00

DDNAME=DFSOLP00 DSN=IMSTESTL.IMS02.OLDSP0START = 1999.251 11:44:49.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:45:29.9 -08:00 LAST DS LSN= 00000000000001BBLOCK SEQUENCE# = 000000000000STATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=1999.251 11:44:49.0 -08:00 ARCHIVE JOB NAME=JT114530VERSION=7.1




GSG Record

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------PRIOLDSSID=SYS3 # DD ENTRIES=4EARLIEST CHECKPOINT = 1999.251 11:40:54.1 -08:00

DDNAME=DFSOLP03 DSN=IMSTESTL.IMS01.OLDSP3START = 1999.251 11:18:52.8 -08:00 FIRST DS LSN= 0000000000000597STOP = 1999.251 11:35:05.7 -08:00 LAST DS LSN= 0000000000000735LOCK SEQUENCE# = 000000000000STATUS=ARC COMPLT FEOV=NO AVAILPRILOG TIME=1999.251 11:16:52.6 -08:00 ARCHIVE JOB NAME=JT114050VERSION=7.1



DDNAME=DFSOLP00 DSN=IMSTESTL.IMS01.OLDSP0START = 1999.251 11:43:11.5 -08:00 FIRST DS LSN= 000000000000039ASTOP = 0000.000 00:00:00.0 +00:00 LAST DS LSN= 0000000000000000LOCK SEQUENCE# = 000000000000STATUS=ACTIVE FEOV=NO AVAILPRILOG TIME=1999.251 11:40:50.0 -08:00VERSION=7.1

DSP0260I NO INTERIM RLDS/SLDS RECORDS FOUND IN RECONDSP0260I NO INT-ONLINE LOG RECORDS FOUND IN RECON


1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------GSGGSGNAME=IMSGSG1 #SGS=2 -SGNAME- -ROLE-

STLSITE1 ACTIVE LOCALSTLSITE2 TRACKING

CURRENT PRILOG TOKEN = 6 TAKEOVER TOKEN = 0MINIMUM PRILOG TOKEN = 1 DSN SEQ NUMBER = 0START TIME OF CURRENT LOG = 1999.251 11:44:49.0 -08:00HIGHEST ACTIVE SITE TIME = 0000.000 00:00:00.0 +00:00TRACKING SUBSYSTEM ID = **NULL**TAKEOVER IN PROGRESS

Figure 31. Sample Listing of a RECON at the Active Site - GSG Record



SSYS Record

BACKOUT Record

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------SSYSSSID=SYS3 LOG START=1999.251 11:40:50.0 -08:00SSTYPE=ONLINE ABNORMAL TERM=OFF RECOVERY STARTED=NO BACKUP=NOTRACKED=NO TRACKER TERM=OFF SHARING COVERED DBS=NOIRLMID=**NULL** IRLM STATUS=NORMAL GSGNAME=IMSGSG1

AUTHORIZED DATA BASES/AREAS=1 VERSION=7.1ENCODED

-DBD- -AREA- -LEVEL- -ACCESS INTENT- -STATE-DEDBDD01 DD01AR0 1 UPDATE 6

Figure 32. Sample Listing of a RECON at the Active Site - SSYS Record

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------BACKOUTSSID=SYS3 #UORS=2

RECOVERY TOKEN=E2E8E2F3404040400000000300000002TIME=1999.251 11:38:22.5 -08:00 PSB=PLVAPZ12

INFLT BMP COLDENDASSOCIATED DATA BASES=3

BACKED DYN BKOUT-DBD- -OUT - -FAILURE-DHVNTZ02 NO NODXVNTZ02 NO NODIVNTZ02 NO NO

RECOVERY TOKEN=E2E8E2F3404040400000000400000000TIME=1999.251 11:38:22.8 -08:00 PSB=PSBEJK05

INFLT BMP COLDENDASSOCIATED DATA BASES=2

BACKED DYN BKOUT-DBD- -OUT - -FAILURE-DBOHIDK5 NO NODXVHIDK5 NO NO

Figure 33. Sample Listing of a RECON at the Active Site - BACKOUT Record



CAGRP and CA Records

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------CAGRPGRPNAME=CAGRP1 GRPMAX=3 CA AVAIL=0 CA USED=1NOREUSE CAJCL=CAJCL DEFLTJCL=**NULL**

#MEMBERS=4 -DBD- -DDN-DEDBJN21 DB21AR1DEDBJN21 DB21AR3DEDBJN21 DB21AR6DEDBJN21 DB21AR7

-------------------------------------------------------------------------------

CADSN=IMSVS.CAGRP1.CA.CA194501 FILE SEQ=1CAGRP=CAGRP1 STOP = 1999.251 11:10:59.7 -08:00 *


RUN = 1999.251 11:45:45.0 -08:00DBD=DEDBJN21 DDN=DB21AR1 PURGETIME = 1999.251 11:08:45.9 -08:00

CHANGES ACCUMULATED=YES COMPLETE CA=YES INDOUBT EEQES=NOLSN = 000000000000 DSSN = 0000000001LRID = 0000000000000424 USID = 0000000002

DBD=DEDBJN21 DDN=DB21AR3 PURGETIME = 1999.251 11:08:47.9 -08:00CHANGES ACCUMULATED=YES COMPLETE CA=YES INDOUBT EEQES=NOLSN = 000000000000 DSSN = 0000000001LRID = 000000000000043A USID = 0000000002

DBD=DEDBJN21 DDN=DB21AR6 PURGETIME = 1999.251 11:02:53.0 -08:00CHANGES ACCUMULATED=NO COMPLETE CA=YES INDOUBT EEQES=NOLSN = 000000000000 DSSN = 0000000000LRID = 0000000000000000 USID = 0000000000


Figure 34. Sample Listing of a RECON at the Active Site - CAGRP and CA Records



DBGRP, DBDSGRP, and RECOVGRP Records

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBGRPGRPNAME=DBGRP1 #MEMBERS=6 -DBD/AREA-

DIVNTZ02DHVNTZ02DXVNTZ02DB21AR0DB21AR1DB21AR2

DBDSGRPGRPNAME=FJKGRP #MEMBERS=5 -DBD- -DDN/AREA-

DIVNTZ02 DBHVSAM1DIVNTZ02 DBHVSAM2DHVNTZ02 HIDAMDHVNTZ02 HIDAM2DXVNTZ02 XDLBT04I

RECOVGRPGRPNAME=RCVGRP1 #MEMBERS=5 -DBD- -AREA-

DIVNTZ02DHVNTZ02DXVNTZ02DEDBJN21 DB21AR0DEDBJN21 DB21AR1

Figure 35. Sample Listing of a RECON at the Active Site - DBGRP, DBDSGRP, andRECOVGRP Records



DB (IMS) and Related Records

1999.251 11:46:24.1 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDBD=DBVHDJ05 IRLMID=*NULL DMB#=2 TYPE=IMSSHARE LEVEL=3 GSGNAME=**NULL** USID=0000000006AUTHORIZED USID=0000000006 RECEIVE USID=0000000006 HARD USID=0000000006RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**FLAGS: COUNTERS:

BACKOUT NEEDED =OFF RECOVERY NEEDED COUNT =0READ ONLY =OFF IMAGE COPY NEEDED COUNT =0PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =0RECOVERABLE =YES HELD AUTHORIZATION STATE=0

EEQE COUNT =0TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0OFR REQUIRED =NO

DBDSDSN=DBVHDJ05.CJXXD01E TYPE=IMSDBD=DBVHDJ05 DDN=CJVHDG1E DSID=001 DBORG=HDAM DSORG=VSAMCAGRP=CAGRP2 GENMAX=2 IC AVAIL=0 IC USED=2 DSSN=00000005NOREUSE RECOVPD=0DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCLRECVJCL=ICRCVJCLFLAGS: COUNTERS:

IC NEEDED =OFFRECOV NEEDED =OFFRECEIVE NEEDED =OFF EEQE COUNT =0

-------------------------------------------------------------------------------

ALLOCALLOC =1999.251 11:18:26.4 -08:00 * ALLOC LRID =0000000000000000DSSN=0000000004 USID=0000000005 START = 1999.251 11:16:52.6 -08:00DEALLOC =1999.251 11:18:52.6 -08:00 DEALLOC LRID =0000000000000000

ALLOCALLOC =1999.251 11:39:00.8 -08:00 * ALLOC LRID =0000000000000000DSSN=0000000005 USID=0000000006 START = 1999.251 11:37:33.0 -08:00

IMAGERUN = 1999.251 11:18:13.1 -08:00 * RECORD COUNT =33STOP = 0000.000 00:00:00.0 +00:00 BATCH USID=0000000004

Figure 36. Sample Listing of a RECON at the Active Site - DB (IMS) and Related Records(Part 1 of 2)



IC1DSN=IMSVS.DBVHDJ05.CJVHDG1E.IC.IC121810 FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

IMAGERUN = 1999.251 11:19:26.0 -08:00 * RECORD COUNT =33STOP = 1999.251 11:19:26.6 -08:00 CONCUR USID=0000000005

IC1DSN=IMSVS.DBVHDJ05.CJVHDG1E.IC.IC121920 FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

Figure 36. Sample Listing of a RECON at the Active Site - DB (IMS) and Related Records(Part 2 of 2)



DB (HALDB and PART) and Related Records

00.168 18:15:28.7 LISTING OF RECON PAGE 0002-------------------------------------------------------------------------------DBDBD=DBHDOK01 DMB#=1 CHANGE#=6 TYPE=HALDBSHARE LEVEL=0 GSGNAME=**NULL**PSNAME=**NULL**FLAGS: COUNTERS:

RECOVERABLE =YES PARTITIONS =4-------------------------------------------------------------------------------00.168 18:15:28.7 LISTING OF RECON PAGE 0003-------------------------------------------------------------------------------DBDBD=PDHDOKA MASTER DB=DBHDOK01 CHANGE#=6 TYPE=PARTUSID=0000000004 AUTHORIZED USID=0000000004 HARD USID=0000000004RECEIVE USID=0000000004 RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**

RANDOMIZER:NAME=DFSHDC20 ANCHOR=3 HIGH BLOCK#=3 BYTES=25

FREE SPACE:FREE BLOCK FREQ FACTOR=0 FREE SPACE PERCENTAGE=0

PARTITION HIGH KEY/STRING (CHAR): (LENGTH=5 )K0200

PARTITION HIGH KEY/STRING (HEX):D2F0F2F0F0404040404040404040404040404040404040404040404040404040

OSAM BLOCK SIZE:A = 2048B = 2048C = 4096D = 4096

FLAGS: COUNTERS:BACKOUT NEEDED =OFF RECOVERY NEEDED COUNT =0READ ONLY =OFF IMAGE COPY NEEDED COUNT =0PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =0

HELD AUTHORIZATION STATE=0EEQE COUNT =0

TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0OFR REQUIRED =NOPARTITION INIT NEEDED =NO

-------------------------------------------------------------------------------00.168 18:15:28.7 LISTING OF RECON PAGE 0004-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.A00001 TYPE=PARTDBD=PDHDOKA DDN=PDHDOKAA DSID=001 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=3 IC AVAIL=0 IC USED=1 DSSN=00000003NOREUSE RECOVPD=3DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------




IMAGERUN = 00.168 09:28:53.4 * RECORD COUNT =3STOP = 00.000 00:00:00.0 BATCH USID=0000000003

IC1DSN=IMSVS.PDHDOKA.PDHDOKAA.IC.IC092846 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0005-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.B00001 TYPE=PARTDBD=PDHDOKA DDN=PDHDOKAB DSID=004 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=4 IC AVAIL=0 IC USED=1 DSSN=00000003NOREUSE RECOVPD=4DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------



IC1DSN=IMSVS.PDHDOKA.PDHDOKAB.IC.IC092847 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0006-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.C00001 TYPE=PARTDBD=PDHDOKA DDN=PDHDOKAC DSID=005 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000001NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------




IC1DSN=IMSVS.PDHDOKA.PDHDOKAC.IC.IC092847 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0007-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.D00001 TYPE=PARTDBD=PDHDOKA DDN=PDHDOKAD DSID=006 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000001NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSVS.PDHDOKA.PDHDOKAD.IC.IC092847 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0008-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.L00001 TYPE=PARTDBD=PDHDOKA DDN=PDHDOKAL DSID=003 DBORG=INDEX DSORG=VSAMFLAGS: COUNTERS:

RECOV NEEDED =OFF EEQE COUNT =0-------------------------------------------------------------------------------



00.168 18:15:28.7 LISTING OF RECON PAGE 0009-------------------------------------------------------------------------------DBDBD=PDHDOKB MASTER DB=DBHDOK01 CHANGE#=3 TYPE=PARTUSID=0000000003 AUTHORIZED USID=0000000003 HARD USID=0000000003RECEIVE USID=0000000003 RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**









-------------------------------------------------------------------------------00.168 18:15:28.7 LISTING OF RECON PAGE 0010-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.A00002 TYPE=PARTDBD=PDHDOKB DDN=PDHDOKBA DSID=001 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------





IC1DSN=IMSVS.PDHDOKB.PDHDOKBA.IC.IC092848 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0011-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.B00002 TYPE=PARTDBD=PDHDOKB DDN=PDHDOKBB DSID=004 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------



IC1DSN=IMSVS.PDHDOKB.PDHDOKBB.IC.IC092848 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0012-------------------------------------------------------------------------------



DBDSDSN=IMSTESTS.DBHDOK01.C00002 TYPE=PARTDBD=PDHDOKB DDN=PDHDOKBC DSID=005 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSVS.PDHDOKB.PDHDOKBC.IC.IC092848 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0013-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.D00002 TYPE=PARTDBD=PDHDOKB DDN=PDHDOKBD DSID=006 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSVS.PDHDOKB.PDHDOKBD.IC.IC092849 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0014-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.L00002 TYPE=PARTDBD=PDHDOKB DDN=PDHDOKBL DSID=003 DBORG=INDEX DSORG=VSAMFLAGS: COUNTERS:

RECOV NEEDED =OFF EEQE COUNT =0-------------------------------------------------------------------------------



00.168 18:15:28.7 LISTING OF RECON PAGE 0015-------------------------------------------------------------------------------DBDBD=PDHDOKC MASTER DB=DBHDOK01 CHANGE#=4 TYPE=PARTUSID=0000000003 AUTHORIZED USID=0000000003 HARD USID=0000000003RECEIVE USID=0000000003 RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**









-------------------------------------------------------------------------------00.168 18:15:28.7 LISTING OF RECON PAGE 0016-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.A00003 TYPE=PARTDBD=PDHDOKC DDN=PDHDOKCA DSID=001 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------





IC1DSN=IMSVS.PDHDOKC.PDHDOKCA.IC.IC092849 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0017-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.B00003 TYPE=PARTDBD=PDHDOKC DDN=PDHDOKCB DSID=004 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------



IC1DSN=IMSVS.PDHDOKC.PDHDOKCB.IC.IC092849 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0018-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.C00003 TYPE=PARTDBD=PDHDOKC DDN=PDHDOKCC DSID=005 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------




IC1DSN=IMSVS.PDHDOKC.PDHDOKCC.IC.IC092849 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0019-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.D00003 TYPE=PARTDBD=PDHDOKC DDN=PDHDOKCD DSID=006 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSVS.PDHDOKC.PDHDOKCD.IC.IC092850 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0020-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.L00003 TYPE=PARTDBD=PDHDOKC DDN=PDHDOKCL DSID=003 DBORG=INDEX DSORG=VSAMFLAGS: COUNTERS:

RECOV NEEDED =OFF EEQE COUNT =0



-------------------------------------------------------------------------------00.168 18:15:28.7 LISTING OF RECON PAGE 0021-------------------------------------------------------------------------------DBDBD=PDHDOKD MASTER DB=DBHDOK01 CHANGE#=5 TYPE=PARTUSID=0000000004 AUTHORIZED USID=0000000004 HARD USID=0000000004RECEIVE USID=0000000004 RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**



PARTITION HIGH KEY/STRING (CHAR): (LENGTH=5 ).....

PARTITION HIGH KEY/STRING (HEX):FFFFFFFFFF404040404040404040404040404040404040404040404040404040





00.168 18:15:28.7 LISTING OF RECON PAGE 0022-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.A00004 TYPE=PARTDBD=PDHDOKD DDN=PDHDOKDA DSID=001 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000003NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------





IC1DSN=IMSVS.PDHDOKD.PDHDOKDA.IC.IC092850 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0023-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.B00004 TYPE=PARTDBD=PDHDOKD DDN=PDHDOKDB DSID=004 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000003NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------



IC1DSN=IMSVS.PDHDOKD.PDHDOKDB.IC.IC092850 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222



-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.C00004 TYPE=PARTDBD=PDHDOKD DDN=PDHDOKDC DSID=005 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000001NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------RUN = 00.168 09:29:30.5 * RECORD COUNT =7STOP = 00.000 00:00:00.0 BATCH USID=0000000003

IC1DSN=IMSVS.PDHDOKD.PDHDOKDC.IC.IC092850 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.D00004 TYPE=PARTDBD=PDHDOKD DDN=PDHDOKDD DSID=006 DBORG=HDAM DSORG=OSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=2DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCLRECVJCL=PRECVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSVS.PDHDOKD.PDHDOKDD.IC.IC092851 FILE SEQ=0001UNIT=3400 VOLS DEF=0001 VOLS USED=0001

VOLSER=222222

00.168 18:15:28.7 LISTING OF RECON PAGE 0026-------------------------------------------------------------------------------DBDSDSN=IMSTESTS.DBHDOK01.L00004 TYPE=PARTDBD=PDHDOKD DDN=PDHDOKDL DSID=003 DBORG=INDEX DSORG=VSAMFLAGS: COUNTERS:

RECOV NEEDED =OFF EEQE COUNT =0



DB (FP) and Related Records

1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0361-------------------------------------------------------------------------------DBDBD=DEDBDD01 DMB#=8 TYPE=FPSHARE LEVEL=1FLAGS: COUNTERS:



-------------------------------------------------------------------------------1999.251 11:46:24.1 -08:00 LISTING OF RECON PAGE 0362-------------------------------------------------------------------------------DBDSDBD=DEDBDD01 AREA=DD01AR0 TYPE=FPSHARE LEVEL=1 DSID=001 DBORG=DEDB DSORG=VSAMGSGNAME=IMSGSG1 USID=0000000003AUTHORIZED USID=0000000003 RECEIVE USID=0000000003 HARD USID=0000000003RECEIVE NEEDED USID=0000000000CAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=0 NOVSO PREOPEN NOPRELOADCFSTR1=**NULL** CFSTR2=**NULL** NOLKASIDDEFLTJCL=**NULL** ICJCL=ICJCL RECVJCL=ICRCVJCL RECOVJCL=RECOVJCLDBRCVGRP=**NULL**

FLAGS: COUNTERS:PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =1

HELD AUTHORIZATION STATE=6IC NEEDED =OFF ADS AVAIL # =1RECOV NEEDED =OFF REGISTERED ADS # =1DATABASE LEVEL TRACK =YES EEQE COUNT =0RECEIVE NEEDED =OFFOFR REQUIRED =NOTRACKING SUSPENDED =NOHSSP CIC IN PROGRESS =NO

ADS LIST:CREATE


ASSOCIATED SUBSYSTEM INFORMATION:ENCODED

-SSID- -ACCESS INTENT- -STATE- -SS ROLE-SYS3 UPDATE 6 ACTIVE

-------------------------------------------------------------------------------



Figure 37. Sample Listing of a RECON at the Active Site - DB (FP) and Related Records(Part 1 of 2)



Sample Listing of a RECON at the Tracking SiteBeginning with Figure 38, the following figures comprise a listing of a RECON froma tracking site in an RSR environment. “Fields Present in a Listing of a RECON byRecord Type” on page 416 describes the fields that can be present in a listing of theRECON.

RECON Status Record

IMAGERUN = 1996.100 07:15:11.2 -08:00 *STOP = 1996.100 07:16:12.3 -08:00 SMSCIC USID=0000000001

IC1DSN=IMSVS.DEDBDD01.SMSCIC.DSN1 FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=IMSCC1

Figure 37. Sample Listing of a RECON at the Active Site - DB (FP) and Related Records(Part 2 of 2)

IMS/ESA VERSION 7 RELEASE 1 DATA BASE RECOVERY CONTROL/* LIST IN LOCAL TIME */LIST.RECON TIMEFMT(L,O,P,4)1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------RECONRECOVERY CONTROL DATA SET, IMS/ESA V7R1DMB#=8 INIT TOKEN=99251F1858306FNOFORCER LOG DSN CHECK=CHECK17 STARTNEW=NOTAPE UNIT=3400 DASD UNIT=SYSDA TRACEOFF SSID=**NULL**LIST DLOG=YES CA/IC/LOG DATA SETS CATALOGED=NOLOG RETENTION PERIOD=00.000 00:15:00.0SIZALERT DSNUM=15 VOLNUM=16 PERCENT= 95LOGALERT DSNUM=3 VOLNUM=16

TIME STAMP INFORMATION:

TIMEZIN = %SYS -LABEL- -OFFSET-PDT -07:00PST -08:00

OUTPUT FORMAT: DEFAULT = LOCORG NONE PUNC YYCURRENT = LOCAL OFFSET PUNC YYYY

-DDNAME- -STATUS- -DATA SET NAME-RECON1 COPY1 IMSTESTL.IMS.RECON1RECON2 COPY2 IMSTESTL.IMS.RECON2RECON3 SPARE IMSTESTL.IMS.RECON3

Figure 38. Sample Listing of a RECON at the Tracking Site - RECON Status Record

Sample RECON Listing Tracking Site


Log Records

1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0305-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:16:52.6 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:35:06.3 -08:00 #DSN=4GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 2EARLIEST CHECKPOINT = 1999.251 11:18:46.7 -08:00

DSN=IMSTESTL.RSR.RLDS1.N0000011START = 1999.251 11:16:52.6 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:17:46.6 -08:00 LAST DS LSN= 0000000000000281#DS CHECKPOINTS= 2 CHKPT ID = 1999.251 11:16:59.8 -08:00

DSN=IMSTESTL.RSR.RLDS1.N0000014START = 1999.251 11:17:46.6 -08:00 FIRST DS LSN= 0000000000000282STOP = 1999.251 11:18:46.9 -08:00 LAST DS LSN= 0000000000000528#DS CHECKPOINTS= 2 CHKPT ID = 1999.251 11:17:53.1 -08:00

DSN=IMSTESTL.RSR.RLDS1.N0000017START = 1999.251 11:18:46.9 -08:00 FIRST DS LSN= 0000000000000529STOP = 1999.251 11:35:05.7 -08:00 LAST DS LSN= 000000000000072F#DS CHECKPOINTS= 2 CHKPT ID = 0000.000 00:00:00.0 +00:00

DSN=IMSTESTL.RSR.RLDS1.N0000019START = 1999.251 11:35:05.7 -08:00 FIRST DS LSN= 0000000000000730STOP = 1999.251 11:35:06.3 -08:00 LAST DS LSN= 000000000000078B#DS CHECKPOINTS= 0 CHKPT ID = 1999.251 11:35:05.6 -08:00


Figure 39. Sample Listing of a RECON at the Tracking Site - Log Records (Part 1 of 6)



1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0306-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:16:52.6 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:35:06.3 -08:00 #DSN=4GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 2

DSN=IMSTESTL.RSR.ARCH1.N0000010START = 1999.251 11:16:52.6 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:17:46.6 -08:00 LAST DS LSN= 0000000000000281#DS CHECKPOINTS= 2 CHKPT ID = 1999.251 11:16:59.8 -08:00

DSN=IMSTESTL.RSR.ARCH1.N0000013START = 1999.251 11:17:46.6 -08:00 FIRST DS LSN= 0000000000000282STOP = 1999.251 11:18:46.9 -08:00 LAST DS LSN= 0000000000000528#DS CHECKPOINTS= 2 CHKPT ID = 1999.251 11:17:53.1 -08:00

DSN=IMSTESTL.RSR.ARCH1.N0000016START = 1999.251 11:18:46.9 -08:00 FIRST DS LSN= 0000000000000529STOP = 1999.251 11:35:05.7 -08:00 LAST DS LSN= 000000000000072F#DS CHECKPOINTS= 2 CHKPT ID = 0000.000 00:00:00.0 +00:00

DSN=IMSTESTL.RSR.ARCH1.N0000018START = 1999.251 11:35:05.7 -08:00 FIRST DS LSN= 0000000000000730STOP = 1999.251 11:35:06.3 -08:00 LAST DS LSN= 000000000000078B#DS CHECKPOINTS= 0 CHKPT ID = 1999.251 11:35:05.6 -08:00

1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0307-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:35:37.8 -08:00 * SSID=BATCH1 VERSION=7.1STOP = 1999.251 11:35:40.2 -08:00 #DSN=1GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 3

DSN=IMSTESTL.RSR.ARCH1.N0000021START = 1999.251 11:35:37.8 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:35:40.2 -08:00 LAST DS LSN= 000000000000009C#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00


DHVNTZ02 HIDAM 1DXVNTZ02 XDLBT04I 1DIVNTZ02 DBHVSAM1 1




1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0308-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:37:33.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:40:49.9 -08:00 #DSN=2GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 4EARLIEST CHECKPOINT = 1999.251 11:37:41.0 -08:00

DSN=IMSTESTL.RSR.RLDS1.N0000024START = 1999.251 11:37:33.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:38:22.8 -08:00 LAST DS LSN= 00000000000001FB#DS CHECKPOINTS= 1 CHKPT ID = 1999.251 11:37:41.0 -08:00

DSN=IMSTESTL.RSR.RLDS1.N0000028START = 1999.251 11:38:22.8 -08:00 FIRST DS LSN= 00000000000001FCSTOP = 1999.251 11:40:49.9 -08:00 LAST DS LSN= 0000000000000220#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00


DEDBDD01 DD01AR0 1DHVNTZ02 HIDAM 1DXVNTZ02 XDLBT04I 1DIVNTZ02 DBHVSAM1 1

1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0309-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:37:33.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 1999.251 11:40:49.9 -08:00 #DSN=2GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 4

DSN=IMSTESTL.RSR.ARCH1.N0000023START = 1999.251 11:37:33.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:38:22.8 -08:00 LAST DS LSN= 00000000000001FB#DS CHECKPOINTS= 1 CHKPT ID = 1999.251 11:37:41.0 -08:00

DSN=IMSTESTL.RSR.ARCH1.N0000027START = 1999.251 11:38:22.8 -08:00 FIRST DS LSN= 00000000000001FCSTOP = 1999.251 11:40:49.9 -08:00 LAST DS LSN= 0000000000000220#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00




1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0310-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:40:50.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 0000.000 00:00:00.0 +00:00 #DSN=2GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000221 PRILOG TOKEN= 5EARLIEST CHECKPOINT = 1999.251 11:37:41.0 -08:00

DSN=IMSTESTL.RSR.RLDS1.N0000030START = 1999.251 11:40:50.0 -08:00 FIRST DS LSN= 0000000000000221STOP = 1999.251 11:40:54.9 -08:00 LAST DS LSN= 00000000000002CD#DS CHECKPOINTS= 1 CHKPT ID = 1999.251 11:37:41.0 -08:00

DSN=IMSTESTL.RSR.SLDS1.N0000026START = 0000.000 00:00:00.0 +00:00 FIRST DS LSN= 00000000000003E0STOP = 0000.000 00:00:00.0 +00:00 LAST DS LSN= 0000000000000000#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00


1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0311-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:40:50.0 -08:00 * SSID=SYS3 VERSION=7.1STOP = 0000.000 00:00:00.0 +00:00 #DSN=2GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000221 PRILOG TOKEN= 5

DSN=IMSTESTL.RSR.ARCH1.N0000029START = 1999.251 11:40:50.0 -08:00 FIRST DS LSN= 0000000000000221STOP = 1999.251 11:40:54.9 -08:00 LAST DS LSN= 00000000000002CD#DS CHECKPOINTS= 1 CHKPT ID = 1999.251 11:37:41.0 -08:00

DSN=IMSTESTL.RSR.SLDS1.N0000026START = 0000.000 00:00:00.0 +00:00 FIRST DS LSN= 00000000000003E0STOP = 0000.000 00:00:00.0 +00:00 LAST DS LSN= 0000000000000000#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00




1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0312-------------------------------------------------------------------------------PRILOGSTART = 1999.251 11:44:49.0 -08:00 * SSID=IMS2 VERSION=7.1STOP = 1999.251 11:45:29.4 -08:00 #DSN=2GSGNAME=IMSGSG1 TRACKING PREV-GAPFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 6EARLIEST CHECKPOINT = 0000.000 00:00:00.0 +00:00

DSN=IMSTESTL.RSR.RLDS1.N0000035START = 1999.251 11:44:49.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:45:28.3 -08:00 LAST DS LSN= 000000000000018C#DS CHECKPOINTS= 2 CHKPT ID = 0000.000 00:00:00.0 +00:00

DSN=IMSTESTL.RSR.RLDS1.N0000037START = 1999.251 11:45:28.3 -08:00 FIRST DS LSN= 000000000000018DSTOP = 1999.251 11:45:29.4 -08:00 LAST DS LSN= 00000000000001BB#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00


1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0313-------------------------------------------------------------------------------PRISLDSTART = 1999.251 11:44:49.0 -08:00 * SSID=IMS2 VERSION=7.1STOP = 1999.251 11:45:29.4 -08:00 #DSN=2GSGNAME=IMSGSG1 TRACKINGFIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 6

DSN=IMSTESTL.RSR.ARCH1.N0000034START = 1999.251 11:44:49.0 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:45:28.3 -08:00 LAST DS LSN= 000000000000018C#DS CHECKPOINTS= 2 CHKPT ID = 0000.000 00:00:00.0 +00:00

DSN=IMSTESTL.RSR.ARCH1.N0000036START = 1999.251 11:45:28.3 -08:00 FIRST DS LSN= 000000000000018DSTOP = 1999.251 11:45:29.4 -08:00 LAST DS LSN= 00000000000001BB#DS CHECKPOINTS= 0 CHKPT ID = 0000.000 00:00:00.0 +00:00




GSG Record

1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0314-------------------------------------------------------------------------------PRIOLDSSID=SYS3 # DD ENTRIES=2EARLIEST CHECKPOINT = 1999.251 11:05:30.9 -08:00

DDNAME=DFSOLP00 DSN=IMSTESTL.IMS01.OLDSP0START = 1999.251 11:05:29.4 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:43:28.7 -08:00 LAST DS LSN= 000000000000045BLOCK SEQUENCE# = 000000000000STATUS=ARC COMPLT FEOV=YES AVAILPRILOG TIME=1999.251 11:05:29.4 -08:00 ARCHIVE JOB NAME=JT114329VERSION=7.1

DDNAME=DFSOLP01 DSN=IMSTESTL.IMS01.OLDSP1START = 1999.251 11:43:28.7 -08:00 FIRST DS LSN= 000000000000045CSTOP = 0000.000 00:00:00.0 +00:00 LAST DS LSN= 0000000000000000LOCK SEQUENCE# = 000000000000STATUS=ACTIVE FEOV=NO AVAILPRILOG TIME=1999.251 11:05:29.4 -08:00VERSION=7.1

DSP0260I NO INTERIM RLDS/SLDS RECORDS FOUND IN RECONDSP0260I NO INT-ONLINE LOG RECORDS FOUND IN RECON1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0315-------------------------------------------------------------------------------PRITSLDSSTART = 1999.251 11:05:29.4 -08:00 * SSID=SYS3 VERSION=7.1STOP = 0000.000 00:00:00.0 +00:00 #DSN=1GSGNAME=IMSGSG1FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0

DSN=IMSVS.SLDSP.SYS3.D99251.T1205294.V00 UNIT=SYSDASTART = 1999.251 11:05:29.4 -08:00 FIRST DS LSN= 0000000000000001STOP = 1999.251 11:43:28.7 -08:00 LAST DS LSN= 000000000000045BFILE SEQ=0001 #VOLUMES=0001



1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------GSGGSGNAME=IMSGSG1 #SGS=2 -SGNAME- -ROLE-

STLSITE1 ACTIVESTLSITE2 TRACKING LOCAL

CURRENT PRILOG TOKEN = 6 TAKEOVER TOKEN = 0MINIMUM PRILOG TOKEN = 1 DSN SEQ NUMBER = 36START TIME OF CURRENT LOG = 1999.251 11:44:49.0 -08:00HIGHEST ACTIVE SITE TIME = 1999.251 11:45:29.4 -08:00TRACKING SUBSYSTEM ID = SYS3TAKEOVER IN PROGRESS

Figure 40. Sample Listing of a RECON at the Tracking Site - GSG Record



SSYS Record

BACKOUT Record

1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------SSYSSSID=SYS3 LOG START=1999.251 11:05:29.4 -08:00SSTYPE=TRACKER ABNORMAL TERM=OFF RECOVERY STARTED=NO BACKUP=NOTRACKED=NO TRACKER TERM=OFF SHARING COVERED DBS=NO

GSGNAME=IMSGSG1


-DBD- -AREA- -LEVEL- -ACCESS INTENT- -STATE-DEDBJN21 DB21AR0 1 EXCLUSIVE 7DHVNTZ02 **NULL** 3 EXCLUSIVE 7DXVNTZ02 **NULL** 3 EXCLUSIVE 7DIVNTZ02 **NULL** 3 EXCLUSIVE 7

SSYSSSID=SYS3 LOG START=1999.251 11:37:33.0 -08:00SSTYPE=ONLINE ABNORMAL TERM=ON RECOVERY STARTED=NO BACKUP=NOTRACKED=YES TRACKER TERM=OFF SHARING COVERED DBS=NOIRLMID=**NULL** IRLM STATUS=NORMAL GSGNAME=IMSGSG1


-DBD- -AREA- -LEVEL- -ACCESS INTENT- -STATE-DEDBDD01 DD01AR0 1 UPDATE 6DHVNTZ02 **NULL** 3 UPDATE 6DXVNTZ02 **NULL** 3 UPDATE 6DIVNTZ02 **NULL** 3 UPDATE 6

Figure 41. Sample Listing of a RECON at the Tracking Site - SSYS Record

1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------BACKOUTSSID=SYS3 #UORS=1

RECOVERY TOKEN=E2E8E2F3404040400000000300000002TIME=1999.251 11:38:22.5 -08:00 PSB=PLVAPZ12

INFLT BMPASSOCIATED DATA BASES=3

BACKED DYN BKOUT-DBD- -OUT - -FAILURE-DHVNTZ02 NO NODXVNTZ02 NO NODIVNTZ02 NO NO

Figure 42. Sample Listing of a RECON at the Tracking Site - BACKOUT Record



CAGRP and CA Records

1999.274 09:27:48.3 -09:00 LISTING OF RECON-------------------------------------------------------------------------------CAGRPGRPNAME=CAGRP1 GRPMAX=3 CA AVAIL=0 CA USED=1NOREUSE CAJCL=CAJCL DEFLTJCL=**NULL**

#MEMBERS=4 -DBD- -DDN-DEDBJN21 DB21AR1DEDBJN21 DB21AR3DEDBJN21 DB21AR6DEDBJN21 DB21AR7

CADSN=IMSVS.CAGRP1.CA.CA182601 FILE SEQ=1CAGRP=CAGRP1 STOP = 1999.274 08:40:44.3 -09:00 *


RUN = 1999.274 09:26:39.6 -09:00DBD=DEDBJN21 DDN=DB21AR1 PURGETIME = 1999.274 08:31:07.0 -09:00

CHANGES ACCUMULATED=YES COMPLETE CA=YES INDOUBT EEQES=NOLSN = 000000000000 DSSN = 0000000001LRID = 0000000000000414 USID = 0000000002

DBD=DEDBJN21 DDN=DB21AR3 PURGETIME = 1999.274 08:31:07.0 -09:00CHANGES ACCUMULATED=YES COMPLETE CA=YES INDOUBT EEQES=NOLSN = 000000000000 DSSN = 0000000001LRID = 0000000000000428 USID = 0000000002



-------------------------------------------------------------------------------CAGRPGRPNAME=CAGRP2 GRPMAX=5 CA AVAIL=0 CA USED=0NOREUSE CAJCL=CAJCL DEFLTJCL=**NULL**

#MEMBERS=3 -DBD- -DDN-DBVHDJ05 CJVHDG1EDBOHIDK5 CKOHIG1ODXVHIDK5 CKVHIIXK

Figure 43. Sample Listing of a RECON at the Tracking Site - CAGRP and CA Records



DBDSGRP Records

DB (IMS) and Related Records

1999.274 09:27:48.3 -09:00 LISTING OF RECON-------------------------------------------------------------------------------DBDSGRPGRPNAME=DBGRP1 #MEMBERS=6 -DBD- -DDN/AREA-

DIVNTZ02 **NULL**DHVNTZ02 **NULL**DXVNTZ02 **NULL**DB21AR0 **NULL**DB21AR1 **NULL**DB21AR2 **NULL**

DBDSGRPGRPNAME=FJKGRP #MEMBERS=5 -DBD- -DDN/AREA-

DIVNTZ02 DBHVSAM1DIVNTZ02 DBHVSAM2DHVNTZ02 HIDAMDHVNTZ02 HIDAM2DXVNTZ02 XDLBT04I

Figure 44. Sample Listing of a RECON at the Tracking Site - DBDSGRP Records

1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDBD=DBVHDJ05 IRLMID=*NULL DMB#=1 TYPE=IMSSHARE LEVEL=3 GSGNAME=**NULL** USID=0000000001AUTHORIZED USID=0000000000 RECEIVE USID=0000000000 HARD USID=0000000000RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**FLAGS: COUNTERS:

BACKOUT NEEDED =OFF RECOVERY NEEDED COUNT =0READ ONLY =OFF IMAGE COPY NEEDED COUNT =0PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =0RECOVERABLE =YES HELD AUTHORIZATION STATE=0

EEQE COUNT =0TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0OFR REQUIRED =NO

DBDSDSN=DBVHDJ05.CJXXD01E TYPE=IMSDBD=DBVHDJ05 DDN=CJVHDG1E DSID=001 DBORG=HDAM DSORG=VSAMCAGRP=CAGRP2 GENMAX=2 IC AVAIL=0 IC USED=0 DSSN=00000000NOREUSE RECOVPD=0DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCLRECVJCL=ICRCVJCLFLAGS: COUNTERS:

IC NEEDED =OFFIC RECOMMENDED =ONRECOV NEEDED =OFFRECEIVE NEEDED =OFF EEQE COUNT =0

Figure 45. Sample Listing of a RECON at the Tracking Site - DB (IMS) and Related Records



DB (FP) and Related Records

1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDBD=DEDBDD01 DMB#=7 TYPE=FPSHARE LEVEL=1FLAGS: COUNTERS:



DBDSDBD=DEDBDD01 AREA=DD01AR0 TYPE=FPSHARE LEVEL=1 DSID=001 DBORG=DEDB DSORG=VSAMGSGNAME=IMSGSG1 USID=0000000002AUTHORIZED USID=0000000000 RECEIVE USID=0000000000 HARD USID=0000000000RECEIVE NEEDED USID=0000000000CAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=0 DSSN=00000001NOREUSE RECOVPD=0 NOVSO PREOPEN NOPRELOADCFSTR1=**NULL** CFSTR2=**NULL** NOLKASIDDEFLTJCL=**NULL** ICJCL=ICJCL RECVJCL=ICRCVJCL RECOVJCL=RECOVJCLDBRCVGRP=**NULL**FLAGS: COUNTERS:

PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =1HELD AUTHORIZATION STATE=6

IC NEEDED =OFF ADS AVAIL # =1IC RECOMMENDED =ONRECOV NEEDED =OFF REGISTERED ADS # =1DATABASE LEVEL TRACK =YES EEQE COUNT =0RECEIVE NEEDED =OFFOFR REQUIRED =NOTRACKING SUSPENDED =NOHSSP CIC IN PROGRESS =NO

ADS LIST:CREATE


ASSOCIATED SUBSYSTEM INFORMATION:ENCODED

-SSID- -ACCESS INTENT- -STATE- -SS ROLE-SYS3 UPDATE 6 ACTIVE

-------------------------------------------------------------------------------

ALLOCALLOC =1999.251 11:37:42.5 -08:00 * ALLOC LRID =00000000000000D8DSSN=0000000001 USID=0000000002 START = 1999.251 11:37:33.0 -08:00

Figure 46. Sample Listing of a RECON at the Tracking Site - DB (FP) and Related Records



IMS DB Records

1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDBD=DHVNTZ02 IRLMID=*NULL DMB#=5 TYPE=IMSSHARE LEVEL=3 GSGNAME=IMSGSG1 USID=0000000003AUTHORIZED USID=0000000003 RECEIVE USID=0000000001 HARD USID=0000000003RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**FLAGS: COUNTERS:

BACKOUT NEEDED =ON RECOVERY NEEDED COUNT =0READ ONLY =OFF IMAGE COPY NEEDED COUNT =0PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =2RECOVERABLE =YES HELD AUTHORIZATION STATE=6DATABASE LEVEL TRACK =YES EEQE COUNT =0TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0OFR REQUIRED =NO

ASSOCIATED SUBSYSTEM INFORMATION:ENCODED B/O NEEDED

-SSID- -ACCESS INTENT- -STATE- -COUNT- -SS ROLE-SYS3 EXCLUSIVE 7 1 TRACKINGSYS3 UPDATE 6 0 ACTIVE

Figure 47. Sample Listing of a RECON at the Tracking Site - More IMS DB Records (Part 1of 5)



1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDSDSN=DHVNTZ02.FKXXI01E TYPE=IMSDBD=DHVNTZ02 DDN=HIDAM DSID=001 DBORG=HIDAM DSORG=VSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=0DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCLRECVJCL=ICRCVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------




IC1DSN=IMSTESTG.DHVNTZ02.HIDAM.BASE.IC FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=IMSRAW

RECOVRUN = 1999.251 11:03:12.0 -08:00 * RUN USID = 0000000001




1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDSDSN=DHVNTZ02.FKXXI02E TYPE=IMSDBD=DHVNTZ02 DDN=HIDAM2 DSID=002 DBORG=HIDAM DSORG=VSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=0DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCLRECVJCL=ICRCVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSTESTG.DHVNTZ02.HIDAM2.BASE.IC FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=IMSRAW


1999.251 11:46:45.8 -08:00 LISTING OF RECON PAGE 0344-------------------------------------------------------------------------------DBDBD=DIVNTZ02 IRLMID=*NULL DMB#=4 TYPE=IMSSHARE LEVEL=3 GSGNAME=IMSGSG1 USID=0000000003AUTHORIZED USID=0000000003 RECEIVE USID=0000000001 HARD USID=0000000003RECEIVE NEEDED USID=0000000000DBRCVGRP=**NULL**FLAGS: COUNTERS:

BACKOUT NEEDED =ON RECOVERY NEEDED COUNT =0READ ONLY =OFF IMAGE COPY NEEDED COUNT =0PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =2RECOVERABLE =YES HELD AUTHORIZATION STATE=6DATABASE LEVEL TRACK =YES EEQE COUNT =0TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0OFR REQUIRED =NO

ASSOCIATED SUBSYSTEM INFORMATION:ENCODED B/O NEEDED

-SSID- -ACCESS INTENT- -STATE- -COUNT- -SS ROLE-SYS3 EXCLUSIVE 7 1 TRACKINGSYS3 UPDATE 6 0 ACTIVE




1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDSDSN=DIVNTZ02.FJXXS01K TYPE=IMSDBD=DIVNTZ02 DDN=DBHVSAM1 DSID=001 DBORG=HISAM DSORG=VSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000002NOREUSE RECOVPD=0DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCLRECVJCL=ICRCVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------

ALLOCALLOC =1999.251 11:35:39.6 -08:00 * ALLOC LRID =000000000000006CDSSN=0000000001 USID=0000000002 START = 1999.251 11:35:37.8 -08:00

ALLOCALLOC =1999.251 11:38:22.6 -08:00 * ALLOC LRID =000000000000019BDSSN=0000000002 USID=0000000003 START = 1999.251 11:37:33.0 -08:00


IC1DSN=IMSTESTG.DIVNTZ02.DBHVSAM1.BASE.IC FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=IMSRAW





Fields Present in a Listing of a RECON by Record TypeThe following sections describe the fields that can be present in a listing of theRECON by record type:

v “Fields Present in a RECON Record” on page 417

v “Fields Present in a THT Record” on page 420

v “Fields Present in a Log Record” on page 421

v “Fields Present in a LOGALL Record” on page 423

v “Fields Present in an Online Log Record” on page 423

v “Fields Present in a GSG Record” on page 427

v “Fields Present in a SSYS Record” on page 428

v “Fields Present in a BACKOUT Record” on page 429

v “Fields Present in a CAGRP Record” on page 430

v “Fields Present in a CA Record” on page 431

v “Fields Present in a Data Group Record” on page 433

v “Fields Present in a DB (IMS) Record” on page 434

v “Fields Present in a DB (Fast Path) Record” on page 440

v “Fields Present in a DBDS (non-Fast Path) Record” on page 441

v “Fields Present in a DB (HALDB) Record” on page 436

v “Fields Present in a DB (PART) and Related Records” on page 437

v “Fields Present in a DBDS (Fast Path) Record” on page 443

v “Fields Present in an ALLOC Record” on page 447

v “Fields Present in an IMAGE Record” on page 448

1999.251 11:46:45.8 -08:00 LISTING OF RECON-------------------------------------------------------------------------------DBDSDSN=DIVNTZ02.FJXXS01E TYPE=IMSDBD=DIVNTZ02 DDN=DBHVSAM2 DSID=002 DBORG=HISAM DSORG=VSAMCAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000000NOREUSE RECOVPD=0DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCLRECVJCL=ICRCVJCLFLAGS: COUNTERS:


-------------------------------------------------------------------------------


IC1DSN=IMSTESTG.DIVNTZ02.DBHVSAM2.BASE.IC FILE SEQ=0001UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001

VOLSER=IMSRAW



Fields in a RECON Listing


v “Fields Present in a REORG Record” on page 450

v “Fields Present in a RECOV Record” on page 451

Examples of many of these fields appear in Figure 29 on page 374 and Figure 38on page 401.

Definition:

A group of lines refers to the lines following the referring statement whose rowspans the width of the table. The group of lines ends at the next statement thatspans the width of the table, unless otherwise specified.

Fields Present in a RECON RecordA RECON record’s fields and their corresponding line numbers are described inTable 20.

Table 20. Fields Present in the RECON Record

RecordType

LineNumber Field Contents

RECON 1

2 RECOVERY CONTROLDATA SET, IMS/ESA VxRx

Identifies the version and release ofthe RECON.

COEXISTENCE ENABLED Specifies that pre-version 6 andversion 6 RECONs may coexist.

3 DMB#= nnn Represents the last value assignedto a new database record.

INIT TOKEN= token The token assigned to this RECONwhen it was initialized.

4 FORCER | NOFORCER Indicates whether databases must beregistered in RECON. FORCERindicates that all databases must beregistered. NOFORCER indicatesthat all databases do not need to beregistered.

LOG DSN CHECK=xxxxxx

The type of log data set namechecking; xxxxxx is CHECK17,CHECK44, or NOCHECK.

STARTNEW= YES | NO When I/O errors exist on one of theRECON, YES indicates that newjobs are to start. NO indicates thatno new jobs are to start.

5 TAPE UNIT= unittype The default unit type for log datasets, NOREUSE image copy datasets, and NOREUSE changeaccumulation data sets that resideon tape devices.

DASD UNIT= unittype The default unit type for log datasets, NOREUSE image copy datasets, and NOREUSE changeaccumulation data sets that resideon DASD devices.

TRACEON | TRACEOFF TRACEON indicates DBRC is toproduce external GTF trace entries.

Fields in a RECON Listing


Table 20. Fields Present in the RECON Record (continued)

RecordType


SSID= xxxxxxxx The IMS subsystem default name.

6 LISTDLOG= YES | NO Indicates whether the names of logdata sets deleted from RECON areto be listed.

CA | IC | LOG DATA SETSCATALOGED= YES | NO

Indicates whether CA, IC, and logdata sets are to be treated as if theyare cataloged. To bypass volumeserial checking of utility DDstatements, specify YES and thedata set is cataloged. If you specifyNO (or the data set is not cataloged),volume serial checking takes place.

7 LOG RETENTION PERIOD=yy.ddd hh:mm:ss.t

Indicates the minimum amount oftime that DBRC is to keep logrecords in RECON.

8 TRACE OPTIONS=options

This line is printed only if an IBMrepresentative has instructed you togather documentation for problemanalysis. It indicates that an IBMrepresentative has providedinstructions to enable DBRC tracerecords to be written to the DBRCtrace table for problem analysis. TheIBM representative will haveprovided the options.

9 LOGALERT= xxxxxxxxxxxxxxxx

The (optional) threshold that triggersthe DSP0287W message (warningyou when you just have time to shutdown an online IMS subsystembefore it ABENDs due to thePRILOG record exceedingRECORDSIZE). Field values can bedsnum, volnum and percent.

10 SIZALERT= xxxxxxxxxxxxxxxx xx

The (optional) thresholds that triggermessages to warn you that a recordhas grown unnaturally large. Fieldvalues can be dsnum, volnum andpercent.

The following line is printed only if a failure occurred during a multiple update to the RECON:

11 UPDATE TYPE= nnnn The type of multiple update that wasin progress.

DBID= xxxxxxxx xxxxxxxx Data set name and data set ddnameof the DBDS involved in the multipleupdate. Can be blank.

CAGRP= xxxxxxxx Name of the CA group involved inthe multiple update. Contains blanksif no group was involved.

NEW DDN= xxxxxxxx New ddname, if any, that wasassociated with the DBDS that wasinvolved in the multiple update.Contains blanks if no new name orDBDS was involved.

Fields in a RECON Record



RecordType


12 OLD RECORD KEY This field is printed only if themultiple update involves a keychange.

13 KEY TYPE= *xxxxx A description of the record type. Theasterisk (*) is printed only if therecord is available for future use (it iseither new or scheduled for reuse).Whenever an unrecognizable recordkey type is found, BADTYP.KEY isprinted, together with the key inhexadecimal characters.

DBD= xxxxxxxx,DDN= xxxxxxxx

The database name and data setddname of a DBDS. If the record isPRILOG, SECLOG, IPRI, or ISEC,the fields are printed as **NULL**. Ifthe record is a CAGRP or DB record,the DBD field is **NULL**, and theDDN field contains the name of theCA group or database.

TIME= timestamp The time stamp of the key of therecord.

14-15 NEW RECORD KEY This field is printed only if a newrecord key is being added. Additionalfields in this part of the record areprinted as shown in line 8.

16-17 BASE RECORD KEY This field is printed only if a newrecord key is being changed. Theremaining fields in this part of therecord are printed as shown in line 8.

18-19 SSID= ssidnameIRLMID= irlmidnameSHARE LVL #= n#DB= nB/O#= n

Information about the multipleupdate.

20 FLAGS: A heading for the following lines.

21 RECOV= ON | OFFNORECOV= ON | OFFICON= ON | OFFICOFF= ON | OFF


22 NORMAL= ON | OFFABNORMAL= ON | OFFSTARTRCV= ON | OFFENDRECOV= ON | OFF


23 READON= ON | OFFREADOFF= ON | OFFAUTH= ON | OFF NOAUTH=ON | OFF


24 B/O DONE= ON | OFFPASS 1= ON | OFFBACKOUT= ON | OFFSHARELVL= ON | OFF





RecordType


25 TIME STAMPINFORMATION:

Heading for section containingRECON time stamp information.

26 TIMEZIN= offset User-specified input time stampoffset default. If no offset is specified,this field displays %SYS meaning thatthe offset of the MVS clock is to beused.

-LABEL- -OFFSET- These column headings are printed ifa Time Zone Label Table has beendefined.

27-nnn label offset The list of defined time zone offsetlabels with their corresponding offsetvalues.

28 OUTPUT FORMAT: Time stamp output format settings.

DEFAULT=offset display form yearsize

Default time stamp output formatsettings.

29 CURRENT=offset display form yearsize

Current time stamp output formatsettings.

30 -DDNAME- -STATUS- -DATASET NAME-

Column headings for the followingone to three lines.

31 RECON1 | RECON2 |RECON3COPY1dsname

The ddname, status, and data setname of the Copy1 RECON.

32-33 RECON1 | RECON2 |RECON3 | COPY2 |DISCARDED | SPARE |UNAVAILABLEdsname or blank

These lines identify the ddname,status, and data set name of theRECON backup (Copy2), theRECON spare, and any RECONsthat are not usable (DISCARDED). ARECON that could not be accessedis shown as UNAVAILABLE(unknown dsname and status).

Fields Present in a THT RecordA time history table record’s fields and their corresponding line numbers aredescribed in Table 21.

Table 21. Fields Present in the THT Record

RecordType


THT 1

2 -LOCAL START--OFFSET-

Column headings for the Time HistoryTable.

3-nnn yyyy.ddd hh:mm:ss.t±hh:mm

The local start time of the period inwhich the offset is in effect.



Fields Present in a Log RecordThe log records include the types listed under Record Type in the Table 22.

A log record’s fields and their corresponding line numbers are described inTable 22.

Table 22. Fields Present in a Log Record

RecordType


PRILOG orSECLOG orPRISLD orSECSLD orIPRI orISEC orIPRISL orISECSL orPRITSLDSorSECTSLDSorIPRITSLDorISECTSLD

1

2 START= timestamp* Time stamp of the start time (that is,original open time) of the log data set.An asterisk (*) indicates that this timestamp is part of the record key.

SSID= ssidname The name of the IMS subsystem.

VERSION=version The version of the IMS subsystemthat created the log.

3 STOP= timestamp Time stamp of the stop time (that is,close time) of the log data set. Zerosindicate that the data set is still open.

#DSN= nn The number of data sets in the logdata set. A value of zero indicatesthat no data set has been created.

4 GSGNAME= gsgname Identifies the name of the GSG towhich the subsystem producing thislog belongs.

The following 4 fields are printed if the condition in the contents column is true:

TRACKING This log data set was originallycreated by an active IMS subsystemof the nonlocal service group andtransported to the tracking site.

GAP There is a gap in the log data sets ofthis record.

PREV-GAP There is a gap in a previous logrecord of the same global servicegroup.

BBO Identifies the log record as it wascreated by batch backout. If therecord was not created by batchbackout, this field is blank.

Fields in Log Records


Table 22. Fields Present in a Log Record (continued)

RecordType


5 FIRST RECORD ID= lsn The log record sequence number ofthe first log record that was writtenduring initialization of the IMSsubsystem.

PRILOG TOKEN= n The numeric log token assignedsequentially to PRILOG records forthe same GSG.

6 EARLIESTCHECKPOINT=timestamp

This line is printed only for onlinePRILOGs. It indicates the earliestcheckpoint required by IMSemergency restart (/ERE or /EREBUILDQ).

7 DSN= log.dsname The data set name of the log data setdescribed in this record.****COMPRESSED DATA SET ****

indicates that PRILOG compressionhas removed unneeded DSN entries.

ERR This field is printed if a previouscommand was used to indicate thatan error exists in the log data set.

UNIT= unittype Unit type to be used for substitutionduring the GENJCL process.

8 START= timestamp Start time of the data set entry in thelog data set.

FIRST RECORD LSN=lsn

The log record sequence number ofthe first log record of the data set.

9 STOP= timestamp Stop time of the data set entry in thelog data set. Zeros indicate that thedata set is still open.

LAST RECORD LSN=lsn

The log record sequence number ofthe last log record of the data set.

10 FILE SEQ= nnnn The file sequence number of the logdata set. This field is not printed fortracking logs.

#VOLUMES= nnn The number of volumes for each dataset entry. This field is not printed fortracking logs.

#DS CHECKPOINTS= n Count of checkpoint records in the logdata set. This field is only printed fortracking logs.

11 VOLSER= volserSTOPTIME= timestamp

Volume serial number and stop time.This field is not printed for trackinglogs.

12 CKPTCT= nCHKPT ID= timestamp

Checkpoint count and ID value.

FEOV Indicates that the corresponding logdata set at the active site was closedby a /DBR with the forced end ofvolume option. This field is onlyprinted for tracking PRILOGs.



Fields Present in a LOGALL RecordA log allocation record’s fields and their corresponding line numbers are describedin Table 23.

Table 23. Fields Present in the LOGALL Record

RecordType


LOGALL 1

2 START= timestamp* The start time of the log data set thatcontains change records for DBDSsincluded in this record. If the asterisk(*) is present, it indicates that thistime stamp also occurs in the key ofthe LOGALL record.

3 DBDS ALLOC= nnnn The number of allocated DBDSs forthis log data set.

-DBD- -DDN- -ALLOC- These headings are printed only if theLOGALL record contained records ofeach DBDS that was allocatedbetween the start and stop timestamps of the log data set.

4-nnn dbdname ddname nnnn The database name, data setddname, and number of allocations ofthe DBDS during the time span of theallocated log.

Fields Present in an Online Log RecordAn online log record’s fields and their corresponding line numbers are described inTable 24.

Table 24. Fields Present in an Online Log Record

RecordType


PRILOG orSECLOG orPRISLD orSECSLD orIPRI orISEC orIPRISL orISECSL orPRITSLDSorSECTSLDSorIPRITSLDorISECTSLD

1

2 START= timestamp* Time stamp of the start time (that is,original open time) of the log data set.An asterisk (*) indicates that this timestamp is part of the record key.



Table 24. Fields Present in an Online Log Record (continued)

RecordType


SSID= ssidname The name of the IMS subsystem.

VERSION=version The version of the IMS subsystemthat created the log.

3 STOP= timestamp Time stamp of the stop time (that is,close time) of the log data set. Zerosindicate that the data set is still open.

#DSN= nn The number of data sets in the logdata set. A value of zero indicatesthat no data set has been created.

4 GSGNAME= gsgname Identifies the name of the GSG towhich the subsystem producing thislog belongs.

The following 4 fields are printed if the condition in the contents column is true:

TRACKING This log data set was originallycreated by an active IMS subsystemof the nonlocal service group andtransported to the tracking site.

GAP There is a gap in the log data sets ofthis record.

PREV-GAP There is a gap in a previous logrecord of the same global servicegroup.

BBO Identifies the log record as it wascreated by batch backout. If therecord was not created by batchbackout, this field is blank.

5 FIRST RECORD ID= lsn The log record sequence number ofthe first log record that was writtenduring initialization of the IMSsubsystem.

PRILOG TOKEN= n The numeric log token assignedsequentially to PRILOG records forthe same GSG.


This line is printed only for onlinePRILOGs. It indicates the earliestcheckpoint required by IMSemergency restart (/ERE or /EREBUILDQ).

7 DSN= log.dsname The data set name of the log data setdescribed in this record.****COMPRESSED DATA SET ****

indicates that PRILOG compressionhas removed unneeded DSN entries.

ERR This field is printed if a previouscommand was used to indicate thatan error exists in the log data set.


Fields in an Online Log Record



RecordType


8 START= timestamp Start time of the data set entry in thelog data set.

FIRST RECORD LSN=lsn

The log record sequence number ofthe first log record of the data set.

9 STOP= timestamp Stop time of the data set entry in thelog data set. Zeros indicate that thedata set is still open.

LAST RECORD LSN=lsn

The log record sequence number ofthe last log record of the data set.

10 FILE SEQ= nnnn The file sequence number of the logdata set. This field is not printed fortracking logs.

#VOLUMES= nnn The number of volumes for each dataset entry. This field is not printed fortracking logs.

#DS CHECKPOINTS= n Count of checkpoint records in the logdata set. This field is only printed fortracking logs.

11 VOLSER= volserSTOPTIME= timestamp

Volume serial number and stop time.This field is not printed for trackinglogs.

12 CKPTCT= nCHKPT ID= timestamp

Checkpoint count and ID value.

blank line These blank lines are printed asvisual separators only when the logdata set has more than one data setentry. The format of each data setentry is a repetition of lines 7 through12 above.

LOGALL 1

2 START= timestamp* The start time of the log data set thatcontains change records for DBDSsincluded in this record. If the asterisk(*) is present, it indicates that thistime stamp also occurs in the key ofthe LOGALL record.

3 DBDS ALLOC= nnnn The number of allocated DBDSs forthis log data set.

-DBD- -DDN- -ALLOC- These headings printed only if theLOGALL record contained records ofeach DBDS that was allocatedbetween the start and stop timestamps of the log data set.

4-nnn dbdname ddname nnnn The database name, data setddname, and number of allocations ofthe DBDS during the time span of theallocated log.




RecordType


PRIOLD orSECOLD orIPRIOL orISECOL

1

2 SSID= xxxxxxxx The name of the IMS subsystem.

# DD ENTRIES= n The number of ddnames in theOLDS.


This line is printed only for PRIOLDrecords. It indicates the earliestcheckpoint required by IMSemergency restart (/ERE or /EREBUILDQ).

4 DDNAME= ddname The ddname of the OLDS.

DSN=log-dsname The data set name of the OLDS.

5 START= timestamp Time stamp of the start time (that is,original open time) of the log data set.

FIRST DS LSN= lsn The log record sequence number ofthe first log record of the data set.

6 STOP= timestamp Time stamp of the stop time (that is,close time) of the log data set. Zerosindicate that the data set is notclosed.

LAST DS LSN= lsn The log record sequence number ofthe last log record of the data set.

7 STATUS= ARC NEEDED|ARC STARTED |ARC SCHED |ARC COMPLT | ACTIVE

The status of the DD entry in theOLDS record. This field applies to thePRIOLDS record only.

ERROR= CLOSE | PREV Indicates a close error on an OLDS oron a previous OLDS record. This fieldapplies to the PRIOLDS record only.

FEOV= YES | NO A specification of FEOV=YES forcesan end-of-output data set at the endof archiving DFSOLP02. This is doneto conform to the recovery pointestablished by the /DBR command.This field applies to the PRIOLDSrecord only.

AVAIL | UNAVAIL Identifies whether the OLDS isavailable for regular use. UNAVAILindicates that the data set has invaliddata or an I/O error. This field appliesto PRIOLDS or SECOLDS recordsonly.

8 PRILOG TIME=timestamp

Time stamp of the time of the firstOLDS the subsystem used. This isalso the start time of the PRILOG andPRISLD records corresponding to thesubsystem invocation.




RecordType


ARCHIVE JOB NAME=jobname

Name of the archive job generated bythe GENJCL ARCHIVE function.

blank line These blank lines are printed asvisual separators only when theOLDS has more than one DD entry.The format of each data set entry is arepetition of lines 4 through 8 above.

Fields Present in a GSG RecordA global service group record’s fields and their corresponding line numbers aredescribed in Table 25.

Table 25. Fields Present in a GSG Record

RecordType


GSG 1

2 GSGNAME= gsgname Identifies the name of the GSG.

#SGS= The number of service groups in thisGSG.

-SGNAME- -ROLE- Headings for the following lines 3through 10.

3-4 sgnamesgrole Service group name and servicegroup role (active or tracking).

LOCAL Identifies which service group is thelocal one of the GSG.

5 CURRENT PRILOGTOKEN= token

The highest PRILOG token at thelocal site of this GSG.

TAKEOVER TOKEN=token

The current PRILOG token at the timean RSR takeover was initiated at thelocal site.

6 MINIMUM PRILOGTOKEN= token

The minimum PRILOG that ismaintained at the local site of theGSG.

DSN SEQ NUMBER=number

The initial DSN sequence numbervalue for the GSG group.

7 START TIME OFCURRENT LOG=timestamp

The start time of the PRILOG with thecurrent log token.

8 HIGHEST ACTIVE SITETIME= timestamp

The highest time received from theactive site. This field is onlymeaningful to the tracking site.

9 TRACKINGSUBSYSTEM ID= ssid

Subsystem identification of thetracking subsystem. This field is nullat the active site.

10 TAKEOVER INPROGRESS

This is printed when an RSR takeoverhas been initiated at the local site.



Fields Present in a SSYS RecordA subsystem record’s fields and their corresponding line numbers are described inTable 26.

Table 26. Fields Present in a SSYS Record

RecordType


SSYS 1

2 SSID= ssidname The name of the IMS subsystem.

LOG START= timestamp The earliest log data set start timeassociated with this system or the logdata set start time created by batchbackout.

3 SSTYPE=ONLINE | BATCH| TRACKER

Indication of whether this is an IMSonline, batch, or tracking subsystem.

ABNORMAL TERM=ON | OFF

The value of this flag field is normallyOFF. If it is ON, the system has beenabnormally ended and databaserecovery is required.

RECOVERY STARTED=YES | NO

If the value of this field is YES, thissubsystem has signed on forrecovery-started processing. Normally,this value is NO.

BACKUP= YES | NO If the value of this field is YES, thereis an alternate subsystem.

4 TRACKED= YES | NO Indicates whether this is the record ofan active subsystem being tracked bythe tracking site.

TRACKER TERM= ON |OFF

Indicates whether the trackingsubsystem has terminated. This fieldonly applies to the tracking subsystemrecord.

SHARING COVEREDDBS= YES | NO

Indicates that this active subsystem issharing RSR-covered databases.

5 IRLMID= xxxxxx The IRLM with which this subsystemis communicating.

IRLM STATUS=NORMAL |IRLM FAILURE |COMM FAILURE |SYS FAILURE

Indicates the status of the IRLM.NORMAL indicates no failure. Thisfield does not apply to an RSRtracking subsystem.

GSG NAME= gsgname Identifies the name of the globalservice group to which the subsystembelongs.

6 BACKUP IRLMID=irlmname

Identifies the IRLM with which thealternate subsystem iscommunicating. Listed only if analternate subsystem exists.

BACKUP TOKEN= nnnn Identifies the backup token. Listedonly if an alternate subsystem exists.

Fields in a SSYS Record


Table 26. Fields Present in a SSYS Record (continued)

RecordType


7 AUTHORIZEDDATABASES |AREAS=nnn

Indicates that this subsystem iscurrently authorized to n databases orareas.

VERSION= n Identifies the IMS release levelthrough which the subsystem signedon.

If the number of authorized databases or areas is not zero, the following lines (up to theBACKOUT record line) list those that are currently authorized:

8-9 -DBD- -AREA- -LEVEL--ACCESSINTENT-ENCODED -STATE-

Column headings for the following lineor lines that describe the currentlyauthorized databases or areas.

10-nnn dbdname areanamesharelvl access encodedstate

This is the name of the database orarea that is currently authorized bythis subsystem, the share level, theaccess intent by this subsystem, andthe encoded state.

Fields Present in a BACKOUT RecordA backout record’s fields and their corresponding line numbers are described inTable 27.

Table 27. Fields Present in a BACKOUT Record

RecordType


BACKOUT 1

2 SSID= xxxxxxxx The name of the associated IMSsubsystem.

#UORS= nn The number of units of recovery(UORs) in the BACKOUT record.

3 RECOVERY TOKEN= 32hexadecimal digits

Describes a specific UOR.

4 TIME= timestamp The time stamp of the beginning ofthe UOR (found in the X'5607' logrecord).

PSB= psbname Name of the PSB associated with theUOR.

Fields in a SSYS Record


Table 27. Fields Present in a BACKOUT Record (continued)

RecordType


5 CANDIDATE INFLT |INDT BMP COLDENDCMD BATCH

UOR indicators, one or more of whichmight be listed. CANDIDATE: UORidentified by BBO utility prior to restart(COLDSTART | ACTIVE controlstatement). Reset (to null) whenpromoted to backout-needed statusby IMS restart. INFLT, In-flight UORdue to an IMS failure. INDT, In-doubtUOR due to a CCTL or DBCTLfailure. BMP, UOR due to a BMP.COLDEND, Cold start has ended.UOR can only be resolved by BBO.CMD, UOR entry has been modifiedby commands (CHANGE, DELETE,NOTIFY). BATCH, UOR due to adynamic backout failure of DL/I batch.

6 ASSOCIATEDDATABASES= nn

Number of databases associated withthe UOR.

7, 8 BACKED DYN BKOUT-DBD- -OUT- -FAILURE

Heading for the following list ofassociated databases.

9-nnn dbname YES | NO YES |NO

Database name. The first YES or NOindicates whether the UOR has beenbacked out for the database. Thesecond YES or NO indicates whetherthe UOR is the result of a dynamicbackout failure.

Fields Present in a CAGRP RecordA change accumulation group record’s fields and their corresponding line numbersare described in Table 28.

Table 28. Fields Present in a CAGRP Record

RecordType


CAGRP 1

2 GRPNAME= cagrpnam The name of the CA group.

GRPMAX= nnnn The maximum number of changeaccumulation run records that can beassociated with this group, whetheravailable or in use.

CA AVAIL= nnnn The number of available changeaccumulation run records currently inRECON for this group.

CA USED= nnnn The number of in-use changeaccumulation run records currently inRECON for this group.

Fields in a BACKOUT Record


Table 28. Fields Present in a CAGRP Record (continued)

RecordType


3 REUSE | NOREUSE Indicates whether changeaccumulation data sets can be reusedand whether empty ones can becreated for subsequent use (REUSE)or not (NOREUSE).

CAJCL= cajclmem The name of the member of apartitioned data set that containsskeletal JCL for this CA group.

DEFLTJCL= member The name of the member of apartitioned data set. This membercontains the skeletal JCL defaultvalues for the user-defined keywordsto be used for this CA group.

4 #MEMBERS= nnnn This number of DBDSs and areasthat belong to this CA group.

-DBD- -DDN- These headings and the followinglines are printed only if some DBDSsare members of this group.

5-nnn dbdname ddname The database name and data setddname of a DBDS that is a memberof this CA group.

Fields Present in a CA RecordA change accumulation record’s fields and their corresponding line numbers aredescribed in Table 29.

Table 29. Fields Present in a CA Record

RecordType


CA 1

2 *DSN=chge.accum.dsname

The asterisk is printed if the changeaccumulation data set identified in thisrecord is available for use. DSN= isthe change accumulation data setname that has been or could be usedas the output data set during a run ofthe Database Change Accumulationutility.

FILE SEQ= nnnn The file sequence number of the firstvolume of this data set.

3 CAGRP= cagrpname Name of the CA group to which thechange accumulation record belongs.


Fields in a CAGRP Record


Table 29. Fields Present in a CA Record (continued)

RecordType


4 CREATE | STOP=timestamp*

CREATE is printed if the data set isavailable for future use. In this case,the time stamp is the time that therecord was created or made availablefor recycling. STOP is printed forin-use records. In this case, the timestamp is the stop time of the last logvolume that was processed by theDatabase Change Accumulationutility. If SUBSET is printed (see line6), the time stamp is the start time ofthe first unselected log. The asterisk(*) indicates that this time stamp is inthe record key.

VOLS DEF= nnnn VOLSUSED= nnnn

The number of volumes that havebeen specified for use by this changeaccumulation data set and thenumber of volumes that were used ina Database Change Accumulationutility run. For available changeaccumulation data sets, if the data setcan be reused, this field contains thesame value as the VOLS DEF field.Otherwise, it indicates the number ofvolumes that were actually used.

5-nnn VOLSER= volser1,volser2,...

Volume serial numbers of thevolumes on which the changeaccumulation data set resides or is toreside. Only as many lines asnecessary are used to list the volume.

The following lines are printed only if the change accumulation data set has been usedduring a run of the Change Accumulation utility (the change accumulation data set is nolonger available):

6 RUN= timestamp This time stamp represents the timeof the run of the ChangeAccumulation utility during which thisrecord was used.

ERR This indicates that you have markedthe change accumulation data set asunusable because of a previous error.

SUBSET This indicates that a subset of logswere processed when the CA wascreated.

* The asterisk (*) indicates that COMPor SUBSET were specified in theCHANGE.CA or NOTIFY.CA commands.

These headings are printed only if purge times exist in the record. If purge times exist, thereis one line in the format labeled below (7-9) for each DBDS in the CA group.

7 DBD= dbdnameDDN= ddname

The database name and data setddname of the DBDS.

Fields in a CA Record


Table 29. Fields Present in a CA Record (continued)

RecordType


PURGETIME= timestamp Change records occurring before thistime stamp for the correspondingDBDS have been ignored by theDatabase Change Accumulationutility.

8 CHANGESACCUMULATED= YES |NO

YES is printed if the DatabaseChange Accumulation utility runaccumulated any changes for thecorresponding DBDS. NO is printed ifno changes were found for DBDS.

COMPLETE CA= YES |NO

YES is printed if the log subset for thecorresponding DBDS is complete. NOis printed if the log subset for theDBDS is incomplete.

INDOUBT EEQES=YES | NO

YES is printed to indicate that indoubt EEQEs were accumulated forthe corresponding DBDS. NO isprinted if no in doubt EEQEs wereaccumulated.

9 LSN= lsn The lock sequence number of the lastchange accumulated for the DBDS islisted.

DSSN= dssn The data set sequence number of thelast change accumulated for theDBDS is listed.

10 LRID= log_record_ID The last log record ID of the lastchange accumulated for the DBDS islisted in this field.

USID= update_set_ID The last update set ID of the lastchange accumulated for the DBDS islisted in this field.

Fields Present in a Data Group RecordA database data group record’s fields and their corresponding line numbers aredescribed in Table 30.

Table 30. Fields Present in the DBDSGRP Record

RecordType


DBDSGRPDBGRP orRECOVGRP

1 Type of group: DBDS, DB, orRecovery.

2 GRPNAME= grpname Name of the group.

#MEMBERS= nnn Number of members belonging to thegroup.

Fields in a CA Record


Table 30. Fields Present in the DBDSGRP Record (continued)

RecordType


-DBD- -DDN/AREA--DBD/AREA- or -DBD--AREA-

Any or all of these headings can beprinted, depending on the groupmembers that exist. For DBDSgroups, the heading is -DBD--DDN/AREA-. For DB groups, theheading is-DBD/AREA-. For recoverygroups, the heading is -DBD- -AREA-.

3-nnn dbdnameddname/areaname

For DBDSGRP, dbdname = DB name,ddname/areaname = DBDS name orarea name. For DBGRP, dbdname =DL/I DB name or DEDB area name.ddname/areaname is blank. ForRECOVGRP, dbdname = DB name,ddname/areaname = area name if DBis a DEDB, or blank if DB is DL/I.

Fields Present in a DB (IMS) RecordAn IMS database record’s fields and their corresponding line numbers aredescribed in Table 31.

Table 31. Fields Present in the DB (IMS) Record

RecordType


DB (IMS) 1

2 DBD= dbdname Name of the database.

IRLMID= xxxxx Identifies the IRLM when the sharelevel of this database is 2. This fieldis printed only when SHARELEVEL=2.

DMB#= nnn The value assigned when thisdatabase was registered.

TYPE= IMS Indicates that this is a DL/I database(rather than a Fast Path DEDB).

3 SHARE LEVEL= n The level of data sharing for whichauthorized subsystems can share thisdatabase.

GSGNAME= gsgname Identifies the name of the GSG towhich this database belongs.

USID= n The highest update set identifier forthis database.

4 AUTHORIZED USID= n The identifier of the current updateset that is being applied to thedatabase.

RECEIVE USID= n The update set identifier of the lastimage copy received for thisdatabase. The update set ID onlyapplies to shadow databases at thetracking site.

Fields in a Data Group Record


Table 31. Fields Present in the DB (IMS) Record (continued)

RecordType


HARD USID= n The update set identifier of the latestchanges that were written to thedatabase.

5 RECEIVE NEEDEDUSID= n

This only applies to shadowdatabases at the tracking site. If n isnot zero, this indicates that imagecopies with the identified USID arerequired for the DBDSs marked“receive needed”.

6 FLAGS: COUNTERS: This heading line is printed for lines 7through 13, which describe the statusof this database.

7 BACKOUT NEEDED=ON | OFF

This flag indicates whether thisdatabase needs to be backed-out byany subsystem.

RECOVERY NEEDEDCOUNT= n

This counter is the number of DBDSsthat are associated with this databasethat need to be recovered. Theprinted output of the DBDS recordindicates which DBDSs needrecovery.

8 READ ONLY= ON | OFF Indicates whether this database canbe authorized for read processingonly, or authorized for read andupdate processing.

IMAGE COPY NEEDEDCOUNT= n

A count of how many DBDSs that areassociated with this database requirean image copy or forward recovery.The printed output of the DBDSrecords indicates which DBDSsrequire an image copy.

9 PROHIBITAUTHORIZATION= ON |OFF

This flag indicates whether thisdatabase is available for authorizationprocessing. If the database can beauthorized, the value is OFF.

AUTHORIZEDSUBSYSTEMS= n

The count of subsystems that havecurrent authorization to this database.

10 RECOVERABLE= YES |NO

An indication of whether the databaseis recoverable (YES) ornon-recoverable (NO).

HELD AUTHORIZATIONSTATE= n

This is the state derived by thedatabase authorization call process inIMS. It represents the composite useof the database by all currentlyauthorized subsystems. If n= 0, nosubsystem is authorized to use thisdatabase. If n> 0, see line the 17encoded state field below for thesubsystem encoded state. If n> 128,block-level data sharing is in effect.Subtract 128 to determine the trueheld authorization state.

Fields in a DB (IMS) Record


Table 31. Fields Present in the DB (IMS) Record (continued)

RecordType


11 DATABASE LEVELTRACK= YES | NO

Indicates the level of tracking for thedatabase. YES is printed fordatabase-readiness tracking. NOindicates recovery-readiness tracking.This is listed only if the database iscontained in a GSG.

EEQE COUNT= n Number of extended error queueelements for this database.

12 TRACKINGSUSPENDED= YES | NO

Indicates whether tracking has beensuspended for this shadow database.

RECEIVE REQUIREDCOUNT= n

Indicates how many of the DBDSs(for this shadow database) needimage copies to be received from theactive site.

13 OFR REQUIRED= YES |NO

Indicates whether online forwardrecovery is required for this shadowdatabase.

The following lines 14 through 17 are printed only when one or more subsystems arecurrently authorized to this database:

14, 15, 16 ASSOCIATEDSUBSYSTEMINFORMATION: -SSID--AC INTENT- ENCODED-STATE- B/O NEEDED-COUNT- -SS ROLE-

Headings for lines 17-nnn. Theseheadings are printed if subsystemsexist

17-nnn ssidname The subsystem associated with thisauthorization.

access intent The intended access for thesubsystem: READ, UPDATE,EXCLUSIVE, or READ-GO.

encoded state= n An internal value derived by IMS toindicate the subsystem’s intended useof the database. The values of n areas follows: 1 - Read only 2 - Readshare 3 - Multiple update 4 - Readexclusive 5 - Batch update 6 - Singleupdate 7 - Exclusive

backout needed count Determines that the database needsn backouts by this subsystem.

ACTIVE | TRACKING Role of authorized subsystem

Fields Present in a DB (HALDB) RecordA HALDB master record’s fields and their corresponding line numbers are describedin Table 32 on page 437.



Table 32. Fields Present in the DB (HALDB) Record

RecordType

LineNumber

Field Contents

DB (HALDBMaster)

1

2 DBD=dbdname Name of the HALDB.

DMB#=nnn The value assigned when thisdatabase was registered.

CHANGE#=nnn The change version number. This isupdated when the definition of theHALDB is changed.

TYPE=HALDB Indicates that this is the HALDBmaster.

3 SHARE LEVEL=n The level of data sharing for whichauthorized subsystems can share anypartition of this HALDB.

GSGNAME=gsgname Identifies the name of the GSG towhich this database belongs.

4 PSNAME=psname The name of the partition selectionroutine used by this HALDB, if any.Otherwise **NULL** is printed.

5 FLAGS: COUNTERS: This heading line is printed for line 6,which describe the status of thisHALDB.

6 RECOVERABLE=YES|NO The HALDB is recoverable or not.

PARTITIONS=n Number of partitions that exist for thisHALDB.

Fields Present in a DB (PART) and Related RecordsA HALDB partition database record’s fields and their corresponding line numbersare described in Table 33.

Table 33. Fields Present in the DB (PART) Record

RecordType

LineNumber

Field Contents

DB (HALDBPartition)

1

2 DBD=dbdname Name of the HALDB partition.

MASTER DB=HALDBmaster name

Name of the HALDB master.

IRLMID=xxxxx Identifies the IRLM name. Thisfield is printed only when SHARELEVEL>=2.

CHANGE#=nnn The change version number isupdated when the definition of thepartition is changed.

TYPE=PART Indicates that a HALDB partition.

3 USID=n The highest update set identifierfor this partition.



Table 33. Fields Present in the DB (PART) Record (continued)

RecordType

LineNumber

Field Contents

AUTHORIZED USID=n The identifier of the current updateset being applied to the partition.

HARD USID=n The update set identifier of thelatest changes written to thepartition.

4 RECEIVE USID=n The update set identifier of the lastimage copy received for thispartition, which applies only toshadow databases at the trackingsite.

RECEIVE NEEDED USID=n The update set identifier thatindicates that image copies withthe identified USID are required forthe DBDSs marked “receiveneeded”, if n is not zero. It appliesonly to shadow databases at thetracking site.

5 DBRCVGRP=rcvgrpnm The name of the recovery group towhich this partition belongs, if any.Otherwise **NULL** is printed.

6-7 RANDOMIZER: NAME=ANCHOR= HIGH BLOCK#=BYTES=nnnnnnnn

Name of the randomizing moduleNumber of root anchor Maximumrelative block number value thatthe user wishes to allow arandomizing module to produce forthis DB. Maximum number of bytesof a DB record that can be storedinto the root addressable area in aseries of inserts unbroken by a callto another DB record.

8-9 FREE SPACE: FREEBLOCK FREQFACTOR=nnn FREE SPACEPERCENTAGE=nn

Specifies that every nth controlinterval or block in this data setgroup is left as free space duringDB load or reorganization.Specifies the minimum percentageof each control interval or blockthat is to be left as free space.

10a PARTITION HIGHKEY/STRING (CHAR):(LENGTH=NNN)

Printable and hexadecimal formatsof the partition high key/selectionstring. The key/string is paddedwith blanks, so the hexadecimalformat may contain extra x’40’characters beyond the length ofthe key/string (LENGTH= in line 10lists the actual key/string length).

10b PARTITION HIGHKEY/STRING (HEX):

Printable and hexadecimal formatsof the partition high key/selectionstring. The key/string is paddedwith blanks, so the hexadecimalformat may contain extra x’40’characters beyond the length ofthe key/string (LENGTH= in line 10lists the actual key/string length).




RecordType

LineNumber

Field Contents

11 OSAM BLOCK SIZE: s =nnnnn

OSAM block size is listed for eachdata set group member defined. sis the data set group identifier Athrough J.

12 FLAGS: COUNTERS: This heading line is printed forlines 7 through 14, which describethe status of this partition.

13 BACKOUTNEEDED=ON|OFF

This flag indicates whether thispartition needs backout by anysubsystem.

RECOVERY NEEDEDCOUNT=n

This counter is the number ofDBDSs associated with this database that need to be recovered.The printed output of the DBDSrecord indicates which DBDSsneed recovery.

14 READ ONLY=ON|OFF Indicates whether this partition canbe authorized for read processingonly, or authorized for read andupdate processing.

IMAGE COPY NEEDEDCOUNT=n

Count of how many DBDSsassociated with this partitionrequire an image copy or forwardrecovery. The printed output of theDBDS records indicates whichDBDSs require an image copy.

15 PROHIBITAUTHORIZATION=ON|OFF

This flag indicates whether thispartition is available forauthorization processing. If thepartition can be authorized, thevalue is OFF.

AUTHORIZEDSUBSYSTEMS=n

The count of subsystems that havecurrent authorization to thispartition.

16 HELD AUTHORIZATIONSTATE=n

The state derived by the databaseauthorization call process in IMS,representing the composite use ofthe partition by all currentlyauthorized subsystems. If n = 0,no subsystem is authorized to usethis partition. If n > 0, see the tablebelow for the subsystem encodedstate. If n > 128, online imagecopy (OLIC) is in progress for adata set of this partition.

17 DATABASE LEVELTRACK=YES|NO

Indicates the level of tracking forthe partition only for the HALDB iscovered by a GSG.. YES is printedfor readiness tracking. NOindicates recovery readinesstracking.




RecordType

LineNumber

Field Contents

EEQE COUNT=n Number of extended error queueelements for this partition.

18 TRACKINGSUSPENDED=YES|NO

Indicates whether tracking hasbeen suspended for this shadowdatabase.

RECEIVE REQUIREDCOUNT=n

Indicates how many of the DBDSs(for this shadow database) needimage copies from the active siteto be received.

19 OFR REQUIRED=YES|NO Indicates whether online forwardrecovery is required for thisshadow database.

20 PARTITION INITNEEDED=YES|NO

Indicates whether partitioninitialization is required for thisHALDB partition.

The following lines 15 through 17 are printed only when one or more subsystems arecurrently authorized to this partition:

21,22,23 ASSOCIATED SUBSYSTEMINFORMATION: -SSID--ACCESS INTENT-ENCODED -STATE- B/ONEEDED -COUNT- -SSROLE-

24-nnn ssidname The subsystem associated withthis authorization.


encoded state=n An internal value derived by IMS toindicate the subsystem’s intendeduse of the partition. The values ofn are as follows:

1. Read only

2. Read share

3. Multiple update

4. Read exclusive

5. Batch update

6. Single update

7. Exclusive

backout needed count Determines that the partition needsn backouts by this subsystem.

ACTIVE|TRACKING Role of authorized subsystem

Fields Present in a DB (Fast Path) RecordA Fast Path database record’s fields and their corresponding line numbers aredescribed in Table 34 on page 441.



Table 34. Fields Present in the DB (Fast Path) Record

RecordType


DB (FastPath)

1

2 DBD= dbdname Name of the database.

DMB#= nnn The value assigned when thisdatabase was registered.

TYPE= FP Indicates that the database beingused is a Fast Path DEDB.

3 SHARE LEVEL= n The level of data sharing for whichauthorized subsystems can share thisdatabase.

4 FLAGS: COUNTERS: This heading line is printed for lines 4through 6 describing status of thisdatabase.

5 RECOVERY NEEDEDCOUNT= n

This counter is the number of areadata sets, associated with thisdatabase, that need to be recovered.The printed output of the area dataset record indicates which area datasets need recovery.

6 IMAGE COPY NEEDEDCOUNT= n

Count of how many area data sets,associated with this database, requirean image copy or forward recovery.The printed output of the area dataset records indicates which area datasets require an image copy.


This flag indicates whether thisdatabase is available for authorizationprocessing. If the database can beauthorized, the value is OFF.

AUTHORIZED AREAS=n

The count of areas that are currentlyauthorized.

8 EEQE COUNT= n Number of extended error queueelements for this DEDB.

Fields Present in a DBDS (non-Fast Path) RecordA non-Fast Path database data set record’s fields and their corresponding linenumbers are described in Table 35.

Table 35. Fields Present in the DBDS (non-Fast Path) Record

RecordType


DBDS(non-FastPath)

1

2 DSN= dsname Data set name of the DBDS.

TYPE= IMS Indicates that this is a DBDS ratherthan a FP DEDB area.

Fields in DB (Fast Path) Record


Table 35. Fields Present in the DBDS (non-Fast Path) Record (continued)

RecordType


TYPE= PART Indicates that this is a DBDS of aHALDB partition.

3 DBD= dbdnameDDN= ddname

The database name and data setddname of the DBDS.

DSID= nn The data set ID number that appearsas part of the information in theDBDLIB data set about the DBDS.

DBORG= dbaseorgDSORG= dsetorg

The database and data setorganization, as defined for the DBDSin the DBDLIB data set.

4 CAGRP= cagrpnam The name of the CA group to whichthis DBDS belongs, if any. Otherwise,**NULL** is printed.

GENMAX= nnnn The maximum number of image copydata sets to be maintained for thisDBDS.

IC AVAIL= nnnnIC USED= nnnn

The number of available and in-useimage copy data sets for the DBDS.

DSSN= nnnn The data set synchronization numberthat is being used concurrently bysharing IMS subsystems. A DSSN isused to reflect the relative order inwhich changes are made to a DBDS.

5 REUSE | NOREUSE REUSE is printed if you havespecified in RECON that image copydata sets are to be reused for thisDBDS.

RECOVPD= nnn This is the recovery period of theimage copies.

The following fields in lines 6 through 11, identify the JCLPDS data set member names thatare to be used in order to generate IMS utility JCL for this DBDS:

6 DEFLTJCL= member The name of the PDS membercontaining the skeletal JCL defaultvalues for the user-defined keywordsthat are to be used for this DBDS.

ICJCL= member The name of the skeletal JCL PDSmember that is to be used in order togenerate JCL for the Database ImageCopy utility for this DBDS.

OICJCL= member The name of the skeletal JCL PDSmember that is to be used in order togenerate a job for the OnlineDatabase Image Copy utility for thisDBDS.

RECOVJCL= member The name of the skeletal JCL PDSmember that is to be used in order togenerate JCL for the DatabaseRecovery utility for this DBDS.

Fields in a DBDS (non-Fast Path) Record


Table 35. Fields Present in the DBDS (non-Fast Path) Record (continued)

RecordType


7 RECVJCL= member The name of the skeletal JCL PDSmember for which the DatabaseRecovery utility is to receive an imagecopy for this DBDS at an RSRtracking site.

8 FLAGS: COUNTERS: Heading for the following lines 9through 11, which describe the statusof this DBDS.

9 IC NEEDED= ON | OFF Indicates whether an image copyneeds to be taken for the DBDS.

10 IC RECOMMENDED=ON

Indicates that DBRC recommends animage copy of the DBDS should betaken before using the database.

11 RECOV NEEDED= ON |OFF

Indicates whether the DBDS needs tobe recovered.

12 RECEIVE NEEDED =ON | OFF

Indicates whether an image copy ofthis DBDS needs to be received atthe tracking site. This indicator is onlyapplicable in an RSR environment atthe RSR tracking site.

EEQE COUNT= n The number of extended error queueelements for this DBDS.

The following, lines 13 through 15, are printed only if one or more extended error queueelements exist.

13, 14 ERROR QUEUEELEMENTS:-EQERBA-EEQETYPE-SSID-

Heading for the following list ofextended error queue elements (lines14-nnn).

15-nnn eeqe rba The relative byte address (RBA) ofthe EEQE.

eeqe type The type of extended error queueelement.

ssid The ID of the subsystem that createdthe EEQE (in doubt EEQEs only).

Fields Present in a DBDS (Fast Path) RecordA Fast Path database data set record’s fields and their corresponding line numbersare described in Table 36.

Table 36. Fields Present in the DBDS (Fast Path) Record

RecordType


DBDS (FastPath)

1

2 DBD= dbdnameAREA= areaname

The database name and area nameof the Fast Path DEDB.

Fields in a DBDS (non-Fast Path) Record


Table 36. Fields Present in the DBDS (Fast Path) Record (continued)

RecordType


IRLMID= irlmname Identifies the IRLM when the sharelevel of this DEDB is 2. This field isprinted only when SHARE LEVEL=2.

TYPE= FP Identifies this database as a FastPath DEDB.

3 SHARE LEVEL= n The level of data sharing for whichauthorized subsystems can share thisarea.

DSID= nn The data set ID number that appearsas part of the information in theDBDLIB data set about the area dataset.

DBORG= dbaseorgDSORG= dsetorg

The database and data setorganization, as defined for the areadata set in the DBDLIB data set.

4 GSGNAME= gsgname Identifies the name of the GSG towhich this area belongs.

USID= n The highest update set identifier forthis area.

5 AUTHORIZED USID= n The identifier of the current updateset that is being applied to the area.

RECEIVE USID= n The update set identifier of the lastimage copy that was received for thisarea. The update set ID only appliesto shadow areas at the tracking site.

HARD USID= n The update set identifier of the latestchanges that were written to the area.

6 RECEIVE NEEDEDUSID= n

This only applies to shadow areas atthe tracking site. If n is not zero, thisindicates that an image copy with theidentified USID needs to be receivedfor this area.

7 CAGRP= cagrpnam The name of the CA group to whichthis area belongs, if any. Otherwise,**NULL** is printed.

GENMAX= nnnn The maximum number of image copydata sets to be maintained for thisarea.

IC AVAIL= nnnnIC USED= nnnn

The number of available image copydata sets, and the number of in-useimage copy data sets for the area.

DSSN= nnnn This is the data set synchronizationnumber that is being usedconcurrently by sharing IMSsubsystems. A DSSN is used toreflect the relative order in whichchanges are made to an area dataset.

Fields in a DBDS (Fast Path) Record



RecordType


8 REUSE | NOREUSE REUSE is printed if you havespecified in RECON that image copydata sets are to be reused for thisarea data set.

RECOVPD= nnn This is the recovery period of theimage copies.

VSO | NOVSO Indicates whether the area resides invirtual storage.

PREOPEN |NOPREOPEN

Indicates whether the area is openedat control region initialization or whenthe area is started.

PRELOAD |NOPRELOAD

Indicates whether the VSO area isloaded into the data space the nexttime it is opened.

9 CFSTR1= cfstr_name The name of the first coupling facilitystructure for the area.

CFSTR2= cfstr_name The name of the second couplingfacility structure for the area.

LKASID | NOLKASID Indicates whether local data cachingfor the specified area is used forbuffer lookaside on read requests.

10 DEFLTJCL= member The name of the member of thepartitioned data set that contains theskeletal JCL default values that are tobe used for the DEDB area.

ICJCL= member The name of the skeletal JCL PDSmember that is to be used in order togenerate the JCL for the DatabaseImage Copy utility for this area dataset.

RECVJCL= member The name of the skeletal JCL PDSmember for which the DatabaseRecovery utility is to receive an imagecopy for this area data set at an RSRtracking site.

RECOVJCL= member The name of the skeletal JCL PDSmember that is to be used in order togenerate the JCL for the DatabaseRecovery utility for this area data set.

11 FLAGS: COUNTERS: This heading line is printed for lines11 through 19 describing the status ofthis area.


The value of this flag is OFF if thearea is available for authorizationprocessing.

AUTHORIZEDSUBSYSTEMS= n

The count of subsystems that havecurrent authorization to this area.




RecordType


13 HELD AUTHORIZATIONSTATE= n

This is the state derived by thedatabase authorization call process inIMS. It represents the composite useof the database by all currentlyauthorized subsystems. If n= 0, nosubsystem is authorized to use thisdatabase. If n> 0, see the table belowfor the subsystem encoded state. Ifn> 128, block-level data sharing is ineffect. Subtract 128 to determine thetrue held authorization state.

14 IC NEEDED= ON | OFF Indicates whether an image copyneeds to be taken for the DEDB area.

ADS AVAIL #= n Indicates the number of availableADS in this area record.

15 IC RECOMMENDED=ON

Indicates that DBRC recommends animage copy of the area should betaken before it is used.

16 RECOV NEEDED= ON |OFF

Indicates whether the areasassociated with the DEDB should berecovered.

REGISTERED ADS #= n Indicates how many area data setsfor this area are registered inRECON.

17 DATABASE LEVELTRACK = YES | NO

Indicates the level of tracking for thearea. YES is printed fordatabase-readiness tracking. NOindicates recovery-readiness tracking.This is listed only if the area iscontained in a GSG.

EEQE COUNT= n The number of extended error queueelements for this DEDB area.

18 RECEIVE NEEDED =ON | OFF

Indicates whether an image copy ofthis area needs to be received at thetracking site. This indicator is onlyapplicable in an RSR environment atthe RSR tracking site.

19 OFR REQUIRED= YES |NO

Indicates whether online forwardrecovery is required for this shadowarea.

20 TRACKINGSUSPENDED= YES | NO

Indicates whether tracking has beensuspended for this shadow area.

21 HSSP CIC INPROGRESS= YES | NO

Indicates whether an HSSPconcurrent image copy is in progress.

The following lines, 22 through 24, are printed only if one or more error queue elementsexist.

2223

ERROR QUEUEELEMENTS:-EQERBA-EEQETYPE-SSID-

Heading for the following list of errorqueue elements.




RecordType


24-nnn eeqe rba The type of extended error queueelement.

eeqe type The type of extended error queueelement.

ssid The ID of the subsystem that createdthe EEQE (in doubt EEQEs only).

If the number of registered area data sets is not zero, the following lines 25 through 27 listthose area data sets that are currently registered in this area record:

252627

ADS LIST: -ADS DDN--ADS DSN- -STAT-CREATE -RUNNING-

These lines, 25 through 27, representthe column headings for the followingline 28.

The following line (28) is repeated for each area data set that is registered for this area.

28-nn adsddn adsdsnAVAIL | UNAVAILYES | NO

AVAIL indicates that the area data setis available. UNAVAIL indicates thatthe area data set is unavailable. YESindicates that the area data set isbeing used. NO indicates that thearea data set is not being used.

The following lines nn+1 through nn+3,are printed only when one or more subsystems arecurrently authorized to this area:

nn+1 nn+2nn+3

ASSOCIATEDSUBSYSTEMINFORMATION -SSID--ACCESS INTENT-ENCODED -STATE- -SSROLE-

Lines nn+1 through nn+3 representthe column headings for the followinglines nn+3-mm.

The following line nn+3-mm, is repeated for each subsystem that has authorization for thisdatabase.

nn+3-mm ssidname The subsystem associated with thisauthorization.


encoded state= n An internal value derived by IMS toindicate the subsystem’s intended useof the database. The values of n areas follows: 1 - Read only 2 - Readshare 3 - Multiple update 4 - Readexclusive 5 - Batch update 6 - Singleupdate 7 - Exclusive

ACTIVE | TRACKING Role of the authorized subsystem.

Fields Present in an ALLOC RecordAn allocation record’s fields and their corresponding line numbers are described inTable 37 on page 448.



Table 37. Fields Present in the ALLOC Record

RecordType


ALLOC 1

2 ALLOC= timestamp* The time stamp for a time that theDBDS was allocated during the run ofan IMS system. An asterisk (*)indicates that it is part of the recordkey.

ALLOC LRID= n The log record sequence number ofthe begin update log record. Thevalue for n is 0 for ALLOC recordsthat are created at the active site.

3 DSSN= nnnn This is the data set synchronizationnumber that is being concurrentlyused by sharing IMS subsystems. ADSSN is used to reflect the relativeorder in which changes are made to aDBDS or area.

USID= n The update set identifier. An updateset is a collection of updates that aremade to the database or area while itis continuously updated by one ormore IMS subsystems.

START= timestamp The start time of the log data set thatwas logging change records whenthis DBDS was allocated.

4 DEALLOC= timestamp The time stamp of a specificdeallocation. This field is printed onlyif a specific deallocation time is in therecord. If the DBDS was allowed toremain allocated to the closing of thelog data set, this line is not printed.

DEALLOC LRID= n The log record sequence number ofthe end-update log record. This fieldis only printed if a specificdeallocation time exists.

5 TRACKINGSUSPENDED ATRECORD: suspend lridTRACKINGSUSPENDED NORECORDS APPLIED

This will only be printed for shadowdatabases that are being tracked atthe tracking site. The suspend lridindicates the current tracking logposition.

Fields Present in an IMAGE RecordAn image record’s fields and their corresponding line numbers are described inTable 38.

Table 38. Fields Present in the IMAGE Record

RecordType


IMAGE 1

Fields in an ALLOC Record


Table 38. Fields Present in the IMAGE Record (continued)

RecordType


2 * The asterisk (*) is printed to the left ofthe record type only if the image copydata sets that are defined in thisrecord are available for the first timefor future use (they have never beenused before).

CREATE | RUN=timestamp*

CREATE is printed if the image copydata set has never been used.Otherwise, RUN is printed. RUN isthe time stamp of the start ofprocessing of the database imagecopy utilities that used this imagecopy data set. The asterisk (*)indicates that the time stamp is partof the key of this record.

RECORD COUNT=nnnnnnnn

The number of records contained inthe image copy data set. This field isprinted only for in-use image copydata sets; it does not apply tononstandard or system managedstorage image copy data sets.

USER IC This is printed for any nonstandardimage copy.

USID= n This is only listed here for anonstandard image copy.

3 USERDATA= cccccccc... This line is printed in this format for anonstandard image copy data set.The characters following USERDATA=comprise the character string youkept in the record to describe thenonstandard image copy data set.

STOP=timestamp

This field contains either zeros or thestop time of an Online DatabaseImage Copy utility run. This fieldapplies to standard image copy datasets, but is not printed for availableimage copy data sets.

ONLINE | BATCH |CONCUR | SMSCIC |SMSNOCIC

This field indicates the type of imagecopy. ONLINE indicates that thisimage copy was produced by anonline database image copy utility.BATCH indicates a batch image copyfrom the Database Image Copy utility.CONCUR indicates that a concurrentimage copy was run. SMSCICindicates that a system managedstorage image copy was run withshared access. SMSNOCIC indicatesthat an SMS image copy was run withexclusive access.

This field applies to standard imagecopy data sets, but is not printed foravailable image copy data sets.

Fields in an IMAGE Record


Table 38. Fields Present in the IMAGE Record (continued)

RecordType


USID= n This is only listed here for a standardimage copy. This is the value of theupdate set identifier of the databaseor area when the image copy wastaken.

4 IN PROGRESS This line is listed when an HSSPconcurrent image copy is currently inprogress.

5 IC1 | IC2 IC1 and accompanying lines arealways printed, followed by IC2 andaccompanying lines, if a duplicateimage copy data set exists.

6 DSN= ic-dsname ic-dsname is the data set name ofthis image copy data set (IC1 or IC2).

FILE SEQ= nnnn The file sequence number of theimage copy data set on the firstvolume on which it resides. This fieldis listed for non-HSSP image copiesonly.

7 UNIT= unittype Unit type to be used for substitutionduring the GENJCL process. This fieldis listed for non-HSSP image copiesonly.

ERR | EMP ERR is printed if you have indicatedthat the image copy data set is not tobe used as input to future utility runs.EMP is printed only for duplicateimage copy data sets that have notbeen used, even though theircorresponding image copy data sethas been used.

VOLS DEF= nnnnVOLS USED= nnnn

The number of volumes that havebeen specified for use by this imagecopy data set and the number ofvolumes that have been used tocreate the data set. The VOLS USEDvalue might be less than the specifiedVOLS DEF. For available image copydata sets, the VOLS USED value is 0.

This field is listed for non-HSSPimage copies only.

8-nn VOLSER= volser,... A list of the volume serial numbers ofvolumes that contain the image copydata set. this field is listed fornon-HSSP image copies only.

Fields Present in a REORG RecordA reorganization record’s fields and their corresponding line numbers are describedin Table 39 on page 451.

Fields in an IMAGE Record


Table 39. Fields Present in the REORG Record

RecordType


REORG 1

2 RUN= timestamp* The time stamp you have supplied forthe time at which a reorganizationoccurred for this DBDS. An asterisk(*) indicates that the time stamp ispart of the key of this record.

USID= n This is the value of the update setidentifier of the database or areawhen the reorganization of this DBDSoccurred.

Fields Present in a RECOV RecordA recovery record’s fields and their corresponding line numbers are described inTable 40.

Table 40. Fields Present in the RECOV Record

RecordType


RECOV 1

2 RUN= timestamp* The time stamp of a DatabaseRecovery utility run for this DBDS.The asterisk (*) indicates that the timestamp is part of the key of this record.

RUN USID= n Listed only if a time stamp recovery isbeing described. This identifies theupdate set identifier of the DBDSwhen the Database Recovery utilitywas run.

3 RECOV TO= timestamp This field indicates that a time stamprecovery is being described. The timestamp recovery restored the DBDS tothe state it was in at the timerepresented by the time stamp.

RECOV TO USID= n Listed only if a time stamp recovery isbeing described. This identifies theupdate set identifier of the DBDS atthe time to which the DBDS wasrestored.

Fields in a REORG Record


Fields in a RECOV Record


Appendix D. Considering IMS DBRC RECON Data SetPlacement

This appendix consists of recommendations for the placement of the IMS DBRCRECON data sets. Shared DASD considerations and the use of GRS (GlobalResource Serialization) are also discussed.

The RECON data sets consist of three VSAM KSDSs. These data sets can beconsidered to be among the most important IMS system data sets in an installation,since they are required to control the recovery of registered data base data sets,and also required to control logging and system restart operations for IMS DC andDBCTL environments. Also, since multiple IMS subsystems can share the same setof RECONs, the loss of the RECON data sets could impact multiple IMSsubsystems.

The RECON data sets are managed with a ″pair and a spare″ concept. There aretwo active KSDSs and a spare KSDS that is used when one of the active RECONdata sets is lost (DBRC automatically copies the remaining good copy to the sparein order to maintain dual processing). In this situation the loss of one of theRECONs in a RECON set of data sets is not a major problem. However, theconcurrent loss of both active RECON KSDSs in a RECON set of data setsnegatively impacts IMS system availability.

To avoid losing both active RECONs at the same time, it is generally recommendedthat any common points of failure for a set of RECONs be eliminated. In particular,for a given set of RECONs:

1. Place each of the RECON data sets on a separate device and string. Inaddition, make sure that a control unit, channel, or director failure does notcause the only path to multiple RECON data sets to be lost.

2. Catalog each of the RECON data sets in unique (separate) catalogs and makesure that the catalogs are on separate devices (preferably, the same device asthe RECON data set). This ensures that a catalog failure does not causemultiple RECONs in the RECON set of data sets to be lost.

The RECON data sets can be shared across multiple IMS systems on multipleprocessors or MVS images. When an IMS subsystem accesses the RECONs,DBRC issues reserves against the RECONs to maintain integrity. While all threeRECON data sets are not always reserved, the data sets that are reserved arereserved in DD name (RECON1, RECON2, RECON3) sequence.

These reserves can be either hardware reserves or can be converted to softwarereserves (SYSTEMS ENQs) by GRS. If hardware reserves are used, then one mustallocate the RECON data sets, in a shared DASD environment, carefully to avoidshared DASD deadlocks or intolerable contention with other data sets that might beon the same volumes as the RECONs. Note that hardware reserves lock outaccess to the entire volume from other CPUs or MVS images.

Shared DASD hardware reserve deadlocks can be avoided by ensuring that:

1. The catalog (BCS) used for a RECON data set is on the same volume as theRECON data set.

2. There are no catalogs (BCS) on a RECON volume that point to VSAM data setson another RECON volume.


3. If multiple sets of RECONs (RECON set A and RECON set B) exist and youwish to share DASD volumes for the multiple sets (use 3 volumes rather than n* 3 volumes), all of the RECON1 data sets from the multiple RECON sets areon one volume, all of the RECON2 data sets are on the second volume, and allof the RECON3 data sets are on the third volume.

Implementing the above recommendations should greatly reduce all known sharedDASD hardware reserve deadlock exposures involving the RECON data sets.

GRS can be used to convert reserve requests from hardware reserves toSYSTEMS ENQ requests and to then propagate the SYSTEMS ENQ request to allCPUs or MVS images in the sharing Sysplex. When this facility is used, the entirevolume is not locked out from access by other CPUs or MVS images; only thelogical resource (the particular RECON data set in the case of DBRC) is serialized.

So, in a GRS environment, the reserve requests issued by DBRC do not preventaccess from other CPUs or MVS images to other data sets that might reside on theRECON volumes. In addition, by using the GRS conversion of RECON reserves,you eliminate any potential DBRC reserve deadlock situations, even when theprevious recommendations are not followed.

The use of GRS is not without overhead. It takes longer for a ″software″ (GRSconverted) reserve to be processed than it takes for a hardware reserve to beprocessed. The amount of elapsed time increase varies by the number of CPUs orMVS images in the Sysplex and installation specified tuning parameters. Using anexample in MVS/ESA Planning: Global Resource Serialization for MVS/SP Version3 the average amount of increase for a 4-processor Sysplex would vary from 7 to12 milliseconds. Most invocations of DBRC only reserve the active pair of RECONs(two reserves) so this time must be doubled (occasionally tripled when the spare isalso reserved). Therefore, the use of GRS to convert the DBRC RECON reserveswould typically add less than 25 milliseconds (about one random I/O) to theduration of an IMS DBRC operation.

Since this increase is probably much less than 10 percent when compared to theduration of an IMS DBRC operation, the potential negative performance impact ofGRS usage should not be a serious consideration for most IMS DBRC users,especially when the positive performance impacts (entire volume no longer held)considered. However, environments could exist where there is an extremely highdegree of contention among multiple IMS subsystems for the RECON data sets. Inthese environments, the negative performance impact of GRS usage could benoticeable.

The GRS manual (referenced earlier) should be consulted for additional informationregarding the implementation, usage, and tuning considerations for GRS.


Bibliography

This bibliography includes all the publications citedin this book, including the publications in the IMSlibrary.

v CICS/ESA-CICS IMS Database Control Guide

v CICS/ESA-CICS Supplied Transactions

v MVS/DFP V3R3 System Program ReferenceManual

v MVS/ESA System Programming Library:Application Development Guide

v OS/390 MVS Planning: Global ResourceSerialization

v OS/390 MVS Programming: AuthorizedAssembler Services Reference

IMS Version 7 Library

SC26-9419 ADB Administration Guide:Database Manager

SC26-9420 AS Administration Guide: SystemSC26-9421 ATM Administration Guide:

Transaction ManagerSC26-9422 APDB Application Programming:

Database ManagerSC26-9423 APDG Application Programming:

Design GuideSC26-9424 APCICS Application Programming:

EXEC DLI Commands forCICS and IMS

SC26-9425 APTM Application Programming:Transaction Manager

SC26-9427 CG Customization GuideSC26-9426 CQS Common Queue Server and

Base Primitive EnvironmentGuide and Reference

SC26-9436 CR Command ReferenceSC26-9428 DBRC DBRC Guide and ReferenceLY37-3738 DGR Diagnosis Guide and

ReferenceLY37-3739 FAST Failure Analysis Structure

Tables (FAST) for DumpAnalysis

SC27-0832 IJUG IMS Java User’s GuideGC26-9429 IIV Installation Volume 1:

Installation and VerificationGC26-9430 ISDT Installation Volume 2:

System Definition andTailoring

SC26-9432 MIG Master Index and GlossaryGC26-9433 MC1 Messages and CodesGC26-1120 MC2 Messages and Codes,

Volume 2

SC26-9434 OTMA Open Transaction ManagerAccess

SC26-9435 OG Operations GuideGC26-9437 RPG Release Planning GuideSC26-9438 SOP Sample Operating

ProceduresSC26-9440 URDBTM Utilities Reference: Database

and Transaction ManagerSC26-9441 URS Utilities Reference: System

Supplementary PublicationsGC26-9431 LPS Licensed Program

SpecificationsSC26-9439 SOC Summary of Operator

Commands

Online Softcopy PublicationsLK3T-3526 CDROM IMS Version 7 Softcopy LibrarySK2T-0730 CDROM IBM Online Library: Transaction

Processing and DataSK2T-6700 CDROM OS/390 Collection



Index

Special Characters%ALLDSSN keyword 328%ALLSEL keyword 328%ALLTIME keyword 328%ALLUSID keyword 328%CADSN keyword 327%CAFSEQ keyword 327%CALGTM keyword 327%CAODSN keyword 318%CASEL keyword 327%CATIME keyword 327%CAUNIT keyword 327%CAVCNT keyword 327%CAVOLS keyword 327%COPIES keyword 354%DALTIME keyword 328%DBADSAV keyword 329%DBADSN keyword 329%DBDDN keyword 328, 329%DBDSN keyword 329%DBDSNRV keyword 329%DBDSSEL keyword 329%DBNAME keyword 328, 329%DBTYPE keyword 329%DBUSID keyword 329%DDNAME keyword 315%DELETE keyword 313, 317%ENDDEL keyword 313, 317%ENDSEL keyword 313, 314%IC2DSN keyword 326%IC2FSEQ keyword 326%IC2SEL keyword 326%IC2UNIT keyword 326%IC2VCNT keyword 326%IC2VOLS keyword 326%ICCAT keyword 326%ICDSN keyword 325%ICDSN2 keyword 354%ICDSN3 keyword 354%ICDSN4 keyword 354%ICFSEQ keyword 325%ICSEL keyword 325%ICSTOP keyword 325%ICTIME keyword 325%ICTYPE keyword 325%ICUNIT keyword 325%ICUNIT2 keyword 354%ICUNIT3 keyword 354%ICUNIT4 keyword 354%ICUSID keyword 326%ICVCNT keyword 326%ICVCNT2 keyword 354%ICVCNT3 keyword 354%ICVCNT4 keyword 354%ICVOLS keyword 326%ICVOLS2 keyword 354%ICVOLS3 keyword 354

%ICVOLS4 keyword 354%LOGDSN keyword 324%LOGETIM keyword 324%LOGFRID keyword 324%LOGFSEQ keyword 324%LOGLRID keyword 325%LOGMERG keyword 324%LOGONL keyword 324%LOGRMT keyword 324%LOGSEL keyword 324%LOGSTIM keyword 324%LOGUNIT keyword 324%LOGVOLS keyword 324%OLDCTIM keyword 321%OLDFRID keyword 321%OLDLRID keyword 321%OLDOTIM keyword 321%OLDSDDN keyword 320%OLDSDSN keyword 320%OLDSSEL keyword 321%OLDSTYP keyword 321%PLGTIME keyword 328%SELECT keyword 321

description 314specifying the record types 315specifying the syntax 320, 329

%SET MEMBER keyword 313, 318%SET TIMEFMT keyword 313, 318%SLDETIM keyword 322%SLDFRID keyword 322%SLDFSEQ keyword 322%SLDLRID keyword 322%SLDRMT keyword 322%SLDSDDN keyword 322%SLDSSEL keyword 322%SLDSTIM keyword 322%SLDUNIT keyword 322%SLDVOLS keyword 322%SSID keyword 312%TIME keyword 312/DBDUMP command 27/GENJCL command, generating JCL 9/NRESTART command

INIT.DB 225restart after IMS failure 42

/REPRO commandrestoring RECONs 68using for backup 64

/RMGENJCL commandgenerating JCL 9

/RMxxxxxx commandsyntax diagram 110

/START commanduse of 20, 212


AABNORMAL parameter commands

CHANGE.SUBSYS 168NOTIFY.SUBSYS 299

access method services (AMS) 64, 68ACTIVE parameter

CHANGE.DB command 125ADD parameter

CHANGE.CAGRP command 118ADDDB parameter

CHANGE.DBDSGRP command 133ADDEQE parameter

CHANGE.DBDS command 127adding information to the RECON

allocation or deallocation 263backout records 264Database Change Accumulation utility 265database data set or area recovery 283database reorganization 285image copy 268nonstandard image copy data sets 299primary online log data set 271primary recovery log data set 274primary system log data set 279secondary online log data set 288secondary recovery log data set 291secondary system log data set 294subsystem 298tracking subsystem log data set 279

ADDMEM parameterCHANGE.DBDSGRP command 133

ADDN parameter commandsCHANGE.ADS 113DELETE.ADS 171INIT.ADS 221NOTIFY.RECOV 283

ADDNNEW parameterCHANGE.ADS command 113

ADSN parameter commandsCHANGE.ADS 113INIT.ADS 221

ALL parametercommands

CHANGE.DB 121CHANGE.SUBSYS 168GENJCL.ARCHIVE 185LIST.BKOUT 245LIST.CAGRP 246LIST.DB 247LIST.DBDSGRP 250LIST.SUBSYS 260

description 121allocation

changes to processing 19database record 63DBRC RECONs 45log record 63

ALLTIME parameterNOTIFY.ALLOC command 263

AMS 64, 68

analyzing requirements for data sharing, assigning asharing level with DBRC 20

ARCHIVE, GENJCLarchiving OLDS 13

ARCHIVED parameterCHANGE.PRILOG (for OLDS) command 137

archivingonline log data sets, DBRC 13

ARCHJCL skeletal JCL execution member 340AREA parameter

commandsCHANGE.ADS 113CHANGE.DBDS 127CHANGE.IC 135CHANGE.UIC 170DELETE.ADS 171DELETE.ALLOC 172DELETE.DBDS 175DELETE.IC 177DELETE.RECOV 181DELETE.UIC 184GENJCL.IC 197GENJCL.OIC 204GENJCL.RECEIVE 208GENJCL.RECOV 212INIT.ADS 221INIT.DBDS 227INIT.IC 234LIST.DBDS 249LIST.HISTORY 253NOTIFY.ALLOC 263NOTIFY.IC 269NOTIFY.RECOV 283NOTIFY.UIC 300

defining a data set 221deleting information from RECON 171

AREANEW parameterCHANGE.DBDS command 128

ARNEEDED parameterCHANGE.PRILOG (for OLDS) command 137

ARSCHED parameterCHANGE.PRILOG (for OLDS) command 137

ARSTART parameterCHANGE.PRILOG (for OLDS) command 137

assigning a sharing level with DBRC 20authorization, changing database 86authorization commands

CHANGE.DB 121, 122CHANGE.DBDS 126, 128

AVAIL parameter commandsCHANGE.ADS 113CHANGE.PRILOG (for OLDS) 137CHANGE.SECLOG (for OLDS) 156, 157INIT.ADS 221

BBACKIRLM parameter commands


backout, BACKOUT record for recovery 58


backout, with data sharingbatch 40dynamic 40

BACKOUT parameterCHANGE.DB command 122

backupcreating a copy of RECON 111database 25

command for 26description 25RECON 64

BACKUP.RECON command 64description 111example 111parameters

BOTH 111RECON1 111RECON2 111

batch backout utility 40, 43adding backout records to RECON 264changing backout records in RECON 114deleting from RECON 172limitations 41SSID naming convention 85

batch environmentcommand

LIST.SUBSYS 260NOTIFY.SUBSYS 299NOTIFY.SUBSYS command 298

BKO (backout) parameter commandsCHANGE.BKOUT 115NOTIFY.BKOUT 265

BOTH parameterBACKUP.RECON command 111

CCADSN parameter commands

CHANGE.CA 116INIT.CA 222NOTIFY.CA 266

CAJCL parametercommands

CHANGE.CAGRP 118INIT.CAGRP 224

skeletal JCL execution member 346calls from IMS to DBRC, elements of DBRC 6catalog management of data sets in RECON 89CATDS parameter commands

CHANGE.RECON 148INIT.RECON 239

category of recordslisting records 255

CATIME parameterGENJCL.CA command 191

CFSTR1 parameter CHANGE.DBDS command 127,230

CFSTR2 parameter CHANGE.DBDS command 128,230

change accumulationdata set

defining 222naming convention 22selecting 326

groupchanging information in the RECON 118defining 37, 223defining for future use 37deleting information from RECON 174listing 245reusing 37using 18

recordgroup 58run 58

stops processing logs, when 86change accumulation says nothing to process,

when 86change accumulation stops processing logs, when 86CHANGE.ADS command 113CHANGE.BKOUT command 114CHANGE.CA command 116CHANGE.CAGRP command 118CHANGE.DB command 121CHANGE.DBDS command 126CHANGE.DBDSGRP 18CHANGE.DBDSGRP command 132CHANGE.IC command 134CHANGE.PRILOG 14CHANGE.PRILOG command

changing RECON log control records 13for OLDS 137for RLDS 139for SLDS 143for TSLDS 143

CHANGE.RECON command 14, 148allocating space for RECONs 50recovering RECONs 68reorganizing RECON 66

CHANGE.RECON command (for THT orREPTHT) 156

CHANGE.SECLOG command 14changing RECON log control records 13for OLDS 156for RLDS 158for SLDS 162for TSLDS 162

CHANGE.SG command 167CHANGE.SUBSYS command 168CHANGE.UIC command 170changes in allocation and deallocation 19changing information

area data set 113backout records 114CA group record 118database 121database change accumulation utility 116DBDS 126DBDSGRP 132IC data set 134

Index 459

changing information (continued)nonstandard image copy data set 170primary online log data set 137primary RLDS 139primary SLDS 143primary TSLDS 143RECON header record 148RECON header record (for THT or REPTHT) 156secondary online log data set 156secondary RLDS 158secondary SLDS and TSLDS 162secondary subsystem entry 168service group 167

CHECK17 parameter commandsCHANGE.RECON 150INIT.RECON 240

CHECK44 parameter commandsCHANGE.RECON 150INIT.RECON 240

CHKINT parameter GENJCL.OIC command 204CHKPTCT parameter commands

CHANGE.PRILOG (for RLDS) 140CHANGE.PRILOG (for SLDS) 144CHANGE.SECLOG (for RLDS) 159CHANGE.SECLOG (for SLDS) 163NOTIFY.PRILOG (for RLDS) 276NOTIFY.PRILOG (for SLDS and TSLDS) 280NOTIFY.SECLOG (for RLDS) 292NOTIFY.SECLOG (for SLDS) 296

CIC (concurrent image copy) 197CIC parameter

commandsGENJCL.IC 197NOTIFY.IC 269

for online image copy 28CIC parameter, commands

GENJCL.IC 197NOTIFY.IC 269

cold startcommands

CHANGE.BKOUT 114DELETE.BKOUT 172LIST.BKOUT 245

multiple in a test environment 90command 110

/DBDUMP database backup copies 27/ERESTART

restart after DBRC failure 42restart after IMS failure 42

/GENJCL 9/NRESTART, restart after IMS failure 42/REPRO 64, 68/RMGENJCL 9/START 20, 212BACKUP.RECON 64CHANGE.PRILOG 13CHANGE.RECON 50CHANGE.RECON, recovering RECONs 68CHANGE.SECLOG 13DELETE.LOG 66GENJCL.ARCHIVE 13, 14

command 110 (continued)GENMAX 17INIT.ADS 12INIT.CAGRP 17INIT.DB 12INIT.DBDS 12, 17INIT.RECON 46INIT.RECON, establishing RECONs for log

control 11INIT.RECON, recovering RECONs 68NOTIFY.UIC 17valid DBRC log related commands 14

command syntax 110comment 100continuation characters 100DBRC 99definition 100description for DBRC utility 99notational conventions 107parameters 100separators 100

COMP parameter commandsCHANGE.CA 117NOTIFY.CA 267

complex expressions 317compression

PRILOG 65, 82concurrent image copy (CIC)

CIC parameter 197database backup copies 28registered database with DBRC 17

considerationswhen using DBRC 12

contention, avoiding RECON 46control group, skeletal JCL 313control keywords, skeletal JCL 313, 329CONTROLINTERVALSIZE keyword 50COPIES parameter commands

GENJCL.IC 197GENJCL.OIC 204

coupling facility structures (CFSTR1 | 2) 230CURRENT parameter commands

NOTIFY.RECOV 283NOTIFY.REORG 286NOTIFY.UIC 300

CYLINDERS keyword 50

Ddamaged RECON 67DASDUNIT parameter commands


data set allocation, DBRC RECONcreating a RECON 50shared among multiple processors 47

data set reorganization, RECON, to increase max.RECORDSIZE 87

data sets, RECON 45data sharing 20

assigning a sharing level with DBRC 20


data sharing 20 (continued)batch backout 40dynamic backout 40forward recovery 41information in RECON 20levels of 20

block level 20database level 20

merging logs 37planning recovery procedures 39record 64

databaseadding information to RECON 285allocation record 63authorization, changing 86backup 25, 33

commands for 26changing information 121data set, changing information 126data set groups, changing information 132defining 225deleting information from RECON 174listing 247making HISAM copies 31making image copies 26open exit 19record 59

database allocation record 63Database Change Accumulation utility 33Database Change Accumulation utility (DFSUCUM0)

CA groupdefining 37defining for future use 37reusing 37

commandsBACKUP.RECON 111CHANGE.ADS 113CHANGE.BKOUT 114CHANGE.CA 116CHANGE.CAGRP 118CHANGE.DBDSGRP 132CHANGE.IC 134CHANGE.PRILOG (for OLDS) 137CHANGE.PRILOG (for RLDS) 139CHANGE.PRILOG (for SLDS) 143CHANGE.PRILOG (for TSLDS) 143CHANGE.RECON 148CHANGE.RECON (for THT or REPTHT) 156CHANGE.SECLOG (for OLDS) 156CHANGE.SECLOG (for RLDS) 158CHANGE.SECLOG (for SLDS and TSLDS) 162CHANGE.SG 167CHANGE.SUBSYS 168CHANGE.UIC 170DELETE.ADS 171DELETE.ALLOC 171DELETE.BKOUT 172DELETE.CA 173DELETE.CAGRP 174DELETE.DB 174DELETE.DBDS 175

Database Change Accumulation utility (DFSUCUM0)(continued)

commands (continued)DELETE.DBDSGRP 175DELETE.GSG 176DELETE.IC 177DELETE.LOG (for OLDS) 177DELETE.LOG (for RLDS) 178DELETE.LOG (for SLDS) 178DELETE.RECOV 181DELETE.REORG 182DELETE.SG 182DELETE.SUBSYS 183DELETE.UIC 184GENJCL.ARCHIVE 185GENJCL.CA 189GENJCL.CLOSE 193GENJCL.IC 195GENJCL.OIC 202GENJCL.RECEIVE 207GENJCL.RECOV 211GENJCL.USER 216INIT.ADS 221INIT.CA 222INIT.CAGRP 223INIT.DB 225INIT.DBDS 227INIT.DBDSGRP 231INIT.GSG 233INIT.IC 233INIT.RECON 239INIT.SG 243LIST.BKOUT 245LIST.CAGRP 245LIST.DB 247LIST.DBDS 248LIST.DBDSGRP 250LIST.GSG 251LIST.HISTORY 252LIST.LOG (for a category of records) 255LIST.LOG (for a PRILOG family) 254LIST.RECON 258NOTIFY.ALLOC 263NOTIFY.BKOUT 264NOTIFY.CA 265NOTIFY.IC 268NOTIFY.PRILOG (for OLDS) 271NOTIFY.PRILOG (for RLDS) 274NOTIFY.PRILOG (for SLDS and TSLDS) 279NOTIFY.RECOV 283NOTIFY.REORG 285NOTIFY.SECLOG (for OLDS) 288NOTIFY.SECLOG (for RLDS) 291NOTIFY.SECLOG (for SLDS) 294NOTIFY.UIC 299RESET.GSG 303

description 33execution recorded by DBRC 17input 36subset of log volumes 36valid log subset with DBRC 37

Index 461

database change accumulation utility JCLadding information to RECON 265changing information about a run 116deleting information from RECON 173generating a job 189skeletal JCL 346

database data set record 59Database Image Copy 2 utility (DFSUDMT0) 17, 27Database Image Copy utility (DFSUDMP0) 27

adding information to RECON 268creating data sets for future use 29description 26execution recorded by DBRC 17generating a job 195maximum number of generations 30nonstandard image copy data sets 32recovery period 30reusing image copy data sets 30skeletal JCL 351

database recovery controlchanging information 134data set, creating a backup copy 111

Database Recovery Control utility (DSPURX00)generating a job 211, 216GENJCL.RECOV command 211overview 75

database recovery records 57database recovery with data sharing

batch 40data sharing 42dynamic 40forward 41managing system logs 37

DB, INIT commanddefining databases 12

DB header recordHALDB 60

DB partitionHALDB 61

DBD parameter commandsCHANGE.ADS 113CHANGE.BKOUT 115CHANGE.DB 121CHANGE.DBDS 127CHANGE.IC 135CHANGE.UIC 170DELETE.ADS 171DELETE.ALLOC 172DELETE.DB 174DELETE.DBDS 175DELETE.IC 177DELETE.RECOV 181DELETE.REORG 182DELETE.UIC 184GENJCL.IC 197GENJCL.OIC 203GENJCL.RECEIVE 208GENJCL.RECOV 212GENJCL.USER 217INIT.ADS 221INIT.DB 225

DBD parameter commands (continued)INIT.DBDS 227INIT.IC 234LIST.DB 247LIST.DBDS 248LIST.HISTORY 252NOTIFY.ALLOC 263NOTIFY.BKOUT 265NOTIFY.IC 268NOTIFY.RECOV 283NOTIFY.REORG 286NOTIFY.UIC 300

DBDS (database data set)commands 212

GENJCL.RECOV 212LIST.DB 248NOTIFY.RECOV 284

defining 227listing 248qualifier 316RECON, deleting information from 175, 177selecting DBDS records 327, 328

DBDS (database data set) groupdefining 231deleting information from RECON 175LIST command 250record 59using 18

DBDS, INIT commanddefining databases 12

DBDS, INIT.DBDS commandspecifying image copy requirements 17

DBRC (Database Recovery Control) 75active and spare RECON 54assigning a sharing level 20authorization, changing database 86calls from IMS 6catalog management of data sets 89change accumulation says nothing to process,

when 86change accumulation stops processing logs,

when 86closing an open online PRILOG 83commands 99

INIT.CA 37INIT.CAGRP 37

components 6controlling database recovery 14, 15, 23data sets

defining recovery requirements 14partitioned 7RECON 6, 45, 65SSYS record 64

database backup 25Concurrent Image Copy 28controlling the number of image copies

managed 29creating image copy data sets for future use 29Database Image Copy (DFSUDMP0) 27Database Image Copy 2 (DFSUDMT0) 27guidelines 32


DBRC (Database Recovery Control) 75 (continued)HISAM copies 31methods 25Online Database Image Copy (DFSUICP0) 28recovering a database 38recovery period of image copy data sets and

GENMAX 30reusing image copy data sets 30

DBRC components 6DBRC log control 13DBRC online command syntax 110DBRC parameter

IMSCTRL macro 10DBRC procedure 11description 13generating JCL 8GENMAX, resetting 80IMS procedures and 11initial RECON access 54initialization 10initializing the RECON 11log control 13log data sets 50log records, deleting 84maintaining RECON records 65notifying that log data sets have moved 87overview 5parameters

IMS.PROCLIB execution parameter 11partitioned data set members 7RECON

creating a RECON 50shared among multiple processors 47

RECON, defining recovery requirements 14RECON, registering databases in 12recording change accumulations 17recording image copies 17Recovery Control utility 7recovery-related information 7

recording 8recovery utilities 7share control 20SLDS stop time, locating the last in RECON 79specifying when it is to be used 10subsystem (SSYS) records 84system, considerations for a 25tailoring JCL 14time stamp 101tips 79using DBRC with batch jobs 10variables 50what is it 5when should you use it 10

DBRC (Database Recovery Control) commandsDatabase Recovery Control utility (DSPURX00) 7RECON Upgrade utility (DSPURU00) 7

DBRC online/RMGENJCL command syntax 110/RMINIT command 110/RMNOTIFY 110

DBTRACK parameterCHANGE.DB command 123CHANGE.DBDS command 131

DDN parameter commandsCHANGE.DBDS 127CHANGE.IC 135CHANGE.UIC 170DELETE.ALLOC 172DELETE.DBDS 175DELETE.IC 177DELETE.RECOV 181DELETE.REORG 182DELETE.UIC 184GENJCL.IC 197GENJCL.OIC 204GENJCL.RECEIVE 208GENJCL.RECOV 212GENJCL.USER 218INIT.DBDS 227INIT.IC 234LIST.DBDS 249LIST.HISTORY 253NOTIFY.ALLOC 263NOTIFY.IC 269NOTIFY.RECOV 283NOTIFY.REORG 286NOTIFY.UIC 300

DDNNEW parameterCHANGE.DBDS command 128

deadlock, avoiding RECON 47deallocation, changes to processing 19DEALTIME parameter command NOTIFY.ALLOC 263DEDB Fast Path record 61default members 310DEFAULTS parameter commands

GENJCL.ARCHIVE 186GENJCL.CA 189GENJCL.CLOSE 193GENJCL.IC 198GENJCL.OIC 204GENJCL.RECEIVE 208GENJCL.RECOV 212GENJCL.USER 218

DEFINE CLUSTER keywords 50DEFLTJCL parameter

CHANGE.CAGRP 119CHANGE.DBDS 128INIT.CAGRP 224INIT.DBDS 228

DELEQE parameter CHANGE.DBDS command 127DELETE.ADS command 171DELETE.ALLOC command 171DELETE.BKOUT command 172DELETE.CA command 173DELETE.CAGRP command 174DELETE.DB command 174DELETE.DBDS 18DELETE.DBDS command 175DELETE.DBDSGRP 18DELETE.DBDSGRP command 175delete group 313

Index 463

DELETE.GSG command 176DELETE.IC command 177DELETE.LOG 14DELETE.LOG (for OLDS) command 177DELETE.LOG (for RLDS) command 178DELETE.LOG (for SLDS) command 178delete log records, how to 84DELETE parameter commands

CHANGE.BKOUT 114CHANGE.CAGRP 118

DELETE.RECOV command 181DELETE.REORG command 182DELETE.SG command 182DELETE.SUBSYS command 183DELETE.UIC command 184deleting a SSYS record 85deleting information

all change accumulation group records 174all database data set records 175all database records 174allocation record of database data set 171area data set 171backout record 172change accumulation run record 173database data set group records 175global service group records 176image copy data set records 177log records 84nonstandard image copy data sets 184online log data set records 177recovery log data set records 178recovery run record 181reorganization records 182service group records 182subsystem records 183system log data set records 178

deleting unnecessary RECON records 66DELMEM parameter, CHANGE.DBDSGRP

command 133DFSUARC0 (Log Archive utility)

description 13DFSUCUM0 (Database Change Accumulation

utility) 333CA group

defining 37defining for future use 37reusing 37

description 33execution recorded by DBRC 17input 36subset of log volumes 36

DFSUDMP0 (Database Image Copy utility) 335DFSUICP0 (Online Database Image Copy utility) 335

creating data sets for future use 29description 26execution recorded by DBRC 17

DFSULTR0 (Log Recovery utility)generating a job 193

DFSURUL0 (HISAM Reorganization Unload utility)for backup 31

discarded RECON, replacing 69

DSN commandsCHANGE.DBDS 129CHANGE.PRILOG (for OLDS) 138CHANGE.PRILOG (for RLDS) 140CHANGE.PRILOG (for SLDS) 144CHANGE.SECLOG (for OLDS) 157CHANGE.SECLOG (for SLDS) 163INIT.DBDS 227NOTIFY.PRILOG (for OLDS) 271NOTIFY.PRILOG (for RLDS) 275NOTIFY.PRILOG (for SLDS) 280NOTIFY.PRILOG (for TSLDS) 280NOTIFY.SECLOG (for OLDS) 288NOTIFY.SECLOG (for RLDS) 291NOTIFY.SECLOG (for SLDS) 295

DSPDBHRC 60partition DB record

HALDB 61DSPDSHRC

partition DBDS recordsHALDB 61

DSPPTNRCHALDB partition record

HALDB 61DSPURU00 (RECON Upgrade utility) 71DSPURX00 (Database Recovery Control utility) 75DSSN parameter NOTIFY.ALLOC command 264DSSTART parameter commands

CHANGE.PRILOG (for RLDS) 140CHANGE.PRILOG (for SLDS) 145CHANGE.SECLOG (for RLDS) 159CHANGE.SECLOG (for SLDS) 164

DUAL parameter CHANGE.RECON command 149dump format 28dynamic allocation 49

of RECON 49dynamic backout with data sharing 40

EENDRECOV parameter commands


enqueue problems, causes of RECON 91error, RECON I/O 67execution members 8exit

database open 19RECON I/O 8

Ffailure and restart with data sharing 39Fast Path

registering databases and DEDB areas 20Fast Path DEDB record 61FILESEQ parameter commands

CHANGE.CA 116CHANGE.IC 135CHANGE.PRILOG (for RLDS) 141CHANGE.PRILOG (for SLDS) 145


FILESEQ parameter commands (continued)CHANGE.SECLOG (for RLDS) 160CHANGE.SECLOG (for SLDS) 164INIT.CA 222INIT.IC 234NOTIFY.CA 266NOTIFY.IC 269NOTIFY.PRILOG (for RLDS) 276NOTIFY.PRILOG (for SLDS and TSLDS) 281NOTIFY.REORG 286NOTIFY.SECLOG (for RLDS) 292NOTIFY.SECLOG (for SLDS or TSLDS) 296

FILESEQ2 parameter commandsCHANGE.IC 135INIT.IC 234NOTIFY.IC 269NOTIFY.REORG 286

FORCER parameter commandsCHANGE.RECON 149INIT.RECON 240

forward recovery with data sharing 41FPAREA parameter, GENJCL.RECOV command 212FREESPACE keyword 50FROMTIME parameter commands

LIST.HISTORY 253LIST.LOG 257

functions of DBRCdata sharing 13database recovery 13logs 13

GGAP parameter, CHANGE.PRILOG (for RLDS) 141,

142Generalized Trace Facility (GTF) USR records 153generating a job

Change Accumulation utility 189Database Image Copy utility 195Database Recovery utility 211, 216Log Archive utility 185Log Recovery utility 193Online Database Image Copy utility 202

generating JCL 309generating user output 309GENJCL

log control requirements in RECON 14GENJCL.ARCHIVE 14GENJCL.ARCHIVE command

syntax 185GENJCL.CA command 189GENJCL.CLOSE 14GENJCL.CLOSE command 193GENJCL commands, description 309GENJCL.IC 18, 26GENJCL.IC command 195GENJCL.OIC 18, 26GENJCL.OIC command 202GENJCL.RECEIVE 18GENJCL.RECEIVE command 207GENJCL.RECOV 18

GENJCL.RECOV command 211GENJCL.USER 18GENJCL.USER command 216GENMAX parameter

image copy data sets for future use 29of the INIT.DBDS command 228resetting 80specifying image copy requirements 17

global service groupdeleting information 176listing 251record 62resetting 303

GROUP parameter commands 197GENJCL.IC 197GENJCL.OIC 203GENJCL.RECEIVE 208GENJCL.RECOV 212GENJCL.USER 217LIST.DBDS 248LIST.HISTORY 252

GRPMAX parameter commandsCHANGE.CAGRP 119INIT.CAGRP 223

GRPMEM parameter INIT.CAGRP command 223GRPNAME parameter commands

CHANGE.CA 116CHANGE.CAGRP 118CHANGE.DBDSGRP 133DELETE.CA 173DELETE.CAGRP 174DELETE.DBDSGRP 176GENJCL.CA 189INIT.CA 222INIT.CAGRP 224INIT.DBDSGRP 232LIST.CAGRP 246LIST.DBDSGRP 250NOTIFY.CA 266

GSG parameter commandsCHANGE.PRILOG (for RLDS) 141CHANGE.PRILOG (for SLDS) 145CHANGE.SECLOG (for RLDS) 160CHANGE.SECLOG (for SLDS) 164

GSGNAME parameter commandsCHANGE.DB 122CHANGE.DBDS command 129

GTF (Generalized Trace Facility) USR records 153

HHALDB

master (DSPDBHRC)DB header record 60

partition 61partition DB record (DSPDBHRC) 61partition DBDS records (DSPDSHRC) 61partition record (DSPPTNRC)

PHDAM 61types of DBDSs 61

header record, RECON 56

Index 465

hints and tipsusing DBRC 79

adjusting GENMAX when it is reached or is toohigh 80

locating the last SLDS Stop Time in RECON 79PRILOG compression not working 82PRILOG record sizes 82

HISAM Reorganization Unload utility (DFSURUL0)for backup 31

HISTORY command 252HSSP data set 17

database registered with DBRC 17

IICDSN parameter commands

CHANGE.IC 135creating for future use 29defining 233duplicate, naming convention 22INIT.IC 234maximum number of generations 30naming convention 21nonstandard 32NOTIFY.IC 269NOTIFY.REORG 287RECON

adding information 283changing information 134

record 62recovery period 30reusing 30selecting 325

ICDSN2 parameter commandsCHANGE.IC 135DELETE.IC 177INIT.IC 234NOTIFY.IC 269NOTIFY.REORG 287

ICJCL parametercommands

CHANGE.DBDS 129GENJCL.CA 189GENJCL.CLOSE 193GENJCL.IC 198GENJCL.OIC 204GENJCL.RECEIVE 209GENJCL.RECOV 213GENJCL.USER 218INIT.DBDS 228

skeletal JCL execution member 351ICOFF parameter CHANGE.DBDS command 129ICON parameter CHANGE.DBDS command 129ICRCVJCL parameter skeletal JCL execution

member 356ILDS (Indirect List Data Set) 18

Index/ILDS Rebuild Utility (DFSPREC0) 15image copy 2 JCL 351image copy data set

recovery period 30Image Copy Group record 62

IMS.ADFSISRC 9IMS.PROCLIB 9IMS recovery utilities 15IMSCTRL macro

archiving OLDS 13parameters 10

INACTIVE parameter DELETE.LOG (for RLDS andSLDS) command 179

Index/ILDS Rebuild Utility (DFSPREC0) 15INDEXED keyword 50INIT.ADS command 12

description 221INIT.CA command 222INIT.CAGRP command 223INIT.DB command

description 225INIT.DBDS command

description 227REUSE keyword 17

INIT.DBDSGRP command 18, 231INIT.GSG command 233INIT.IC command 233INIT.RECON command 14

description 239initializing the RECON 46recovering RECONs 68

INIT.SG command 243initialize

area data set 221change accumulation data set 222change accumulation group 223database 225database data set 227database data set groups 231global service group 233image copy data sets 233RECON header records 239service group 243

initializing DBRCDBRC procedure 11IMSCTRL Macro 10

initializing RECON 11input/output error processing 67INTERIM parameter commands

DELETE.LOG (for OLDS) 178DELETE.LOG (for RLDS and SLDS) 180NOTIFY.PRILOG (for OLDS) 272NOTIFY.PRILOG (for RLDS) 276NOTIFY.PRILOG (for SLDS and TSLDS) 281NOTIFY.SECLOG (for OLDS) 289NOTIFY.SECLOG (for RLDS) 293NOTIFY.SECLOG (for SLDS or TSLDS) 297

INVALID parameter commandsCHANGE.CA 116CHANGE.IC 135

INVALID2 parameterCHANGE.IC command 136description 136

IRLM (Internal Resource Lock Manager)with batch backout 40


IRLMID parameter commandsCHANGE.SUBSYS 168NOTIFY.SUBSYS 299

JJCL (job control language)

generated by DBRC 8generating 309skeletal execution members explained 8tailoring for utilities 14

JCL allocation 49JCLOUT parameter

command GENJCL.ARCHIVE 186skeletal JCL 310

JCLPDS parametercommands 186


skeletal JCL 310JOB parameter commands


JOBJCLskeletal JCL execution member 9, 340

KKEYS keyword 50keyword

%IC 354%ICDSN2 354%ICDSN3 354%ICDSN4 354%ICUNIT2 354%ICUNIT3 354%ICUNIT4 354%ICVCNT2 354%ICVCNT3 354%ICVCNT4 354%ICVOLS2 354%ICVOLS3 354%ICVOLS4 354CONTROLINTERVALSIZE 50CYLINDERS 50DEFINE CLUSTER 50FREESPACE 50INDEXED 50KEYS 50

keyword (continued)NAME 50NOERASE 50NOREUSE 50RECORDSIZE 51SHAREOPTIONS 51SPANNED 51SPEED 51substitution 311UNIQUE 51UNORDERED 51VOLUMES 51

keywords, symbolic 309

Llevel of sharing definitions 20LIST.BKOUT command 245LIST.CAGRP command 245LIST.DB command 247LIST.DBDS 18LIST.DBDS command 248LIST.DBDSGRP 18LIST.DBDSGRP command 250LIST.GSG command 251LIST.HISTORY 18LIST.HISTORY command 252LIST.LOG 14LIST.LOG (for a category of records) command 255LIST.LOG (for a PRILOG family) command 254LIST parameter commands


LIST.RECON commanddescription 258fields displayed by command 417sample listing 367

LIST.SUBSYS command 260listing

backout records 245category of records 255change accumulation group 245database 247database data set 248database groups 250database histories 252global service group 251PRILOG family 254RECON 258, 367subsystem 260

LKASID parameterCHANGE.DBDS command 130INIT.DBDS command 230

Local Shared Resources (LSR) option 50log allocation record 63

Index 467

Log Archive utility (DFSUARC0)description 13

log controlvalid commands 14

log data sets, records 56, 57log records, deleting 84Log Recovery utility (DFSULTR0)

generating a job 193log volumes, specifying

a subset 36all 36

LOGCLJCL skeletal JCL execution member 349logging

accumulating logs using DFSUCUM0 33condensing logs using DFSUCUM0 33

LOGRET parameterINIT.RECON 241

LOGRET parameter of CHANGE.RECON 151LSR (Local Shared Resources option) 50

Mmacro

DEQ 48DFP Record Management Services 48GRS 47IMSCTRL 13OBTAIN 48RESERVE 47

maximum number of generations, image copy data sets,GENMAX parameter 129, 228

MAXOLDS parameter GENJCL.ARCHIVEcommand 186

MEMBER parameter commandsGENJCL.ARCHIVE 187GENJCL.CA 190GENJCL.CLOSE 194GENJCL.IC 199GENJCL.OIC 205GENJCL.RECEIVE 209GENJCL.RECOV 213GENJCL.USER 217INIT.DBDSGRP 232

members 310merging logs 37MULTIJOB parameter commands

GENJCL.IC 199GENJCL.OIC 205GENJCL.RECOV 213GENJCL.USER 219

multiplecold starts in a test environment 90

NNAME keyword 50naming conventions

change accumulation data sets 22DBRC data sets 21duplicate image copy data sets 22image copy data sets 21

naming conventions (continued)SSIDs in RECON SSYS records, for 84SSIDs processed by batch backout, for 85

NEWTIME parameter commandsCHANGE.PRILOG (for RLDS) 141CHANGE.PRILOG (for SLDS) 145CHANGE.SECLOG (for RLDS) 160CHANGE.SECLOG (for SLDS) 164

NEWVOL parameter commandsCHANGE.PRILOG (for RLDS) 141CHANGE.PRILOG (for SLDS) 145CHANGE.SECLOG (for RLDS) 160CHANGE.SECLOG (for SLDS) 164

NOAUTH parameter commandsCHANGE.DB 122CHANGE.DBDS 128

NOBACK parameter CHANGE.DB command 122NOBACKUP parameter CHANGE.SUBSYS

command 168NOCATDS parameter commands


NOCFSTR2 parameter CHANGE.DBDS command 128NOCHECK parameter


NODEFLT parameter commandsCHANGE.CAGRP 119GENJCL.CA 190GENJCL.IC 199GENJCL.OIC 205GENJCL.RECOV 214GENJCL.USER 219

NOERASE keyword 50NOFORCER parameter commands


NOJOB parameter commandsGENJCL.ARCHIVE 186GENJCL.CA 190GENJCL.CLOSE 193GENJCL.IC 198GENJCL.OIC 205GENJCL.RECEIVE 209GENJCL.RECOV 213GENJCL.USER 218

NOLIST parameter commandsGENJCL.ARCHIVE 186GENJCL.CA 190GENJCL.CLOSE 194GENJCL.IC 199GENJCL.OIC 205GENJCL.RECEIVE 209GENJCL.RECOV 213GENJCL.USER 218

NOLKASID parameterCHANGE.DBDS command 130, 230

NONEW parameter commands 242CHANGE.RECON 152INIT.RECON 242

NONRECOV parameter command, CHANGE.DB 123


nonstandard image copy data setsdescription 32RECON

adding information 299changing information 170deleting information 184

NOPREL parameter CHANGE.DBDS command 130NOPREO parameter CHANGE.DBDS command 131NORECOV parameter CHANGE.DBDS command 131NOREUSE keyword 50NOREUSE parameter

CA data set 38CHANGE.DBDS 130command

CHANGE.CAGRP 119image copy data sets for future use 29INIT.CAGRP 224INIT.DBDS 228

NORMAL parameter commandsCHANGE.PRILOG (for OLDS) 138CHANGE.PRILOG (for RLDS) 140CHANGE.PRILOG (for SLDS) 145CHANGE.SECLOG (for OLDS) 157CHANGE.SECLOG (for RLDS) 160CHANGE.SECLOG (for SLDS) 164CHANGE.SUBSYS 168NOTIFY.SUBSYS 299

normal restart 42notational conventions, commands 107NOTCOVER parameter

CHANGE.DB command 122CHANGE.DBDS command 129

nothing to process, when change accumulationsays 86

NOTIFY.ALLOC command 263NOTIFY.BKOUT command 264NOTIFY.CA command 265NOTIFY.PRILOG 14NOTIFY.PRILOG (for OLDS) command 271NOTIFY.PRILOG (for RLDS) command 274NOTIFY.PRILOG (for SLDS and TSLDS)

command 279NOTIFY.RECOV command 283NOTIFY.REORG command 285NOTIFY.SECLOG 14NOTIFY.SECLOG (for OLDS) command 288NOTIFY.SECLOG (for RLDS) command 291NOTIFY.SECLOG (for SLDS) command 294NOTIFY.SUBSYS command 298NOTIFY.UIC command

description 299notifying DBRC that log data sets have moved 87NOVSO parameter 132

CHANGE.DBDS 132, 230NXTOLDS parameter commands

NOTIFY.PRILOG (for OLDS) 273NOTIFY.SECLOG (for OLDS) 290

OOICJCL parameter

commands 130CHANGE.DBDS 130INIT.DBDS 229

skeletal JCL execution member 354OLDS (online log data set)

archiving DBRC 13changing information 137, 156commands

CHANGE.PRILOG 137CHANGE.SECLOG 157DELETE.LOG (for OLDS) 178GENJCL.ARCHIVE 185GENJCL.CLOSE 194NOTIFY.PRILOG (for OLDS) 271NOTIFY.SECLOG (for OLDS) 288

RECONadding information 271, 288deleting information 177

records 57selecting in JCL 320

OLDVOL parameter commandsCHANGE.PRILOG (for RLDS) 141CHANGE.PRILOG (for SLDS) 146CHANGE.SECLOG (for RLDS) 160CHANGE.SECLOG (for SLDS) 165

ONEJOB parameter commandsGENJCL.IC 199GENJCL.OIC 205GENJCL.RECOV 213GENJCL.USER 219

online/RMDELETE command 110

Online Database Image Copy utility (DFSUICP0) 28creating data sets for future use 29description 26execution recorded by DBRC 17generating a job 202

Online Database Image Copy utility JCL 354ONLINE parameter commands

LIST.SUBSYS 260NOTIFY.IC 269NOTIFY.SUBSYS 299

Online Recovery Service (ORS) 7, 15database recovery process 38image copy output 28time stamp recovery 232

Pparameter

CIC 28DBRC for online IMS 10GENMAX 29NOREUSE 29, 38record type 315RECOVPD 17REUSE 29selection criteria 316

Index 469

parameter (continued)STARTNEW 68

partition DB record (DSPDBHRC)HALDB

TYPE=PART 61partition DBDS records (DSPDSHRC)

HALDBtypes of DBDSs 61

partition record (DSPPTNRC)HALDB

PHDAM 61PDS members 8PRELOAD parameter CHANGE.DBDS command 130PREOPEN parameter CHANGE.DBDS command 131PRILOG

closing an open online 83compression 82compression, automatic 65

PRILOG familylisting records 254

procedures, installation 10PSB parameter commands 115

CHANGE.BKOUT 115GENJCL.OIC 204GENJCL.USER 219NOTIFY.BKOUT 265

PURGLIST parameter NOTIFY.CA command 266

RRCVTIME parameter

GENJCL.RECOV 214NOTIFY.RECOV 283, 284

RCVTRACK parameterCHANGE.DB command 123CHANGE.DBDS command 131

reading syntax diagrams 107READOFF parameter CHANGE.DB command 124READON parameter CHANGE.DB command 124RECDCT parameter commands

CHANGE.IC 136NOTIFY.IC 270NOTIFY.REORG 287

RECONactive 54allocation 45availability 46backup 64changing log control records 13concurrent image copy data set 17contention problems 46creating 50data sharing record types 64data sharing records 20Database Image Copy 2 data set 17defining 46defining requirements in 14description 45, 64DSECTS 367dynamic allocation 49enqueue problems, causes of 91

RECON (continued)extending 50header records 56HSSP image copy data set 17initial access 54initialization 46keywords 50maintaining 64maintaining records 65overview 45RECON Upgrade utility 71recovering 68recovery record types 57registering databases 12reorganizing 66reorganizing to increase maximum

RECORDSIZE 87sample listing 367security considerations 54serialization 47shared among multiple processors 47spare 54VSAM CREATE mode 49

RECON command INITestablishing RECONs for log control 11

RECON I/O exit routine 8RECON initialization token (RIT) 19RECON record types 55RECON Upgrade utility (DSPURU00) 71

JCL example 74return codes and messages 73usage procedure 71

RECON1 parameter, BACKUP.RECON command 111RECONs, both are unusable 68record log information 13record type parameter 315recording recovery related information 8records

BACKOUT 58change accumulation group 58change accumulation run 58data sharing 64database 59database allocation 63database data set 59database data set group 59database recovery 57DBDS group 59DEDB 61deleting unnecessary 65global service group 62image copy 62in RECON 55log allocation 63log data set 56maintaining RECON 65RECON header 56recovery 64reorganization 63subsystem 64

RECORDSIZE keyword 51


RECOVABL parameter commandsCHANGE.DB 123INIT.DB 225

recoverable databasesCHANGE.DB command 26Image Copy utilities 26INIT.DB command 26

recovering a database 38archiving log records 43batch support 40DBRC role 39dynamic backout 40process 38recovery facilities 40setting up recovery mechanisms 39without DBRC 42

recoveryCHANGE.DBDS 131concepts 5database data set or area, adding information to

RECON 283DBRC 13description 69IMS process 5in data sharing

planning procedures 39without DBRC 42

log data setdeleting information 178

log data set, adding information to RECON 274,291

overview 5period, of image copy data sets 30RECON 68record 64

recovery controldata set

commands to generate JCL and user-definedoutput 309

header record 56listing 258

recovery control data set 45I/O error processing 67records 55replacing discarded RECON 69

Recovery Control utility (DSPURX00)description 8

recovery functions for DBDSs 13recovery records, database 57recovery utilities 7RECOVJCL parameter

commandsCHANGE.DBDS 131INIT.DBDS 229

skeletal JCL execution member 358RECOVPD parameter 17RECOVPD parameter commands

CHANGE.DBDS 131INIT.DBDS 229

RECTIME parameter commandsCHANGE.CA 116

RECTIME parameter commands (continued)CHANGE.IC 135CHANGE.UIC 170DELETE.ALLOC 172DELETE.CA 173DELETE.IC 177DELETE.RECOV 181DELETE.REORG 182DELETE.UIC 184

RECVJCL parameter CHANGE.DBDS command 131registering databases in RECON 12Remote Site Recovery (RSR), DBRC support 22Removing an SSYS from DB Authorization 86reorganization of RECON

adding information 285deleting information 182process to increase maximum RECORDSIZE 87

reorganization record 63reorganizing RECON, CHANGE.RECON 66REPLACE parameter CHANGE.RECON

command 149REPRO function of VSAM AMS, offline

reorganization 67REPTHT parameter, CHANGE.RECON command 156RESERVE command, during backup 64RESET.GSG command 303resetting the GENMAX parameter 80restart in data sharing

after DBRC failure 42after IMS failure 42emergency, after DBRC failure 42emergency, after IMS failure 42normal 42

RESTORE parameter GENJCL.RECOV command 214REUSE parameter, image copy data sets for future

use 29REUSE parameter commands

CHANGE.CAGRP 119CHANGE.DBDS 130INIT.CAGRP 224INIT.DBDS 17, 228

reusing image copy data sets 30RIT (RECON initialization token) 19RLDS (recovery log data set) 139

accumulating changes using DFSUCUM0 33commands 140

CHANGE.PRILOG (for RLDS) 140CHANGE.SECLOG (for RLDS) 159NOTIFY.PRILOG (for RLDS) 277NOTIFY.SECLOG (for RLDS) 293

deleting information from RECON 178records 56selecting 323

ROLB call 40RSR 22RUNTIMES parameter commands

CHANGE.PRILOG (for RLDS) 142CHANGE.PRILOG (for SLDS) 146CHANGE.SECLOG (for RLDS) 161CHANGE.SECLOG (for SLDS) 165NOTIFY.CA 266

Index 471

RUNTIMES parameter commands (continued)NOTIFY.IC 269NOTIFY.PRILOG (for OLDS) 271NOTIFY.PRILOG (for RLDS) 275NOTIFY.PRILOG (for SLDS) 280NOTIFY.PRILOG (for TSLDS) 280NOTIFY.REORG 286NOTIFY.SECLOG (for OLDS) 288NOTIFY.SECLOG (for RLDS) 291NOTIFY.SECLOG (for SLDS) 295NOTIFY.UIC 300

Ssample listing of RECON

Active Site 373tracking site 401

select group, skeletal JCL 313selection criteria parameter 316serialization

of RECON 47strategies 48

service groupchanging information 167deleting information 182

service utilitiescontrol statement parameters 315

share control 13share level, in DBRC 20SHARELVL parameter

CHANGE.DB 124INIT.DB 226specification descriptions 20

SHAREOPTIONS keyword 51sharing level, assigning one with DBRC 20simple keywords 311

control keywords 311%DELETE 313, 317%ENDDEL 313, 317%ENDSEL 313, 314%SELECT 313, 320%SET MEMBER 313, 318%SET TIMEFMT 313, 318

size calculation for SSYS record 85skeletal JCL 356

coding default members 329coding execution members 311, 329data set 310default members explained 310execution members explained 310generating JCL and user-defined output 309IBM-supplied 310, 340writing your own 310, 331

SLDS (system log data set)accumulating changes using DFSUCUM0 33adding information to RECON 279, 294CHANGE.PRILOG (for SLDS) 144CHANGE.SECLOG (for SLDS) 163changing information 143, 162deleting information from RECON 178NOTIFY.PRILOG (for SLDS) 279

SLDS (system log data set) (continued)NOTIFY.SECLOG (for SLDS) 295records 56selecting 321

SLDS stop time, locating the last in RECON 79SMS concurrent image copy, SMSCIC parameter 197SMSCIC (SMS concurrent image copy) 197SMSCIC parameter command,

GENJCL.IC 197space requirements, RECONs 45SPANNED keyword 51spare RECON, I/O error processing 67specifying log retention intervals,

CHANGE.RECON 151SPEED keyword 51SSID parameter commands

CHANGE.BKOUT 114CHANGE.DB 125CHANGE.PRILOG (for OLDS) 138CHANGE.PRILOG (for SLDS) 146CHANGE.RECON 152CHANGE.SECLOG (for OLDS) 157CHANGE.SECLOG (for SLDS) 165CHANGE.SUBSYS 168DELETE.BKOUT 172DELETE.LOG (for OLDS) 178DELETE.SUBSYS 183GENJCL.ARCHIVE 187GENJCL.CLOSE 194GENJCL.USER 219INIT.RECON 242LIST.BKOUT 245LIST.LOG (for a category of records) 258LIST.LOG (for a PRILOG family) 255LIST.RECON 259LIST.SUBSYS 260, 261NOTIFY.BKOUT 264NOTIFY.PRILOG (for OLDS) 273NOTIFY.PRILOG (for RLDS) 277NOTIFY.PRILOG (for SLDS and TSLDS) 282NOTIFY.SECLOG (for OLDS) 290NOTIFY.SECLOG (for RLDS) 293NOTIFY.SECLOG (for SLDS) 297NOTIFY.SUBSYS 298

standard form of time stamps, parameters of DBRCcommands 101

START commanduse of 20, 212

STARTIME parameter commandsCHANGE.PRILOG (for RLDS) 140CHANGE.PRILOG (for SLDS) 144CHANGE.SECLOG (for RLDS) 159CHANGE.SECLOG (for SLDS) 163DELETE.LOG (for RLDS and SLDS) 179NOTIFY.ALLOC 263NOTIFY.PRILOG (for OLDS) 272NOTIFY.PRILOG (for RLDS) 275NOTIFY.PRILOG (for SLDS and TSLDS) 280NOTIFY.SECLOG (for OLDS) 289NOTIFY.SECLOG (for RLDS) 292NOTIFY.SECLOG (for SLDS) 296


STARTNEW parametercommands 152


usage 68STARTRCV parameter commands


STATUS parameter LIST.RECON command 259STOPTIME parameter commands

CHANGE.IC 136NOTIFY.CA 266NOTIFY.IC 270

SUBSET parameter commandsCHANGE.CA 117NOTIFY.CA 267

subsystemchanging information 168listing 260RECON 183

adding information 298deleting information 183

subsystem (SSYS) recorddeleting a 85initializing during IMS restart 64size calculation 85working with 84

symbolic keywordsdescription 310, 313, 329JCL execution member

%ALLSEL 328%ALLTIME 328%ALLUSID 328%CADSN 327%CAFSEQ 327%CALGTM 327%CAODSN 318%CASEL 327%CATIME 327%CAUNIT 327%CAVCNT 327%CAVOLS 327%DALTIME 328%DBADDN 329%DBADSAV 329%DBDDN 328, 329%DBDSDEL 329%DBDSN 329%DBDSNRV 329%DBNAME 328, 329%DBTYPE 329%DBUSID 329%DDNAME 315%ICCAT 326%ICDSN 325%ICFSEQ 325%ICSEL 325%ICSTOP 325%ICTIME 325%ICTYPE 325%ICUNIT 325

symbolic keywords (continued)JCL execution member (continued)

%ICUSID 326%ICVCNT 326%ICVOLS 326%LOGDSN 324%LOGETIM 324%LOGFRID 324%LOGFSEQ 324%LOGLRID 325%LOGMERG 324%LOGONL 324%LOGRMT 324%LOGSEL 324%LOGSTIM 324%LOGUNIT 324%LOGVOLS 324%OLDCTIM 321%OLDFRID 321%OLDLRID 321%OLDOTIM 321%OLDSDDN 320%OLDSDSN 320%OLDSSEL 321%OLDSTYP 321%PLGTIME 328%SLDETIM 322%SLDFRID 322%SLDFSEQ 322%SLDLRID 322%SLDRMT 322%SLDSDDN 322%SLDSSEL 322%SLDSTIM 322%SLDUNIT 322%SLDVOLS 322%SSID 312%TIME 312simple keywords 311, 328

recognized by DBRC 331user-defined 312

symbolic keywords, JCL execution membersubstitution 309

syntax, DBRC command 99syntax diagrams

reading 107arrow symbols 107conventions 108default keywords 109IMS-specific syntax information 109multiple or optional items 108optional items 108repeatable items 109required items 108

syntax notation, commands 107system log management, with data sharing 37system logs, with data sharing 37

Index 473

TTAPEUNIT parameter commands


tasks of DBRC 6THT parameter, CHANGE.RECON command 156time qualifier 316time stamp 101

conversions and examples 105DBRC commands affected by format 106specifying zero values 105standard default settings for values 106standard format 101time history table (THT) 107TIMEFMT parameter 102two-digit year input 105

TIMEFMT parameter sublistCHANGE.RECON 154default settings 105order of precedence of the subparameters 104

TIMEZIN parameter CHANGE.RECON command 154TIMEZONE parameter, CHANGE.RECON

command 153TOTIME parameter commands

DELETE.LOG (for RLDS and SLDS) 179GENJCL.ARCHIVE 186LIST.HISTORY 253LIST.LOG 257

TRACEOFF parameter CHANGE.RECONcommand 153

TRACEON parameter CHANGE.RECONcommand 153

TRACK parameter NOTIFY.RECOV command 284TRACKING parameter

CHANGE.DB command 125CHANGE.SUBSYS command 169

TSLDS (tracking subsystem log data set)adding information to RECON 279CHANGE.PRILOG (for TSLDS) 144CHANGE.SECLOG (for TSLDS) 163changing information 143NOTIFY.PRILOG (for TSLDS) 279

TYPEFP parameter commandsCHANGE.DB 125INIT.DB 226LIST.DB 247

TYPEIMS parameter commandsCHANGE.DB 125INIT.DB 226LIST.DB 247

UUCF (Utility Control Facility) with data sharing 42UDATA parameter commands

CHANGE.UIC 170NOTIFY.UIC 300

UIC, NOTIFY.UIC commandupdating RECON 17

UNAUTH parameterCHANGE.DB command 125restrictions 121using 121

UNAVAIL parameter commandsCHANGE.ADS 113CHANGE.PRILOG (for OLDS) 137CHANGE.SECLOG (for OLDS) 157INIT.ADS 221

UNIQUE keyword 51UNIT parameter commands

CHANGE.CA 117CHANGE.IC 136CHANGE.PRILOG (for RLDS) 142CHANGE.PRILOG (for SLDS) 146CHANGE.SECLOG (for RLDS) 161CHANGE.SECLOG (for SLDS) 166GENJCL.CA 190GENJCL.IC 199GENJCL.OIC 205INIT.CA 222INIT.IC 234NOTIFY.CA 267NOTIFY.IC 270NOTIFY.PRILOG 282NOTIFY.PRILOG (for RLDS) 278NOTIFY.REORG 287NOTIFY.SECLOG (for RLDS) 294NOTIFY.SECLOG (for SLDS) 297

UNIT2 parameter commandsCHANGE.IC 136GENJCL.OIC 206INIT.IC 234NOTIFY.IC 270NOTIFY.REORG 287

UNORDERED keyword 51UOR (unit of recovery) parameter commands

CHANGE.BKOUT 114NOTIFY.BKOUT 265

UORTIME parameter CHANGE.BKOUT command 114USEDBDS parameter GENJCL.RECOV command 214USEIC parameter GENJCL.RECOV command 214USERKEYS parameter commands


using DB Groups 19using DBRC, considerations for 12USR records, GTF (Generalized Trace Facility) 153utilities

DBRC (DFSURDB0) 42Recovery Control (DSPURX00) 8VSAM AMS 67, 68

Utility Control Facility (UCF) 42utility control statement

INIT.CA 37


utility control statement (continued)INIT.CAGRP 37

Vvalid log subset, in data sharing to compress the

size 37VALID parameter commands

CHANGE.CA 116CHANGE.IC 135

VALID2 parameter CHANGE.IC command 136VOLLIST parameter commands

CHANGE.CA 117CHANGE.IC 136CHANGE.PRILOG (for RLDS) 142CHANGE.PRILOG (for SLDS) 146CHANGE.SECLOG (for RLDS) 161CHANGE.SECLOG (for SLDS) 166GENJCL.CA 191GENJCL.IC 200GENJCL.OIC 206INIT.CA 222INIT.IC 234NOTIFY.CA 266NOTIFY.IC 270NOTIFY.REORG 287

VOLLIST2 parameter commandsCHANGE.IC 136GENJCL.IC 200GENJCL.OIC 206INIT.IC 235NOTIFY.IC 270NOTIFY.REORG 287

VOLNUM parameter GENJCL.CA command 191VOLSER parameter commands

NOTIFY.PRILOG (for RLDS) 278NOTIFY.PRILOG (for SLDS and TSLDS) 282NOTIFY.SECLOG (for RLDS) 294NOTIFY.SECLOG (for SLDS) 297

VOLUMES keyword 51VSAM (Virtual Storage Access Method) create

mode 49VSAM AMS (access method services)

offline reorganization 67restoring RECONs 68

VSO parameterCHANGE.DBDS 132, 230

Index 475


Readers’ Comments — We’d Like to Hear from You

IMS Version 7DBRC Guide and Reference

Publication No. SC26-9428-01

Overall, how satisfied are you with the information in this book?

Very Satisfied Satisfied Neutral Dissatisfied Very DissatisfiedOverall satisfaction h h h h h

How satisfied are you that the information in this book is:

Very Satisfied Satisfied Neutral Dissatisfied Very DissatisfiedAccurate h h h h h

Complete h h h h h

Easy to find h h h h h

Easy to understand h h h h h

Well organized h h h h h

Applicable to your tasks h h h h h

Please tell us how we can improve this book:

Thank you for your responses. May we contact you? h Yes h No

When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in anyway it believes appropriate without incurring any obligation to you.

Name Address

Company or Organization

Phone No.

Readers’ Comments — We’d Like to Hear from YouSC26-9428-01

SC26-9428-01

��Cut or FoldAlong Line

Cut or FoldAlong Line

Fold and Tape Please do not staple Fold and Tape

Fold and Tape Please do not staple Fold and Tape

NO POSTAGENECESSARYIF MAILED IN THEUNITED STATES

BUSINESS REPLY MAILFIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK

POSTAGE WILL BE PAID BY ADDRESSEE

International Business Machines CorporationDepartment BWE/H3P.O. Box 49023San Jose, CA95161-9945

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

__

_

��

Program Number: 5655-B01

Printed in the United States of Americaon recycled paper containing 10%recovered post-consumer fiber.

SC26-9428-01

Spin

ein

form

atio

n:

��

�IM

SVe

rsio

n7

DBR

CG

uide

&R

efer

ence

Documents

DBRC Guide and Reference