DFSDBRG 4

IMS
Database Recovery Control (DBRC) Guide

and Reference
Version 9
SC18-7818-03
IMS
Database Recovery Control (DBRC) Guide

and Reference
Version 9
SC18-7818-03
Note
Before using this information and the product it supports, read the information in “Notices” on page 569.
| This edition applies to IMS Version 9 (program number 5655-J38) and to all subsequent releases and modifications
| until otherwise indicated in new editions. This edition replaces SC18-7818-02.
© Copyright International Business Machines Corporation 1974, 2007.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . v Chapter 4. Initializing and Maintaining
the RECON Data Set . . . . . . . . . 55
Tables . . . . . . . . . . . . . . . vii Planning Considerations for the RECON Data Set 55
Initially Accessing the RECON Data Set . . . . . 62
About This Book. . . . . . . . . . . ix Records in the RECON Data Set . . . . . . . 63
Prerequisite Knowledge . . . . . . . . . . ix Maintaining the RECON Data Set . . . . . . . 72
How to Use This Book . . . . . . . . . . . ix Tracking Changes Made to the RECON Data Set . . 81
Related Reading . . . . . . . . . . . . . ix
IBM Product Names Used in This Information . . . x Chapter 5. Skeletal JCL . . . . . . . 83
Accessibility Features for IMS Version 9 . . . . . xi Generating JCL and User-Defined Output . . . . 83
How to Send Your Comments . . . . . . . . xii Using IBM-Supplied Skeletal JCL . . . . . . . 84
Writing Your Own Skeletal JCL . . . . . . . . 85
Summary of Changes . . . . . . . . xiii Contents of the Skeletal JCL Data Set . . . . . . 85
| Changes to the Current Edition of This Book for Skeletal JCL Syntax . . . . . . . . . . . . 86
| IMS Version 9 . . . . . . . . . . . . . xiii
Changes to This Book for IMS Version 9 . . . . xiii Chapter 6. Hints and Tips for DBRC 107
Library Changes for IMS Version 9 . . . . . . xiv Changing the RECON Data Set to Output Time
Stamps in Local Time of Origin . . . . . . . 107
Locating the Last SLDS Stop Time in RECON . . 108
Part 1. How to Use DBRC . . . . . . 1 Adjusting GENMAX When It Is Reached or It Is
Too High . . . . . . . . . . . . . . . 109
Chapter 1. Overview of DBRC . . . . . 3 Getting PRILOG Compression to Work . . . . . 110
What Is DBRC? . . . . . . . . . . . . . 3 Getting Notified When the PRILOG Record
DBRC Tasks . . . . . . . . . . . . . . 4 Exceeds the Maximum Record Size . . . . . . 111
DBRC Components . . . . . . . . . . . . 4 Closing an Open Online PRILOG . . . . . . . 111
When Should You Use DBRC? . . . . . . . . 5 Deleting Log Records . . . . . . . . . . . 112
| Communicating with DBRC . . . . . . . . . 6 Working with Subsystem Records (SSYS) . . . . 113
DBRC Functions . . . . . . . . . . . . . 7 Removing Authorization Inconsistency Between the
| Defining DBRC to IMS . . . . . . . . . . 19 SSYS from DB/AREA Records . . . . . . . . 114
Registering Databases and Database Data Sets . . . 20 Getting Change Accumulation to Start Processing
Planning for Recovery . . . . . . . . . . . 21 Logs Again . . . . . . . . . . . . . . 114
Getting Change Accumulation Working When It
Chapter 2. Database Recovery Control States Nothing to Process . . . . . . . . . 114
Utility (DSPURX00) . . . . . . . . . 27 Moving Log Data Sets . . . . . . . . . . 115
What Is the Database Recovery Control Utility Cataloging Data Sets . . . . . . . . . . . 115
(DSPURX00)? . . . . . . . . . . . . . . 27 Performing Multiple Cold Starts in a Test
Input and Output for the Database Recovery Environment . . . . . . . . . . . . . 116
Control Utility . . . . . . . . . . . . . 27 Avoiding Some Causes of RECON Data Set
Invoking the Database Recovery Control Utility Enqueue Problems. . . . . . . . . . . . 117
from Your Program . . . . . . . . . . . . 28
Example of Database Recovery Control Utility JCL 30 Part 2. DBRC Command Reference 119
Chapter 3. Considerations for a DBRC Chapter 7. DBRC Commands . . . . 121
System . . . . . . . . . . . . . . 33 DBRC Batch Commands. . . . . . . . . . 121
General Considerations for Using DBRC. . . . . 33 | DBRC Online Commands . . . . . . . . . 122
Data Set Naming Conventions . . . . . . . . 33 DBRC Command Syntax . . . . . . . . . 122
Database Backup Copies . . . . . . . . . . 35
Log Record Change Accumulation. . . . . . . 43 Chapter 8. BACKUP Command . . . . 133
DBDS Group Considerations . . . . . . . . 48 BACKUP.RECON . . . . . . . . . . . . 133
DB Groups . . . . . . . . . . . . . . 49
| DBRC Considerations for HALDB Online
Chapter 9. CHANGE Commands . . . 135
| Reorganization . . . . . . . . . . . . . 49
CHANGE Commands In This Chapter . . . . . 135
© Copyright IBM Corp. 1974, 2007 iii

Chapter 10. DELETE Commands . . . 205 STOPDBRC Request . . . . . . . . . . . 431
DELETE Commands In This Chapter . . . . . 205
Part 4. Appendixes . . . . . . . . 433
Chapter 11. GENJCL Commands . . . 221
GENJCL Commands In This Chapter . . . . . 221 Appendix A. Symbolic Keywords
Recognized by DBRC . . . . . . . . 435
Chapter 12. INIT Commands . . . . . 263 All Supported Utilities . . . . . . . . . . 435
INIT Commands In This Chapter. . . . . . . 263 Log Archive Utility (ARCHJCL) . . . . . . . 436
Database Change Accumulation Utility (CAJCL) 437
Chapter 13. LIST Commands . . . . . 291 Log Recovery Utility (LOGCLJCL) . . . . . . 438
LIST Commands In This Chapter . . . . . . . 291 Database Image Copy Utility, Database Image
Copy Utility 2, and Online Database Image Copy
Chapter 14. NOTIFY Commands . . . 309 Utility (ICJCL and OICJCL). . . . . . . . . 438
NOTIFY Commands In This Chapter . . . . . 309 Database Recovery Utility- Receive (ICRCVJCL) 440
Database Recovery Utility-Recovery (RECOVJCL) 442
IBM-Supplied Skeletal JCL Execution Members . . 443
Chapter 15. RESET Command . . . . 349
RESET.GSG . . . . . . . . . . . . . . 349
Appendix B. Sample Listings from the
RECON Data Set . . . . . . . . . . 473
Part 3. DBRC Application Sample Listing of LIST.HISTORY Output . . . . 474
Programming Interface (API) Sample Listing of a RECON at the Active Site . . 479
Reference . . . . . . . . . . . . 351 Sample Listing of a RECON at the Tracking Site 508
Fields Present in a Listing of a RECON by Record
| Chapter 16. Using the DBRC API . . . 353 Type . . . . . . . . . . . . . . . . 532
| Writing an Application to Access the DBRC API 353
| Runtime Considerations of the DBRC API . . . . 357 Appendix C. Resource Names for
Command Authorization. . . . . . . 565
Chapter 17. DBRC Query Request . . 361
Output from Query Requests . . . . . . . . 361 Notices . . . . . . . . . . . . . . 569
Query Requests Reference . . . . . . . . . 362 Trademarks . . . . . . . . . . . . . . 571
| Chapter 18. DBRC Release Buffer Bibliography . . . . . . . . . . . . 573

| Request . . . . . . . . . . . . . . 423 IMS Version 9 Library . . . . . . . . . . 573
| RELBUF Request . . . . . . . . . . . . 423 Supplementary Publications . . . . . . . . 574
Publication Collections . . . . . . . . . . 574
| Chapter 19. DBRC Start Request . . . 427 Accessibility Titles Cited in This Library . . . . 574
| STARTDBRC Request. . . . . . . . . . . 427
Index . . . . . . . . . . . . . . . 575
Chapter 20. DBRC Stop Request . . . 431
iv DBRC Guide and Reference

Figures
1. Logs Produced for Recovery and Restart . . . 7 42. DSECT of DSPAPQCG . . . . . . . . 396
2. IMS Database Recovery process . . . . . . 10 | 43. DSECT of DSPAPQCA . . . . . . . . 397
3. How DBRC Works With the Database | 44. Format for QUERY TYPE=GSGROUP Output 398
Recovery Utility . . . . . . . . . . . 12 45. DSECT of DSPAPQGG . . . . . . . . 399
4. DBRC’s Role in Utility Execution . . . . . 15 | 46. Format for QUERY TYPE=LOG Log
5. Database Recovery Control Utility Input and | Information Output . . . . . . . . . 404
Output . . . . . . . . . . . . . . 28 47. DSECT of DSPAPQLI . . . . . . . . . 404
6. Registers and Operand List Contents Needed | 48. Format for QUERY TYPE=LOG Output for
To Invoke the Database Recovery Control | PRILOG, SECLOG, PRISLDS, SECSLDS,
Utility . . . . . . . . . . . . . . 30 | PRITSLDS, and SECTSLDS . . . . . . . 405
7. Inputs and Outputs of the Database Recovery 49. DSECT of DSPAPQLG . . . . . . . . 405
Control Utility . . . . . . . . . . . 31 | 50. Format for QUERY TYPE=LOG Output for
8. What Change Accumulation Does with Redo | LOGALL . . . . . . . . . . . . . 407
Data from Divergent Data Streams . . . . . 45 51. DSECT of DSPAPQLA . . . . . . . . 407
9. DBRC Dual RECON Set Up with a Spare 55 | 52. Format for QUERY TYPE=OLDS Output 411
10. Major RECON Record Types and the 53. DSECT of DSPAPQOL . . . . . . . . 412
Relationships Between Them . . . . . . . 64 | 54. Format for QUERY TYPE=RECON Output 415
11. DBRC DL/I Records . . . . . . . . . 68 55. DSECT of DSPAPQRC . . . . . . . . 416
12. Record Structure for a HALDB in the RECON | 56. Format for QUERY TYPE=SUBSYS Output 421
Data Set. . . . . . . . . . . . . . 68 57. DSECT of DSPAPQSS . . . . . . . . . 421
13. DBRC Fast Path Database Records . . . . . 70 58. IBM-Supplied Skeletal JCL for the Log
14. Skeletal JCL Data Set Contents . . . . . . 86 Archive Utility . . . . . . . . . . . 445
| 15. General Format of Query Output . . . . . 362 59. IBM-Supplied Skeletal JCL for the Database
16. DSECT of DSPAPQHD - QUERY Output Change Accumulation Utility . . . . . . 451
Block Header . . . . . . . . . . . 362 60. IBM-Supplied Skeletal JCL for the Log
| 17. Format for QUERY TYPE=BACKOUT Output 365 Recovery Utility . . . . . . . . . . 454
18. DSECT of DSPAPQBO . . . . . . . . 366 61. IBM-Supplied Skeletal JCL for the Database
| 19. Format of QUERY TYPE=DB (Full Function) Image Copy Utility and the Database Image
| Output. . . . . . . . . . . . . . 372 Copy 2 Utility . . . . . . . . . . . 457
| 20. DSECT of DSPAPQDB . . . . . . . . 373 62. IBM-Supplied Skeletal JCL for the Online
21. DSECT of DSPAPQSL. . . . . . . . . 374 Database Image Copy Utility . . . . . . 461
| 22. Format of QUERY TYPE=DB (Fast Path 63. IBM-Supplied Skeletal JCL for the Database
| DEDB) Output . . . . . . . . . . . 375 Recovery Utility - Tracking Site . . . . . 464
23. DSECT of DSPAPQFD . . . . . . . . 376 64. IBM-Supplied Skeletal JCL for the Database
24. DSECT of DSPAPQAR . . . . . . . . 377 Recovery Utility . . . . . . . . . . 466
25. DSECT of DSPAPQEL . . . . . . . . 379 65. IBM-Supplied Skeletal JCL for the HALDB
| 26. Format of QUERY TYPE=DB (HALDB Master Index/ILDS Rebuild Utility . . . . . . . 471
| and Partitions) Output . . . . . . . . 379 | 66. Sample LIST.HISTORY Output . . . . . . 475
27. DSECT of DSPAPQHB . . . . . . . . 380 67. Sample Listing of a RECON at the Active Site
28. DSECT of DSPAPQHP . . . . . . . . 381 - RECON Status. . . . . . . . . . . 480
| 29. Format of QUERY TYPE=DB (DBDS) Output 383 | 68. Sample Listing of a RECON at the Active Site
30. DSECT of DSPAPQDS . . . . . . . . 384 | - Log Records . . . . . . . . . . . 481
| 31. Format of QUERY TYPE=DB (RCVINFO) | 69. Sample Listing of a RECON at the Active Site
| Output. . . . . . . . . . . . . . 385 | - GSG Record . . . . . . . . . . . 490
32. DSECT of DSPAPQRI . . . . . . . . . 386 | 70. Sample Listing of a RECON at the Active Site
33. DSECT of DSPAPQAL . . . . . . . . 386 | - SSYS Record . . . . . . . . . . . 491
34. DSECT of DSPAPQIC . . . . . . . . . 387 | 71. Sample Listing of a RECON at the Active Site
35. DSECT of DSPAPQRV . . . . . . . . 388 | - BACKOUT Record . . . . . . . . . 491
36. DSECT of DSPAPQRR . . . . . . . . 389 | 72. Sample Listing of a RECON at the Active Site
| 37. Format of QUERY TYPE=DB (Database Not | - CAGRP and CA Records . . . . . . . 492
| Found) Output . . . . . . . . . . . 389 | 73. Sample Listing of a RECON at the Active Site
| 38. DSECT of DSPAPQNF . . . . . . . . 390 | - DBGRP, DBDSGRP, and RECOVGRP
| 39. Format for QUERY TYPE=DBDSGROUP, | Records . . . . . . . . . . . . . 493
| DBGROUP, RECOVGROUP Output . . . . 393 | 74. Sample Listing of a RECON at the Active Site
40. DSECT of DSPAPQDG . . . . . . . . 394 | - DB (IMS) and Related Records . . . . . 494
| 41. Format for QUERY TYPE=CAGROUP Output 395
© Copyright IBM Corp. 1974, 2007 v

| 75. Sample Listing of a RECON at the Active Site | 81. Sample Listing of a RECON at the Tracking
| - DB (HALDB and PART) and Related | Site - BACKOUT Record . . . . . . . . 516
| Records . . . . . . . . . . . . . 496 | 82. Sample Listing of a RECON at the Tracking
| 76. Sample Listing of a RECON at the Active Site | Site - CAGRP and CA Records . . . . . . 517
| - DB (FP) and Related Records . . . . . . 507 | 83. Sample Listing of a RECON at the Tracking
| 77. Sample Listing of a RECON at the Tracking | Site - DBDSGRP Records . . . . . . . . 518
| Site - RECON Status Record . . . . . . 508 | 84. Sample Listing of a RECON at the Tracking
| 78. Sample Listing of a RECON at the Tracking | Site - DB (IMS) and Related Records . . . . 519
| Site - Log Records . . . . . . . . . . 509 | 85. Sample Listing of a RECON at the Tracking
| 79. Sample Listing of a RECON at the Tracking | Site - DB (HALDB and PART) and Related
| Site - GSG Record . . . . . . . . . . 515 | Records . . . . . . . . . . . . . 521
| 80. Sample Listing of a RECON at the Tracking | 86. Sample Listing of a RECON at the Tracking
| Site - SSYS Record . . . . . . . . . . 516 | Site - DB (FP) and Related Records . . . . 532
vi DBRC Guide and Reference

Tables
1. Licensed Program Full Names and Short Names x | 24. Return and Reason Codes for TYPE=OLDS
2. Results of GENJCL.IC Processing When | Query Requests . . . . . . . . . . . 409
GENMAX and RECOVPD are Specified with | 25. Return and Reason Codes for TYPE=RECON
REUSE . . . . . . . . . . . . . . 40 | Queries . . . . . . . . . . . . . 414
3. Results of GENJCL.IC Processing When | 26. Return and Reason Codes for TYPE=SUBSYS
GENMAX and RECOVPD are Specified with | Query Requests . . . . . . . . . . . 419
NOREUSE . . . . . . . . . . . . . 41 | 27. Return and Reason Codes for RELBUF 424
| 4. DSID DCB Numbers for the A-J, L, and X and | 28. Return and Reason Codes for the
| the M-V and Y Data Sets . . . . . . . . 51 | STARTDBRC Request . . . . . . . . . 428
| 5. Data Sharing Between the Releases. . . . . 52 29. Return and Reason Codes for the STOPDBRC
6. Determining Which RECON Data Sets Are Request . . . . . . . . . . . . . 432
Accessed . . . . . . . . . . . . . 62 30. Symbolic Keywords for All Supported
7. GENJCL Commands and What They Generate 83 Utilities . . . . . . . . . . . . . 435
8. Records That Can Be Selected Using the 31. Symbolic Keywords for Log Archive Utility 436
%SELECT Keyword . . . . . . . . . . 90 32. Symbolic Keywords for Database Change
9. Parameter Definitions for HALDB Partition Accumulation Utility . . . . . . . . . 437
and Master . . . . . . . . . . . . 144 33. Symbolic Keywords for Log Recovery Utility 438
10. CHANGE.DBDS for HALDBs . . . . . . 152 34. Symbolic Keywords for Database Image Copy
11. Supported dbname specifications for Utilities . . . . . . . . . . . . . 438
HALDBs on CHANGE.DBDSGRP command 35. Symbolic Keywords for Database Recovery
parameters . . . . . . . . . . . . 161 (Receive) Utility. . . . . . . . . . . 440
| 12. Service Level IDs and Associated Required 36. Symbolic Keywords for Database Recovery
| Maintenance . . . . . . . . . . . . 181 Utility - Recovery (RECOVJCL) . . . . . 442
13. Supported dbname specifications for 37. Fields Present in the RECON Record 533
HALDBs on INIT.DBDSGRP command 38. Fields Present in a Log Record . . . . . . 537
parameters . . . . . . . . . . . . 277 39. Fields Present in the LOGALL Record 539
14. Parameters of NOTIFY.PRILOG (for OLDS) 40. Fields Present in an Online Log Record 540
Command for Open, Switch, and Close . . . 318 41. Fields Present in a GSG Record . . . . . 541
15. Parameters of NOTIFY.PRILOG (for RLDS) 42. Fields Present in a SSYS Record . . . . . 542
Command for Open, EOV, and Close . . . 322 43. Fields Present in a BACKOUT Record 543
16. Parameters of NOTIFY.PRILOG (SLDS or 44. Fields Present in a CAGRP Record . . . . 544
TSLDS) Command for Open, EOV, and Close . 327 45. Fields Present in a CA Record . . . . . . 544
17. Parameters of NOTIFY.SECLOG (for OLDS) 46. Fields Present in the DBDSGRP Record 546
Command for Open, Switch, and Close . . . 336 47. Fields Present in the DB (IMS) Record 547
18. Parameters of NOTIFY.SECLOG (for RLDS) | 48. Fields Present in the DB (HALDB) Record 549
Command for Open, EOV, and Close . . . 339 49. Fields Present in the DB (PART) Record 550
19. Parameters of NOTIFY.SECLOG (for SLDS or 50. Fields Present in the DB (Fast Path) Record 554
TSLDS) Command for Open, EOV, and Close . 343 51. Fields Present in the DBDS (non-Fast Path)
| 20. Return and Reason Codes for Record . . . . . . . . . . . . . . 555
| TYPE=BACKOUT Query Requests . . . . 364 52. Fields Present in the DBDS (Fast Path) Record 556
| 21. Return and Reason Codes for TYPE=DB 53. Fields Present in the ALLOC Record . . . . 560
| Queries . . . . . . . . . . . . . 370 54. Fields Present in the IMAGE Record . . . . 561
| 22. Return and Reason Codes for 55. Fields Present in the REORG Record 562
| TYPE=xxxxGROUP Query Requests . . . . 392 56. Fields Present in the RECOV Record 563
| 23. Return and Reason Codes for TYPE=LOG 57. Resource Names for Command Authorization 565
| Query Requests . . . . . . . . . . . 402
© Copyright IBM Corp. 1974, 2007 vii

viii DBRC Guide and Reference
About This Book
This information is available as part of the Information Management Software for
z/OS® Solutions Information Center at http://publib.boulder.ibm.com/infocenter/
imzic. A PDF version of this information is available in the information center.
This book describes the administrative and operational tasks associated with the
IMS™ Database Recovery Control facility (DBRC). DBRC provides tools for tracking
information used during database recovery. This book is for system and database
administrators who are responsible for design, operation, and recovery procedures
for installation.
With IMS Version 9, you can reorganize HALDB partitions online, either by using
the integrated HALDB Online Reorganization function or by using an external
product. In this information, the term HALDB Online Reorganization refers to the
integrated HALDB Online Reorganization function that is part of IMS Version 9,
unless otherwise indicated.
Prerequisite Knowledge
IBM® offers a wide variety of classroom and self-study courses to help you learn
IMS. For a complete list of courses available, go to the Education link off of the
IMS home page on the Web: 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 z/OS control programs
v VSAM file structure and VSAM Access Method Services (AMS)
How to Use This Book

This book is structured as both a guide and reference.
v Read Part 1, “How to Use DBRC,” on page 1 to familiarize yourself with how to
use DBRC and the DBRC utilities.
v Use Part 2, “DBRC Command Reference,” on page 119 to find information
regarding the syntax and explanations associated with the DBRC commands.
v Read Part 3, “DBRC Application Programming Interface (API) Reference,” on
page 351 to find information regarding the usage, syntax, and explanations
associated with the DBRC API requests.
v Use the Appendixes for additional reference information.
Related Reading
The following books in the IMS library contain information related to DBRC.
v For definitions of terminology used in this manual and references to related
information in other manuals, see the IMS Version 9: Master Index and Glossary.
© Copyright IBM Corp. 1974, 2007 ix

v For more information on upgrading the RECON data set from previous releases
of IMS, see the IMS Version 9: Release Planning Guide.
v For installation and initialization topics, see the:
– IMS Version 9: Installation Volume 1: Installation Verification
– IMS Version 9: Installation Volume 2: System Definition and Tailoring
v For information on database and system administration, see the:
– IMS Version 9: Administration Guide: Database Manager
– IMS Version 9: Administration Guide: System
v For information on operating procedures, see the IMS Version 9: Operations Guide.
v For information on system utilities, see the IMS Version 9: Utilities Reference:
System.
v For information on the utilities used in database recovery, see the IMS Version 9:
Utilities Reference: Database and Transaction Manager.
v For information on the RECON I/O exit routine, see the IMS Version 9:
Customization Guide.
v For diagnostic information and messages, see the:
– IMS Version 9: Diagnosis Guide and Reference
– IMS Version 9: Messages and Codes, Volume 1 and IMS Version 9: Messages and
Codes, Volume 2
IBM Product Names Used in This Information

In this information, the licensed programs shown in Table 1 are referred to by their
short names.
Table 1. Licensed Program Full Names and Short Names
Licensed program full name Licensed program short name
IBM Application Recovery Tool for IMS and Application Recovery Tool
DB2®
IBM CICS® Transaction Server for OS/390® CICS
IBM CICS Transaction Server for z/OS CICS
™
IBM DB2 Universal Database DB2 Universal Database
IBM DB2 Universal Database for z/OS DB2 UDB for z/OS
IBM Enterprise COBOL for z/OS Enterprise COBOL
IBM Enterprise COBOL for z/OS and Enterprise COBOL
OS/390
IBM Enterprise PL/I for z/OS and OS/390 Enterprise PL/I
IBM High Level Assembler for MVS & VM & High Level Assembler
VSE
IBM IMS Advanced ACB Generator IMS Advanced ACB Generator
IBM IMS Batch Backout Manager IMS Batch Backout Manager
IBM IMS Batch Terminal Simulator IMS Batch Terminal Simulator
IBM IMS Buffer Pool Analyzer IMS Buffer Pool Analyzer
IBM IMS Command Control Facility for IMS Command Control Facility
z/OS
IBM IMS Connect for z/OS IMS Connect
™
IBM IMS Connector for Java IMS Connector for Java
x DBRC Guide and Reference

Table 1. Licensed Program Full Names and Short Names (continued)
Licensed program full name Licensed program short name
IBM IMS Database Control Suite IMS Database Control Suite
IBM IMS Database Recovery Facility for IMS Database Recovery Facility
z/OS
IBM IMS Database Repair Facility IMS Database Repair Facility
IBM IMS DataPropagator for z/OS IMS DataPropagator
IBM IMS DEDB Fast Recovery IMS DEDB Fast Recovery
IBM IMS Extended Terminal Option Support IMS ETO Support
IBM IMS Fast Path Basic Tools IMS Fast Path Basic Tools
IBM IMS Fast Path Online Tools IMS Fast Path Online Tools
IBM IMS Hardware Data IMS Hardware Data Compression-Extended
Compression-Extended
IBM IMS High Availability Large Database IBM IMS HALDB Conversion Aid
(HALDB) Conversion Aid for z/OS
IBM IMS High Performance Change IMS High Performance Change
Accumulation Utility for z/OS Accumulation Utility
IBM IMS High Performance Load for z/OS IMS HP Load
IBM IMS High Performance Pointer Checker IMS HP Pointer Checker
for OS/390
IBM IMS High Performance Prefix Resolution IMS HP Prefix Resolution
for z/OS
IBM z/OS Language Environment® Language Environment
® ®
IBM Tivoli NetView for z/OS Tivoli NetView for z/OS
®
IBM WebSphere Application Server for WebSphere Application Server for z/OS
z/OS and OS/390
IBM WebSphere MQ for z/OS WebSphere MQ
IBM WebSphere Studio Application WebSphere Studio
Developer Integration Edition
IBM z/OS z/OS
IBM z/OS C/C++ C/C++
Accessibility Features for IMS Version 9

Accessibility features help a user who has a physical disability, such as restricted
mobility or limited vision, to use information technology products successfully.
Accessibility Features
The following list includes the major accessibility features in z/OS products,
including IMS Version 9. These features support:
v Keyboard-only operation.
v Interfaces that are commonly used by screen readers and screen magnifiers.
v Customization of display attributes such as color, contrast, and font size.
Note: The Information Management Software for z/OS Solutions Information

Center (which includes information for IMS Version 9) and its related
About This Book xi

publications are accessibility-enabled for the IBM Home Page Reader. You
can operate all features by using the keyboard instead of the mouse.
Keyboard Navigation
You can access IMS Version 9 ISPF panel functions by using a keyboard or
keyboard shortcut keys.
For information about navigating the IMS Version 9 ISPF panels using TSO/E or
ISPF, refer to the z/OS TSO/E Primer, the z/OS TSO/E User’s Guide, and the z/OS
ISPF User’s Guide. These guides describe how to navigate each interface, including
the use of keyboard shortcuts or function keys (PF keys). Each guide includes the
default settings for the PF keys and explains how to modify their functions.
Related Accessibility Information

Online documentation for IMS Version 9 is available in the Information
Management Software for z/OS Solutions Information Center.
IBM and Accessibility

See the IBM Accessibility Center at www.ibm.com/able for more information about
the commitment that IBM has to accessibility.
How to Send Your Comments

Your feedback is important in helping us provide the most accurate and highest
quality information. If you have any comments about this or any other IMS
information, you can take one of the following actions:
v Click the Feedback link located at the bottom of every page in the Information
Management Software for z/OS Solutions Information Center. The information
center can be found at http://publib.boulder.ibm.com/infocenter/imzic.
v Go to the IMS Library page at www.ibm.com/software/data/ims/library.html
and click the Library Feedback link, where you can enter and submit comments.
v Send your comments by e-mail to [email protected]. Be sure to include the
title, the part number of the title, the version of IMS, and, if applicable, the
specific location of the text on which you are commenting (for example, a page
number in the PDF or a heading in the Information Center).
xii DBRC Guide and Reference

Summary of Changes
| Changes to the Current Edition of This Book for IMS Version 9
| This edition includes technical and editorial changes.
Changes to This Book for IMS Version 9

New information on the following enhancements is included:
v Command Authorization for /RM Commands (see “DBRC Online Commands”
on page 122)
v Eliminate the DSPSLDRC Part from DBRC (PRISLD / SECSLD / PRITSLDS /
SECTSLDS now mapped by DSPLOGRC, see the RECON data set record
DSECTs listed in Appendix B, “Sample Listings from the RECON Data Set,” on
page 473)
v Fast Path Multiple Areas Shared VSO Structures (see “CHANGE.DBDS” on page
152, “INIT.DBDS” on page 271, and “DB (FP) and Related Records” on page 507)
v Sysgen Conditional Bind Removal (see “Defining DBRC to IMS” on page 19)
v Recommendations about “RECON Data Set Serialization Strategies” on page 58
v Chapter 1 (DBRC in the IMS Database Recovery Process) was completely
rewritten and renamed to Chapter 1, “Overview of DBRC,” on page 3.
v Some reorganization has occurred:
– Some sections from Chapter 3, “Considerations for a DBRC System,” on page
33 were moved and merged into Chapter 1, “Overview of DBRC,” on page 3.
– Chapter 2, “Database Recovery Control Utility (DSPURX00),” on page 27 was
moved to from being Chapter 4 to being Chapter 2.
– Appendix D (Invoking the Database Recovery Utility from your Program)
was merged into Chapter 2, “Database Recovery Control Utility
(DSPURX00),” on page 27.
v A terminology change has occurred. All instances of “simple keyword” have been
changed to “symbolic keyword”.
v HALDB Online Reorganization. See:
– “DBRC Considerations for HALDB Online Reorganization” on page 49
– “CHANGE.DB” on page 143
– “CHANGE.RECON” on page 179
– “GENJCL.IC” on page 233
– “GENJCL.OIC” on page 242
– “INIT.DB” on page 268
– “NOTIFY.IC” on page 314
– “NOTIFY.REORG” on page 332
– “NOTIFY.UIC” on page 346
– “Sample Listing of a RECON at the Active Site” on page 479
v DBRC Application Programming Interface (API). See:
– “DBRC Tasks” on page 4
– “Communicating with DBRC” on page 6
– Chapter 16, “Using the DBRC API,” on page 353
© Copyright IBM Corp. 1974, 2007 xiii

– Chapter 17, “DBRC Query Request,” on page 361
– Chapter 18, “DBRC Release Buffer Request,” on page 423
– Chapter 19, “DBRC Start Request,” on page 427
– Chapter 20, “DBRC Stop Request,” on page 431
Library Changes for IMS Version 9

Changes to the IMS Library for IMS Version 9 include the addition of one title, a
change of one title, organizational changes, and a major terminology change.
Changes are indicated by a vertical bar (|) to the left of the changed text.
The IMS Version 9 information is now available in the Information Management

Software for z/OS Solutions Information Center, which is available at
http://publib.boulder.ibm.com/infocenter/imzic. The Information Management
Software for z/OS Solutions Information Center provides a graphical user interface
for centralized access to the product information for IMS, IMS Tools, DB2
Universal Database (UDB) for z/OS, DB2 Tools, and DB2 Query Management
Facility (QMF™).
New and Revised Titles

The following list details the major changes to the IMS Version 9 library:
v IMS Version 9: IMS Connect Guide and Reference
The library includes new information: IMS Version 9: IMS Connect Guide and
Reference. This information is available in softcopy format only, as part of the
Information Management Software for z/OS Solutions Information Center, and
in PDF and BookManager® formats.
IMS Version 9 provides an integrated IMS Connect function, which offers a
functional replacement for the IMS Connect tool (program number 5655-K52). In
this information, the term IMS Connect refers to the integrated IMS Connect
function that is part of IMS Version 9, unless otherwise indicated.
v The information formerly titled IMS Version 8: IMS Java User’s Guide is now
titled IMS Version 9: IMS Java Guide and Reference. This information is available in
softcopy format only, as part of the Information Management Software for z/OS
Solutions Information Center, and in PDF and BookManager formats.
v To complement the IMS Version 9 library, a retail book, An Introduction to IMS by
Dean H. Meltz, Rick Long, Mark Harrington, Robert Hain, and Geoff Nicholls
(ISBN # 0-13-185671-5), is available from IBM Press. Go to the IMS Web site at
www.ibm.com/ims for details.
Organizational Changes
Organization changes to the IMS Version 9 library include changes to:
v IMS Version 9: Customization Guide
v IMS Version 9: IMS Connect Guide and Reference
v IMS Version 9: IMS Java Guide and Reference
v IMS Version 9: Messages and Codes, Volume 1
v IMS Version 9: Utilities Reference: System
| A new appendix has been added to the IMS Version 9: Customization Guide that
| describes the contents of the ADFSSMPL (also known as SDFSSMPL) data set.
| The IMS Connect messages that were in IMS Version 9: IMS Connect Guide and
| Reference have moved to IMS Version 9: Messages and Codes, Volume 1.
xiv DBRC Guide and Reference

| The IMS Connect commands that were in IMS Version 9: IMS Connect Guide and
| Reference have moved to IMS Version 9: Command Reference.
The chapter titled ″DLIModel Utility″ has moved from IMS Version 9: IMS Java
Guide and Reference to IMS Version 9: Utilities Reference: System.
The DLIModel utility messages that were in IMS Version 9: IMS Java Guide and
Reference have moved to IMS Version 9: Messages and Codes, Volume 1.
| To ease the transition of your security support from the Security Maintenance
| Utility (SMU) to RACF, new SMU to RACF conversion utilities have been
| introduced. These utilities are documented in a new part in the IMS Version 9:
| Utilities Reference: System.
Terminology Changes
IMS Version 9 introduces new terminology for IMS commands:
type-1 command
A command, generally preceded by a leading slash character, that can be
entered from any valid IMS command source. In IMS Version 8, these
commands were called classic commands.
type-2 command
A command that is entered only through the OM API. Type-2 commands
are more flexible than type-2 commands and can have a broader scope. In
IMS Version 8, these commands were called IMSplex commands or
enhanced commands.
Summary of Changes xv
xvi DBRC Guide and Reference
Part 1. How to Use DBRC
Chapter 1. Overview of DBRC . . . . . . . . 3 Concurrent Image Copy . . . . . . . . . 38
What Is DBRC? . . . . . . . . . . . . . 3 Creating Image Copy Data Sets for Future Use
DBRC Tasks . . . . . . . . . . . . . . 4 and Reuse . . . . . . . . . . . . . . 39
DBRC Components . . . . . . . . . . . . 4 Controlling the Number of Image Copies
RECON Data Set . . . . . . . . . . . . 4 Managed . . . . . . . . . . . . . . 39
Database Recovery Control Utility (DSPURX00) . 4 Recovery Period of Image Copy Data Sets and
Skeletal JCL . . . . . . . . . . . . . 5 GENMAX . . . . . . . . . . . . . . 40
When Should You Use DBRC? . . . . . . . . 5 Reusing Image Copy Data Sets . . . . . . . 41
| Communicating with DBRC . . . . . . . . . 6 HSSP Image Copy . . . . . . . . . . . 42
| DBRC Commands . . . . . . . . . . . 6 HISAM Copies (DFSURUL0 and DFSURRL0) . . 42
| DBRC API Requests . . . . . . . . . . . 6 Nonstandard Image Copy Data Sets . . . . . 43
DBRC Functions . . . . . . . . . . . . . 7 Frequency and Retention of Backup Copies. . . 43
Recording and Controlling Log Information . . . 7 Log Record Change Accumulation. . . . . . . 43
Recovering Databases . . . . . . . . . . 10 Condensing the Accumulated SLDS or RLDS
Recording Information About Opening and (Change Accumulation) . . . . . . . . . 44
Updating Databases . . . . . . . . . . 16 When Is Change Accumulation Required? . . . 45
Supporting Data Sharing . . . . . . . . . 16 DBDS Group Considerations . . . . . . . . 48
Supporting Remote Site Recovery . . . . . . 18 DB Groups . . . . . . . . . . . . . . 49
Supporting IMSplexes . . . . . . . . . . 18 | DBRC Considerations for HALDB Online
| Defining DBRC to IMS . . . . . . . . . . 19 | Reorganization . . . . . . . . . . . . . 49
The IMSCTRL Macro . . . . . . . . . . 19 | GENJCL.IC and GENJCL.OIC Command
IMS.PROCLIB Execution-Parameter Members . . 19 | Considerations . . . . . . . . . . . . 50
IMS Procedures and DBRC . . . . . . . . 19 | NOTIFY.IC and NOTIFY.UIC Command
DBRC Procedure . . . . . . . . . . . 20 | Considerations . . . . . . . . . . . . 50
Initializing the RECON Data Set . . . . . . 20 | Records Used in HALDB Online Reorganization 50
Registering Databases and Database Data Sets . . . 20 | RSR Tracking System . . . . . . . . . . 52
Planning for Recovery . . . . . . . . . . . 21 | Maintaining Recovery-Related Records . . . . 52
Setting Up Recovery Mechanisms . . . . . . 21 | The Online Reorganization Process . . . . . 53
Recovery Facilities . . . . . . . . . . . 22
Recovery without DBRC . . . . . . . . . 24 Chapter 4. Initializing and Maintaining the
Restart After an IMS Failure . . . . . . . . 24 RECON Data Set . . . . . . . . . . . . 55
Restart After a DBRC Failure . . . . . . . 25 Planning Considerations for the RECON Data Set 55
Recovery Involving IRLM Configurations . . . 25 Initializing the RECON Data Set for the First
Batch Backout . . . . . . . . . . . . 25 Time. . . . . . . . . . . . . . . . 56
Avoiding RECON Data Set Contention Problems 56
Chapter 2. Database Recovery Control Utility Initially Accessing the RECON Data Set . . . . . 62
(DSPURX00) . . . . . . . . . . . . . . 27 Records in the RECON Data Set . . . . . . . 63
What Is the Database Recovery Control Utility RECON Header Records . . . . . . . . . 64
(DSPURX00)? . . . . . . . . . . . . . . 27 Log Data Set Records . . . . . . . . . . 64
Input and Output for the Database Recovery Database Recovery Records . . . . . . . . 65
Control Utility . . . . . . . . . . . . . 27 Maintaining the RECON Data Set . . . . . . . 72
Invoking the Database Recovery Control Utility Backing Up the RECON Data Set . . . . . . 73
from Your Program . . . . . . . . . . . . 28 Deleting Unnecessary RECON Log Records . . 73
Example of Database Recovery Control Utility JCL 30 Reorganizing the RECON Data Set . . . . . 74
Replacing Damaged RECON Data Sets . . . . 75
Chapter 3. Considerations for a DBRC System 33 Recovering the RECON Data Set . . . . . . 76
General Considerations for Using DBRC. . . . . 33 Replacing a Discarded RECON Data Set . . . . 77
Data Set Naming Conventions . . . . . . . . 33 RECON Loss Notification. . . . . . . . . 78
Naming Convention for Image Copy Data Sets 34 Preserving the Integrity of the RECON Data Set
Naming Convention for Duplicate Image Copy with DBRC Command Authorization Support . . 78
Data Sets . . . . . . . . . . . . . . 34 Tracking Changes Made to the RECON Data Set . . 81
Naming Convention for Change Accumulation
Data Sets . . . . . . . . . . . . . . 34 Chapter 5. Skeletal JCL . . . . . . . . . . 83
Database Backup Copies . . . . . . . . . . 35 Generating JCL and User-Defined Output . . . . 83
The Image Copy Utilities (DFSUDMP0, Using IBM-Supplied Skeletal JCL . . . . . . . 84
DFSUDMT0, DFSUICP0) . . . . . . . . . 35 Writing Your Own Skeletal JCL . . . . . . . . 85
© Copyright IBM Corp. 1974, 2007 1

Contents of the Skeletal JCL Data Set . . . . . . 85
Skeletal JCL Syntax . . . . . . . . . . . . 86
Symbolic Keywords . . . . . . . . . . 86
Using Control Keywords . . . . . . . . . 88
Writing Control Keywords . . . . . . . . 94
Understanding Skeletal JCL Default Members 103
Chapter 6. Hints and Tips for DBRC . . . . . 107

Changing the RECON Data Set to Output Time
Stamps in Local Time of Origin . . . . . . . 107
Locating the Last SLDS Stop Time in RECON . . 108
Adjusting GENMAX When It Is Reached or It Is
Too High . . . . . . . . . . . . . . . 109
Solutions When GENMAX is Too Low . . . . 109
Solution When GENMAX is Too High . . . . 110
Getting PRILOG Compression to Work . . . . . 110
Getting Notified When the PRILOG Record
Exceeds the Maximum Record Size . . . . . . 111
Closing an Open Online PRILOG . . . . . . . 111
Deleting Log Records . . . . . . . . . . . 112
Working with Subsystem Records (SSYS) . . . . 113
Naming Conventions for SSIDs in RECON
Subsystem Records . . . . . . . . . . 113
Batch Backout . . . . . . . . . . . . 113
Deleting a Subsystem Record . . . . . . . 113
Subsystem Record Size . . . . . . . . . 114
Removing Authorization Inconsistency Between the
SSYS from DB/AREA Records . . . . . . . . 114
Getting Change Accumulation to Start Processing
Logs Again . . . . . . . . . . . . . . 114
Getting Change Accumulation Working When It
States Nothing to Process . . . . . . . . . 114
Moving Log Data Sets . . . . . . . . . . 115
Cataloging Data Sets . . . . . . . . . . . 115
Performing Multiple Cold Starts in a Test
Environment . . . . . . . . . . . . . 116
Avoiding Some Causes of RECON Data Set
Enqueue Problems. . . . . . . . . . . . 117
In a Shared DASD Environment . . . . . . 117
In a Non-Shared DASD Environment . . . . 118
2 DBRC Guide and Reference

Chapter 1. Overview of DBRC
This chapter provides an overview of the IMS Database Recovery Control facility
(DBRC) and a discussion of the interactions between IMS and DBRC.
In This Chapter:
v “What Is DBRC?”
v “DBRC Tasks” on page 4
v “DBRC Components” on page 4
v “When Should You Use DBRC?” on page 5
v “Communicating with DBRC” on page 6
v “DBRC Functions” on page 7
v “Defining DBRC to IMS” on page 19
v “Registering Databases and Database Data Sets” on page 20
v “Planning for Recovery” on page 21
What Is DBRC?
| DBRC is an integral part of IMS. IMS relies on DBRC to:
| v Record and manage information about many items. DBRC keeps this
| information in a set of VSAM data sets that are collectively called the RECovery
| CONtrol (RECON) data set.
| v Advise IMS (based on the information in the RECON data set) about how to
| proceed for certain IMS actions.
| Specifically, DBRC:
| v Helps you ensure IMS system and database integrity by recording and
| managing information associated with the logging process.
| v Assists IMS in the restart process by notifying IMS which logs to use for restart.
| v Assists IMS to allow or prevent access to databases in data-sharing
| environments by recording and managing database authorization information.
| v Facilitates database and log recovery by:
| – Controlling the use and integrity of the information in the logs.
| – Recording and maintaining information about the databases and logs in the
| RECON data set.
| – Generating and verifying the Job Control Language (JCL) for various IMS
| utility programs.
| v Supports Extended Recovery Facility (XRF) by identifying (in the RECON data
| set) if the subsystem is XRF capable.
| v Supports Remote Site Recovery (RSR) by containing the RSR complex definition
| in the RECON data set and providing other services associated with controlling
| RSR.
| v Supports IMSplexes by notifying all DBRCs in the same IMSplex when one of
| the DBRCs performs a RECON data set reconfiguration.

DBRC overview
DBRC Tasks
DBRC automatically performs the following tasks:
v Records and manages information about logs for IMS
v Records recovery information in the RECON data set
v Verifies that database utilities have the correct input
v Controls the recovery of databases that are registered with DBRC
v Controls the access authorization information for the control and serialization of
shared databases
You can perform the following tasks and more when you initiate them by passing
commands or requests to DBRC:
| v Start or stop the DBRC application programming interface (API)
v Record recovery information in the RECON data set
v Generate JCL for various IMS utilities and generate user-defined output
v List general information in the RECON data set
| v Gather specific information from the RECON data set
Related Reading:
v See “Recording and Controlling Log Information” on page 7 for additional
information about DBRC’s logging support.
v See “Supporting Data Sharing” on page 16 for additional information about
DBRC’s data sharing support.
| v See Part 2, “DBRC Command Reference,” on page 119 for detailed information
| about the DBRC commands.
| v See Part 3, “DBRC Application Programming Interface (API) Reference,” on page
| 351 for detailed information about the DBRC API requests.
DBRC Components
DBRC includes the following components, which are introduced in this section:
v “RECON Data Set”
v “Database Recovery Control Utility (DSPURX00)”
v “Skeletal JCL” on page 5
RECON Data Set

DBRC stores recovery-related information in the RECON data sets.
| Recommendation: Define three VSAM KSDSs for the RECON data sets when you
| install DBRC. The first two data sets are active data sets; the third one is a spare.
| The second active data set is a copy of the first. For most purposes, you can think
| of the two active RECON data sets as if they were a single data set, the RECON
| data set.
Related Reading: These data sets are described in detail in Chapter 4, “Initializing
and Maintaining the RECON Data Set,” on page 55.
Database Recovery Control Utility (DSPURX00)

Use the Database Recovery Control utility to issue DBRC commands.
The DBRC commands allow you to perform all of the following tasks:
DBRC overview
v List the information in the RECON data set

v Update the information in the RECON data set
v Use the information in the RECON data set to generate jobs for the IMS utilities
Related Reading: The details for using the Database Recovery Control utility can
be found in Chapter 2, “Database Recovery Control Utility (DSPURX00),” on page
27.
Skeletal JCL
DBRC uses partitioned data set (PDS) members as input models (or templates) for
generating input for some of the recovery utilities. These PDS members are
distributed with IMS and are called skeletal JCL.
DBRC uses the skeletal JCL, information from the RECON data set, and
instructions from a GENJCL command to generate the JCL and control statements
that are needed to correctly run some of the recovery utilities. Modify the skeletal
JCL to reflect your installation’s system configuration.
Related Reading: For more information about skeletal JCL, see Chapter 5, “Skeletal
JCL,” on page 83.
IMS provides PDS members that contain skeletal JCL statements. These PDS
members are called skeletal JCL execution members and can be found in the
IMS.SDFSISRC target library.
The IMS Installation Verification Program (IVP), customizes the skeletal JCL
execution members and places the customized members into the IMS.PROCLIB
procedure library. DBRC uses the members (from IMS.PROCLIB) to generate jobs
(JCL and control statements) for the IMS utilities listed in Table 7 on page 83. There
is also a skeletal JCL execution member, JOBJCL, that produces a JOB statement.
When Should You Use DBRC?

Most IMS configurations require DBRC, including:
v Online configurations: DB/DC, DCCTL, or DBCTL
v Data-sharing environments, including IMSplexes
v Configurations that use Extended Recovery Facility (XRF)
v Remote Site Recovery (RSR)
DBRC also plays a key role in managing the log data needed to restart and recover
IMS online subsystems.
Attention: DBRC is not required for IMS batch jobs and for some offline utilities.
However, if batch jobs and utilities that access registered databases are allowed to
run without DBRC, the recoverability and integrity of the databases could be lost.
Even if your configuration does not require the use of DBRC (such as in a
non-data sharing, non-RSR batch environment), you can simplify your recovery
process by using DBRC to supervise recovery and protect your databases.
Related Reading:
v IMS Version 9: Operations Guide provides detailed descriptions of recovery
procedures with and without DBRC.
Chapter 1. Overview of DBRC 5

DBRC overview
v “How DBRC Helps in Recovery” on page 12 further describes how DBRC helps
with database recovery.
| Communicating with DBRC

| Use DBRC commands or DBRC API requests to obtain services from DBRC.
| “DBRC Commands” and “DBRC API Requests” discuss these two topics in more
| detail.
| DBRC Commands
| Use DBRC batch and online commands to:
| v Add to, change, and delete information in the RECON data sets.
| v Generate the JCL and the control statements necessary to run the various IMS
| utilities used in database recovery.
| The following is a list of the DBRC batch commands:

| v BACKUP.RECON
| v CHANGE
| v DELETE
| v GENJCL
| v INIT
| v LIST
| v NOTIFY
| v RESET.GSG
| Use the Database Recovery Control utility (DSPURX00) to issue DBRC batch
| commands. This utility can process these commands while running either in a
| batch environment or as a TSO foreground program.
| A variation of some of the DBRC batch commands can be issued online using the
| /RMxxxxxx command (for example, /RMCHANGE DBRC='RECON'). Although most of the
| command examples in this book feature the DBRC batch commands, the online
| version (where appropriate) of the example command can be used instead.
| Related Reading: For more information about the DBRC commands, see Chapter 7,
| “DBRC Commands,” on page 121.
| DBRC API Requests

| Use DBRC API requests to:
| v Start and stop DBRC.
| v Query specific information from the RECON data set.
| The following is a list of the DBRC API requests:

| v STARTDBRC
| v QUERY
| v RELBUF
| v STOPDBRC
| Related Reading: For more information about the DBRC application programming
| interface and the API requests, see Chapter 16, “Using the DBRC API,” on page
| 353.

DBRC overview
DBRC Functions
The following sections describe DBRC’s major functions:
v “Recording and Controlling Log Information”
v “Recovering Databases” on page 10
v “Recording Information About Opening and Updating Databases” on page 16
v “Supporting Data Sharing” on page 16
v “Supporting Remote Site Recovery” on page 18
v “Supporting IMSplexes” on page 18
Recording and Controlling Log Information

| As IMS operates, it constantly records its activities in the IMS logs. The IMS logs
| contain information about:
| v IMS startups and shutdowns
| v Changes made to databases
| v Transaction requests received and responses sent
| v Application program initializations and terminations
| v Application program checkpoints
| v IMS system checkpoints
The IMS logs consist of the:

v Write-ahead data set (WADS)
v Online log data set (OLDS)
v System log data set (SLDS)
v Recovery log data set (RLDS)
Figure 1 shows the log data sets and restart data set (RDS) that IMS produces and
the RECON data set that DBRC creates and maintains.
Figure 1. Logs Produced for Recovery and Restart

DBRC overview
Related Reading: See the IMS Version 9: Operations Guide for detailed discussions
of the IMS logging process.
| After you have initialized DBRC, it participates in the IMS logging process by
| recording and controlling information about IMS’s logging activities. This
| information is recorded in the RECON data set. If you want DBRC to control the
| recovery of your database data sets (DBDSs), you must register them with DBRC.
| DBRC automatically records many items in the RECON data set, including:
| v Information about log data sets
| v Information about database data sets
| v Information about events, such as:
| – Database updates
| – Database authorizations
| – Creation of database image copies
| – Reorganizations of databases
| – Recoveries of databases
| – Archiving of an OLDS and creation of the corresponding SLDS and RLDS
| – Execution of the Log Recovery utility
| – Subsystem sign-on
| v Definitions and information about events for Remote Site Recovery
IMS uses this information for restarting itself and for database recovery jobs (if the
databases are registered with DBRC). DBRC also tracks the archiving requirements
of the OLDS and, if requested, generates and submits the JCL for archiving jobs.
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.
For logs produced by batch systems, you are not required to use DBRC. The
advantage of using DBRC for batch jobs is that DBRC records information about
all the log data sets that are produced by batch jobs and prevents batch update
jobs from executing if you specify a dummy or null log data set.
Attention: If registered databases are updated without DBRC control, DBRC

cannot correctly control recovery for the databases and database integrity can be
jeopardized.
Changing Log Records in the RECON Data Set

Use the CHANGE.PRILOG or CHANGE.SECLOG commands to modify the information
about OLDSs, RLDSs, or SLDSs in the log record of the RECON data set. Update
the log record to indicate when errors have occurred on the data sets or that
volume serial numbers have changed. You do not normally need to use these
commands.
Archiving an OLDS
Run the Log Archive utility to archive an OLDS to an SLDS so that IMS can reuse
the OLDS. How frequently you should archive depends on the load on the
subsystem and the number of log records written to the OLDSs.
The Log Archive utility always produces an SLDS. The SLDS contains all log
records that are required for both database recovery and for online IMS restart.

DBRC overview
You can ask the Log Archive utility to produce an RLDS in addition to an SLDS.
The RLDS contains only those log records that are required for database recovery.
If you request an RLDS, information about the output RLDS data sets is recorded
in the PRILOG record in the RECON data set and information about the SLDS
data sets is recorded in the PRISLD record. If you do not request an RLDS, the
same information about the SLDS data sets is recorded in both the PRILOG and
PRISLD records.
If there is a secondary OLDS, or if you request that dual logs be produced from a
single OLDS, the information about the secondary-log output is recorded in
corresponding SECLOG and SECSLD records.
Important: Log data sets that are output from IMS batch jobs are technically
SLDSs, but the information about them is recorded in the PRILOG and SECLOG
records.
Run the Log Archive utility by issuing the GENJCL.ARCHIVE command. DBRC then
determines which OLDSs are full, and generates the appropriate JCL.
Related Reading: See Member DFSVSMxx in the IMS Version 9: Installation

Volume 2: System Definition and Tailoring for more information on the ARCHDEF
statement and automatic archiving.
Recommendation: Whether you use automatic archiving or invoke archiving

yourself, make sure the archive jobs run as quickly as possible. The online
subsystem only reuses an OLDS after it has been archived. If the archive job is not
run and all the OLDS become full, the online subsystem waits. One way to ensure
that archive jobs run quickly is to use an initiator that runs with a fairly high
priority and is not used by many other users. This ensures that the archive jobs do
not remain on the internal reader queue for too long.
If DBRC has marked an OLDS in the RECON data set as having errors, the GENJCL
function does not submit it for archiving. If one of a pair of OLDSs has been
destroyed or is unavailable, you can choose to mark it in the RECON data set as
having errors.
The following references point to where you can find more information about
archiving log records.
Related Reading:
v See IMS Version 9: Operations Guide for more information about automatic,
manual and custom archiving of log records.
v See IMS Version 9: Utilities Reference: System for more information about
specifying entry points and running the Log Archive utility.
v Refer to IMS Version 9: Customization Guide for more information about the Log
Archive and the Logger exit routines.
DBRC Log-Related Commands

Use the following commands to perform DBRC log-related functions in your
operational procedures:
v CHANGE.PRILOG
v CHANGE.RECON
v CHANGE.SECLOG

DBRC overview
v DELETE.LOG
v GENJCL.ARCHIVE
v GENJCL.CLOSE
v LIST.LOG
v NOTIFY.PRILOG
v NOTIFY.SECLOG
In addition to the LIST.LOG command, you can use a Log or OLDS query API
request to retrieve log-related information from the RECON data set.
Related Reading: See the command chapters in Part 2, “DBRC Command

Reference,” on page 119 for descriptions of the commands and “Log Query” on
page 399 for the details of the Log and OLDS query requests.
Recovering Databases
This topic provides an overview of how databases are recovered. Included in this
topic are:
v “The Basic Steps of Database Recovery”
v “How DBRC Helps in Recovery” on page 12
The Basic Steps of Database Recovery

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 be
recovered:
1. Restore the database to the most current image copy.
2. Use the log data sets (or change accumulation data sets) to restore changes
made to the database since the image copy was made.
Definition: Change accumulation is the process of creating a compacted
version of one or more IMS log data sets by eliminating records not related to
recovery, and by merging multiple changes to a single segment into a single
change. For more information about change accumulation, see “Log Record
Change Accumulation” on page 43.
3. Back out any incomplete changes.
Figure 2 illustrates a simple database recovery.
Figure 2. IMS Database Recovery process
Information for a database recovery can come from any or all of the following
sources:
v Image copies of the database

DBRC overview
v Database reorganization data sets

v Log data sets (SLDSs and RLDSs)
v Change accumulation data sets
You can use DBRC to track all of these information sources, greatly simplifying the
task of database recovery.
Related Reading: Refer to IMS Version 9: Operations Guide for more information
about the recovery process.
If you register recoverable databases in the RECON data set, DBRC records the
association of the databases to the log data sets containing database change
records.
DBRC also records information about:

v Database image copies
v Reorganizations (except DEDB online reorganizations)
v Recoveries
v Change accumulations
v Backout
DBRC can generate JCL for executing a database recovery, because DBRC records
this information in the RECON data set. Whether you use the GENJCL commands to
generate JCL or provide the JCL yourself, DBRC uses information in the RECON
data set to determine exactly which data sets are required for input. The Database
Recovery utility runs only if DBRC verifies that the JCL is correct.
You can omit all logged changes after a certain time from the input by performing
a time-stamp recovery. A time-stamp recovery is equivalent to backing out the
omitted changes from the database.
Most time-stamp recoveries require DBRC in order to be successful. When you

involve DBRC in your request for a time-stamp recovery, DBRC selects the correct
logs and, at execution time, communicates to the Database Recovery utility where
to stop processing the input to correctly perform your request.
Figure 3 on page 12 shows how DBRC works with the Database Recovery utility.

DBRC overview
Figure 3. How DBRC Works With the Database Recovery Utility
Recommendation: Implement DBRC in phases, defining at first only a few

recoverable databases in the RECON data set. This allows you to gain experience
in the use of DBRC, and gives you an opportunity to assess, make, and test any
changes needed in your backup, recovery, and operational procedures.
How DBRC Helps in Recovery

DBRC is invoked by recovery tools and utilities to provide information about the
resources required for database recovery. These resources can include information
about image copies, logs, change accumulations, and database data sets.
DBRC can:
v Generate JCL that can be used to run various utilities (see “Generating Recovery
JCL” on page 13)
v Validate the input to those utilities (see “Validating Utility JCL” on page 14)
v Record the result (in the RECON data set) of running the utilities (see
“Recording the Result” on page 15)

DBRC overview
Generating Recovery JCL: You can use the GENJCL.RECOV command to generate
the JCL that is necessary to recover a registered database data set. Using
information recorded in the RECON data set, DBRC:
1. Selects the image copy data set to use for loading the most recent image copy
2. Selects the change accumulation and log data sets that are to be input to
applying all the changes that were logged since the image copy was created
If change accumulation input is required (because of data sharing), but it is not

present or usable, DBRC informs you of that fact and the GENJCL.RECOV command
fails.
The GENJCL.USER command can generate user-defined output, which can include
JCL. No skeletal JCL execution members are supplied to support the GENJCL.USER
command. If you want to enter GENJCL.USER commands, you must supply the
members to support them.
Issue the GENJCL command to request that DBRC generate JCL in batch or issue the
/RMGENJCL command online. When you enter either command, DBRC reads skeletal
JCL and replaces symbolic parameters with actual values based on the information
recorded in the RECON data set to build the appropriate JCL. For example, if you
request that DBRC generate JCL to recover a database, DBRC retrieves the skeletal
JCL member from the library and completes the JCL with information about the
latest image copy, change accumulation, and log data sets, if necessary. Your
databases must be registered in order for DBRC to generate JCL to process them.
The amount of time and effort required to recover a database can be significantly
reduced by using the GENJCL to generate the JCL and control statements necessary
for the recovery. Using the GENJCL command also eliminate the causes of many
recovery errors. You could spend a large amount of time during database
recoveries determining which input data sets should be provided in what order to
the Database Recovery utility.
When change accumulation data sets or PRILOG records (in the RECON data set)
are available, DBRC selects them rather than the SLDS for recovery. This results in
quicker database recoveries if you run the Database Change Accumulation
regularly. DBRC knows which log data sets are required and ensures that IMS
processes all volumes in the correct order. DBRC also selects the most recent image
copy for database recovery.
DBRC always selects the optimum input for the Database Recovery utility by using
change accumulation data sets whenever possible. If you have not used the
Database Change Accumulation utility, or if that utility did not process some log
data 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.
Related Reading:
v See IMS Version 9: Installation Volume 2: System Definition and Tailoring for more
information about the tailoring actions for IMS.PROCLIB members, the DBRC
procedure, and the JCLOUT and JCLPDS DD statements.
v See Chapter 5, “Skeletal JCL,” on page 83 for details about customizing your
own skeletal JCL and about the contents of IMS-supplied skeletal JCL.
Recommendation: For increased availability of data entry databases (DEDBs), use

the DEDB Area Data Set Create utility to provide additional usable copies of an

DBRC overview
online area. It does not provide backup copies for recovery. The DEDB Area Data
Set Create utility uses the RECON data set as part of its input.
Validating Utility JCL: When the a recovery utility processes a registered

database data set, the utility presents its input to DBRC for validation. Whether the
recovery JCL was created by you or by DBRC, DBRC verifies that the input JCL to
the utility is correct (according to the current information in the RECON data set).
It is possible, even if you created the JCL with the GENJCL command, that
intervening events could invalidate the input JCL before the utility is run.
DBRC is invoked by the following IMS utilities and services to validate input and
record the results:
v Index/ILDS Rebuild utility (DFSPREC0)
v Database Image Copy utility (DFSUDMP0)
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 HALDB online reorganization
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)
v /RECOVER commands
Figure 4 on page 15 shows DBRC’s role in running the previously mentioned

utilities.

DBRC overview
Figure 4. DBRC’s Role in Utility Execution
Related Reading:
v See IMS Version 9: Utilities Reference: Database and Transaction Manager for more
information on the IMS recovery utilities.
v See “NOTIFY.BKOUT” on page 311 for information about a related command,
which manually creates a BACKOUT record in the RECON data set.
When you run the Batch Backout utility (DFSBBO00), DBRC determines the
complete set of logs that are needed for a particular backout job. In addition,
DBRC manages information about the logs so that backout and restart jobs can be
easily coordinated.
Exception: DBRC does not verify the JCL input For the HD and the HISAM
Reorganization utilities, but does record information about their execution in the
RECON data set.
Recording the Result: When the recovery completes successfully, DBRC records
information about the recovery in the RECON data set. If you performed a
time-stamp recovery, DBRC records information about the range of omitted
changes.
Requirement: If a time-stamp recovery is performed within a database allocation

interval, you must immediately create an image copy to ensure a valid starting
point for subsequent recovery attempts. DBRC then prevents the changes from
being reapplied on any subsequent recovery.

DBRC overview
Recording Information About Opening and Updating

Databases
After IMS opens a database, DBRC passes back the RECON data set initialization
token (RIT) and any extended error queue elements (EEQEs) associated with each
DBDS. The RIT allows IMS to determine whether the database has been used
without DBRC or whether the database has been controlled by a different RECON
data set.
Related Reading: See IMS Version 9: Operations Guide for information on EEQEs.
When changes to DBDSs and areas occur, DBRC records information about these
changes in the RECON data set. DBRC subsequently uses this information to
determine which log data sets might contain change records for a given DBDS or
area.
When a DBDS that is registered in the RECON data set is first opened for updates
(or allocated), IMS tells DBRC to create an ALLOC record. In the case of a DEDB
area, the ALLOC record is created when the area is first opened for update. The
ALLOC record identifies the DBDS or area and contains the time stamp of the first
update and the open time stamp of the corresponding PRILOG.
When DBRC creates the ALLOC record, DBRC also enters the name of the DBDS
or area being changed in the LOGALL record for the PRILOG that is active at the
time of the change.
When you de-allocate (close) a DBDS or area using a /DBRECOVERY command from
the operator console of the online IMS subsystem, DBRC writes a de-allocation
time stamp in the ALLOC record. If no de-allocation time is recorded, DBRC uses
the closing time of the associated log as the de-allocation time. Thus the RECON
data set contains a list of the names of 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 a specific DBDS or area (ALLOC records) and a list
of the logs containing the changes.
Supporting Data Sharing

Data sharing requires that the databases be registered with DBRC. DBRC checks
that subsystems have authority to perform the requested task and that other
subsystems are not currently reserving the database.
Related Reading: See the IMS Version 9: Operations Guide and the IMS Version 9:
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 resource that can be
accessed for update by a single IMS system at a time. For area
resources this can also be called Area-level sharing.
Block level A database or DEDB area can be accessed by multiple IMS
subsystems concurrently. Data integrity is preserved for the IMS
subsystems that access the shared data. Within a database or area,
resources are reserved at the block level.
Definition:

DBRC overview
v For OSAM databases, the block is a physical data block stored on DASD. For
VSAM databases and DEDBs, the block is a control interval (CI).
Recording Data-Sharing Information in the RECON Data Set

DBRC records the following data-sharing information in the RECON data set 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 or DEDB area determines whether a request for
access is granted. DBRC allows you to establish one of four sharing levels.
The following sharing levels are defined using the INIT.DB command and modified
with the CHANGE.DB command.
SHARELVL 0 The database is not to be shared. The database can be authorized
for use by one IMS system at a time. SHARELVL 0 is equivalent to
specifying ACCESS=EX on the /START command.
SHARELVL 1 Sharing is at the database level. One IMS system can be authorized
for update at one time; any sharing systems can only be authorized
for read-only processing. Otherwise, the data sharing is for
multiple readers.
SHARELVL 2 Sharing is at the block level but only within the scope of a single
IRLM and a single z/OS. Sharing requires that IMS subsystems
sharing a database use the same RECON data set. Multiple IMS
systems can be authorized for update or read processing.
SHARELVL 3 Sharing is at the block level by multiple IMS subsystems on
multiple Realms. Multiple IMS systems can be authorized for
non-exclusive access. The IMSs can be on multiple z/OS images
using different IRLMs.
Note:
| To ensure the integrity of databases in data sharing environments when

| batch jobs running without IRLM support access SHARELVL 3 databases,
| DBRC authorizes batch jobs that have update access only if all other IMS
| systems and batch jobs that are currently authorized by DBRC to the
| database have read-only access.
| If IRLM=N is specified in the IMSCTRL macro or DBBBATCH procedure,

| DBRC authorizes a batch job for update access to a database only if all other
| IMS systems and batch jobs that are currently authorized by DBRC to the
| database have read-only access.
| When a batch IRLM=N job has authorization for update, authorization for
| an online system or other batch job fails unless it is for read-only access.

DBRC overview
Supporting Remote Site Recovery

DBRC assists you with the definition and management of IMS components in the
RSR complex. In support of RSR, DBRC provides:
v Commands to define, update, and display the status of the RSR complex.
The RECON data set contains the definition of an RSR complex.
Related Reading: See the IMS Version 9: Operations Guide and the IMS Version 9:
Administration Guide: System for more information about RSR.
v Services that are used by an active subsystem to identify the tracking subsystem
and 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 database
component whether the database is covered by RSR. If the databases are being
tracked by RSR, the active subsystem sends its log data to the tracking
subsystem.
v Services used by a tracking subsystem to record information about log data that
is received from an active subsystem.
As logs are received and stored at the tracking site, DBRC records the receipt of
the 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) or
Recovery level tracking (RCVTRACK).
– Maintains log data set information for online forward recovery.
– Records which database change records have actually been applied to the
covered databases.
v Services to assist in the takeover process
During a remote takeover, DBRC changes the state information of the registered
databases at the new active site to indicate that they are now the active
databases.
Related Reading: See the IMS Version 9: Administration Guide: System for more
information on controlling database recovery in an RSR environment.
Supporting IMSplexes
When an I/O error occurs on a RECON data set in an IMSplex and a spare data
set is available, the instance of DBRC that noticed the error copies the good
RECON data set to the spare, activates the spare, and deallocates the original
RECON data set.
At this point in the processing, the DBRC that noticed the I/O error can
automatically notify the other DBRCs in the IMSplex about the reconfiguration.
Then, after the original RECON data set is deallocated, it can be deleted and
redefined as the spare RECON data set.
Related Reading: See the IMS Version 9: Common Service Layer Guide and Reference
for more information about IMSplexes.

DBRC overview
| Defining DBRC to IMS

| You initialize DBRC as part of the IMS system definition process. This section
| provides a brief overview of the requirements for creating and executing a DBRC
| region.
Related Reading:
v Refer to IMS Version 9: Installation Volume 1: Installation Verification and IMS
Version 9: Installation Volume 2: System Definition and Tailoring for a complete
description of IMS installation procedures and requirements.
v See Chapter 4, “Initializing and Maintaining the RECON Data Set,” on page 55
for information on creating and allocating the RECON data set.
IMS online systems always use DBRC; you cannot override this.
You can choose whether IMS batch jobs use DBRC. But you must understand that
certain functions, such as data sharing, cannot be used without DBRC.
| Batch and utility regions can use the DFSIDEF0 module during initialization. In
| DFSIDEF0, you can set the DBRC= keyword to YES, NO, or FORCE. The
| DFSIDEF0 module that is shipped in the IMS.ADFSSMPL library contains a batch
| and utility region default of DBRC=YES. This value is coded on the DFSIDEF
| macro.
| You are not required to use the DFSIDEF0 module. If you do not use the module
| or if the module cannot be loaded at initialization time, IMS defaults to
| DBRC=YES. Therefore, if DBRC is to be used for your batch and utility regions,
| then creating the DFSIDEF0 module is not required.
| Related Reading: For more information about the DFSIDEF0 module, see the IMS
| Version 9: Installation Volume 2: System Definition and Tailoring.
The IMSCTRL Macro

| As of IMS Version 9, the DBRC= parameter on the IMSCTRL macro is ignored by
| IMS.
Use the DBRCNM= parameter to request that IMS create a cataloged DBRC
procedure.
Place DBRC’s load modules into a load library that is in the normal load library
search sequence for your IMS load modules, for example, IMS.SDFSRESL.
IMS.PROCLIB Execution-Parameter Members

You can override the DBRC procedure name specified in your system definition in
the DFSPBIMS, DFSPBDBC, and DFSPBDCC members.
IMS Procedures and DBRC

The EXEC parameter, DBRC=, determines whether DBRC is used in a batch
procedure. It is ignored by an online IMS.
The DBRCNM= parameter can be used to override the DBRC procedure name for
an online IMS execution.

DBRC overview
DBRC Procedure
IMS automatically starts the DBRC procedure by issuing a z/OS START command
during control region initialization. This procedure specifies parameters for the
DBRC region. DBRC runs in its own address space for an online IMS subsystem.
To include the DBRC procedure during system definition, copy the skeletal DBRC
procedure from IMS.PROCLIB to SYS1.PROCLIB. The member name must match
the name specified on the DBRCNM parameter in the IMSCTRL macro or the
applicable EXEC procedure.
If DBRCNM is specified in more than one place, or if DBRCNM is not explicitly

specified, the following order of precedence 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 the
IMSCTRL macro setting.
v DBRCNM=name defined in a JCL EXEC parameter overrides the IMS.PROCLIB
member setting.
Related Reading: See the IMS Version 9: Installation Volume 2: System Definition and
Tailoring for a complete description of the DBRC procedure and its parameters.
Initializing the RECON Data Set

Use the Access Method Services (IDCAMS) DEFINE CLUSTER command to create the
RECON data sets and then use the INIT.RECON command to initialize the RECON
data sets as usable by DBRC.
If you do not intend to register databases, the INIT.RECON command is the only
command you need to issue in order to initialize the data set.
Related Reading:
v See Chapter 4, “Initializing and Maintaining the RECON Data Set,” on page 55
for information about creating the RECON data set.
v See “Registering Databases and Database Data Sets” for information about
registering databases.
v See “INIT.RECON” on page 284 for detailed information about the INIT.RECON
command.
Registering Databases and Database Data Sets

The RECON data set must have a DB record for each database whose recovery
DBRC is to control.
If you want DBRC to control database recovery, you must register the databases in
the RECON data set. DBRC then records information about database updates and
about the corresponding log data sets that contain updated log records. DBRC also
records the creation of image copy and change accumulation data sets, and records
database recoveries and reorganizations that affect registered databases.
For non-HALDBs (High Availability Large Databases), use the INIT.DB and
INIT.DBDS commands to register databases in the RECON data set and to define
them as recoverable or non-recoverable. For HALDBs, you can use the INIT.DB and
INIT.PART commands, or the HALDB Partition Definition utility.

DBRC overview
For each non-HALDB database that you have registered, issue the INIT.DBDS
command to register all its data sets or DEDB areas. For DEDBs, use the INIT.ADS
command to identify the data sets within each area. An area can have up to seven
area data sets (ADSs).
Requirement: Utility jobs that issue either an INIT.DB or INIT.PART command (to
register a HALDB) or any INIT.DBDS command, require a ddname for the
IMS.DBDLIB data set that contains an entry for the HALDB DBD (or non-HALDB
DBDS) for which you are issuing the command. A ddname for the IMS.DBDLIB is
not needed for non-HALDB INIT.DB command.
Related Reading: See Chapter 12, “INIT Commands,” on page 263 for specifics
about 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 can
use the HALDB Partition Definition utility or the following DBRC commands;
CHANGE.DB, CHANGE.DBDS, CHANGE.PART, DELETE.PART, or DELETE.DB.
Related Reading:
v See the IMS Version 9: Administration Guide: Database Manager for an overview of
HALDBs and detailed information about how to create them.
v See the IMS Version 9: Utilities Reference: Database and Transaction Manager for
information about the HALDB Partition Definition utility.
v See Chapter 9, “CHANGE Commands,” on page 135 for information about the
CHANGE commands.
Planning for Recovery

Planning for recovery (in non-data sharing and data sharing environments)
involves these primary tasks:
v Setting up the mechanisms of recovery (logging, taking checkpoints, keeping
records)
v Setting up your operational procedures for situations that require recovery
The following sections describe some additional aspects of planning for recovery:
v “Setting Up Recovery Mechanisms”
v “Recovery Facilities” on page 22
v “Recovery without DBRC” on page 24
v “Restart After an IMS Failure” on page 24
v “Restart After a DBRC Failure” on page 25
v “Recovery Involving IRLM Configurations” on page 25
v “Batch Backout” on page 25
Setting Up Recovery Mechanisms

The logging and checkpoint mechanisms of online IMS subsystems in a
non-sharing environment are also active in a data sharing environment. These
include:
v System log data sets and the use of the WADS and restart data sets
v Program, system, and message-queue checkpoints

DBRC overview
v Making image copies of databases
The primary difference between non-sharing and data sharing environments is in

their degree of reliance on DBRC. DBRC helps control the data-sharing
environment; it does not merely keep records.
Specifically, the following items are different in a non-data sharing environment:

v Database reconstruction (forward recovery)
v Program-level (dynamic) backout
v Database backout
v IMS restart (with embedded recovery)
Related Reading: See the IMS Version 9: Operations Guide for detailed information
on recovery procedures in non-data sharing and data-sharing environments.
Recovery Facilities
The following recovery facilities behave differently in non-data sharing and
data-sharing environments:
v “Dynamic Backout”
v “Batch Backout Support”
v “Forward Recovery” on page 24
Also included in this section is “Limitations of DBRC Backout Support” on page
23.
Dynamic Backout
In non-data sharing and data-sharing environments, an online IMS subsystem
dynamically backs out the uncommitted database changes of an application
program and discards its uncommitted output messages under either of these
conditions:
v The program fails.
v The program requests backout with a rollback call.
In a data-sharing environment, however, IRLM locks and status indicators in the

RECON data set ensure integrity by protecting uncommitted changes from sharing
subsystems. Operation of the system and other programs continues uninterrupted.
about dynamic backout.
Batch Backout Support

DBRC 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 to track each unit-of-recovery (UOR)
for each database in need of backout. DBRC verifies logs that are input to the
Batch Backout utility.
BACKOUT records are created for online subsystems. BACKOUT records are not
created for DL/I batch subsystems unless dynamic backout was being used and it
failed.
Prior to performing an emergency restart with the COLDSYS parameter (/ERESTART

COLDSYS), run batch backout with either the COLDSTART or ACTIVE parameter.
After the batch backout completes, DBRC creates a BACKOUT record for all

DBRC overview
in-flight and indoubt UORs as candidates for backout. The next IMS restart
promotes candidate UORs to backout-needed status and DBRC sets BACKOUT
NEEDED=ON in the database records in the RECON data set.
When dynamic backout fails, a BACKOUT record is created with a UOR indicating
dynamic backout failure and DBRC sets BACKOUT NEEDED=ON in the database
record in the RECON data set.
When the databases are backed out successfully, DBRC resets the backout flags in
the database records (in the RECON data set) appropriately and updates the
BACKOUT records. When backout processing for all of the UORs have been
completed, DBRC deletes the BACKOUT record from the RECON data set.
For DBCTL, if you choose not to back out an unresolved indoubt UOR, use either
the DELETE.BKOUT or CHANGE.BKOUT command to remove the unresolved indoubt
UOR from the BACKOUT record in the RECON data set.
DBRC commands are available to update BACKOUT records if needed. The need
to make manual changes to the backout record should be minimal.
Attention: Use the DELETE.BKOUT or CHANGE.BKOUT commands with extreme caution

because you could compromise database integrity.
DBRC verifies the validity of the logs used as input to the Batch Backout utility.
DBRC checks the input log volumes to ensure that they are in the correct sequence,
that all the needed logs are provided, and that they are properly closed. When you
include ACTIVE or COLDSTART statements in the Batch Backout utility SYSIN
statement, DBRC performs an additional check to ensure all volumes related to
restart are included. For DL/I batch logs, a check is also performed to ensure that
the correct volumes are from the last batch execution.
Attention: If BYPASS LOGVER is included in the SYSIN statement of the Batch

Backout utility, then DBRC does not verify the input log and the Batch Backout
utility does not notify DBRC about the UORs. Existing UORs are updated when
backout processing has completed successfully.
Related Reading: See IMS Version 9: Operations Guide and IMS Version 9: Utilities
Reference: Database and Transaction Manager for more information about UORs, the
backout process, and the Batch Backout utility.
Limitations of DBRC Backout Support

Although DBRC’s backout support protects databases from damage caused by the
most common errors, the following list describes some other possible sources of
damage to databases:
v If an IMS subsystem abends and an /ERE COLDSYS command is issued before the
in-flight and indoubt UORs have been identified to DBRC (by a Batch Backout
run), the databases associated with those in-flights and indoubts are not
protected from erroneous updates until the first Batch Backout run using the
COLDSTART or ACTIVE statements.
v Including logs from multiple runs of a batch job in the same log data set (by
specifying DISP=MOD) makes log verification unreliable.
v You can modify the RECON data set with DBRC commands. Careless use of
these commands could lead to errors, such as:
– Allowing backouts that should not be performed.
– Allowing other subsystems access to databases that need to be backed out.

DBRC overview
v The Batch Backout BYPASS LOGVER control statement allows backouts to be

performed when information in the RECON data set indicates that the input log
is invalid or that the backouts are not needed. Careless use of this control
statement can cause backouts to be performed that should not be performed.
v Unregistered databases are not protected from being used while backout is
needed.
v Backing out a normally terminated job (that did not use IRLM) after a
time-stamp recovery was performed (to recover the database to a point in time
prior to this log) makes log verification unreliable. DBRC will erroneously
validate that the log can be used as input because the log being backed out is
the last log for this subsystem name (SSID).
Forward Recovery
The process of recovering a database in a data-sharing environment has certain
similarities to recovering a database in a non-data sharing environment. In both
environments, use DBRC for database recovery and use the following as input to
the recovery process:
v The most recent image copy of the lost database
v The recovery log data set (RLDS) or all pertinent system log data sets used since
that copy was made
Recommendation: Use the RLDS as input to the recovery process. The RLDS is a
more efficient input to the recovery process than the pertinent system log data sets
because the RLDS contains only database change log records.
If you are using the Database Recovery utility for forward recovery and block-level
data sharing is involved, you might require the additional step of change
accumulation.
Related Reading: See the IMS Version 9: Operations Guide for further discussion of
forward recovery.
Recovery without DBRC

If you perform any recovery-related actions offline when DBRC is not running,
such as making database image copies, problems could arise because DBRC would
not be notified of the changes in status. Therefore, DBRC must be specifically
informed of such changes. DBRC offers you several commands for this purpose.
about recovery without DBRC and its related commands.
Because restart is required, the Utility Control Facility (UCF) might have to be
used without DBRC being active. If you use UCF for any recovery-related work,
DBRC must be informed of status changes afterward.
Restart After an IMS Failure

Restart an IMS subsystem in a data sharing environment in the same way as in a
non-data sharing environment:
v If you can shut IMS down normally (a checkpoint shutdown using the
/CHECKPOINT PURGE, /CHECKPOINT DUMPQ, or /CHECKPOINT FREEZE commands), use
the /NRESTART command to restart IMS normally.
v If the IMS failed, you must use the /ERESTART command to perform an
emergency restart.

DBRC overview
In a data-sharing environment, if the associated IRLM also stops or fails, you must
first start IRLM before you start IMS in a block-level environment.
Related Reading: See the IMS Version 9: Operations Guide for more information
about restarting IMS after it fails.
Restart After a DBRC Failure

IMS knows whether its DBRC fails because DBRC runs under the control of IMS. If
a DBRC failure occurs, IMS terminates abnormally, attempts to flush its buffers,
and closes the system log. After correcting the DBRC problem, you can restart IMS
by issuing the /ERESTART command.
Recovery Involving IRLM Configurations

DBRC records IRLM status information in the subsystem record in the RECON
data set.
Related Reading: See Appendix B, “Sample Listings from the RECON Data Set,”
on page 473 and IMS Version 9: Operations Guide for information on the IRLM
status information that DBRC records in the subsystem record.
Batch Backout
Prior to executing an emergency restart with the COLDSYS parameter (/ERESTART
COLDSYS), run the Batch Backout utility with either the COLDSTART or ACTIVE
parameter. Provide DBRC with the names of the logs to protect registered
databases (that need 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 BACKOUT record.
Attention: Use the DELETE.BKOUT command with extreme caution. It deletes all
backout information for a subsystem from the RECON data set.

Chapter 2. Database Recovery Control Utility (DSPURX00)
In This Chapter:
v “What Is the Database Recovery Control Utility (DSPURX00)?”
v “Input and Output for the Database Recovery Control Utility”
v “Invoking the Database Recovery Control Utility from Your Program” on page
28
v “Example of Database Recovery Control Utility JCL” on page 30
What Is the Database Recovery Control Utility (DSPURX00)?

Use the Database Recovery Control utility to issue commands that build and
maintain the RECON data set, add information to the RECON data set, and
generate jobs for utilities.
Commands submitted to the Database Recovery Control utility have the same
general format. Each command is composed of a verb and a modifier (separated
by a period) and then followed by parameters.
Additionally, the Database Recovery Control utility is used to upgrade a RECON

data set from an earlier, supported IMS version using the CHANGE.RECON UPGRADE
command.
The Database Recovery Control utility runs as a standard z/OS job.
Related Reading:
v See “CHANGE.RECON” on page 179 and the IMS Version 9: Release Planning
Guide, GC17-7831 for more information on RECON data set conversion.
v See Chapter 7, “DBRC Commands,” on page 121 for information about
command syntax.
Input and Output for the Database Recovery Control Utility

Figure 5 on page 28 shows the input and output requirements for the Database
Recovery Control utility. Notes that describe the input and output in more detail
follow the figure.

Database Recovery Control Utility
Figure 5. Database Recovery Control Utility Input and Output
Notes to Figure 5:
1. The DBRC command (input to the Database Recovery Control utility)
2. The RECON data set (input to the Database Recovery Control utility)
3. The PDS, which contains the JCL and control statements for the utility that
DBRC uses to generate a job (input to the Database Recovery Control utility)
4. The data set that contains the database descriptions for the databases that are
under the control of DBRC (occasional input to the Database Recovery Control
utility)
5. Jobs created by GENJCL commands (output from the Database Recovery Control
utility)
6. The RECON data set, which might have been updated by the utility (output
from the Database Recovery Control utility)
7. One or more of the following (output from the Database Recovery Control
utility):
v A listing of the input commands
v Informational messages associated with their execution or diagnostic
messages explaining any failures and return codes
v A listing of each job that was created in the case of GENJCL commands
Invoking the Database Recovery Control Utility from Your Program

This section is intended to help you understand how to invoke the Database
Recovery Control utility from your program, using entry point DSPURXRT to
specify alternate ddnames for SYSPRINT, SYSIN, and IMS. You might want to use
different ddnames if your calling program already uses these ddnames and you
might want the Database Recovery Control utility to use different data sets.
DSPURXRT is invoked by your program through the ATTACH, LINK, or LOAD

and CALL macro instructions. The dynamic invocation of DSPURXRT enables
respecification of some of the ddnames normally used by DBRC. You may specify
an alternate ddname for SYSPRINT, SYSIN and IMS. See “Example of Database
Recovery Control Utility JCL” on page 30 for a description of these data sets. The

RECON1, RECON2, and RECON3 DD statements cannot be substituted and must

be supplied (if required) by your program. If there is no RECON1 DD statement,
the RECON data set will be dynamically allocated. Also, substitution is not
allowed for the JCLOUT and JCLPDS DD statements.
Related Reading: Refer to z/OS V1R3.0 MVS Programming: Assembler Services

reference Volume 1 and z/OS V1R3.0 MVS Programming: Assembler Services Reference
Volume 2 for more information on ATTACH, LINK, or LOAD and CALL macro
instructions.
| Unless stated otherwise, programs that invoke DBRC do not have to pass DBRC
| any parameters specified on the EXEC statement. DBRC will locate the parameter
| list passed by z/OS. The invoking program should not alter this parameter list.
DSPURXRT must be called in 31-bit mode. It executes in 31-bit mode and returns
to the caller in 31-bit mode with the return code set in register 15. Up to two
parameters may be passed on the CALL. The first parameter specifies the address
of an option that could be specified in the PARM parameter of the EXEC
statement. DSPURXRT currently does not support any options. This address must
point to a halfword of binary zeros. The second parameter specifies the address of
a list of alternate ddnames for standard data sets used during DSPURXRT
processing. If standard ddnames are to be used, the second parameter should
either point to a halfword of binary zeros or be omitted.
A processing program invokes DSPURXRT with the ATTACH, LINK, or LOAD,

and CALL macros. Before issuing the invoking macro, however, the program must
initialize the appropriate registers and operand list contents. The register contents
follow standard linkage conventions:
v Register 1 contains the address of the argument list.
v Register 13 contains the address of a save area.
v Register 14 contains the address of the return point.
v Register 15 contains the address of the entry point DSPURXRT.
The argument list pointed to by register 1 consists of up to two pointers to

parameters. The last word in the list must have the high order bit on, indicating it
is the last word. The first word is the address of options passed to DSPURXRT.
Currently, no options are recognized and this word must point to a halfword of
binary zeroes. See Figure 6 on page 30 for an illustration of the necessary registers
and operand list contents.
Chapter 2. Database Recovery Control Utility (DSPURX00) 29

Figure 6. Registers and Operand List Contents Needed To Invoke the Database Recovery
Control Utility
The second word is the address of the ddname list (see Figure 6 on page 30). The
ddname list consists of the following:
v A halfword containing the total length of the ddname list, including this
halfword.
v A reserved halfword.
v An eight-byte field containing the ddname to be used in place of SYSIN, or eight
bytes of blanks (X'40') if SYSIN is not to be substituted. The ddname must be left
justified and padded on the right with blanks if necessary.
v An eight-byte field containing the ddname to be used in place of SYSPRINT, or
eight bytes of blanks (X'40') if SYSPRINT is not to be substituted. The ddname
must be left justified and padded on the right with blanks if necessary.
v An eight-byte field containing the ddname to be used in place of IMS, or eight
bytes of blanks (X'40') if IMS is not to be substituted. The ddname must be left
justified and padded on the right with blanks if necessary.
Example of Database Recovery Control Utility JCL

Figure 7 on page 31 is a sample job that initializes the RECON data set and
registers one database with two DBDSs. Descriptions of the individual numbered
JCL statements are listed under Figure 7 on page 31.

//INITRCON JOB
1 //INIT04 EXEC PGM=DSPURX00
2 //STEPLIB DD DSN=IMS.SDFSRESL
3 //SYSPRINT DD SYSOUT=A
4 //*
5 //IMS DD DSN=IMS.DBDLIB
6 //JCLPDS DD DSN=IMS.JCLPDS
7 //JCLOUT DD DSN=IMS.JCLOUT
8 //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 7. Inputs and Outputs of the Database Recovery Control Utility
The numbers in the following list refer to the JCL statements illustrated in Figure 7.
1. EXEC Indicates the program to be executed.
2. STEPLIB Points to IMS.SDFSRESL, which contains the IMS nucleus and the
required action modules.
3. SYSPRINT Defines the destination of DBRC diagnostic messages and the
listing output. The destination can be a tape or DASD data set, a
printer, or it can be routed through the output stream (SYSOUT).
4. RECON DD statements for RECON1, RECON2, and RECON3 are omitted
so that the RECON data set is allocated dynamically.
5. IMS Defines the IMS DBDLIB data set. It is required only for the
INIT.PART commands; the INIT.DBDS commands; the NOTIFY.REORG
commands; the INIT.DB command, if you are initializing a HALDB;
and the CHANGE.DBDS commands, if you change a DBDS ddname or
area name; and the CHANGE.PART command if you change the
KEYSTRNG value.
6. JCLPDS, or the DD name you supply with the JCLPDS parameter
Defines the PDS containing skeletal JCL members. It is required
only for the GENJCL commands.
7. JCLOUT, or the DD name you supply with the JCLOUT parameter
Defines the data set which is to receive generated JCL. It is
required only for the GENJCL commands.
8. SYSIN Defines the source of input commands. SYSIN can be a tape or
DASD data set, a card reader, or it can be routed through the input
stream (DD * or DD DATA).
Chapter 2. Database Recovery Control Utility (DSPURX00) 31

The following are the input command statements:

9. INIT.RECON
Initializes the RECON data set with control information and a
default subsystem 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 of
three image copy data sets, which are to be predefined and are to
be reused when the GENMAX value is exceeded. GENJCL.IC and
GENJCL.RECOV commands issued for this DBDS uses the
user-specified skeletal JCL members of the JCLPDS instead of the
default members ICJCL and RECOVJCL.
12. INIT.IC Commands identify data sets to receive image copies of the DBDS
that was just defined. The data set names are specified using the
naming convention described in “Data Set Naming Conventions”
on page 33 The ICDSN2 parameter on the second INIT.IC
command identifies a duplicate image copy data set.
13. INIT.DBDS
Identifies a second DBDS for the database, for which a maximum
of four image copies is to be maintained. Image copy data sets are
not reused, but are deleted when the GENMAX value is exceeded.
14. INIT.CAGRP
Defines a change accumulation group that includes the two DBDSs
just defined. A maximum of two change accumulation data sets is
to be maintained for this group, which are to be predefined and
reused when the GRPMAX value is exceeded.
15. INIT.CA Commands identify change accumulation data sets that are
available for future use by the CA group just defined. They are
named according to the naming convention described in “Data Set
Naming Conventions” on page 33.

Chapter 3. Considerations for a DBRC System
This chapter discusses concepts under the following headings that might be helpful
for you to consider for your DBRC system.
In This Chapter:
v “General Considerations for Using DBRC”
v “Data Set Naming Conventions”
v “Database Backup Copies” on page 35
v “DBDS Group Considerations” on page 48
v “DB Groups” on page 49
v “Log Record Change Accumulation” on page 43
| v “DBRC Considerations for HALDB Online Reorganization” on page 49
This chapter also describes how to use DBRC to control these database-related and
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
General Considerations for Using DBRC

Be 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 reason
to register them.
v Logging is required for batch jobs that use DBRC and have update access.
v Never update the RECON data set information (such as for DBDSs or log data
sets) about a data set that is currently in use.
v Be sure to set the time-of-day (TOD) clock value in the host processors
accurately, or unpredictable results might occur in the RECON data set.
Data Set Naming Conventions

The use of z/OS catalog facilities for image copy and change accumulation data
sets is optional because DBRC always records volume serial information pertaining
to these data sets in the RECON data set. If you catalog image copy and change
accumulation data sets, they must have unique data set names.
DBRC provides a data set naming convention to help you generate unique data set
names for those image copy data sets (for HSSP image copies and concurrent
image copies, as well as standard image copies) and change accumulation data sets
that you define for future use.
If you use this convention all the time, uniqueness of your data set names is
assured. If you use the convention only occasionally, you are sent a message at the

DBRC Considerations
end of your job step that indicates that you did not follow the naming convention
and that duplicate data set names could exist in the RECON data set. DBRC
assumes that data set names specified in quotation marks do not follow the
naming convention. Therefore, DBRC does not check data set names surrounded
by quotation marks.
When you add records to the RECON data set that create data sets for one of the
recovery utilities to use in the future and you are using this data set naming
convention, you can specify either the fully-qualified data set name or simply the
abbreviation high-level-qualifier.*.low-level-qualifier (for example, ALPHA1.*.OMEGA).
You can use these abbreviated names on any INIT, CHANGE, DELETE, or NOTIFY.REORG
command of DBRC when you are specifying the name of a data set that follows
the naming convention. DBRC expands the abbreviated name to its fully-qualified
form before it accesses the RECON data set.
The following sections describe additional data set naming conventions:

v “Naming Convention for Image Copy Data Sets”
v “Naming Convention for Duplicate Image Copy Data Sets”
v “Naming Convention for Change Accumulation Data Sets”
Naming Convention for Image Copy Data Sets

The format for image copy data sets is:
high-level-qualifier.dbdname.ddname.IC.low-level-qualifier
high-level-qualifier
A character string that can be from 1 to 8 alphanumeric characters long.
The first character must be alphabetic.
dbdname
The database name of the DBDS for which the image copy data set is
being recorded in the RECON data set.
ddname
The data set ddname of the DBDS for which the image copy data set is
being recorded in the RECON data set.
IC Indicates that this is the image copy data set.
low-level-qualifier
A character string that can be from 1 to 8 alphanumeric characters long. It
must be unique for each DBDS and the first character must be alphabetic.
Naming Convention for Duplicate Image Copy Data Sets

The format for duplicate image copy data sets is:
high-level-qualifier.dbdname.ddname.IC2.low-qualifier
This format is identical to the convention for image copy data sets, except that the
IC2 field indicates that this is a duplicate image copy data set.
Naming Convention for Change Accumulation Data Sets

The format for change accumulation data sets is:
high-level-qualifier.cagrpname.CA.low-level-qualifier
high-level-qualifier
A character string that can be from 1 to 8 alphanumeric characters long.
The first character must be alphabetic.

DBRC Considerations
cagrpname
The name of the CA group for which you are creating the change
accumulation data set.
CA Indicates that this is a change accumulation data set.
low-level-qualifier
A character string that can be from 1 to 8 alphanumeric characters long
and must be unique for each CA group. The first character must be
alphabetic.
Database Backup Copies

When IMS takes a regular system checkpoint, it records internal control
information for DL/I (for Fast Path, IMS also records buffers and MSDBs), but it
does not record the external contents of the database. If the database is lost,
examining the last system 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 backup
copy is, the fewer log change records need to be processed during recovery, thus
reducing 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 access
method services to make the copy.
v The Database Image Copy 2 utility (DFSUDMT0) runs offline and invokes
DFSMS Concurrent Copy to make the copy.
v The Online Database Image Copy utility (DFSUICP0) runs online and uses IMS
services 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
DBRC to update essential information in the RECON data set. If you use a
supported image copy utility, DBRC records the image copies for registered
databases. DBRC also generates the JCL for the utility if you enter the GENJCL.IC or
GENJCL.OIC command.
You can also use various utilities supplied by the operating system to make your
backup copies; however, these do not interact with DBRC, and so you need to take
certain actions to notify DBRC of your non-standard image copies. See
“Nonstandard Image Copy Data Sets” on page 43 for a discussion of how to notify
DBRC about these data sets.
Related Reading: See IMS Version 9: Administration Guide: Database Manager for
more information on HSSP processing of DEDB areas.
The Image Copy Utilities (DFSUDMP0, DFSUDMT0, DFSUICP0)

IMS enables you to “take a picture” of your database before and after changes
have been made to the database. The “pictures” are called image copies. The term
refers to the fact that the copy is an as-is image; the image copy utilities do not
Chapter 3. Considerations for a DBRC System 35

Backup Considerations
alter the physical format of the database as they copy it. Image copies are backup
copies 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 image
copies of databases. All of the image copy utilities operate on data sets or DEDB
areas, so if a database is composed of multiple data sets or areas, be sure to supply
the utility with multiple specifications. You can request that one of the supported
image copy utilities produce both an image copy data set and a duplicate image
copy data set in one run of the utility.
Recommendation: Copy all data sets or areas belonging to a database at one time.
If you perform multiple recoveries in order to reset a database to a prior state,
recover all data sets belonging to the database and to all logically related databases
(including those related by application processing) to the same point to avoid
integrity problems.
Each of the image copy utilities provide the option to create backup copies without
taking databases and areas offline. You can use this capability to provide increased
database availability. Image copies taken while the database is available for
concurrent update processing by IMS applications are called concurrent image
copies or fuzzy image copies. Changes already made to the database by active
applications might be missing from the copy because the changes might not have
been physically written to the data set. These changes, however, have been written
to the log. In this case, it is necessary to go back to some earlier point in the logs
to ensure that all changes are applied. How far to go back depends on the type of
database and which image copy utility was used.
When the concurrent image copy option is not used, the database must be either
taken offline or made available only for ’read’ access and a consistent or ’clean’
image copy is taken. See “Concurrent Image Copy” on page 38 for more
information.
If the image copy was made while the database was not being accessed for update,
only changes that were logged after the run time of the copy are required.
When using these utilities, you have the option of creating one to four output
image copies. Only the Database Image Copy 2 utility allows three or four output
copies and only the first two output copies are recorded in the RECON data set.
The advantage of making multiple copies is that if an I/O error occurs on one
copy, the utility continues to completion on the other copies. Also, if one copy
cannot be read, you can perform recovery using another. The trade-off in deciding
whether to make multiple copies, is that performance can be degraded because of
the time required to write the additional copies.
DBRC works similarly with the three image copy utilities. The rules for
pre-definition and reuse of image copy data sets apply to all three. Each utility
calls DBRC:
v To verify the input to the utility (DBRC allows it to run only if the input is
valid.
v Calls DBRC to record information in the RECON data set about the image copy
data sets that it creates.

An image copy record in the RECON data set has the same format whether its
corresponding image copy data set was created by the Database Image Copy
utility, the Database Image Copy 2 utility, or by the Online Database Image Copy
utility.
Two different commands create image copy jobs:

v GENJCL.IC for the offline utilities Database Image Copy and Database Image
Copy 2
v GENJCL.OIC for the online utility Online Database Image Copy
When you run batch jobs without logging, take an image copy immediately
afterwards; do not count on rerunning the batch jobs, as part of a subsequent
recovery, in combination with the Database Recovery utility. The database could be
damaged by the combination because the batch processing is not guaranteed to be
physically repeatable.
Database Image Copy (DFSUDMP0)

Use the Database Image Copy (DFSUDMP0) utility to create data set copies of:
v HISAM databases
v HIDAM databases
v HDAM databases
v PHDAM (partitioned HDAM databases)
v PHIDAM (partitioned HIDAM) databases
v PSINDEX (partitioned secondary index) databases
v DEDB areas
The Database Image Copy runs offline. It supports a concurrent image copy (CIC)
option that enables you to create an image copy while the database remains online.
The CIC option can create image copies of OSAM data sets and VSAM Entry
Sequenced Data Sets (ESDSs). The Database Image Copy does not support creating
image copies of VSAM Key Sequenced Data Set (KSDSs).
To request a concurrent image copy, use the CIC keyword on the GENJCL.IC
command. Alternatively, you can specify the CIC parameter on the EXEC
statement for image copy job. DBRC must be used by the utility and you can only
take a concurrent image copy of a database that has been registered with DBRC.
When you run the Database Image Copy utility to take a consistent image copy
(CIC option not specified), DBRC is not required but is recommended. DBRC
ensures that there is no update activity against the database or area while the
utility is executing. If you run the utility without using DBRC you must make
certain that no updates occur to the database or area. You can issue a /DBDUMP
command or a/STOP AREA command, for example, to prevent updating of the
database or area by transactions in the system previously doing updates.
Database Image Copy 2 (DFSUDMT0)

The Database Image Copy 2 utility (DFSUDMT0) uses DFSMS Concurrent Copy to
take an image copy. It invokes DFSMS to dump the input data set using the
Concurrent Copy option. The output is recorded in the RECON data set and can
be used for database recovery in the same way as the output from either of the
other image copy 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 be copied by this utility must reside on hardware that supports the
Concurrent Copy option.

An optional COMPRESS parameter invokes the “compress” option in DFSMS

Concurrent Copy. The compress option enables you to reduce the storage space
required to hold the image copy; however, using the compress option increases the
CPU time that is required to perform the copy operation.
The Database Image Copy 2 utility provides greater database availability when
taking consistent image copies. The database needs to unavailable for update
processing for only a very short period of time while DFSMS establishes a
concurrent copy session. Update processing can then be resumed while the image
copy data sets are actually being written. The updates are not included in the
image copy.
This utility can also copy the database while it is being updated by IMS
applications. The image copy created in this case is a concurrent image copy. The
Database Image Copy 2 utility can copy all supported data set types, including
VSAM KSDSs, while the databases remain online.
Requirement: The Database Image Copy 2 utility must use DBRC and the
databases and areas being copied must be registered with DBRC. The utility can
create up to 4 output copies, but only the information about the primary and
secondary copies are recorded in the RECON data set.
The image copy output from the Database Image Copy 2 utility is in DFSMS dump
format, which is different than the format of the output of the other image copy
utilities. It is, however, directly usable as input to database recovery. Information
about the image copies are recorded in the RECON data set with image copy type
SMSCIC or SMSNOCIC.
Requirement: The Database Recovery utility must use DBRC when using the
SMSCIC or SMSNOCIC image copy data sets for recovery.
Online Database Image Copy (DFSUICP0)

Online Database Image Copy (DFSUICP0) runs as a BMP program in the online
IMS and DBCTL environments. You can use it for HISAM, HIDAM, HDAM,
PHDAM, PHIDAM, and PSINDEX databases only; it does not support areas. A
database being copied by this utility is available for updating by the IMS
subsystem in which the utility is executing. Other IMS subsystems cannot have
concurrent update access to the database.
If the database being copied is updated while the utility is running, a fuzzy image
copy is produced. Recovery with this image copy requires all logs starting with the
log that was in use when the Online Database Image Copy utility was started.
Concurrent Image Copy

IMS provides the capability to take an image copy of a database without taking
that database offline. This means the database can be updated while the image
copy is being 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 the database over a certain period of time rather than at one specific
instant in time. It is also called a ’concurrent image copy’ because the copy was
taken while update processing is happening.
The ability to take image copies while the databases are being updated by IMS
applications allows increased database availability. The offline image copy utilities,
Database Image Copy and Database Image Copy 2, provide an option to take a
concurrent image copy. A database being copied by the Online Database Image
Copy utility can be concurrently updated by the IMS subsystem in which the
utility is running (but not by other IMS subsystems). Image copies created by
HSSP processing are also ’fuzzy’ copies because the areas are available for update
processing while HSSP is running.
When a consistent image copy is input to database recovery, the recovery only
requires logs from after the image copy job completed. A concurrent image copy,
might not include updates that were made before the image copy process started
or while it was executing. Therefore, when a concurrent image copy is input to
recovery, logs from before the image copy process was started might have to be
supplied to database recovery.
Restrictions: The following restrictions apply to creating concurrent image copies:

v Only databases that are registered with DBRC are eligible for concurrent image
copying.
v The Database Image Copy utility (which can take consistent image copies
without using DBRC) must use DBRC when creating a concurrent image copy.
v Non-recoverable databases are not eligible for concurrent image copying because
there is no log data to complete the image copy.
Creating Image Copy Data Sets for Future Use and Reuse
Use the REUSE parameter to inform DBRC that you want to be able to define
image copy data sets and record them in the RECON data set for future use. You
define image copy data sets with the INIT.IC command. When processing the
GENJCL.IC command, DBRC selects one of the image copy data sets for use by the
image copy utility.
When the Database Image Copy utility uses an available image copy data set,
DBRC updates its record in the RECON data set with the time stamp of the run of
the Database Image 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 in
either the skeletal JCL member used in processing the GENJCL.IC command or in
the JCL that you produce yourself. When you specify NOREUSE, DBRC
dynamically sets the unit type of the output image copy data set. DBRC sets it to
the default unit type for the device as specified in the INIT.RECON and
CHANGE.RECON commands. Specify NOREUSE when you want more than two
DFSMS concurrent copies (you can have up to four).
If you do not specify REUSE, every time the image copy utility is run DBRC
deletes the oldest image record that exceeds both the GENMAX and RECOVPD
values. The image copy data set itself is not scratched-only its record in the
RECON data set is scratched. You must either scratch the data set or keep track of
it yourself, because DBRC is no longer aware of its existence.
If you are using the image copy option of HSSP for a DEDB area, the area must be
defined with the REUSE parameter and the data sets you predefine must be
cataloged.
Controlling the Number of Image Copies Managed

You can use the INIT.DBDS and the CHANGE.DBDS commands to specify how many
image 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. Duplicate
image 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 more
information about the RECOVPD parameter.
v See “INIT.DBDS” on page 271 for more information on the REUSE, NOREUSE,
GENMAX, and RECOVPD.
Recovery Period of Image Copy Data Sets and GENMAX

When you register a DBDS in the RECON data set, you specify the maximum
number of image copy generations for DBRC to record with the GENMAX
parameter of the INIT.DBDS command. When this number is exceeded, DBRC
discards the information relating to the oldest image copy. For example, if you take
image copies daily and want to keep four days of back level image copies, specify
a GENMAX of 4. However, in some emergency situations, you may take backup
copies more frequently, possibly three in one day.
To prevent DBRC from discarding information relating to the earlier copies, specify
the optional recovery period parameter (RECOVPD) to indicate the number of
days you want information retained. If the GENMAX limit is reached, but the
RECOVPD for the oldest image copy record has not expired, DBRC issues a
warning message (DSP0065I), and does not discard the record. If the DSP0065I
warning message appears frequently, you might need to tune the GENMAX or
RECOVPD values with the CHANGE.DBDS command.
| A recovery period is the minimum amount of time that information is maintained in

| the RECON data set. For example, if the recovery period of a DBDS or DEDB area
| is 14 days, DBRC maintains sufficient recovery-generation information 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 copy
data set.
Table 2 shows the results of GENJCL.IC processing when both GENMAX and
RECOVPD have been specified for a DBDS or area defined with the REUSE
parameter.
Table 2. Results of GENJCL.IC Processing When GENMAX and RECOVPD are Specified
with REUSE
Number of
Number of In-Use Image Age of Oldest
Image Data Sets Copies Image Copy GENJCL Result
=GENMAX =GENMAX <RECOVPD Fail (DSP0063I)
>GENMAX =GENMAX <RECOVPD Avail IC DS used (DSP0065I)
=GENMAX =GENMAX >RECOVPD Oldest IC DS reused
>GENMAX =GENMAX >RECOVPD AVAIL IC DS used

Table 3 shows the results of running an image copy utility when both GENMAX
and RECOVPD have been specified for a DBDS or area defined with the
NOREUSE parameter.
Table 3. Results of GENJCL.IC Processing When GENMAX and RECOVPD are Specified
with NOREUSE
Age of Oldest Image
Number of Image Copies Copy 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 RECOVPD
values that are less than the existing values, any used image copy data sets that
are beyond the recovery period are deleted until the number of remaining image
copy data sets equals the specified GENMAX value.
If you issue the DELETE.IC command, any specified image copy data set record is
deleted regardless of RECOVPD or GENMAX.
Reusing Image Copy Data Sets

DBRC enables you to reuse old image copy data sets. The REUSE parameter of the
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 image
copy data set means that the same name, volumes, and physical space are used for
the new image copy.
A run of one of the IMS image copy utilities automatically reuses the oldest image
copy data set for a DBDS or area with the REUSE attribute when all of the
following conditions are met:
v A number of image copy data sets equal to the current GENMAX value are
recorded in the RECON data set. To see the current GENMAX value, use the
LIST.DBDS command.
v The Database Image Copy utility or Online Database Image Copy utility used all
image copy data sets for this DBDS. None of the image copy data sets is
available.
v The oldest image copy is beyond the recovery period.
v A run of one of the IMS image copy utilities automatically uses an available
image copy if one exists. If GENMAX has been reached and the oldest image
copy is beyond the recovery period or there is no recovery period, the oldest
image copy data set is made available.
When you use a GENJCL.IC command to generate the job for the Database Image
Copy 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 all
image copy data sets have been used, more image copy data sets must be defined
for the DBDS or area before running the Database Image Copy utility. The number
of image copy data sets should be greater than the GENMAX value if you want to
use a recovery period.
The Database Image Copy 2 utility can create up to four output image copy data
sets. However, if you issue a GENJCL.IC command for a DBDS defined as REUSE,
DBRC generates JCL for only one or two output copies (because you can define

image copy data sets for only one or two copies). If you use the GENJCL.IC
command for the Database Image Copy 2 utility to process a DBDS defined as
REUSE and you want more than two output copies, modify the generated JCL
before you run the job.
DBRC generates JCL so that the oldest DASD data set is always used for output
for the image copy. DBRC has the same capability with tape volumes. However,
you need to analyze your existing tape library techniques to make sure there is no
conflict.
HSSP Image Copy

The high speed sequential processing (HSSP) image copy (IC) process requires that
a database be registered with DBRC and requires that an area be registered with
the REUSE attribute for recycling the predefined IC data sets. Image copies that are
created by HSSP are concurrent image copies.
HISAM Copies (DFSURUL0 and DFSURRL0)

Using the HISAM Reorganization Unload utility (DFSURUL0) to make backup
copies of a database lets you process an entire HISAM database in one pass (the
image 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 resuming
normal online operations, the data set must be reloaded using the HISAM
Reorganization Reload utility (DFSURRL0). 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 the
actual database and the backup database are mismatched.
The reload utility (DFSURRL0) notifies DBRC. The unload utility creates a
reorganized copy of each data set. Then the reload utility reloads each data set
from the reorganized copy, and through DBRC, creates a REORG and an IC record
in the RECON data set for each data set. The IC record points to the data set that
was output from the Unload utility and input to the Reload utility. After a
database has been reorganized, a DBDS can be authorized only if an image copy of
that data set has been 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 reload
operation are wiped-out by the reload operation. In addition, the change records
that are logged reflect the old organization, so that a subsequent recovery using
those log records damages the database.
You can prevent access to a shared database during reorganization by using one of
the following methods:
v From an online IMS subsystem, issue a global /DBRECOVERY command for the
database that is to be reorganized. This prevents any subsequent authorizations
except for reorganization and recovery. Ensure that recovery utilities do not run
during the reorganization.
v Manually update the RECON data set by specifying the NOAUTH parameter of
the CHANGE.DB command. This prevents any subsequent authorizations except for
the reorganization and recovery utilities. Ensure that recovery utilities do not
run during the reorganization. After the reorganization process is complete,

manually update the RECON data set by specifying the AUTH parameter of the
CHANGE.DB command for the database that was just reorganized.
Nonstandard Image Copy Data Sets

You can create backup copies of DBDSs by using some means other than the
Database Image Copy utility. For example, you could make a copy of the volume
on which a DBDS resides. DBRC does not record the existence of these
nonstandard image copy data sets in the RECON data set automatically; use a
NOTIFY.UIC command to inform the RECON data set of these data sets. If this
information is not recorded in the RECON data set, DBRC might misinterpret
subsequent information about changes to the DBDS. You cannot issue the
NOTIFY.UIC command for a DBDS that is defined with the REUSE option.
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 the
nonstandard image copy (UIC) and record the event in the RECON data set (by
issuing NOTIFY.RECOV with RCVTIME specified).
2. Apply the change records from the logs that were produced since the UIC (by
running DBRC with USEDBDS or USEAREA for the GENJCL.RECOV command or
DFSDUMP DD DUMMY statement in the DBRC JCL).
DBRC does not allow DBRC to process any log that contains changes outside the
recovery range because an image copy is not used for Step 2. The recovery range is
defined by the time-stamp recovery record RECOV TO (image copy time) and
RUNTIME values.
Frequency and Retention of Backup Copies

Consider 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 frequently
you 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 are
sometimes not discovered for weeks.) Conversely, making each new copy requires
work, 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 data sets
at the same time.
v If you reorganize a database, immediately make a new backup copy of it. (This
is not 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 time-stamp recovery, make a backup copy for use in
subsequent recoveries.
Log Record Change Accumulation

As IMS runs, the number of stored SLDSs or RLDSs grows. You can use these
stored volumes to recover a lost or damaged database, but to use them in their
raw form would be inefficient because:

Change Accumulation Considerations
v Each SLDS or RLDS contains a record of activities of the entire system and all
the 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 SLDS
or RLDS does not apply.
v The SLDS or RLDS chronologically notes each change to any single record. If a
record were changed 100 times since the last backup copy of the data set, the
SLDS or RLDS would include 100 such notations. Yet, in recovery, you are only
interested in the value the data had at the moment the data set was lost. The
previous 99 changes are irrelevant.
The Database Recovery utility requires that change records be input in

chronological order, but if a database is shared, the change records might be
distributed among different log data sets in a way that makes their input to the
utility impossible. A DBRC GENJCL.RECOV command or DB Recovery utility
execution fails if this log data has not been properly merged. Such a failure is
accompanied by a message informing you that a Change Accumulation should be
run.
Condensing the Accumulated SLDS or RLDS (Change

Accumulation)
The Database Change Accumulation utility offers you a way of sorting through
your accumulated 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 8 on page 45 illustrates how the Database Change Accumulation utility

merges the relevant log data (a, b, and c) from 3 different SLDSs (A, B, and C),
from one IMS system, into one change accumulation data set record.

Figure 8. What Change Accumulation Does with Redo Data from Divergent Data Streams
When Is Change Accumulation Required?

Running the Database Change Accumulation utility is not required if, during the
time period in question, only one system updated the database; using it
periodically speeds any database recovery that becomes necessary. Alternately, you
can run the Database Change Accumulation utility only when the need for
recovery arises (just before running DB Recovery utility).
Change accumulation would not be required when non-concurrent data set update
information exists in various logs. The database changes are received in the correct
order if the logs are input serially to DB Recovery utility.
Change accumulation can be required when concurrent data set update

information exists in various logs. The logs cannot be input to DB Recovery utility
in a way that the change records are seen in the correct order.
Related Reading: See the IMS Version 9: Utilities Reference: Database and Transaction
Manager for detailed instructions on running the Database Change Accumulation
utility.
Input to the Database Change Accumulation Utility

In addition to stored SLDSs and RLDSs, you can use a previous change
accumulation data set and other IMS log volumes as input. The utility writes the
accumulated changes in a new change accumulation data set.
You can specify all log volumes or a subset of log volumes as input to the
Database Change Accumulation utility. When you specify a subset of log volumes,

DBRC determines whether the subset is complete for each DBDS or area. A subset
of log volumes is complete for a DBDS or area when all of the following
conditions are true:
v The first volume in the subset is the earliest volume, that could possibly have
changes to the DBDS, that were not included in the last change accumulation or
in the last image copy.
v The remaining volumes are in sequence.
v In a data sharing environment, logs from all updating subsystems containing
changes and any open data streams for a DBDS are included.
The DBRC LIST.CAGRP command indicates whether the log subset for each DBDS
of the change accumulation group is complete.
You can use the change accumulation data set as input to a later run of the
Database Change Accumulation utility whether your subset of log volumes is
complete or incomplete; however, you can use a change accumulation data set as
input to DB Recovery utility only if it represents a complete log subset.
Recommendation: If DBRC is being used, it is recommended that the change

accumulation process is performed using the GENJCL.CA command. This command
creates the correct JCL and includes all unprocessed log data sets. If you use your
own JCL instead, verify the specifications for change accumulation before
execution.
An image copy of the specified database data set is needed and must be identified
to the RECON data set 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 a
time-stamp recovery has occurred since the last image copy, the change
accumulation that is created is invalid for use in future recoveries. No error
messages 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 time
to reduce data to a minimum.
When the most recent image copy is used as input to the Change Accumulation
utility and that image copy is a concurrent image copy, changes already made to
the database by active applications might be missing from the copy because the
changes might not have been physically written to the data set. These changes,
however, have been written to the log. In this case, it is necessary to go back to
some earlier point in the logs to ensure that all changes are applied. How far to go
back depends on the type of database and which image copy utility was used.
The point-in-time selected to start the Change Accumulation utility is called the
purge time.
Related Reading:
v See the IMS Version 9: Utilities Reference: System for more information on the
Database Change Accumulation utility.
v See the IMS Version 9: Operations Guide for more information on the change
accumulation process in general.

Change Accumulation Groups

You can use the Database Change Accumulation utility to process some or all of
your recoverable, registered databases as change accumulation (CA) groups. You
can, for example, organize the DBDSs into the following groups:
v Application-associated databases
v Physical database clusters
v Logical database clusters
v Volatile (critical data) databases
You can add or delete members of a CA group after you have created it. A
database can be a member in only one CA group. To move a member from one CA
group to another CA group, you must first delete it from its current CA group and
then add it to the new CA group.
| Recommendation: Create an image copy of a CA-group member before you move

| that member to a new CA group. The change accumulation utility processes all
| logs for the member that are needed for recovery, based on the last good image
| copy.
A Change Accumulation group can contain from one to 32767 members, which
must be registered DBDSs or areas.
Use INIT.CAGRP to create your Change Accumulation group. To modify your

Change Accumulation group, use CHANGE.CAGRP. A DBDS or area can belong to
only one Change Accumulation group.
DBRC supports the Change Accumulation utility only by Change Accumulation

group. Likewise, GENJCL.CA generates JCL only for a Change Accumulation group.
The DBRC verification exit routine verifies for a whole Change Accumulation
group.
You can run the Change Accumulation utility for DBDSs that do not belong to a
Change Accumulation group even with DBRC=YES in effect. However, DBRC does
not verify the input to the utility nor record its output.
Defining Change Accumulation Data Sets for Future Use

You can use the REUSE keyword on the INIT.CAGRP command to inform DBRC
that you want to define a “pool” of data sets to receive the output from the
Change Accumulation utility. Define the data sets using the INIT.CA command. The
number of change accumulation data sets that you can define, can equal up to the
value of the INIT.CAGRP command GRPMAX parameter that defined the group.
If you define a Change Accumulation group with the REUSE parameter and also
use a GENJCL.CA command to generate the job for the Database Change
Accumulation utility, data set reuse can occur. When all available change
accumulation data sets for this Change Accumulation group have been used and
the maximum number of change accumulation data sets has been reached, the next
run of the Database Change Accumulation utility for this group 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 change accumulation data set.
If you define the Change Accumulation group with NOREUSE:

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

v When you run the Change Accumulation utility and the number of data sets
specified by GRPMAX has been reached, DBRC deletes the record of the change
accumulation data set (from the RECON data set) that contains the oldest
change records. The data set itself is not scratched. The data set must be
manually scratched or monitored if you want to keep it, because DBRC no
longer recognizes its existence.
Related Reading: See “Database Change Accumulation Utility (CAJCL)” on page

437 and “Database Change Accumulation Utility JCL (CAJCL)” on page 450 for
details on the Change Accumulation JCL specifications.
DBDS Group Considerations

A DBDS group is a named collection of DBDSs or DEDB areas. DBRC can perform
various operations by DBDS group so that you do not need to repeat the command
for every member of the group.
You can specify DBDS groups on the following commands:

v GENJCL.IC
v GENJCL.OIC
v GENJCL.RECEIVE
v GENJCL.RECOV
v GENJCL.USER
v LIST.DBDS
v LIST.HISTORY
When you specify a DBDS group on a command, DBRC invokes that command for
each member of the DBDS group. For example, you might have a DBDS group for
a particular application, like payroll. When performing a time-stamp recovery, for
example, all DBDSs of a particular application of a database must be recovered to
the same point. If you specify a DBDS group on the GENJCL.RECOV command, you
need only invoke the command once to recover all DBDSs.
You can also specify a CA group as a DBDS group. DBRC then executes the
command for each member of the CA group.
You can define as many DBDS groups as you want. Up to 2000 DBDSs can be in a
group. All DBDSs in a group must be registered in the RECON data set. A DBDS
can belong to more than one DBDS group.
A database is an implied DBDS group for the GENJCL and LIST commands. It is
unnecessary to define a DBDS group consisting of the DBDSs or areas of a single
database. Specify the database name and omit the DD name to operate on the
whole 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.

Group Considerations
Related Reading: See Chapter 11, “GENJCL Commands,” on page 221 for the
impact of these data sets on the GENJCL commands.
DB Groups
A DB group is a named collection of databases or DEDB areas. A DB group name
can be specified in the /START, /STOP, /DBRECOVERY, and /RECOVER commands,
instead of issuing these commands separately for each database or area. Specifying
a DB group name with these commands greatly reduces the number of times these
commands must be issued. Use the DATAGROUP keyword to specify the DB
group name.
DB groups can also include HALDB master and HALDB partition names. Be aware
of the effects of a command issued using a DB group that has a HALDB master
name and one or more of its partitions. See IMS Version 9: Command Reference for
more information.
| You can define as many DB groups as you want. Up to 32767 databases or areas
| can be in a group. A database or area can belong to more than one DB group and
| need not be registered in the RECON data set.
Recommendation: Use a database group whenever possible, even though a DBDS

group can be used as a DB group. Processing a DBDS group as a DB group entails
increased overhead.
DB groups are a form of a DBDS group, so they are stored in the RECON data set
using the DBDS group record. The following commands affect the definition of a
DB group:
v INIT.DBDSGRP
v CHANGE.DBDSGRP
v DELETE.DBDSGRP
v LIST.DBDSGRP
| DBRC Considerations for HALDB Online Reorganization

| The following topics describe the DBRC considerations with respect to HALDB
| online reorganization.
| The following DBRC commands support HALDB online reorganization:

| v CHANGE.DB
| v GENJCL.IC
| v GENJCL.OIC
| v INIT.DB
| v NOTIFY.IC
| v NOTIFY.REORG
| v NOTIFY.UIC
| The records in the RECON data set that contain HALDB online reorganization
| information are the:
| v HALDB master record
| v Partition DB record
| v DBDS record

DBRC Considerations for HALDB Online Reorganization
| v REORG record
| GENJCL.IC and GENJCL.OIC Command Considerations

| You can generate the JCL for the GENJCL.IC and GENJCL.UIC commands in advance
| and not execute the JCL immediately. Therefore, the active set of DBDSs might
| change in the interim time period.
| GENJCL no longer generates DD statements for the HALDB DBDS that is being
| copied because dynamic allocation is recommended for the Database Image Copy
| utility and the Database Image Copy 2 utility. The SYSIN control statement
| identifies which DBDS to copy: either the A-through-J or the M-through-V set of
| data sets. The image copy utility then copies the corresponding active set of data
| sets: A-through-J or M-through-V.
| NOTIFY.IC and NOTIFY.UIC Command Considerations

| You cannot take an image copy if a HALDB online reorganization cursor is active
| (OLREORG CURSOR ACTIVE =YES) or has been terminated. The NOTIFY.IC and
| NOTIFY.UIC commands fail if they attempt to record an image copy while the
| HALDB online reorganization cursor is active.
| Records Used in HALDB Online Reorganization

| HALDB online reorganization relies on a number of records to track information
| and activities related to online reorganization. This section includes descriptions of
| some of the records impacted by HALDB online reorganization:
| v “DB Record Fields Used in HALDB Online Reorganization”
| v “REORG Record Fields Used in HALDB Online Reorganization” on page 52
| DB Record Fields Used in HALDB Online Reorganization

| The DB record for a HALDB partition contains information for HALDB online
| reorganization. Complete descriptions of the fields in the DB record for a HALDB
| partition are in Table 49 on page 550. The DB record includes:
| v A field that indicates whether the database can be reorganized online (ONLINE
| REORG CAPABLE=). This field is also in the HALDB master DB record. This
| field cannot be reset if:
| – Online reorganization is active
| – Any of the M-through-V and Y data sets are active
| – Any partition for the HALDB is authorized
| If these conditions do not exist and the field can be reset, all of the M-through-V
| and Y data set information in the RECON data set is deleted.
| v A field that indicates whether the HALDB online reorganization cursor is active
| (OLREORG CURSOR ACTIVE=).
| v The SSID of the IMS that is currently performing a HALDB online
| reorganization (OLRIMSID=).
| v A field that indicates which set or sets of DBDSs is or are active for the partition
| (ACTIVE DBDS=).
| v Counters showing the number of cursor-active status changes (OLR ACTIVE
| HARD COUNT=) and cursor-inactive status changes (OLR INACTIVE HARD
| COUNT=) that are not yet hardened at the RSR tracking site.
| DBDS Record Definitions: The M-through-V and Y DBDS records are defined in
| the RECON data set with the same attributes as the corresponding A-through-J, L,
| and X DBDS records. The M-through-V and Y DBDS records are added to the same

| CAGROUP as the A-through-J and X DBDS. Similarly, the M-through-V and Y

| DBDS records are added to each DBDS group where the A-through-J DBDS records
| are found.
| The exceptions to the similarities in attributes include DD names, data set names,
| and the DSID. The DSID of the M-through-V and Y data set is the same as the
| corresponding A-through-J, L, and X data set, except that its X'80' bit is set on. For
| the RECON data set list purposes, the X'80' bit is ignored.
| Table 4 shows the data set ID (DSID) DCB number associated with the A-through-J,
| L, and X data sets and the M-through-V and Y data sets.
| Table 4. DSID DCB Numbers for the A-J, L, and X and the M-V and Y Data Sets
| A-J, L, and X Data Sets M-V and Y Data Sets
| DSID DCB
| Number PHIDAM PHDAM PHIDAM PHDAM
| 1 A A M M
| 2
| 3 L L
| 4 B N
| 5 X C Y O
| 6 B D N P
| 7 C E O Q
| 8 D F P R
| 9 E G Q S
| 10 F H R T
| 11 G I S U
| 12 H J T V
| 13 I U
| 14 J V
|
| Support for OLR Coexistence: The DB record header also includes parameters
| that indicate if online reorganization is allowed. These parameters are OLRCAP or
| OLRNOCAP.
| If online reorganization is enabled, sharing of HALDBs with IMS Version 7, or IMS

| Version 8 without the OLR Coexistence SPE applied, is no longer allowed. Full
| data sharing is allowed for IMS Version 8 with the OLR Coexistence SPE applied.
| IMS Version 7 or IMS Version 8 without the OLR Coexistence SPE applied are
| allowed to process databases that are marked as not capable of being reorganized
| online. You can set or reset this field using the CHANGE.DB DBD(HALDB_master)
| command, and display it in the output from a LIST.DB command or the
| appropriate Query API request.
| Table 5 on page 52 shows whether full data sharing of databases is allowed

| between these IMS Versions:
| v Version 7
| v Version 8 (without the OLR Coexistence SPE applied)
| v Version 8 (with the OLR Coexistence SPE applied)
| v Version 9

| The ability to share data also depends on whether OLRCAP or OLRNOCAP is

| specified for a database, and Table 5 also identifies those cases.
| Table 5. Data Sharing Between the Releases
| Version 8
| without SPE Version 8 with
| Version 7 Applied SPE Applied Version 9
| OLRCAP NO NO YES YES
| OLRNOCAP YES YES YES YES
|
| REORG Record Fields Used in HALDB Online Reorganization

| The REORG record for a HALDB partition DBDS, which is shown in Table 55 on
| page 562, contains a stop time for HALDB online reorganization. To run an offline
| reorganization of a database, you must take it offline by issuing a /DBR command.
| Therefore, only the start time of the online reorganization is significant. With
| HALDB online reorganization, the database is online, so the duration of the
| process is significant. The stop time of the online reorganization is recorded in the
| REORG record (STOP=timestamp), with information that indicates that it is an
| online reorganization and indicates whether the online reorganization can be used
| as input to recovery.
| A REORG record is recorded under both the A-through-J, L, and X DBDS and the
| M-through-V and Y DBDS. The REORG record for the DBDS that was the output
| data set indicates that it can be used as input for recovery. The REORG record for
| the DBDS that was the input data set indicates that it cannot be used for recovery
| after online reorganization completes.
| RSR Tracking System

| Ownership of the HALDB online reorganization is not recorded in the tracking
| RECON data set.
| The RECON data set at the tracking site always reflects the current status of the
| covered databases. Counters keep track of outstanding HALDB online
| reorganizations that have been recorded in the RECON data set at the tracking site
| but not yet applied to the databases.
| Maintaining Recovery-Related Records

| The A-through-J and M-through-V data sets are treated as one logical set of
| DBDSs. The M-through-V data sets are defined in the RECON data set with the
| same attributes as their corresponding A-through-J data sets.
| The recovery information in the two DBDS headers is maintained as if they are one
| logical DBDS. For example, the values for GENMAX, RECOVPD, and CAGRP are
| the same. Any changes that are made to the active DBDS are also made to the
| inactive DBDS.
| There is a one-to-one relationship between each partition data set; for example, A
| correlates to M, B correlates to N, C correlates to O, and so on. You can perform
| online reorganization on any of these data sets (A-through-J, L and X or
| M-through-V and Y) at any time, depending on which set is active before the
| online reorganization starts. Therefore, data sets A and M are one logical data set
| during an online reorganization. After an image copy is taken, DBRC removes any
| extraneous recovery-related records (IMAGE, ALLOC, RECOV, and REORG) from
| the RECON data set. The extraneous records are determined by the maximum

| number of recovery generations (GENMAX) settings and the optional recovery

| period (RECOVPD) settings for the DBDS.
| For example, assume that the GENMAX value for data set A (and M) is 2, and that
| data set A has two image copies. When data set M becomes the active data set and
| an image copy is taken, the image copy cleanup process deletes the oldest image
| copy from data set A, including any of its extraneous recovery records. Another
| image copy of data set M causes the rest of data set A’s image copy and recovery
| records to be deleted. Note that data set A becomes unrecoverable if its image copy
| and recovery records are deleted.
| The Online Reorganization Process

| When online reorganization is started, the ID of the IMS that is responsible for the
| reorganization is assigned to the partition. After the cursor-active status is recorded
| in the RECON data set and copying begins between the A-through-J and
| M-through-V data sets, these changes also occur:
| v The DB record for the partition indicates that online reorganization is active
| (OLREORG CURSOR ACTIVE =YES).
| v The status of the active DBDSs shows that both data sets are active (ACTIVE
| DBDS=A-J and M-V).
| v REORG records that show the start time of the online reorganization are written.
| The stop time is zero.
| v The REORG record associated with the output data set now indicates that this
| data set can be used as input for recovery.
| v The REORG record associated with the input data set does not indicate that this
| data set can be used for recovery. DBRC uses this record to ensure that this data
| set cannot be recovered after online reorganization completes.
| v The M-through-V and Y data sets are defined in the RECON data set if they do
| not already exist.
| v The M-through-V and Y DBDSs are added to the same change accumulation
| group as the A-through-J, L, and X DBDSs, if a change accumulation group is
| assigned.
| v The M-through-V and Y DBDSs are added to any DBDS group where the
| A-through-J, L, and X DBDSs are found.
| After these changes take place, the online reorganization must complete; otherwise,
| you must run an offline reorganization to reset the HALDB online reorganization
| settings.
| You cannot start online reorganization if it is already running for a partition.

| However, another IMS can take over the online reorganization if it is terminated;
| that is, when there is no IMS ID assigned.
| When the online reorganization process completes successfully, these changes

| occur:
| v The REORG records are updated to include the HALDB OLR stop time.
| v The DB record for the partition is changed to indicate that online reorganization
| is not active (OLREORG CURSOR ACTIVE = NO).
| v The status of the active DBDSs is switched to the newly reorganized data sets.
| v The online reorganization IMS ID is cleared.

| Recommendation: You are not required to create image copies of a partition’s

| DBDSs after a successful online reorganization. However, it is recommended that
| you take an image copy as soon as possible to reduce recovery time.
| Restriction: An image copy of a DBDS cannot be taken while the online

| reorganization cursor is active (OLREORG CURSOR ACTIVE =YES). DBRC causes
| the image copy to fail in this situation.

Chapter 4. Initializing and Maintaining the RECON Data Set
DBRC records recovery-related information in a pair of key-sequenced data sets
(KSDSs) called the RECovery CONtrol (RECON) data set. DBRC uses two RECON
data sets to increase availability and recoverability. They contain identical
information. The data sets are identified by the DD names RECON1 and RECON2.
If you define only two RECON data sets and an error occurs on one of them
during operation, the current jobs continue using the remaining one. New jobs
cannot start unless your RECON setting allows a job to start with only one active
RECON data set. If you want to continue operations in dual mode, you can define
a third RECON data set (RECON3). DBRC does not use this spare data set unless
an error occurs on one of the two active RECON data sets. Then, DBRC copies the
good RECON to the spare data set (RECON3), which then becomes active (thus
maintaining RECON dual-mode operation).
Figure 9 shows the recommended three RECON data set operating configuration.
Figure 9. DBRC Dual RECON Set Up with a Spare
The RECON data sets are critical resources for both DBRC and IMS. If both
RECON data sets are lost, DBRC abnormally terminates rather than compromising
database integrity. IMS cannot continue processing transactions without a viable
RECON data set, so IMS also abnormally terminates.
In This Chapter:
v “Planning Considerations for the RECON Data Set”
v “Initially Accessing the RECON Data Set” on page 62
v “Records in the RECON Data Set” on page 63
v “Maintaining the RECON Data Set” on page 72
v “Tracking Changes Made to the RECON Data Set” on page 81
Planning Considerations for the RECON Data Set

Each RECON data set is a VSAM KSDS with a 32-byte key.

Maintaining the RECON data set
Define your RECON data sets specifying VSAM SHAREOPTION(3,3). Ideally, each
data set should be on a different device, channel, control unit, and catalog. The
RECON data sets should also be of different sizes (see “Avoiding RECON Data Set
Space Problems” on page 60).
Recommendations:
v When defining the RECON data sets using Access Method Services (AMS):
– Use the same index control interval (CI) size and data CI size for all the
RECON data sets.
| – Allocate at least twice as much space for an IMS Version 9 RECON data set as
| was allocated for an IMS Version 7 RECON data set during the initial
| upgrade. After the next reorganization of the RECON, you can check the
| amount of space being used and lower the space allocation.
v Ensure that the data CI size specified exceeds the specified index CI size by at
least 2048 bytes. Failure to do so can seriously degrade your DBRC performance.
v Use secondary allocation to safeguard against a RECON data set becoming full.
Initializing the RECON Data Set for the First Time

After allocating the RECON data sets, use the INIT.RECON command to initialize
the RECON data set. This command is only valid for an empty, uninitialized
RECON data set. If the initialization job fails, delete and redefine the data sets
before rerunning the job.
Avoiding RECON Data Set Contention Problems

Maximum RECON data set availability depends on the following:
v Eliminating deadlock
v Minimizing situations in which more than one RECON data set becomes
simultaneously unavailable
For maximum availability, each RECON data set must:

v Have different space allocations. The spare data set must be at least as large as
the largest RECON data set.
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 RECON

Data Set Space Problems” on page 60.
| Recommendation: To eliminate contention and facilitate recoverability, the RECON

| data sets should be the only type of data set on their respective devices if using
| implementing hardware reserves for the RECON data sets.
To eliminate deadlocks (if you are using implementing hardware reserves for the
RECON data sets), the RECON data sets must:
v Be the only objects cataloged in their respective catalogs.
v Be on the same device as their catalogs. When the RECON data sets are
accessed, an enqueue on the RECON data sets can result, followed by an
enqueue on the catalog. When the RECON data sets and catalog are on the same
device, the possibility of conflicts with another job enqueuing the devices in
reverse order is eliminated.

Avoiding RECON Data Set Deadlocks

To avoid deadlock situations, give special consideration to the placement of
RECON data sets that are shared among multiple processors. During a physical
open, DBRC reserves RECON1, RECON2, and RECON3. DBRC determines which
are available and which are Copy1, Copy2, and spare. DBRC then closes and
dequeues the spare (if it exists) and any unusable RECON data sets. So, during the
use of DBRC, two RECON data sets are reserved most of the time. DBRC always
reserves both RECON data sets in this order: RECON1 and RECON2. If RECON1
and RECON2 are specified consistently throughout jobs, DBRC does not encounter
deadlock.
However, other jobs that reserve multiple volumes can cause deadlock if any of the
volumes also contain a RECON data set.
Related Reading: The z/OS MVS System Programming Library: Application

Development Guide explains deadlock situations and volume assignments further;
refer to it when placing your RECON data sets.
RECON Data Set Serialization

Access to the RECON data sets must be controlled to avoid deadlock. The
following z/OS macros are used to control access to the RECON data sets:
RESERVE, GRS, OBTAIN, and DEQ. DFP Record Management Services are also
discussed and RECON data set serialization strategies are presented in the
following sections.
RESERVE: DBRC issues the z/OS RESERVE macro to serialize access to each
RECON data set. DBRC keeps the RECON data sets reserved until it completes its
processing. The more RECON records DBRC must examine or change, the longer it
holds the RECON data sets. The RESERVE macro serializes access to a resource (a
data set on a shared DASD volume) by obtaining control of the volume on which
the resource resides to prevent jobs on other systems from using any data set on
the entire volume. This reserve is done under the major name DSPURI01 and has a
scope of SYSTEMS.
Batch jobs will serialize on another resource name first, before issuing a RESERVE
for the RECON data sets. The resource name for batch is DSPURI02 and has a
scope of SYSTEM. Each job gets control of the resource, based on the position of
the task’s request and whether the request was exclusive or share control. The
queue is not ordered by the priority of tasks. The effect of this serialization of
batch jobs is that an IMS online region never has to wait for more than one batch
job to complete before gaining access to the RECON data set.
Global Resource Serialization (GRS): The GRS macro provides a method of

converting a RESERVE request into an ENQ request. The ENQ, DEQ, and
RESERVE macros identify 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 name
of APPL01,MASTER,SYSTEM. The major name (qname) is APPL01, the minor
name (rname) is MASTER, and the scope is SYSTEM.
Chapter 4. Initializing and Maintaining the RECON Data Set 57

When an application uses the ENQ, DEQ, and RESERVE macros to serialize
resources, global resource serialization uses resource name lists (RNLs) and the
scope on the ENQ, DEQ, or RESERVE macro to determine whether a resource is a
local resource or a global resource. Global resource serialization identifies each
resource by its entire symbolic name. For example, a resource that is specified as
A,B,SYSTEMS is considered a different resource from A,B,SYSTEM or A,B,STEP
because the scope of each resource is different. To ensure that resources are treated
as you want them to be without changes to your applications, global resource
serialization provides three resource name lists (RNLs):
v SYSTEMS EXCLUSION RNL
The SYSTEMS exclusion RNL contains a list of resources that are requested with
a scope of SYSTEMS that you want global resource serialization to treat as local
resources.
v RESERVE CONVERSION RNL
The RESERVE conversion RNL contains a list of resources that are requested on
RESERVE macros for which you want global resource serialization to suppress
the RESERVE.
v SYSTEM INCLUSION RNL
The SYSTEM inclusion RNL contains a list of resources that are requested with a
scope of SYSTEM that you want global resource serialization to treat as global
resources.
Related Reading: See the following publications for more information about GRS
and the z/OS RESERVE, DEQ, and ENQ macros:
v z/OS MVS Programming: Authorized Assembler Services Reference, GC28-1763
v z/OS MVS Planning: Global Resource Serialization, GC28-1759
OBTAIN: DBRC uses a VSAM DADSM (Direct Access Device Storage

Management) OBTAIN request to the FORMAT-4 DSCB (the VTOC) to force an
I/O that insures that DBRC really has the RECON data set reserved in a
multi-system environment. For more information about the OBTAIN DADSM
macro, see the DFSMS/MVS V1R5 MDFSMSdfp Advanced Services, SC26-4921,
manual.
The OBTAIN macro is not issued if the Synchronous RESERVE (SYNCHRES)

option is in effect. The Synchronous RESERVE feature allows specification upon
installation of whether the hardware RESERVE should be obtained for a device
prior to granting a global resource serialization ENQ.
The SYNCHRES option can be activated through either the GRSCNFxx parmlib
member or the SETGRS operator command. The GRSDEF statement of GRSCNFxx
contains the SYNCHRES (Y | N) parameter. The default value for SYNCHRES is
| NO. During normal system operation, the operator can modify the setting of
SYNCHRES by issuing the SETGRS command. Activate SYNCHRES by issuing
SETGRS SYNCHRES=YES and deactivate it by issuing SETGRS SYNCHRES=NO.
DEQ: DBRC releases the RECON data sets by using the z/OS DEQ macro.
DFP Record Management Services: DBRC uses VSAM services to retrieve,

manipulate, and store the RECON data set records. These records have a 32-byte
| record key.
| RECON Data Set Serialization Strategies: This section describes several

| serialization strategies, and the effects of implementing those strategies.

| Recommendations:
| v In a GRS Star configuration, a RESERVE CONVERSION RNL should be
| implemented for DSPURI01 if all systems accessing the RECON data sets are
| within the sysplex (or GRSPlex).
| Note: If the RECON data sets are accessed by systems that are outside of the
| sysplex, the reserve must not be converted. A SYSTEMS EXCLUSION
| RNL must be implemented instead.
| v In a GRS Ring configuration, a SYSTEMS EXCLUSION RNL should be
| implemented for DSPURI01 so that the RECON is serialized by hardware
| reserve.
| GRS RESERVE CONVERSION RNL
| If you implement GRS RNL CONVERSION by adding the
| QNAME for the RECON data set, DSPURI01, to the conversion list,
| the hardware reserve is eliminated and replaced by a GRS enqueue
| that is communicated to all other sharing z/OS systems.
| Other data sets on the same DASD volume can be used while the
| RECON data set is reserved; this is the benefit of performing the
| RNL conversion. GRS RNL conversion uses CPU and storage and
| affects system performance positively. The performance (in terms
| of least CPU time used, least storage used, and least elapsed time)
| is best using this option in a GRS STAR configuration.
| To implement this method, follow these steps:
| 1. Add the RECON data set QNAME to the RESERVE
| CONVERSION RNL. For example:
| RNLDEF RNL(CON) TYPE(GENERIC) QNAME(DSPURI01)
| 2. Consider carefully the placement of the following VSAM
| QNAMEs: SYSZVVDS and SYSIGGV2.
| Related Reading: For more information on implementing GRS
| RNL CONVERSION, see z/OS MVS Planning: Global Resource
| Serialization.
| GRS SYSTEMS EXCLUSION RNL
| If you implement GRS SYSTEMS EXCLUSION RNL, then GRS
| does not perform global serialization and the RESERVE macro is
| issued. This might work well provided that the RECON data set is
| located on a DASD volume that does not contain other data sets
| that are needed by other z/OS systems.
| To implement this method, follow these steps:
| 1. Add the RECON data set QNAME to the SYSTEMS
| EXCLUSION RNL. For example:
| RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(DSPURI01)
| 2. Carefully consider the placement of the following VSAM
| QNAMEs; SYSZVVDS and SYSIGGV2.
| Related Reading: The z/OS MVS Planning: Global Resource
| Serialization provides more information about VSAM QNAMEs.
| Related Reading: There are a number of possible solutions to contention or

| performance problems associated with the RECON data sets.
| v See the Informational APAR II10915 for information on RECON contention and
| performance problems.

| v See the Informational APAR II10735 for information on performance and tuning
| diagnostics.
Allocating the RECON Data Sets

For 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 data set, omit the DD statements for
RECON1, RECON2, and RECON3.
| Use the TYPE=RECON macro statement of the IMS DFSMDA dynamic allocation
| macro to establish three dynamic allocation parameter lists in IMS.SDFSRESL.
| When multiple processors access the same RECON data sets, keep the
| IMS.SDFSRESL information pertaining to dynamic allocation parameters in
| synchronization on all processors.
Related Reading: See IMS Version 9: Utilities Reference: System for information
about the DFSMDA macro.
DBRC always allocates RECON data sets with DISP=SHR.
Although JCL allocation and dynamic allocation are both valid methods for
allocating RECON data sets, JCL allocation should be used only in a controlled
test.
Recommendation: Use dynamic allocation for your production system and all
other test or development environments.
The principal advantages of dynamically allocating the RECON data set are:
v All DBRC jobs automatically use the correct and current RECON data sets, and
no JCL statements are left to become outdated.
v You can reorganize and restore RECON data sets, in case of error, without
having to shut down online IMS systems.
Avoiding RECON Data Set Space Problems

| Allocate the RECON data sets with different amounts of space so that if one
| becomes full, the system can continue using the other RECON data set while you
| provide a replacement. Allocate secondary extents for the RECON data set when
| you define space for it.
If one RECON data set becomes full during online operation, IMS deallocates it.
DBRC responds by copying and reorganizing the good RECON data set to a spare
RECON data set, if one is available. If no spare RECON data set is available, the
system runs in single-RECON mode.
When all active subsystems have deallocated the failing RECON data set, you can
delete and redefine it offline using AMS. See “Replacing a Discarded RECON Data
Set” on page 77 for information on replacing a discarded RECON data set. If you
are in single mode, and a spare RECON data set is available, the next time DBRC
accesses the RECON data set, it automatically enters dual-RECON mode. You do
not have to enter the CHANGE.RECON command with the DUAL or REPLACE option.
Creating a RECON Data Set

| Create a RECON data set using the DEFINE CLUSTER command. The keywords that
| are recommended when defining a RECON VSAM KSDS are discussed in the

| following list. Information on all the keywords can be found in the z/OS DFSMS
| Access Method Services for Integrated Catalog Facility.
| CONTROLINTERVALSIZE
| The values used with this keyword affect the total amount of storage used by
| DBRC for VSAM and internal buffers. DBRC uses the Local Shared Resources
| (LSR) option of VSAM to process the RECON data sets. If the number of index
| and data buffers created by DBRC is allowed to default, the amount of storage
| used for RECON buffers is:
| (60 X index_ci_size) + (120 X data_ci_size)
| This amount of storage is used when the index and data CI sizes are the same
| for all RECON data sets. You can change the default number of index or data
| buffers used by DBRC in an online or batch environment with the DSPBUFFS
| Buffer Size Specification Facility.
| DBRC uses one set of internal buffers for each RECON data set to build logical
| records from smaller segments. The size of these buffers depends initially upon
| the CI size or the VSAM maximum record size (LRECL), whichever is smaller.
| After the initial allocation of these buffers, the logical record buffers grow over
| time as the largest logical record on the RECON data set grows. Because only
| the initial allocation of buffers is determined by the VSAM data set definition,
| the storage allocated to internal buffers cannot ultimately be affected by
| changes to either the CI or the record size.
| DBRC divides its own records into segments, each of which is always smaller
| than a single control interval and which is seen by VSAM as a complete
| physical record. VSAM record spanning is not used. Segmenting allows a
| logical RECON record to be as large as 16M bytes independent of the VSAM
| RECORDSIZE parameter.
| Recommendations: Initially set your minimum CI size to a minimum of eight
| KB. The allowable CI size is affected by the value you select for RECORDSIZE.
| Also, ensure that the smallest data CI size exceeds the largest index CI size by
| at least 2048 bytes. Failure to do so can seriously degrade your DBRC
| performance.
| Related Reading: See IMS Version 9: Customization Guide for further details
| about using the DSPBUFFS Buffer Size Specification Facility.
| CYLINDERS
| Specifies the amount of space to allocate to the cluster.
| FREESPACE
| The default values of FREESPACE(0 0) must not be used. While you are
| entering initial information in the RECON data set, you must specify a high
| control-interval percentage (for example, 70%) as free space. Later, you can
| lower the percentage with an Access Method Services (AMS) ALTER command.
| INDEXED
| Specifies that the cluster is defined for key-sequenced data.
| KEYS
| KEYS(32 0) is required.
| NAME
| Defines the cluster’s entry name and is required.
| NONSPANNED
| See RECORDSIZE.

| RECORDSIZE
| DBRC always writes physical VSAM records that are less than the CI size in
| length, even though the logical RECON records can be a long as 16 MB.
| Recommendation: Set the maximum record size to be, at most, equal to the CI
| size minus seven bytes and ensure that NONSPANNED is specified. For
| example, if the CI size was defined as 8192 bytes, then RECORDSIZE
| (4086,8185) is appropriate.
| SHAREOPTIONS
| SHAREOPTIONS(3 3) must be specified. The first value is required with
| single-host processors. Both values are required with multiple-host processors.
| SPEED
| This is recommended because the initial load is faster.
| NOWRITECHECK
| Avoid using WRITECHECK. It can degrade the RECON data set I/O
| performance. Using dual RECON data sets eliminates the need for
| WRITECHECK.
Recommendation: Do not use authorization keywords because frequent operator

prompting results.
Security Considerations for the RECON Data Set

All jobs that access the RECON data sets must have control-level authority to the
RECON data sets. Control, rather than update-level authority, must be specified,
because VSAM issues VERIFY macros. VERIFY uses control interval processing.
Even jobs with read intent for databases using DBRC must have control-level
authority because even a job with read intent updates information on the RECON
header record.
Initially Accessing the RECON Data Set

When a job needs to read the RECON data set, the RECON data set must be
opened. When three RECON data sets exist, DBRC determines which two are the
active RECON data sets and which is the spare data set. Table 6 shows how this
determination is made. The columns in Table 6 have the following meanings:
v In the DD Statement column, RECONA, RECONB, and RECONC represent the
RECON1, RECON2, and RECON3 DD statements in no particular sequence.
v The Data Set Status column indicates the status of the data set during open time.
v The Data Set Use column indicates how DBRC assigns the data set.
Table 6. Determining Which RECON Data Sets Are Accessed
Case DD Statement Data Set Status Data Set Use DBRC Selection Criteria
1 RECONA Create Mode Copy1 Not selected until INIT.RECON
command is specified
RECONB Create Mode Copy2 Not selected until INIT.RECON
RECONC Create Mode Spare
2 RECONA RECON Copy1 Current copy of RECON
RECONB Create Mode Copy2 Produced from Copy1

Table 6. Determining Which RECON Data Sets Are Accessed (continued)

Case DD Statement Data Set Status Data Set Use DBRC Selection Criteria
RECONB RECON Copy2 Current copy of RECON
RECONB RECON Unused Older copy than RECONA
RECONC Create Mode Copy2 Produced from Copy1
RECONC RECON Unused Older copy than RECONA
RECONC RECON Unused Older copy than RECONA
RECONB Create Mode Copy2 Produced from Copy1
8 RECONA Create Mode Copy1 Not selected until INIT.RECON
RECONB Create Mode Copy2 Not selected until INIT.RECON
11 RECONA Create Mode None Discontinue processing
Case 4 is the situation where two RECON data sets are available, but one is now
out of date. DBRC does not use the out-of-date RECON data set. Instead, it copies
the up-to-date RECON data set to the spare data set.
Only one RECON data set is available in cases 5, 10, and 12. If you have specified
the STARTNEW parameter of the INIT.RECON or CHANGE.RECON command,
processing continues with one RECON data set. Otherwise, processing ends.
Records in the RECON Data Set

The RECON data set contains many types of records. Some records, such as header
records, exist primarily to control processing of the RECON data set. Other records
exist to define the various data sets used in the recovery of DBDSs. Still others
exist to record events related to the use of DBDSs.
Figure 10 on page 64 shows the major relationships between RECON record types.
These relationships are described in detail in the sections that follow Figure 10 on
page 64.

Figure 10. Major RECON Record Types and the Relationships Between Them
Related Reading:
v See Appendix B, “Sample Listings from the RECON Data Set,” on page 473 for
details of what the records contain.
v See the IMS Version 9: Diagnosis Guide and Reference for a complete listing of
RECON keys.
RECON Header Records

The RECON data set has two record types that contain control information DBRC
uses in its processing:
v RECON header
In addition to internal control information that DBRC creates and uses, the
RECON header record contains information provided by you in the parameters
of the INIT.RECON and CHANGE.RECON commands.
v RECON header extension
The RECON header extension record contains RECON data set configuration
and state data that DBRC uses to process the RECON data sets.
Log Data Set Records

Three 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
– 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 a
PRILOG and one or more of the following: SECLOG, PRISLD, and SECSLD for a
given time period and IMS subsystem. All records in this set have the same start
and end times and normally have matching data set entries. The same LOGALL
record applies to all members of the set.
DBRC creates the PRILOG and PRISLD records whenever an online IMS opens the
first OLDS, and updates them each time an OLDS is archived. If you use dual
archiving, DBRC creates SECLOG and SECSLD records when the first OLDS is
archived and updates them each time an OLDS is archived.
Related Reading: See “Archiving an OLDS” on page 8 for more information about
DBRC and the archiving of online logs.
Log data sets output from IMS batch jobs are recorded in PRILOG / SECLOG
records even though, technically, they are SLDSs. These records are created
whenever the output log is opened and updated when volume switches occur.
In addition, during log recovery processing, DBRC creates an IPRISL or IPRIOL

record for each interim primary-log data set and an interim secondary-log record
for each interim secondary-log data set whenever the Log Recovery utility runs.
An interim log record is an internal record that is used to reflect intermediate
processing of the DUP function of the Log Recovery utility.
Related Reading: See IMS Version 9: Operations Guide for more information about
interim primary and interim secondary-log data sets.
Although not part of normal DBRC operation, you can use the following
commands to create log records (for example, to set up a test environment or for
RECON data set repair purposes):
v NOTIFY.PRILOG
v NOTIFY.SECLOG
Database Recovery Records

In addition to the log data set records, the following types of records contain
database recovery information:
v “Backout Record (BACKOUT)” on page 66
v “Change Accumulation Group Record (CAGRP)” on page 66

v “Change Accumulation Run Record (CA)”

v “Data Group Record (DBGRP, DBDSGRP, RECOVGRP)” on page 67
v “Database Records (DB)” on page 67
– “DL/I Database Records” on page 67
– “HALDB Records” on page 68
– “Fast Path Database Records” on page 69
v “Global Service Group Record (GSG)” on page 70
v “Image Copy Record (IMAGE)” on page 70
v “Reorganization Record (REORG)” on page 71
v “Log Allocation Record (LOGALL)” on page 71
v “Database Allocation Record (ALLOC)” on page 71
v “Recovery Record (RECOV)” on page 72
v “Subsystem Records (SSYS)” on page 72
Backout Record (BACKOUT)

A BACKOUT record contains information about units of recovery including time
stamp, associated PSB name, recovery token, and database name. The names of
nonrecoverable databases are not stored in the BACKOUT record.
Change Accumulation Group Record (CAGRP)

A CAGRP record identifies a change accumulation (CA) group. This record
includes up to 32,767 names of DBDSs whose change records are accumulated
during one run of the Database Change Accumulation utility. Each DBDS (for
which DBRC is controlling recovery) can be a member of only one CA group in
order for the Database Change Accumulation utility to accumulate its changes. You
specify the CAGRP name in the INIT.CAGRP command that you use to create a
CAGRP record in the RECON data set.
The CAGRP record contains the name of a member of a partitioned data set. This
member contains the skeletal JCL that is to be used to generate the JCL to run the
Database Change Accumulation utility for this CA group. The CAGRP record also
contains an indicator that specifies whether change accumulation data sets that
correspond to this group can be reused. It also contains an indication of the
maximum number of change accumulation data sets that are to be maintained for
the group.
Change Accumulation Run Record (CA)

For each CAGRP record, there can be up to 1024 CA records. A CA record contains
information about a change accumulation data set and can be either available or in
use.
An available CA record is created by an INIT.CA command. This CA record

contains the volume serial numbers and the data set name of a data set that is to
be used for output from a subsequent run of the Database Change Accumulation
utility. You can create available CA records only for those CA groups that are
defined with the REUSE parameter.
An in-use change accumulation record is created by a run of the Database Change

Accumulation utility. It can be a formerly available CA record that was used
during a run of the Database Change Accumulation utility, or it can be a new
record with information obtained from the JCL. The information in an in-use
change accumulation 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 utility
processed; or, if the CA processed a subset of logs, the start time of the first log
that 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 a DBDSGRP 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 databases and DEDB areas that can be named in the
DATAGROUP parameter for the /STA, /STO, and /DBR commands
v RECOVGRP, a group of DL/I databases and DEDB areas that are logically
related for database recovery purposes
All groups must have unique names. For example, a DBDSGRP cannot have the
same name as a DBGRP.
You use the INIT.DBDSGRP, CHANGE.DBDSGRP, DELETE.DBDSGRP, and LIST.DBDSGRP

commands to manipulate all three data group types.
Recommendation: Although any type of group can be named in the

DATAGROUP parameter for the /STA, /STO, and/DBR commands, the use of a
DBDSGRP is not recommended because it is inefficient.
Related Reading: See “DBDS Group Considerations” on page 48 for more

information on DBDS groups.
Database Records (DB)

DBRC treats DL/I, Fast Path, and HALDB (High Availability Large Database)
database records differently. These types of records, their treatment, and contents
are explained in the following sections.
DL/I Database Records: A DB record identifies a database that is registered and

whose recovery is under the control of DBRC. This record contains information
about 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
is used)
A DBDS record identifies a DBDS whose recovery DBRC is to control. This record
contains information about the DBDS (such as its data set organization) and related
recovery 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 in
order to generate JCL for utilities that are run for this DBDS
To describe DL/I databases and DBDSs, DBRC maintains logically related records,
as shown in Figure 11.
Figure 11. DBRC DL/I Records
HALDB Records: From a RECON data set perspective, HALDBs consist of a

HALDB master (TYPE=HALDB) and one or more HALDB partitions
(TYPE=PART).
Figure 12 shows the relationship of the RECON data set records that represent a
HALDB.
Figure 12. Record Structure for a HALDB in the RECON Data Set
HALDB Master (DSPDBHRC)
The RECON data set stores information pertaining to the entire HALDB by using a
DB 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

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
| v OLRCAP | OLRNOCAP
The TYPE=HALDB DB record stores information about the HALDB. Applications

conduct DB activity at the HALDB master level; DBRC conducts the DB activity at
the HALDB partition level. A subsystem authorizes a HALDB partition, not a
HALDB master.
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. The
HALDB Partition Definition utility displays the partition record information. The
LIST command does not display the partition record.
v Partition DB record (DSPDBHRC)
DSPDBHRC accesses the HALDB at the partition level. Like the TYPE=IMS DB
record, the DB record for the HALDB partition records all sharing and recovery
information. The partition name sets the database name field in this record.
TYPE=PART has been defined for this record. The following fields have the
same settings 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
| – OLRCAP | OLRNOCAP
v Partition DBDS records (DSPDSHRC)
Depending on the organization of the HALDB, there can be three types of
DBDSs for each HALDB partition: data, index, and ILDS data sets. Multiple data
DBDSs can exist, but only one of each of the others. Only data DBDSs can be
recovered. The other DBDSs are rebuilt using the HALDB Index/ILDS Rebuild
utility (DFSPREC0).
Related Reading: See IMS Version 9: Administration Guide: Database Manager for
information about the data set and DDN naming conventions for DBDS records.
Fast Path Database Records: To describe DEDBs, AREAs, and AREA Data Sets
(ADSs), DBRC has a logical structure of records, as shown in Figure 13 on page 70

Figure 13. DBRC Fast Path Database Records
DBRC uses the DB and DBDS records to describe both DL/I databases and DEDBs;
however, DBRC adds an ADS list to the Fast Path DBDS record giving information
about each ADS. Each DEDB may contain multiple areas, and each area may
contain up to seven ADSs.
The Fast Path DB record contains information similar to the information in a DL/I
DB 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 is
composed of an area authorization record and an area recovery record. The Fast
Path DB record is displayed in the listing as the DBDS record.
Related Reading: See the sample listing in Appendix B, “Sample Listings from the
RECON Data Set,” on page 473.
When an area is registered in the RECON data set, 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 group and the service groups that make up the
GSG. An RSR service group is made up of two service groups: the active and the
tracker.
GSG records are created by the INIT.GSG command and can be deleted by the
DELETE.GSG command. The INIT.SG and DELETE.SG commands add and remove
service group definitions to and from the GSG record. The CHANGE.SG command
modifies information about a service group.
Image Copy Record (IMAGE)

An IMAGE record contains information about an image copy data set and can be
either available or in-use.
An available IMAGE record is created by an INIT.IC command. It describes data

sets 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
with the 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 IMAGE
record or a reused in-use record.
v If the DBDS or area is defined with NOREUSE, it is a new record with the data
set description that is obtained from the JCL.
In addition to the data set description, the in-use IMAGE record identifies the type
of copy operation and contains the copy operation’s run time and, depending on
the type of copy, the copy operation’s stop time.
If you request that the image copy utility create an image copy data set and a
duplicate image copy data set, DBRC records information about both in the same
image copy record. The first record is designated IC1, and the duplicate is
designated IC2.
If you create a nonstandard image copy data set (one that the image copy utility
did not create), you must use a NOTIFY.UIC command to record its existence in the
RECON data set.
Related Command: See “NOTIFY.UIC” on page 346 for more information on the
IMAGE COPY record.
Reorganization Record (REORG)

| DBRC creates a REORG record each time you run the HISAM Reorganization
| Reload utility, HD Reorganization Reload utility, HALDB Online Reorganization
| utility for a registered DBDS or partition. For the HALDB Online Reorganization
| utility, the REORG record indicates that the type of REORG is online, includes a
| stop time, and indicates if the reorganized data set can be used for recovery. DBRC
| creates a REORG record in the RECON data set for each DBDS that you
| reorganize.
Related Command: See “NOTIFY.REORG” on page 332 for more information on

the REORG record.
Log Allocation Record (LOGALL)

DBRC creates a log allocation (LOGALL) record for each PRILOG record. A
LOGALL record identifies the registered DBDSs that were changed while the
corresponding log data set was open.
Database Allocation Record (ALLOC)

For Fast Path, DBRC creates an ALLOC record when the area is placed in
OPEN-for-update status. For DL/I, DBRC creates an ALLOC record when IMS
updates a DBDS the first time during a run of IMS or the first time after you enter
a /DBRECOVERY command. This record contains the time stamp 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 records that are needed for
recovery. If the DBDS is subsequently deallocated, DBRC adds the time stamp of
the deallocation to the ALLOC record.
DBRC automatically deletes allocation records if they are older than the oldest
image copy record and if DBRC no longer needs them for database recovery. As
DBRC deletes an ALLOC record, it changes the associated LOGALL record. This is
part of the DBRC Image Copy utility exit routine processing. This automatic
deletion of ALLOC records for a DBDS does not occur under either of the
following conditions:

v The ALLOC record has no deallocation time.

A deallocation time is recorded when the database or area has had the /DBR
command run against it. Otherwise, the ALLOC record uses the log close time as
an implicit deallocation time.
v The PRILOG record associated with the ALLOC record is open (it has a
STOPTIME of zero) but is not marked in error.
In cases such as these, you can use the DELETE.ALLOC command to delete unwanted
ALLOC records from the RECON data set. DBRC automatically updates allocation
time stamps during online and concurrent image copy utility exit routine
processing to move the allocation time stamps forward in time.
Related Command: See “DELETE.ALLOC” on page 206 and “NOTIFY.ALLOC”

on page 309 for more information on the ALLOC record.
Recovery Record (RECOV)

DBRC creates a RECOV record each time you run the Database Recovery utility to
recover a DBDS. The RECOV record can indicate one of these types of recovery:
v A full recovery of a DBDS where the RECOV record contains the time stamp of
the recovery.
v A time-stamp recovery where the RECOV record contains the time stamp of the
run of the Database Recovery utility and the time stamp to which the DBDS was
recovered.
Related Command: See “NOTIFY.RECOV” on page 329 for more information on

the RECOV record.
Subsystem Records (SSYS)

The RECON data set uses the subsystem (SSYS) record to describe data sharing
information.
An SSYS record is created when an IMS subsystem signs on to DBRC. This SSYS
record contains information about the subsystem and related recovery information
including:
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 “NOTIFY.SUBSYS” on page 345 for more information on

the SSYS record.
Maintaining the RECON Data Set

You should perform periodic maintenance on the RECON data set to maintain data
integrity and an acceptable level of performance. Maintenance of the RECON data
set falls into these categories:
v “Backing Up the RECON Data Set” on page 73
v “Deleting Unnecessary RECON Log Records” on page 73
v “Reorganizing the RECON Data Set” on page 74
v “Replacing Damaged RECON Data Sets” on page 75
v “Recovering the RECON Data Set” on page 76

v “Replacing a Discarded RECON Data Set” on page 77

v “RECON Loss Notification” on page 78
v “Preserving the Integrity of the RECON Data Set with DBRC Command
Authorization Support” on page 78
Backing Up the RECON Data Set

Back up the RECON data sets frequently. They are a critical resource. Always make
backup copies of the RECON data set after performing any RECON record
maintenance, such as registering databases and adding or deleting change
accumulation groups.
Use the BACKUP.RECON command to perform backup. This command issues the
necessary RESERVE commands (reserving the device during backup processing) to
ensure backup integrity. Then it invokes the AMS REPRO command to copy the data
set. The BACKUP.RECON command copies only the first copy of the RECON data set.
Its parameters determine whether it makes one or two copies.
Related Reading: See Chapter 8, “BACKUP Command,” on page 133 for additional
information on the BACKUP.RECON command.
Deleting Unnecessary RECON Log Records

You can delete unnecessary RECON records using the following methods:
v Automatic deletion by the RECON data set
v PRILOG compression
v Manual log record deletion
Automatic Deletion of Extraneous Records

Normally you should not need to perform much record maintenance for
database-related records.
When the RECON data set is notified of an image copy, it may delete or reuse the
oldest in-use IMAGE record, and a later IMAGE record becomes the oldest IMAGE
record. RECOV and REORG records with start times earlier than the (now) oldest
IMAGE record, and ALLOC records with DEALLOC times earlier than that, are
now extraneous, and are deleted from the RECON data set. This is the image copy
cleanup process.
At the same time that extraneous IMAGE records are deleted from the RECON
data set, all active ALLOC records are updated to the time of the first log volume
necessary for recovery, based on the oldest image copy for the DBDS or area.
When the cleanup process deletes an extraneous ALLOC record it changes the state
of the associated LOGALL records. Once all the ALLOC records associated with
the LOGALL record have been deleted (this may take place over many image
copies for many databases), the PRILOG record associated with the LOGALL
record becomes inactive.
Compressing the PRILOG Record

PRILOG record compression is the deletion of all inactive data set entries in the
PRILOG record. A data set entry is defined as being 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 oldest
ALLOC on the log or the first gap in the data set entries. A gap occurs when an
OLDS has not yet been archived.
When inactive data set entries are deleted from active PRILOGs, they are
compressed to a single dummy data set entry that has the same start time as the
start time of the log and the same stop time as the stop time of the last inactive
data set entry deleted.
Automatic PRILOG Compression

PRILOG record compression is attempted automatically after an OLDS has been
archived. At an RSR (remote site recovery) tracking site, automatic compression is
attempted when a tracking log data set is opened by Log Router and recorded in
the RECON data set.
Compression includes the deletion of all inactive data set entries in the PRILOG
record. When applicable, corresponding entries in the SECLOG, PRISLD, and
SECSLD records are also deleted.
Manual Process for PRILOG Compression

You can initiate PRILOG record compression manually by using the DELETE.LOG
INACTIVE command. This command deletes inactive data set entries from active
PRILOG records and deletes entire inactive PRILOG records.
Deleting Log Records

DBRC does not automatically delete RECON records that describe log data sets
(PRILOG and SECLOG records). This design gives you control over which RECON
records associated with log data sets are deleted. You must periodically delete
PRILOG and SECLOG records that are no longer needed for recovery.
Use the DELETE.LOG INACTIVE command to delete inactive PRILOG and SECLOG
records.
Deleting log records does not prevent the RECON data sets from filling up because
the space freed by deletions might not be reused by VSAM. However, if you delete
the log records before backing up or reorganizing the RECON data set, you are
able to reclaim the space during backup or reorganization.
Related Reading:
v See “DELETE.LOG (for OLDS)” on page 212 for more information on LIST.LOG.
v See “LIST.LOG (for a PRILOG Family)” on page 300 for more information on
DELETE.LOG.
Reorganizing the RECON Data Set

You need to reorganize the RECON data sets periodically. Many of the record keys
in the RECON data set include the date and time. DBRC recording of IMS log and
database activity can cause CI and CA splits, that can degrade performance. In
addition, deleting unnecessary records might not prevent the RECON data set
from filling up because VSAM does not always reuse the space freed.
Using CHANGE.RECON to Reorganize a RECON Data Set

You can reorganize a RECON data set online if you are using dynamic allocation
for the RECON data set. A spare RECON data set must be available. In this
situation, you can issue the CHANGE.RECON command with the REPLACE option.
This causes DBRC to copy and reorganize the active RECON data set (specified on

the CHANGE command) to the spare data set. VSAM removes all CI and CA splits,
and restores the original FREESPACE attributes.
The CHANGE command also deallocates the old RECON data set (the one that
needed reorganization). Before you can delete and redefine this data set, however,
you must wait for all other subsystems that are using it to deallocate it. If you
redefine the data set with the same name it originally had, it is available to the
online system for use as a spare data set. You can repeat this process to reorganize
the second active RECON data set. If you use JCL in order to allocate data sets,
dynamic deallocation does not occur.
If you do not use dynamic allocation or if a spare RECON data set is not available,
you must wait for the online subsystem and all other subsystems that access the
RECON data set to deallocate it before you can reorganize.
Backing up RECON Data Sets before Reorganization

It is recommended that you back up the RECON data sets before and after
reorganizing, using the following procedure:
1. Copy the RECON data sets 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.
Procedure for Reorganizing the RECON Data Set

To clean up your logs and reorganize your RECON data sets, follow this
procedure. This process assumes that you are running DBRC in dual mode with
RECON1 (as Copy1), RECON2 (as Copy2), and a spare.
1. Issue a LIST.LOG OPEN command to identify any open logs. Determine which of
the 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 data set reorganization.
3. Issue a CHANGE.RECON with the REPLACE option for RECON1. DBRC then:
a. Signals the start of the RECON data set reconfiguration with message
DSP0380I
b. Identifies the subsystems that are active at reconfiguration with message
DSP0388I
c. Signals that the process has completed with message DSP0381I.
4. Replace the discarded RECON data set. See “Replacing a Discarded RECON
Data Set” on page 77 for more information.
Your RECON data sets have now been reorganized and the logs are now clean.
Replacing Damaged RECON Data Sets

If an I/O error occurs in the current RECON data set that is the only one
remaining, DBRC stops the job. Any other jobs that are currently using the RECON
data set continue to run if no other I/O error is encountered.
If an I/O error occurs in a RECON data set and two RECON data sets exist, DBRC
attempts to locate a spare data set. If a spare is available, DBRC copies the RECON

data set without the I/O error to the spare RECON data set. DBRC then
establishes the spare as the Copy2 RECON data set.
Recommendation: After the spare RECON data set replaces the RECON data set
that had the error, redefine the discarded RECON data set as quickly as possible. If
you immediately replace the RECON with the I/O error, you are unlikely to
experience a subsystem failure due to loss of all RECON data sets. See “Replacing
a Discarded RECON Data Set” on page 77for more information.
If DBRC cannot locate a spare RECON data set and you have specified the
STARTNEW parameter of the INIT.RECON command, DBRC continues processing
with one RECON data set. Otherwise, DBRC completes the current job but does
not start new jobs until you define a spare RECON data set.
Recovering the RECON Data Set

Steps for recovering your RECON data set depend on the set up of your RECON
data set and the situation. The following paragraphs discuss various solutions for
recovering a RECON data set.
A Spare RECON data set is available: If an I/O error occurs on a RECON and a
spare data set is available, DBRC copies the good RECON to the spare, and then
activates the spare.
If, however, you want to analyze the RECON error, before deleting and redefining
the discarded RECON data set, make a copy of it for later problem diagnosis.
A Spare RECON data set is not available: If a spare RECON is not available, all
currently executing jobs continue processing using the RECON data set in single
mode. If you specified the STARTNEW parameter in the INIT.RECON or
CHANGE.RECON command, DBRC allows new jobs to start with only one RECON
data set. This is not recommended as it jeopardizes the integrity of the system.
If one of the data sets in the set of RECON data sets becomes unusable by DBRC,
you need to deallocate the RECON data set that is unusable and allocate a new
spare.
In an RSR environment, the isolated log sender (ILS) starts its own copy of DBRC.
If Automatic RECON Loss Notification is not active, you might need to stop ILS to
terminate the DBRC in the transport manager address space. This causes the ILS’s
DBRC to deallocate the RECON data sets so that you can replace the unusable
RECON data set. Issue a STOP ILS(gsg) command for each started ILS instance.
Then issue START ILS(gsg) to bring up ILS and DBRC again.
Both RECON data sets are not usable:
It is unlikely that both RECON data sets would be not usable. If, however, both
RECON data sets ever become unusable, follow this procedure:
1. Stop all jobs that require access to the RECON data set.
2. Use the AMS REPRO command to back up the RECON data sets if you can
access both of them. This step is optional, but it is recommended.
3. Use the AMS utility to delete and redefine your RECON data sets.
4. Use the AMS REPRO command to restore one of the RECON data sets.
5. Use the AMS REPRO command to restore the other RECON data set from the
first.

6. Use the LIST.RECON command to list one of the RECON data sets. Evaluate the
list and determine which DBDSs have been updated since you made the
backup in step 2 on page 76. If you cannot determine which DBDSs have been
updated, assume that all have been updated.
7. Use the CHANGE.IC command with the INVALID parameter to mark all image
copy 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 RECON data
sets.
The RECON data sets are now restored and resynchronized with the databases.
If you do not control an excessive number of databases, it might be easier to follow

this procedure:
1. Stop all jobs that require access to the RECON data set.
2. Define new RECON data sets.
3. Initialize these RECON data sets.
4. Register the environment. Always keep a backup copy of the most recently
initialized, but not-yet-used, RECON data set available.
5. Take image copies of all databases.
Finally, before you proceed with your regular operations, clean up the new
RECON data set by, for example, closing any open, out-of-date OLDSs with the
NOTIFY.PRILOG command.
Replacing a Discarded RECON Data Set

DBRC detects that a RECON data set is discarded only when some activity occurs
that causes DBRC to access the RECON data sets. You can have multiple instances
of DBRC whenever you have multiple IMS subsystems, online or batch. You
cannot delete and redefine a discarded RECON data set until all instances of DBRC
detect that a change has occurred and they deallocate the discarded data set. DBRC
lists the subsystems that are active at reconfiguration in message DSP0388I. This
message enables you to identify the subsystems that might need your help in
detecting the status change of the RECON data sets.
To redefine a RECON data set after an I/O error has occurred, or in conjunction
with the CHANGE.RECON REPLACE command, follow this procedure:
1. Allow all batch jobs using DBRC to finish.
2. Issue LIST.RECON STATUS in all online subsystems if you do not have Automatic
Loss Notification active. Issuing the command causes the online subsystems to
obtain the same Copy1 and Copy2 RECONs and to deallocate the discarded
RECON data set. If you do have Automatic Loss Notification active, all
subsystems are automatically notified to deallocate the discarded RECON data
set. See “RECON Loss Notification” on page 78 for more information on
RECON Loss Notification.
3. Use the AMS DELETE command to delete the discarded RECON data set.
4. Use the AMS DEFINE command to recreate the RECON data set as an empty
VSAM KSDS data set. Use the same procedure that you used originally to
create the RECON data set. See “Creating a RECON Data Set” on page 60.

RECON Loss Notification

All DBRC instances that are allocated to the RECON, using the same IMSplex, are
notified of errors, at the time the errors occur, through the IMS Structured Call
Interface (SCI). Then, any DBRC allocated to the discarded RECON will deallocate.
DBRC obtains the IMSplex name from the SCI Registration exit routine
(DSPSCIX0), or from an EXEC parameter, IMSPLEX. DBRC records the IMSplex
name in the RECON data set when the first use of RECON Loss Notification
occurs for a given RECON data set. Any subsequent attempt at accessing a
RECON data set using a different IMSplex, or no IMSplex, is rejected and message
DSP1136A is issued. Otherwise, RECON Loss Notification is automatically invoked.
If you want to change the IMSplex associated with a set of RECONs, use the
IMSPLEX() or NOPLEX parameter on the CHANGE.RECON command. See
“CHANGE.RECON” on page 179 for more information. To change an
IMSplex/RECON association when a DBRC instance is active, perform the
following procedure to avoid having your command rejected and message
DSP1137I issued:
1. Wait for all DBRC activity on the current IMSplex to cease.
2. Submit a Database Recovery Control utility job to change the IMSplex name.
3. Alter the IMSplex name in DSPSCIX0.
4. Ensure that the new IMSplex SCI is ready.
5. Resume DBRC activity on the new IMSplex.
Related Reading:
v See the IMS Version 9: Common Service Layer Guide and Reference for introductory
information about IMSplexes.
v See the IMS Version 9: Customization Guide for more information on the SCI
Registration exit routine.
v See the IMS Version 9: Utilities Reference: Database and Transaction Manager and the
IMS Version 9: Installation Volume 2: System Definition and Tailoring for more
information about the IMSPLEX EXEC parameter.
Preserving the Integrity of the RECON Data Set with DBRC

Command Authorization Support
| The RECON data sets are critical to the integrity of IMS databases. Therefore, you
| should restrict access (control authorization) to the DBRC commands. Consider
| providing access to only a subset of the DBRC commands for those users who
| must issue them.
In the online region, IMS provides some authorization functions for commands
issued. By default, IMS restricts /RMxxxxxx commands (except for /RMLIST) to the
Master Terminal Operator (MTO).
| You can establish authorization control for DBRC commands through RACF® (or
| an equivalent product), a user exit routine, or both. For example, logon ID SMITH
| could have access to issue an INIT.DB command against DBD PAYROLL but not
| against DBD CUSTOMER.
Related Reading: For more information about using exit routines and RACF for
command authorization, see:
v “Authorizing Commands with RACF” on page 79

v “Authorizing security profiles for DBRC commands” on page 80

v “Authorizing Commands with the DBRC Command Authorization Exit Routine
(DSPDCAX0)” on page 80
v “Authorizing Commands with Both the DBRC Command Authorization Exit
Routine (DSPDCAX0) and RACF” on page 80
The HALDB Partition Definition utility is an ISPF application that allows you to
manage the definitions of IMS HALDBs and their partitions in the RECON data
set, providing functionality equivalent to the following:
v INIT.DB
v INIT.PART
v CHANGE.DB
v CHANGE.PART
v CHANGE.DBDS
v DELETE.DB
v DELETE.PART
v LIST.DB
Authorization for the HALDB Partition Definition utility is controlled using the
same resources as defined for these commands with one exception; the
CHANGE.PART resource is used in place of the CHANGE.DBDS resource.
Manager, SC18-7833 for more information about the HALDB Partition Definition
utility.
Authorizing Commands with RACF

You can set up DBRC command authorization support with RACF by defining
resource profiles (explicit or generic) that cover all of the DBRC commands and
permitting appropriate user access to these profiles. The resource name
corresponds directly to the command and consists of a high-level qualifier (HLQ)
and up to three elements of the DBRC command. The resource name model has
the following format:
v High Level Qualifier (for example, SAFHLQ)
v Command verb (for example NOTIFY)
v Command modifier (for example, PRILOG or IC)
v Command qualifier (for example, dbname or OLDS)
DBRC uses a list of resource names for command authorization support. See
Appendix C, “Resource Names for Command Authorization,” on page 565.
Different profiles can be used based on the set of RECON data sets being used, but
only one HLQ per RECON data set is allowed. For example, you might use an
HLQ name of PRODRECN for the production RECON data sets and an HLQ name
of TESTRECN for the test RECON data sets.
Other considerations for your definitions are as follows:

v Resource profiles protecting the DBRC commands must be defined in the
FACILITY resource class
v User identifiers found in the ACEEUSRI field of the ACEE are used for all
authorization checking and the user must be permitted READ access to the
resource profile at a minimum

v DBRC command authorization is enabled or disabled using the CHANGE.RECON

and INIT.RECON command with the CMDAUTH keyword. The HLQ is required
when enabling command authorization.
| Authorizing security profiles for DBRC commands

| You can define security resource profiles for your system to protect specific DBRC
| commands and permit appropriate user access to each command. The security
| resource name corresponds directly to the DBRC command and consists of a
| high-level qualifier (HLQ) and up to three elements of the command. Assume that
| you are using RACF for data security and decide to use IMSA as your HLQ to
| identify your IMS system.
| To restrict access to the DELETE.SUBSYS command:

| 1. Issue the following RACF command to allow access to all DBRC commands:
| RDEFINE FACILITY IMSA.** OWNER(...) UACC(READ)
| 2. Issue the following two RACF commands to restrict DELETE.SUBSYS to the
| userids listed in the ID(...) parameter:
| RDEFINE FACILITY IMSA.DELETE.SUBSYS.* OWNER(...) UACC(NONE)
| PERMIT IMSA.DELETE.SUBSYS.* CLASS(FACILITY) ID(...) ACC(READ)
| Command protection is now in effect.
| 3. Issue the following command to clear the cache and cause RACF to refresh and
| read the new values from the database:
| SETROPTS REFRESH GENERIC(FACILITY) RACLIST(FACILITY)
| 4. Issue the following DBRC command to specify that accesses for this RECON
| use the prefix IMSA for security checking:
| CHANGE.RECON CMDAUTH(SAF,IMSA)
Authorizing Commands with the DBRC Command Authorization

Exit Routine (DSPDCAX0)
| You can use the DBRC Command Authorization exit routine (DSPDCAX0) to
| verify that a user is authorized to issue a particular command. If you decide to use
| this exit, you will make the appropriate selection when using the INIT.RECON or
| CHANGE.RECON commands. Refer to “INIT.RECON” on page 284 and
| “CHANGE.RECON” on page 179 for more information.
DSPDCAX0 is a required exit routine if it is specified to authorize DBRC

commands (that is, if either sub-parameter EXIT or BOTH is specified in the
CMDAUTH keyword on the INIT.RECON or CHANGE.RECON commands). DSPDCAX0
must be found in an authorized library or in LINKLST. If DSPDCAX0 is found in a
concatenated STEPLIB or JOBLIB, only the data set containing DSPDCAX0 must be
authorized. If DSPDCAX0 is found in LINKLST, no authorization check is
performed.
Related Reading: See IMS Version 9: Customization Guide, for more information on
the DBRC Command Authorization exit (DSPDCAX0).
Authorizing Commands with Both the DBRC Command

Authorization Exit Routine (DSPDCAX0) and RACF
| The DBRC command authorization exit routine (DSPDCAX0) can be used in
| conjunction with RACF to provide command authorization. In such cases, the
| security product is invoked first. The return and reason codes are passed to the
| exit routine. The return code that the exit routine issues ultimately determines the
| success or failure of the command authorization; the exit routine overrides the

| outcome of the security product. Therefore, DBRC messages that are put out as a
| result of unsuccessfully invoking the security product will be suppressed.
Again, if EXIT or BOTH is specified in the CMDAUTH keyword on the INIT.RECON

or CHANGE.RECON commands, DSPDCAX0 is a required exit routine. Also,
DSPDCAX0 must be found in an authorized library or in LINKLST. If DSPDCAX0
is found in a concatenated STEPLIB or JOBLIB, only the data set containing
DSPDCAX0 must be authorized. If DSPDCAX0 is found in LINKLST, no
authorization check is performed.
Related Reading: See IMS Version 9: Customization Guide for more information on
the DBRC Command Authorization exit (DSPDCAX0).
Tracking Changes Made to the RECON Data Set

For administrative purposes, it is a good practice to keep a log of the changes
made to the RECON data set. You can provide your own exit routine which is to
be called every time RECON records are changed or read. This exit routine, also
called the RECON I/O exit routine (DSPCEXT0), allows you to keep track of
changes to RECON in the form of a journal.
Related Reading: See IMS Version 9: Customization Guide for detailed information
about the RECON I/O exit routine.

Chapter 5. Skeletal JCL
The following sections discuss various aspects of working with skeletal JCL.
In This Chapter:
v “Generating JCL and User-Defined Output”
v “Using IBM-Supplied Skeletal JCL” on page 84
v “Writing Your Own Skeletal JCL” on page 85
v “Contents of the Skeletal JCL Data Set” on page 85
v “Skeletal JCL Syntax” on page 86
Generating JCL and User-Defined Output

Eight GENJCL commands are supported by the Database Recovery Control utility.
Seven of these commands generate the JCL and control statements necessary to run
various IMS recovery-related utilities. You can use the remaining command,
GENJCL.USER, to generate user-defined output, including JCL.
Table 7 lists the eight GENJCL commands and what they generate.
Table 7. GENJCL Commands and What They Generate
Command (PDS Member) What the Command Generates
GENJCL.ARCHIVE (ARCHJCL Log Archive utility JCL and control statements
member)
GENJCL.CA (CAJCL member) Database Change Accumulation utility JCL and
control statements
GENJCL.CLOSE (LOGCLJCL member) Log Recovery utility JCL and control statements
GENJCL.IC (ICJCL member) Database Image Copy or Database Image Copy 2
utility JCL and control statements
GENJCL.OIC (OICJCL member) Online Database Image Copy utility JCL and control
statements
GENJCL.RECEIVE (ICRCVJCL Database Recovery utility JCL and control statements
member)
GENJCL.RECOV (RECOVJCL member) Database Recovery utility JCL and control statements
GENJCL.USER (DSPUPJCL member) User-defined output, including JCL and control
statements
Note: Sample JCL for the HALDB INDEX/ILDS Rebuild utility (DSPUPJCL) is
shipped with IMS and can be used with the GENJCL.USER command, but
other types of JCL can be used as well. No default is defined.
When you issue a GENJCL command, it uses a skeletal JCL execution member. The
execution member is a model of the JCL or user output that you are producing.
The execution member contains symbolic keywords. DBRC substitutes current
information for the symbolic keywords. The substituted information comes from
the RECON data set and from skeletal JCL default members, and from your
USERKEY values. Typical of the information DBRC substitutes for symbolic

Skeletal JCL
keywords are data set names and volume information. DBRC performs the
keyword substitution and then generates the JCL or user output you requested by
issuing the GENJCL command.
| Related Reading: See Appendix A, “Symbolic Keywords Recognized by DBRC,”

| on page 435 for a complete list of the symbolic keywords that are recognized by
| DBRC.
IBM supplies a JOB statement execution member that is used by all GENJCL
commands. If the IBM-supplied skeletal JCL execution members meet your general
requirements, you can modify them slightly to provide installation-specific
information. Information on what needs to be modified is contained in “Using
IBM-Supplied Skeletal JCL.”
If the IBM-supplied skeletal JCL does not meet your general requirements or if you
plan to use the GENJCL.USER command, you must write your own skeletal JCL
members 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 85.
Using IBM-Supplied Skeletal JCL

If you are generating JCL for the IMS recovery-related utilities using the
IBM-supplied skeletal JCL execution members, the process is simple. It involves
modifying the IBM-supplied skeletal JCL execution members. For the skeletal JCL
execution members, see “IBM-Supplied Skeletal JCL Execution Members” on page
443. Before you use them:
v Add two DD statements (JCLPDS and JCLOUT) to the DBRC dependent address
space procedure used for online IMS. JCLPDS identifies the partitioned data set
containing the skeletal JCL execution members. JCLOUT identifies the data set to
which the generated job is to be written. Output is in card image format. The
output data set can be a punch file, a DASD data set that you plan to examine
before submitting the job for execution, or directly to the z/OS internal reader.
These two ddnames can be specified on the GENJCL command. When GENJCL is
used, the two specified data sets are in effect for the GENJCL command only, and
not for the life of the job. The JCLOUT data set is opened at the start of the
command 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 z/OS internal reader) only contains the
results from the last command that was processed.
v Add any STEPLIB and STEPCAT DD names, and job accounting information
that your installation requires to the skeletal JCL execution member. Except for
the skeletal JCL member for the JOB statement, do not add any JOBCAT,
JOBLIB, and JES control statements to your skeletal JCL; doing so causes errors
if multiple steps are generated.
v Change the default value for the REGION parameter on the skeletal JCL EXEC
statement 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, because DBRC
does not verify any of the JCL that is generated.

Skeletal JCL
Writing Your Own Skeletal JCL

The following sections describe the things you need to know before writing your
own skeletal JCL or developing symbolic keywords to modify the IBM-supplied
skeletal JCL. You must write your own skeletal JCL or symbolic keywords if the
IBM-supplied skeletal JCL execution members do not meet your requirements or if
you plan to use the GENJCL.USER command. IBM provides no skeletal JCL execution
member for the GENJCL.USER command.
Contents of the Skeletal JCL Data Set

As shown in Figure 14 on page 86, the skeletal JCL data set contains the skeletal
JCL members used by the GENJCL command processor to generate output. The two
types of skeletal JCL members are execution members and default members.
Execution members are models of the output you are generating. Execution
members can be IBM supplied (as described in “Using IBM-Supplied Skeletal JCL”
on page 84) or supplied by you. Execution members contain symbolic keywords,
which represent information DBRC provides.
Default members specify default values for symbolic keywords in the execution
members. The use of default members is optional. You provide the default
members. To use a default member, you specify the member on the GENJCL
command. Or, in the case of DBDS and CA groups, you can implicitly specify the
default member (see “Specifying Default Members” on page 104 for more
information).
Chapter 5. Skeletal JCL 85

Skeletal JCL Syntax
Figure 14. Skeletal JCL Data Set Contents
Skeletal JCL Syntax

| Skeletal JCL execution members are models of the output to be produced. The
| execution members contain symbolic keywords and control keywords. Symbolic
| keywords are symbolic parameters that DBRC substitutes with a value in the
| output stream (for example, data set names), based upon what is specified on a
| GENJCL command and information obtained from the RECON data set.
| Control keywords regulate what output is generated by DBRC, based upon what is
| specified on a GENJCL command (for example, what RECON records are to be used
| for keyword substitution).
The keywords in skeletal JCL members must be in uppercase.
Simple keywords and control keywords are explained in the following sections:
v “Symbolic Keywords”
v “Using Control Keywords” on page 88
v “Writing Control Keywords” on page 94
v “Understanding Skeletal JCL Default Members” on page 103
Symbolic Keywords
When JCL is generated, symbolic keywords in the skeletal JCL execution members
are replaced with the current keyword value. For example, the IBM-supplied

Skeletal JCL Syntax
skeletal JCL execution members use %TIME as a symbolic keyword. When DBRC
encounters %TIME, it replaces it with the time of day. Keyword substitution occurs
each time DBRC encounters a symbolic keyword. Multiple symbolic keywords can
exist in a skeletal JCL execution member.
Symbolic keywords must be assigned a value before you use them. Keyword
values are assigned (or set) in several different ways as specified below:
v The GENJCL command specifies values for some of the symbolic keywords in
skeletal JCL execution or default members. User-defined keywords are assigned
a value in the USERKEYS parameter in the command. Other keyword values are
set by various parameters on the command. For example, the SSID parameter
sets the value for the %SSID keyword (the subsystem ID).
v Skeletal JCL default members set default values for keywords in skeletal JCL
execution members.
v The RECON data set also provides keyword values. For example, when the
GENJCL.ARCHIVE command is issued, the ddnames and data set names for the
OLDS 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 been
assigned a value, no substitution takes place. Instead, DBRC issues a warning
message.
When writing your own skeletal JCL execution members, you can define your own
symbolic keywords as well as use the symbolic keywords already recognized by
DBRC. For a list of the symbolic keywords that DBRC recognizes, see Appendix A,
“Symbolic Keywords Recognized by DBRC,” on page 435. You can also define your
own symbolic keywords and add them to the IBM-supplied skeletal JCL execution
members.
Here are some conventions, restrictions, and other detail you should know when
writing symbolic keywords:
v Keywords must begin with a percent (%) sign.
v The minimum keyword length is two characters, including the percent sign. The
maximum 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 remaining
characters must be alphanumeric (A-Z, 0-9). Keywords are delimited by a
non-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 with
predefined keywords.
v User-defined symbolic keywords must be assigned a value with the USERKEYS
parameter 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 the
keyword, the remaining data on the record is shifted to the left and filled with
blanks. If the keyword value is longer than the keyword, the remaining data is
shifted to the right. If any non-blank characters are shifted beyond column 71, a
JCL continuation statement is generated. In some cases (for example, when the
output 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 output

record for DBRC to split it. When DBRC cannot find a break in the statement, it
splits the statement at column 71.
Using Control Keywords

Use the following control keywords to regulate what JCL (or other output) is
generated:
%SELECT and %ENDSEL
The %SELECT keyword selects the RECON records that are needed in order
to resolve symbolic keywords. The %ENDSEL keyword indicates the end of
the records selected by the %SELECT keyword. These control keywords
always occur in pairs. A %SELECT keyword is followed by one or more
execution member records, which is followed by the %ENDSEL keyword.
This sequence of records is called a control group or, more specifically, a
select group.
%DELETE and %ENDDEL
The %DELETE keyword deletes records from the generated output stream.
Deletion occurs based on a specific condition. The %ENDDEL keyword
delimits the scope of the %DELETE keyword. These control keywords always
occur in pairs. A %DELETE keyword is followed by one or more execution
member records, which is followed by the %ENDDEL keyword. This sequence
of records is called a control group or, more specifically, a delete group.
%SET MEMBER
The %SET MEMBER keyword specifies a different skeletal JCL execution
member that is to be used in the next step of a multistep job.
%SET TIMEFMT
The %SET TIMEFMT keyword is used to specify a form for time stamps that
appear in GENJCL output.
Using the %SELECT and %ENDSEL Keywords

Use the %SELECT keyword to select one or more records from the RECON data set.
The selected records identify IMS data sets or events tracked by DBRC.
Information from the selected records is used to resolve symbolic keywords in the
select group. Symbolic keywords can occur in the execution member records or in
the %SELECT keyword statement.
The format for a select group follows:

%SELECT record_type(selection_criteria)
execution_member_record(s)
%ENDSEL
The record_type is the type of RECON record to be selected. You can select any of
the following record_types:
v OLDS (PRIOLD)
v SLDS (PRISLD)
v RLDS (PRILOG)
v IC (IMAGE)
v CA (CA)
v ALLOC (ALLOC)
v DBDS (DBDS)

Skeletal JCL Syntax
The selection_criteria depend on the type of record you select, and can be time
ranges and ddnames.
Both the record_type and selection_criteria can be symbolic keywords.
| As RECON records are selected, information from them is used to set the values of
| symbolic keywords. Depending on the type of record being selected, the values of
| a particular group of symbolic keywords associated with the selected record are
| set. The group of symbolic keywords associated with particular records are
| discussed in “Writing Control Keywords” on page 94.
Any values assigned to a keyword before the select group is processed are
overridden when the select group is processed. The keyword values in effect after
the 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, the
records in the select group are not processed. The next records to be processed are
those that appear just after the %ENDSEL statement. A select group can occur within
a delete group. When this occurs and the delete group is deleted, the select group
is not processed, and no keyword values are set (or changed).
The selection_criteria for a select group can cause one or more RECON records
to be selected. One execution member can be output more than once depending
upon the type of records that have been selected.
When the output stream is JCL, a select group can generate either concatenated or
repeated DD statements. The first execution member record of the select group
determines which is to be generated. Repeated DD statements are generated if this
record is a JCL DD statement and the ddname is a symbolic keyword. Otherwise, a
concatenated DD statement is generated.
Example:
Assume that the first record is:

//DDNAME DD DSN= . . .
In this case, concatenated DD statements are generated. Alternatively, the first

record might be:
//%DDNAME DD DSN= . . .
In this case, repeated DD statements are generated. When repeated DD statements

are generated, you must provide some mechanism to ensure that the repeated
ddnames are unique. When selecting OLDSs, DBRC uses the OLDS ddname, which
is in the OLDS RECON record. DBRC does not track ddnames for any other type
of data set. Therefore, DBRC might not be able to generate unique ddnames for
data sets that are not OLDSs.
The two sections that follow explain the record_type and selection_criteria
parameters in more detail.
Specifying the Record Type Parameter: The types of records that can be specified
on the %SELECT keyword are shown in Table 8 on page 90.

Skeletal JCL Syntax
Table 8. 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 selected
unless the SLDS record in the RECON data set shows the SLDS has
an error. In this case, the SECSLD is selected. The SLDS is the one
created by the Log Archive utility when archiving OLDSs, not the
one created by an IMS batch region. To select an IMS batch SLDS,
specify RLDS.
SSLDS Specifies that SECSLDs are to be selected.
RLDS Specifies that RLDSs are to be selected. The PRIRLDS is selected
unless the PRILOG record in the RECON data set indicates the
RLDS has an error. In this case, the SECRLDS is selected. RLDS
refers to both the RLDS created by the Log Archive utility and the
SLDS created by 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.
ALLOC Specifies that DBDS allocation records are to be selected.
DBDS Specifies that DBDS records are to be selected.
Understanding the Selection Criteria Parameter: The selection criteria depend on

the record type you select. Selection criteria are described under the sections on
selecting individual record types.
The following common terms, used for selection criteria, are used in the remainder
of this chapter.
dbds qualifier
Specifies the DBDS with which the selected records are to be associated. The
DBDS can be specified as dbname, ddname, or CA group name. When a CA
group name is specified, all DBDSs in the CA group are used for selection. The
DBDS qualifier is used when selecting:
v RLDSs
v Change accumulation data sets
v Image copy data sets
v ALLOC records
v DBDSs
time qualifier
Specifies a time stamp or a range of time stamps.
DBRC selects RECON records by their record key. Many records contain a time
stamp and the time that is contained in the record key is signified by an
adjacent asterisk (*) in a listing. The time qualifier that is specified in a
FROMTIME or TOTIME parameter determines what records DBRC selects.
Some records such as PRILOG or PRISLD records consist of multiple DSN
entries, each of which has a start time and stop time. DBRC cannot select
specific DSN entries without first selecting the entire log record. The

Skeletal JCL Syntax
FROMTIME and TOTIME values must be specified such that the entire log
record that contains desired DSN entries is selected based on the time stamp
that is in the record key.
For example, if you specify a FROMTIME of 12:00, DSN entries with time
stamps later than 12:00 (but that are included in a PRISLDS record with a start
time of 11:00) would not be selected and displayed by DBRC, because the
PRISLDS 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 the
forms described in “Standard Time Stamp Format” on page 126.
FIRST
Specifies that the oldest record is to be selected.
LAST
Specifies that the most recent record is to be selected.
| LASTDSET
| Similar to LAST but will ignore empty log records and return the last
| RLDS or SLDS that contains DSN entries. LASTDSET is only valid for
| RLDS and SLDS (including secondary) and will default to LAST if
| specified for any other record type.
(FROM(time),TO(time)) or (FROM(time)) or FROM(time) or (TO(time)) or
TO(time)
Specifies that all records with time greater than or equal to the FROM time
and less than or equal to the TO time are to be selected.
ALL
Specifies that all records are to be selected.
Using the %DELETE and %ENDDEL Keywords

Use the %DELETE and %ENDDEL keywords to delete records from the output stream
based on a specific condition. The syntax of a delete group follows:
%DELETE (relational expression) execution_member_record(s) %ENDDEL
%DELETE statements cannot be nested. Each %DELETE keyword must be followed by

a 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 symbolic keyword.
v 'value' is any character string enclosed in single quotes. A null string ('') can
be specified for the value. You can specify a zero time value. The time qualifier
can be specified in the forms described in “Standard Time Stamp Format” on
page 126.
v %userkey is any keyword defined via the USERKEYS parameter in the GENJCL
command. The %userkey must be enclosed in quotes and the %userkey value
must exclude leading zeros.
v op is one of the following operators:
EQ Equal
NE Not equal
LT Less than

Skeletal JCL Syntax
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, the

relational expression is evaluated. If the expression is true, the delete group is
deleted from the output stream. If the expression is false, the applicable records are
copied to the output stream after keywords are resolved. If a value has not been
assigned to a keyword, the value is the null string (''). If an undefined keyword is
encountered in the skeletal JCL, an error message is received and no substitution
takes place.
Specifying Complex Expressions: You can specify complex expressions consisting

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:

%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 (blanks
are optional).
v The statement is processed from left to right with no connective priority and no
bracketing.
where:
relexpx = relational expression
This complex expression takes the results of the OR operation between relexp1 and
relexp2 and performs the AND operation with relexp3.
Using the %SET MEMBER Keyword

The %SET MEMBER keyword can be used when you are generating multistep jobs
(such as GENJCL.CA with the VOLNUM parameter specified). You use %SET MEMBER to
specify a different skeletal JCL execution member than the one that is executed for
the first step of the job. The execution member you specify is used in all job steps
after the first. You can explicitly code various %keywords in the execution member
that 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:
%SET_MEMBER=newmbrname
The %SET MEMBER keyword can be placed anywhere in the current skeletal JCL
execution member. However, it takes effect only after processing of the current

Skeletal JCL Syntax
execution 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 for
all job steps after the first job step. newmbrname must reside in the library named in
the JCLPDS DD statement. newmbrname is not used until it is necessary to begin
processing of the new member. It is possible to specify an incorrect member name
and not have an error condition occur until a GENJCL command is issued that
causes enough steps to be generated to cause the member to be read.
Using the %SET TIMEFMT Keyword

The %SET TIMEFMT keyword is used to specify a format for time stamps that appear
in GENJCL output. See “TIMEFMT Parameter” on page 127 for more information on
time stamps.
For GENJCL.USER, the default is:

TIMEFMT(O,O,C,2,TEMP,1)
Note that the GENJCL TIMEFMT default values have been chosen to produce correct
output with IBM-supplied skeletal JCL. If you use the %SET statement to change the
TIMEFMT values in a way that affects the values substituted into the IBM-supplied
JCL statements, the results might be invalid.
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 next four examples are based on the following skeletal JCL member (called
USER01) that is used with GENJCL.USER.
LOGETIM=%LOGETIM
%ENDSEL
v This sample output format was obtained by using the USER01 JCL, specifying
SSID(XXXX), and using the default for TIMEFMT, which is:
TIMEFMT(O,O,C,2,1)
LOGETIM=960021315001-0700
SSID(XXXX), and using the default for TIMEFMT on an open log.
LOGETIM=000000000000+0000
SSID(XXXX), and using the specification, TIMEFMT(,N).
LOGETIM=960111314544
SSID(XXXX), and using the specification, TIMEFMT(,,P,4).
LOGETIM=1996.011 13:15:00.0 -07:00

Skeletal JCL Syntax
Restriction: The %SET TIMEFMT keyword affects GENJCL output only if it is issued
via the GENJCL command or from a %SET statement in the skeletal JCL.
The syntax of the %SET TIMEFMT keyword is:
%SET_TIMEFMT(subparm,[subparm],...)
Related Reading: For detailed information about the TIMEFMT keyword, its
parameters, and format, see “TIMEFMT Parameter” on page 127. Remember that
the TIMEFMT keyword affects GENJCL output only if it is issued via the GENJCL
command or from a %SET statement in the skeletal JCL.
Writing Control Keywords

When writing control keywords, you need to observe the following conventions
and restrictions:
v Control keywords must begin in column 1 of a skeletal JCL execution member
record.
v Everything specified for the keyword must be contained on one record. Any
data following the control statement is ignored.
v Any number of skeletal JCL execution member records can be contained in a
control group.
v Delete groups and select groups cannot be nested. However, a select group can
be contained within a delete group, or a delete group can be contained within a
select group.
v Execution member records containing control keywords are not copied to the
output stream.
Selecting OLDSs
The syntax of the %SELECT keyword to select OLDSs is as follows:
%SELECT OLDS(ssid,olds_qualifier)
ssid
Subsystem ID of the IMS online control region that created the OLDS.
olds_qualifier
Specifies the OLDSs that are to be selected as follows:
INUSE
Specifies that the OLDS that is currently in use by the specified subsystem
is to be selected. If dual logging is in effect, both the primary and
secondary OLDSs are selected.
LATEST
Specifies that the OLDS that was most recently opened by the specified
subsystem is to be selected. If dual logging is in effect, both the primary
and secondary OLDSs are selected.
UNARCH
Specifies that all unarchived OLDSs for the specified subsystem are to be
selected. If dual logging is in effect, both the primary and secondary
OLDSs are selected.

Skeletal JCL Syntax
(DDNAME)
Specifies one or more OLDSs by ddname. If dual logging is in effect and
both the primary and secondary OLDS are to be selected, both ddnames
should be specified.
ALL
Specifies that all OLDSs for the specified subsystem are to be selected.
In the execution member records following the %SELECT keyword, you use symbolic
keywords to specify the type of information to be gathered for each OLDS record
that is selected. The types of information you can gather are:
%OLDSDDN The ddname of the OLDS.
%OLDSDSN The data set name of the OLDS.
%OLDSTYP The OLDS type. DBRC sets the %OLDSTYP to P for primary OLDS or
S for secondary OLDS.
%OLDOTIM The time the OLDS was opened. DBRC sets %OLDOTIM in the form
yydddhhmmsst{offset}.
%OLDCTIM The time the OLDS was closed. DBRC sets %OLDCTIM in the form
yydddhhmmsst{offset}. If the OLDS has not been closed, DBRC sets
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 the
OLDS.
%OLDLRID The log record sequence number of the last log record of the
OLDS.
Example 1: The following select group generates repeated DD statements for all
unarchived 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 to
subsystem IMSA:
%SELECT OLDS(IMSA,ALL)
%OLDSTYPOLDS DD NAME=%OLDSDDN
DSN=%OLDSDSN
CLOSE TIME=%OLDSCTIM
%ENDSEL
The output generated by this select group might be:

POLDS DD NAME=DFSOLP00
DSN=IMS.POLDS00
CLOSE TIME=842351638193+0012
DSN=IMS.POLDS01

Skeletal JCL Syntax
CLOSE TIME=842351712246+0055
DSN=IMS.POLDS02
CLOSE TIME=000000000000+0000
Selecting SLDSs
The syntax of the %SELECT keyword to select SLDS is:
%SELECT slds_type(ssid,time_qualifier)
slds_type
Can be specified as SLDS (for the PRISLD) or SSLDS (for the SECSLD). This
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 the associated
| secondary data set if one that is not also in error exists. If the associated 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 it is marked
| in error. An SLDS record might not contain a DSN entry. In this case, the
| values for %SLDSDSN, %SLDUNIT, and %SLDVOLS are null. You can use the LASTDSET
| time qualifier to have the last PRISLDS data set that contains data set entries
| returned. You must use the %DELETE statement in order to ensure that DBRC
| substitutes valid data in the generated JCL. See “Example 4” on page 97.
ssid
The subsystem ID (of the IMS online control region) that created the OLDSs
that were archived to become SLDSs.
time_qualifier
The time qualifier as specified in “Understanding the Selection Criteria
Parameter” on page 90.
In the execution member records following the %SELECT keyword, you specify
(using symbolic keywords) the type of information to be gathered for each SLDS
record that is 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 form
%SLDETIM The stop time of the SLDS. DBRC sets the %SLDETIM in the form
%SLDOTIM The start time of the PRISLDS/SECSLDS. DBRC sets %SLDOTIM in
the form yydddhhmmsst{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 the
SLDS.
%SLDLRID The log record sequence number of the last log record of the SLDS.

Skeletal JCL Syntax
%SLDCHKT The Checkpoint Types value of the SLDS data set entry. This is a
hexadecimal representation of the bit settings of the value where:
v Bit 0 - simple checkpoint
v Bit 1 - snapq checkpoint
v Bit 2 - dumpq checkpoint
v Bit 3 - purge checkpoint
v Bit 4 - freeze checkpoint
v Bit 5-7 - not used
Example 3: The following select group generates the most recent SLDS for
subsystem 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
If the SLDS record has more than one data set, then all the data sets to be selected
and your output may look like this:
LATEST SLDS: DSN=IMS.IMSA.SLDSP.D97107.T1405235.V06
STOP TIME=971071420469+0100
STOP TIME=971071420579+0100
STOP TIME=971071430087+0100
Example 4: The following select group generates a concatenated DD statement for

all SLDSs for subsystem IMSA that have an open time greater than or equal to
840031903298.
%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 is

because the volume serial number list was longer than the output record.
The %DELETE statement prevents the JCL statement from being generated for an
SLDS record that does not contain a DSN entry.

Skeletal JCL Syntax
Selecting RLDSs
The syntax of the %SELECT keyword to select RLDSs can be specified as follows:
%SELECT RLDS(ssid,time_qualifier )
,max_volumes
SRLDS(ssid,time_qualifier )
,max_volumes
RLDS(dbds_qualifier,time_qualifier )
,max_volumes
| Use SRLDS to request that secondary RLDS records be selected. Secondary RLDS
| records can be specifically requested only when you specify SSID. When you
| specify dbds_qualifier, you are specifically requesting primary RLDS records. If
| the primary RLDS is marked in error, DBRC selects the associated secondary data
| set if one that is not also in error exists. If no associated data set exists or if it is
| also in error, DBRC selects the original record. An RLDS record might not contain
| a DSN entry. In this case, the values for %LOGDSN, %LOGUNIT, and %LOGVOLS are null.
| You can use the LASTDSET time qualifier to have the last PRILOG data set that
| contains data set entries returned.
| ssid
| The subsystem ID of the IMS online control region or an IMS batch region.
| PRILOG (or SECLOG) records corresponding to the specified SSID are selected
| to satisfy the specified search criteria. Because RECON records are selected, all
| data sets identified by the record are selected.
| time_qualifier
| Time qualifier as specified in “Understanding the Selection Criteria Parameter”
| on page 90.
| dbds_qualifier
| DBDS qualifier as specified in “Understanding the Selection Criteria
| Parameter” on page 90. When a dbds_qualifier is specified, only RLDSs that
| contain log records corresponding to the specified DBDS are selected. (In other
| words, those RLDSs for which an ALLOC record exists in the RECON data
| set.) Only primary RLDSs can be selected when the dbds_qualifier is
| specified.
| max_volumes
| The maximum number of log volumes to be selected. If max_volumes is
| specified, processing of the select group terminates when the specified number
| of log volumes is reached. If max_volumes is specified and a log merge situation
| exists, more than the specified number of volumes can be selected. This is to
| ensure that a valid subset of logs is selected.
keywords to specify the type of information to be gathered for each RLDS record
%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 form

Skeletal JCL Syntax
%LOGETIM The stop time of the RLDS. DBRC sets %LOGETIM in the form
yydddhhmmsst{offset}. If the data set is still open, the time is set to
000000000000+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. %LOGMERG
is always set to NO if SSID is specified.
%LOGONL Set to YES if the RLDS is associated with an online region. Set to NO
for 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 the
RLDS.
%LOGLRID The log record sequence number of the last log record of the RLDS.
%LOGOTIM The start time of the PRILOG/SECLOG. DBRC sets %LOGOTIM in the
form yydddhhmmsst{offset}.
Example 5: The following select group generates a DD statement for the

most-recent RLDS for subsystem BATCHJOB. This example assumes the RLDS is
still 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 the RECON data set for the subsystem or if the
most-recent RLDS has been closed, no DD statement is generated. Otherwise, the
generated DD statement might be:
//LOGDD DD DSN=IMS.RLDS,DISP=OLD,
// UNIT=3400,
// VOL=SER=(VOLUM1,VOLUM2)
// LABEL=(1,SL)
Selecting Image Copy Data Sets

The syntax of the %SELECT keyword to select image copy data sets is:
%SELECT IC(dbds_qualifier,time_qualifier)
dbds_qualifier and time_qualifier

DBDS qualifier and time qualifier are as specified in “Understanding the
Selection Criteria Parameter” on page 90.
In the execution member records following the %SELECT keyword, you specify
(using symbolic keywords) the type of information to be gathered for each image
copy record that is selected. If the duplicate image copy is marked in error, the
DBRC selects the 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, or
SMSNOCIC.
Skeletal JCL Syntax
%ICFSEQ The file sequence number of the image copy data set if it is a
NONHSSP 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 form
%ICUNIT The unit type of the image copy data set if it is a NONHSSP type;
otherwise, ICUNIT is null.
%ICVCNT The number of volumes of the image copy data set if it is a
NONHSSP type; otherwise, ICVCNT is null.
%ICVOLS The volume serial number list of the image copy data set if it is a
NONHSSP 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 the
selected 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. If
the IC was created by HSSP, IC2FSEQ is set to null.
%IC2UNIT The unit type of the duplicate image copy data set. If the IC was
created by HSSP, IC2UNIT is set to null.
%IC2VCNT The number of volumes of the duplicate image copy data set. If the
IC 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 oldest
image copy data set for the DBDS with a database name of SHISAMDB and a
ddname 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)

Skeletal JCL Syntax
Selecting Change Accumulation Data Sets

The syntax of the %SELECT keyword to select change accumulation data sets is:
%SELECT CA(dbds_qualifier,time_qualifier)

Selection Criteria Parameter” on page 90.
keywords to specify the type of information to be gathered for each change
accumulation record that is selected. The types of information you can gather are:
%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
input to the change accumulation data set. DBRC sets %CALGTM in
the form yydddhhmmsst{offset}.
%CATIME The change accumulation data set time in the form
%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 sets
created since time 842310000000+0000 for CA group CAGRP1.
%SELECT CA((CAGRP1),FROM(842310000000+0000))
DSNAME=%CADSN
VOLUMES=%CAVOLS
RUNTIME=%CATIME
LOGTIME=%CALGTM
%ENDSEL
The generated output might be:

DSNAME=CAGRP1.DSN1
VOLUMES=VOLUM1,VOLUM2,VOLUM3,
VOLUM4, C
// VOLUM5,VOLUM6
RUNTIME=842310618230
LOGTIME=842302315557
DSNAME=CAGRP1.DSN2
VOLUMES=VOLUM1,VOLUM2
RUNTIME=842361824443
LOGTIME=842360934519
In this example, the volume serial number list for the first data set does not fit on
the output record. Therefore, a JCL continuation statement is generated (even
though JCL is not being generated).
Selecting DBDS Allocation (ALLOC) Records

The syntax of the %SELECT keyword to select ALLOC records can be one of the
following:

Skeletal JCL Syntax
%SELECT ALLOC(dbds_qualifier,time_qualifier)
%SELECT ALLOC(PRILOG,time_qualifier)

Selection Criteria Parameter” on page 90. When a dbds_qualifier is specified,
ALLOC records corresponding to the specified DBDSs are selected. All ALLOC
records for the specified DBDS with allocation times within the bounds of the
specified time_qualifier are selected. When PRILOG is specified, all ALLOC
records corresponding to PRILOG records within the specified time bounds are
selected.
keywords to specify the type of information to be gathered for each ALLOC record
%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}. Set
to 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 is
set to NO.
%ALLUSID The update set identifier (USID)
Example 8: The following select group generates a list of information about all
ALLOC records for the DBDS with a database name of SHISAMDB and ddname of
SHISAMDD:
%SELECT ALLOC((SHISAMDB,SHISAMDD),ALL)
DBNAME %DBNAME
DDNAME %DBDDN
ALLOC time %ALLTIME
DEALL time %DALTIME
PRILOG time %PLGTIME

DBNAME SHISAM
DDNAME SHISAM
ALLOC TIME 832560800000+0000
DEALL TIME 000000000000+0000
PRILOG TIME 832560630000+0000
Selecting DBDS Records

The syntax of the %SELECT keyword to select DBDS records is:
%SELECT DBDS(dbds_qualifier)
dbds_qualifier
DBDS qualifier is as specified in “Understanding the Selection Criteria

Skeletal JCL Syntax
Parameter” on page 90. For DEDBs, the select group is processed once for each
defined area data set (ADS) for each specified area. For other types of
databases, the select group is processed once for each specified DBDS.
keywords to specify the type of information to be gathered for each DBDS record
%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 Path
database. Set to DLI for DBDSs of non-HALDBs. Set to PDATA for
data DBDSs of HALDBs. Set to PINDEX for primary index DBDSs of
HALDBs. 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 in the
RECON data set. Set to UNAVAIL if the ADS is unavailable. For
other types of databases, DBADSAV is set to null.
%DBDSSEL Set to YES if any DBDS records are selected. Otherwise, DBDSDEL is
set to NO.
%DBUSID For DEDBs, the update set identifier (USID) of the area. For other
types of databases, DBUSID is set to NULL.
%DBDSNRV Set to YES if the DBDS is non-recoverable. Otherwise, DBDSNRV is set
to NO.
Example 9: The following select group generates a series of DD statements for

available area data sets for the area named DBHVSAM1. This area is in the DEDB
named DIVNTZ04.
%SELECT DBDS((DIVNTZ04,DBHVSAM1))
%DELETE (%DBADSAV ne 'AVAIL')
//%DBADDN DD DSN=%DBDSN,DISP=OLD
%ENDDEL
%ENDSEL

//FP1ADD1 DD DSN=IMS.FP1ADD1,DISP=OLD
//FP1ADD2 DD DSN=IMS.FP1ADD2,DISP=OLD
Understanding Skeletal JCL Default Members

Skeletal JCL default members are used to set default values for keywords you have
defined in the skeletal JCL execution members. The use of default members is
optional. You must supply any default members to be used.
Writing Default Members

Default members can have two types of records: assignment records or comment
records. Assignment records assign default values to user-defined keywords.
Assignment records must contain a percent sign (%) in column 1. If a record does
not contain a percent sign in column 1, it is a comment record, which DBRC
ignores.

Skeletal JCL Syntax
%user defined keyword='value'
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. The
entire value must be contained on one record. Any data following the closing
single quote is ignored. A closing single quote is required. If a closing single quote
is missing, 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 = %DEDBNAM
AREA NAME = %AREANAM
Using the DEFAULTS parameter and assuming the values are not overridden, the
GENJCL command generates the following:
DATABASE NAME = DIVNTZ04
AREA NAME = DBHVSAM1
Specifying Default Members

You can specify default members either explicitly or implicitly.
Members are explicitly specified using the DEFAULTS parameter on the GENJCL
command. 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 default
members to be implicitly used are specified using the DEFLTJCL parameter on the
INIT.DBDS, CHANGE.DBDS, INIT.CAGRP, and CHANGE.CAGRP commands. Only one
default member is allowed per DBDS or CA group.
The use of an implicit default member can be overridden with the NODEFLT
parameter on the GENJCL command. When both explicitly and implicitly specified
default members are used, explicitly specified members have precedence. That is, if
a keyword is assigned a value in both members, the value assigned by the
explicitly specified member is used.
If a keyword is assigned a value both in a default member and in the USERKEYS

parameter of the GENJCL command, the latter value is used. USERKEYS parameter
values override default member values.
Using User-Supplied or Modified Skeletal JCL

Before using your skeletal JCL execution or default members, you must do the
following:
v Add the JCLPDS and JCLOUT ddnames to the JCL required to run DBRC. JCLPDS
identifies the partitioned data set containing the skeletal JCL execution members.
JCLOUT identifies the data set to which the generated job is to be written. Output
is in card image format. The output data set can be a punch file, a DASD data
set that you plan to examine before submitting the job for execution, or directly
to the z/OS internal reader.
v Add to the skeletal JCL execution member any STEPLIB and STEPCAT ddnames
and job accounting information that your installation requires. If the DD

Skeletal JCL Syntax
statements contain comments or continuation characters, they are ignored when

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.

Skeletal JCL Syntax

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 “Changing the RECON Data Set to Output Time Stamps in Local Time of
Origin”
v “Locating the Last SLDS Stop Time in RECON” on page 108
v “Adjusting GENMAX When It Is Reached or It Is Too High” on page 109
v “Getting PRILOG Compression to Work” on page 110
v “Getting Notified When the PRILOG Record Exceeds the Maximum Record
Size” on page 111
v “Closing an Open Online PRILOG” on page 111
v “Deleting Log Records” on page 112
v “Working with Subsystem Records (SSYS)” on page 113
v “Removing Authorization Inconsistency Between the SSYS from DB/AREA
Records” on page 114
v “Getting Change Accumulation to Start Processing Logs Again” on page 114
v “Getting Change Accumulation Working When It States Nothing to Process” on
page 114
v “Moving Log Data Sets” on page 115
v “Cataloging Data Sets” on page 115
v “Performing Multiple Cold Starts in a Test Environment” on page 116
v “Avoiding Some Causes of RECON Data Set Enqueue Problems” on page 117
Changing the RECON Data Set to Output Time Stamps in Local Time
of Origin
If the listing of the RECON data set does not list the offset value for time stamps,
the record might have been created when the offset value was different from the
current offset value. Using DBRC commands to change or delete such a record will
result in a “record-not-found” condition because the current offset is applied if it is
not included in the time stamp parameter of the command.
To change the RECON data set to output time stamps in local time of origin, when
they were created, use one of the following:
CHANGE.RECON TIMEFMT(O,O,P,4,PERM)
or
CHANGE.RECON TIMEFMT(O,O,P,2,PERM)
This will permanently change the RECON data set to output time stamps when the
records were originally created with the appropriate offsets in punctuated
four-digit or two-digit year formats. The time stamp listed can be used in
commands such as the following:
CHANGE.PRILOG STARTIME('2002.063 16:11:58.1 -08:00') -
DSSTART('2002.063 16:11:58.1 -08:00') ERROR RLDS

Hints and Tips
Locating the Last SLDS Stop Time in RECON

Follow this procedure to find the last SLDS stop time in the RECON data set using
the GENJCL.USER command. This can be done when IMS is still running and also
works if the PRISLD is already closed.
| 1. Create a skeletal JCL execution member first. Here is an example of a member
| named SELSLDS:
| %SELECT SLDS(%USSID,LAST)
| %ENDSEL
| SLDSDD BEG=%SLDSTIM
| END=%SLDETIM
| VOL=%SLDVOLS
| UNT=%SLDUNIT
| DSN=%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 is
| to be run with member SELSLDS:
| GENJCL.USER MEMBER(SELSLDS)
| NOJOB USERKEYS((%USSID,'IMS1')) -
| JCLOUT(SYSPRINT)
| 3. Below is the SLDS listing:
| PRISLD RECORD SIZE= 784
| START = 04.194 08:59:46.7 * SSID=IMS1 VERSION=9.1
| STOP = 04.194 09:02:33.9 #DSN=4
| GSGNAME=**NULL**
| FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0
|
| DSN=IMSVS.SLDSP.IMS1.D04194.T0859467.V00 UNIT=SYSDA
| START = 04.194 08:59:46.7 FIRST DS LSN= 0000000000000001
| STOP = 04.194 09:00:49.0 LAST DS LSN= 0000000000000B70
| FILE SEQ=0001 #VOLUMES=0001
| CHECKPOINT TYPES=80: SIMPLE=Y SNAPQ=N DUMPQ=N PURGE=N FREEZE=N
|
| VOLSER=000000 STOPTIME = 04.194 09:00:49.0
| CKPTCT=1 CHKPT ID = 04.194 08:59:48.4
| LOCK SEQUENCE#= 000000000000
|
| START = 04.194 09:00:49.0 FIRST DS LSN= 0000000000000B71
| STOP = 04.194 09:01:17.5 LAST DS LSN= 00000000000010AD
| CHECKPOINT TYPES=00: SIMPLE=N SNAPQ=N DUMPQ=N PURGE=N FREEZE=N
|
| VOLSER=000000 STOPTIME = 04.194 09:01:17.5
| CKPTCT=0 CHKPT ID = 04.194 08:59:48.4
|
| START = 04.194 09:01:17.5 FIRST DS LSN= 00000000000010AE
| STOP = 04.194 09:01:41.2 LAST DS LSN= 000000000000163E
| CHECKPOINT TYPES=00: SIMPLE=N SNAPQ=N DUMPQ=N PURGE=N FREEZE=N
|
| VOLSER=000000 STOPTIME = 04.194 09:01:41.2
| CKPTCT=0 CHKPT ID = 04.194 08:59:48.4
|
| START = 04.194 09:01:41.2 FIRST DS LSN= 000000000000163F
| STOP = 04.194 09:02:33.9 LAST DS LSN= 000000000000189C
| CHECKPOINT TYPES=08: SIMPLE=N SNAPQ=N DUMPQ=N PURGE=N FREEZE=Y

Hints and Tips
|
| VOLSER=000000 STOPTIME = 04.194 09:02:33.9
| CKPTCT=1 CHKPT ID = 04.194 09:02:33.7
Below is the output that results from issuing the previous sample GENJCL.USER
command:
| SLDSDD BEG=041940901412-0700
| END=041940902339-0700
| VOL=000000
| UNT=SYSDA
| DSN=IMSVS.SLDSP.IMS1.D04194.T0901412.V00
Adjusting GENMAX When It Is Reached or It Is Too High

Prior to image copy utility execution, verification exit processing may determine
that one 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 recovery
period.
– No available image copies exist that can be used.
– Message DSP0063I was displayed.
See “Solutions When GENMAX is Too Low” on page 109 on how to correct this.
v Situation 2 - GENMAX Value is Too High
– GENMAX has not been reached so the in use image copy data sets cannot be
used.
– No available image copy data sets exist that can be used.
– Message DSP0084I was displayed.
– No recovery period is defined.
See “Solution When GENMAX is Too High” on page 110 on how to correct this.
Solutions When GENMAX is Too Low

Either of the following will solve Situation 1 as described in “Adjusting GENMAX
When It Is Reached or It Is Too High”:
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 command to increase the GENMAX and INIT.IC parameters
| to define the additional image copy data sets:
| 1. Create a JCL job similar to one of the following jobs. These examples assume
| that your DBD name is THISDB, that your area name is AREA1, and that your
| previous 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) -
Chapter 6. Hints and Tips for DBRC 109

Hints and Tips
| 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 When GENMAX is Too High

Either of the following steps will resolve Situation 2 as described in “Adjusting
GENMAX When It Is Reached or It Is Too High” on page 109.
v 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 new

GENMAX value is recorded regardless of whether the oldest image copies are
undeletable, because they are within the recovery period.
Getting PRILOG Compression to Work

If your PRILOG is not getting compressed, you will receive message DSP1150I
because of one of the following reasons:
v EARLIEST CHECKPOINT
If this time stamp is within the first DSN entry in the PRILOG, then
compression is not possible. Most often, the oldest checkpoint needed for restart
causing the problem is the checkpoint to rebuild the message queues. If so, take
a SNAPQ checkpoint. When the OLDS that records this SNAPQ checkpoint is
archived, the earliest checkpoint time stamp is updated.
v EARLIEST ALLOC TIME
The databases listed in the LOGALL record are in earliest allocation time stamp
order. The earliest allocation time listed in the LOGALL record is associated with
the first databases in the listing.
Concurrent image copies (CICs) and Online image copies (OICs) update the
allocation time to reflect the earliest log that is needed for recovery. The
checkpoint IDs and checkpoint counts on the logs prior to the start of the CIC
are used to determine where the new allocation time is set. If the allocation
times are not being moved forward-in-time, ensure that checkpoint IDs and
counts are being recorded in the DSN entries.
Old allocations for any databases in the LOGALL record can cause compression
to fail. Image copy databases on a regular basis to allow old allocations to be
deleted.
v LOG RETENTION TIME
Indicates the minimum amount of time that DBRC is to keep log records in the
RECON data set.

Hints and Tips
Getting Notified When the PRILOG Record Exceeds the Maximum

Record Size
DBRC ABENDs when the PRILOG record exceeds the 16M maximum record size.
DBRC issues warning messages indicating that a PRILOG record is approaching its
maximum size. You can control the timing of those messages, taking into account
the typical rate at which your system fills OLDSs and the average number of
volumes in each archive data set.
The current size of the PRILOG record is printed on the listing of the PRILOG
record.
Closing an Open Online PRILOG

During time stamp recoveries, when DBRC reports that there are open allocations
that are not needed for the recovery, it might be easier to close the open PRILOG
rather than deleting the individual allocations. Use the NOTIFY.PRILOG command to
close the open PRILOG.
If an open PRILOG record is found for an online IMS subsystem, and the PRILOG
record is not for the current run of IMS, it indicates that the last OLDS for this
online IMS has not yet been archived. If the OLDS is no longer available and you
need to close the open PRILOG record, the following commands can be used to
create a dummy DSN entry in the PRILOG:
| NOTIFY.PRILOG SSID(IMS1) RLDS DSN(DUMMY) FIRSTREC(00) -
| STARTIME(042010652499) VOLSER(VOL001)
| NOTIFY.PRILOG SSID(IMS1) RLDS -
| STARTIME(042010652499) RUNTIME(042010753260) LASTREC(500)
| CHANGE.PRILOG STARTIME(042010652499)
| ERROR - DSSTART(042010653260)
Below is the PRILOG as it appears in the RECON data set before issuing the
NOTIFY.PRILOG command to close it:
| PRILOG RECORD SIZE= 464
| START = 04.201 06:52:49.9 * SSID=IMS1 VERSION=9.1
| STOP = 00.000 00:00:00.0 #DSN=2
| GSGNAME=**NULL**
| EARLIEST CHECKPOINT = 04.201 06:52:52.0
|
| DSN=IMSVS.RLDSP.IMS1.D04201.T0652499.V00 UNIT=SYSDA
| STOP = 04.201 06:53:12.7 LAST DS LSN= 0000000000000642
|
| VOLSER=000000 STOPTIME = 04.201 06:53:12.7
| CKPTCT=1 CHKPT ID = 04.201 06:52:52.0
|
| DSN=IMSVS.RLDSP.IMS1.D04201.T0653127.V00 UNIT=SYSDA
| STOP = 04.201 06:53:26.0 LAST DS LSN= 00000000000007A9
|
| VOLSER=000000 STOPTIME = 04.201 06:53:26.0
| CKPTCT=0 CHKPT ID = 04.201 06:52:52.0
|
| LOGALL
| START = 04.201 06:52:49.9 *

Hints and Tips
| EARLIEST ALLOC TIME = 04.201 06:53:03.2

| DBDS ALLOC=1 -DBD- -DDN- -ALLOC-
| DBVHDJ05 CJVHDG1E 1
Below is the PRILOG as it appears in the RECON data set after issuing the
NOTIFY.PRILOG command to close it (differences are highlighted):
PRILOG RECORD SIZE= 624
START = 04.201 06:52:49.9 * SSID=IMS1 VERSION=9.1
STOP = 04.201 07:53:26.0 #DSN=3
GSGNAME=**NULL**
FIRST RECORD ID= 0000000000000001 PRILOG TOKEN= 0
EARLIEST CHECKPOINT = 04.201 06:52:52.0
DSN=IMSVS.RLDSP.IMS1.D04201.T0652499.V00 UNIT=SYSDA
START = 04.201 06:52:49.9 FIRST DS LSN= 0000000000000001
STOP = 04.201 06:53:12.7 LAST DS LSN= 0000000000000642
FILE SEQ=0001 #VOLUMES=0001
VOLSER=000000 STOPTIME = 04.201 06:53:12.7

CKPTCT=1 CHKPT ID = 04.201 06:52:52.0
LOCK SEQUENCE#= 000000000000
STOP = 04.201 06:53:26.0 LAST DS LSN= 00000000000007A9
VOLSER=000000 STOPTIME = 04.201 06:53:26.0

CKPTCT=0 CHKPT ID = 04.201 06:52:52.0
DSN=DUMMY ERROR UNIT=3400

STOP = 04.201 07:53:26.0 LAST DS LSN= 00000000000001F4
VOLSER=VOL001 STOPTIME = 04.201 07:53:26.0

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
LOGALL
START = 04.201 06:52:49.9 *
EARLIEST ALLOC TIME = 04.201 06:53:03.2
DBDS ALLOC=1 -DBD- -DDN- -ALLOC-
DBVHDJ05 CJVHDG1E 1
Deleting Log Records

As time passes, the RECON data set accumulates old records associated with IMS
log data sets. You can use the DELETE.LOG command to eliminate unnecessary
PRILOG families and their associated LOGALL records.
Related Reading: See “DELETE.LOG (for OLDS)” on page 212 and “DELETE.LOG
(for RLDS and SLDS)” on page 212 for descriptions of the available DELETE.LOG
commands and their parameters.
Use the DELETE.LOG INACTIVE command periodically to keep the RECON data set
free of unnecessary PRILOG family records. Refer to the description of the
DELETE.LOG command INACTIVE parameter for the conditions that must be met
before DBRC deletes a PRILOG family of records. The DELETE.LOG command,
specified with either the INACTIVE or the TOTIME parameter, does not delete
active log records.

Hints and Tips
Common problems are old open (nonzero stop time) PRILOG records that were
created by jobs that terminated abnormally. These jobs abended without closing
their logs. You can find these open logs by issuing the LIST.LOG command with the
OPEN parameter. You can use the DELETE.LOG command with the STARTIME
parameter 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 the RECON
data set? If authorization for a database fails and you list the database and all the
subsystem records in the RECON data set, you might wonder how the subsystem
names (SSIDs) were created. The following sections discuss different aspects of the
SSIDs.
Naming Conventions for SSIDs in RECON Subsystem Records

The SSYS record is created when a signon call is issued to DBRC. The SSID must
be unique. Normal conventions for creating the subsystem name are:
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 translated

to 0-9,A-Z
ZZZZ is the control region IMSID
Online image copy is the only BMP that creates its own subsystem record in the
RECON data set.
Batch Backout
If batch backout is processing a log created by a batch subsystem, the SSID that is
used is the job name of the subsystem that is being backed out. The job name of
the batch backout utility job is not used.
If batch backout is processing a log that was created by an online subsystem, the
job name of the backout utility job is used as the SSID.
Deleting a Subsystem Record

When you no longer need a particular subsystem record in the RECON data set,
the following commands can be used to delete the SSYS:
CHANGE.SUBSYS SSID(XXXXX) STARTRCV
CHANGE.SUBSYS SSID(XXXXX) ENDRECOV <---(removes auth from DB)
DELETE.SUBSYS SSID(XXXXX)

Hints and Tips
Subsystem Record Size

The subsystem record grows in size. If the subsystem record grows to exceed the
16M maximum record size, IMS abends.
Removing Authorization Inconsistency Between the SSYS from

DB/AREA Records
To change database authorization or if authorization fails, a LIST.DB shows that the
DB 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 the
command below to remove a database/area name from the list in a subsystem
record when a LIST.SUBSYS shows it authorized and a LIST.DB does not show it
authorized.
CHANGE.DB DBD(dbname) SSID(XXXX) UNAUTH (or)
CHANGE.DB DBD(dbname) AREA(areaname) SSID(XXXX) UNAUTH
Getting Change Accumulation to Start Processing Logs Again

Change accumulation erroneously stops processing logs and the source of the
problem is traced to an OLDS left in the ARC STARTED state. An IPL of z/OS is
done on the CPU where the archive job was run and the status of the OLDS
remains in this state. GENJCL.ARCHIVE jobs do not include any OLDS in ARC
STARTED status. The online IMS that created the OLDS is not running on this
CPU.
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. The
OLDS is included in the next archive job. To avoid this problem, run archive jobs
on the same CPU as their corresponding IMS systems.
In cases where manual intervention is required, use the following command to

change the status of the OLDS to archive needed (ARNEEDED):
CHANGE.PRILOG OLDS(DFSOLPXX) ARNEEDED SSID(XXXX)
Getting Change Accumulation Working When It States Nothing to

Process
Change accumulation has issued a message stating that it found no logs to process.
A review of the listing reveals that there are many logs that need to be processed.
DBRC selects all logs needed to satisfy the allocations for each DBDS since the
effective image copy time. The logs are put in log volume start time order as a way
for DBRC to keep track of which logs it has processed. DBRC processes all
available logs and truncates the list of log volumes when it encounters a log in
error, an open log, or when it detects an unarchived OLDS. A message indicating
the condition that was encountered (such as an open log) is issued.
If the last change accumulation execution record shows that a SUBSET of logs was
input to it last, the STOPTIME reflects the start time of the first unavailable log
volume. Find this log volume time stamp in the listing of the RECON data set. If
no log volume exists with this start time, there is an unarchived OLDS.
The following time line illustrates this open OLDS condition:

Hints and Tips
T1--T2---T3--T4-T5--------T6--------T7---------T8----T9---
|---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 and

is a SUBSET. T4 is the start time of the first unavailable log. After this JCL is
executed, any attempts to run GENJCL.CA result in issuing two messages; one
stating that an unarchived OLDS exists and another stating that there are no logs
to process until the open OLDS is closed and archived.
Moving Log Data Sets

DBRC records information about IMS logs in the RECON data set. This
information includes the log data set name (DSN), its starting and ending times,
and the volume serial (VOLSER).
The best way to avoid lost logs is to use cataloged log data sets and the DBRC
CATDS option.
For non-cataloged log data sets, inform DBRC about changes by using the
CHANGE.PRILOG or CHANGE.SECLOG command.
Related Reading: See the CHANGE.PRILOG commands starting with

“CHANGE.PRILOG (for OLDS)” on page 169 and the CHANGE.SECLOG commands
starting with “CHANGE.SECLOG (for OLDS)” on page 189.
Cataloging Data Sets

You can indicate whether image copy, change accumulation, and log data sets are
cataloged by using the CATDS or NOCATDS keywords on the CHANGE.RECON or
INIT.RECON command.
| The CHANGE.RECON and INIT.RECON commands update the RECON header record
| accordingly if you specify either CATDS or NOCATDS. The only difference
| between the two commands in respect to cataloging is that INIT.RECON can be
| issued only once for each set of RECON data sets (3) required for an IMS region.
To specify that these data sets are cataloged specify:

//CHGRECON JOB
.
.
.
//SYSIN DD *
CHANGE.RECON CATDS
/*
-OR-
//INITRCON JOB
.
.
.
//SYSIN DD *
INIT.RECON CATDS
/*

Hints and Tips
The data set must have been initialized as cataloged for CATDS to be effective
with the CHANGE.RECON command.
Specifying NOCATDS on the CHANGE.RECON or INIT.RECON command establishes

that these data sets, regardless of their cataloged status, are not to be treated as
cataloged.
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 284 and “CHANGE.RECON” on

page 179 for more information.
Performing Multiple Cold Starts in a Test Environment

Many times in a test environment, you may want to cold start IMS. In order to
cold start 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 in the RECON data set so it may be reused:
| NOTIFY.PRILOG STARTIME(042052037526) RUNTIME(042052137526) -
| LASTREC(2218) OLDS(DFSOLP02) SSID(IMS1)
| CHANGE.PRILOG OLDS(DFSOLP02) ARCHIVED SSID(IMS1)
| The entries for each OLDS (such as: DFSOLP00, DSPOLP01, and DSPOLD02) in the
PRIOLD record are built when the OLDSs are used (if they do not already exist in
the RECON data set). If you also need to delete the OLDS from the RECON data
set, the following commands can be used:
DELETE.LOG OLDS(DFSOLP00) SSID(IMSA)
DELETE.LOG OLDS(DFSOLP01) SSID(IMSA)
DELETE.LOG OLDS(DFSOLP02) SSID(IMSA) LASTCLOS
Note that the LASTCLOS is necessary to delete the last OLDS used by IMS. The
PRIOLD record is also deleted when the last DDNAME entry is removed.
The PRIOLD record before issuing the commands:

| PRIOLD
| SSID=IMS1 # DD ENTRIES=3
|
| DDNAME=DFSOLP00 DSN=IMSTESTL.IMS01.OLDSP0
| STOP = 04.205 20:37:29.1 LAST DS LSN= 0000000000000642
| LOCK SEQUENCE# = 000000000000
| STATUS=ARC COMPLT FEOV=YES AVAIL
| PRILOG TIME=04.205 20:36:58.7 ARCHIVE JOB NAME=JT203738
| VERSION=9.1

Hints and Tips
|
| STOP = 04.205 20:37:52.6 LAST DS LSN= 00000000000007A9
| LOCK SEQUENCE# = 000000000000
| STATUS=ARC COMPLT FEOV=YES AVAIL
| PRILOG TIME=04.205 20:36:58.7 ARCHIVE JOB NAME=JT203752
| VERSION=9.1
|
| START = 04.205 20:37:52.6 FIRST DS LSN= 00000000000007AA
| STOP = 00.000 00:00:00.0 LAST DS LSN= 0000000000000000
| LOCK SEQUENCE# = 000000000000
| STATUS=ACTIVE FEOV=NO AVAIL
| PRILOG TIME=04.205 20:36:58.7
| VERSION=9.1
| The PRIOLD record after issuing the commands to close and mark DFSOLP02 as
archived (with the differences highlighted):
PRIOLD
SSID=IMS1 # DD ENTRIES=3
DDNAME=DFSOLP00 DSN=IMSTESTL.IMS01.OLDSP0
STOP = 04.205 20:37:29.1 LAST DS LSN= 0000000000000642
LOCK SEQUENCE# = 000000000000
STATUS=ARC COMPLT FEOV=YES AVAIL
PRILOG TIME=04.205 20:36:58.7 ARCHIVE JOB NAME=JT203738
VERSION=9.1
STOP = 04.205 20:37:52.6 LAST DS LSN= 00000000000007A9
VERSION=9.1
START = 04.205 20:37:52.6 FIRST DS LSN= 00000000000007AA
STOP = 04.205 21:37:52.6 LAST DS LSN= 00000000000008AA
STATUS=ARC COMPLT FEOV=NO AVAIL
PRILOG TIME=04.205 20:36:58.7
VERSION=9.1
Avoiding Some Causes of RECON Data Set Enqueue Problems

The following sections describe some situations that can cause RECON data set
enqueue problems and contain suggestions for avoiding these problems.
Related Reading: See “RECON Data Set Serialization” on page 57 for more
information.
In a Shared DASD Environment

Operating in a shared DASD environment, the most common cause of RECON
data set enqueue problems is failing to follow the recommendation to catalog each
RECON data set in its own ICF catalog on the same volume as the RECON data
set.

Hints and Tips
If you catalog each RECON data set in its own ICF catalog on the same volume as
the RECON and still have problems; examine your GRS, (or equivalent) RESERVE
conversion list, to determine how you process SYSIGGV2 and DSPURI01
QNAMEs. A couple of combinations might lead to deadlocks.
In a Non-Shared DASD Environment

If 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 slow
performance. Here are a few things to look at in this situation:
1. Minimize the amount of time any job holds the RECON data set.
One way to minimize that time is to tune the LSR buffer pool DBRC uses when
accessing the RECON data sets. There is a CSECT, DSPBUFFS, that contains the
values used for online, batch, and a procedure in the IMS Version 9:
Customization Guide on how to zap it to change the values. The defaults might
be low for your usage.
2. Analyze the other contents of the volumes where the RECON data set resides.
Consider isolating these volumes, to prevent interference from other I/O
activity (and vice versa). Consider placing the RECON s on high performance
cached DASD, or perhaps solid state DASD.

Part 2. DBRC Command Reference
Chapter 7. DBRC Commands . . . . . . . 121 DELETE.SG . . . . . . . . . . . . . 217
DBRC Batch Commands. . . . . . . . . . 121 DELETE.SUBSYS . . . . . . . . . . . 218
| DBRC Online Commands . . . . . . . . . 122 DELETE.UIC . . . . . . . . . . . . 218
DBRC Command Syntax . . . . . . . . . 122
Separators . . . . . . . . . . . . . 123 Chapter 11. GENJCL Commands . . . . . . 221
Continuation Characters . . . . . . . . . 123 GENJCL Commands In This Chapter . . . . . 221
Comments . . . . . . . . . . . . . 123 GENJCL.ARCHIVE . . . . . . . . . . 221
Commands . . . . . . . . . . . . . 123 GENJCL.CA . . . . . . . . . . . . . 225
Parameters . . . . . . . . . . . . . 123 GENJCL.CLOSE . . . . . . . . . . . 229
How to Read Syntax Diagrams . . . . . . 124 GENJCL.IC . . . . . . . . . . . . . 233
DBRC Time Stamps . . . . . . . . . . 126 GENJCL.OIC . . . . . . . . . . . . 242
GENJCL.RECEIVE. . . . . . . . . . . 247
Chapter 8. BACKUP Command . . . . . . . 133 GENJCL.RECOV . . . . . . . . . . . 251
BACKUP.RECON . . . . . . . . . . . . 133 GENJCL.USER . . . . . . . . . . . . 257
BACKUP.RECON Usage. . . . . . . . . 133
Chapter 12. INIT Commands. . . . . . . . 263
Chapter 9. CHANGE Commands . . . . . . 135 INIT Commands In This Chapter. . . . . . . 263
CHANGE Commands In This Chapter . . . . . 135 INIT.ADS. . . . . . . . . . . . . . 263
CHANGE.ADS . . . . . . . . . . . . 135 INIT.CA . . . . . . . . . . . . . . 265
CHANGE.BKOUT . . . . . . . . . . . 136 INIT.CAGRP . . . . . . . . . . . . 266
CHANGE.CA . . . . . . . . . . . . 138 INIT.DB . . . . . . . . . . . . . . 268
CHANGE.CAGRP . . . . . . . . . . . 140 INIT.DBDS . . . . . . . . . . . . . 271
CHANGE.DB . . . . . . . . . . . . 143 INIT.DBDSGRP. . . . . . . . . . . . 276
CHANGE.DBDS . . . . . . . . . . . 152 INIT.GSG. . . . . . . . . . . . . . 277
CHANGE.DBDSGRP . . . . . . . . . . 159 INIT.IC . . . . . . . . . . . . . . 278
CHANGE.IC . . . . . . . . . . . . 162 INIT.PART . . . . . . . . . . . . . 280
CHANGE.PART . . . . . . . . . . . 164 INIT.RECON . . . . . . . . . . . . 284
CHANGE.PRILOG (for OLDS) . . . . . . 169 INIT.SG . . . . . . . . . . . . . . 289
CHANGE.PRILOG (for RLDS). . . . . . . 171
CHANGE.PRILOG (for SLDS and TSLDS) . . . 175 Chapter 13. LIST Commands . . . . . . . 291
CHANGE.RECON. . . . . . . . . . . 179 LIST Commands In This Chapter . . . . . . . 291
CHANGE.SECLOG (for OLDS) . . . . . . 189 LIST.BKOUT . . . . . . . . . . . . 291
CHANGE.SECLOG (for RLDS) . . . . . . 191 LIST.CAGRP . . . . . . . . . . . . 292
CHANGE.SECLOG (for SLDS and TSLDS) . . 195 LIST.DB . . . . . . . . . . . . . . 293
CHANGE.SG . . . . . . . . . . . . 200 LIST.DBDS . . . . . . . . . . . . . 294
CHANGE.SUBSYS. . . . . . . . . . . 201 LIST.DBDSGRP . . . . . . . . . . . . 296
CHANGE.UIC . . . . . . . . . . . . 202 LIST.GSG . . . . . . . . . . . . . . 297
LIST.HISTORY . . . . . . . . . . . . 298
Chapter 10. DELETE Commands . . . . . . 205 LIST.LOG (for a PRILOG Family). . . . . . 300
DELETE Commands In This Chapter . . . . . 205 LIST.LOG (for a Category of Records) . . . . 301
DELETE.ADS . . . . . . . . . . . . 205 LIST.RECON . . . . . . . . . . . . 304
DELETE.ALLOC . . . . . . . . . . . 206 LIST.SUBSYS . . . . . . . . . . . . 306
DELETE.BKOUT . . . . . . . . . . . 207
DELETE.CA . . . . . . . . . . . . . 207 Chapter 14. NOTIFY Commands . . . . . . 309
DELETE.CAGRP . . . . . . . . . . . 208 NOTIFY Commands In This Chapter . . . . . 309
DELETE.DB . . . . . . . . . . . . . 208 NOTIFY.ALLOC . . . . . . . . . . . 309
DELETE.DBDS . . . . . . . . . . . . 209 NOTIFY.BKOUT . . . . . . . . . . . 311
DELETE.DBDSGRP . . . . . . . . . . 210 NOTIFY.CA . . . . . . . . . . . . . 312
DELETE.GSG . . . . . . . . . . . . 210 NOTIFY.IC . . . . . . . . . . . . . 314
DELETE.IC . . . . . . . . . . . . . 211 NOTIFY.PRILOG (for OLDS) . . . . . . . 317
DELETE.LOG (for OLDS) . . . . . . . . 212 NOTIFY.PRILOG (for RLDS) . . . . . . . 321
DELETE.LOG (for RLDS and SLDS) . . . . . 212 NOTIFY.PRILOG (for SLDS and TSLDS) . . . 326
DELETE.PART . . . . . . . . . . . . 215 NOTIFY.RECOV . . . . . . . . . . . 329
DELETE.RECOV . . . . . . . . . . . 216 NOTIFY.REORG . . . . . . . . . . . 332
DELETE.REORG . . . . . . . . . . . 217 NOTIFY.SECLOG (for OLDS) . . . . . . . 335

NOTIFY.SECLOG (for RLDS) . . . . . . . 338
NOTIFY.SECLOG (for SLDS and TSLDS) . . . 342
NOTIFY.SUBSYS . . . . . . . . . . . 345
NOTIFY.UIC . . . . . . . . . . . . 346
Chapter 15. RESET Command . . . . . . . 349

RESET.GSG . . . . . . . . . . . . . . 349
RESET.GSG Usage. . . . . . . . . . . 349

Chapter 7. DBRC Commands
This chapter contains a description of the DBRC commands. Use these commands
to add to, change, and delete information in the RECON and to generate the JCL
and the control statements you need to run the various IMS utilities used in
database recovery.
In This Chapter:
v “DBRC Batch Commands”
v “DBRC Online Commands” on page 122
v “DBRC Command Syntax” on page 122
DBRC Batch Commands

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 make the following changes to a RECON:
– Create entries
– Create CA groups
– Register DBDSs or DEDB areas
– Define global service groups
– Register HALDB partitions
– Initialize a RECON
v Use the LIST commands to produce a formatted printout of all or selected parts
of the RECON.
v Use the NOTIFY commands to add to the RECON information that is normally
written there automatically.
v Use the RESET.GSG command after an unplanned RSR takeover to remove
obsolete recovery information about RSR-covered databases and areas from the
original active site RECONs.
| You can also issue a variation of some of these commands online using the
| /RMxxxxxx command (see “DBRC Online Commands” on page 122).
CICS users can execute DBRC commands using the CICS-supplied transaction
CDBM, that provides a command interface to DBCTL.
Related Reading:
v See the command chapters for valid parameters and usage notes for each
command. See IMS Version 9: Command Reference for details pertaining to the
syntax of the online commands (/RMxxxxxx).
v See CICS Transaction System for z/OS CICS Supplied Transaction, SC34-5992 for a
description of CDBM, and CICS Transaction System for z/OS V2R2 IMS Database
Control Guide, SC34-6010, for details of the DBCTL and DBRC commands you
can use with the CDBM transaction.

DBRC Commands
v See “How to Read Syntax Diagrams” on page 124 for information about the
syntax diagrams and notations used in this book.
v See “Data Set Naming Conventions” on page 33 for information on naming
conventions.
| DBRC Online Commands

| Certain DBRC commands can be issued from an online IMS environment
| (/RMxxxxxx commands). The online DBRC commands are:
| v /RMCHANGE
| v /RMDELETE
| v /RMGENJCL
| v /RMINIT
| v /RMLIST
| v /RMNOTIFY
| Related Reading: See IMS Version 9: Command Reference for details on DBRC
| commands that can be entered online and the supported DBRC parameters
| (modifiers) that are associated with those commands.
| After these commands successfully pass through IMS security, IMS passes these
| commands to DBRC where they are processed. These commands are processed in a
| similar manner as the regular DBRC commands of similar name. For example,
| DBRC processes a /RMCHANGE command in a similar manner as a CHANGE command.
| The authorization of these online commands can also be controlled in a similar
| manner as the batch DBRC commands, namely you can use the DBRC Command
| Authorization exit (DSPDCAX0), a security authorization program like RACF, or
| both.
| Related Reading:
| v For more information about DBRC command authorization support, see
| “Preserving the Integrity of the RECON Data Set with DBRC Command
| Authorization Support” on page 78.
| v For the details of using the DBRC Command Authorization Exit (DSPDCAX0),
| see the IMS Version 9: Customization Guide.
DBRC 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 Method
Services.
You can enter commands in uppercase, lowercase, or mixed case format. DBRC
translates most command input into uppercase format before processing, regardless
of the format that is used. However, DBRC does not translate keyword values and
string values into uppercase format. For example, the ’value’ portion of the
USERKEYS parameter on GENJCL commands, and the UDATA parameter on the
NOTIFY.UIC and CHANGE.UIC commands are processed in the exact format in
which they are entered.
The following sections discuss additional aspects of the syntax of DBRC

commands.
v “Separators” on page 123
v “Continuation Characters” on page 123

Command Syntax
v “Comments”
v “Commands”
v “Parameters”
v “How to Read Syntax Diagrams” on page 124
v “DBRC Time Stamps” on page 126
Separators
A blank, a comma, or a comment can be interchanged in a command wherever a
separator is needed. More than one separator can be used between parameters.
Continuation Characters
Continuation characters are used to continue commands and comments that do not
fit on a single line of input.
The two continuation characters used by DBRC are the minus sign (−) and the plus
sign (+):
+ Deletes the leading separators from the continued line.
− Does not delete the leading separators from the continued line.
Restriction: A character string enclosed in single quotation marks (for example,

('c...c') can be continued only with a minus continuation character because
separators are meaningful in a character string between single quotation marks.
DBRC assumes such a character string to be ended if the end of a line is reached
before the ending quotation mark is encountered and the last non-blank character
in the line is not a minus continuation character. The maximum length of a
character string is 256 characters.
Comments
Comments 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 the
character string (*/) is encountered and if the last character in the line is not a
continuation character.
Commands
A 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 verb
and the modifier.
Commands can be entered anywhere in columns 1 through 72 of the DBRC SYSIN

input stream. Commands can be continued on multiple lines by entering a
continuation character as the last non-blank character of the command line.
Columns 73 through 80 of the SYSIN input stream are ignored.
Parameters
Most DBRC commands have both required and optional parameters.
In general, there are no positional keyword parameters in DBRC commands. The

keyword parameters are of the following types:
Chapter 7. DBRC Commands 123

Command Syntax
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..)..)
When you enter a repeating list of values only once for this type of keyword,
you can omit the outer set of parentheses like this:
keyword(v1,v2)
| Some commands have mutually exclusive parameters. In the parameter

| descriptions, a vertical bar (|) separates the mutually exclusive parameters. If you
| specify more that one of these parameters on the same command, you will not get
| an error, but DBRC will use the last one specified and ignore the others.
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 the
characters 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 in
apostrophes.
v Data set names, data set ddnames, and volume serial numbers can include
hyphens.
v Data set names follow the conventions specified in the z/OS JCL manuals.
Except where otherwise noted, optional keywords with values have the following
defaults.
Numeric values 0
Character values blank
If a particular parameter is encountered more than once within a command, the

last occurrence of the parameter is used. If mutually exclusive parameters are
encountered within a command, the last occurrence is used.
How to Read Syntax Diagrams

The following rules apply to the syntax diagrams that are used in this information:
v Read the syntax diagrams from left to right, from top to bottom, following the
path of the line. The following conventions are used:
– The >>--- symbol indicates the beginning of a syntax diagram.
– The ---> symbol indicates that the syntax diagram is continued on the next
line.
– The >--- symbol indicates that a syntax diagram is continued from the
previous line.
– The --->< symbol indicates the end of a syntax diagram.
v Required items appear on the horizontal line (the main path).
required_item

Command Syntax
v Optional items appear below the main path.
required_item
optional_item
If an optional item appears above the main path, that item has no effect on the
execution of the syntax element and is used only for readability.
optional_item
required_item
v If 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 the main
path.
required_item required_choice1
required_choice2
If choosing one of the items is optional, the entire stack appears below the main
path.
required_item
optional_choice1
optional_choice2
If one of the items is the default, it appears above the main path, and the
remaining choices are shown below.
default_choice
required_item
optional_choice
optional_choice
v An arrow returning to the left, above the main line, indicates an item that can be
repeated.
required_item repeatable_item
If the repeat arrow contains a comma, you must separate repeated items with a
comma.
required_item repeatable_item
A repeat arrow above a stack indicates that you can repeat the items in the
stack.
v Sometimes a diagram must be split into fragments. The syntax fragment is
shown separately from the main syntax diagram, but the contents of the
fragment should be read as if they are on the main path of the diagram.

Command Syntax
required_item fragment-name
fragment-name:
required_item
optional_item
v In IMS, a b symbol indicates one blank position.

v Keywords, and their minimum abbreviations if applicable, appear in uppercase.
They must be spelled exactly as shown. Variables appear in all lowercase italic
letters (for example, column-name). They represent user-supplied names or
values.
v Separate keywords and parameters by at least one space if no intervening
punctuation is shown in the diagram.
v Enter punctuation marks, parentheses, arithmetic operators, and other symbols,
exactly as shown in the diagram.
v Footnotes are shown by a number in parentheses, for example (1).
DBRC Time Stamps

Time stamps are points in time recorded in the RECON. Correctly interpreting time
stamp formats found in RECON listings, messages, and dumps will help you enter
the appropriate time stamp in commands.
Standard Time Stamp Format

Certain parameters require a time stamp, which may be entered in one of the
following 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)
t Is the tenth of a second (0 to 9)
| Can be any non-numeric character delimiter including
blank except the single quotation mark. If the time stamp
contains any blanks, commas, or parentheses, it must be
enclosed in single quotation marks. For example,
LIST.LOG STARTIME('94.252 08:24:45.7 -8')
or
LIST.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” on page 179
for more information on the TIMEZIN parameter.

Command Syntax
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 a
numeric value from 0 to 14. For the compressed format
if mm is specified, then hh must also be specified. mm
is 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
the omitted element’s digits are assumed to be zeros.
You can truncate the input at the beginning of any element after ddd; so, yyyy|ddd
is acceptable, as is yyyy|ddd|hh. Part of an element cannot be entered: for example,
yyyy|ddd|h is invalid.
If only two digits are entered for the year, the two high order digits are
extrapolated by using the sliding-window method described in “Extrapolation of
Two-digit Year Input” on page 130.
The same time stamp value could be entered in the following ways:
942520824457
942520824457-0800
94.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: Use the optional TIMEFMT parameter to define the form
in which time stamps appear in messages, displays, and listings from DBRC. Each
parameter associated with TIMEFMT is optional and can be omitted by including
only the comma.
The TIMEFMT parameter can be used on CHANGE.RECON, LIST.xxxx, and

GENJCL.xxxx commands or can be specified in a skeletal JCL member.
Restriction: The parameters that are associated with TIMEFMT are positional.
The format of the TIMEFMT parameter sublist is as follows:
TIMEFMT( )
offset ,
offset_display , A
A:

Command Syntax
form ,
year_size ,
(1)
duration
(2)
precision
Notes:
1 duration can only be set on the CHANGE.RECON command.
2 precision is only valid on the %SET statement.
If items of the sublist are omitted, the current values from the RECON header are
used.
offset
Specifies 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 event
occurred.
L Current local offset-that is, display the current-local-time equivalent.
offset_display
Specifies 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 has
been defined for it. If no label is defined, the offset is displayed in numeric
format.
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.
form
Specifies whether the time stamp is to be displayed in punctuated or
compressed 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_size
Specifies whether all four digits of the year are to be displayed or only the two
low-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.
duration
Specifies the scope of these choices to be either limited to the current job or
used as global overrides to the system defaults. The duration subparameter
can only be specified on a CHANGE.RECON command.
PERM
Indicates that the specified options are to be in effect for any subsequent
DBRC utility job running with the same RECON; that is, these values
become the defaults for subsequent jobs.

Command Syntax
TEMP
Indicates that the specified options are in effect only for the job in which
the command is entered. If neither PERM nor TEMP is coded, TEMP is
the default.
precision
Coded only on a %SET statement in skeletal JCL as a number from 1 to 6. You
can use it to control the number of low-order digits contained in time stamps
that 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. Full
time-stamp precision is not required nor accepted for IMS utility JCL; it is only
intended for GENJCL output generated for user-specified purposes (normally
GENJCL.USER).
(As with other parameters, coding a null value causes the corresponding
TIMEFMT value to be reset to the GENJCL default. TIMEFMT() resets all values.)
TIMEFMT in Skeletal JCL: Besides its use on the CHANGE.RECON command, the
TIMEFMT parameter can be coded on any LIST.xxx or GENJCL.xxx DBRC
command. It can also be specified in a skeletal JCL member as:
%SET TIMEFMT(....)
Here is an example of the %SET keyword in skeletal JCL:

%SET TIMEFMT(,N)
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 93 for more
examples of %SET output specifications.
TIMEFMT Subparameter Order of Precedence: The order of precedence of the

TIMEFMT subparameters, from lowest to highest, is as follows:
1. RECON defaults
The RECON defaults are established by the INIT.RECON command. These
defaults 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
SYSIN command stream using either PERM or TEMP options of the
CHANGE.RECON command.
3. %SET statements in skeletal JCL members
The TIMEFMT settings in a %SET statement override the GENJCL default
settings, as well as settings from a previous %SET statement in the same
member.
4. Command override
The TIMEFMT settings in a DBRC command override all of the above settings
within the scope of that command invocation. For example, a GENJCL.xxx
command TIMEFMT setting overrides the TIMEFMT settings on any %SET
statement in the applicable skeletal JCL member.
When coded on any command other than CHANGE.RECON, the last parameter,
duration, has no meaning; any TIMEFMT values coded override the values that are

Command Syntax
currently in effect only for the duration of the command. For any omitted values,
the values currently in effect from the most recent CHANGE.RECON command with a
PERM duration, which override the INIT.RECON defaults, remain in effect.
Default Settings: The values set in the RECON by the INIT.RECON command are
TIMEFMT(O,N,P,2,TEMP).
The defaults used by GENJCL commands are TIMEFMT(O,O,C,2,TEMP,1).
Recommendation: If your installation operates multiple IMS systems with

different time 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 Values

A zero time stamp is valid only where explicitly allowed for a command keyword
value. A zero time stamp value, where permitted, can be entered in either
punctuated or compressed format, or can be condensed into a single digit. For
example, 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 Input

Input time stamps on DBRC commands are accepted with the two-digit year
notation. In this case the century digits are derived for the use of the internal time
stamp. The century digits in the internal time stamp are determined from the two
entered digits by the following process:
The entered year digits are compared to a sliding window of 100 years. The
lower limit of the window is the current year minus 70. The upper limit is the
current year plus 29. A “breakpoint” is defined as the two low-order digits of
the lower limit.
If the entered digits are equal to, or greater than, the breakpoint; the century
digits of the lower limit are used. Otherwise, the century digits of the upper
limit are used. The upper and lower limits of the window and the breakpoint
are established when IMS is initialized. When the year changes, these values are
recomputed.
Time Stamp Conversions and Examples

In the examples that follow, local time is PST (offset -08:00).
An event occurring at 1998.030 10:00:0.1 -08:00 (punctuated format - yyyy ddd hh

mm ss) or 98030100001 -0800 (compressed format - yydddhhmmsst) is recorded in
12 bytes in the RECON as 1998030F|18000012|3456032d| (yyyyddd hhmmsstx
xxxxfqqs), where:
hh UTC, 8 hours later than local time
x xxxx Low-order digits ignored by DBRC (except for GENJCL.USER output with
precision)
fqqs Offset:
f Flag bits, normally 0
qq Quarter hours (32/4=8)
s Sign (D is negative, C is positive)

Command Syntax
Note: The offset is always added to UTC to obtain local time. To obtain UTC from
local time, reverse the sign and add. The time stamp from a record in the RECON
data set, that is PRILOG, lists as:
'1998.030 10:0:00.1 -08:00'
When the time stamp above is entered in a command with the quotes, DBRC finds
the record in the RECON data set with the recorded time as:
1998030F 18000012 3456032D
DBRC ignores the low-order time digits and the offset when searching. The UTC
date and time is determined.
If no offset is supplied in the time stamp, DBRC uses the TIMEZIN value which
might not be correct if a clock change has occurred since the time when the record
was written in RECON.
Time stamps from different RECON listings, even with time stamps displayed in
different formats, can be used freely, so long as the offsets are included.
Standard Default Settings for Time-Stamp Values

The RECON data set time-stamp formats are the standard default.
From the RECON header:

TIMEZIN=%SYS
OUTPUT FORMAT: DEFAULT = LOCORG NONE PUNC YY

No user-defined labels are defined.
Listing an allocation record without offset values lists the time stamp as:
99.027 19:03:47.0
The allocation record was written prior to daylight savings change. The time stamp
is entered on a command to list the record without an offset. With TIMEZIN=%SYS
set in RECON, the offset is obtained from current z/OS clock which has changed.
The record is not found in RECON.
DBRC Commands Affected by the Time-Stamp Format

These DBRC commands have time stamps as part of their syntax.
v CHANGE.BKOUT
v CHANGE.CA
v CHANGE.IC
v CHANGE.PRILOG
v CHANGE.SECLOG
v CHANGE.UIC
v DELETE.ALLOC
v DELETE.CA
v DELETE.IC
v DELETE.LOG
v DELETE.RECOV
v DELETE.REORG
v DELETE.UIC
v GENJCL.CA
v GENJCL.RECOV
v GENJCL.USER
v LIST.HISTORY

Command Syntax
v LIST.LOG
v NOTIFY.ALLOC
v NOTIFY.BKOUT
v NOTIFY.CA
v NOTIFY.IC
v NOTIFY.PRILOG
v NOTIFY.RECOV
v NOTIFY.REORG
v NOTIFY.SECLOG
v NOTIFY.UIC
Related Reading: See “Standard Time Stamp Format” on page 126 for more
information on the standard time-stamp format.

Chapter 8. BACKUP Command
Use the BACKUP.RECON command to create backup copies of the RECON from the
Copy1 RECON.
In This Chapter:
v “BACKUP.RECON”
BACKUP.RECON
“BACKUP.RECON Usage” contains the details for the BACKUP.RECON command.
BACKUP.RECON Usage
The BACKUP.RECON command first opens the RECON and any needed cleanup is
done. The command then invokes the IDCAMS REPRO command, using its normal
defaults, to create the backup copy. Any restrictions applicable to the normal use of
the REPRO command apply to this command. The data set receiving the backup
copy must be empty.
If your RECON RECORDSIZE is greater than 32 KB, the BACKUP.RECON

command will fail if the back up is to a sequential data set. Perform the following
steps to back up a RECON to a sequential file (for example, to a tape):
1. Create a backup KSDS using the BACKUP.RECON command
2. Use DFSMSdss to copy the backed-up KSDS to the sequential file
BACKUP.RECON Syntax
RECON1
BACKUP.RECON
RECON2
BOTH
Parameters for BACKUP.RECON

RECON1 | RECON2 | BOTH
A required parameter that specifies the backup data set to which the RECON
is copied.
RECON1
Copies RECON to the backup data set specified by the BACKUP1 DD
statement of your JCL.
RECON2
Copies RECON to the backup data set specified by the BACKUP2 DD
statement of your JCL.
BOTH
Copies RECON to the data sets specified by the BACKUP1 and BACKUP2
DD statements of your JCL.
Example of Creating Backups of a RECON

In this example, two backup copies of the Copy1 RECON are created.

BACKUP.RECON
//BKUP JOB
//BACKUP1 DD . . .
//BACKUP2 DD . . .
.
.
.
//SYSIN DD *
BACKUP.RECON BOTH
/*
To create a sequential backup, the BACKUPx DD statement must include

appropriate DCB parameters. The BLKSIZE specified must be larger than the
maximum RECORDSIZE defined in the RECON, but less than 32K. For example,
DCB=(RECFM=VB,LRECL=32756,BLKSIZE=32760).

Chapter 9. CHANGE Commands
Use the CHANGE commands to modify information in a RECON.
CHANGE Commands In This Chapter

The following is a list of all the CHANGE commands:
v “CHANGE.ADS”
v “CHANGE.BKOUT” on page 136
v “CHANGE.CA” on page 138
v “CHANGE.CAGRP” on page 140
v “CHANGE.DB” on page 143
v “CHANGE.DBDS” on page 152
v “CHANGE.DBDSGRP” on page 159
v “CHANGE.IC” on page 162
v “CHANGE.PART” on page 164
v “CHANGE.PRILOG (for OLDS)” on page 169
v “CHANGE.PRILOG (for RLDS)” on page 171
v “CHANGE.PRILOG (for SLDS and TSLDS)” on page 175
v “CHANGE.RECON” on page 179
v “CHANGE.SECLOG (for OLDS)” on page 189
v “CHANGE.SECLOG (for RLDS)” on page 191
v “CHANGE.SECLOG (for SLDS and TSLDS)” on page 195
v “CHANGE.SG” on page 200
v “CHANGE.SUBSYS” on page 201
v “CHANGE.UIC” on page 202
CHANGE.ADS
Use the CHANGE.ADS command to change DEDB ADS information in RECON. The
CHANGE.ADS command fails if you issue it while the area is in use. To create an ADS
entry, refer to “INIT.ADS” on page 263.
CHANGE.ADS Syntax
CHANGE.ADS ADDN(name) AREA(name) DBD(name)
ADDNNEW(name)
UNAVAIL

ADSN ( name ) AVAIL
Parameters for CHANGE.ADS

ADDN(name)
Required parameter you use to specify the area data set ddname of the ADS
being changed.

CHANGE.ADS
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 database
name
ADDNNEW(name)
Optional parameter you use to identify the ADS being changed, by new
ddname.
ADSN(name)
Optional parameter you use to identify the ADS being changed, by new data
set name.
AVAIL | UNAVAIL
Mutually exclusive, optional parameters you use to change the ADS record to
indicate its availability.
AVAIL
Indicates that the ADS is available. The CHANGE.ADS AVAIL command fails if
the area needs to be recovered.
UNAVAIL
Indicates that the ADS is unavailable.
If neither AVAIL nor UNAVAIL is specified but ADSN is specified, the value
defaults to UNAVAIL.
Example of Changing an ADS Record

In 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
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 backout

failure has occurred and certain known backout records are invalid. Using the
CHANGE.BKOUT command incorrectly can result in a loss of recovery integrity.
CHANGE.BKOUT Syntax
CHANGE.BKOUT SSID(name) UOR(uor) UORTIME(time_stamp)

DELETE( UOR ) PSB(name) ,
ALL
, DBD( name )
name

CHANGE.BKOUT

,
BKO( name )
Parameters for CHANGE.BKOUT

SSID(name)
Required parameter that specifies the subsystem for which the backout record
is to be changed. The name is an alphanumeric string, with up to eight
characters, that represents any valid subsystem name.
UOR(uor)
Required parameter that you use in conjunction with the UORTIME parameter
to identify a unit of recovery in the backout record. The recovery token (uor) is
16-byte field that describes a specific UOR in the backout record. The value for
this parameter must be expressed as 32 hexadecimal digits.
This parameter can specify a unit of recovery that currently exists in the
backout 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. The
value is the beginning time of the UOR (found in the X'5607' log record). The
time stamp must be in standard form.
DELETE(UOR | ALL | name...)
Optional parameter used to delete some or all of the information related to the
unit of recovery that is specified by the required parameters described above.
UOR
Deletes the entire UOR defined by the required UOR and UORTIME
parameters described above. If you do not specify DELETE(UOR),
CHANGE.BKOUT assumes you are changing an existing UOR or adding a UOR
that 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.
ALL
Specifies that the database entries for the specified UOR and UORTIME are
deleted, but that the UOR prefix information is left intact, if you also
specify database names in the DBD parameter, the BKO parameter, or both.
If you do not specify database names in DBD or BKO, CHANGE.BKOUT acts 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 record
without disturbing the control data in the UOR’s prefix. You can also use
the ALL option to delete all database entries in the UOR except those that
are listed in the DBD or BKO parameters.
name
Specifies up to eight database names for use with the DELETE parameter.
Use a comma to separate each specified name. If you list all of the
databases associated with the specified unit of recovery, CHANGE.BKOUT acts
as if DELETE(ALL) is specified.
If any listed database name is not in the specified UOR, the command fails.
HALDB Restriction: When using the CHANGE.BKOUT command for HALDBs,
name specifies the name of a HALDB partition.
Chapter 9. CHANGE Commands 137

CHANGE.BKOUT
The following optional parameters can only be used if you do not specify
DELETE(UOR). If the UOR already exists in the backout record, you must provide at
least one of the optional parameters. If the UOR does not exist in the backout
record, it is added. In this case, you must specify the PSB and either the DBD
parameter 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 same
time.
PSB(name)
Optional parameter that identifies the PSB associated with the UOR. To add a
UOR to the backout record, you must specify PSB(name). If the UOR defined
by the required parameters already exists in the backout record, the specified
PSB 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. The
database names listed here identify the databases that require backout for this
unit of recovery. This parameter can be used to change the status of an existing
database entry to backout required.
BKO(name...)
Optional parameter that identifies databases to which the UOR applies. Use
BKO to identify databases that have already been backed out from this UOR.
Up to eight database names can be specified with the BKO parameter. This
parameter can be used to change the status of an existing database entry to
backout completed.
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
Use the CHANGE.CA command to change information about a specified run of the
Change Accumulation (CA) utility for an identified CA group in RECON.
CHANGE.CA Syntax
CHANGE.CA GRPNAME(name) RECTIME(time_stamp)
CADSN(name)

CHANGE.CA

FILESEQ(value) INVALID 3400
VALID UNIT( unittype )

, COMP
SUBSET
VOLLIST( volser )
Parameters for CHANGE.CA

GRPNAME(name)
Required parameter you use to specify the name of the CA group for which
information is to be changed.
RECTIME(time_stamp)
Required parameter you use to identify the change accumulation run record
that you are changing.
Use the STOP time marked with an asterisk (*) from the listing of the CA
record. The time stamp must be in standard form (see “Standard Time Stamp
Format” on page 126).
CADSN(name)
Optional parameter you use to specify the new name of the change
accumulation data set in the identified record.
FILESEQ(value)
Optional parameter you use to specify a new file sequence number that is to
be recorded in the identified record.
INVALID | VALID
Mutually exclusive, optional parameters you use to specify whether a change
accumulation data set is to be used as input for a subsequent run of change
accumulation or database recovery.
INVALID
Specifies that the change accumulation data set is not to be used as input
for a subsequent run of change accumulation or database recovery. If an
invalidated change accumulation data set is subsequently reused for
output by change accumulation, it is automatically marked as valid and is
used. See “INIT.CAGRP” on page 266 for an explanation of the REUSE
parameter.
VALID
Specifies that the previously invalidated change accumulation data set is
available for use as input to a subsequent run of change accumulation or
database recovery. Use this parameter only if the change accumulation data
set was previously marked as invalid and is now valid.
Specifying the INVALID parameter causes the STOPTIME and RUNTIME of

the change accumulation record to be swapped. This prevents duplicate
records in the RECON. Specifying the VALID parameter causes the STOPTIME
and RUNTIME to be swapped back.
UNIT(3400 | unittype)
Optional parameter you use to change the unit type of the volumes on which
the change accumulation data set resides. The unit type can be up to eight
alphanumeric characters long.

CHANGE.CA
VOLLIST(volser)
Optional parameter that can be listed, that you use to replace the volume serial
numbers of the change accumulation data set in the specified change
accumulation run record. You can substitute up to 255 volume serial numbers
in the variable field; each can be up to six alphanumeric characters long.
SUBSET | COMP
Mutually exclusive, optional parameters you use to indicate the change
accumulation status.
SUBSET
Indicates that when the CA was created, a subset of logs were processed
and the CA’s stop time is the start time of the first unprocessed log
volume.
COMP
Indicates that when the CA was created, a complete set of logs were
processed and the CA’s stop time is the stop time of the last log volume
that was processed.
You do not need to use this parameter under normal conditions. Checking is
not done to verify that the use of this parameter is consistent with the value of
the CA stop time. This parameter value is used by the GENJCL.CA and
GENJCL.RECOV processes. Incorrect use can result in invalid generated JCL.
Example of Changing a Change Accumulation Run Record

In 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 as
input to a subsequent run of a utility. The VOLLIST, FILESEQ, and CADSN
parameters indicate additional fields in the record that are to be changed.
//CHGCA JOB
.
.
.
//SYSIN DD *
CHANGE.CA GRPNAME(CAGRP2) RECTIME(820650204335) -
INVALID CADSN(IMS.CAGRP2.CA.CADSN2) -
VOLLIST(VOLCA1) FILESEQ(4)
/*
CHANGE.CAGRP
Use a CHANGE.CAGRP command to modify information contained in a specified CA
group record in RECON. You can change the names of DBDSs that are members of
a CA group with this command.
Restriction: HALDB, ILDS, and PHIDAM Primary Index DBDSs are not
recoverable and changes to them are not logged. The CHANGE.CAGRP command does
not support these data sets.
CHANGE.CAGRP Syntax
CHANGE.CAGRP GRPNAME(name)
,
ADD( ( dbname , ddname ) )

,
DELETE( ( dbname , ddname ) )

CHANGE.CAGRP

CAJCL(member) DEFLTJCL(member) GRPMAX(value) NOREUSE
NODEFLT REUSE
Parameters for CHANGE.CAGRP

GRPNAME(name)
Required parameter you use to specify the name of the CA group whose
record you want to modify.
ADD(dbname,ddname) | DELETE(dbname,ddname)
Mutually exclusive, optional parameters you use to specify the member you
want to add to or delete from the specified CA group.
ADD
Specifies members you are adding to the identified CA group. A group
cannot have more than 32767 members.
Restriction: User-recoverable databases cannot be added to a CA group.
DELETE
Specifies members you are deleting from the identified CA group. When
you have deleted a member from a CA group, DBRC has no knowledge of
previous change accumulation activities on that DBDS.
Specify a list of one or more members in the variable field; each member is a
pair of names enclosed in parentheses. dbname is the member’s database name.
For HALDBs, dbname specifies the name of a HALDB partition. ddname is the
symbolic name of the DD statement.
If you delete all the members of a group, the record of that group is deleted
from RECON.
CAJCL(member)
Optional parameter you use to change the name of a member of a partitioned
data set of skeletal JCL. The member is used to generate the JCL for a run of
the Change Accumulation utility when you issue a GENJCL.CA command for the
specified CA group.
DEFLTJCL(member) | NODEFLT
Mutually exclusive, optional parameters you use to specify the implicit skeletal
JCL default member for the CA group.
DEFLTJCL
Specifies an implicit skeletal JCL default member for the CA group.
GENJCL.CA uses the default member you specify in order to resolve
keywords you have defined. For more information, see “GENJCL.CA” on
page 225.
NODEFLT
Specifies that no skeletal JCL default member is to be used for the CA
group.
GRPMAX(value)
Optional parameter you use to modify the number of change accumulation
data sets to be maintained for the specified CA group. The value you
substitute in the variable field must be a decimal number from 2 to 1024.
If you are increasing the GRPMAX value and REUSE is specified, you should
use the INIT.CA command to add additional change accumulation data sets. If

CHANGE.CAGRP
the number of data sets does not equal GRPMAX, reuse does not take place
and you eventually run out of available data sets for the utility.
NOREUSE | REUSE
Mutually exclusive, optional parameters you use to indicate whether change
accumulation data sets should be reused.
NOREUSE
Indicates that change accumulation data sets that were already used for the
specified CA group cannot be reused as output data sets in subsequent
runs of the Change Accumulation utility. Any existing, unused change
accumulation run records for the specified CA group are deleted when you
specify the NOREUSE keyword.
REUSE
Indicates that change accumulation data sets that were already used for the
specified CA group can be reused as output data sets in subsequent runs
of 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.
For additional information about reusing change accumulation data sets, see
the explanation of the REUSE parameter “INIT.CAGRP” on page 266.
Examples of Using the CHANGE.CAGRP Command

Here are several examples of things you can do using the CHANGE.CAGRP command.
Example of Adding DBDSs to the Existing CA Group CAGRP1: In this example,

the DBDSs identified by the dbname and ddname parameters are to be added to
the existing CA group, CAGRP1.
//CHGCAGRP JOB
.
.
.
//SYSIN DD *
CHANGE.CAGRP GRPNAME(CAGRP1) ADD((DB1,DD1),(DB2,DD2))
Example of Deleting DBDSs from the CA Group CAGRP1: In this example, the
DBDSs identified by the dbname and ddname parameters are to 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 Record: In this example, a CA group record

in RECON is being changed. The changes are made to prevent the reuse of CA
data sets by the Change Accumulation utility. It also renames the member of the
partitioned data set of skeletal JCL that is used for generating the JCL that is
needed for the Change Accumulation utility for this CA group.
//CHGCAGRP JOB
.
.
.
//SYSIN DD *
CHANGE.CAGRP GRPNAME(CAGRP3) NOREUSE CAJCL(JCLCA)
/*

CHANGE.DB
CHANGE.DB
Use a CHANGE.DB command to change the information about a database or a Fast
Path DEDB area. This information is contained in a database record or area record
in the RECON. If you specify the parameters SHARELVL, TYPEFP, or TYPEIMS
while the 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 between
the subsystem (SSYS) record and the database or area (DB/AREA) record. This
inconsistency occurs when either the SSYS record still has an entry for the
DB/AREA in its authorized databases/areas list but the DB/AREA record no
longer contains the SSID entry in its associated subsystem information list or the
SSID entry is still in the DB/AREA but the SSYS record either no longer exists in
RECON or no longer contains an entry for the DB/AREA. Use the AUTH
parameter with the syntax shown above.
Restrictions:
v The following restrictions apply when you use the UNAUTH parameter:
– If any parameters other than DBD, AREA, SSID, and ACTIVE | TRACKING
are specified for UNAUTH, the command fails.
– If AREA, ACTIVE, or TRACKING is specified without UNAUTH, the
command fails.
– If the inconsistency between the SSYS and DB/AREA records as described
above does not exist, the command fails.
– If the ACTIVE or TRACKING parameter do not match the SS ROLE field in
the associated subsystem information entry of the specified database or area,
the command fails.
| v When issuing a CHANGE.DB command during a HALDB online reorganization:
| – CHANGE.DB can only be specified for a HALDB partition (TYPE=PART).
| – HALDB online reorganization must have already been attempted for this
| partition (the M-through-V data sets must exist).
| – The ALL parameter can only be used when issuing a CHANGE.DB ALL OLRCAP
| command. All HALDBs that are available to be marked as online
| reorganization capable are marked “OLRCAP.” Those unavailable for change
| (such as HALDBs that are currently authorized) are skipped and are not
| marked as OLRCAP.
| v If you change a VSO DEDB from SHARELVL (2 or 3) to SHARELVL (0 or 1),
| MAS is reset to NOMAS. See “Parameters for CHANGE.DBDS” on page 154 for
| a the description of MAS and NOMAS.
CHANGE.DB Syntax
Use one of the following two diagrams for the CHANGE.DB command.
| ALL
| CHANGE.DB
DBD(name) AUTH NOBACK SSID(name)
NOAUTH BACKOUT(value) SSID(name)
|
| OLRCAP OLRBYTES(value) OLRROOTS(value) OLRSEGS(value)
OLRNOCAP

CHANGE.DB

OLRRGON OLRIMSID(name) OLRDBDS( A ) PINIT
OLRRGOFF NOOWNER M NOPINIT

READON SHARELVL( 0 ) NONRECOV ICREQ TYPEFP
READOFF 1 RECOVABL NOICREQ TYPEIMS
2 USERRCOV
3
|
GSGNAME(gsgname) RCVTRACK PARTSEL(pgmname) (***)
NOTCOVER DBTRACK HIKEY REORGI
NOREORGI
Or:
CHANGE.DB UNAUTH DBD(name) SSID(name)

(1)
AREA(name)
ACTIVE

TRACKING
Notes:
1 Required if using this command for a Fast Path DEDB
Parameters for CHANGE.DB

DBD(name) | ALL
Mutually exclusive, optional parameters you use to identify the database for
which the record is to be changed.
DBD
Specifies that you are changing the record of a single database.
Restrictions for HALDBs: For HALDBs, name specifies the name of a
HALDB partition or the HALDB master (if you want to change all
partitions of the HALDB master). For HALDBs, you can use the CHANGE.DB
command only as defined in Table 9 on page 144.
Table 9. Parameter Definitions for HALDB Partition and Master
CHANGE.DB name = TYPE=HALDB name = TYPE=PART
| AUTH | NOAUTH Yes (Global) Yes
ICREQ|NOICREQ Yes No
NOBACK | BACKOUT No Yes
NORECOV | RECOVABL Yes No
| OLRCAP | OLRNOCAP Yes No
| OLRBYTES Yes Yes
| OLRROOTS Yes Yes
| OLRSEGS Yes Yes
| OLRRGON | OLRRGOFF No Yes

CHANGE.DB
Table 9. Parameter Definitions for HALDB Partition and Master (continued)

CHANGE.DB name = TYPE=HALDB name = TYPE=PART
| OLRIMSID(name) NOOWNER No Yes
| OLRDBDS(A | M) No Yes
| PARTSEL|HIKEY Yes No
| PINIT | NOPINIT Yes Yes
| READON | READOFF No Yes
| REORGI | NOREORGI Yes Yes
SHARELVL Yes No
TYPEFP | TYPEIMS No No
GSGNAME | NOTCOVER Yes No
RCVTRACK | DBTRACK Yes No
UNAUTH No Yes
Restriction: If you specify the UNAUTH parameter, you must specify the
DBD name. The ALL parameter is not valid with UNAUTH.
ALL
Specifies that you are changing all the databases registered in RECON.
If any of the databases are HALDB masters or partitions, and you have
specified any of the restricted parameters (for example, the PINIT or
NOPINIT parameters), a warning message is issued and command
processing continues.
AUTH | NOAUTH
Mutually exclusive, optional parameters you use to specify whether the
database is authorized to participate in data sharing.
AUTH
Indicates that authorization processing for data sharing is permitted for the
database.
NOAUTH
Indicates that authorization processing for data sharing is prohibited for
the database.
GSGNAME(gsgname) | NOTCOVER
Mutually exclusive, optional parameters you use to assign the remote site
recovery attributes of a DL/I database, including HALDBs.
GSGNAME
Assigns the database to a global service group (GSG).
NOTCOVER
Discontinues remote site recovery for the database.
You cannot use CHANGE.DB to change the state of a database from
non-RSR-covered to RSR-covered at a remote site. Message DSP1044I is
issued if you attempt to change the covered state of the database with this
command. In order to change a database not covered at a remote site,
delete and reinitialize the database. Neither Fast Path DEDBs nor
non-recoverable databases can be assigned to a GSG. Neither GSGNAME
nor NOTCOVER can be specified while the database is in use.

CHANGE.DB
ICREQ | NOICREQ
Mutually exclusive, optional parameters used to specify whether DBRC should
enforce the requirement of taking an image copy of a non-recoverable or
user-recoverable database after it has been loaded or reorganized. This option
affects all DBDSs within the DB.
ICREQ
Used to reset the IMAGE COPY NEEDED option. When this option is
active, DBRC will set IC NEEDED ON in the DBDS record and increment
the IMAGE COPY NEEDED COUNT in the DB record following initial
load (PROCOPT=L) or a reorganization of the DBDS.
NOICREQ
Used to disable the IC NEEDED requirement. DBRC will not set IC
NEEDED ON in the DBDS record or increment the IMAGE COPY
NEEDED COUNT in the DB record following initial load or a
reorganization of the DBDS. The IC NEEDED flag can still be set manually
with the CHANGE.DB ICON command.
Restrictions:
v If the DB is recoverable, NOICREQ cannot be specified without also
specifying NONRECOV or USERRCOV.
v NOICREQ will reset all DBDS IC NEEDED values to OFF and the DB
IMAGE COPY NEEDED COUNT to 0.
v If the DB is changed to RECOVABL, this option is reset to ICREQ and IC
NEEDED is set ON in all DBDSs; and the DB IMAGE COPY NEEDED
COUNT is set accordingly.
v ICREQ | NOICREQ cannot be specified with the ALL parameter.
| NOBACK SSID(name) | BACKOUT(value) SSID(name)
database needs backout by any subsystem. Do not use these parameters for a
DEDB.
NOBACK
Indicates that the specified subsystem does not need to back out the
database. You use this parameter to delete backout information in the
specified database record.
If the held AUTH state and ENCODED state are zero, and if the
BACKOUT-NEEDED flag is on, using the NOBACK parameter causes the
associated subsystem information to be deleted from the database record.
BACKOUT
Indicates that the specified subsystem needs to back out the database the
specified number of times. You need to specify the subsystem name with
the SSID parameter. If you do not specify the SSID parameter with the
BACKOUT parameter, this command fails.
SSID(name)
Required parameter specifying which subsystem encountered the backout
errors.
name is any valid subsystem name.
With UNAUTH, SSID indicates which entry is to be removed from the
associated subsystem information list of the database specified with the
DBD parameter, or which SSYS record is to be changed by removing the
specified DB/AREA from the authorized databases/areas list.

CHANGE.DB
| SSID is required with the NOBACK, BACKOUT or UNAUTH parameters

| If SSID is not included with NOBACK, BACKOUT or UNAUTH, the
| command fails.
NONRECOV | RECOVABL | USERRCOV
Mutually exclusive, optional parameters used to specify whether update logs
of the specified database are recorded in the RECON data set.
NONRECOV
Specifies that no recovery is to be performed on the database.
RECOVABL
Specifies that the database is recoverable and all updates performed for the
DBDSs or areas are to be registered in the RECON data set.
USERRCOV
Specifies that update allocations for the Fast Path DEDB are not to be
recorded in the RECON data set. Database updates are logged by IMS, but
DBRC cannot be used to manage recovery for the database. Recovery is
allowed with JCL manually generated by the user. This parameter is valid
only for Fast Path DEDBs.
Notes for USERRCOV:
1. USERRCOV should only be used if a critical need to reduce database
open time exists and recoverability is require.
2. USERRCOV requires the user to provide their own manually-created
JCL for change accumulation and recovery.
Restrictions for NONRECOV, RECOVABL, and USERRCOV:

v HALDB master databases are supported by these parameters, but HALDB
partitions are not.
v These parameters are not valid when ALL is specified with the CHANGE.DB
command.
v You cannot take concurrent image copies of nonrecoverable or
user-recoverable databases.
v If the database is registered as RECOVABL or USERRCOV, VIO data sets
cannot be used for the output log (IEFRDER) in any job that updates the
database. Temporary log data sets, such as VIO, are deleted at job
termination, and therefore are not usable for recovery.
v NONRECOV or USERRCOV cannot be specified for RSR-covered databases.
v NONRECOV does not support DEDBs with SDEPs. For a more detailed
description of this restriction, see the ″Non-Recovery Option″ section in the
IMS Version 9: Administration Guide: Database Manager manual.
OLRCAP | OLRNOCAP
Mutually exclusive, optional parameters that specify if the HALDB can be
reorganized online using HALDB OLR. There is no default and these
parameters are valid only when the DBD is a HALDB master.
OLRCAP Specifies (in the master database record and the partition
database record) that the HALDB database is capable of being
reorganized online.
| OLRNOCAP Specifies (in the master database record and the partition
| database record) that the HALDB database is not capable of
| being reorganized online. If the HALDB OLR cursor is active
| or if any M-through-V and Y DBDSs are active, the command
| fails. If the command completes successfully and the

CHANGE.DB
| M-through-V and Y DBDSs and all of their associated records

| exist in the RECON data set, the M-through-V and Y DBDSs
| and all of their associated records are deleted from the RECON
| data set for all partitions.
| OLRBYTES(value)
| Optional parameter to specify a RECON value that indicates the number of
| bytes of a HALDB partition that have been moved by HALDB online
| reorganization. The value can range between 0 and 47244640256. The value can
| be specified in decimal or hexadecimal equivalent. Hexadecimal values must
| be enclosed in quotation marks, such as X'B00000000'.
| The OLRBYTES keyword is not valid for, or with, the following items:
| v ALL, UNAUTH, OLRCAP, and OLRNOCAP keywords
| v HALDB master
| v HALDB partition that is marked as not capable of running OLR
| v Fast Path databases
| OLRROOTS(value)
| roots of a HALDB partition that have been moved by HALDB online
| be enclosed in quotation marks, such as X'7FFFFFFF'.
| The OLRROOTS keyword is not valid for, or with, the following items:
| v HALDB master
| OLRSEGS(value)
| segments of a HALDB partition that have been moved by HALDB online
| be enclosed in quotation marks, such as X'B00000000'.
| The OLRSEGS keyword is not valid for, or with, the following items:
| v HALDB master
OLRRGON | OLRRGOFF
| Mutually exclusive, optional parameters that specify whether a HALDB OLR is
| in progress. These parameters are valid only for a HALDB partition.
| OLRRGON Specifies that a HALDB OLR is in progress. Both the
| A-through-J and the M-through-V data sets contain active data.
| OLRRGOFF Specifies that a HALDB OLR has completed and that either the
| A-through-J set of data sets or the M-through-V set of data sets
| contain active data. The flag is changed to indicate that the
| inactive data sets are now the active data sets. OLREORG CURSOR
| ACTIVE = NO is set in the DB record. The OLRIMSID is cleared.

CHANGE.DB
| Note: You might need to manually delete either the DB

| (HALDB) records or to add a stop time to them using
| the DELETE.REORG and NOTIFY.REORG commands. For
| more information, see “DELETE.REORG” on page 217
| and “NOTIFY.REORG” on page 332.
| OLRIMSID(name) | NOOWNER
Mutually exclusive, optional parameters that specify or change the name of the
IMS that owns the HALDB OLR.
OLRDBDS(A | M)
Optional parameter that indicates the active set of DBDSs for this partition is
either A-through-J and X or M-through-V and Y.
A Specifies that the A-through-J and X data sets are active.
M Specifies that the M-through-V and Y data sets are active.
PINIT | NOPINIT
Mutually exclusive, optional parameters used to specify whether a HALDB
partition needs to be initialized. Use this parameter after deleting and
redefining one or more partition data sets without changing the database
definition.
If the database specified by DBD parameter is a HALDB master, the change is
made to all partitions. Otherwise, only the partition that is specified is
changed.
Restriction: The PINIT | NOPINIT parameters are not valid with ALL.
PINIT
Indicates that the partition needs to be initialized using the DB
Prereorganization utility or the HALDB Partition Data Set Initialization
utility.
NOPINIT
Indicates that the partition does not need to be initialized.
RCVTRACK | DBTRACK
Mutually exclusive, optional parameters you use to specify the type of RSR
tracking (shadowing) for DL/I databases that are assigned to a GSG.
RCVTRACK
Indicates recovery-readiness tracking.
DBTRACK
Indicates database-readiness tracking.
Neither RCVTRACK nor DBTRACK can be specified for Fast Path DEDBs. For
DL/I databases, RCVTRACK or DBTRACK can only be specified if the
database is assigned to a GSG and is not currently in use, including all the
partitions of a HALDB.
READON | READOFF
database can be restricted to read only processing only. Do not use either
parameter for a DEDB.
READON
Specifies that the database can be authorized only for read processing.

CHANGE.DB
READOFF
Specifies that the database can be authorized for both read processing and
update processing.
SHARELVL(0 | 1 | 2 | 3)
Optional parameter you use to specify the level of data sharing for which
authorized subsystems can share a database. You cannot specify this parameter
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 subsystem
authorized for update and other IMS subsystems authorized only for
read processing (no integrity processing). 1 can also indicate that the
database can be shared by multiple IMS subsystems that have been
authorized only for read processing. Level 1 is known as database-level
sharing.
2 Indicates that the database can be shared by multiple, concurrent
subsystems that have been authorized for update in a single-host
processor environment. Level 2 is known as intrahost, block-level
sharing.
3 Indicates that the database can be shared by multiple, concurrent
subsystems that have been authorized for update in a multiple-host
processor environment. Level 3 is known as interhost, block-level
sharing.
For more information on data sharing levels and dynamic allocation, see IMS
Version 9: Utilities Reference: System.
Restrictions:
v The SHARELVL parameter must be greater than 0 for concurrent image
copies.
| v If you are using IRLM, and have specified SHARELVL 1, 2 or 3, ensure that
| the VSAM SHAREOPTIONS (3 3) parameter is also specified.
| For more information on coordinating VSAM data set definitions with share
| options, see IMS Version 9: 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 coupling
| facility structure name (CFSTR1) for all VSO areas in the DEDB is set to the
| name 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, resets
| the LKASID parameter to NOLKASID, and resets the MAS parameter to
| NOMAS. See “CHANGE.DBDS” on page 152 for explanations of the
| CFSTR1, LKASID, NOLKASID, MAS, and NOMAS parameters.
TYPEFP | TYPEIMS
Mutually exclusive, optional parameters you use to change the RECON record
structure to a Fast Path DEDB or a DL/I database.
TYPEFP
Specifies that the database is a Fast Path DEDB and that the record
structure in RECON must be changed from IMS to Fast Path. TYPEFP
cannot be specified for an RSR-covered DL/I database.
TYPEIMS
Specifies that the database is a DL/I database and that the record structure

CHANGE.DB
in RECON must be changed from Fast Path to IMS. TYPEIMS cannot be

specified if any area of a DEDB is covered by RSR.
UNAUTH
Removes an entry from the associated subsystem information list in the
database specified by the DBD parameter, or removes an entry from the
authorized databases/areas list in the SSYS record specified by the SSID
parameter. 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 the
name of the DEDB area. If you specify AREA without UNAUTH, the
command fails.
ACTIVE | TRACKING
Indicates the role of the specified subsystem when UNAUTH is specified.
These parameters are ignored unless UNAUTH is specified.
ACTIVE
Specifies that the subsystem is an RSR active subsystem.
TRACKING
Specifies that the subsystem is an RSR tracking subsystem.
| PARTSEL(pgmname) | HIKEY
| Mutually exclusive, optional parameters used to either identify or delete a user
| Partition Selection Exit program name for a HALDB. Deleting the partition
| selection exit program name causes all of the partition selection strings to be
| cleared. Adding or changing a partition selection exit program name will leave
| the partition high keys or partition selection strings intact. In all cases, all of
| the partitions are marked PINIT (partition initialization needed). The command
| will fail if NOPINIT is also specified. Use the CHANGE.PART command to specify
| new partition high keys or partition selection strings.
| PARTSEL(pgmname)
| Identifies a user Partition Selection Exit program name for a HALDB. The
| value is a program name that is up to 8 characters long.
| Restriction: This parameter is not valid with ALL.
| HIKEY
| Removes an existing Partition Selection Exit program associated with a
| HALDB.
| Restriction: This parameter is not valid with ALL.
| REORGI | NOREORGI
| Mutually exclusive, optional parameters used by online reorganization
| products (other than the HALDB Online Reorganization function that is
| delivered with IMS) to inform DBRC they are active (they intend to reorganize
| the database) to provide data integrity for full function databases. When the
| REORG INTENT flag is set to ON, database authorization fails for other
| reorganization products, batch access, and online image copy processes.

CHANGE.DB
| REORGI
| Indicates that the database is going to be reorganized and sets the REORG
| INTENT flag to ON in the database record of the RECON data set if the
| following conditions have been met:
| v Database type is valid. Must be full function including HALDBs.
| v The REORG INTENT flag is off.
| v No batch jobs are authorized to the database.
| v HALDB Online Reorganization (OLR) cannot have cursor active set
| (OLREORG CURSOR ACTIVE=YES).
| v The database cannot be owned by an IMS OLRIMSID=imsid.
| NOREORGI
| Indicates that the database is not going to be reorganized (or has just
| completed reorganization) and sets the REORG INTENT flag to OFF in the
| database record of the RECON data set if the following conditions have
| been met:
| v Database type is valid. Must be full function including HALDBs.
| v The REORG INTENT flag is on.
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 database
identified with the DBD parameter. The level of data sharing is specified, and the
database needs one backout.
//CHGDB JOB
.
.
.
//SYSIN DD *
CHANGE.DB DBD(THISDBD) NOAUTH READOFF SHARELVL(2) -
BACKOUT(1) SSID(IMSID1)
/*
CHANGE.DBDS
Use a CHANGE.DBDS command to change the information about a DBDS. This
information 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, the
command fails.
Some attributes of a HALDB DBDS can be changed with this command. See
“CHANGE.PART” on page 164 if you want to change all the DBDSs of a HALDB
partition.
Restrictions for HALDBs: For HALDBs, you can use this command only as
indicated in Table 10 on page 152.
Table 10. CHANGE.DBDS for HALDBs
CHANGE.DBDS Partition Data DBDS Partition Index/ILDS
DBDS
ADDEQE | DELEQE Yes Yes
CFSTR1 N/A N/A
CFSTR2 | NOCFSTR2 N/A N/A
AUTH | NOAUTH N/A N/A
DDNEW | AREANEW No No
DEFLTJCL | NODEFLT Yes No

CHANGE.DBDS
Table 10. CHANGE.DBDS for HALDBs (continued)

CHANGE.DBDS Partition Data DBDS Partition Index/ILDS
DBDS
DSN No No
GENMAX Yes No
GSGNAME | NOTCOVER N/A N/A
ICJCL Yes No
ICON | ICOFF Yes No
NOREUSE | REUSE Yes No
OICJCL Yes No
LKASID | NOLKASID N/A N/A
PRELOAD | NOPREL N/A N/A
PREOPEN | NOPREO N/A N/A
RCVTRACK | DBTRACK N/A N/A
RECOV | NORECOV Yes Yes
RECOVJCL Yes No
RECOVPD Yes No
RECVJCL Yes No
VSO | NOVSO N/A N/A
CHANGE.DBDS Syntax
| CHANGE.DBDS DBD(name) DDN(name)
| AREA(name) ,
ADDEQE( value )
,
DELEQE( value )
|
| CFSTR1(name) CFSTR2(name) AUTH DDNNEW(name)
NOCFSTR2 NOAUTH AREANEW(name)
|
| DEFLTJCL(member) DSN(name) GENMAX(value) GSGNAME(gsgname)
NODEFLT NOTCOVER
|
| ICJCL(member) ICON NOREUSE OICJCL(member) LKASID
ICOFF REUSE NOLKASID
|
| MAS PRELOAD PREOPEN RCVTRACK RECOV
NOMAS NOPREL NOPREO DBTRACK NORECOV
|
| RECOVJCL(member) RECOVPD(value) RECVJCL(member) VSO
NOVSO
|

CHANGE.DBDS
Parameters for CHANGE.DBDS

DBD(name)
Required parameter you use to identify by its database name the DBDS or
DEDB area whose record is to be changed.
Restrictions for HALDBs: For HALDBs, name specifies the name of a HALDB
partition.
DDN(name) | AREA(name)
Mutually exclusive, required parameters you use to identify the DBDS or
DEDB area whose record is to be changed. When you specify DDN, you
specify the ddname of the DBDS. When you specify AREA, you specify the
name of the area.
ADDEQE(value) | DELEQE(value)
Mutually exclusive, optional parameters you use to change the error queue
elements of a DBDS.
ADDEQE
Adds error queue elements to a DBDS. Error queue elements indicate that
an I/O error occurred on the data set and that the data set therefore needs
to be recovered. Processing continues except for that part of the data set
described by the error queue element. Error queue elements can be added
only when the DBDS is not in use. The value specified in the variable field
is one or more 4-byte hexadecimal values enclosed in quotes; for example,
ADDEQE(X'00002345', X'00012345', ...).
DELEQE
Deletes error queue elements from a DBDS. Deletion of error queue
elements indicates that recovery processing has occurred on that data set.
Error queue element deletions can be done only when the DBDS is not in
use. The value specified in the variable field is one or more 4-byte
hexadecimal values enclosed in quotes; for example, DELEQE(X'00002345',
X'00012345', ...).
When you add an EQE to a database, the RECOV-NEEDED flag is

automatically turned on. When you delete an EQE, and no other EQE flags
exist for the database, the RECOV needed flag is turned off. Do not specify
RECOV or NORECOV when specifying the ADDEQE or DELEQE parameters.
CFSTR1(name)
Optional parameter you specify to change the name of the first coupling
facility structure for the identified VSO area. Adhere to the z/OS coupling
facility structure naming conventions. This parameter is valid only for VSO
areas of DEDBs that are defined with SHARELVL(2 | 3). The area name is the
default if the area is changed to VSO and the DEDB is SHARELVL(2 | 3).
CFSTR1 is not allowed if the area is authorized, unless it is also being changed
from NOVSO to VSO.
CFSTR2(name) | NOCFSTR2
Mutually exclusive, optional parameters you use to update or remove the
name of the second coupling facility structure for the identified VSO area.
These parameters are valid only for VSO areas of DEDBs that are defined with
SHARELVL(2 | 3). These parameters are allowed for an authorized area only if
it is being changed from NOVSO to VSO.
CFSTR2(name)
Specifies the new name of the second coupling facility structure. Adhere to
the z/OS naming conventions for coupling facility structures.

CHANGE.DBDS
Related Reading: See IMS Version 9: Administration Guide: Database

Manager for details on coupling facility structure naming conventions.
Restriction: CFSTR2 cannot be specified with MAS or cannot be specified
if the area is already specified as a multi-area coupling facility structure.
NOCFSTR2
Removes the name of the second coupling facility structure (CFSTR2).
AUTH | NOAUTH
Mutually exclusive, optional parameters you use to specify whether the area is
available for authorization processing. The AUTH and NOAUTH parameters
are valid only if you have specified the AREA parameter.
AUTH
Specifies that the area is available for authorization processing.
NOAUTH
Specifies that authorization processing is prohibited for the area.
If you specify the CHANGE.DBDS AREA(name) RECOV command, all ADSs that
belong 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 database
ddname of the specified DBDS or the area name of the specified Fast Path
DEDB area in RECON.
When you specify this parameter, the new ddname replaces the existing
ddname 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 the
CHANGE.DBDS command. The new ddname must be defined in the IMS DBD
library and its numeric data set identifier must be unchanged; it also cannot
already exist in RECON.
AREANEW is valid only if you have specified the AREA parameter.
DEFLTJCL(member) | NODEFLT
Mutually exclusive, optional parameters you use to specify an implicit skeletal
JCL default member for the DBDS.
DEFLTJCL
Specifies the new implicit skeletal JCL default member for the DBDS. The
specified member is used by the GENJCL.IC, GENJCL.OIC, and GENJCL.RECOV
commands to resolve keywords you have defined.
NODEFLT
Removes the default JCL name from the DBDS record when you do are not
using a default JCL member.
DSN(name)
Optional parameter you use to change the data set name of the identified
DBDS. You cannot use this parameter for a DEDB area.
GENMAX(value)
Optional parameter you use to change the maximum number of image copy
data sets DBRC is to maintain for the specified DBDS or DEDB area. value
must be a decimal number from 2 to 255.
If the value you specify is smaller than the number of image copy data sets
currently existing for the specified DBDS, records of image copy data sets that
are beyond the recovery period are deleted from RECON until the number

CHANGE.DBDS
reaches the specified GENMAX value. Records of image copy data sets with
the oldest time stamps are deleted until the number that remains equals the
specified GENMAX value.
If you are increasing the GENMAX value and REUSE is specified, use the
INIT.IC command to create additional image copy records in RECON. If the
number of data sets does not equal GENMAX, reuse of the data sets does not
take place and you eventually run out of available data sets for the utility.
GSGNAME(gsgname) | NOTCOVER
Mutually exclusive, optional parameters you use to assign the remote site
recovery attributes of a DEDB area.
GSGNAME
Assigns the area to a global service group (GSG).
NOTCOVER
Discontinues 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 from
non-RSR-covered to RSR-covered. Message DSP1044I is issued if you attempt
to change the covered state of the area with this command. In order to change
an area from non-RSR-covered to RSR-covered, issue the following two
commands for the area:
v DELETE.DBDS
v INIT.DBDS
ICJCL(member)
Optional parameter you use to change the name of the member of the
partitioned data set of skeletal JCL. The GENJCL.IC command uses this name to
generate the JCL for a run of the Database Image Copy utility for the specified
DBDS or DEDB area.
ICON | ICOFF
Mutually exclusive, optional parameters you use to specify whether a database
needs an image copy.
ICON
Specifies that a DBDS needs to have an image copy taken. If the image
copy status of a DBDS is IC RECOMMENDED, issuing a CHANGE.DBDS ICON
command changes the image copy status (in the RECON) from IC
RECOMMENDED to IC NEEDED. In the associated database record, the
IC NEEDED counter increases to indicate how many DBDSs need an
image copy.
ICOFF
Specifies that a DBDS does not need an image copy. If the image copy
status of a DBDS is IC RECOMMENDED or IC NEEDED, issuing a
CHANGE.DBDS ICOFF command resets (turns off) the image copy status. If the
image copy status was IC NEEDED before issuing the CHANGE.DBDS ICOFF
command, the IC NEEDED counter in the associated database record is
decreased by one after the CHANGE.DBDS ICOFF command is issued. The IC
NEEDED counter indicates the number of DBDSs that need an image copy.
NOREUSE | REUSE
Mutually exclusive, optional parameters you use to indicate whether image
copy data sets can be reused for subsequent image copy jobs.

CHANGE.DBDS
NOREUSE
Indicates that image copy data sets already used for the specified DBDS or
DEDB area are not to be reused for subsequent image copies. Any existing,
unused image copy data set records for the specified DBDS or DEDB area
are deleted.
REUSE
Indicates that image copy data sets already used for the specified DBDS or
DEDB area can be made available for reuse by subsequent image copies.
You cannot specify REUSE if RECON contains any nonstandard image
copy data set records for the DBDS or DEDB area.
If GENMAX is higher than the number of existing data sets for the group,
use the INIT.IC command to add additional data sets; otherwise, reuse of
the data sets does not take place. See “INIT.IC” on page 278 for more
information.
For additional information about reusing image copy data sets, see
“INIT.DBDS” on page 271 for an explanation of the REUSE parameter.
OICJCL(member)
Optional parameter you use to change the name of the partitioned data set
member of skeletal JCL. You cannot use this parameter for a DEDB area. The
GENJCL.OIC command uses this name to generate the JCL for a run of the
Online Database Image Copy utility for the specified DBDS.
LKASID | NOLKASID
Mutually exclusive optional parameters you use to specify whether local data
caching for the specified area is to be used for buffer lookaside on read
requests. The LKASID option is valid only for VSO areas that are specified as
SHARELVL(2 | 3). These parameters are allowed for an authorized area only if
it is being changed from NOVSO to VSO.
LKASID
Indicates that buffer lookaside is to be performed on read requests for this
area.
NOLKASID
Indicates that buffer lookaside is not to be performed on read requests for
this area.
| MAS | NOMAS
| Mutually exclusive, optional parameters you use to specify whether a shared
| VSO area is to reside in a multi-area coupling facility structure.
| MAS Indicates that the area is to reside in a multi-area coupling facility
| structure. A second coupling facility structure name (CFSTR2) cannot
| be specified if MAS is specified. If a second structure is already
| defined, the second structure’s name is removed.
| Restrictions: MAS can only be specified if the DEDB is specified as
| SHARELVL (2 or 3) and either VSO is specified or the area is already
| specified as a VSO DEDB. Also, CFSTR2 cannot be specified with MAS
| or cannot be specified if the area is already specified as a multi-area
| coupling facility structure.
| NOMAS
| Indicates that the coupling facility structure (or structures) should
| contain data for only this area.

CHANGE.DBDS
PRELOAD | NOPREL
Mutually exclusive, optional parameters you use to specify whether a VSO
DEDB area is to be loaded the next time it is opened.
PRELOAD
| Indicates that the area is to be loaded into the data space or coupling
| facility structure the next time that it is opened. Selecting this option also
| causes the area to be preopened.
NOPREL
| Indicates that the VSO area is not to be loaded into the data space or
| coupling facility structure the next time that it is opened. CIs are copied
| into a data space when they are read for the first time.
PREOPEN | NOPREO
Mutually exclusive, optional parameters you use to specify whether a VSO
DEDB area is to be opened either, after the first checkpoint following the next
control region initialization, or when the next /STA AREA command is
processed.
PREOPEN
Indicates that the area is to be opened the next time the control region is
started or a /STA AREA command is processed. This option is valid for both
VSO and non-VSO areas.
NOPREO
Indicates that the area is not to be preopened the next time the control
region is started or a /STA AREA command is processed. You cannot specify
this parameter with the PRELOAD parameter.
RCVTRACK | DBTRACK
Mutually exclusive, optional parameters you use to specify the type of RSR
tracking (shadowing) for an area assigned to a GSG.
RCVTRACK
DBTRACK
Restriction:
RCVTRACK and DBTRACK can only be specified if AREA is specified and the
area is assigned to a GSG.
RECOV | NORECOV
Mutually exclusive, optional parameters you use to specify whether a DBDS or
DEDB area needs to be recovered.
RECOV
Specifies that the DBDS or area needs to be recovered. A
RECOVER-NEEDED counter in the associated database record is increased
to indicate the number of DBDSs that need to be recovered.
NORECOV
Specifies that the DBDS or DEDB area does not need to be recovered. A
RECOVERY-NEEDED counter in the associated database record is
decreased 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

CHANGE.DBDS
partitioned data set of skeletal JCL. The GENJCL.RECOV command uses the
member to generate 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 for a specified
DBDS or DEDB area.
value must be a number from 0 to 999 that represents the number of days the
image copies are to be kept in RECON. A 0 indicates no recovery period.
RECVJCL(member)
Optional parameter you use to specify the name of the skeletal JCL member to
be used for the GENJCL.RECEIVE command.
RECVJCL can be specified for both RSR-covered and non-RSR-covered DL/I
DBDSs and Fast Path areas.
VSO | NOVSO
Mutually exclusive, optional parameters you use to specify whether an area
resides in virtual storage the next time the control region is initialized or when
the next /STA AREA command is processed.
VSO
Indicates that the area is to reside in virtual storage. Areas defined with
SHARELVL(0 | 1) are read into and written from a z/OS data space. Areas
defined with SHARELVL(2 | 3) use the coupling facility to share data
between connected subsystems.
NOVSO
Indicates that this area is not to reside in virtual storage.
If an area was previously specified as SHARELVL(2 | 3), changing the area
to NOVSO clears the coupling facility structure names and resets the
LKASID setting to NOLKASID. NOVSO cannot be specified if the area is
in use.
Example of Changing a Record for a Fast Path DEDB

This example specifies changes to be made to the record in RECON for the Fast
Path DEDB that is identified by the DBD and AREA parameters. The image copy
data sets for the specified DEDB area are not reused, and the maximum number of
images that DBRC maintains is two. In addition, the image copy data sets for the
specified 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
Use a CHANGE.DBDSGRP command to change the information about a DBDS or
database group. This information is contained in a DBDS group record in RECON.
CHANGE.DBDSGRP Syntax
CHANGE.DBDSGRP GRPNAME(name)

CHANGE.DBDSGRP
ADDDB( ( dbname ) )
areaname
,
DELDB( ( dbname ) )
areaname
,
ADDMEM( (dbname, ddname ) )

areaname
,
DELMEM( (dbname, ddname ) )

areaname
,
(1)
ADDRECOV( (dbname ) )
,
(2)
(dbname ,areaname)
,
(1)
DELRECOV( (dbname ) )
,
(2)
(dbname ,areaname)
Notes:
1 Full-function database name
2 Fast Path DEDB name
Parameters for CHANGE.DBDSGRP

GRPNAME(name)
Required parameter you use to identify the DBDSGRP to be changed. A record
with that name must already exist.
ADDDB(dbname | areaname) | DELDB(dbname | areaname) |
ADDMEM(dbname,ddname | areaname) | DELMEM(dbname,ddname | areaname) |
ADDRECOV(dbname,areaname) | DELRECOV(dbname,areaname)
Mutually exclusive, optional parameters you use to identify the member or
members to be added to or deleted from the group. A member can belong to
any number of DB groups or DBDS groups but can belong only to one
recovery group.
ADDDB(dbname)
Identifies one or more database or area names to be added to a DB group.
The name specified can be a full-function database name, a Fast Path
DEDB name, or an area name.
DELDB(dbname)
Identifies one or more database or area names to be deleted from a DB
group. The name specified can be a full-function database name, a Fast
Path DEDB name, or an area name.

CHANGE.DBDSGRP
ADDMEM(dbname,ddname)
Identifies one or more members to be added to a DBDS group, where
dbname is the database name and ddname is the DD statement name or the
area name.
DELMEM(dbname,ddname)
Identifies one or more members to be deleted from a DBDS group, where
dbname is the database name and ddname is the DD statement name or the
area name.
ADDRECOV(dbname,areaname)
Identifies one or more databases or DEDB areas to be added to a recovery
group, where dbname is the database (or DEDB) name and areaname is the
DD statement name or the area name.
If a DEDB area is to be added to the recovery group, both dbname and
areaname 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 the
members specified by ADDRECOV already belong to another recovery
group, the command fails with message DSP0078I.
DELRECOV(dbname,areaname)
Identifies one or more databases or DEDB areas to be deleted from a
recovery group, where dbname is the database (or DEDB) name and
areaname is the DD statement name or the area name.
If a DEDB area is to be deleted from the recovery group, both dbname and
areaname must be specified. If the group specified is not a recovery group,
the command fails with message DSP0077I.
If you delete all the members of a group, the record of that group is deleted from
RECON.
Restrictions for HALDBs: For HALDBs, dbname specifies the name of a HALDB
partition or the HALDB master. When specifying HALDB database names, use the
CHANGE.DBDSGRP command only as defined in Table 11.
Table 11. Supported dbname specifications for HALDBs on CHANGE.DBDSGRP command
parameters
CHANGE.DBDSGRP dbname = HALDB dbname = Partition
Master
ADDDB Yes Yes
DELDB Yes Yes
ADDMEM No Yes
DELMEM No Yes
ADDRECOV Yes No
DELRECOV Yes No
Example of Changing a Group of DBDSs

In this example, a group of DBDSs is changed.

CHANGE.DBDSGRP
//CHGDBGRP JOB
.
.
.
//SYSIN DD *
CHANGE.DBDSGRP GRPNAME(GRP1) -
ADDMEM((DB1,DD1),(DB2,DD2))
/*
CHANGE.IC
Use a CHANGE.IC command to modify information contained in an image copy
record in RECON.
CHANGE.IC Syntax
CHANGE.IC DBD(name) DDN(name) RECTIME(time_stamp)
AREA(name)

FILESEQ(value) FILESEQ2(value) ICDSN(name) ICDSN2(name)

INVALID INVALID2 RECDCT(value) 3400
VALID VALID2 UNIT( unittype )

3400 ,
UNIT2( unittype )
VOLLIST( volser )

, STOPTIME(time_stamp)
VOLLIST2( volser )
Parameters for CHANGE.IC

DBD(name)
Required parameter you use to identify the database name of the DBDS whose
image copy record is to be modified.
Restrictions for HALDBs: For HALDBs, dbname specifies the name of a
HALDB partition.
Mutually exclusive, required parameters you use to identify the name of the
DBDS 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 record
to be changed.
Use the Run time marked with an asterisk (*) from the listing of the IMAGE
FILESEQ(value)
Optional parameter you use to change the file sequence number in the record
of the identified image copy data set.

CHANGE.IC
FILESEQ2(value)
Optional parameter you use to change or add the file-sequence number in the
record of the identified duplicate image copy data set.
ICDSN(name)
Optional parameter you use to change the data set name of the identified
image copy data set.
ICDSN2(name)
Optional parameter you use to change or add the data set name of the
identified 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 first
image copy data set must exist in RECON.
INVALID | VALID
| Mutually exclusive, optional parameters that you use to prevent or permit the
| use of an image copy data set as input to a subsequent run of the Database
| Recovery utility (DFSURDB0).
| INVALID
| Prevents the use of the specified image copy data set as input to a
| subsequent run of the Database Recovery utility. If the invalidated image
| copy data set is reused, it is automatically marked as valid. See
| “INIT.DBDS” on page 271 for an explanation of the REUSE parameter.
| VALID
| Permits the use of a previously invalidated image copy data set as input to
| a subsequent run of the Database Recovery utility.
| The Database Recovery utility expects this image copy data set as input
| unless it is marked as INVALID, in which case the utility expects a
| duplicate image copy data set as input.
INVALID2 | VALID2
| Mutually exclusive, optional parameters that you use to prevent or permit the
| use of a duplicate image copy data set as input to a subsequent run of the
| Database Recovery utility (DFSURDB0).
| INVALID2
| Prevents the use of the specified, duplicate image copy data set as input to
| a subsequent run of the Database Recovery utility. If the invalidated,
| duplicate image copy data set is subsequently reused, it is automatically
| marked as valid. See “INIT.DBDS” on page 271 for an explanation of the
| REUSE parameter.
| VALID2
| Permits the use of a previously invalidated, duplicate image copy data set
| as input to a subsequent run of the Database Recovery utility.
| 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 the
corresponding image copy data set in the specified image copy record.
CHANGE.ICvalue must be a decimal number up to 2 147 483 647.
Optional parameter you use to change the unit type that is recorded in the
specified image copy record. The unit type can be up to eight alphanumeric
characters.

CHANGE.IC
UNIT2(3400 | unittype)
Optional parameter you use to change the unit type that is recorded in the
specified duplicate image copy record. The unit type can be up to eight
alphanumeric characters.
VOLLIST(volser)
Optional parameter you use to change, in the image copy record, the volume
serial numbers of the volumes on which the identified image copy data set
resides.
VOLLIST2(volser)
Optional parameter you use to change or add, in the image copy record, the
volume serial numbers of the volumes on which the identified duplicate image
copy data set resides.
STOPTIME(time_stamp)
Optional parameter you use to specify the time when an image copy has
completed. The time stamp must be in standard form (see “Standard Time
Stamp Format” on page 126) and cannot be less than the image copy start
time. If this is an HSSP CIC that is in progress, specifying a valid stop time
terminates the HSSP CIC and resets the in-progress indicators in the IC record
and the DBDS record.
Example of Changing an Image Copy Record

In 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
names of both image copy data sets (specified in the ICDSN and ICDSN2
parameters) follow the default naming convention. The volume serial numbers on
which the image copy data sets reside are also to be changed as specified in the
VOLLIST 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.PART
Use a CHANGE.PART command to change attributes of a HALDB partition. The
changes apply to all the DBDSs of the partition. Some attributes such as skeletal
JCL member names can be changed for a single DBDS of a partition by a
CHANGE.DBDS command. See “CHANGE.DBDS” on page 152 for a list of what
can be changed.
Restriction: The IMS DBDLIB data set must be identified in the job stream for the
RECOVERY Control utility with a ddname of IMS if KEYSTRNG is being set.
| Use the DISABLE parameter to temporarily remove a partition from active use.
| Use the ENABLE parameter to return the partition to active use. You would
| normally DISABLE a partition prior to deleting it (see “DELETE.PART” on page
| 215), but do not want to remove all the recovery related information that DBRC
| maintains until the changes have been tested. A partition marked as DISABLE can
| be deleted or made active again by marking it ENABLE. A partition that is
| changed from DISABLE to ENABLE must be recovered before it can be used.

CHANGE.PART
| Restriction: No other parameters are allowed on a CHANGE.PART command if

| either DISABLE or ENABLE is specified.
Related Reading: See the IMS Version 9: Administration Guide: Database Manager for
information on designing databases, especially the following:
v “Designing Databases”
v “Naming Conventions”
v “Procedure for Changing PHDAM, PHIDAM, and PSINDEX Partition
Definitions”
CHANGE.PART Syntax
Use one of the following diagrams for the CHANGE.PART command.
CHANGE.PART DBD(name) PART(name)

KEYSTRNG( string )
hex_string

DSNPREFX(string) RANDOMZR(name) ANCHOR(value)

HIBLOCK(value) BYTES(value) FBFF(value) FSPF(value)

, GENMAX(value) DEFLTJCL(member)
BLOCKSZE( nnnnn )

ICJCL(member) OICJCL(member) REUSE RECOVJCL(member)
NOREUSE

RECOVPD(value) RECVJCL(member)
Or:
| CHANGE.PART DBD(name) DISABLE

ENABLE
|
Parameters for CHANGE.PART

DBD(name)
Required parameter used to identify the HALDB.
PART(name)
Required parameter you use to identify the partition.
KEYSTRNG(char or hex value)
Optional parameter used to change a HALDB partition high key value or a
selection string for use by a partition selection exit. Specified as a character
value up to 256 characters long or a hexadecimal value up to 512 characters
long. Character values must be alphanumeric (with no embedded blanks or
commas unless the string is enclosed by single quotes). Unless enclosed by
single quotes, the character string will be folded to upper case. Hexadecimal
values must be enclosed by single quotes and preceded by the letter X, for
example: KEYSTRNG(X'D7C1D9E3D2C5E8').

CHANGE.PART
If no partition selection routine is specified for the HALDB, KEYSTRNG

defines a partition high key value which cannot be longer than the root key
length. If the high key length is less than the defined root key length, the high
key value is padded with hex ’FF’s up to the defined root key length. The
partition high key values must be unique for each partition within a HALDB.
If a partition selection routine is specified for the HALDB, KEYSTRNG defines
a Partition Selection String which is passed to the partition selection routine.
The Partition Selection String may be up to 256 bytes long and consist of
simple character information. If it contains non-printable characters, it must be
identified using hex notation. A hex character string is enclosed by single
quotation marks and prefixed with an X.
The command fails if the partition is in use, or any other partition affected by
a change to the high key value is in use. The partition and all other partitions
affected by a change to the high key value are marked as needing partition
initialization (PINIT is set on) and can not be used until initialized (see
HALDB Partition Data Set Initialization utility (DFSUPNT0) in IMS Version 9:
Utilities Reference: Database and Transaction Manager, SC18-7833).
Requirement: When you issue a CHANGE.PART KEYSTRNG command, the IMS
DBDLIB data set must be identified in the job stream for the Database
Recovery Control utility with a ddname of IMS.
DSNPREFX(string)
Optional parameter used to change the data set name prefix for the partition
data 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 change the name of the randomizing module for
HALDB PHDAM databases only. A randomizing module controls root segment
placement in, or retrieval from, the PHDAM HALDB.
ANCHOR(value)
Optional parameter used to change the number of RAPs (root anchor points)
desired in each control interval or block in the root addressable area of a
PHDAM HALDB. The value specified must be between 1 and 255. Typical
values are from 1 to 5.
HIBLOCK(value)
Optional parameter used to change the maximum relative block number value
that 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
root addressable area of an PHDAM HALDB. The value may range between 1
and 16,777,215 (2**24 - 1). This parameter is valid only for a PHDAM HALDB.
BYTES(value)
| Optional parameter used to change the maximum number of bytes of a
| HALDB record that can be stored into the root addressable area in a series of
| inserts unbroken by a call to another HALDB record. The value has a range of
| 0 to 16,777,215 (2**24 - 1). This parameter is valid for PHDAM HALDBs only.
| A value of 0 (zero) means that all bytes are addressable. Setting BYTES to 0 is
| equivalent to omitting BYTES on the DBD definition
FBFF(value)
Optional parameter used to change the free block frequency factor (fbff) which
specifies that every nth control interval or block in this data set group is left as
free space during database load or reorganization (where FBFF=n). The range
of FBFF includes all integer values from 0 to 100 except 1.

CHANGE.PART
FSPF(value)
Optional parameter used to change the free space percentage factor. It specifies
the minimum percentage of each control interval or block that is to be left as
free space in this data set group. value may be any number between 0 and 99.
BLOCKSZE(nnnnn)
Optional parameter used to change the block size for OSAM data sets. Specify
an even numeric value no greater than 32766. The block size value is used by
OSAM only. You may specify up to 10 values, one for each data set group
defined in the DBD. Omitted values remain unchanged.
GENMAX(value)
Optional parameter used to change the maximum number of image copies that
DBRC is to maintain for the partition DBDSs. If you identify a partition DBDS
with the NOREUSE parameter, the oldest image copy beyond the recovery
period is deleted when the number of image copies exceeds the GENMAX
value. If you identify it with the REUSE parameter, the oldest image copy
beyond the recovery period is reused. Specified as a numeric value from 2 to
255. All partition DBDSs will be changed to use this GENMAX value. The
CHANGE.DBDS command can be used to change this for individual partition
DBDSs.
DEFLTJCL(member)
Optional parameter used to change the implicit skeletal JCL default member
for a HALDB Partition DBDS. The specified member is used by the
GENJCL.IC, GENJCL.OIC, and GENJCL.RECOV commands in order to resolve
keywords you have defined. All partition DBDSs will be changed to use this
DEFLTJCL member. The CHANGE.DBDS command can be used to change this
for individual partition DBDSs.
ICJCL(member)
Optional parameter used to change the name of a member of a partitioned
data 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 Copy
utility (or the Database Image Copy 2 utility) for the partition DBDS specified
on the GENJCL command. All partition DBDSs will be changed to use this
ICJCL member. The CHANGE.DBDS command can be used to change this for
individual partition DBDSs.
NOREUSE | REUSE
Mutually exclusive, optional parameters used to change whether the supported
image copy utilities are to reuse previously used image copy data sets. REUSE
allows the GENJCL.IC command or the GENJCL.OIC command to generate a
job that causes the supported image copy utilities to reuse the oldest image
copy data set (for the DBDS specified on the GENJCL command) when the
GENMAX value for it is exceeded. REUSE requires that you create empty
image copy data sets for future use by the supported image copy utilities. In
addition, you must use an INIT.IC command to record their existence in
RECON. The NOREUSE parameter prohibits such actions. All partition DBDSs
will be changed to use the parameter specified. The CHANGE.DBDS command
can be used to change this for individual partition DBDSs.
OICJCL (member)
data set that contains skeletal JCL. When you issue a GENJCL.OIC command,
DBRC uses this member to generate the JCL to run the Online Image Copy
utility for the partition DBDS specified on the GENJCL command. Appropriate
partition DBDSs will be changed to use this OICJCL member. The CHANGE.DBDS
command can be used to change this for individual partition DBDSs.

CHANGE.PART
RECOVJCL(member)
data set that contains skeletal JCL. When you issue the GENJCL.RECOV
command, DBRC uses this member to generate the JCL to run the Database
Recovery utility for the partition DBDS specified on the GENJCL command. All
partition DBDSs will be changed to use this RECOVJCL member. The
DBDSs.
RECOVPD(value)
| Optional parameter used to change the recovery period for a specified
| partition DBDS. Specify a numeric value from 0 to 999 that represents the
| number of days you want DBRC to maintain sufficient recovery-generation
| information in the RECON data set. All partition DBDSs will be changed to
| use this RECOVPD value. The CHANGE.DBDS command can be used to
| change this for individual partition DBDSs.
RECVJCL(member)
Optional parameter used to change the name of the skeletal JCL member to be
used by the GENJCL.RECEIVE command. RECVJCL can be specified for both
RSR-covered and non-covered HALDB DBDSs. All partition DBDSs will be
changed to use this RECVJCL member. The CHANGE.DBDS command can be
used to change this for individual partition DBDSs.
| DISABLE | ENABLE
| Mutually exclusive parameters used to change the state of the partition.
| DISABLE marks the partition as unavailable for use by IMS and most utilities.
| In most situations, a partition marked DISABLE will not be known by IMS (it
| is treated as if it is not registered to DBRC). DBRC LIST commands will list
| information about partitions marked DISABLE and the HALDB Partition
| Definition utility (PDU) displays partitions which are marked DISABLE. The
| partition still counts towards the maximum number of partitions which may be
| defined for a HALDB.
| Although a partition that is marked DISABLE is not removed from DBRC
| groups (a CAGROUP, DBDSGRP, DBGROUP and RECOVGRP), it is generally
| not processed as part of the group when the group is used in a DBRC
| command. This also applies to implied groups used in a command. The one
| exception to this is the GENJCL.CA command and the execution of the IMS
| Database Change Accumulation utility. Changes will be accumulated for
| partitions that are members of a CA Group, even when marked DISABLE.
| GENJCL.IC and GENJCL.RECOV commands fail for partitions that are marked
| DISABLE. If the commands specify a group of any kind, partitions that are
| marked DISABLE are skipped, that is, JCL is not generated and no message is
| issued.
| ENABLE makes a partition which had been made DISABLE available for use
| by IMS again. The partition is set to a Recovery Needed status and must be
| recovered before being used by IMS. Setting a partition to ENABLE has the
| same effect as adding a new partition to the HALDB. If the HALDB uses a
| partition selection exit, all the other partitions are set to a Partition
| Initialization Needed status. If the HALDB uses high key values, the partition
| with the next high key value is set to a Partition Initialization Needed status.
| Requirement: When you issue a CHANGE.PART ENABLE command, the IMS
| DBDLIB data set must be identified in the job stream for the Database
| Recovery Control utility with a ddname of IMS.

CHANGE.PART
Examples of Changing a Partition

This example specifies changes to be made to the partition that is identified by the
DBD and NAME parameters. The high key for the partition is changed, as well as
the name of the randomizer routine. The maximum number of images that DBRC
maintains is 12. In addition, the image copy data sets for the specified DBDS are
kept in RECON for at least 15 days. The partition and the next one will be marked
as needing partition initialization as a result of the change.
//CHGPART JOB
.
.
.
//IMS DD DSN=IMS.DBDLIB,DISP=SHR
...
//SYSIN DD *
CHANGE.PART DBD(DB3) PART(PART3) KEYSTRNG(X'D7C1D9E3D2C5E8') -
RANDOMZR(RNDNAME2) GENMAX(12) RECOVPD(15)
/*
| The following example changes the partition identified by the DBD and PART
| parameters to a DISABLE status.
| //CHGPART JOB
| ...
| //SYSIN DD *
| CHANGE.PART DBD(DB3) PART(PART3) DISABLE
| /*
CHANGE.PRILOG (for OLDS)

Use a CHANGE.PRILOG (for OLDS) command to change information in the RECON
about a PRIOLDS. You cannot change the archive status after an OLDS has been
archived.
CHANGE.PRILOG (for OLDS) Syntax

CHANGE.PRILOG OLDS(ddname)
ARNEEDED AVAIL DSN(name)
ARSCHED UNAVAIL
ARSTART
ARCHIVED

ERROR SSID(name)
NORMAL
Parameters for CHANGE.PRILOG (for OLDS)

OLDS(ddname)
Required parameter you use to specify the OLDS for which the RECON record
is to be changed.
ARNEEDED | ARSCHED | ARSTART | ARCHIVED
Mutually exclusive, optional parameters you use to change the archive status
of an OLDS.
ARNEEDED
Indicates that the OLDS was closed by IMS and needs to be archived.
ARSCHED
Indicates that the GENJCL.ARCHIVE command has been issued for the OLDS.

ARSTART
Indicates that the Log Archive utility is currently archiving the OLDS.
ARCHIVED
Indicates that the OLDS has been archived and is available for reuse.
AVAIL | UNAVAIL
Mutually exclusive, optional parameters you use to change the PRIOLDS to
AVAIL
Indicates that the OLDS contains valid data and can be used as input to
the Log Archive utility.
UNAVAIL
Indicates that the OLDS contains invalid data and should not be used as
input to the Log Archive utility.
DSN(name)
Optional parameter you use to change the name of a primary OLDS. name can
be up to 44 characters long.
ERROR | NORMAL
Mutually exclusive, optional parameters you use to change the specified
PRIOLDS to indicate whether it contains errors.
ERROR
Changes the RECON record to indicate that a specified OLDS contains
errors, so IMS is unable to close the OLDS properly. Close the OLDS before
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 close
the OLDS that is marked in error.
NORMAL
Changes the record of the PRIOLDS, which was previously marked as
containing errors, to indicate that the data set is now available for use as
input to any log utility. When you specify NORMAL for an OLDS, the
record immediately indicates that neither the secondary OLDS nor the
next-OLDS is 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 a
CHANGE.PRILOG RLDS ERROR command, DBRC automatically uses the
corresponding 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 this
time frame fail.
SSID(name)
Optional parameter you use to specify the name of the IMS subsystem that
created the OLDS for which the RECON record is to be changed. The SSID is
an eight—character string consisting of any alphanumeric characters that
represent a valid IMS subsystem identification name.
If you do not specify SSID, DBRC uses the default subsystem identifier in the
RECON header record. Use the INIT.RECON or CHANGE.RECON command to set
the default subsystem identifier in the RECON header record. If you have not
specified a default in the RECON header record, you must specify SSID.

Example of Renaming an OLDS

In 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)

You can use the CHANGE.PRILOG (for RLDS) command to change information in the
RECON about a primary RLDS (or an SLDS that a batch subsystem created). Use
the NOTIFY.PRILOG (for RLDS) command to add a PRILOG record or to add data
set entries to an existing PRILOG record.
With the exception of the GSG name and the gap information, all the information
you can change resides in a data set entry of the PRILOG record. Each
CHANGE.PRILOG command you issue changes only one data set entry. If the log
has multiple data sets, you must use the DSSTART parameter to identify the data
set entry to be changed. (Note that if you are only changing the GSG or the gap
information, 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 tracking
site 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.
CHANGE.PRILOG (for RLDS) Syntax

CHANGE.PRILOG RLDS STARTIME(time_stamp)
DSN(name)

, ,
CHKPTCT( value ) CHKPTID( chkptid )

DSSTART(time_stamp) ERROR FILESEQ(value) GAP( ON )
NORMAL OFF

GSG(gsgname) , ,
NEWTIME( time_stamp ) NEWVOL( volser )

, PREVGAP( ON )
OFF
OLDVOL( volser )


, 3400
UNIT( unittype )
RUNTIMES( time_stamp )

,
VOLLIST( volser )
Parameters for CHANGE.PRILOG (for RLDS)

RLDS
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 PRILOG
record that is to be changed. The time stamp must be in standard form (see
“Standard Time Stamp Format” on page 126).
DSN(name)
Optional parameter you use to change data set name. name can be up to 44
characters.
CHKPTCT(value)
Optional parameter you use to change the number of checkpoints completed
on each volume of the data set. Specify a value for each volume designated in
the OLDVOL or NEWVOL parameters. If OLDVOL is specified without
NEWVOL, the number of values for CHKPTCT equals the number of volume
serial numbers that appear with OLDVOL. If NEWVOL is specified, the
number of values for CHKPTCT equals the number of volume serial numbers
that appear in 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 active
PST on each volume of the data set. Specify one checkpoint ID for each
volume listed in OLDVOL or NEWVOL. If OLDVOL is specified without
NEWVOL, the number of checkpoint IDs equals the number of volumes listed
in OLDVOL. If NEWVOL is specified, the number of checkpoint IDs equals the
number of volumes listed in NEWVOL.
The checkpoint ID must be in standard form for a time stamp (see “Standard
Time Stamp Format” on page 126). 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 be
changed. The DSSTART parameter is required if the PRILOG has multiple data
set entries; it is optional if the PRILOG has only one data set entry. The time
stamp must be in standard form (see “Standard Time Stamp Format” on page
126).
ERROR | NORMAL
Mutually exclusive, optional parameters you use to change the data set entry
to indicate whether it contains errors.

ERROR
changes the data set to indicate that it contains errors and should not be
used as input to any DBRC-controlled run of a recovery utility.
NORMAL
changes a data set which was previously marked as containing errors to
indicate 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 you substitute 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 a
tracking PRILOG record.
GSG(gsgname)
Optional parameter you use to change the global service group (GSG) name in
the PRILOG record.
NEWTIME(time_stamp)
Optional parameter you use to change the stop times of any but the last
volume of the data set. If you specify NEWTIME, you must also specify
OLDVOL and NEWVOL. The parameter sets NEWTIME OLDVOL NEWVOL
and RUNTIMES VOLLIST are mutually exclusive.
If you specify NEWTIME, you must specify one less time stamp than the
number of volume serial numbers specified in NEWVOL. This is because the
stop time of the last volume specified in NEWVOL cannot be changed with
this command. (See “NOTIFY.PRILOG (for RLDS)” on page 321 to see how to
specify the stop time of the final volume.) Each time stamp is used as the
volume stop time of the corresponding volume serial number specified by
NEWVOL. If not specified, the stop time of the new volume is the same as the
stop 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 stop
time of the volume immediately preceding the changed volumes. Each time
126).
NEWVOL(volser)
Optional parameter you use to change the volume serial number of one or
more volumes of the data set. If you specify NEWVOL, you must also specify
OLDVOL.
The volume serial numbers that you specify in NEWVOL replaces the
corresponding volume serial numbers specified in the OLDVOL parameter. You
do not need to specify the same number of volume serial numbers in
NEWVOL and OLDVOL. You cannot specify a volume serial number in
NEWVOL that is the same as one that 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 serial
numbers of the volumes.

OLDVOL(volser)
more volumes of the data set. If you specify OLDVOL, you must also specify
NEWVOL, CHKPTCT, or CHKPTID.
The volume serial numbers you specify are those of the volumes being
changed. Each volume serial number specified in OLDVOL must match a
volume serial number in the PRILOG record.
PREVGAP(ON | OFF)
Optional parameter you use to set (ON) or reset (OFF) the PREV-GAP flag in a
tracking PRILOG record.
RUNTIMES(time_stamp)
volume of the data set. This parameter is provided for compatibility with
previous releases of DBRC. Use NEWTIME OLDVOL NEWVOL to change the
stop times of log volumes. If you do specify RUNTIMES, you must also specify
VOLLIST. The following parameter sets are mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
You can specify up to 255 time stamps on the RUNTIMES parameter. Each
time stamp must be in standard form (see “Standard Time Stamp Format” on
page 126).
Each time stamp in the variable field must correspond to a volume in the
variable field of the VOLLIST parameter. The variable fields of the RUNTIMES
and VOLLIST keywords must each contain the same number of entries. Each
time stamp in the variable field of the RUNTIMES parameter must be greater
than the previous time stamp.
The first time stamp in the variable field of the RUNTIMES parameter must be
greater than the time stamp specified for the STARTIME parameter. The last
time stamp in the variable field of the RUNTIMES parameter must be equal to
the stop time of the corresponding primary RLDS as specified in the record
being changed. You cannot use this command to change the stop time of the
primary RLDS. For information about closing open recovery logs, see
“NOTIFY.PRILOG (for RLDS)” on page 321.
Optional parameter you use to change the unit type of the device on which the
data 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 numbers
of the volumes that contain the data set. This parameter is provided for
compatibility with previous releases of DBRC. Use the new parameter set,
NEWTIME, OLDVOL, and NEWVOL to change the volume serial numbers of
volumes in the data set.
If you specify the VOLLIST parameter, you must also specify the RUNTIMES
parameter. See the description of the RUNTIMES parameter under “Parameters
for CHANGE.PRILOG (for RLDS)” on page 172 for an explanation of how the
two parameters interact. The following parameter sets are mutually exclusive:
v NEWTIME

v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
Examples of Using the CHANGE.PRILOG (for RLDS) Command

Here are some examples of using the CHANGE.PRILOG (for RLDS) command.
Example of Changing Volume Serial Numbers: In this example, some volume

serial numbers are changed for a log which contains a single data set. The example
PRILOG record in RECON has six volumes (VOL001, VOL002, VOL003, VOL004,
VOL005, and VOL006) and a start time of 842331243299. The serial numbers of the
third and fourth volumes can be changed 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 Errors: In 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)

You can use the CHANGE.PRILOG (for SLDS) command to change information in the
RECON about a primary SLDS for an online system. You can use the
CHANGE.PRILOG (for TSLDS) command to change information in the RECON about a
primary SLDS for an RSR tracking subsystem. Use CHANGE.PRILOG (for RLDS) to
change information about an SLDS that a batch subsystem created, because DBRC
considers such data to be an RLDS. Use the NOTIFY.PRILOG (for SLDS) command to
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 in
a data set entry of the PRISLD record. Each CHANGE.PRILOG command you
issue changes only one data set entry. If the log has multiple data sets, you must
use the DSSTART parameter to identify the data set entry to be changed. (Note
that if you are only changing the GSG, you must still specify DSSTART if the log
has more than one data set.)
If the PRISLD record represents log data that was received by an RSR tracking site
from an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,
CHANGE.PRILOG (for SLDS and TSLDS) Syntax

CHANGE.PRILOG SLDS STARTIME(time_stamp)
TSLDS DSN(name)


, ,

DSSTART(time_stamp) ERROR FILESEQ(value) GSG(gsgname)
NORMAL

, ,

, , SSID(name)
OLDVOL( volser ) RUNTIMES( time_stamp )

3400 ,
UNIT( unittype )
VOLLIST( volser )
Parameters for CHANGE.PRILOG (for SLDS and TSLDS)

SLDS
Required parameter you use to specify that an PRISLD record is to be changed.
TSLDS
Required parameter you use to specify that a PRITSLDS record is to be
changed at an RSR tracking subsystem. If you do not specify SLDS or TSLDS,
the default is RLDS.
Required parameter you use to specify the starting time stamp of the PRISLD
DSN(name)
characters.
CHKPTCT(value)
CHKPTID(chkptid)

DSSTART(time_stamp)
is a parameter you use to specify the starting time of the data set entry to be
changed. The DSSTART parameter is required if the PRISLD or PRITSLDS has
multiple data set entries. The parameter is optional if the PRISLD or PRITSLDS
has only one data set entry. The time stamp must be in standard form (see
ERROR | NORMAL
ERROR
is used to change the data set entry to indicate that it contains errors.
NORMAL
is used to change a data set entry which was previously marked as
containing errors to indicate that it is normal.
FILESEQ(value)
9999.
GSG(gsgname)
the PRISLD record. GSG cannot be specified for PRITSLDS records.
NEWTIME(time_stamp)
volume of the data set. When you specify NEWTIME, you must also specify
OLDVOL and NEWVOL. The parameter sets, NEWTIME OLDVOL NEWVOL
and RUNTIMES VOLLIST, are mutually exclusive.
When you specify NEWTIME, you must specify one less time stamp than the
this command. (See “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 326 to
learn how to specify the stop time of the final volume.) Each time stamp is
used as the volume stop time of the corresponding volume serial number
specified by NEWVOL. If not specified, the stop time of the new volume is the
same as the stop time of the last—specified old volume.
time of the volume prior to the changed volumes. Each time stamp must be in
standard form (see “Standard Time Stamp Format” on page 126).
NEWVOL(volser)
more volumes of the data set. When you specify NEWVOL, you must also
specify OLDVOL.

The volume serial numbers you specify in NEWVOL replace the corresponding
volume serial numbers specified in the OLDVOL parameter. You do not need
to specify the same number of volume serial numbers in NEWVOL and
OLDVOL. You cannot specify a volume serial number in NEWVOL that is the
same as one that already exists in the PRISLD or PRITSLDS record.
Use the NEWTIME parameter if you want to change the time stamps as well
as the serial numbers of the volumes.
OLDVOL(volser)
more volumes of the primary SLDS or TSLDS. When you specify OLDVOL,
you must also specify NEWVOL, CHKPTCT, or CHKPTID (all described
above).
The volume serial numbers you specify are those of the volumes to be
changed. Each volume serial number specified must match a volume serial
number in the PRISLD or PRITSLDS record.
previous releases of DBRC. Use the NEWTIME, OLDVOL, and NEWVOL
parameters to change the stop times of log volumes. If you do specify
RUNTIMES, you must also specify VOLLIST. The following parameter sets are
mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
time stamp must be in standard form. (See “Standard Time Stamp Format” on
page 126).
the stop time of the corresponding primary SLDS or TSLDS as specified in the
record being changed. You cannot use this command to change the stop time
of the primary SLDS or TSLDS. For information about closing open system
logs, see “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 326.
SSID(name)
created the SLDS or TSLDS for which the RECON record is to be changed.
The SSID is an eight-character string consisting of any alphanumeric characters
that describe a valid IMS subsystem identification name. If you do not specify
SSID, DBRC uses the default subsystem identifier in the RECON header

record. Use the INIT.RECON or CHANGE.RECON command to set the default

subsystem identifier in the RECON header record. If you have not specified a
default in the RECON header record, you must specify SSID.
VOLLIST(volser)
compatibility with previous releases of DBRC. Use the NEWTIME, OLDVOL,
and NEWVOL parameters to change the volume serial numbers of volumes in
the data set.
parameter. See the above description of the RUNTIMES parameter for an
explanation of how the two parameters interact. The following parameter sets
are mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
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 Time: In this example,
some volume serial numbers and a volume stop time for a log which contains a
single data set. The example PRISLD record in RECON has a start time of
832331243299 and six volumes (VOL001, VOL002, VOL003, VOL004, VOL005, and
VOL006). The fourth volume has been copied to new volumes VOL007 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 Normal: In 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
Use a CHANGE.RECON command to update options in the RECON status record.

CHANGE.RECON
CHANGE.RECON Syntax
| CHANGE.RECON
| CATDS CDSLID(value)
NOCATDS
|
| CMDAUTH( SAF ,safhlq ) DASDUNIT(unittype)
EXIT
BOTH
NONE
|
| DUAL FORCER NOCHECK IMSPLEX(imsplex_name)
REPLACE(RECONn) NOFORCER CHECK17 NOPLEX
CHECK44
|
| LISTDL LOGALERT( dsnum,volnum ) LOGRET('time_interval')
NOLISTDL
|
| MINVERS( '7.1' ) REORGV SSID(name)
'8.1' NOREORGV
'9.1'
|
| SIZALERT(dsum,volnum,percent) STARTNEW TAPEUNIT(unittype)
NONEW
|
| TRACEON ,
TRACEOFF
TIMEZONE( (label , ) )
(1)
offset
|
| TIMEZIN( offset_rep,duration ) TIMEFMT(sublist) UPGRADE
|
Notes:
1 The offset subparameter of the TIMEZONE parameter must be omitted in
order to delete an entry.
Parameters for CHANGE.RECON

CATDS | NOCATDS
Mutually exclusive, optional parameters you use to modify the status of
whether image copy, change accumulation, and log data sets are cataloged.
CATDS
| Specifies that these data sets are cataloged or SMS-managed. If the data set
| is allocated by the catalog and the CATDS option is used, DBRC bypasses
| volume serial and file sequence verification for the data set.
| For the CATDS option to be effective, the data set must be cataloged, and
| VOLSER information for the data set must be omitted from the JCL. If the
| data set is cataloged, CATDS is specified, and VOLSER information is
| included in the JCL, DBRC ignores CATDS and allocates the data set by
| the JCL. Normal VOLSER and file sequence checking occurs.

CHANGE.RECON
| If the data set is not cataloged, CATDS is not effective, and DBRC allocates
| the data set by the JCL, with VOLSER and file sequence checking.
| If log data sets are SMS-managed, select the CATDS option and remove the
| %LOGVOLS keyword from skeletal JCL member CAJCL.
| Attention: The CATDS option affects restart of IMS from SLDS data sets.
| Since the CATDS option indicates the SLDS are under the control of a
| catalog management system, the VOLSER is not passed back to IMS for
| data set allocation. If the SLDS data sets are not cataloged, IMS restart fails.
NOCATDS
Specifies that these data sets, regardless of their cataloged status, are not to
be treated as cataloged. In addition to data set name checking, DBRC
verifies that the volume serial and file sequence numbers specified in the
JCL are the same as the information recorded in the RECON.
| CDSLID(value)
| CDSLID sets the cross-DBRC service level ID in the RECON data set. The
| service level ID indicates that the maintenance corresponding to the given
| value has been applied to all systems that will be accessing this RECON data
| set.
| Occasionally, maintenance must be applied to all systems that access the same
| RECON data set before you enable that maintenance. The ++HOLD card
| associated with the maintenance will indicate the need to issue the
| CHANGE.RECON CDSLID() command.
| This command is used to enable the function provided by the maintenance
| after the maintenance has been applied to all the systems. The value to specify
| on the command will be indicated in the ++HOLD card.
| After the cross-DBRC service level ID is set, all maintenance related to any
| service level ID less than or equal to the value set will be activated. If, after
| enabling some maintenance, you find that a system does not yet have the
| maintenance applied, to deactivate the enabled function specify a value less
| than the enabling service level ID. For example if service level ID 5 was set in
| the RECON data set, issuing a CHANGE.RECON CDSLID(3) command would
| deactive functions associated with IDs 4 and 5.
| The following table describes the maintenance that is associated with a
| particular service level ID:
| Table 12. Service Level IDs and Associated Required Maintenance
| Service level ID Associated maintenance
| 1 v PQ98438 (for IMS V7)
| v PQ98654 (for IMS V8)
| v PQ98655 (for IMS V9)
|
| CMDAUTH(SAF,safhlq | EXIT,safhlq | BOTH,safhlq | NONE)
Optional parameter you use to specify whether DBRC command authorization
is to be performed.
Specification of this parameter will result in command authorization being
performed using the specified command authorization setting. However, in
order to turn off command authorization (specifying NONE), you must be
authorized under the current command authorization setting.

CHANGE.RECON
SAF | EXIT | BOTH | NONE

Mutually exclusive subparameters you use to specify your DBRC
authorization option.
SAF
Specifies that a security product is to be called for command
authorization.
EXIT
Specifies that the DBRC Command Authorization Exit (DSPDCAX0) is
to be called for command authorization.
BOTH
Specifies that a security product and the DBRC Command
Authorization Exit (DSPDCAX0) are to be called for command
authorization. The security product is called first, then DSPDCAX0.
safhlq
High level qualifier of the resource name used to determine command
authorization. safhlq must be specified with SAF, EXIT, or BOTH.
safhlq is a name up to eight alphanumeric characters in length.
NOTE: If you simply want to change your high level qualifier, specify
your current command authorization option with the new safhlq. The
profiles with the new qualifier must exist before entering the
command. Create the new profiles or rename the old ones.
NONE
Specifies that command authorization is to be skipped.
DASDUNIT(unittype)
Optional parameter you use to change the unit type of the DASD device that
holds the records for log data sets. The unit type can be up to eight
DUAL | REPLACE(RECONn)
Mutually exclusive, optional parameters you use to reestablish dual mode or to
replace an active RECON data set with the spare RECON:
DUAL
Causes DBRC to enter dual-RECON mode. If DBRC is already using two
RECONs, the dual parameter is ignored. If DBRC is using one RECON, it
attempts to use a spare RECON. If no spare RECON is available, dual
mode is not entered; however, any other optional parameters are
processed.
You are not required to use the DUAL parameter to cause DBRC to enter
dual-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, it
automatically reenters dual-RECON mode as soon as it becomes aware of
the existence of a spare RECON. However, in installations that use DBRC
for log control only, it can be some time before DBRC becomes aware of a
recently created spare RECON. Use the CHANGE.RECON command with the
DUAL parameter to cause DBRC to enter dual-RECON mode immediately.
REPLACE
Causes DBRC to replace an active RECON with a spare RECON. When
you specify this parameter, you can reorganize the RECON data sets
online.

CHANGE.RECON
Related Reading: See Chapter 4, “Initializing and Maintaining the

RECON Data Set,” on page 55 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 active
or if no spare RECON is available, the replace does not take place;
however, any other optional parameters that are specified on the command
are executed.
FORCER | NOFORCER
Mutually exclusive, optional parameters you use to specify whether all
databases must be registered in RECON.
FORCER
Specifies that all databases must be registered in RECON. If a job tries to
access an unregistered database, the database authorization call from IMS
to DBRC fails.
NOFORCER
Specifies that databases do not have to be registered in RECON.
DBRC checks this parameter during initialization and it remains in effect for as
long as the subsystem runs. If you change this parameter while the control
region is active, the change does not take effect until restart or initialization,
although the change appears in a listing of the RECON.
NOCHECK | CHECK17 | CHECK44
Mutually exclusive, optional parameters you use to change the type of
comparison of log data set names that is done by DBRC.
NOCHECK
Specifies that the data set name you specify as input to DBRC has a new
high-level qualifier and is longer than 17 characters. With NOCHECK,
DBRC does not compare the log data set name that is recorded in RECON
with the name on the appropriate DD statement.
CHECK17
Verifies that the last 17 characters of a log data set name are consistent
with RECON. If the name in RECON does not match the name on the
appropriate DD statement, the utility stops.
CHECK44
Verifies 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 log
DD statement, the utility stops.
IMSPLEX(imsplex_name) | NOPLEX
Mutually exclusive, optional parameters you use to change the IMSplex name
associated with the RECON. CHANGE.RECON cannot be used to set an initial
IMSplex name in the RECON.
| There can be no other DBRC instances that are registered to SCI accessing the
| RECON when this command is processed. The DBRC instance processing the
| command must be using the IMSplex name that is currently saved in the
| RECON.
The IMSplex name in the RECON should only be changed when your SCI
registration exit, DSPSCIX0, is changed to return the new IMSplex name.

CHANGE.RECON
Restriction: CHANGE.RECON IMSPLEX and CHANGE.RECON NOPLEX can only be

issued from the batch command utility. You cannot issue these commands from
an online IMS.
IMSPLEX(imsplex_name)
Specifies the new IMSplex name. The IMSplex name can be up to 5
NOPLEX
Specifies that no IMSplex name is to be associated with the RECON.
There is no default for this parameter. If neither is specified, the current setting
is unchanged.
Note: If DSPSCIX0 is not found, DBRC will behave as though the sample exit
were used. So, if the IMSPLEX parameter is not used, DBRC will
assume that RECON Automatic Loss Notification is inactive. When the
IMSPLEX parameter is used, DBRC will use its value to register with
SCI.
LISTDL | NOLISTDL
Mutually exclusive, optional parameters you use to specify whether data set
names that are deleted from the RECON (by the DELETE.LOG command or by
an archive job log compression) are listed in the job output. The setting
specified on this command can be overridden by the DELETE.LOG command.
There is no way to override the setting for log compression during an archive
job.
LISTDL
Specifies that deleted data set names are to be listed in the job output.
NOLISTDL
Specifies 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 setting
is unchanged.
LOGALERT(dsnum,volnum)
Optional parameter you use to define the threshold that triggers the
DSP0287W message. Message DSP0287W displays when you just have time to
shut down an online IMS subsystem before it terminates abnormally because
the PRILOG record size exceeds the 16M record size maximum.
dsnum,volnum
These values apply only to PRILOG-family records. The message is
issued 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 to
successfully archive all OLDSs currently needing to be archived
(including the new one) plus dsnum more, assuming each OLDS uses
volnum volumes.
The values that you enter, based on your knowledge of the rate at
which the subsystem normally fills OLDSs, should be calculated to
give you sufficient time to effect a normal shutdown of the online IMS
subsystem.
All values must be supplied. A zero (0) in any position means that the existing
value in the RECON record is not to be changed.

CHANGE.RECON
The default values in a new RECON or one that has been upgraded from an
earlier 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 log
becomes inactive after it is opened. (It is then eligible to be deleted.)
v The time interval is a partial, punctuated time stamp representing a time
interval (days, hours, minutes, seconds and tenths of a second) instead of
date and time. The time stamp for this command follows the format
described in “Standard Time Stamp Format” on page 126 except that the
year subparameter element is omitted. Valid intervals range from a tenth of
a second to 365 days.
Because the time interval is treated as a time stamp, message DSP0106I can
be 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')
The following shows two different formats for equivalent time stamp
specifications. Both are valid.
LOGRET(030) LOGRET('030') = 30 days
LOGRET('010 12,30') LOGRET('010 12:30') x= 10 days, 12 hours, 30 minutes
Related Reading: See “DELETE.LOG (for RLDS and SLDS)” on page 212 for
more information on deleting inactive logs.
| MINVERS('7.1' | '8.1' | '9.1')
| Optional parameter that you use to specify the lowest version of IMS allowed
| to sign on. This keyword cannot be set to a higher IMS release if any
| subsystems with a lower version of IMS are currently signed on to DBRC.
| When the UPGRADE keyword is specified on a CHANGE.RECON command and
| the MINVERS value is less than '7.1', the MINVERS value is set to a default of
| '7.1' in the new RECON.
| Note: The IMS Version 9 format for the MINVERS keyword includes a period.
| DBRC considers this a special character and requires it to be enclosed in
| single quotes. The format from earlier versions (71 | 81 | 91) is also
| accepted for compatibility.
| REORGV | NOREORGV
| Mutually exclusive, optional parameters you use to modify the HALDB
| partition reorganization number verification. A CHANGE command with these
| parameters is allowed while databases are currently authorized to other
| subsystems.
| REORGV
| Specifies that HALDB partition reorganization number verification is
| enabled. The RECON will store the reorganization number for each
| partition to prevent the reorganization number from being regressed, or
| incremented by more than one. After a CHANGE.RECON REORGV
| command is issued, the partition reorganization number in each partition
| record is set to zeros.
| Note: The MINVERS value must be a minimum of 8.1 in order to set

| REORGV.

CHANGE.RECON
| NOREORGV
| disabled. Any requests to store, update or verify the reorganization number
| will be ignored.
SSID(name)
Optional parameter you use to change the name of the IMS subsystem to be
used 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 that
comprise a valid IMS subsystem identification name.
SIZALERT(dsnum,volnum,percent)
Optional parameter you use to define thresholds that trigger messages to warn
you that a record has grown unusually large. The decimal threshold values
that you supply for SIZALERT are:
dsnum,volnum
These values apply only to PRILOG-family records. The message
DSP0387W 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 been archived,
there will no longer be room in the record for dsnum data set entries of
volnum volumes each, or the record size will exceed percent percent of
the 16M record size maximum.
percent
This value applies to all records. The threshold is reached when a record
exceeding percent percentage of the 16MB record size maximum.
STARTNEW | NONEW
Mutually exclusive, optional parameters you use to specify whether new jobs
are to be started when only one RECON is available.
STARTNEW
Specifies that new jobs are to be started.
NONEW
Specifies that new jobs are not to be started.
TAPEUNIT(unittype)
Optional parameter you use to specify the unit type of the tape device that
holds the records for log data sets. The unit type can be up to eight
TRACEON | TRACEOFF
Mutually exclusive, optional parameters you use to specify whether to start or
stop external tracing.

CHANGE.RECON
Note: If the CHANGE.RECON command is issued in a batch job, the RECON

header record will be changed to show the requested status (TRACEON
or TRACEOFF), however, the actual TRACE status will not be changed
for any active IMS system.
If the CHANGE.RECON command is issued as a command in a control

region (/RMCHANGE DBRC='RECON TRACEON | TRACEOFF'), the trace status
and the RECON header record will be changed to show the requested
status (TRACEON or TRACEOFF) for this control region. However, the
actual TRACE status will not be changed for any other active IMS
system (batch or online).
TRACEON
Starts external tracing. If you specify this parameter, the specified
Generalized Trace Facility (GTF) must be active for USR-type records.
TRACEOFF
Stops external tracing. If you specify this parameter, DBRC only does
internal tracing.
TIMEZONE((label,offset),(label,offset))
Optional parameter that alters the time zone label table. This parameter is used
to define one or more symbolic time zone labels. Because most people do not
readily associate a numeric offset with a time zone, TIMEZONE allows you to
define 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 is
composed of a label and an offset.
Related Reading: See “Suggestions for Time Zone Label Table Management”
on page 189 for more information about the TIMEZONE parameter.
label
An alphanumeric value of up to five characters, the first of which must be
alphabetic. Lowercase characters are translated to upper case.
offset
A signed-decimal value in the form of ± [h]h[:mm] that meets the
requirements of a valid time stamp offset. See “Standard Time Stamp
Format” on page 126 for a description of valid offset formats. The offset is
the value that, when added to UTC, gives local time. For example, the
value 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 as
follows:
v Adding an entry to the stored table is accomplished when an input list
entry contains both a label that does not exist in the RECON and a valid
offset value.
v Replacing an entry to the stored table is accomplished when the input
entry contains both a label that matches an existing label in the table and
a valid offset value.
v Deleting an entry to the stored table is accomplished when the input
entry is a label that matches an existing label in the table and no offset
value was specified. If the offset is omitted, and the label is not found in
the table, the table is not altered.

CHANGE.RECON
The labels in the table must be unique. Information about the use of labels
versus offsets is presented in “Suggestions for Time Zone Label Table
Management” on page 189.
TIMEZIN(offset_rep [,duration])
Optional parameter you use to define a default time zone value for time
stamps that are entered without time zone information on subsequent DBRC
commands.
offset_rep
The default time zone value. It may be one of the following choices:
label
A time zone label that has been previously defined using the
TIMEZONE parameter.
offset
A numeric offset value in the same form as defined above for the
TIMEZONE parameter.
%SYS
A keyword used to designate that the offset is to be derived from the
current offset found in the z/OS CVT control block. This is the initial
default for DBRC.
duration
Specifies the duration of the offset_rep choice.
PERM
Indicates that the label or offset default is to be in effect for any
subsequent DBRC command running with the same RECON.
TEMP
Indicates that the label or offset default is in effect only for the job in
which the command is entered.
TIMEFMT(sublist)
Optional parameter you use to define the form in which time stamps appear
from DBRC in messages, displays, and listings. See “Standard Time Stamp
Format” on page 126 for examples of the different output forms. The five
values are positional. Each is optional and can be omitted by including only
the comma.
The format of the TIMEFMT parameter sublist is presented in detail in
“TIMEFMT Parameter” on page 127.
UPGRADE
| Optional parameter that you use to upgrade all IMS Version 7 and IMS Version
| 8 RECON records to an IMS Version 9 level. You do not need to shut down
| other IMS subsystems that share the RECON, although they might have to
| wait for the command to complete. When UPGRADE is specified, a default of
| 71 is set for the MINVERS value in the new RECON.
| Restriction: You can issue the CHANGE.RECON UPGRADE command only in the
| batch command utility. You cannot issue it from an online IMS.
| CHANGE.RECON UPGRADE upgrades the RECON in two stages: first, Copy 1 and
| then Copy 2.
| Message DSP0250l indicates the beginning of the first stage. Any failure during
| this stage causes DBRC to reconfigure the RECONs, discarding Copy 1. If a
| failure occurs during the first stage, you need to rerun the CHANGE.RECON
| UPGRADE command.

CHANGE.RECON
| After successful completion of the first stage, message DSP0251l indicates that
| the second stage is beginning. Any failure during this stage causes DBRC to
| reconfigure the RECONs, discarding Copy 2. However, if there is a failure
| during the second stage, you do not need to rerun the CHANGE.RECON UPGRADE
| command.
| You can use the CHANGE.RECON UPGRADE command in either nonconcurrent or
| concurrent mode. The mode is determined by the environment at the time you
| issue the command.
| Nonconcurrent mode
| No other jobs are currently accessing the RECON.
| Before issuing the CHANGE.RECON UPGRADE command, you might want to
| create a backup copy of the RECON in case the upgrade and the
| RECON recovery procedures fail, which can happen if you have not
| allocated two RECONs and a spare.
| Concurrent mode
| Other jobs are currently accessing the RECON. These jobs can be either
| Version 7 or Version 8 and must have the respective Version 9 SPE
| applied. Two RECONs plus a spare must be allocated for a concurrent
| upgrade.
| When an upgrade is performed, an existing HALDB is marked (in the RECON)
| to indicate that it is not capable of being reorganized online with the HALDB
| Online Reorganization function. To enable the HALDB for online
| reorganization, use the CHANGE.DB DBD(HALDB_master)OLRCAP command.
Suggestions for Time Zone Label Table Management

The same offset should not be designated by more than one label because DBRC
always uses the first occurrence in the table when outputting a time stamp.
The practicality of using the label format is affected by the scope of the IMS
installation. For those operating solely in a single time zone, use of labels
eliminates the need for the operator to know the exact offset to UTC at all times
during the year. For multiple time zone operation, the use of offsets rather than
labels, is suggested (though not mandatory). The time zone label table may not be
practical if offsets are not unique from one zone to the next when daylight saving
time adjustments are taken into account. Changing the table when daylight saving
time switches are made would add to the confusion, so, in that case, use numeric
offset values for cross time zone operation.
Example of Updating the RECON Header Record

In 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.SECLOG (for OLDS)

Use a CHANGE.SECLOG (for OLDS) command to change information in RECON about
a secondary OLDS.

CHANGE.SECLOG (for OLDS) Syntax

CHANGE.SECLOG OLDS(ddname)
AVAIL DSN(name) ERROR
UNAVAIL NORMAL

SSID(name)
Parameters for CHANGE.SECLOG (for OLDS)

OLDS(ddname)
Required parameter you use to specify the OLDS for which the RECON record
is to be changed. Failure to specify this parameter results in an RLDS being
changed.
AVAIL | UNAVAIL
Mutually exclusive, optional parameters you use to change the SECOLDS to
AVAIL
Indicates that the OLDS contains valid data and that it can be used as
UNAVAIL
Indicates that the OLDS contains invalid data and it should not be used as
DSN(name)
Optional parameter you use to change the name of a secondary OLDS. The
name you substitute in the variable field can be up to 44 characters long.
ERROR | NORMAL
Mutually exclusive, optional parameters you use to change the specified
SECOLDS record to indicate whether it contains errors.
ERROR
Changes the RECON record to indicate that a specified OLDS contains
errors, so IMS is unable to close the OLDS properly. The OLDS must be
closed before it can be used as input to the Log Archive utility.
When you use dual logging, you use ERROR to change a specified
SECOLDS record to indicate that it contains errors. The subsystem uses the
data in the error-free OLDS to close the OLDS that is marked ERROR.
NORMAL
Changes the SECOLDS record, which was previously marked as containing
errors, to indicate that the data set is now available for use as input to any
log utility. When you specify NORMAL for a secondary OLDS, the record
immediately indicates that the next primary OLDS is no longer needed in
order to close the corresponding primary OLDS.
SSID(name)
created the OLDS for which the RECON record is to be changed.
that comprise a valid IMS subsystem identification name. If you do not specify

Example Showing a SECOLDS Error

In this example, a SECOLDS that IMS online subsystem IMSA created is known to
be in error.
//CHGSECLG JOB
.
.
.
//SYSIN DD *
CHANGE.SECLOG OLDS(DFSOLS02) -
SSID(IMSA) ERROR
/*
CHANGE.SECLOG (for RLDS)

You can use the CHANGE.SECLOG (for RLDS) command to change information in the
RECON about a primary RLDS (or an SLDS that a batch subsystem created). Use
the NOTIFY.SECLOG (for RLDS) command to add a SECLOG record or to add data
set entries to an existing SECLOG record.
a data set entry of the SECLOG record. Each CHANGE.SECLOG command you
that if you are only changing the GSG you must still specify DSSTART if the log
If the SECLOG record represents log data that was received by an RSR tracking
site from an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,
CHANGE.SECLOG (for RLDS) Syntax

RLDS
CHANGE.SECLOG STARTIME(time_stamp)
DSN(name)

, ,

DSSTART(time_stamp) ERROR FILESEQ(value) GSG(gsgname)
NORMAL

, ,


, ,
OLDVOL( volser ) RUNTIMES( time_stamp )

3400 ,
UNIT( unittype )
VOLLIST( volser )
Parameters for CHANGE.SECLOG (for RLDS)

RLDS
Is the parameter you can use to specify that a SECLOG record is to be
changed. Since RLDS is the default, if you do not specify a record type as the
first parameter for CHANGE.SECLOG, RLDS is assumed.
Required parameter you use to specify the starting time stamp of the SECLOG
DSN(name)
characters.
CHKPTCT(value)
CHKPTID(chkptid)
DSSTART(time_stamp)
Is a parameter you use to specify the starting time of the data set entry to be
changed. 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. The time
126).
ERROR | NORMAL
ERROR
changes the data set to indicate that it contains errors and should not be
used as input to any DBRC-controlled run of a recovery utility.
NORMAL
changes a data set which was previously marked as containing errors to
indicate that it is now available for use as input to any recovery utility.
FILESEQ(value)
9999.
GSG(gsgname)
the SECLOG record.
NEWTIME(time_stamp)
volume of the data set. If you specify NEWTIME, you must also specify
OLDVOL and NEWVOL. The following parameter sets are mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
If you specify NEWTIME, you must specify one less time stamp than the
this command. (See “NOTIFY.PRILOG (for RLDS)” on page 321 to see how to
specify the stop time of the final volume.) Each time stamp is used as the
volume stop time of the corresponding volume serial number specified by
NEWVOL. If not specified, the stop time of the new volume is the same as the
stop time of the last-specified old volume.
time of the volume immediately preceding the changed volumes. Each time
126).
NEWVOL(volser)
more volumes of the data set. If you specify NEWVOL, you must also specify
OLDVOL (described below).
same as one which already exists in the SECLOG record.

Use the NEWTIME parameter to change the time stamps as well as the serial
numbers of the volumes.
OLDVOL(volser)
more volumes of the data set. If you specify OLDVOL, you must also specify
NEWVOL, CHKPTCT, or CHKPTID.
The volume serial numbers you specify are those of the volumes being
changed. Each volume serial number specified in OLDVOL must match a
volume serial number in the SECLOG record.
parameter set to change the stop times of log volumes. If you do specify
mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
time stamp must be in standard form (see “Standard Time Stamp Format” on
page 126).
the stop time of the corresponding secondary RLDS as specified in the record
being changed. You cannot use this command to change the stop time of the
secondary RLDS. For information about closing open recovery logs, see
“NOTIFY.PRILOG (for RLDS)” on page 321.
VOLLIST(volser)
compatibility with previous releases of DBRC. Use the NEWTIME, OLDVOL,
and NEWVOL parameter set to change the volume serial numbers of volumes
in the data set.
parameter. See the description of the RUNTIMES parameter under “Parameters
for CHANGE.PRILOG (for RLDS)” on page 172 for an explanation of how the
two parameters interact. The following parameter sets are mutually exclusive:
v NEWTIME

v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
Examples of Using CHANGE.SECLOG (for RLDS)

Here are some examples of using the CHANGE.SECLOG (for RLDS) command.
Example of Changing Volume Serial Numbers: In this example, some volume

serial numbers are changed. The example SECLOG record in RECON has one data
set with six volumes (VOL001, VOL002, VOL003, VOL004, VOL005, and VOL006)
and a start time of 832331243299. The serial numbers of the third and fourth
volumes are replaced with three others by the following command:
//CHGSECLG JOB
.
.
.
//SYSIN DD *
CHANGE.SECLOG RLDS STARTIME(832331243299) -
OLDVOL(VOL003,VOL004) -
NEWVOL(VOL007,VOL008,VOL009)
/*
Example of Changing Volume Stop Times: In this example, STARTIME identifies

the SECLOG record and DSSTART identifies its first data set entry, of which the
data set name and the stop times of three volumes 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)

You can use the CHANGE.SECLOG (for SLDS) command to change information in the
RECON about a secondary SLDS for an online system. You can use the
CHANGE.SECLOG (for TSLDS) command to change information in the RECON about a
secondary SLDS for an RSR tracking subsystem. Use CHANGE.SECLOG (for RLDS) to
change information about an SLDS that a batch subsystem created, because DBRC
considers such data to be an RLDS. Use the NOTIFY.SECLOG (for SLDS) command to
add a SECSLD record or to add data set entries to an existing SECSLD record.
a data set entry of the SECSLD record. Each CHANGE.SECLOG command you
that if you are only changing the GSG, you must still specify DSSTART if the log
If the SECSLD record represents log data that was received by an RSR tracking site
from an active IMS subsystem, none of the keywords FILESEQ, NEWTIME,

CHANGE.SECLOG (for SLDS and TSLDS) Syntax

CHANGE.SECLOG SLDS STARTIME(time_stamp)
TSLDS DSN(name)

, , DSSTART(time_stamp)

ERROR FILESEQ(value) GSG(gsgname) ,
NORMAL
NEWTIME( time_stamp )

, , ,
NEWVOL( volser ) OLDVOL( volser ) RUNTIMES( time_stamp )

SSID(name) 3400 ,
UNIT( unittype )
VOLLIST( volser )
Parameters for CHANGE.SECLOG (for SLDS and TSLDS)

SLDS
Required parameter you use to specify that an SECSLD record is to be
changed.
TSLDS
Required parameter you use to specify that a SECTSLDS record is to be
changed at an RSR tracking subsystem. If you do not specify SLDS or TSLDS,
the default is RLDS.
Required parameter you use to specify the starting time stamp of the SECSLD
DSN(name)
characters.
CHKPTCT(value)
CHKPTID(chkptid)

DSSTART(time_stamp)
Is a parameter you use to specify the starting time of the data set entry to be
changed. The DSSTART parameter is required if the SECSLD or SECTSLDS has
multiple data set entries. The parameter is optional if the SECSLD or
SECTSLDS has only one data set entry. The time stamp must be in standard
form (see “Standard Time Stamp Format” on page 126).
ERROR | NORMAL
ERROR
Is used to change the data set entry to indicate that it contains errors.
NORMAL
Is used to change a data set entry which was previously marked as
containing errors to indicate that it is normal.
FILESEQ(value)
9999.
GSG(gsgname)
the SECSLD record. GSG cannot be specified for SECTSLDS records.
NEWTIME(time_stamp)
volume of the data set. When you specify NEWTIME, you must also specify
OLDVOL and NEWVOL. The following parameter sets are mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
When you specify NEWTIME, you must specify one less time stamp than the
this command. (See “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 326 to
learn how to specify the stop time of the final volume.) Each time stamp is
used as the volume stop time of the corresponding volume serial number
specified by NEWVOL. If not specified, the stop time of the new volume is the
same as the stop time of the last—specified old volume.
time of the volume prior to the changed volumes. Each time stamp must be in
standard form (see “Standard Time Stamp Format” on page 126).

NEWVOL(volser)
more volumes of the data set. When you specify NEWVOL, you must also
specify OLDVOL.
same as one that already exists in the SECSLD or SECTSLDS record.
Use the NEWTIME parameter if you want to change the time stamps as well
as the serial numbers of the volumes.
OLDVOL(volser)
more volumes of the secondary SLDS or TSLDS. When you specify OLDVOL,
you must also specify NEWVOL, CHKPTCT, or CHKPTID (all described
above).
The volume serial numbers you specify are those of the volumes to be
changed. Each volume serial number specified must match a volume serial
number in the SECSLD or SECTSLDS record.
parameter set to change the stop times of log volumes. If you do specify
mutually exclusive:
v NEWTIME
v OLDVOL
v NEWVOL
v RUNTIMES
v VOLLIST
time stamp must be in standard form. (See “Standard Time Stamp Format” on
page 126).
the stop time of the corresponding secondary SLDS or TSLDS as specified in
the record being changed. You cannot use this command to change the stop
time of the secondary SLDS or TSLDS. For information about closing open
system logs, see “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 326.

SSID(name)
created the SLDS or TSLDS for which the RECON record is to be changed.
that describe a valid IMS subsystem identification name. If you do not specify
record. Use the INIT.SECLOG or CHANGE.SECLOG command to set the default
VOLLIST(volser)
compatibility with previous releases of DBRC. You should use the new
parameter set, NEWTIME OLDVOL NEWVOL, to change the volume serial
numbers of volumes in the data set.
parameter. See the above description of the RUNTIMES parameter for an
explanation of how the two parameters interact. The parameter sets,
NEWTIME OLDVOL 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 Time: In this example,
some volume serial numbers and a volume stop time of an SECSLD are changed.
The example SECSLD record in RECON has six volumes (VOL001, VOL002,
VOL003, VOL004, VOL005, and VOL006) and a start time of 832331243299. The
fourth volume has been copied to new volumes VOL007 and VOL008 with the
new volume stop time 832331248325 for VOL007. The SECSLD record 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 Normal: In this example, the first
and only data set of a secondary SLDS is being marked as normal.
//CHGPRILG JOB
.
.
.
//SYSIN DD *
CHANGE.SECLOG SLDS STARTIME(840541212120) -
DSSTART(840541212120) NORMAL
/*

CHANGE.SG
CHANGE.SG
Use a CHANGE.SG command to change the role of a service group (SG). The role of a
service group cannot be changed while a subsystem is signed on to its global
service 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 is
assigned the complementary attributes of the SG that is named in the command.
CHANGE.SG Syntax
CHANGE.SG SGNAME(sgname) GSGNAME(gsgname)
ACTIVE LOCAL NORTA
TRACKING NONLOCAL
Parameters for CHANGE.SG

SGNAME(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 | TRACKING
Optional parameter you use to specify the new role of the service group. This
parameter is sometimes referred to as the STATUS parameter.
LOCAL | NONLOCAL
Optional parameter you use to specify whether the service group is local or
nonlocal for this set of RECONs. This parameter is sometimes referred to as
the LOCALE parameter.
NORTA
Optional parameter you use to specify that you do not want to continue a
remote takeover that is currently in progress. This parameter turns off takeover
indicators in the RECON. This parameter is valid for either the active or
tracking subsystem.
When you specify the NORTA parameter, you must specify the appropriate
STATUS parameter (either ACTIVE or TRACKING), and you cannot specify
the LOCALE parameter (LOCAL | NONLOCAL).
If you use NORTA when no remote takeover is in progress, message DSP0144I
is issued. You should wait to receive a takeover-in-progress message before
using NORTA.
Example of Changing the Status of a Service Group

In this example, the Service Group’s role or status is changed to ACTIVE.
//CHGSG
. JOB
.
.
//SYSIN DD *
CHANGE.SG SGNAME() GSGNAME(GSG1) ACTIVE
/*
In this example, SG1 is changed to a tracking role:

CHANGE.SG SGNAME(SG1) GSGNAME(GSG1) TRACKING
In this case, SG2 is automatically changed to an active role.

CHANGE.SUBSYS
CHANGE.SUBSYS
Use a CHANGE.SUBSYS command to modify information that is contained in a
subsystem record in RECON.
CHANGE.SUBSYS Syntax
ALL
CHANGE.SUBSYS
SSID(name) BACKIRLM(name) IRLMID(name) NORMAL
NOBACKUP ABNORMAL

STARTRCV TRACKING
ENDRECOV
Parameters for CHANGE.SUBSYS

SSID(name) | ALL
Optional parameters you use to specify the subsystem you are using. The SSID
is an eight-character string consisting of any alphanumeric characters that
comprise a valid z/OS or IMS subsystem identification name. ALL is the
default, which will process this command for every subsystem that
communicates with the specified Internal Resource Lock Manager (IRLM).
BACKIRLM(name) | NOBACKUP
Mutually exclusive, optional parameters you use to change the specification of
the alternate subsystem.
BACKIRLM
Adds an alternate subsystem IRLM ID to the active subsystem record.
When you specify BACKIRLM, you must also specify IRLMID. DBRC
locates the specified subsystem record and adds or changes the IRLM ID of
the alternate subsystem.
NOBACKUP
Deletes the IRLM ID of the alternate subsystem from the active subsystem
record. This also resets the flags in the subsystem record to indicate that
the alternate subsystem is signed on. This command might be required
prior to restarting the alternate subsystem.
Restriction: You cannot use NORMAL or ABNORMAL, or STARTRCV or

ENDRECOV with this parameter.
IRLMID(name)
Optional parameter you use to specify the name of the IRLM with which the
subsystem is communicating. The IRLMID is a five-character string consisting
of any alphanumeric characters.
Restriction: You cannot change the IRLM ID. Specify the IRLM ID in order to
change processing mode of a subsystem.
NORMAL | ABNORMAL
Mutually exclusive, optional parameters you use to specify the status of the
subsystem.
NORMAL
Specifies that normal processing is to continue for the subsystem.

CHANGE.SUBSYS
ABNORMAL
Indicates that the subsystem has abnormally ended. When ABNORMAL is
specified, DBRC does the following:
v Removes authorization for any databases that have not been updated
but 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 the
subsystem record is deleted.
Restriction: If you specify STARTRCV or ENDRECOV, you cannot specify

ABNORMAL.
STARTRCV | ENDRECOV
Mutually exclusive, optional parameters you use to specify whether a signon
recovery has completed successfully.
STARTRCV
Indicates a signon recovery start.
ENDRECOV
removes authorization for all databases that the specified subsystem
authorized.
If you want to delete all database authorizations from a subsystem, you must
issue the CHANGE.SUBSYS STARTRCV command and then issue the
CHANGE.SUBSYS ENDRECOV command. These two commands simulate the
signon recovery start and signon recovery complete calls.
Recommendation: Do not use this sequence of commands unless an abnormal
end occurred. Otherwise, you remove authorization for the databases that 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.DB
command with the NOBACK parameter is required in order to clear the
remaining subsystem ID from the database record.
TRACKING
Specifies that information about the RSR tracking subsystem is to be changed.
Attention: If you specify TRACKING, do not specify STARTRCV or
ENDRECOV.
Example of Identifying the IRLM

In this example, IRLMID identifies the IRLM that is communicating with the
subsystem identified in the SSID parameter. In addition, ABNORMAL indicates
that this subsystem abnormally ended.
//CHGSBSYS JOB
.
.
.
//SYSIN DD *
CHANGE.SUBSYS IRLMID(IRLM2) SSID(ISM34) ABNORMAL
/*
CHANGE.UIC
Use a CHANGE.UIC command to modify information in the image copy record in
RECON that corresponds to a nonstandard image copy data set.

CHANGE.UIC
CHANGE.UIC Syntax
CHANGE.UIC DBD(name) DDN(name) RECTIME(time_stamp) UDATA('string')
AREA(name)
Parameters for CHANGE.UIC

DBD(name)
Required parameter you use to identify the database name of the DBDS for
which a nonstandard image copy data set exists.
Restrictions for HALDBs: For HALDBs, name specifies the name of a HALDB
partition.
Mutually exclusive, required parameters you use to identify the name of the
DBDS 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 the
nonstandard image copy data set that is to be modified. Use the time stamp
with an adjacent asterisk (*) in a listing of the IMAGE record. The time stamp
must be in standard form (see “Standard Time Stamp Format” on page 126).
UDATA('string')
Required parameter you use to change the user data in the identified image
copy record. string can be up to 80 characters and must appear in single
quotation marks.
Example of Changing the Nonstandard ICDSN in RECON

In this example, information in RECON about the nonstandard image copy data
set identified by the RECTIME parameter is to be changed. The UDATA parameter
specifies the new information that is to be recorded for the specified image copy
data set.
//CHGUIC JOB
.
.
.
//SYSIN DD *
CHANGE.UIC DBD(DBDKSDS1) AREA(AREA003) -
RECTIME(840651010100) -
UDATA('DUMP OF VOLUME VOL001 AT 840651010100')
/*

CHANGE.UIC

Chapter 10. DELETE Commands
Use the DELETE commands to delete information from a RECON.
DELETE Commands In This Chapter

The following is a list of all the DELETE commands:
v “DELETE.ADS”
v “DELETE.ALLOC” on page 206
v “DELETE.BKOUT” on page 207
v “DELETE.CA” on page 207
v “DELETE.CAGRP” on page 208
v “DELETE.DB” on page 208
v “DELETE.DBDS” on page 209
v “DELETE.DBDSGRP” on page 210
v “DELETE.GSG” on page 210
v “DELETE.IC” on page 211
v “DELETE.LOG (for OLDS)” on page 212
v “DELETE.LOG (for RLDS and SLDS)” on page 212
v “DELETE.PART” on page 215
v “DELETE.RECOV” on page 216
v “DELETE.REORG” on page 217
v “DELETE.SG” on page 217
v “DELETE.SUBSYS” on page 218
v “DELETE.UIC” on page 218
DELETE.ADS
Use a DELETE.ADS command to delete an ADS from its associated area in the
RECON record structure. An area can consist of a maximum of seven ADSs. The
ADS 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 the
ADS is in AVAILABLE status. The command can be used if the ADS is in
UNAVAILABLE status, provided that the ADS Create utility is not running.
DELETE.ADS Syntax
DELETE.ADS ADDN(name) AREA(name) DBD(name)
Parameters for DELETE.ADS

ADDN(name)
Required parameter you use to identify the area name of the ADS to be
deleted.
AREA(name)
Required parameter you use to identify the name of the area that contains the
ADS to be deleted.

DELETE.ADS
DBD(name)
Required parameter you use to identify the database name of the area that is
to be deleted.
Example of Deleting an ADS Record

In this example an ADS record is deleted from RECON for the DEDB area that is
identified 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
Use a DELETE.ALLOC command to delete from RECON an allocation record that is
related to a specified DBDS or DEDB area. An allocation record can be deleted
only when it contains a deallocation time or when its associated log has a stop
time. Except for deleting allocation records that precede the oldest image copy data
set 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
a period of time during which you changed the specified DBDS or area can cause a
future recovery to be incorrect.
DELETE.ALLOC Syntax
DELETE.ALLOC DBD(name) DDN(name) RECTIME(time_stamp)
AREA(name)
Parameters for DELETE.ALLOC

DBD(name)
Required parameter you use to identify the database name of the DBDS or area
for which the allocation record is to be deleted.
Restriction for HALDBs: For the DELETE.ALLOC command, name specifies the
name of a HALDB partition.
Mutually exclusive, optional parameters you use to identify the data set
ddname of the DBDS or DEDB area for which the allocation record is to be
deleted.
RECTIME(time_stamp)
Required parameter you use to identify the specific allocation record to be
deleted for a specified DBDS or DEDB area. Use the time stamp with an
adjacent asterisk (*) in a listing of the ALLOC record. The time stamp must be
in standard form (see “Standard Time Stamp Format” on page 126).
Example of Deleting an Allocation Record

In this example, an allocation record is deleted from RECON for the DBDS that is
identified by the DBD and DDN parameters. The RECTIME parameter identifies
the specific allocation record that is to be deleted.

DELETE.ALLOC
//DELALLOC JOB
.
.
.
//SYSIN DD *
DELETE.ALLOC DBD(DBDKSDS1) DDN(DDNKSDS1) -
RECTIME(840231102234)
/*
DELETE.BKOUT
Use a DELETE.BKOUT command to delete backout records from the RECON.
Use this command, for example, following the successful restore of a recent image
copy. The backout information held in RECON at the time of the copy is
meaningless, but DBRC is not aware of this fact, and DBRC does not delete the
backout records automatically.
Attention: Use the DELETE.BKOUT command with extreme caution. It deletes all
backout information for a subsystem from the RECON; this is information that
DBRC uses to help IMS maintain database integrity.
DELETE.BKOUT Syntax
DELETE.BKOUT SSID(name)
Parameters for DELETE.BKOUT

SSID(name)
Required parameter you use to identify the subsystem for which a backout
record is to be deleted. The subsystem name is an eight-character,
alphanumeric string that represents any valid subsystem. You can specify one
subsystem each time you issue the command.
For each database entry in the record that is marked as backout required, the
backout 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 Command

This example uses the DELETE.BKOUT command to backout subsystem IMS3.
//DELBKOUT JOB
.
.
.
//SYSIN DD *
DELETE.BKOUT SSID(IMS3)
/*
DELETE.CA
Use a DELETE.CA command to delete from RECON a change accumulation run
record for a specified CA group.
DELETE.CA Syntax
DELETE.CA GRPNAME(name) RECTIME(time_stamp)
Chapter 10. DELETE Commands 207

DELETE.CA
Parameters for DELETE.CA

GRPNAME(name)
Required parameter you use to specify the CA group. The CA run record that
is to be deleted is a member of this CA group.
RECTIME(time_stamp)
Required parameter you use to specify the change accumulation run record
that is to be deleted.
Use the RECTIME marked with an asterisk (*) from the listing of the CA
Example of Deleting a Run Record

In this example, a run record is deleted from RECON for the CA group identified
by the GRPNAME parameter. The RECTIME parameter identifies the record to be
deleted.
//DELCA JOB
.
.
.
//SYSIN DD *
DELETE.CA GRPNAME(CAGRP1) RECTIME(821220909540)
/*
DELETE.CAGRP
Use a DELETE.CAGRP command to delete a CA group record and all associated CA
run records from RECON.
DELETE.CAGRP Syntax
DELETE.CAGRP GRPNAME(name)
Parameters for DELETE.CAGRP

GRPNAME(name)
Required parameter you use to specify the name of the CA group whose
records that are to be deleted.
Example of Deleting CA Group Records

In this example, CA group records are deleted from RECON. The CA group for
which the record is being deleted is identified by the GRPNAME parameter.
//DELCAGRP JOB
.
.
.
//SYSIN DD *
DELETE.CAGRP GRPNAME(CAGRP2)
/*
DELETE.DB
Use a DELETE.DB command to delete from RECON a database and all information
related to the database that has been recorded in the RECON. If the database is a
HALDB, the database and all its partitions are deleted. If the named database is a
HALDB partition, the command fails. Use DELETE.PART command to delete a
HALDB partition. If the database or any partition of a HALDB database is in use,
the command fails and none of the RECON records are deleted.

DELETE.DB
information on designing databases, especially “Procedures for Changing PHDAM,
PHIDAM, and PSINDEX Partition Definitions.”
DELETE.DB Syntax
DELETE.DB DBD(name)
Parameters for DELETE.DB

DBD(name)
Required parameter you use to identify the name of the database to be deleted.
All database, DBDS, allocation, image copy, recovery, and reorganization
records 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 any entries
for which the corresponding DBDS records have been deleted. All log
allocation records are also scanned in order to delete any entries in the
allocation list for which the corresponding DBDS records have been deleted.
Restriction for HALDBs: For the DELETE.DB command, name specifies the name
of a HALDB master database.
Example of Deleting Records from RECON

In this example, records are deleted from RECON for the database and its
corresponding DBDSs identified by the DBD parameter.
//DELDB JOB
.
.
.
//SYSIN DD *
DELETE.DB DBD(THISDB)
/*
DELETE.DBDS
Use a DELETE.DBDS command to delete from RECON all records that are related to
a specified DBDS or DEDB area. If the DBDS for which the records are to be
deleted belongs to a CA group or to a DBDS group, its name is removed from the
group record. The DELETE.DBDS command fails if the DL/I database or Fast Path
DEDB area is in use.
| Restriction for HALDBs: The DELETE.DBDS command cannot be used to delete

| any DBDSs from a HALDB partition. Use the DELETE.PART command or the
| HALDB Partition Definition utility to delete a HALDB partition and all of its
| DBDSs.
DELETE.DBDS Syntax
DELETE.DBDS DBD(name) DDN(name)
AREA(name)
Parameters for DELETE.DBDS

DBD(name)
Required parameter you use to specify the database name of the DBDS or
DEDB area for which all records to be deleted.

DELETE.DBDS
Mutually exclusive, required parameters you use to specify the ddname of the
DBDS 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 the
DBD and DDN parameters.
//DELDBDS JOB
.
.
.
//SYSIN DD *
DELETE.DBDS DBD(DBDESDSA) DDN(DDNESDSA)
/*
DELETE.DBDSGRP
Use a DELETE.DBDSGRP command to delete the record of a specified DBDS group
from RECON.
DELETE.DBDSGRP Syntax
DELETE.DBDSGRP GRPNAME(name)
Parameters for DELETE.DBDSGRP

GRPNAME(name)
Required parameter you use to specify the name of the DBDS group that is
being deleted. The specified name must be that of a group that is identified in
RECON.
Example of Deleting a DBDS Group Record

In this example, a DBDS group record is deleted from RECON.
//DELDBDGP JOB
.
.
.
//SYSIN DD *
DELETE.DBDSGRP GRPNAME(DBDSGRP1)
/*
DELETE.GSG
Use a DELETE.GSG command to delete a global service group record from the
RECON. The GSG must not have any subsystem assigned to it.
Databases assigned to this GSG are reset to uncovered status as part of the
processing of the DELETE.GSG command. The GSG names and log tokens of all
RECON log records that are associated with this GSG are reset.
DELETE.GSG Syntax
DELETE.GSG GSGNAME(gsgname)

DELETE.GSG
Parameters for DELETE.GSG

GSGNAME(gsgname)
Required parameter you use to specify the name of the global service group to
be deleted.
Example of Deleting a Global Service Group Record

In this example, a global service group record is deleted from RECON.
//DELDBDGP JOB
.
.
.
//SYSIN DD *
DELETE.GSG GSGNAME(GSGNM1)
/*
DELETE.IC
Use a DELETE.IC command to delete an image copy record or the information
about a second image copy data set. If you specify the ICDSN2 parameter, only the
information about a second image copy data set is deleted; otherwise, both the
entire image copy record and the information about the second image copy data
set are deleted.
DELETE.IC Syntax
DELETE.IC DBD(name) DDN(name) RECTIME(time_stamp) ICDSN2(name)
AREA(name)
Parameters for DELETE.IC

DBD(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.
Restriction for HALDBs: For the DELETE.IC command, name specifies the name
of a HALDB partition.
Mutually exclusive, required parameters you use to identify the image copy
record to be deleted. name is the name of the DBDS or DEDB area to which it
is related.
RECTIME(time_stamp)
Required parameter you use to identify the specific image copy record that is
to be deleted. Use the RUN time marked with an asterisk (*) in a listing of the
IMAGE record. The time stamp must be in standard form (see “Standard Time
Stamp Format” on page 126).
ICDSN2(name)
Optional parameter you use to specify the name of a duplicate image copy
data set for which information is to be deleted from an image copy record.
(The record of the first image copy data set remains in RECON.)
Example of Deleting Information from an Image Copy Record

In this example, information about a duplicate image copy data set is deleted from
an image copy record in RECON. The parameters DBD, AREA, ICDSN2, and
RECTIME identify the information to be deleted. The asterisk (*) in the ICDSN2
parameter is to be expanded by DBRC according to the default-naming convention
for image copy data sets.

DELETE.IC
//DELIC JOB
.
.
.
//SYSIN DD *
DELETE.IC DBD(DBDKSDS1) AREA(AREA006) -
RECTIME(841231223221) ICDSN2(IMS.*.ICDSN5)
/*
DELETE.LOG (for OLDS)

Use this command to delete a data set entry from an OLDS record.
DELETE.LOG (for OLDS) Syntax

DELETE.LOG OLDS(ddname)
INTERIM LASTCLOS SSID(name)
Parameters for DELETE.LOG (for OLDS)

OLDS(ddname)
Required parameter you use to specify the ddname of the primary OLDS.
DBRC deletes the RECON records of the primary and secondary OLDS for the
specified subsystem with the specified ddname. You can delete the record of an
OLDS only if the OLDS has been archived.
INTERIM
Optional parameter you use to specify that an interim OLDS record is to be
deleted.
LASTCLOS
Optional parameter you use to specify that the OLDS specified in the OLDS
parameter is the last OLDS in the PRIOLDS record and should be deleted. Use
this parameter with caution. Normally, the last OLDS in the PRIOLDS record is
the last OLDS that was closed, and you should not delete it. Close the first
OLDS in a subsequent restart if the first OLDS is empty because of an error.
SSID(name)
created the log data set for which the RECON record is to be deleted.
comprise a valid IMS subsystem identification name. If you do not specify
subsystem identifier in the RECON header record. If you have not set a default
in the RECON header record, you must specify SSID.
Example of Deleting an Interim OLDS Record

In 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)

Use this command to:
v Delete the following records:

– A PRILOG family of records

– One data set entry from a PRILOG family
– Some or all inactive PRILOG families
– SLDSs produced by RSR tracking subsystems (TPSLD, TSSLD, TIPSL TISSL)
v Delete records of SLDSs created by RSR tracking IMS subsystems.
v Delete single data set entries from RLDS and SLDS records.
v Prevent the PRILOG records from exceeding the maximum RECON record size.
DELETE.LOG (for RLDS and SLDS) Syntax

INACTIVE
DELETE.LOG
DSN(name) TRACKING SSID(name)
INTERIM
TOTIME(time_stamp)
TRACKING SSID(name)

LISTDL
NOLISTDL
Parameters for DELETE.LOG (for RLDS and SLDS)

INACTIVE | STARTIME(time_stamp) | TOTIME(time_stamp)
Mutually exclusive, optional parameters you use to specify the records that are
to 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 the
oldest image copy data set that is known to DBRC (empty LOGALL record).
v The log is older than the log retention period that was specified in the
INIT.RECON or CHANGE.RECON command.
v The log has either been terminated (nonzero stop time) or has the ERROR
flag in the PRILOG or SECLOG record set on.
INACTIVE
Deletes an inactive PRILOG and its associated log records. INACTIVE is
the default.
INACTIVE does not delete PRILOG and SECLOG records for logs that do
not satisfy all three conditions. Most logs satisfy the conditions. Use
DELETE.LOG STARTIME(time_stamp) command for those logs that do not
satisfy all three conditions.
When the DELETE.LOG INACTIVE command is issued, DBRC also examines
active PRILOG records to determine if they should be compressed
(meaning that any inactive data set entries in the records will be deleted).
A data set entry is defined as inactive if all of the following three
conditions are met:
v It is older than the log retention period that was specified in the
v It is older than the earliest log volume required for recovery of any
database that 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 112 and “Getting PRILOG

Compression to Work” on page 110 for more information about deleting
log records and compression.
Specifies the START time of the log records to be deleted. Use the time
stamp with an adjacent asterisk (*) in a list of the PRILOG or SECLOG
record.
DSN(name)
Optional parameter (used with STARTIME) to specify the data set
name of a particular log data set (located at the tracking site) 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 primary and secondary RLDS
and SLDS records. All entries having the same log sequence number
range as the specified data set are deleted.
Only tracking log data at the tracking site (the data that is a partial
copy of the log data at the active site) is eligible for deletion.
If the data set to be deleted is the last in the log record and if it is
closed, the log stop time is set to zeros to indicate that a data set gap
exists at the end of the record.
If DSN is not specified, the entire RLDS or SLDS record is deleted.
Restrictions: STARTIME is required with DSN. You cannot specify
TOTIME, INTERIM, or TRACKING with DSN.
INTERIM
Optional parameter you use to specify the interim RLDS record and
interim SLDS record to be deleted.
Restrictions: You cannot specify INTERIM if DSN is specified.
STARTIME must be specified in conjunction with INTERIM.
TOTIME
Specifies that the records of all inactive RLDSs and SLDSs that have a start
time older than the time specified with the TOTIME parameter are to be
deleted. You must specify a time that is older than the current time, minus
the log retention period. The time stamp must be in standard form (see
“Standard Time Stamp Format” on page 126). If the PRILOG is older than
TOTIME specified, but it is still active, the PRILOG will be examined and
all inactive data set entries in the record will be deleted.
Restriction: You cannot specify TOTIME if DSN is specified.
LISTDL | NOLISTDL
Mutually exclusive, optional parameters you use to specify whether the names
of the data sets deleted from the RECON are to be listed in the job output.
These parameters override the default. The default is the value specified by the
LISTDL
Specifies that the names of deleted data sets are to be listed in the job
output.
NOLISTDL
Specifies that the names of deleted data sets are not to be listed in the job
output.

SSID(name)
Required parameter (when you specify TRACKING) that specifies the
subsystem name of the RSR tracking IMS subsystem that created the SLDSs to
be deleted.
comprise a valid IMS subsystem identification name.
Restriction: The default SSID specified on the INIT.RECON or CHANGE.RECON
command is not used on this form of the DELETE.LOG command.
TRACKING
Optional parameter you use to specify that only records of SLDSs created by
RSR tracking subsystems are to be deleted. These are the TPSLD, TSSLD,
TIPSL, and TISSL records.
Requirement: This parameter must be specified with SSID and either
STARTIME or TOTIME.
Restrictions:
v If TRACKING is specified, neither DSN nor INACTIVE can be specified.
v If INTERIM is specified, only the TIPSL and TISSL records are deleted.
Example of Deleting the Record of an RLDS and SLDS

In this example, the interim RLDS and interim SLDS records that are identified by
the STARTIME parameter are deleted from RECON.
//DELLOG JOB
.
.
.
//SYSIN DD *
DELETE.LOG STARTIME(840541212120)-
INTERIM
/*
DELETE.PART
Use a DELETE.PART command to delete from RECON a HALDB partition and all
information related to the partition that has been recorded in the RECON. If the
partition, or any other partition affected by the deletion, is in use, the command
fails and none of the RECON records are deleted.
Restriction: You cannot delete individual DBDSs belonging to HALDB partitions

with the DELETE.DPDS command. When a DELETE.PART command is issued, it
removes all the DBDSs associated with this partition as well as all of their recovery
related records (for example, ALLOC, IMAGE, RECOV, and REORG records).
information on designing databases, especially ″Procedures for Changing PHDAM,
PHIDAM, and PSINDEX Partition Definitions.″
DELETE.PART Syntax
DELETE.PART DBD(name) PART(name)
Parameters for DELETE.PART

DBD(name)
Required parameter you use to identify the HALDB for which the partition is
to be deleted.

DELETE.PART
PART(name)
Required parameter you use to identify the HALDB partition name to be
deleted.
Example of Deleting a Partition from RECON

In this example, records are deleted from RECON for the partition and its
corresponding DB and DBDSs identified by the DBD and NAME parameter.
//DELPART JOB
//SYSIN DD *
DELETE.PART DBD(DB3) PART(PART3)
/*
DELETE.RECOV
Use a DELETE.RECOV command to delete a specified recovery run record from
RECON. Specifying DELETE.RECOV for the recovery run record of a time-stamp
recovery implies that the DBDS or DEDB area that is related to the record has been
restored. It has been restored to the state it was in just before the time-stamp
recovery that created the recovery run record that you are deleting. Such a deletion
also implies that no allocations of the DBDS or DEDB area took place that
generated change records on IMS log data sets after the time-stamp recovery
occurred.
DELETE.RECOV Syntax
DELETE.RECOV DBD(name) DDN(name) RECTIME(time_stamp)
AREA(name)
Parameters for DELETE.RECOV

DBD(name)
Required parameter you use to identify the recovery record to be deleted; name
is the database name of the related DBDS or DEDB area.
Restriction for HALDBs: For the DELETE.RECOV command, name specifies the
Mutually exclusive, required parameters you use to identify the recovery
record to be deleted; name is the name of the related DBDS or DEDB area.
RECTIME(time_stamp)
Required parameter you use to specify the time stamp of the recovery run
record to be deleted. Use the time stamp with an adjacent asterisk (*) in a list
of the RECOV record. The time stamp must be in standard form (see
Example of Deleting a Recovery Record of the DBDS

This example shows the deletion from RECON of the record of a recovery of the
DBDS identified by the DBD and DDN parameters. The record to be deleted is
identified by the RECTIME parameter.
//DELRECOV JOB
.
.
.
//SYSIN DD *
DELETE.RECOV DBD(DBDESDSB) DDN(DDNESDSB) -
RECTIME(930891919190)
/*

DELETE.REORG
DELETE.REORG
Use a DELETE.REORG command to delete a database reorganization record for a
specified DBDS from RECON. When you specify the DELETE.REORG command, you
are implying that the DBDS and the IMS DBD library have been restored to the
state they were in before the reorganization that created the database
reorganization record. By using the DELETE.REORG command, you are also implying
that no allocations of the reorganized database that generated records in IMS log
data sets took place.
DELETE.REORG Syntax
DELETE.REORG DBD(name) DDN(name) RECTIME(time_stamp)
Parameters for DELETE.REORG

DBD(name)
Required parameter you use to identify the reorganization record to be deleted;
name is the database name of the related DBDS.
Restriction for HALDBs: For the DELETE.REORG command, name specifies the
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(time_stamp)
Required parameter you use to identify the specific database reorganization
record to be deleted. Use the time stamp with an adjacent asterisk (*) in a list
of the REORG record. The time stamp must be in standard form (see
Example of Deleting a Reorganization Record of a DBDS

In 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
Use a DELETE.SG command to delete a service group entry within a global service
group record in the RECON. The service group cannot be deleted while a
subsystem is signed on to the global service group.
DELETE.SG Syntax
DELETE.SG GSGNAME(gsgname) SGNAME(sgname)

DELETE.SG
Parameters for DELETE.SG

GSGNAME(gsgname)
Required parameter you use to specify the name of the global service group to
which the service group belongs.
SGNAME(sgname)
Required parameter you use to specify the name of the service group to be
deleted.
Example of Deleting a Global Service Group Record

In this example, a service group entry within a global service group record is
deleted from RECON.
//DELDBDGP JOB
.
.
.
//SYSIN DD *
DELETE.SG GSGNAME(GSGNM1) SGNAME(SGNM1)
/*
DELETE.SUBSYS
Use a DELETE.SUBSYS command to delete the subsystem entry in RECON after it is
verified that the specified subsystem is not authorized to use any database.
For more information about deleting subsystem entries, see “CHANGE.SUBSYS”

on page 201.
To close the subsystem log, issue the NOTIFY.PRILOG command, and then issue the
DELETE.SUBSYS command.
DELETE.SUBSYS Syntax
DELETE.SUBSYS SSID(name)
Parameters for DELETE.SUBSYS

SSID(name)
Required parameter you use to identify the subsystem for which the entry is
deleted from RECON if no database is authorized by the subsystem.
When you issue this command online, the IMS control region under which the
command was issued cannot be the subsystem being deleted.
Example of Deleting a Specified SUBSYS Record

In this example, the specified SUBSYS record is deleted if no database is
authorized by the subsystem.
//DELSBSYS JOB
.
.
.
//SYSIN DD *
DELETE.SUBSYS SSID(IMS34)
/*
DELETE.UIC
Use a DELETE.UIC command to delete the record of a nonstandard image copy data
set from RECON.

DELETE.UIC
DELETE.UIC Syntax
DELETE.UIC DBD(name) DDN(name) RECTIME(time_stamp)
AREA(name)
Parameters for DELETE.UIC

DBD(name)
Required parameter you use to identify the nonstandard image copy record to
be deleted; name is the database name of the related DBDS or area.
Restriction for HALDBs: For the DELETE.UIC command, name specifies the
Mutually exclusive, required parameters you use to identify the nonstandard
image copy record to be deleted; name is the name of the related DBDS or
DEDB area.
RECTIME(time_stamp)
Required parameter you use to specify the time stamp of the nonstandard
image copy record to be deleted. Use the time stamp with an adjacent asterisk
(*) in a list of the IMAGE record. The time stamp must be in standard form
(see “Standard Time Stamp Format” on page 126).
Example of Deleting a Nonstandard Image Copy Data Set Record

This example shows the deletion of a record of a nonstandard image copy data set
from RECON.
//DELUIC JOB
.
.
.
//SYSIN DD *
DELETE.UIC DBD(DBDESDSB) AREA(AREAESD2) -
RECTIME(840871212120)
/*

DELETE.UIC

Chapter 11. GENJCL Commands
Use the GENJCL commands to generate JCL and utility control statements that run
the various IMS recovery utilities.
GENJCL Commands In This Chapter

The following is a list of all the GENJCL commands:
v “GENJCL.ARCHIVE”
v “GENJCL.CA” on page 225
v “GENJCL.CLOSE” on page 229
v “GENJCL.IC” on page 233
v “GENJCL.OIC” on page 242
v “GENJCL.RECEIVE” on page 247
v “GENJCL.RECOV” on page 251
v “GENJCL.USER” on page 257
GENJCL.ARCHIVE
Use the GENJCL.ARCHIVE command to generate the JCL and utility control
statements that run the Log Archive utility. For the IBM-supplied skeletal JCL
execution member that is used by GENJCL.ARCHIVE, see “Generating JCL and
User-Defined Output” on page 83.
GENJCL.ARCHIVE Syntax
ALL
GENJCL.ARCHIVE
, ,
OLDS( ddname ) DEFAULTS( member )

SLDS
TOTIME(time_stamp)
JOB NOLIST

JCLOUT JCLPDS JOB(member) LIST
JCLOUT( ddname ) JCLPDS( ddname ) NOJOB

MAXOLDS(n) MEMBER(member) SSID(name) TIMEFMT(sublist)

,
USERKEYS( ( %key1, 'value' ) )

%key2
Parameters for GENJCL.ARCHIVE

ALL | OLDS(ddname) | SLDS
Mutually exclusive, optional parameters that you use to specify which OLDS is
being archived or to request the archive of tracking SLDSs.

GENJCL.ARCHIVE
Attention: Ensure that the RSR tracking IMS subsystem has completed the
processing of the SLDS before you run a batch archive. If a tracking IMS
process (such as online forward recovery (OFR), log truncation, or catch up)
needs to read from an SLDS that is being processed by batch archive,
allocation of the SLDS by the tracking IMS fails, and the tracking IMS might
terminate abnormally.
ALL
Generates JCL to archive all OLDSs that have not been archived. A
multiple-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 .
OLDS
Specifies the ddname of the primary OLDS you are archiving.
SLDS
Generates JCL to archive all tracking SLDSs which are associated with the
specified subsystem that have not been archived. A multiple-step job can
be produced if the PRISLD or SECSLD (or both) have non-contiguous data
set entries that need to be archived, or if they have more unarchived DSNs
than the specified MAXOLDS value.
TOTIME(time_stamp)
Specifies that only tracking log data sets with start times older than or
equal to time_stamp are to be archived. This parameter is optional and
is valid only when SLDS is also specified. Otherwise it is ignored. The
time stamp must be in standard format.
DEFAULTS(member)
Optional parameter you use to specify up to 10 skeletal JCL default members
to be used when generating JCL. Default members are searched to resolve
keywords in the order in which the members are specified on this parameter.
If a keyword is assigned a value in both the DEFAULTS and USERKEYS
parameters, the value specified in USERKEYS is used.
JCLOUT(JCLOUT | ddname)
Optional parameter you use to specify the output data set for the generated
JCL. The data set is specified by ddname. A JCL DD statement with this
ddname must be included in the job step containing the GENJCL command. The
specified data set can be a member of a partitioned data set (PDS) as long as it
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 be
used 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 step
containing the GENJCL command.
JOB | JOB(member) | NOJOB
Mutually exclusive, optional parameters that you use to specify whether to
produce the job statement in the generated JCL.
JOB
Specifies that the job statement is to be produced. When JOB is specified
without a member name, the IBM-supplied execution member JOBJCL
produces the job statement. When JOB(member) is specified, the specified
execution member produces the job statement.

GENJCL.ARCHIVE
NOJOB
Specifies that the job statement is not produced in the generated JCL.
LIST | NOLIST
print the generated JCL using the SYSPRINT data set.
LIST
Prints the generated JCL.
NOLIST
Suppresses printing of the generated JCL.
MAXOLDS(n)
Optional parameter you use to specify the maximum number of OLDSs or
SLDSs to be archived in a single job. n can be any decimal number from 1 to
100.
If MAXOLDS is specified and more OLDSs need archiving than are specified
in n, multiple jobs are generated. Each generated job archives no more than n
OLDSs.
This parameter functions somewhat differently for SLDSs than for OLDSs. If
MAXOLDS is specified and more SLDSs need archiving than are specified in n,
multiple job steps are generated. Each generated job step archives no more
than 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 (that
is, DD statements for 2 x n data sets).
If you do not specify MAXOLDS, a single job is generated for all OLDSs or
SLDSs.
MEMBER(member)
Optional parameter you use to specify the name of the skeletal JCL execution
member to be used. If this parameter is not specified, the IBM-supplied
execution member for the GENJCL.ARCHIVE command is used. For a description
of this execution member, see “Generating JCL and User-Defined Output” on
page 83.
SSID(name)
created the OLDSs or SLDSs that are to be archived.
comprise a valid IMS subsystem identification name. If you do not specify
record. Use the INIT.RECON or CHANGE.RECON command to set the default system
identifier in the RECON header record. If you have not set a default in the
RECON header record, you must specify SSID.
TIMEFMT(sublist)
Optional parameter you use to define the form in which time stamps appear in
user-defined output. This specification overrides both the GENJCL default values
and any values set on %SET statements in the input skeletal JCL.
The default for the GENJCL output time format is compressed, with a two-digit
year, and the offset in numeric form: 960021315001 +0700. If you want the
output time stamps to appear without offsets, for example, you can override
the default with TIMEFMT(,N).
The override is good only for the duration of a single GENJCL command.
Chapter 11. GENJCL Commands 223

GENJCL.ARCHIVE
Related Reading:
v The TIMEFMT parameter sublist format is described in “TIMEFMT
v See “TIMEFMT Subparameter Order of Precedence” on page 129 for
information on the precedence of the subparameters.
v See “Standard Time Stamp Format” on page 126 for examples of the
different output forms.
USERKEYS(%key1,'value' | %key2)
Optional parameter you use to set the value of keywords you have defined.
Up to 32 keywords can be specified.
%key1
User-defined keyword being assigned a value. The maximum length of the
keyword is eight characters, including the percent sign. The first character
after the percent sign must be alphabetic (A-Z). The remaining characters
must be alphanumeric (A-Z, 0-9).
'value'
Value assigned to the user-defined keyword when it is encountered. value
can be any character string enclosed in single quotes. The maximum length
of 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 time
stamp, it can be zero.
%key2
Any simple keyword that was previously assigned a value, including
DBRC-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 “Symbolic Keywords” on page
86.
If a keyword is assigned a value in both the USERKEYS and DEFAULTS
parameter, the value specified in USERKEYS is used.
Examples of Running the Log Archive Utility

Here are some examples of using the GENJCL.ARCHIVE command.
Example with Primary OLDS Defined by the OLDS Parameter: In this example,
a GENJCL.ARCHIVE command generates the JCL and control statements required to
run the Log Archive utility for the primary OLDSs that are defined by the OLDS
parameter. When this command is issued, the PRIOLDS record in RECON is
updated to indicate that an archive has been scheduled for the OLDS. Default
skeletal member ARCHJCL is taken from the data set that is identified in the
JCLPDS DD statement. The generated JCL goes to the data set identified in the
JCLOUT DD statement. Skeletal member JOBJCL produces a job statement.
//GENJAR JOB
//JCLOUT DD . . .
//JCLPDS DD . . .
.
.
.
//SYSIN DD *
GENJCL.ARCHIVE SSID(IMSA) -
OLDS(DFSOLP01,DFSOLP02)
/*

GENJCL.ARCHIVE
As part of the archive process, the PRIOLDS record in RECON is updated to

indicate that the archive has completed. RECON is updated with the PRISLD and
SECSLD records that identify the created SLDSs. In addition, RECON is updated
with the PRILOG and SECLOG records that identify the created RLDSs.
Example of the SSID IMSB OLDS Parameter Defining the Primary OLDS: In
this example, a GENJCL.ARCHIVE command generates JCL to archive the primary
OLDS that is defined in the OLDS parameter for SSID IMSB. JCL execution
member ARCHJCLA is taken from the JCLPDS data set that is identified in the
PDSJCL DD statement. The generated JCL goes to SYSOUT=A, which is identified
in 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 OLDSs: In this example, the

GENJCL.ARCHIVE command generates JCL and control statements to archive all
unarchived OLDSs for the default subsystem ID.
JCL execution member ARCHJCLB is taken from the JCLPDS data set that is
identified by the JCLPDS DD statement. Member DEFARC01 from the JCLPDS
data set (identified in the JCLPDS DD statement) contains values to resolve
user-defined keywords in ARCHJCLB. %SSPACE is a user-defined keyword in
member ARCHJCLB which is assigned a value of 'CYL,1'. %RSPACE is a user-defined
keyword in member ARCHJCLB, which is assigned a value of 'TRK,4'.
The values specified in the USERKEYS parameter for a keyword overrides the
values found in the DEFAULTS member. JOB1 is a member in the JCLPDS that
produces a job statement.
//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
Use the GENJCL.CA command to generate the JCL and utility control statements to
run the Change Accumulation utility for a specified CA group. For information on
the IBM-supplied skeletal JCL execution member used by GENJCL.CA, see
“Generating JCL and User-Defined Output” on page 83.
GENJCL.CA Syntax
GENJCL.CA GRPNAME(name)
, JCLOUT
JCLOUT( ddname )
DEFAULTS( member )
JOB NOLIST

JCLPDS JOB(member) LIST MEMBER(member) NODEFLT
JCLPDS( ddname ) NOJOB

GENJCL.CA

TIMEFMT(sublist) 3400
UNIT( unittype )

, ,
USERKEYS( ( %key1, 'value' ) ) VOLLIST( volser )

%key2

VOLNUM(value)
CATIME(time)
Parameters for GENJCL.CA

GRPNAME(name)
you are running the Change Accumulation utility.
DEFAULTS (member)
Optional parameter you use to specify the names of up to 10 skeletal JCL
default members that are used when generating JCL. Default members are
searched to resolve keywords in the order in which the members are specified
on this parameter.
JCLOUT (JCLOUT | ddname)
specified data set can be a member of a partitioned data set as, but only if it is
not the same data set that is used for the default, JCLOUT.
used for input when generating JCL. The data set is specified by ddname. A JCL
DD statement with this ddname must be included in the job step containing
the GENJCL command.
produce the first job statement in the generated JCL.
JOB
produces the job statement.
JOB(member)
Specified execution member produces the job statement.
NOJOB
Specifies that the job statement is not produced in the generated JCL.
LIST | NOLIST
Mutually exclusive, optional parameters that you use to specify whether you
want the generated JCL to be written to the SYSPRINT data set.

GENJCL.CA
LIST
NOLIST
Suppresses the printing of the generated JCL.
MEMBER(member)
member that is to be used. If this parameter is not specified, the default
specified for the CA group is used. For a description of the IBM-supplied
execution member, see “Generating JCL and User-Defined Output” on page 83.
NODEFLT
Optional parameter you use to specify that the implicit skeletal JCL default
member, if any, for the CA group is not to be used.
TIMEFMT(sublist)
Related Reading:
Optional parameter you use to specify the unit type of the output change
accumulation data set. This parameter is valid only when both of the following
conditions are true:
v The VOLLIST parameter is specified.
v The CA group for which the JCL is being generated is defined with the
NOREUSE parameter.
| USERKEYS(%key1,'value' | %key1, %key2)
%key1
'value'

GENJCL.CA
%key2

86.
VOLLIST(volser)
Optional parameter you use to specify the volumes that are to contain the
change accumulation data set. This parameter is valid only if the CA group for
which the JCL is being generated was defined with the NOREUSE parameter.
VOLNUM(value) | CATIME(time)
Mutually exclusive, optional parameters that you use to specify the log
volumes that are used by the Change Accumulation utility.
VOLNUM
Specifies the number of log volumes that are to be used in each change
accumulation job step. DBRC generates a multiple-step job that invokes the
Change 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 may
be overridden by DBRC. DBRC may also override VOLNUM for the
following 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 decimal
number 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 the
accumulation in that step.
CATIME
Specifies the time after which no log volumes for the specified CA group
are to be included. The time stamp does not need to be the stop time of
any log volume. DBRC uses the time stamp as the ending delimiter for the
log volume subset. Therefore, all log volumes that have start times less
than or equal to the specified time stamp are included in the subset of
volumes. The time stamp must be in standard form (see “Standard Time
Examples of Running the Change Accumulation Utility

Here are some examples of using the GENJCL.CA command.
Example for the GRPNAME CA Group: In this example, a GENJCL.CA command

generates the JCL and control statements required to run the Change Accumulation
utility for the CA group identified in the GRPNAME parameter. CAGRP1 is
defined as REUSE. If the INIT.CAGRP command for CAGRP1 is specified without a
CAJCL(member) parameter, default skeletal member CAJCL from the data set
identified in the JCLPDS DD statement is used. If INIT.CAGRP is specified with the

GENJCL.CA
CAJCL(member) parameter, that member is used. The generated JCL goes to the
data set that is identified in the JCLOUT DD statement. Skeletal member JOBJCL
//GENJCA JOB
//JCLPDS DD . . .
//JCLOUT DD . . .
.
.
.
//SYSIN DD *
GENJCL.CA GRPNAME(CAGRP1)
/*
Example of CAJCLA Generated Skeletal JCL: In this example, the GENJCL.CA

command is generated with skeletal JCL execution member CAJCLA, which was
taken from the JCLPDS data set identified by the PDSJCL DD statement. Output
from the generated JCL goes to SYSOUT=A, identified in the OUTJCL DD
statement. CAGRP2 is defined with the NOREUSE parameter. 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 JCL: In this example, the GENJCL.CA

command generates JCL and control statements to run the Change Accumulation
utility for CAGRP3, which is defined as REUSE. JCL execution member CAJCLB is
taken from the JCLPDS data set identified by the JCLPDS DD statement.
DEFAULTS(DEFCA01) is a member in the JCLPDS data set which contains values

to resolve user defined keywords in member CAJCLB. The default member for the
CAGRP, if initialized in the INIT.CAGRP DEFLTJCL(MEMBER) command, is also
used to resolve keywords. %DISP is a user-defined keyword in member CAJCLB
which is assigned a value of 'SHR'. %OUTCLS is a user-defined keyword in member
CAJCLB which is assigned a value of 'B'.
The values in the explicitly defined DEFAULTS member overrides values in the
predefined DEFLTJCL member. The values specified in the USERKEYS parameter
for a keyword overrides the values found in the DEFAULTS member. JCL is
generated with no job statement. All volumes that have stop times less than or
equal to the specified time stamp are included in the subset of volumes that is
used as input to the Change Accumulation utility. Generated JCL is listed.
//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
Use the GENJCL.CLOSE command to generate the JCL and utility control statements
that run the Log Recovery utility to close an OLDS using the WADS. For
information about the IBM-supplied skeletal JCL execution member used by
GENJCL.CLOSE, see “Generating JCL and User-Defined Output” on page 83.

GENJCL.CLOSE
GENJCL.CLOSE Syntax
GENJCL.CLOSE
, JCLOUT
JCLOUT( ddname )
DEFAULTS( member )
JOB NOLIST

JCLPDS JOB(member) LIST MEMBER(member)

OLDS(ddname) SSID(name) TIMEFMT(sublist)

,

%key2
Parameters for GENJCL.CLOSE

DEFAULTS(member)
Optional parameter you use to specify up to 10 names of skeletal JCL default
members used when generating JCL. Default members are searched to resolve
keywords in the order in which the members are specified on this parameter.
specified data set can be a member of a partitioned data set, but only if it is
Optional parameter you use to specify the skeletal JCL data set to be used for
input when generating JCL. The data set is specified by ddname. A JCL DD
statement with this ddname must be included in the job step containing the
GENJCL command.
JOB | JOB(member)|NOJOB
JOB
Specifies that the job statement is produced. When JOB is specified without
a member name, the IBM-supplied execution member JOBJCL produces the
job statement.
JOB(member)
Specified execution member produces the job statement.
NOJOB
Specifies that no job statement is to be produced in the generated JCL.

GENJCL.CLOSE
LIST | NOLIST
Mutually exclusive, optional parameters that you use to specify whether you
want the generated JCL to be written to the SYSPRINT data set.
LIST
NOLIST
MEMBER(member)
member to be used. If this parameter is not specified, the IBM-supplied
execution member for the GENJCL.CLOSE command is used. For a description of
this execution member, see “Generating JCL and User-Defined Output” on
page 83.
OLDS(ddname)
Optional parameter you use to specify which OLDS is to be closed. You specify
the name of the DD statement that was used when the online IMS subsystem
created the log data. The ddname of the primary OLDS must be specified. If
you do not specify the OLDS, DBRC generates JCL to close the OLDS that was
most recently opened.
SSID(name)
created the OLDSs being closed.
The SSID is an eight-character alphanumeric string that comprises a valid IMS
subsystem identification name. If you do not specify SSID, DBRC uses the
default subsystem identifier in the RECON header record. Use the INIT.RECON
or CHANGE.RECON command to set the default system identifier in the RECON
header record. If you have not set a default in the RECON header record, you
must specify SSID.
TIMEFMT(sublist)
Related Reading:
%key1
User-defined keyword that is being assigned a value. The maximum length

GENJCL.CLOSE
of the keyword is eight characters, including the percent sign. The first
character after the percent sign must be alphabetic (A-Z). The remaining
characters must be alphanumeric (A-Z, 0-9).
'value'
%key2

86.
Examples of Running the Log Recovery Utility

Here are some examples of using the GENJCL.CLOSE command.
Example When a Host Operating System Failed and /ERE Is Not Possible: In
this example, a GENJCL.CLOSE command generates the JCL and control statements
that are required to run the Log Recovery utility for the IMS online subsystem
with subsystem ID IMSA, which was using a primary OLDS when a host
operating system failed and /ERE could not be performed. Default skeletal member
LOGCLJCL 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 DD
statement. 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 the
OLDS is updated to indicate the successful close.
Example Using the CLOSE1 JCLPDS Member: In this example, the GENJCL.CLOSE
command is generated with a skeletal JCL execution member CLOSE1, which is
taken from the JCLPDS data set identified in the PDS DD statement. Output from
the generated JCL goes to the data set identified in the OUT DD statement.
MEMBER DEFCL1 from the JCLPDS DD statement 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
GENJCL.IC
Use the GENJCL.IC command to generate the JCL and utility control statements
needed to run the Database Image Copy utility or the Database Image Copy 2
utility. For information about the IBM-supplied skeletal JCL execution member
used by GENJCL.IC, see “Generating JCL and User-Defined Output” on page 83.
Important:
v For HALDB partitions, the GENJCL.IC command treats ILDS and index data sets
differently than data DBDSs. The GENJCL.IC command skips these data sets in
groups, regardless of whether the groups are explicit or implicit. If you explicitly
specify one of these data sets, the GENJCL.IC command fails.
| v For HALDB DBDSs, the GENJCL.IC command does not generate DD statements
| for the DBDSs to be copied. The SYSIN control statement identifies which active
| DBDSs to copy. These can be either the A-through-J data set or the M-through-V
| data sets.
Manager for an overview of the Database Image Copy utility and the Database
IMage Copy 2 utility.
GENJCL.IC Syntax
| GENJCL.IC DBD(name)
| GROUP(name) COPIES( 1 ) DDN(ddname)
2 AREA(name)
3
4
| CIC
|
NOCIC ,
SMSCIC
(Sameds) DEFAULTS( member )
(Compress)
(n)
(Sameds,Compress)
(Sameds,Compress,n)
(Compress,n)
DBREL(L)
SMSNOCIC
(Sameds) DBREL(P)
(Compress)
(n)
(Sameds,Compress)
(Sameds,Compress,n)
(Compress,n)
| JOB NOLIST
|
| MULTIJOB
|
MEMBER(member) ONEJOB NODEFLT TIMEFMT(sublist)

GENJCL.IC
|
| 3400 3400 3400
UNIT( unittype ) UNIT2( unittype ) UNIT3( unittype )
|
| 3400 ,
UNIT4( unittype )
%key2
|
| , , ,
VOLLIST( volser ) VOLLIST2( volser ) VOLLIST3( volser )
|
| ,
VOLLIST4( volser )
Parameters for GENJCL.IC

DBD(name) | GROUP(name)
Mutually exclusive, required parameters that you use to specify the database
or DBDS group for which DBDSs are to be copied.
DBD
Specifies the name of the database that contains the DBDS or area to be
copied.
If DDN is omitted and ONEJOB is specified for a SMSCIC or SMSNOCIC
image copy, a utility control statement specifying the DBD name as the
group name is generated in the JCL.
Restriction for HALDBs: For the GENJCL.IC command, name specifies the
name of either a HALDB master database name or a HALDB partition
name.
GROUP
Specifies that all DBDSs of a DBDS group are to be copied. If GROUP is
specified, the GENJCL.IC command executes repeatedly for each DBDS of
the named DBDS group.
If GROUP and ONEJOB are specified for an SMSCIC or SMSNOCIC image
copy, a utility control statement specifying the group name is generated in
the JCL.
COPIES(1 | 2 | 3 | 4)
Optional parameter you use to specify how many two image copy data sets
are to be produced for the specified DBDS.
If the specified DBDS is identified in RECON with the NOREUSE attribute,
you can specify the COPIES parameter if you want two or more image copy
data sets; otherwise, one image copy data set is produced. COPIES(3 | 4) can
only be specified if either SMSCIC or SMSNOCIC is also specified. The third
and fourth copies are not recorded in RECON.

GENJCL.IC
If the specified DBDS is identified in RECON with the REUSE attribute, the
COPIES parameter is not allowed. The number of copies is determined by the
number of pre-defined image copy data sets specified on the INIT.IC
command.
Mutually exclusive, optional parameters that you use to identify the DBDS
ddname or DEDB area name that is to be copied.
Specify the DDN or AREA parameter only if you specify the DBD parameter. If
you do not specify DDN or AREA, the GENJCL.IC command executes
repeatedly, once for each DBDS or area of the specified database. If you specify
a HALDB master name, the GENJCL.IC command is performed for all data
DBDSs for each partition in the HALDB master database. If you specify a
HALDB partition name, the GENJCL.IC command is performed for all data
DBDSs of the identified partition.
For HALDBs, you must specify a partition database name with the DBD
parameter in order to use the DDN parameter. The DDN parameter value is
the partition DDN. The GENJCL.IC command is performed for the identified
DBDS of the partition. The GENJCL.IC command fails if DDN does not identify
a data DBDS in the partition.
| CIC | NOCIC | SMSCIC(Sameds | Compress | n | any combination) |
| SMSNOCIC(Sameds | Compress | n | any combination | DBREL(L | P)
| Optional parameters that you use to indicate how the image copy is to be
| taken.
| Restriction: CIC and SMSCIC cannot be used for nonrecoverable or
| user-recoverable databases.
| CIC
| Specifies that the Database Image Copy (DFSUDMP0) utility is to be used
| to take an image copy. If CIC is specified, the copy is concurrent with
| update processing.
| NOCIC
| Specifies that the Database Image Copy (DFSUDMP0) utility is to be used
| to take an image copy. If NOCIC is specified, the copy is made while the
| database is unavailable for update processing.
| SMSCIC(Sameds | Compress | n | any combination)
| Indicates that the Database Image Copy 2 utility is to be used to take an
| image copy concurrent with update processing. The Database Image Copy
| 2 utility invokes DFSMSdss to dump the database data set or sets using the
| Concurrent Copy option.
| Sameds
| An optional parameter you use to specify that all the image copies
| generated by the job are to be written to a single output data set. This
| option is not valid if any of the DBDs or areas have the REUSE
| attribute, if ONEJOB is not specified, or if more than 255 data sets
| and/or areas are to be copied. You can abbreviate this option when
| specifying it. When a DBDS group (explicit or implicit) is specified, this
| option applies to all members of the group.
| Compress
| An optional parameter you use to indicate that the utility is to specify
| the DFSMSdss compress option. The compress option enables you to
| reduce the storage space required to hold the image copy; however,
| using the compress option increases the CPU time that is required to

GENJCL.IC
| perform the copy operation. You can abbreviate this option when
| n An optional parameter you use to specify the value to be used for the
| DFSMSdss OPTIMIZE parameter. n is a number from 1 to 4 where:
| v If n is 1, DFSMSdss reads one track at a time.
| v If n is 2, DFSMSdss reads two tracks at a time.
| v If n is 3, DFSMSdss reads five tracks at a time.
| v If n is 4, DFSMSdss reads one cylinder at a time.
| If n is not specified, the default is 1 for SMSCIC and 4 for SMSNOCIC.
| Note that higher values use more real and virtual storage, and keeps
| the channel busy for longer blocks at a time. You can abbreviate this
| option when specifying it. When a DBDS group (explicit or implicit) is
| specified, this option applies to all members of the group.
| SMSNOCIC(Sameds | Compress | n | any combination | DBREL(L | P)
| Indicates that the Database Image Copy 2 utility is to be used to take an
| image copy while the database is unavailable for update processing. The
| Database Image Copy 2 utility invokes DFSMSdss to dump the database
| data set(s) using the Concurrent Copy option.
| Sameds
| An optional parameter you use to specify that all the image copies
| generated by the job are to be written to a single output data set. This
| option is not valid if any of the DBDs or areas have the REUSE
| attribute, if ONEJOB is not specified, or if more than 255 data sets
| and/or areas are to be copied. You can abbreviate this option when
| Compress
| An optional parameter you use to indicate that the utility is to specify
| the DFSMSdss compress option. The compress option enables you to
| reduce the storage space required to hold the image copy; however,
| using the compress option increases the CPU time that is required to
| perform the copy operation. You can abbreviate this option when
| n An optional parameter you use to specify the value to be used for the
| DFSMSdss OPTIMIZE parameter. n is a number from 1 to 4 where:
| v If n is 1, DFSMSdss reads one track at a time.
| v If n is 2, DFSMSdss reads two tracks at a time.
| v If n is 3, DFSMSdss reads five tracks at a time.
| v If n is 4, DFSMSdss reads one cylinder at a time.
| If n is not specified, the default is 1 for SMSCIC and 4 for SMSNOCIC.
| Note that higher values use more real and virtual storage, and keeps
| the channel busy for longer blocks at a time. You can abbreviate this
| option when specifying it. When a DBDS group (explicit or implicit) is
| specified, this option applies to all members of the group.
| DBREL(L | P)
| Indicates when the database is to be made available for update
| processing. DBREL is applicable only when SMSNOCIC is also
| specified. IMS ignores DBREL when it is specified with SMSCIC.

GENJCL.IC
| L L indicates that updates are to be allowed after the image copy is

| logically complete (after DFSMS has initialized a concurrent copy
| session). Update processing can occur (or be resumed) before the
| image copy is physically complete.
| P P indicates that updates are not to be allowed until the image copy
| is physically complete.
DEFAULTS(member)
members to be used when generating JCL. Default members are searched to
resolve keywords in the order in which the members are specified on this
parameter.
the GENJCL command.
JOB
NOJOB
Specifies that the job statement is not to be produced in the generated JCL.
LIST | NOLIST
write the generated JCL to the SYSPRINT data set.
LIST
NOLIST
MEMBER(member)
member to be used. For a description of the IBM-supplied execution member,
see “Generating JCL and User-Defined Output” on page 83. If this parameter is
not specified, the default specified on the INIT.DBDS command is used.

GENJCL.IC
MULTIJOB | ONEJOB
Mutually exclusive, optional parameters that you use to control how many JOB
and EXEC statements are to be generated when a DBDS group is specified
either explicitly or implicitly.
MULTIJOB
Produces one job for each group member.
ONEJOB
Produces one job with:
v A separate step for each group member with the CIC or NOCIC option.
v A single step to copy all members of the group with the SMSCIC or
SMSNOCIC option.
These parameters are invalid if the NOJOB subparameter is specified on the

JOB parameter, or if a DBDS group is not specified.
NODEFLT
member, if any, for the DBDS is not to be used.
TIMEFMT(sublist)
Related Reading:
Optional parameter you use to specify the unit type of the first, second, third,
or fourth output image copy data sets. These parameters are valid only if both
of the following conditions are true:
v The corresponding VOLLIST parameter is specified
v The DBDS for which the JCL is being generated was defined with the
NOREUSE option
%key1

GENJCL.IC
'value'
%key2

86.
VOLLIST(volser)
VOLLIST2(volser)
VOLLIST3(volser)
VOLLIST4(volser)
Optional parameters that you use to specify the volumes on which the image
copy data set copies are to reside. These parameters are valid only if:
v The DBDS for which the JCL is being generated is defined with the
NOREUSE option.
v DBD is specified with DDN or AREA.
Examples of Running the Database Image Copy Utility

Here are some examples of using the GENJCL.IC command.
Example for DBDS Defined by the DBD and DDN Parameters: In this example,
a GENJCL.IC command generates the JCL and control statements required to run
the Database Image Copy utility for the DBDS identified in the DBD and DDN
parameters. The default Concurrent Image Copy (CIC) is used. The database is
defined as REUSE. If the INIT.DBDS command for the DBDS for which JCL is being
generated is specified with ICJCL(member), that skeletal member is used from the
data set that is identified in the JCLPDS DD statement. If not, the default skeletal
member ICJCL from the JCLPDS data set is used. Output from the generated JCL
goes to the data set identified in the JCLOUT DD statement. Skeletal member
//GENJIC1 JOB
//JCLOUT DD . . .
//JCLPDS DD . . .
.
.
.
//SYSIN DD *
GENJCL.IC DBD(DBDKSDS1) DDN(DDNKSDS1)
The EXEC and SYSIN statements for the generated JCL are shown below:
.
.
.
//IC1 EXEC PGM=DFSUDMP0,REGION=nnnK,
// PARM='CIC,GSGNAME='
//D1OU1 DD DSN=...

GENJCL.IC
.
.
.
//SYSIN DD *
D1 DBDKSDS1 DDNKSDS1 D1OU1
/*
Example for All DBDSs in a Group with NOCIC: In this example, the GENJCL.IC
command generates JCL and control statements to run 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 set identified in PDS4. The keyword,
%DEFIC, is a user-defined value in ICJCL1 that is resolved to '1ST USERKEYS
PARM'. The default member for the database initialized in INIT.DBDS
DEFLTJCL(MEMBER) is not used to resolve keywords. Skeletal member JOBJCL
//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 of
the SYSIN statements for the generated JCL:
.
.
.
// PARM=',GSGNAME='
//D1OU1 DD DSN=...
.
.
.
//SYSIN DD *
D1 DBD1GRP1 DDN1GRP1 D1OU1
/*
// PARM=',GSGNAME='
.
.
.
Example of Running the Database Image Copy 2 Utility with SMSCIC: In this
example, a GENJCL.IC command generates the JCL and control statements required
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. The database is
defined as NOREUSE and four copies are requested. The default skeletal member
ICJCL from the JCLPDS data set is used. Output from the generated JCL goes to
the data set identified in the JCLOUT DD statement. Skeletal member JOBJCL
//GENJIC3 JOB
//JCLOUT DD . . .
//JCLPDS DD . . .
.
.
.
//SYSIN DD *
GENJCL.IC DBD(DBDVSAM1) DDN(DDNVSAM1) COPIES(4) SMSCIC(1) -
VOLLIST(IC2001) VOLLIST2(IC2002) VOLLIST3(IC2003) -
VOLLIST4(IC2004)
/*

GENJCL.IC
.
.
.
//IC1 EXEC PGM=DFSRRC00,REGION=nnnK,
// PARM='ULU,DFSUDMT0,,,,,,,,,,,,Y,,,,,,,,'
.
.
.
//SYSIN DD *
4 DBDVSAM1 DDNVSAM1 D1OU1 D2OU1 D3OU1 D4OU1 S 1
/*
Example of Running the Database Image Copy 2 Utility with SMSNOCIC: In

this example, the GENJCL.IC command generates JCL and control statements to run
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 is
defined as REUSE and the default, one copy, is requested. The global service group
name for DBDVSAM2 is GSGN4IC2. The default skeletal member ICJCL from the
JCLPDS data set is used. Output from the generated JCL goes to the data set
identified in the JCLOUT DD statement. Skeletal member JOBJCL produces a job
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
/*
Example of Running the Database Image Copy 2 utility with an implied

database group: All data sets for the database will be copied in a single step to a
single output data set, with the Compress option.
//GENJIC5 JOB
//JCLOUT DD . . .
//JCLPDS DD . . .
.
.
.
//SYSIN DD *
GENJCL.IC DBD(DBDVSAM) SMSCIC(SAMEDS,COMPRESS) ONEJOB
/*
The following are the EXEC and SYSIN cards in the generated JCL:
.
.
.
//IC1 EXEC PGM=DFSRRC00,REGION=800K,
// PARM='ULU,DFSUDMT0,,,,,,,,,,,,Y,,,,,,,,'
//D1OU0 DD DSN=...
//SYSIN DD *
G DHVNTZ02 S C1
1 DHVNTZ02 HIDAM D1OU0
S DHVNTZ02 HIDAM2 /*

GENJCL.OIC
GENJCL.OIC
Use the GENJCL.OIC command to generate the JCL and utility control statements
needed to run the Online Database Image Copy utility. For information about the
IBM-supplied skeletal JCL execution member used by GENJCL.OIC, see “Generating
JCL and User-Defined Output” on page 83.
Important:
v For HALDB partitions, the GENJCL.OIC command treats ILDS and index data sets
differently than data DBDSs. The GENJCL.OIC command skips these data sets in
groups, regardless of whether the groups are explicit or implicit. If you explicitly
specify one of these data sets, the GENJCL.OIC command fails.
| v For HALDB DBDSs, the GENJCL.IC command does not generate DD statements
| for the DBDSs to be copied. The SYSIN control statement identifies which active
| DBDSs to copy. These can be either the A-through-J data set or the M-through-V
| data sets.
Restriction: The GENJCL.OIC command and online image copy cannot be used on
databases at an RSR-tracking site.
GENJCL.OIC Syntax
GENJCL.OIC DBD(name) PSB(name)
GROUP(name) CHKINT(value) COPIES( 1 )
2

DDN(ddname) , JCLOUT
JCLOUT( ddname )
DEFAULTS( member )
JOB NOLIST

JCLPDS JOB(member) LIST MEMBER(member)
MULTIJOB

ONEJOB NODEFLT TIMEFMT(sublist) 3400
UNIT( unittype )

3400 ,
UNIT2( unittype )
%key2

, ,
VOLLIST( volser ) VOLLIST2( volser )
Parameters for GENJCL.OIC

Mutually exclusive, required parameters that you use to specify the DBDS or
DEDB area that is to be copied.

GENJCL.OIC
DBD
Specifies the name of the DBDS or DEDB area that is to be copied.
Restriction for HALDBs: For the GENJCL.OIC command, name specifies the
name.
GROUP
Specifies that all DBDSs of a DBDS group are to be copied. If GROUP is
specified, the GENJCL.OIC command executes repeatedly, once for each
DBDS of the DBDS group.
PSB(name)
Required parameter you use to specify the name of the PSB that is required for
a run of the Online Database Image Copy utility.
If you specify GROUP, the same PSB name is used for all members of the
group.
CHKINT(value)
Optional parameter you use to specify the checkpoint interval for the Online
Database 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
own default value for the checkpoint interval.
COPIES(1 | 2)
Optional parameter you use to request that the Online Database Image Copy
utility in order to produce one or two image copy data sets for the specified
DBDS.
If the specified DBDS is identified in RECON with the NOREUSE attribute,
you must specify the COPIES parameter in order to produce two image copy
data sets; otherwise, one image copy data set is produced.
If the specified DBDS is identified in RECON with the REUSE attribute, you
cannot specify a COPIES parameter; the number of image copy data sets that
are produced for this DBDS is determined by parameters in the INIT.IC
command.
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. If
DDN is not specified, the GENJCL.OIC command executes repeatedly, once for
each 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 in
the HALDB master. If you specify a HALDB partition name, the GENJCL.OIC
command is performed for all data DBDSs of the identified HALDB partition.
the partition DDN. The GENJCL.OIC command is performed for the identified
DBDS of the partition. The GENJCL.OIC command fails if DDN does not identify
a data DBDS in the partition.
DEFAULTS (member)
members to be used when generating JCL. Default members are searched in
order to resolve keywords in the order in which the members are specified on
this parameter.

GENJCL.OIC

not the same data set used for the default, JCLOUT.
JCLPDS (JCLPDS | ddname)
DD statement with this ddname must be included in the job step that contains
the GENJCL command.
JOB
NOJOB
LIST | NOLIST
LIST
NOLIST
MEMBER(member)
member that is to be used. For a description of the IBM-supplied execution
member, see “Generating JCL and User-Defined Output” on page 83. If this
parameter is not specified, the default specified on the INIT.DBDS command is
used.
MULTIJOB | ONEJOB
statements are to be generated when a DBDS group is specified either
explicitly or implicitly.
MULTIJOB
Processes the skeletal JCL JOB member for each group member (multiple
JOB statements are to be produced).
ONEJOB
Processes 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 not

specified.

GENJCL.OIC
NODEFLT
TIMEFMT(sublist)
Related Reading:
Optional parameter you use to specify the unit type of the primary output data
set. This parameter is valid only if:
v The VOLLIST parameter was specified.
NOREUSE option.
Optional parameter you use to specify the unit type of the secondary output
data set. This parameter is valid only if:
v The VOLLIST2 parameter was specified.
NOREUSE option.
%key1
'value'
%key2

GENJCL.OIC

86.
VOLLIST(volser)
Optional parameter you use to specify the volumes on which the image copy
data set is to reside. This parameter is valid only if the DBDS for which the
JCL is being generated is defined with the NOREUSE option, and if the DBDS
is being used with DBDs, not with groups.
VOLLIST2(volser)
Optional parameter you use to specify the volumes on which the duplicate
image copy data set is to reside. This parameter is valid only if the DBDS for
which the JCL is being generated is defined with the NOREUSE option, and if
the DBDS is being used with DBDs, not with groups.
Examples of Running the Online Database Image Copy Utility

Here are some examples of using the GENJCL.OIC command.
Example Using JCLPDS Member OICJCL: In this example, a GENJCL.OIC

command generates the JCL and control statements required to run the Online
Database Image Copy utility for the DBDS identified in the DBD and DDN
parameters. The database is defined as REUSE. If the INIT.DBDS command for the
DBDS for which the JCL is being generated is specified with OICJCL(member), that
member is used and is found in the data set identified in the JCLPDS DD
statement. If not, default skeletal member OICJCL from the JCLPDS data set is
used. Output from the generated JCL goes to the data set defined in the JCLOUT
DD statement. Skeletal member JOBJCL produces a job statement.
//GENJOIC JOB
//JCLPDS DD . . .
//JCLOUT DD . . .
.
.
.
//SYSIN DD *
GENJCL.OIC DBD(DBDKSDS1) DDN(DDNKSDS1) -
PSB(MYJOB)
/*
Example Using JCLPDS Member OICJCL2: In this example, the GENJCL.OIC

command generates JCL and control statements to run the Online Image Copy
utility for all DBDSs of GROUP1. The skeletal member used is OICJCL2 from the
data set identified in the OICPDS DD statement. One job statement for each group
member is generated from the JOBCARD member found in the data set identified
in the OICPDS DD statement. %DEFDBDS is a user-defined value in OICJCL2 and is
resolved with 'DATABASE DEFINED HERE'. Members DEF1, 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 parameter for a keyword
override the values found in the DEFAULTS member.
//GENJOIC1 JOB
//OICOUT DD . . .
//OICPDS DD . . .
//SYSIN DD *

GENJCL.OIC
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
Use the GENJCL.RECEIVE command to apply an image copy from an RSR active site
to a database data set or area at an RSR tracking site. This command generates the
JCL and utility control statements required to run the database recovery utility for
image copy receive. If more than one image copy data set is registered in the
RECON for a given DBDS or area, the most recent usable image copy data set is
received. 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 2
utility 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 tracking
service group.
Important: For HALDB partitions, the GENJCL.RECEIVE command treats ILDS and
index data sets differently than data DBDSs. The GENJCL.RECEIVE command skips
these data sets in groups, regardless of whether the groups are explicit or implicit.
If you explicitly specify one of these data sets, the GENJCL.RECEIVE command fails.
For information about the IBM-supplied skeletal JCL execution member that is
used by GENJCL.RECEIVE, see “Generating JCL and User-Defined Output” on page
83.
GENJCL.RECEIVE Syntax
GENJCL.RECEIVE DBD(name)
GROUP(name) , DDN(ddname)
AREA(name)
DEFAULTS( member )
JOB NOLIST


MEMBER(member) TIMEFMT(sublist)

,

%key2
Parameters for GENJCL.RECEIVE

Mutually exclusive, required parameters that you use to specify the database
that is to be received.

GENJCL.RECEIVE
DBD
Specifies the name of the database to be received. The database must be
RSR-covered.
Restriction for HALDBs: For the GENJCL.RECEIVE command, name specifies
the name of either a HALDB master database name or a HALDB partition
name.
GROUP
Specifies that image copies for all DBDSs of a DBDS or CA group are to be
received. If GROUP is specified, the GENJCL.RECEIVE command executes
repeatedly, once for each DBDS of the DBDS or CA group. If you attempt
an implicit or explicit group execution with recoverable and
nonrecoverable DBDSs, JCL is not generated for the nonrecoverable DBDSs.
If GROUP is specified, all DBDS areas of the group must be covered by the
same global service group.
DEFAULTS (member)
members that are to be used when generating JCL. Default members are
searched to resolve keywords in the order in which the members are specified
on this parameter.
If a keyword is assigned a value in both the DEFAULTS and the USERKEYS
ddname or DEDB area to be received.
The DDN or AREA parameter is specified only if the DBD parameter is
specified.
the partition DDN. The GENJCL.RECEIVE command is performed for the
identified DBDS of the partition. The GENJCL.RECEIVE command fails if DDN
does not identify a data DBDS in the partition.
If DDN or AREA is not specified, the GENJCL.RECEIVE command executes
repeatedly, once for each DBDS or area of the specified database. If you specify
a HALDB master name, the GENJCL.RECEIVE command is performed for all
data DBDSs for each HALDB partition in the HALDB master. If you specify a
HALDB partition name, the GENJCL.RECEIVE command is performed for all
data DBDSs of the identified partition.
not the same data set that is used for the default (JCLOUT).
the GENJCL command.

GENJCL.RECEIVE

JOB
without a member name, the IBM-supplied execution member ICRCVJCL
NOJOB
LIST | NOLIST
LIST
NOLIST
MEMBER(member)
member that is to be used. For a description of the IBM-supplied execution
member, see “Generating JCL and User-Defined Output” on page 83. If this
parameter is not specified, the default specified on the INIT.DBDS command is
used.
TIMEFMT(sublist)
Related Reading:
%key1
'value'

GENJCL.RECEIVE
%key2

86.
Examples of Running the Database Recovery Utility to Receive

an Image Copy
Here are some examples of using the GENJCL.RECEIVE command.
Example for the DBDS Identified by the DBD and DDN Parameters: In this
example, a GENJCL.RECEIVE command generates the JCL and control statements that
are required to run the database recovery utility to receive an image copy 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, is
specified with RECVJCL(member), that member is used and is found in the data set
that is identified in the JCLPDS DD statement. If not, default skeletal member
RECVJCL, from the JCLPDS data set is used. Output from the generated JCL goes
to the data set that is identified in the JCLOUT DD statement. Skeletal member
//GENJRCVE JOB
//JCLPDS DD . . .
//JCLOUT DD . . .
.
.
.
//SYSIN DD *
GENJCL.RECEIVE DBD(DBESDSA) DDN(DDESDSA)
/*
Example for All DBDSs in a Group: In this example, the GENJCL.RECEIVE

command generates JCL and control statements to run the database recovery utility
to receive image copies for all DBDSs of GROUP1.
The skeletal member used is RCVJCL2 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 RCVJCL2,
which resolve to 'DEFINE DB1' and 'DEFINE DB2'. Default members DEF1, DEF2,
and DEF3 are used to resolve user-defined keywords in RECJCL2. The default
member for the DBDS, if initialized in the INIT.DBDS DEFLTJCL(MEMBER)
command, is also used to resolve keywords. The values in the explicitly defined
DEFAULTS members override values in the predefined DEFLTJCL member. The
values specified in the USERKEYS parameter for a keyword override the values
found in the DEFAULTS members.
//GENJRCV1 JOB
//OUT DD . . .
//PDS DD . . .

GENJCL.RECEIVE
//SYSIN DD *
GENJCL.RECEIVE GROUP(GROUP1) MEMBER(RCVJCL2) -
JCLPDS(PDS) JCLOUT(OUT) -
USERKEYS((%DEFDBD1,'DEFINE DB1'),(%DEFDBD2,'DEFINE DB2')) -
GENJCL.RECOV
Use the GENJCL.RECOV command to generate the JCL and utility control statements
required to run the database recovery utility. You can request the JCL and utility
control statements for a full recovery or a time-stamp recovery of a specified DBDS
or area. All log data must be archived; otherwise the GENJCL.RECOV command fails.
Restrictions:
v A nonstandard image copy data set cannot be used as input to the database
recovery utility. The procedure for recovering a database with a nonstandard
image copy is slightly different depending on whether the IMS system is an
active or tracking subsystem.
v A GENJCL.RECOV command cannot be issued for a user-recoverable database.
Active subsystem
1. Restore the DBDS from the nonstandard image copy.
2. Record this restoration by entering a NOTIFY.RECOV command with the
image 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
1. Restore the DBDS from the nonstandard image copy. This must be the
latest recorded image copy.
2. Record this restoration by entering a NOTIFY.RECOV command with the
image copy run time as the RUNTIME parameter and the USID from
the image copy as the RUNUSID parameter.
3. Issue a /START command for the database. Online forward recovery
(OFR) automatically completes, applying changes made since the image
copy.
For information about the IBM-supplied skeletal JCL execution member used by
GENJCL.RECOV, see “Generating JCL and User-Defined Output” on page 83.
Use the RESTORE parameter to recover DBDSs that were designated as

nonrecoverable.
Important: For HALDB partitions, the GENJCL.RECOV command treats ILDS and
index data sets differently than data DBDSs. The GENJCL.RECOV command skips
these data sets in groups, regardless of whether the groups are explicit or implicit.
If you explicitly specify one of these data sets, the GENJCL.RECOV command fails.
Restriction: The GENJCL.RECOV command does not support ILDS and index data
sets. To generate JCL for the HALDB Index/ILDS Rebuild Utility (DFSPREC0), use
the GENJCL.USER command. See “Sample JCL for HALDB INDEX/ILDS Rebuild
Utility (DSPUPJCL)” on page 470 for information about IBM-supplied sample JCL
that you can use.

GENJCL.RECOV
GENJCL.RECOV Syntax
GENJCL.RECOV DBD(name)
GROUP(name) , DDN(ddname)
AREA(name)
DEFAULTS( member )
JOB NOLIST

MULTIJOB

MEMBER(member) ONEJOB NODEFLT RCVTIME(time_stamp) RESTORE
USEIC

TIMEFMT(sublist) USEDBDS ,
USEAREA
USEOLRRG USERKEYS( ( %key1, 'value' ) )
%key2
Parameters for GENJCL.RECOV

Mutually exclusive, required parameters that you use to specify the DBDSs
that are to be recovered.
DBD
Specifies the database name of the DBDSs to be recovered.
Restriction for HALDBs: For the GENJCL.RECOV command, name specifies
the name of either a HALDB master database name or a HALDB partition
name.
GROUP
Specifies that all DBDSs of a DBDS or CA group are to be recovered. If
GROUP is specified, the GENJCL.RECOV command executes repeatedly for
each DBDS of the DBDS or CA group. If you attempt an implicit or explicit
group execution with recoverable and nonrecoverable DBDSs (and
RESTORE is not specified), JCL is not generated for the nonrecoverable
DBDSs.
DEFAULTS (member)
members to be used when generating JCL. Default members are searched to
resolve keywords in the order in which the members are specified on this
parameter.
If a keyword is assigned a value in both the DEFAULTS and the USERKEYS
ddname or DEDB area to be recovered.
The DDN or AREA parameter is specified only if the DBD parameter is
specified.

GENJCL.RECOV
the partition DDN. The GENJCL.RECOV command is performed for the identified
DBDS of the partition. The GENJCL.RECOV command fails if DDN does not
identify a data DBDS in the partition.
If DDN or AREA is not specified, the GENJCL.RECOV command executes
repeatedly for each DBDS or area of the specified database. If you specify a
HALDB master name, the GENJCL.RECOV command is performed for all data
DBDSs for each HALDB partition in the HALDB master. If you specify a
HALDB partition name, the GENJCL.RECOV command is performed for all data
not the same data set used for the default (JCLOUT).
the GENJCL command.
JOB
NOJOB
LIST | NOLIST
LIST
NOLIST
MEMBER(member)
member to be used. For a description of the IBM-supplied execution member,
see “Generating JCL and User-Defined Output” on page 83. If this parameter is
not specified, the default specified on the INIT.DBDS command is used.
MULTIJOB | ONEJOB
statements are generated when a DBDS group is specified either explicitly or
implicitly.
MULTIJOB
JOB statements are produced).

GENJCL.RECOV
ONEJOB
Processes the skeletal JCL JOB member only for the first group member.
These parameters are invalid if NOJOB is specified or a DBDS group is not

specified.
NODEFLT
RCVTIME(time_stamp)
Optional parameter you use to specify a time-stamp recovery, which is a
partial recovery 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 recent state.
A valid time stamp for a partial recovery is any point at which there are no
allocations of the DBDS or area and there is not a merge of logs needed that
cannot be resolved by running the change accumulation utility.
Attention: An allocation that has no de-allocation time recorded persists until
the stop time of the current log.
Related Reading:
v See “Using the %SET TIMEFMT Keyword” on page 93 for more information
on full recovery.
v See IMS Version 9: Operations Guide for more information about time-stamp
recoveries.
RESTORE
Optional parameter used to generate JCL for a database data set that is
designated as nonrecoverable. If the last image copy was taken before the
DBDS was designated as nonrecoverable, normal recovery JCL is generated to
recover the DBDS up to the point of the recovery-status change. If the last
image copy was taken after the DBDS was designated as nonrecoverable, the
generated JCL uses only the image copy for recovery.
If you attempt an implicit or explicit group execution with recoverable and
nonrecoverable DBDSs (and RESTORE is specified), JCL is generated only for
the nonrecoverable DBDSs.
Do not specify RESTORE for a recoverable DBDS.
TIMEFMT(sublist)
Related Reading:

GENJCL.RECOV
| USEIC | USEDBDS | USEAREA | USEOLRRG
| Mutually exclusive, optional parameters that you use to specify the starting
| point of the requested recovery action.
| USEIC
| Starts the recovery with an image copy data set. You can then apply
| subsequent changes that occurred in the DBDS.
| USEIC is the default.
| USEDBDS
| Recovery is performed using only the changes that have occurred to the
| DBDS in its current state. An image copy data set is not used as input to
| this recovery. You can specify the USEDBDS parameter only if you also
| specify the DBDS parameter, and only after performing a time-stamp
| recovery in which an image copy data set is used as input.
| USEAREA
| Recovery is performed using only the changes that have occurred to the
| DEDB area in its current state. An image copy data set is not used as input
| to this recovery. You can specify USEAREA only if you also specify the
| AREA parameter, and only after performing a time-stamp recovery in
| which an image copy data set is used as input.
| USEOLRRG
| Starts the recovery with a HALDB Online Reorganization updates.
| You can use these parameters to recover a DBDS or area to a specified time
| stamp using an image copy data set and then apply the changes that have
| occurred since the image copy by specifying an additional recovery using the
| USEDBDS or USEAREA parameter.
| Restriction: If this required time-stamp recovery restored the DBDS or DEDB
| area to a time that falls within an existing time-stamp recovery’s range (the
| time between the RECOV TO and RUN times), then the USEDBDS or
| USEAREA parameter is invalid.
%key1
'value'
%key2

GENJCL.RECOV

86.
Examples of Running the Database Recovery Utility

Here are some examples of using the GENJCL.RECOV command.
Example for the DBDS Identified in the DBD and DDN Parameters: In this
example, a GENJCL.RECOV command generates the JCL and control statements
required to run the database recovery utility for the DBDS identified in the DBD
and DDN parameters. The USEIC parameter indicates that the time-stamp recovery
starts with an image copy data set and ends with the log data set that has the stop
time stamp specified in the RCVTIME parameter.
If the INIT.DBDS command for the DBDS for which the JCL is being generated is
specified with RECOVJCL(member), that member is used and is found in the data
set identified in the JCLPDS DD statement. If not, default skeletal member
RECOVJCL from the JCLPDS data set is used. Output from the generated JCL goes
to the data set identified in the JCLOUT DD statement. Skeletal member JOBJCL
//GENJRCOV JOB
//JCLPDS DD . . .
//JCLOUT DD . . .
.
.
.
//SYSIN DD *
GENJCL.RECOV DBD(DBESDSA) DDN(DDESDSA) USEIC -
RCVTIME(821001212130)
/*
Example for All DBDSs in a Group: In this example, the GENJCL.RECOV command
generates JCL and control statements to run the database recovery utility for all
DBDSs of GROUP1. The skeletal member that 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 resolve
to 'DEFINE DB1' and 'DEFINE DB2'. Default members DEF1, DEF2, and DEF3 are
used to resolve user-defined keywords in RECJCL2. The default member for the
DBDS, if initialized in the INIT.DBDS DEFLTJCL(MEMBER)command, is also used to
resolve keywords. The values in the explicitly defined DEFAULTS members
override values in the predefined DEFLTJCL member. The values specified in the
USERKEYS parameter for a keyword override the values found in the DEFAULTS
members.
//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')) -

GENJCL.USER
GENJCL.USER
Use the GENJCL.USER command to generate JCL or any kind of user output. You
must provide the skeletal JCL execution member that is needed for the
GENJCL.USER command. For more information, see “Generating JCL and
User-Defined Output” on page 83.
GENJCL.USER Syntax
GENJCL.USER MEMBER(name)
DBD(name) DDN(ddname)
GROUP(name)
JCLOUT(JCLOUT) JCLPDS(JCLPDS) JOB

, JCLOUT(ddname) JCLPDS(ddname) JOB(member)
NOJOB
DEFAULTS( member )
NOLIST MULTIJOB

LIST ONEJOB NODEFLT PARTONLY PSB(name) SSID(name)

TIMEFMT(sublist) ,

%key2
Parameters for GENJCL.USER

MEMBER(name)
Required parameter you use to specify the name of the skeletal JCL execution
member that is used to generate output. You must have already supplied the
execution member.
The name can be any valid member name for a partitioned data set. If the
specified member does not exist in the skeletal JCL data set, the command
fails.
Mutually exclusive, optional parameters that you use to set the value of the
%dbname keyword.
DBD
If you specify DBD without the DDN parameter, the GENJCL.USER
command executes repeatedly for each DBDS or the specified database.
Restriction for HALDBs: For the GENJCL.USER command, name specifies the
name. You can use this parameter to set the value of the %dbname keyword
to be either a HALDB master name or a HALDB partition name. If you use
a HALDB master name, the GENJCL.USER command is performed for all
data DBDSs for each HALDB partition in the HALDB master. If you use a
HALDB partition name, the GENJCL.USER command is performed for all
GROUP
If you specify GROUP, the GENJCL.USER command executes repeatedly, once

GENJCL.USER
for each DBDS of the specified DBDS group. For each repeated execution,
the DBD and DDN parameters are set to the corresponding group member.
If you specify neither DBD nor GROUP, the value of the %dbname keyword is
null unless a value is assigned in the USERKEYS parameter or a skeletal JCL
default member.
DDN(name)
Optional parameter you use to set the value of the %ddname keyword. If you do
not specify DDN, the value of the %ddname keyword is null unless a value is
assigned in the USERKEYS parameter or a skeletal JCL default member.
parameter in order to use the DDN parameter. In this case, the DDN is the
partition DDN. The GENJCL.USER command is performed for the identified
DBDS of the partition. The GENJCL.USER command fails if DDN does not
identify a DBDS in the partition.
You cannot specify DDN if you also specify GROUP.
DEFAULTS(member)
members to be used when generating JCL or other user-defined output.
Default members are searched to resolve keywords in the order in which the
members are specified on this parameter.
JCL or other user-defined output. The data set is specified by ddname. A JCL
the GENJCL.USER command. The specified data set can be a member of a
partitioned data set, but only if it is not the same data set that is used for the
default (JCLOUT).
used for input when generating the JCL or other user-defined output. The data
set is specified by ddname. A JCL DD statement with this ddname must be
included in the job step containing the GENJCL.USER command.
JOB
NOJOB
LIST | NOLIST
LIST

GENJCL.USER
NOLIST
MULTIJOB | ONEJOB
statements are generated when a DBDS group is specified either explicitly or
implicitly.
MULTIJOB
JOB statements are produced).
ONEJOB
Only 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 not

specified.
NODEFLT
member, if any, for the DBDS is not to be used. If you do not specify GROUP
or DBD, this parameter is ignored.
PARTONLY
Optional parameter you use to specify that only the HALDB partitions are to
be processed instead of all data DBDSs for each HALDB partition. PARTONLY
is only meaningful for HALDB. If the specified DBD is not a HALDB master
name or a HALDB partition name then this parameter is ignored. This
parameter sets the value of %mdbname to the HALDB master name and
%dbname to the HALDB partition name.
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 PSB ddname.
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 value
is assigned in the USERKEYS parameter or a skeletal JCL default member.
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 IMS
subsystem 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 JCL
default member.
TIMEFMT(sublist)
Related Reading:

GENJCL.USER

%key1
'value'
%key2

86.
Example of Running DBRC

In this example, the GENJCL.USER command generates JCL from member USER4 in
the data set that is identified in DD statement MYJCLPDS. Output from the
generated JCL goes to the data set identified in DD statement JCLOUT.
Substitutions for %SSID, %DBNAME and %DDNAME should be made. Skeletal member
//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

GENJCL.USER
//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
Use the INIT commands to make the following changes to a RECON:
v Create entries
v Create CA groups
v Register DBDSs or DEDB areas
v Define global service groups
v Register HALDB partitions
v Initialize a RECON
INIT Commands In This Chapter

The following is a list of all the INIT commands:
v “INIT.ADS”
v “INIT.CA” on page 265
v “INIT.CAGRP” on page 266
v “INIT.DB” on page 268
v “INIT.DBDS” on page 271
v “INIT.DBDSGRP” on page 276
v “INIT.GSG” on page 277
v “INIT.IC” on page 278
v “INIT.PART” on page 280
v “INIT.RECON” on page 284
v “INIT.SG” on page 289
INIT.ADS
Use the INIT.ADS command to create an entry in the RECON data set that defines
an ADS (area data set) that belongs to an area. An area can consist of a maximum
of seven data sets.
| Before you issue the INIT.ADS command, you must create the area and database
| records in the RECON data set. Use the INIT.DBDS command to register the area. If
| the ADDN or ADSN names are not unique for this area, the INIT.ADS command
| fails. When you register the area, the area status is set as recovery needed to
| prevent inadvertent use by the IMS online system before you have completed
| registration of the required ADSs. While an area has a recovery needed status, you
| can create the ADS records in the RECON data set, but you must create them as
| unavailable by issuing the command INIT.ADS UNAVAIL. However, you can create
| an ADS that is immediately available if you first remove the recovery needed status
| from the area with the CHANGE.DBDS NORECOV command and then create the ADS by
| issuing the INIT.ADS AVAIL command.
| To create multiple copies of an area data set, issue multiple INIT.ADS commands
| that have the same area name, as recorded in the RECON data set.

INIT.ADS
INIT.ADS Syntax
UNAVAIL
INIT.ADS ADDN(name) ADSN(name) AREA(name) DBD(name)
AVAIL
Parameters for INIT.ADS

ADDN(name)
Required parameter you use to identify the ADS that is being identified to
DBRC by its ddname.
ADSN(name)
Required parameter you use to identify the ADS that is being identified to
DBRC by its data set name.
AREA(name)
Required parameter you use to identify the area name for which an ADS is
being identified to DBRC.
DBD(name)
Required parameter you use to identify that area by database name for which
an ADS is being identified to DBRC.
AVAIL | UNAVAIL
Mutually exclusive, optional parameters that you use to indicate whether the
ADS record is available.
AVAIL
Makes the ADS status available. The INIT.ADS AVAIL command fails if you
issue it when the area is in use or if the area needs to be recovered.
UNAVAIL
Makes the ADS status unavailable.
Examples of Creating a Record That Defines an ADS

In 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)
/*
In this example, a record is created in the RECON data set that defines a single
area data set:
|| //INITADS
. JOB
|| .
.
| //SYSIN DD *
| INIT.DB DBD(DEDBJN21) SHARELVL(1) TYPEFP
| INIT.DBDS DBD(DEDBJN21) AREA(DB21AR0) GENMAX(2) VSO PRELOAD
| INIT.ADS DBD(DEDBJN21) AREA(DB21AR0) ADSN(IMSTESTL.DB21AR01) -
| ADDN(DB21AR01)
Example of Creating a Record That Defines Multiple Area Data

Sets (MADSs)
In this example, a record is created in the RECON data set that identifies multiple
area data sets (MADSs) that are associated with the following information:

INIT.ADS
|| //INITADS
. JOB
|| .
.
| //SYSIN DD *
| INIT.DB DBD(DEDBJN21) SHARELVL(1) TYPEFP
| INIT.DBDS DBD(DEDBJN21) AREA(DB21AR0) GENMAX(2) VSO PRELOAD
| ADDN(DB21AR01)
| ADDN(DB21AR02)
| ADDN(DB21AR03)
| /*
INIT.CA
Use an INIT.CA command to create a record in RECON that identifies a change
accumulation data set that is available for future use by the Change Accumulation
utility in processing the specified CA group. You can create such change
accumulation records only for those CA groups that have been defined with the
REUSE option of the INIT.CAGRP command. You can create change accumulation
records in RECON up to the number specified in the GRPMAX parameter of the
INIT.CAGRP command that you used to define the CA group.
INIT.CA Syntax
,
INIT.CA CADSN(name) GRPNAME(name) VOLLIST( volser )

1
FILESEQ( value )

3400
UNIT( unittype )
Parameters for INIT.CA

CADSN(name)
Required parameter you use to specify the name of the change accumulation
data set for which you are creating a record in RECON. The name you
substitute in the variable field can be up to 44 characters. You can use the
default naming convention for change accumulation data sets to assign this
name.
GRPNAME(name)
you are creating the record. The GRPNAME keyword must specify the name of
a CA group that is already defined in RECON.
VOLLIST(volser)
Required parameter you use to specify the volume serial numbers of the
volumes on which the change accumulation data set being defined are to
reside. You can substitute from 1 to 255 volume serial numbers in the variable
field; each can be up to six alphanumeric characters long, and they must
follow z/OS JCL conventions for volume serial numbers.
FILESEQ(1 | value)
Optional parameter you use to specify the file-sequence number of the change
accumulation data set that is being defined.
Chapter 12. INIT Commands 265

INIT.CA
value must be a decimal number from 1 to 9999.

Optional parameter you use to specify the unit type of the volumes on which
the change accumulation data sets are to reside. The unit type can be up to
eight alphanumeric characters.
Example of Creating a Record That Defines a CA Data Set

In this example, a record is created in RECON that identifies a change
accumulation data set (identified by the CADSN parameter). This change
accumulation data set is being created for use by a subsequent run of the Change
Accumulation utility for the CA group identified in the GRPNAME parameter.
Creation of this record implies that the identified CA group was defined with a
REUSE parameter.
//INITCA JOB
.
.
.
//SYSIN DD *
INIT.CA GRPNAME(CAGRP1) -
CADSN(IMS.CAGRP1.CA.CA001) -
VOLLIST(VOL001) FILESEQ(4)
/*
INIT.CAGRP
Use an INIT.CAGRP command to specify the DBDSs that are to belong to a specified
CA group. You must have created a record in RECON with an INIT.DBDS
command for each DBDS in the CA group before you assign it to a CA group.
Each DBDS can belong to only one CA group.
Restriction: Index and ILDS DBDSs are not recoverable, and changes to them are
not logged. The INIT.CAGRP command does not support these data sets.
INIT.CAGRP Syntax
,
INIT.CAGRP GRPMAX(value) GRPMEM( (dbdname,ddname) ) GRPNAME(name)
NOREUSE

CAJCL DEFLTJCL( DEFLTJCL ) REUSE
CAJCL( member ) member
Parameters for INIT.CAGRP

GRPMAX(value)
Required parameter you use to specify the maximum number of change
accumulation data sets that DBRC is to maintain for the specified CA group.
When the number of times you run the Change Accumulation utility for the
specified group exceeds the GRPMAX value, the record of the earliest change
accumulation run for the group is deleted if you specify the NOREUSE
keyword for this CA group. The record of the earliest change accumulation run
is reused if you specify the REUSE keyword for this CA group.

INIT.CAGRP
GRPMEM(dbdname,ddname)
Required parameter you use to specify the names of the DBDSs that are to be
members of the CA group you are defining.
There can be from 1 to 32767 members in a CA group. The names you
substitute 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 set
ddname.
Restrictions:
v When using the INIT.CAGRP command for HALDBs, dbdname specifies the
v User-recoverable databases cannot be added to a CA group.
GRPNAME(name)
Required parameter you use to specify the name of the CA group being
created. name can be up to eight alphanumeric characters, and it must not be
the 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 partitioned
data set of skeletal JCL. You create this member to be used to generate the JCL
required to run the Change Accumulation utility for the CA group being
created.
DEFLTJCL(DEFLTJCL | member)
Optional parameter you use to specify an implicit skeletal JCL default member
for the CA group. The specified member is used by the GENJCL.CA command to
resolve keywords you have defined.
NOREUSE | REUSE
Mutually exclusive, optional parameters that you use to specify whether the
change accumulation data sets for the CA group being defined can be reused.
REUSE
Indicates that the Change Accumulation utility is to reuse the oldest
change accumulation data set and record (for the group being defined)
when the GRPMAX value for the group is exceeded. Reuse means that the
Change Accumulation utility uses the same physical space, volumes, data
set name, and record in RECON for the new change accumulation data set
as were used for the oldest change accumulation data set in the group.
NOREUSE
Indicates that the change accumulation data sets in this group are not to be
reused by the Change Accumulation utility.
Example of Creating a CA Group

In this example, a CA group is being created. A maximum of 15 change
accumulation data sets are to be maintained for this group. (This is indicated in the
GRPMAX parameter.) The NOREUSE parameter indicates that change
accumulation data sets for this group are not to be reused by the Change
Accumulation utility when the GRPMAX value has been reached. That parameter
also implies that empty change accumulation data sets cannot be defined for this
group for use in future runs of the Change Accumulation utility.
//INITCAGP JOB
.
.
.
//SYSIN DD *
INIT.CAGRP GRPNAME(CAGRP1) GRPMAX(15) NOREUSE -

INIT.CAGRP
GRPMEM((DB1,DD1) (DB2,DD2) (DB3,DD3) -

(DB4,DD4) (DB5,DD5) (DB6,DD6) (DB7,DD7) -
(DB8,DD8) (DB9,DD9) (DB10,DD10))
/*
INIT.DB
Use an INIT.DB command to register a database with DBRC and specify the level
of database sharing. A database must be registered with DBRC before you can
initialize a new DBDS, HALDB partition, or DEDB area with the INIT.DBDS
command or INIT.PART.
| When you issue an INIT.DB command for a HALDB partition (TYPE=PART), the
| following fields are set as defaults:
| v OLREORG CURSOR ACTIVE =NO
| v OLRIMSID=**NULL**
| v ACTIVE DBDS=A-J
INIT.DB Syntax
RECOVABL 0
INIT.DB DBD(name) SHARELVL( 1 )
ICREQ 2
NONRECOV 3
NOICREQ
USERRCOV
TYPEIMS DBTRACK

TYPEFP GSGNAME(gsgname) RCVTRACK
OLRCAP
TYPHALDB
OLRNOCAP HIKEY
PARTSEL(pgmname)
Parameters for INIT.DB

DBD(name)
Required parameter you use to specify the database name of the database to be
registered in RECON.
Restriction for HALDBs: For the INIT.DB command, name specifies the name
of a HALDB master database.
DBTRACK | RCVTRACK
Mutually 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 is
specified.
v Specifying DBTRACK has no effect if the tracking subsystem is a recovery
readiness level (RLT) subsystem.
DBTRACK
Indicates database readiness tracking.
RCVTRACK
Indicates recovery readiness tracking.

INIT.DB
GSGNAME(gsgname)
Optional parameter used to specify to which global service group a database is
to be assigned.
GSGNAME cannot be specified if TYPEFP is specified.
ICREQ | NOICREQ
Mutually exclusive, optional parameters used to specify whether DBRC should
enforce the requirement of taking an image copy of a non-recoverable or
user-recoverable database after it has been loaded or reorganized. This option
affects all DBDSs within the DB.
ICREQ
Default value that turns on IC NEEDED in the DBDS record and
increments the IMAGE COPY NEEDED COUNT in the DB record
following initial load (PROCOPT=L) or REORG of the DBDS.
NOICREQ
Turns off the IC NEEDED requirement. DBRC will not turn on IC
NEEDED in the DBDS record or increment the IMAGE COPY NEEDED
COUNT in the DB record following initial load or REORG of the DBDS.
The IC NEEDED flag can still be set manually with the CHANGE.DBDS ICON
command.
Requirement: When NOICREQ is specified, NONRECOV or USERRCOV
must also be specified.
NONRECOV | RECOVABL | USERRCOV
Mutually exclusive, optional parameters used to specify whether DBRC can
record the updates in the RECON for the data sets of the specified databases.
NONRECOV
Specifies that no record of the updates for the data sets of the specified
database are to be kept in the RECON.
RECOVABL
Specifies that the update allocations on the database are to be written in
the RECON.
USERRCOV
Specifies that update allocations for the Fast Path database are not to be
recorded in the RECON. Database updates are logged, however, DBRC will
not be able to manage recovery for the database. Recovery is allowed with
JCL manually generated by the user. This parameter is only valid for
TYPEFP. USERRCOV cannot be specified for an RSR-covered database.
Notes:
1. USERRCOV should only be used if a critical need to reduce database
open time exists and recoverability is require.
2. USERRCOV requires the user to provide their own manually-created
JCL for change accumulation and recovery.
Restrictions:
v If the database is registered as RECOVABL or USERRCOV, VIO or DD
DUMMY data sets cannot be used for the output log (IEFRDER) in any job
that updates the database. Temporary log data sets, such as VIO data sets,
are deleted at job termination, so they are not usable for recovery.
v NONRECOV or USERRCOV cannot be specified if GSGNAME is specified.
v You cannot make concurrent image copies of non-recoverable or
user-recoverable databases.

INIT.DB
SHARELVL(0 | 1 | 2 | 3)
Optional parameter you use to specify the level of data sharing for which
authorized subsystems can share a database. For a description of the levels of
data sharing, see “Assigning a Sharing Level with DBRC” on page 17.
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 the
VSAM SHAREOPTIONS (3 3) parameter is also specified.
For more information on coordinating VSAM data set definitions with share
options, see IMS Version 9: Administration Guide: System.
| TYPEFP | TYPEIMS | TYPHALDB
| Mutually exclusive, optional parameters that you use to specify whether the
| database is a Full Function, Fast Path DEDB, or a HALDB.
| TYPEFP
| Specifies that the database is Fast Path DEDB.
| TYPEIMS
| Specifies that the database is a DL/I database (non-HALDB).
| TYPHALDB
| Specifies that the database is a DL/I database (HALDB). When you issue a
| INIT.DB TYPHALDB command, the IMS DBDLIB data set must be identified
| in the job stream for the Database Recovery Control utility with a ddname
| of IMS.
| OLRCAP | OLRNOCAP
| Mutually exclusive, optional parameters used to indicate that HALDB
| OLR is allowed to run on that database.
| OLRCAP Specifies in the master database record and in the
| partition database record that HALDB OLR is allowed
| to run on that database. This is the default (except for
| a PSINDEX, which is always OLRNOCAP).
| OLRNOCAP Specifies in the master database record and in the
| partition database record that HALDB OLR is not
| allowed to run on that database.
| HIKEY | PARTSEL (pgname)
| Mutually exclusive, optional parameters that you use to identify
| whether the HALDB uses a Partition Selection Exit or high key values.
| This setting determines whether the KEYSTRNG parameter on the
| INIT.PART command defines a partition selection exit string or a high
| key value. These parameters are valid only with TYPHALDB.
| PARTSEL(pgmname)
| Specifies the name of the Partition Selection Exit program to be
| used for the HALDB. The pgmname is specified as a value up to 8
| characters long that is a valid program name.
| HIKEY
| Specifies that this HALDB uses high key values.
| If both PARTSEL and HIKEY are omitted, the HALDB will use the
| Partition Selection Exit module name (PSNAME) from the HALDB
| DBD. If no Partition Selection Exit module name was specified in the
| DBD, the HALDB will use high key values.

INIT.DB
Example of Creating a SHARELVL 1 DB Record

In this example, a new database record is created in RECON. This database has a
share level of 1.
//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 must
exist for any of the other commands to work for a given DBDS or DEDB area. In
order 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 its
database organization.
The IMS DBDLIB data set must be identified in the job stream for the Database
Recovery Control utility with a ddname of IMS.
The INIT.DBDS command fails if you issue it while the database is in use.
When you issue an INIT.DBDS command, DBRC sets the image copy status in the
DBDS record in the RECON to IC RECOMMENDED. After registering the DBDS,
you can reset the image copy status in the RECON by performing either of the two
following actions:
v Use the Image Copy utility to create a backup copy.
v Use the CHANGE.DBDS command to change the image copy status in the RECON
(see the explanations of the ICON and ICOFF parameters under
“CHANGE.DBDS” on page 152 for more information).
| Restriction for HALDBs: You cannot use the INIT.DBDS command to register
| DBDSs of HALDB databases. You must instead use either the HALDB Partition
| Definition utility or the INIT.DB and INIT.PART commands.
INIT.DBDS Syntax
| DBTRACK
| INIT.DBDS DBD(name) DDN(name) DSN(name) GENMAX(value)
AREA(name) RCVTRACK
| NOREUSE
|
DEFLTJCL(member) GSGNAME(gsgname) ICJCL REUSE
ICJCL( member )
| NOPREO
|
OICJCL PREOPEN RECOVJCL
OICJCL( member ) RECOVJCL( member )
|
| 0 RECVJCL
RECOVPD( value ) RECVJCL( member )

INIT.DBDS
| NOVSO

NOLKASID NOMAS NOPREL
VSO
CFSTR1(name) CFSTR2(name) LKASID MAS PRELOAD
|
Parameters for INIT.DBDS

DBD(name)
DEDB area being identified to DBRC.
Mutually exclusive, required parameters that you use to specify the ddname of
the DBDS or DEDB area being identified to DBRC.
DSN(name)
Required parameter you use with the DDN(name) parameter to specify the
data set name of the DBDS being identified to DBRC. You cannot use this
parameter with a DEDB area.
If the DBDS is an ADS that is registered to DBRC, do not specify this
parameter. Instead specify the data set name in the INIT.ADS command.
GENMAX(value)
Required parameter you use to specify the maximum number of image copies
that DBRC is to maintain for the identified DBDS.
Each time you run the Database Image Copy utility for the DBDS that is being
initiated, a new image copy is defined in RECON. If you identified the DBDS
with the NOREUSE parameter, the oldest image copy for the DBDS beyond the
recovery period is deleted when the number of image copies exceeds the
GENMAX value. If you identify the DBDS with the REUSE parameter, the
oldest image copy beyond the recovery period is reused.
DBTRACK | RCVTRACK
Mutually exclusive, optional parameters that you use to specify the type of
RSR tracking (shadowing) for an area that is assigned to a global service
group. Neither RCVTRACK nor DBTRACK can be specified without
GSGNAME and AREA.
Specifying DBTRACK has no effect if the tracking subsystem is a
recovery-readiness level (RLT) subsystem.
DBTRACK
RCVTRACK
DEFLTJCL(member)
for 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 is
to be assigned.
GSGNAME can only be specified if AREA is specified.

INIT.DBDS
ICJCL(ICJCL | member)
utility for the DBDS or DEDB area being identified.
NOREUSE | REUSE
supported image copy utilities are to reuse previously used image copy data
sets.
REUSE
Allows the GENJCL.IC command or the GENJCL.OIC command to generate a
job that causes the supported image copy utilities to reuse the oldest image
copy data set (for the DBDS being defined) when the GENMAX value for
the DBDS is exceeded. REUSE requires that you create empty image copy
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. The
NOREUSE parameter prohibits such actions.
NOREUSE
Prevents the automatic reuse of image copy data sets for this DBDS by the
supported image copy utilities.
If the NOREUSE option is specified for the HISAM database, the
image-copy-needed flag is not turned on at the end of the HISAM Reload
utilities. The input data set that is used while the HISAM database is being
reloaded is used as an image copy data set.
If you want HSSP image copy processing, you must specify REUSE. Reuse
means that the image copy job uses the same volumes, data set name, and
record in RECON for the new image copy data set as those of the oldest DBDS
image copy data set.
OICJCL(OICJCL | member)
data set that contains skeletal JCL. You cannot use this parameter with a DEDB
area. When you issue a GENJCL.OIC command, DBRC uses this member to
generate the JCL to run the Online Database Image Copy utility for the DBDS
being identified.
PREOPEN | NOPREO
Mutually exclusive, optional parameters that you use to specify whether an
area is to be opened after the first checkpoint following the next control region
initialization or when the next /START AREA command is processed. NOPREO is
the default, except if you specify PRELOAD, in which case PREOPEN is the
default.
PREOPEN
Indicates that the area is to be opened the next time the control region is
started or a /STA AREA command is processed. This option is valid for
both VSO and non-VSO areas.
NOPREO
Indicates that the area is not to be pre-opened the next time the control
region is started or a /START AREA command is processed. You cannot
specify NOPREO with PRELOAD.
RECOVJCL(RECOVJCL | member)

INIT.DBDS
data set of skeletal JCL. When you issue the GENJCL.RECOV command, DBRC
uses this member to generate the JCL that runs the Database Recovery utility
for the DBDS or area being identified.
RECOVPD(0 | value)
Optional parameter you use to specify the recovery period for a specified
DBDS or DEDB area.
The recovery period is the amount of time before the current date for which
DBRC maintains recovery information in the RECON data set. For example, if
the recovery period of a DBDS or area is 14 days, DBRC maintains sufficient
recovery-generation information for at least 14 days.
The recovery period is calculated as the current date minus the date of the
oldest image copy. If the image copies are dated within the days specified in
the RECOVPD(value), DBRC keeps them in the RECON.
For value, specify a decimal number from 0 to 999 that represent the number of
days the image copies are to be kept in RECON. If you specify 0 (the default),
there is no recovery period.
Related Reading: See IMS Version 9: Operations Guide for more information
about the recovery period of image copy data sets.
RECVJCL(RECVJCL | member)
be used by the GENJCL.RECEIVE command.
RECVJCL can be specified for both RSR-covered and non-covered DL/I DBDSs
and Fast Path areas.
VSO | NOVSO
Mutually exclusive, optional parameters that you use to specify whether an
area is to reside in virtual storage the next time the control region is initialized
or when the next /STA AREA command is processed.
VSO
Indicates that the area is to reside in virtual storage. Areas that are defined
with SHARELVL(0 | 1) are read into and written from a z/OS data space.
Areas defined with SHARELVL(2 | 3) use the coupling facility to share
data between connected subsystems.
CFSTR1(name)
Optional parameter you use to specify the name of the first coupling
facility structure for the identified area. z/OS coupling facility structure
naming conventions must be adhered to. This parameter is valid only
for VSO areas of DEDBs that are defined with SHARELVL(2 | 3). The
area name is the default if VSO is specified and the DEDB is
SHARELVL(2 | 3).
CFSTR2(name)
Optional parameter you use to specify the name of the second
coupling facility structure for the identified area. z/OS coupling facility
structure naming conventions must be adhered to. This parameter is
valid only for VSO area of DEDBs defined with SHARELVL(2 | 3).
There is no default.
| Restrictions: The name cannot be the area name if the CFSTR1
| keyword is not specified. CFSTR2 cannot be specified if MAS is
| specified.

INIT.DBDS
Related Reading: See IMS Version 9: Administration Guide: Database

Manager for details on CFSTR (coupling facility structure) naming
conventions.
LKASID | NOLKASID
Mutually exclusive optional parameters that you use to specify
whether local data caching for the specified area is to be used for
buffer lookaside on read requests. The LKASID option is valid only for
SHARELVL(2 | 3) VSO areas.
LKASID
Indicates that buffer lookaside is to be performed on read requests
for this area.
NOLKASID
Indicates that buffer lookaside is not to be performed on read
requests for this area.
| MAS | NOMAS
| Mutually exclusive optional parameters that you use to specify
| whether a shared VSO is to reside in a multi-area coupling facility
| structure.
| MAS
| Indicates that the area is to reside in a multi-area coupling facility
| structure. If MAS is specified, a second coupling facility structure
| (CFSTR2) cannot be specified.
| NOMAS
| Indicates that the coupling facility structure (or structures) should
| contain data only for this area. NOMAS is the default.
PRELOAD | NOPREL
Mutually exclusive, optional parameters that you use to specify
whether a VSO area is to be loaded the next time it is opened.
PRELOAD
Indicates that the area is to be loaded into a data space or coupling
facility structure the next time that it is opened. Selecting this
option also causes the area to be pre-opened.
NOPREL
Indicates that the area is not to be loaded into a data space or
coupling facility structure the next time that it is opened. For VSO
areas, CIs are copied into a data space when they are read for the
first time.
NOVSO
Indicates that this area is not to reside in virtual storage.
Example of Identifying the DBDS to Initiate DBRC’s Control Over

Recovery
In this example, a DBDS is registered with DBRC. The IMS DD statement is
required to allow access to the IMS DBDLIB data set to obtain the data set
identifier, data set organization, and database organization of the DBDS. The DBDS
is identified by the DBD, DDN, and DSN parameters and is accessed only by an
IMS system. Image copy data sets (of the DBDS) can be reused and DBRC
maintains a maximum number of 2 image copies. The ICJCL parameter specifies
the member of the partitioned data set of skeletal JCL that is to be used for the
generation of JCL for the Database Image Copy utility. The RECOVJCL parameter
does the same for the Database Recovery utility.

INIT.DBDS
//INITDBDS JOB
.
.
.
//SYSIN DD *
INIT.DBDS DBD(DBD002) DDN(DDN003) GENMAX(2) REUSE -
ICJCL(ICJCLX) RECOVJCL(RECOVJCX) DSN(DSN003)
/*
INIT.DBDSGRP
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 for the
/DBR command, but this usage is inefficient. Define a separate DB group for such
use.
A recovery group is used with database recoveries. It can also be used anywhere
that a DB group can be used.
INIT.DBDSGRP Syntax
,
INIT.DBDSGRP GRPNAME(name) MEMBERS( (dbname,ddname) )

,
DBGRP( dbname )
,
RECOVGRP( (dbname ) )
,areaname
Parameters for INIT.DBDSGRP

GRPNAME(name)
Required parameter you use to identify the DBDSGRP to be created. The name
can be from one to eight alphanumeric characters, and must not be the name
of an existing DBDSGRP or CAGRP record.
MEMBERS(dbname,ddname) | DBGRP(dbname) | RECOVGRP(dbname,areaname)
Mutually exclusive, required parameters that identify the members to be
included in the new group. A group can contain up to 32767 members.
MEMBERS(dbname,ddname)
Indicates that the group is a DBDS group. This parameter identifies one or
more DBDSs or DEDB areas, each by a pair of names enclosed in
parentheses, where dbname is the database name and ddname is the DD
statement 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 more
databases or area names. Any member can belong to more than one DB
group.

INIT.DBDSGRP
RECOVGRP(dbname,areaname)
| Indicates that the group is a recovery group. A recovery group is a group of
| full-function databases, HALDB databases, or DEDB areas that you
| consider to be related. HALDB partitions and Fast Path databases cannot
| belong to a recovery group. If you perform a time-stamp recovery on one
| of the members of the group, some database recovery tools require you to
| recover all members of the group to the same time. A recovery group
| otherwise can be used like a DB group.
| RECOVGRP identifies one or more DBs or DEDB areas. If a DEDB area is
| to be added to the recovery group, both dbname and areaname must be
| specified. Otherwise, areaname must not be specified. A database or area
| can belong to only one recovery group. If any of the members specified by
| RECOVGRP already belongs to another recovery group, the command
| fails.
Restrictions for HALDBs: For HALDBs, dbname specifies the name of a HALDB
partition or the HALDB master database. When specifying HALDB database
names, use the INIT.DBDSGRP command only as defined in Table 13.
Table 13. Supported dbname specifications for HALDBs on INIT.DBDSGRP command
parameters
INIT.DBDSGRP dbname = HALDB dbname = Partition
Master
MEMBERS No Yes
DBGRP Yes Yes
RECOVGRP Yes No
Example of Creating a Group of DBDSs

In this example, a group of DBDSs is defined.
//INITDBGRP JOB
.
.
.
//SYSIN DD *
INIT.DBDSGRP GRPNAME(DBDSG1) -
MEMBERS((DB1,DD1),(DB2,DD2),(DB3,DD3))
/*
INIT.GSG
Use an INIT.GSG command to define a global service group (GSG). The GSG must
be defined in every RECON which is to be used by any IMS subsystem in the
GSG.
INIT.GSG Syntax
INIT.GSG GSGNAME(gsgname)
SEQNUM(number)
Parameters for INIT.GSG

GSGNAME(gsgname)
Required parameter you use to specify the name of the GSG you want to
create.

INIT.GSG
SEQNUM(number)
Optional parameter you use to specify the initial DSN sequence number for the
GSG you want to create. If you do not specify a SEQNUM parameter, the GSG
DSN SEQ NUMBER is set to zero (0). This value is used to create unique
tracking log data set names. If you have deleted an old GSG and are now
creating a new GSG with the same name, specify a SEQNUM equal to the
value of the last DSN SEQ NUMBER of the old GSG. Otherwise, the tracker
might create logs that have data set duplicate names of previously created logs.
Example of Creating a Global Service Group

Here is an example of using the INIT.GSG command.
//INITGSG
. JOB
.
.
//SYSIN DD *
INIT.GSG GSGNAME(IMSGSG1)
/*
INIT.IC
Use 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 during
subsequent runs of the supported image copy utilities.
Each INIT.IC command creates one image copy record. You can define image copy
data sets for subsequent use only if you have specified a REUSE parameter for the
corresponding DBDS or DEDB area when it was identified in RECON with an
INIT.DBDS command. The maximum number of image copy records that are to be
used for a given DBDS or DEDB area is determined by the value of GENMAX for
the specified DBDS or DEDB area.
INIT.IC Syntax
INIT.IC DBD(name) DDN(name) ICDSN(name)
AREA(name) 1
FILESEQ( value )

1 ICDSN2(name) 3400
FILESEQ2( value ) UNIT( unittype )

3400 , ,
UNIT2( unittype )
VOLLIST( volser ) VOLLIST2( volser )
Parameters for INIT.IC

DBD(name)
Required parameter you use to identify the image copy data set being created
by the database name of its related DBDS or DEDB area.
Restriction for HALDBs: For the INIT.IC command, name specifies the name
of a HALDB partition.
Mutually exclusive, required parameters that you use to identify the image
copy data set being created; nameis the data set ddname of the related DBDS or
DEDB area.

INIT.IC
ICDSN(name)
Required parameter you use to specify the name of the image copy data set for
which the image copy record is being created. name can be up to 44 characters.
You can use the default-naming convention for image copy data sets for this
name.
FILESEQ(1 | value)
Optional parameter you use to specify the file sequence number of the image
copy data set for which the image copy record is being created. You can
specify this parameter only if you specify a VOLLIST parameter, and only if
the file sequence 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 the
duplicate 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 copy data set, if you specify a VOLLIST2 parameter, and if the
file-sequence number is not 1. The value you substitute in the variable field
must be a decimal number from 1 to 9999.
ICDSN2(name)
Optional parameter you use to specify the name of the duplicate image copy
data set for which the image copy record is being created. name can be up to
44 characters. You can use the default naming convention for duplicate image
copy data sets for this name.
Optional parameter you use to specify the unit type of the image copy data set
being defined. The unit type can be up to eight alphanumeric characters long.
If you specify the UNIT parameter, you must also specify the VOLLIST
parameter.
Optional parameter you use to specify the unit type of the duplicate image
copy data set being defined. The unit type can be up to eight alphanumeric
characters.
VOLLIST(volser)
Optional parameter you use to specify the list of volumes on which the image
copy data set resides when it is used by the supported image copy utilities.
Each volume serial number you substitute in the variable field can be up to six
alphanumeric characters. The volume serial list can contain from 1 to 255
volume serial numbers.
VOLLIST2(volser)
Optional parameter you use to specify the list of volumes on which the
duplicate image copy data set (identified with the ICDSN2 parameter) resides
when it is used by the supported image copy utilities. Each volume serial
number you substitute in the variable field can be up to six alphanumeric
characters. The volume serial list can contain from 1 to 255 volume serial
numbers.
Example of Creating a Record That Defines the ICDSN

In this example, a record is created in RECON that defines an image copy data set
that is to be used for creating an image copy of the DBDS. The name of the image
copy data set is specified in the ICDSN parameter; in this example, the default
naming convention is used to generate the fully qualified data set name. The

INIT.IC
volume on which the image copy data set is to reside is specified by the VOLLIST
parameter. 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
Use an INIT.PART command to register a HALDB Partition. The INIT.PART
command creates the RECON HALDB partition structure (a PART record, the
partition DB record and one or more DBDS records according to the DBD
specification). The INIT.PART command will fail if the HALDB is being used by
the HALDB Partition Definition utility. The IMS DBDLIB data set must be
identified in the job stream for the Recovery Control utility with a ddname of IMS.
Some parameters (identified below in the parameter description) apply to all the
partition DBDSs created as a result of this command. This differs from the HALDB
Partition Definition utility where these parameters may be specified separately for
each partition DBDS being created. These parameters can later be changed
individually with the CHANGE.DBDS command.
Related Reading: See IMS Version 9: Administration Guide: Database Manager,

SC18-7806 for information on designing databases, especially the following
chapters:
v ″Designing Databases″
v ″Naming Conventions″
| INIT.PART Syntax
| INIT.PART DBD(name) PART(name)
| KEYSTRNG string
hex_string
| DSNPREFX(string)
| RANDOMZR(name) ANCHOR(value) HIBLOCK(value)
|
| BYTES(value) 0 0
FBFF( value ) FSPF( value )
|
| , 2
GENMAX( value )
BLOCKSZE ( 4096 )
value

INIT.PART
| NOMVDBDS
|
DEFLTJCL(member) ICJCL MVDBDS
ICJCL( member )
| NOREUSE
|
OICJCL REUSE RECOVJCL
OICJCL( member ) RECOVJCL( member )
|
| 0 RECVJCL
RECOVPD( value ) RECVJCL( member )
| Parameters for INIT.PART

DBD (name)
Required parameter used to identify the HALDB for which the partition is to
be defined.
PART (name)
Required parameter used to identify a HALDB partition name. Specified as an
alphanumeric value, up to 7 characters long, with the first character being
alphabetic.
KEYSTRNG (char value or hex value)
Optional parameter you use to specify a HALDB partition high key value or a
selection string for use by a partition selection exit. Specified as a character
value up to 256 characters long or a hexadecimal value up to 512 characters
long. Character values must be alphanumeric (with no embedded blanks or
commas unless the string is enclosed by single quotes). Unless enclosed by
single quotes, the character string will be folded to uppercase. Hexadecimal
values must be enclosed by single quotes and preceded by the letter X, for
example: KEYSTRNG(X’D7C1D9E3D2C5E8’).
If no partition selection routine was specified in the HALDB master definition,
KEYSTRNG defines the Partition high key and is required. The high key length
cannot be longer than the root key length. If the high key length is less than
the defined root key length, the high key value is padded with X'FF's up to the
defined root key length. The partition high key values must be unique for each
partition within a HALDB.
If a partition selection routine was specified in the HALDB master definition,
KEYSTRNG defines a Partition Selection String which is passed to the partition
selection routine. Your installation partition selection routine may or may not
require a Partition Selection String. If required, the content of the string is
determined by your installation. It can be up to 256 bytes long and consist of
simple character information. If it contains non-printable characters, it must be
identified using hex notation. A hex character string is enclosed by single
quotation marks and prefixed with an X.
DSNPREFX (string)
Required parameter you use to specify the data set name prefix for the
partition data 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 for
HALDB PHDAM databases only. If RANDOMIZR is omitted, the name of the

INIT.PART
randomizing module is obtained from the DBD. A randomizing module

controls root 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 a
PHDAM HALDB. The value specified must be between 1 and 255. Typical
values are from 1 to 5. If ANCHOR is omitted, the value is obtained from the
DBD. This parameter is for PHDAM HALDBs only.
HIBLOCK (value)
Optional parameter used to specify the maximum relative block number value
that 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
root addressable area of an PHDAM HALDB. The value may range between 1
and 16,777,215(2**24-1). If BYTES is omitted, the value is obtained from the
DBD. This parameter is for PHDAM HALDBs only.
BYTES (value)
| Optional parameter used to specify the maximum number of bytes of a
| HALDB database record that can be stored into the root addressable area in a
| series of inserts unbroken by a call to another HALDB database record. The
| value can range between 0 and 16,777,215 (2**24-1). If BYTES is omitted, the
| value is obtained from the DBD. This parameter is for PHDAM HALDBs only.
| A value of 0 (zero) means that all bytes are addressable. Setting BYTES to 0 is
| equivalent to omitting BYTES on the DBD definition.
FBFF (0|value)
Optional parameter used to specify the free block frequency factor (fbff) which
specifies that every nth control interval or block in this data set group is left as
free space during database load or reorganization (where FBFF=n). The range
of FBFF includes all integer values from 0 to 100 except 1. The default value
for FBFF is 0.
FSPF (0|value)
Optional parameter used to specify the free space percentage factor. It specifies
the minimum percentage of each control interval or block that is to be left as
free space in this data set group. Value may be any number between 0 and 99.
The default value for FSPF is 0.
BLOCKSZE (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 used
for OSAM only. The default is 4096. You may specify up to 10 values, one for
each data set group defined in the DBD. See the SIZE keyword on the
DATASET statement in the chapter on Database Description (DBD) Generation
in the IMS Version 9: Utilities Reference: Database and Transaction Manager for
further information on specifying the block size for OSAM data sets (although
DBDGEN is not used to define HALDB partitions).
GENMAX (2|value)
Optional parameter you use to specify the maximum number of image copies
that DBRC is to maintain for the partition DBDSs. If you identify a partition
DBDS with the NOREUSE parameter, the oldest image copy beyond the
recovery period is deleted when the number of image copies exceeds the
GENMAX value. If you identify it with the REUSE parameter, the oldest image
copy beyond the recovery period is reused. Specified as a numeric value from
2 to 255. All partition DBDSs will be created with this GENMAX value. The

INIT.PART

DBDSs. The default value for GENMAX is 2.
DEFLTJCL (member)
for a HALDB Partition DBDS. The specified member is used by the
GENJCL.IC, GENJCL.OIC, and GENJCL.RECOV commands in order to resolve
keywords you have defined. All partition DBDSs will be created with this
DEFLTJCL member. The CHANGE.DBDS command can be used to change this
for individual partition DBDSs.
ICJCL (ICJCL|member)
utility (or the Database Image Copy 2 utility) for the partition DBDS specified
on the GENJCL command. All partition DBDSs will be created with this ICJCL
member. The CHANGE.DBDS command can be used to change this for
individual partition DBDSs.
NOREUSE | REUSE
supported image copy utilities are to reuse previously used image copy data
sets.
NOREUSE
REUSE allows the GENJCL.IC command or the GENJCL.OIC command to
generate a job that causes the supported image copy utilities to reuse the
oldest image copy data set (for the DBDS specified on the GENJCL
command) when the GENMAX value for it is exceeded. REUSE requires
that you create empty image copy data sets for future use by the
supported image copy utilities. In addition you must use an INIT.IC
command to record their existence in RECON.
NOREUSE
NOREUSE parameter prohibits such actions. All partition DBDSs will be
created with the parameter specified. The CHANGE.DBDS command can
be used to change this for individual partition DBDSs.
| MVDBDS | NOMVDBDS
| Optional parameters used to allow the partner DBDSs (M-V,Y) to be created in
| RECON for HALDBs capable of running HALDB Online Reorganization.
| MVSDBDS
| Optional parameter used to create the M-V, Y data sets if the HALDB is
| defined as OLRCAP. If the parameter is not included on an INIT.DBDS
| command, the M-V, Y data sets are not created until HALDB Online
| Reorganization is run the first time.
| NOMVDBDS
| Optional parameter to indicate the M-V, Y data sets are not to be created in
| RECON for HALDBs defined as OLRCAP. NOMVDBDS is the default for
| HALDBs that are OLRCAP.
OICJCL (OICJCL| member)
data set that contains skeletal JCL. When you issue a GENJCL.OIC command,
DBRC uses this member to generate the JCL to run the Online Database Image
Copy utility for the partition DBDS specified on the GENJCL command. All

INIT.PART
partition DBDSs will be created with this OICJCL member. The

DBDSs.
RECOVJCL (RECOVJCL| member)
data set that contains skeletal JCL. When you issue the GENJCL.RECOV
command, DBRC uses this member to generate the JCL to run the Database
Recovery utility for the partition DBDS specified on the GENJCL command. All
partition DBDSs will be created with this RECOVJCL member. The
DBDSs.
RECOVPD (0| value)
| Optional parameter you use to specify the recovery period for a specified
| partition DBDS. Specify a numeric value from 0 to 999 that represents the
| number of days you want DBRC to maintain sufficient recovery-generation
| information in the RECON data set. The default is 0 which means there is no
| recovery period. All partition DBDSs will be created with this RECOVPD
| value. The CHANGE.DBDS command can be used to change this for
| individual partition DBDSs.
RECVJCL(RECVJCL| member)
be used by the GENJCL.RECEIVE command. RECVJCL can be specified for
both RSR-covered and non-covered HALDB DBDSs. All partition DBDSs will
be created with this RECVJCL member. The CHANGE.DBDS command can be
used to change this for individual partition DBDSs.
Example of Creating a Partition

This example creates a partition for the HALDB identified by the DBD parameter.
The partition name is identified by the PART parameter. The HALDB uses a
partition selection exit. The KEYSTRNG parameter defines the selection string used
by the Partition Selection exit. The string is 149 characters long. The character
string must be enclosed in quotes because it contains blanks. The ending minus
sign (“-”) indicates the line is continued. Note that the selection string also contains
minus signs, so the first line of the string ends with two minus signs (the first,
being part of the selection string, and the second, being the continuation character).
The first DSGROUP (DBDS) is assigned a block size of 32000, the second is
defaulted to 4096, the third is 4000, and the remaining DSGROUPs will all have the
default of 4096. The partition is marked as needing partition initialization when it
is created.
//INITPART JOB
.
.
.
//SYSIN DD *
INIT.PART DBD(DBHDOK01) PART(PDHDOKE) KEYSTRNG('ABCDEFGHIJKL--
MNOPQRSTUVWXYZ0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJ-
KLMNOPQRSTUVWXYZ0123456789-
EFGHIJKLMNOPQRSTUVWXYZ0123456789') -
DSNPREFX(TESTSYS1.PROJECT) -
BLOCKSZE(32000,,4000)
/*
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7..
INIT.RECON
Use the INIT.RECON command to initialize the RECON for use by DBRC.

INIT.RECON
The RECON data sets must first be created using the AMS DEFINE CLUSTER
command, and must be empty.
INIT.RECON Syntax
| NOCATDS CMDAUTH(NONE)
| INIT.RECON
CATDS CMDAUTH( SAF ,safhlq)
EXIT
BOTH
| DASDUNIT(3400) NOFORCER CHECK17 NOLISTDL

|
DASDUNIT(unittype) FORCER CHECK44 LISTDL
NOCHECK
| LOGRET(001) MINVERS('7.1')
|
LOGRET('time_interval') MINVERS( '8.1' ) REORGV
'9.1' NOREORGV
| NONEW TAPEUNIT(3400)
|
SSID(name) STARTNEW TAPEUNIT(unittype)
|
Parameters for INIT.RECON

CATDS | NOCATDS
Mutually exclusive, optional parameters that you use to indicate whether
image copy, change accumulation, and log data sets are cataloged.
CATDS
| Specifies that these data sets are cataloged or SMS-managed. If the data set
| is allocated by the catalog and the CATDS option is used, DBRC bypasses
| volume serial and file sequence verification for the data set.
| In order for the CATDS option to be effective, the data set must be
| cataloged, and volume serial information for the data set must be omitted
| from the JCL. If the data set is cataloged, CATDS is specified, and volume
| serial information is included in the JCL, DBRC ignores CATDS and
| allocates the data set by the JCL. Normal volume serial and file sequence
| checking occurs.
| If the data set is not cataloged, CATDS is not effective, and DBRC allocates
| the data set by the JCL, with volume serial and file sequence checking.
| If log data sets are SMS-managed, select the CATDS option and remove the
| %LOGVOLS keyword from skeletal JCL member CAJCL.
| Attention: The CATDS option affects restart of IMS from SLDS data sets.
| Because the CATDS option indicates the SLDSs are under the control of a
| catalog management system, the VOLSER is not passed back to IMS for
| data set allocation. If the SLDS data sets are not cataloged, IMS restart fails.
NOCATDS
Specifies that these data sets, regardless if they are cataloged, are not to be
treated as cataloged. DBRC verifies that the volume serial and file
sequence numbers appearing in the job file control block are the same as
the information recorded in the RECON.

INIT.RECON
CMDAUTH(SAF | EXIT | BOTH | NONE,safhlq)

Optional parameter you use to specify whether DBRC batch command
authorization is to be performed.
Specification of this parameter will result in command authorization being
performed using the specified setting.
SAF | EXIT | BOTH | NONE
Mutually exclusive subparameters that you use to specify your DBRC
batch command security option.
SAF
Specifies that a security product is to be called for command
authorization.
EXIT
Specifies that the DBRC Command Authorization Exit (DSPDCAX0) is
to be called for command authorization.
BOTH
Specifies that a security product and the DBRC Command
Authorization Exit (DSPDCAX0) are to be called for command
authorization. The security product is called first, then DSPDCAX0.
NONE
Specifies that command authorization is to be skipped. This is the
default.
safhlq
High level qualifier of the resource name used to determine command
authorization. safhlq must be specified with SAF, EXIT, or BOTH. safhlq is
a name up to eight alphanumeric characters in length.
DASDUNIT(unittype)
Optional parameter you use to specify the unit type of the DASD device
holding the records for log data sets. The unit type can be up to eight
If you do not use this parameter to specify a DASD device, then the
INIT.RECON command defaults to DASD unit type 3400.
FORCER | NOFORCER
Mutually exclusive, optional parameters that you use to specify whether all
IMS databases must be registered in RECON.
FORCER
Specifies that all databases must be registered. If you specify FORCER and
a job attempts to access an unregistered database, the database
authorization call from IMS to DBRC fails.
NOFORCER
Specifies that databases do not have to be registered.
CHECK17 | CHECK44 | NOCHECK
Mutually exclusive, optional parameters that you use to change the type of log
data set name comparison that DBRC does.
CHECK17
Verifies that the last 17 characters of a log data set name are consistent
with RECON. If the name in RECON does not match the names on the
appropriate ddname, the utility stops.

INIT.RECON
CHECK44
Verifies 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 log
ddname, the utility stops.
NOCHECK
Used if the data set name specified as input to the Database Recovery
utility is longer than 17 characters and has a new high-level qualifier.
DBRC does not compare the log data set name recorded in RECON with
the name 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
becomes inactive after it is opened. (It is then eligible to be deleted.)
v The time_interval is a partial, punctuated time stamp representing a time
interval (days, hours, minutes, and seconds) rather than a date and time.
The time 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 (,).
The time stamp must be enclosed in single quotes (’) if it contains any blanks
or special characters. The number of days must include any leading zeros, but
you can omit trailing zeros. Valid intervals range from a tenth of a second to
365 days. The default value, 001, is 24 hours.
Because the time interval is treated as a time stamp, message DSP0106I can be
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 days
LOGRET('010 12,30') LOGRET('10 12:30') = 10 days, 12 hours, 30 minutes
If you do not use this parameter to specify a retention period, then the
INIT.RECON command defaults to a period of 001 (24 hours).
Related Reading:
v See “DELETE.LOG (for RLDS and SLDS)” on page 212 for more information
on deleting inactive logs.
v See “Standard Time Stamp Format” on page 126 for more information on
time stamps.
LISTDL | NOLISTDL
Mutually exclusive, optional parameters that you use to specify whether data
set names deleted from the RECON (by the DELETE.LOG command or by an

INIT.RECON
archive job log compression) are listed in the job output. The setting specified
on this command can be overridden by the DELETE.LOG command. There is no
way to override the setting for log compression during an archive job.
LISTDL
Specifies that names of deleted data sets are to be listed in the job output.
NOLISTDL
Specifies that names of deleted data sets are not to be listed in the job
output.
| MINVERS('7.1' | '8.1' | '9.1')
| Optional parameter used to specify the lowest version of IMS allowed to sign
| on. This keyword cannot be set to a higher IMS release if any subsystems with
| a lower version of IMS are currently signed on to DBRC. The default is IMS
| '7.1'.
| Note: The IMS Version 9 format for the MINVERS keyword includes a period.
| DBRC considers this a special character and requires it to be enclosed in
| single quotes. The format from earlier versions (71 | 81 | 91) is also
| accepted for compatibility.
| REORGV | NOREORGV
| Mutually exclusive, optional parameters you use to modify the HALDB
| partition reorganization number verification. A CHANGE command with these
| parameters is allowed while databases are currently authorized to other
| subsystems.
| REORGV
| enabled. The RECON will store the reorganization number for each
| partition to prevent the reorganization number from being regressed, or
| incremented by more than one. After a CHANGE.RECON REORGV
| command is issued, the partition reorganization number in each partition
| record is set to zeros.
| Note: The MINVERS value must be a minimum of 8.1 in order to set

| REORGV.
| NOREORGV
| disabled. Any requests to store, update or verify the reorganization number
| will be ignored.
SSID(name)
Optional parameter you use to specify the name of the IMS subsystem that is
to be 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 IMS
subsystem ID.

INIT.RECON
STARTNEW | NONEW
Mutually exclusive, optional parameters that you use to specify whether new
jobs are to be started when only one RECON is available.
STARTNEW
Specifies that new jobs are to be started.
NONEW
Specifies that new jobs are not to be started.
TAPEUNIT(unittype)
Optional parameter you use to specify the unit type of the tape device that is
holding the records for log data sets. The unit type can be up to eight
If you do not use this parameter to specify a tape device, then the INIT.RECON
command defaults to unit type 3400.
Example of Initializing the RECON

In this example, the RECON data sets are identified by the RECON1 and RECON2
DD 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
Use an INIT.SG command to define a service group as a member of a GSG. Every
service group in the GSG must be defined in every RECON that is to be used by
any IMS subsystem in the GSG. This command also specifies the initial role of the
service group.
INIT.SG Syntax
NONLOCAL
INIT.SG GSGNAME(gsgname) SGNAME(sgname) ACTIVE
TRACKING LOCAL
Parameters for INIT.SG

ACTIVE | TRACKING
Mutually exclusive, required parameters that you use to specify the initial role
of the service group.
ACTIVE
Indicates that the service group is an active subsystem. ACTIVE can only
be specified for one service group of a GSG.
TRACKING
Indicates that the service group is a tracking subsystem. TRACKING can
only be specified for one service group of a GSG.

INIT.SG
GSGNAME(gsgname)
Required parameter you use to specify the name of the GSG to which the
service group belongs.
SGNAME(sgname)
Required parameter you use to specify the name of the service group you want
to create.
LOCAL | NONLOCAL
service group is local or nonlocal.
LOCAL
Indicates that this is the local service group for this set of RECONs.
NONLOCAL
Indicates that this is the nonlocal service group for this set of RECONs.
Examples of Creating Service Groups

In this example, the ACTIVE Service Group named STLSITE1 is added to the GSG
IMSGSG1, and a LOCAL TRACKING SG named STLSITE2 is added to the same
GSG.
//INITSG
. JOB
.
.
//SYSIN DD *
INIT.SG GSGNAME(IMSGSG1) SGNAME(STLSITE1) ACTIVE
INIT.SG GSGNAME(IMSGSG1) SGNAME(STLSITE2) TRACKING LOCAL
/*

Chapter 13. LIST Commands
Use the LIST commands to produce a formatted printout of all or selected
information contained in a RECON.
LIST Commands In This Chapter

The following is a list of all the LIST commands:
v “LIST.BKOUT”
v “LIST.CAGRP” on page 292
v “LIST.DB” on page 293
v “LIST.DBDS” on page 294
v “LIST.DBDSGRP” on page 296
v “LIST.GSG” on page 297
v “LIST.HISTORY” on page 298
v “LIST.LOG (for a PRILOG Family)” on page 300
v “LIST.LOG (for a Category of Records)” on page 301
v “LIST.RECON” on page 304
v “LIST.SUBSYS” on page 306
LIST.BKOUT
Use a LIST.BKOUT command to list information about the backout record for the
selected subsystem or to list all backout records in RECON. For the format of the
records listed by this command, see the Appendix B, “Sample Listings from the
RECON Data Set,” on page 473.
LIST.BKOUT Syntax
ALL
LIST.BKOUT
SSID(name) TIMEFMT(sublist)
Parameters for LIST.BKOUT

ALL | SSID(name)
Mutually exclusive, optional parameters that identify the backout records that
are to be displayed.
ALL
Specifies 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 an
eight-character alphanumeric string that identifies a valid subsystem ID.
TIMEFMT(sublist)
messages, displays, and listings from DBRC.
Related Reading:
v See “TIMEFMT Parameter” on page 127 for a description of the TIMEFMT
parameter sublist format.
LIST.BKOUT
The LIST commands get the TIMEFMT default from what is specified in the
RECON header record.
Example of Running LIST.BKOUT

Here is an example of running the LIST.BKOUT command.
//LISTBKOUT JOB
.
.
.
//SYSIN DD *
LIST.BKOUT SSID(IMS1)
/*
LIST.CAGRP
Use a LIST.CAGRP command to list information in the Copy1 RECON about either a
specified CA group or all CA groups. For the format of the records listed by this
command, see the Appendix B, “Sample Listings from the RECON Data Set,” on
page 473.
LIST.CAGRP Syntax
ALL
LIST.CAGRP
GRPNAME(name) TIMEFMT(sublist) MEMBERS
Parameters for LIST.CAGRP

ALL | GRPNAME(name)
Mutually exclusive, optional parameters you use to specify the name of the CA
group for which information is to be displayed.
ALL
Produces a list of the CA group record and corresponding change
accumulation run records for each CA group in RECON.
GRPNAME(name)
Produces a list of the CA group record and the change accumulation run
records for the group that you request in name.
MEMBERS
Optional parameter you use to only list information about the CA group
definition. CA execution information is not listed.
TIMEFMT(sublist)
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:
The TIMEFMT default for LIST commands is obtained from what is specified
in the RECON header record.

LIST.CAGRP
Example of Specifying the CA Group and CA Records via

GRPNAME
In this example, the CA group record and the associated CA records are specified
by the GRPNAME parameter.
//LISTCAGP JOB
.
.
.
//SYSIN DD *
LIST.CAGRP GRPNAME (MYGROUP)
/*
LIST.DB
Use a LIST.DB command to receive a list of databases registered in RECON. You
can 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 B, “Sample
Listings from the RECON Data Set,” on page 473.
The LIST.DB command displays the recoverable or nonrecoverable status of the

database.
Related Reading:
v See “HALDB Records” on page 68 for detailed information about how HALDBs
are represented in the RECON data set.
v See IMS Version 9: Administration Guide: Database Manager for an overview of
HALDBs and information about how to create them.
LIST.DB Syntax
ALL
LIST.DB
TYPEIMS COVERED DBDS TIMEFMT(sublist)
TYPEFP GSG(gsgname)
TYPHALDB
DBD(dbname)
Parameters for LIST.DB

ALL | TYPEIMS | TYPEFP | TYPHALDB | DBD(dbname)
Mutually exclusive, optional parameters you use to specify which databases in
RECON are to be displayed.
ALL
Specifies that all database records in RECON are to be displayed. For
HALDBs, the partition database records are listed under the master record.
TYPEIMS
Specifies that all database records in RECON that describe a DL/I database
TYPEFP
Specifies that all database records in RECON that describe a Fast Path
DEDB are to be displayed.
TYPHALDB
Specifies that all database records that represent HALDBs are to be
Chapter 13. LIST Commands 293

LIST.DB
displayed, 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.
Restriction for HALDBs: For HALDBs, specifying the HALDB master
name lists the HALDB master record and all of its partition database
records. Specifying the partition database name lists only the partition
database record.
COVERED | GSG(gsgname)
Mutually exclusive, optional parameters you use to qualify the database
records in RECON that are to be displayed. Neither COVERED nor
GSG(gsgname) can be specified if DBD is specified.
COVERED
Specifies that all RSR-covered databases are to be displayed.
GSG(gsgname)
Specifies that only databases covered by the specified global service group
DBDS
Optional parameter you use to display those DBDSs or areas in RECON that
are associated with the specified database. DBDS information includes
recovery-related records (ALLOC, IC, RECOV, REORG). If you do not specify
this parameter, no DBDS records or area records are displayed.
TIMEFMT(sublist)
Related Reading:
Example of Displaying a Database and Its DBDS Records

In this example, database HDAMVSAM and its associated DBDS records are
displayed.
//LISTDB
.
.
.
//SYSIN DD *
LIST.DB DBD(HDAMVSAM) DBDS
/*
LIST.DBDS
Use a LIST.DBDS command to display a list of all records in RECON that contain
information about a specific DBDS or DEDB area. For the format of the records
listed by this command, see the Appendix B, “Sample Listings from the RECON
Data Set,” on page 473.

LIST.DBDS
LIST.DBDS Syntax
LIST.DBDS DBD(name)
GROUP(name) DDN(name) TIMEFMT(sublist)
AREA(name)
Parameters for LIST.DBDS

DEDB area being listed.
DBD
Specifies the database name of the DBDS or DEDB area being displayed.
Restrictions for HALDBs: For HALDBs, you can specify either a HALDB
master database name or a HALDB partition name when you do not
specify the DDN parameter. When you specify the DDN parameter, you
can only specify a HALDB partition name.
GROUP
Specifies that all DBDSs or DEDB areas of the named DBDS group are to
be displayed. If GROUP is specified, the LIST.DBDS command is executed
for each member of the identified group.
Mutually exclusive, optional parameters you use to identify the DBDS or
DEDB area to be displayed. You specify one of these parameters only when
you specify the DBD parameter.
DDN(name)
Specifies the name of the DBDS to display.
Restrictions for HALDBs: For HALDBs, you must specify a HALDB
partition name (not a HALDB master name) with the DBD parameter in
order to use the DDN parameter. The DDN parameter value is the HALDB
partition DDN. The LIST.DBDS command is performed for the identified
DBDS of the partition. The LIST.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 for
each DBDS or DEDB area of the specified database.
Restrictions for HALDBs: If you specify a HALDB master name, the
LIST.DBDS command is performed for each DBDS for each HALDB 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.
TIMEFMT(sublist)
Related Reading:
LIST.DBDS
Example of Displaying AREA Parameters

In this example, information about the DEDB area specified in the DBD and AREA
parameters is displayed.
//LISTDBDS JOB
.
.
.
//SYSIN DD *
LIST.DBDS DBD(FPEDBD02) AREA(AREA01)
/*
LIST.DBDSGRP
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 recovery
groups) 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 276
v “CHANGE.DBDSGRP” on page 159
LIST.DBDSGRP Syntax
ALL
LIST.DBDSGRP GRPNAME(name)
, TIMEFMT(sublist)
ALL( (dbname ) )
,areaname
,ddname
Parameters for LIST.DBDSGRP

GRPNAME(name) | ALL
Mutually exclusive, optional parameters you use to specify the groups to be
listed.
ALL
Produces a list of all the DBDS, DB, and recovery groups identified in
RECON. All is the default.
GRPNAME
Produces a list of the members of the specified group. The named group
must exist in RECON.
ALL(dbname,areaname,ddname)
Produces a limited list of the DBDS, DB, and recovery groups identified in
the RECON. Use the parameters (dbname,areaname,ddname) to limit the
number of records listed. A group is listed only if it contains one or more
of the databases, DBDSs, or areas specified.
Restriction for HALDBs: For the LIST.DBDSGRP command, dbname can
specify either the name of a HALDB partition or a HALDB master
database.

LIST.DBDSGRP
TIMEFMT(sublist)
Related Reading:
Example of Displaying the Members of a DBDS Group

In this example, the members of a specified DBDS group are displayed.
//LISTDBGP JOB
.
.
.
//SYSIN DD *
LIST.DBDSGRP GRPNAME(DBDSG1)
/*
LIST.GSG
Use a LIST.GSG command to receive a list of the global service group records in
RECON. 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 B, “Sample
Listings from the RECON Data Set,” on page 473.
LIST.GSG Syntax
ALL
LIST.GSG
GSGNAME(gsgname) TIMEFMT(sublist)
Parameters for LIST.GSG

ALL | GSGNAME(name)
Mutually exclusive, optional parameters you use to specify which GSG records
in RECON are to be displayed.
ALL
Specifies that all GSG records in RECON are to be displayed.
GSGNAME(name)
Displays a specific GSG record.
TIMEFMT(sublist)
Related Reading:

LIST.GSG
Example of Listing a Global Service Group

In this example a single GSG record is displayed.
//LISTGSG
. JOB
.
.
//SYSIN DD *
LIST.GSG GSGNAME(GSG1)
/*
LIST.HISTORY
Use the LIST.HISTORY command to produce a history-of-activity listing for DBDSs
or DEDB 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 area
recovery records are combined to form a DBDS record listing.)
v The following records (if present), listed in time sequence order under each
DBDS or area:
– ALLOC records.
– IMAGE records.
– CA execution records, showing the purge time only for the current DBDS or
area.
– 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 records
listed above.
You can use the FROMTIME and/or TOTIME parameters to define a time range
that excludes these records:
v ALLOC records for USIDs that are not active within the range. If any ALLOC
record 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
the range.
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 474 for an illustration of

sample output produced by the LIST.HISTORY command.
LIST.HISTORY Syntax
LIST.HISTORY DBD(name)
GROUP(name) DDN(name) FROMTIME(time_stamp)
AREA(name)

TOTIME(time_stamp) TIMEFMT(sublist) TIMELINE

LIST.HISTORY
Parameters for LIST.HISTORY

DEDB area to list.
DBD
Specifies the database name of the DBDS or DEDB area to be listed.
Restrictions for HALDBs: For HALDBs, you can specify either a HALDB
master database name or a HALDB partition name when you do not
specify the DDN parameter. When you specify the DDN parameter, you
can only specify a HALDB partition name.
GROUP
Specifies that all the DBDSs or DEDB areas of a DBDS group or CA group
are to be listed. If GROUP is specified, the LIST.HISTORY command is
executed for each member of the identified group.
Mutually exclusive, optional parameters you use to identify the DBDS or
DEDB area to be listed. You specify one of these parameters only when you
specify the DBD parameter.
DDN
Specifies the name of the DBDS to list.
Restrictions for HALDBs: For HALDBs, you must specify a partition
database name with the DBD parameter in order to use the DDN
parameter. The DDN parameter value is the partition DDN. The
LIST.HISTORY command is performed for the identified DBDS of the
partition. The LIST.HISTORY command fails if DDN does not identify a
DBDS in the partition.
AREA
Specifies the name of the DEDB area to list.
If neither DDN nor AREA is specified, the LIST.HISTORY command is executed

for each DBDS or DEDB area of the specified database.
Restrictions for HALDBs: If you specify a HALDB master name, the
LIST.HISTORY command is performed for each DBDS for each partition in the
HALDB master. If you specify a HALDB partition name, the LIST.HISTORY
command is performed for each DBDS of the identified partition.
FROMTIME(time_stamp)
Optional parameter you use to specify the time stamps of the DBDS or DEDB
area records that are to be listed in time sequence order. The time stamp must
be in standard form (see “Standard Time Stamp Format” on page 126). Those
records that are not listed in time-sequence order are listed regardless of
whether FROMTIME or TOTIME are specified. FROMTIME specifies the time
stamp of the oldest record to be listed. If you specify only FROMTIME, all
subsequent, pertinent records in RECON are listed.
You can combine the FROMTIME and TOTIME parameters in order to specify
a range of records to display.
If you specify neither FROMTIME nor TOTIME, all the records that exist in
RECON for the specified DBDSs or DEDB areas are listed.
TOTIME(time_stamp)
Optional parameter you use to specify the time stamps of the DBDS or DEDB

LIST.HISTORY
area records to be listed in time-sequence order. The time stamp must be in

standard form (see “Standard Time Stamp Format” on page 126). Those records
not listed in time-sequence order are listed regardless of whether FROMTIME
or TOTIME are specified. TOTIME specifies the time stamp of the last 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
a range of records to display.
If you specify neither FROMTIME nor TOTIME, all the records that exist in
RECON for the specified DBDSs or DEDB areas are listed.
TIMEFMT(sublist)
Related Reading:
Timeline
Optional parameter you use to specify that only the time line summary should
be listed in the output.
Example of Displaying a DBDSs Activity History

In 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)

Use this command to display the PRILOG record and any of the following records
having the specified start time.
v LOGALL
v SECLOG
v PRISLD
v SECSLD
LIST.LOG (for a PRILOG Family) Syntax

| LIST.LOG
| STARTIME(time_stamp) SSID(name) GSG(gsgname)
TRACKING
|
| TIMEFMT(sublist)
|

LIST.LOG (for a PRILOG family)
Parameters for LIST.LOG (for a PRILOG Family)

Required parameter you use to specify the start time of the records that you
want displayed.
SSID(name)
Optional parameter that limits the display of log records or OLDS entries to
those associated with the specified subsystem.
| GSG(gsgname) | TRACKING
| Mutually exclusive, optional parameters that you use to specify that log data
| sets for an RSR tracking subsystem are to be displayed. LIST.LOG ALL does
| not show RSR tracking subsystem information.
| GSG(gsgname)
| Optional parameter that limits the display of log records to those
| associated with 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.
| TRACKING
| Indicates that only records of log data sets created by tracking
| subsystems in the global service group are to be displayed.
TIMEFMT(sublist)
Related Reading:
Attention: If the ERROR, OPEN, or UNARCH parameters are coded, message

DSP0141I 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 described
under the next section.
Example of Listing a PRILOG Family of Records

In the example, all PRILOG, SECLOG, PRISLD, SECSLD, and LOGALL records
that 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.

LIST.LOG (for a category of records)
LIST.LOG (for a Category of Records) Syntax

ALL
LIST.LOG
See “Optional Filters”
v PRILOG
v LOGALL
v SECLOG
v PRISLD
v SECSLD
v PRIOLD
v SECOLD
ALL
LIST.LOG INTERIM
v IPRI
v ISEC
v IPRISL
v ISECSL
v IPRIOL
v ISECOL
ALL
LIST.LOG TRACKING
v PRITSLDS
v SECTSLDS
ALL
LIST.LOG TRACKING INTERIM
See “Optional Filter”
v IPRITSLD
v ISECTSLD
LIST.LOG ALLOLDS
v PRIOLD
v SECOLD
LIST.LOG ALLOLDS INTERIM

v IPRIOL
v ISECOL

LIST.LOG OLDS(ddname)
SSID(name) See “Optional Filters”
v PRIOLD
v SECOLD
LIST.LOG OLDS displays only the data set entries with matching DD names and
| subsystem names. If SSID is omitted, processing is the same as for ALLOLDS.
| Optional Filters: The LIST.LOG command can be further qualified with one or
more of the following optional parameters. For example, combining SSID and
OPEN limits the display to logs and OLDS entries that belong to a specified
subsystem and to those that are not closed.
| The optional parameters for LIST.LOG ALL, ALLOLDS, and OLDS are:
|
| FROMTIME(time_stamp) TOTIME(time_stamp) SSID(name) GSG(gsgname)
|
| OPEN ERROR UNARCH
|
Parameters for LIST.LOG (for a Category of Records)

FROMTIME(time_stamp)
| Optional parameter that limits the display to log records or OLDS entries
| starting at, or after, this time. The time stamp must be in standard form (see
| “Standard Time Stamp Format” on page 126).
TOTIME(time_stamp)
Optional parameter that limits the display to log records or OLDS entries
starting at, or before, this time. The time stamp must be in standard form (see
SSID(name)
Optional parameter that limits the display to log records or OLDS entries
associated with the specified subsystem.
GSG(gsgname)
Optional parameter that limits the display of log records to those associated
with the specified GSG.
OPEN
Optional parameter that limits the display to log records or OLDS entries that
are not closed.
ERROR
Optional parameter that limits the display to log records having one or more
data set entries marked in error, and to OLDS entries marked in error.
UNARCH
Optional parameter that limits the display of OLDS entries to those that are
not archived.
Attention: Specifying UNARCH without the ERROR or OPEN parameters
causes 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.


TIMEFMT(sublist)
TIMEFMT(sublist)
Related Reading:
Attention: If the ERROR, OPEN, or UNARCH parameters are coded, message

DSP0141I 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 described
under the next section.
Example of Displaying RECON Records Specified by STARTIME

In this example, the RLDSs, SLDS, and corresponding LOGALL record with the
time 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 Records

In this example, the OLDS records from subsystem IMSA are to be displayed.
//LISTRCON JOB
.
.
.
//SYSIN DD *
LIST.LOG ALLOLDS SSID(IMSA)
/*
LIST.RECON
Use the LIST.RECON command to obtain a display of the RECON’s current status
and 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 The minimum IMS release level to coexist with this RECON
v The status of each of the three RECONs as follows:
RECON status Meaning

LIST.RECON
COPY1 PRIMARY ACTIVE RECON

COPY2 SECONDARY ACTIVE RECON
SPARE AVAILABLE RECON
UNAVAILABLE UNAVAILABLE RECON
DISCARDED UNUSABLE RECON
The RECON is unavailable when the resource is allocated in another system.
LIST.RECON Syntax
LIST.RECON
STATUS TIMEFMT(sublist)
Parameters for LIST.RECON

STATUS
Optional parameter you use to request the RECON header record information
and the status of all RECONs. If you specify this parameter the listing of the
remainder of the records is suppressed.
TIMEFMT(sublist)
Related Reading:
Examples of Displaying the RECONs

Here are some examples of using the LIST.RECON command.
Example of Displaying the RECONs: In this example, the status and contents of
RECON are displayed.
//LISTRCON JOB
.
.
.
//SYSIN DD *
LIST.RECON
/*
For a sample of RECON, see the Appendix B, “Sample Listings from the RECON
Data Set,” on page 473.
Example of Displaying RECON Header and Status Information: In 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 B, “Sample Listings from
the RECON Data Set,” on page 473 is produced in this case.
Related Reading: See Chapter 4, “Initializing and Maintaining the RECON Data
Set,” on page 55 for an explanation of the possible RECON states.
LIST.SUBSYS
Use a LIST.SUBSYS command to receive a formatted list of the subsystems
registered in RECON. For the format of the records listed by this command, see the
Appendix B, “Sample Listings from the RECON Data Set,” on page 473.
LIST.SUBSYS Syntax
ONLINE
LIST.SUBSYS
SSID(name) TIMEFMT(sublist) TRACKING
ALL
BATCH
Parameters for LIST.SUBSYS

SSID(name) | ALL | ONLINE| BATCH
Mutually exclusive, optional parameters you use to specify which subsystem
information is to be displayed.
SSID(name)
Specifies the name of the subsystem for which information is to be
displayed.
ALL
Specifies that all subsystem information, both batch and online, is to be
displayed.
ONLINE
Specifies that all online subsystem information is to be displayed.
BATCH
Specifies that all batch subsystem information is to be displayed.
TIMEFMT(sublist)
Related Reading:

LIST.SUBSYS
TRACKING
Specifies that all RSR tracking subsystem information is to be displayed.
Example of Displaying All Online Subsystem Records

In this example, all online subsystem records are displayed.
//LISTSS JOB
.
.
.
//SYSIN DD *
LIST.SUBSYS
/*

LIST.SUBSYS

Chapter 14. NOTIFY Commands
Use the NOTIFY commands to add information to a RECON that is normally
written there automatically.
NOTIFY Commands In This Chapter

The following is a list of all the NOTIFY commands:
v “NOTIFY.ALLOC”
v “NOTIFY.BKOUT” on page 311
v “NOTIFY.CA” on page 312
v “NOTIFY.IC” on page 314
v “NOTIFY.PRILOG (for OLDS)” on page 317
v “NOTIFY.PRILOG (for RLDS)” on page 321
v “NOTIFY.PRILOG (for SLDS and TSLDS)” on page 326
v “NOTIFY.RECOV” on page 329
v “NOTIFY.REORG” on page 332
v “NOTIFY.SECLOG (for OLDS)” on page 335
v “NOTIFY.SECLOG (for RLDS)” on page 338
v “NOTIFY.SECLOG (for SLDS and TSLDS)” on page 342
v “NOTIFY.SUBSYS” on page 345
v “NOTIFY.UIC” on page 346
NOTIFY.ALLOC
Use a NOTIFY.ALLOC command to add information to RECON about either a
specific database allocation or a specific database deallocation of a DBDS or DEDB
area. This addition of information is required only when RECON was not updated
during a 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,

user-recoverable, or in use.
HALDB Restriction: This command is not allowed for ILDS or Index DBDSs of
HALDB partitions.
NOTIFY.ALLOC Syntax
NOTIFY.ALLOC ALLTIME(time_stamp) DBD(name) DDN(name)
AREA(name)
DEALTIME(time_stamp)
STARTIME(time_stamp) DSSN(value) USID(value)
Parameters for NOTIFY.ALLOC

ALLTIME(time_stamp)
Required parameter you use to specify the time stamp of the allocation of the

NOTIFY.ALLOC
database that contains the DBDS or DEDB area that is specified in this
command. The time stamp must be in standard form (see “Standard Time
When used with the STARTIME parameter, ALLTIME causes a new allocation
record to be written in RECON. When used with a DEALTIME parameter, it
identifies the allocation record in RECON for which a deallocation time is
being added.
DBD(name)
DEDB area for which you are adding allocation information to RECON.
Restriction for HALDBs: When using the NOTIFY.ALLOC command for
HALDBs, name must specify the name of a HALDB partition.
Required parameter you use to specify the data set ddname of the DBDS or
DEDB area for which you are adding allocation information to RECON.
DEALTIME(time_stamp) | STARTIME(time_stamp)
Mutually exclusive, required parameters. The time stamp must be in standard
DEALTIME
Specifies the time stamp of the deallocation of the database for the
specified DBDS or DEDB area. This addition to RECON is required only if
the database is allocated for updates and explicitly deallocated before the
end of an IMS run.
STARTIME
Specifies the starting time stamp of the log data set that was active at the
time of the allocation specified in the ALLTIME parameter.
DSSN(value)
Optional parameter you use to specify which data set sequence number is
placed in the allocation record to be created. If you do not specify the DSSN
parameter, 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 the
appropriate DSSN. You use this parameter for log-merge processing.
USID(value)
Optional parameter you use to specify the update set identifier of the database
or area when the update occurred.
USID is required if the database or area is assigned to a GSG. If the database
or area is not assigned to a GSG, USID cannot be specified.
Example of Adding Allocation Information to RECON

In this example, information about an allocation of a specified DBDS is to be
added to RECON. The ALLTIME parameter specifies the time stamp of the
allocation of the DBDS or DEDB area; the STARTIME parameter specifies the time
stamp of the start 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
NOTIFY.BKOUT
Use the NOTIFY.BKOUT command to create a backout record for a specified
subsystem and to add a single unit of recovery (UOR) entry to the record that is
created. Additional UOR entries can be added to the backout record by using the
CHANGE.BKOUT command.
NOTIFY.BKOUT Syntax
NOTIFY.BKOUT SSID(name) UOR(uor) UORTIME(time_stamp) PSB(name)

, ,
DBD( name ) BKO( name )
Parameters for NOTIFY.BKOUT

SSID(name)
Required parameter you use to specify the subsystem for which the backout
record is to be created. The name is an eight-character, alphanumeric string
that represents any valid subsystem name.
UOR(uor)
Required parameter you use in conjunction with the UORTIME parameter to
identify a unit of recovery in the backout record. The recovery token (uor) is a
16-byte field that describes a specific UOR that is to be included with the
backout record. uor must be 32 hexadecimal digits expressed as a character
string; for example, UOR(E2E8E2F3404040400000000600000003).
The recovery token is intended to be a unique identifier, but it can be
duplicated across restarts. When you include UORTIME, you eliminate the
problem of possible duplication.
UORTIME(time_stamp)
Required parameter you use to specify the time of the UOR to be added to the
backout record. The value is the time stamp of the beginning of the UOR
(found in the X'5607' log record). The time stamp must be in standard form
(see “Standard Time Stamp Format” on page 126).
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 changes
associated with the unit of recovery that require backout.
Restriction for HALDBs: When using the NOTIFY.BKOUT command for
BKO(name)
Optional parameter you use to identify up to eight databases having changes
associated with the unit of recovery that have already been backed out.
Use BKO to identify databases that have already been backed out from this
UOR-UORTIME combination. You can specify either the BKO parameter, the
DBD 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 at
the same time.)
Chapter 14. NOTIFY Commands 311

NOTIFY.BKOUT
Example of Adding a Backout Record to RECON

In 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
Use a NOTIFY.CA command to add information about a run of the Database Change
Accumulation utility for a specified CA group.
NOTIFY.CA Syntax
NOTIFY.CA CADSN(name) GRPNAME(name) RUNTIME(time_stamp) STOPTIME(time_stamp)
VOLLIST( volser )
1
FILESEQ( value )

, 3400
NO COMPLETE UNIT( unittype )
PURGLIST( ( time_stamp, YES , INCOMPLETE ) )
COMP

SUBSET
Parameters for NOTIFY.CA

CADSN(name)
Required parameter you use to specify the data set name of the change
accumulation data set in the identified record. If the CA group is defined as
reusable, the data set name must be unique. DBRC does not check for
duplicate data set names.
GRPNAME(name)
information is to be added.
RUNTIME(time_stamp)
Required parameter you use to identify the specific change accumulation run
record to be added. The time stamp represents the time at which the Database
Change Accumulation utility was run, and it must be in standard form (see
Required parameter you use to specify the time stamp of the change

NOTIFY.CA
accumulation run record for which information is to be added. The time stamp
is the stop time of the last log volume that was processed by the specified run
of the Change Accumulation utility, and it must be in standard form (see
VOLLIST(volser)
Required parameter you use to specify the volume serial numbers of the
change accumulation data set in the specified change accumulation run record.
You can specify a maximum of 255 volume serial numbers for volser. Each
volume serial number can be a maximum of six alphanumeric characters.
FILESEQ(1 | value)
Optional parameter you use to specify the file sequence number of the
identified change accumulation data set.
PURGLIST(time_stamp,YES | NO,COMPLETE | INCOMPLETE)
Optional parameter you use to specify the purge time, which is the point in
time in the input log records where change accumulation started and to specify
whether the logs form a complete subset.
The time stamp must be in standard form (see “Standard Time Stamp Format”
on page 126). 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 must
choose a purge time that satisfies the DBRC input requirements for recovery.
Recovery first chooses an image copy and then uses a change accumulation
whose purge time for that DBDS matches the run time of the image copy.
YES | NO
Mutually exclusive subparameters you use to specify whether any changes
for the corresponding DBDS have been accumulated.
YES
Specifies that some changes have been accumulated for the
corresponding DBDS.
NO
Specifies that no changes have been accumulated for the corresponding
DBDS.
COMPLETE | INCOMPLETE
Mutually exclusive subparameters you use to specify whether the logs
form a complete subset. To determine whether a log subset is complete,
use the LIST.CAGRP command. See “LIST.CAGRP” on page 292 for more
information.
COMPLETE
Specifies that the logs form a complete subset. When you specify
COMPLETE, the time stamp of the STOPTIME parameter is the stop
time of the last log input to the Change Accumulation utility.
INCOMPLETE
Specifies that the logs form an incomplete subset. When you specify
INCOMPLETE, the time stamp of the STOPTIME parameter is the start
time of the earliest unselected (open) log volume. This volume should
be the first one that is selected at a later run.
If you specify the PURGLIST parameter, the order of the time stamp and the
change indicator in the purge list corresponds to the order of the DBDS names
specified in the GRPMEM parameter of the INIT.CAGRP command. For

NOTIFY.CA
example, the third purge time and change indicator is the purge time for the
third DBDS that is specified in the GRPMEM parameter of the INIT.CAGRP
command.
If you specify fewer subparameters with the PURGLIST parameter than you
specified with the GRPMEM parameter of the INIT.CAGRP command, DBRC
uses the defaults of NO and COMPLETE for each DBDS that you omit.
Similarly, if you do not specify the PURGLIST parameter, DBRC uses the
defaults of NO and COMPLETE for each DBDS specified with the GRPMEM
parameter of the INIT.CAGRP command. To use a default of NO for certain
DBDSs, use commas to indicate which DBDSs are subject to the default.
the change accumulation data set resides. unittype can be up to eight
COMP | SUBSET
Mutually exclusive, optional parameters you use to indicate that the change
accumulation record’s stop time is a log volume start time.
COMP
Indicates that when the CA was created, a complete set of logs was
processed and that the CA’s stop time is the stop time of the last log
volume processed.
SUBSET
Indicates that when the CA was created, a subset of logs was processed
and the CA’s stop time is the start time of the first unprocessed log
volume. Specifying INCOMPLETE in the PURGLIST parameter does not
automatically cause SUBSET to be set.
You do not need to use this parameter under normal conditions. Checking is
not done to verify that the use of this parameter is consistent with the value of
the CA stop time. This parameter value is used by the GENJCL.CA and
GENJCL.RECOV processes. Incorrect use of this parameter can result in invalid
generated JCL.
Example of Adding CADSN Information to RECON

In this example, information about a change accumulation data set is to be added
to RECON.
//NFYCA JOB
.
.
.
//SYSIN DD *
NOTIFY.CA GRPNAME(CAGRP2) -
STOPTIME(840240202020) -
RUNTIME(840250305029) CADSN(CADSN06) -
VOLLIST(VOL005) -
PURGLIST((840240302005,YES),,(840250420256,))
/*
NOTIFY.IC
Use a NOTIFY.IC command to add information about an image copy.
HALDB Restrictions:
v The NOTIFY.IC command is not allowed for ILDS or Index DBDSs of HALDB
partitions

NOTIFY.IC
| v The NOTIFY.IC command will fail if it is attempting to record an image copy of a

| HALDB that has an online reorganization in progress. This is because an image
| copy of a HALDB cannot be taken while the HALDB is being reorganized online
| and the reorganization has not completed (either it is in progress or was
| terminated).
| NOTIFY.IC Syntax
| NOTIFY.IC DBD(name) DDN(name) ICDSN(name) RUNTIME(time_stamp)
| AREA(name)
| ,
| FILESEQ(1) UNIT(3400)
VOLLIST( volser )
FILESEQ(value) UNIT(unittype)
| BATCH
|
, ONLINE RECDCT(value)
CIC
ICDSN2(name) VOLLIST2( volser ) A SMSCIC
SMSNOCIC
|
| STOPTIME(time_stamp) USID(value)
| A:
| FILESEQ2(1) UNIT2(3400)
FILESEQ2(value) UNIT2(unittype)
|
| Parameters for NOTIFY.IC

DBD(name)
Required parameter you use to specify the database name of the DBDS or area
for which an image copy run record is to be added.
Restriction for HALDBs: When using the NOTIFY.IC command for HALDBs,
name must specify the name of a HALDB partition.
Mutually exclusive, required parameters you use to specify the data set
ddname of the DBDS (use DDN) or DEDB area (use AREA) for which an
image copy run record is to be added.
ICDSN(name)
Required parameter you use to specify the data set name of the image copy
data set that contains the image copy whose run record is being added. name
can be a maximum of 44 characters.
RUNTIME(time_stamp)
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

NOTIFY.IC
VOLLIST(volser)
Required parameter you use to specify (in the batch or online image copy
record) the volume serial numbers of the volumes on which the specified
image copy data set resides. This parameter is required when either ONLINE
or BATCH parameters are specified.
FILESEQ(1 | value)
identified image copy data set. value must be a decimal number from 1 to 9999.
FILESEQ2(1 | value)
identified duplicate image copy data set. value can be a decimal number from 1
to 9999.
You can specify this parameter only if you specify the VOLLIST2 parameter. If
the VOLLIST2 parameter is specified, then FILESEQ2(1) is the default for this
parameter.
ICDSN2(name)
Optional parameter you use to specify the data set name of the duplicate
image copy data set that is to contain the image copy whose run record is
being added. name can be a maximum of 44 characters.
VOLLIST2(volser)
Optional parameter you use to specify the volume serial numbers (in the
image copy record) of the volumes on which the specified duplicate image
copy data set resides. This parameter is required if ICDSN2 is specified, and
when either online or batch parameters are specified.
BATCH| ONLINE | CIC | SMSCIC | SMSNOCIC
Mutually exclusive, optional parameters you use to specify the type of image
copy that the data set contains.
Restriction: CIC, SMSCIC, and ONLINE cannot be used for user-recoverable
databases.
BATCH
Indicates that the Database Image Copy (DFSUDMP0) utility was used to
create the image copy while the database was unavailable for update
processing (the CIC parameter was not specified). BATCH can also be
specified to record the output of the HISAM Reorganization Unload utility
image copy.
ONLINE
Specifies that the image copy data set was obtained by executing the
Online Database Image Copy utility. You must use the STOPTIME
parameter when you specify ONLINE.
CIC
Indicates that a concurrent image copy was taken. A concurrent image
copy 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
copy VSAM KSDS databases.
SMSCIC
Indicates that the Database Image Copy 2 was used to create the image
copy while the database was available for update processing (’S’ was
specified on the utility control statement). The image copy is in DFSMS

NOTIFY.IC
dump format. The image copy is a “fuzzy” copy so logs must be applied
to recover the data set to a usable state. The STOPTIME parameter must be
specified when you specify SMSCIC.
SMSNOCIC
Indicates that the Database Image Copy 2 utility was used to create the
image copy while the database was unavailable for update processing (’X’
was specified on the utility control statement). The image copy is in
DFSMS dump format.
RECDCT(value)
Optional parameter you use to specify the count of the records in the image
copy data set. value must be a decimal number from 1 to 2147483647.
Optional parameter you use to specify the stop time of the online or
concurrent image copy. You must specify this parameter when online, CIC, or
SMSCIC is specified. The time stamp must be in standard form (see “Standard
Time Stamp Format” on page 126).
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.
Optional parameter you use to specify the unit type of the duplicate image
copy data set. The unit type can be up to eight alphanumeric characters long.
USID(value)
or area when the reorganization occurred.
USID is required if the database or area is assigned to a GSG. If the database
or area is not assigned to a GSG, USID is optional.
Example of Notifying DBRC of Concurrent Image Copy

Completion
In this example, DBRC is notified of the successful completion of a concurrent
image copy for the area specified. RUNTIME refers to the time the image copy
started. STOPTIME refers to the time the image copy ended.
//NFYIC JOB
.
.
.
//SYSIN DD *
NOTIFY.IC DBD(DBD001) AREA(AREA1)
RUNTIME(8520002020)
STOPTIME(8520004040)
ICDSN(IC0005) CIC
/*
NOTIFY.PRILOG (for OLDS)

Use a NOTIFY.PRILOG command to add information about a primary OLDS to
RECON and to manually create interim PRILOG in RECON. You would do this in
a case where the log processing exit routines of the IMS system failed to do so.
NOTIFY.PRILOG (for OLDS) Syntax

NOTIFY.PRILOG OLDS(ddname) DSN(name) STARTIME(time_stamp)
RUNTIME(time_stamp)


FIRSTREC(number) GSG(gsgname) INTERIM LASTREC(number)

LOGTOKEN(number) NXTOLDS(ddname) SSID(name)
Parameters for NOTIFY.PRILOG (for OLDS)

OLDS(ddname)
Required parameter you use to specify that a record is to be created in RECON
for an OLDS. If you do not specify OLDS, the default is RLDS (see
“NOTIFY.PRILOG (for RLDS)” on page 321). ddname is the DD statement that
the IMS online control region used when it used the OLDS.
DSN(name) | RUNTIME(time_stamp)
Mutually exclusive, required parameters.
DSN
Specifies the data set name of the primary OLDS for which a log record is
being created in RECON.
RUNTIME
Specifies the time stamp of a close operation for the specified primary
OLDS. The time stamp must be in standard form (see “Standard Time
These two parameters are used in conjunction with the STARTIME, FIRSTREC,
and NXTOLDS parameters to identify what type of primary OLDS entry is to
be added to the RECON. Table 14 indicates which parameter combinations are
required for each type of primary OLDS entry.
Definitions:
OLDS Open
Starting to use an OLDS and inserting a starting time.
OLDS Switch
Stopping the use of the current OLDS (inserting a stop time) and
starting to use the next OLDS (inserting a starting time into the new
OLDS).
OLDS Close
Stopping the use of an OLDS (inserting a stop time)
Table 14. Parameters of NOTIFY.PRILOG (for OLDS) Command for Open, Switch, and Close
Type of Log Entry Required Keywords
OLDS Open STARTIME, DSN, FIRSTREC
OLDS Switch STARTIME, DSN, FIRSTREC, NXTOLDS
OLDS Close LASTREC, STARTIME, RUNTIME
For each primary OLDS, you must issue a separate NOTIFY.PRILOG command
for open, switch, and close.
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 126.
See Table 14 for a description of the use of this parameter with other
parameters in the NOTIFY.PRILOG command.

FIRSTREC(number)
Optional parameter you use to specify the log record sequence number of the
first log record of the OLDS. For the first OLDS of the PRILOG, it corresponds
to the first log record that was written during initialization of the IMS
subsystem.
FIRSTREC is required for OLDS OPEN and SWITCH commands. It specifies the
first log record sequence number on the OLDS that is being opened. It is
invalid for 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 preceded by
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. For
example: FIRSTREC(68508).
In either case, leading zeros can be omitted.
GSG(gsgname)
Optional parameter you use to specify the GSG name of the IMS subsystem
that produced the OLDS.
GSG is required if LOGTOKEN is specified.
INTERIM
Optional parameter you use to specify that an interim log data set record is to
be created.
Before you specify NOTIFY.PRILOG INTERIM, a corresponding primary log record
must exist.
LASTREC(number)
last log record of the OLDS.
LASTREC is required for the OLDS CLOSE command. It is optional for the
SWITCH command; if it is omitted, the FIRSTREC value minus 1, is recorded for
the OLDS that is being closed. It is invalid for an OPEN command.
the letter, X. For example: LASTREC(X'10B9C').
v A decimal number
example: LASTREC(68508).
LOGTOKEN(number)
Optional parameter you use to specify the log token to be inserted into the
PRILOG record and, if necessary, into the GSG record. It is valid only on an
OLDS Open command.
Log tokens are numeric, assigned sequentially within PRILOG records for the
same GSG, and used during recovery to ensure that all logs produced by
members of the GSG have been included. The highest token assigned to any
PRILOG 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 the
same GSG, if any.
v Must be less than that contained in the next PRILOG record for the same
GSG, if any.
v Must not be more than one greater than the high PRILOG token contained
in the specified GSG record.
NXTOLDS(ddname)
Optional parameter you use when RECON is to be updated to reflect an OLDS
switch. The current OLDS is closed and an IMS online control region opens a
new OLDS. ddname is the DD statement of the OLDS being opened. You
specify the OLDS being closed with the OLDS(ddname) parameter. Use the
DSN(name) parameter to specify the data set name of the OLDS being opened.
Use the STARTIME(time_stamp) parameter to specify the close time of the
OLDS being closed and the open time of the OLDS being opened.
SSID(name)
created the log data set.
The SSID is an eight-character, alphanumeric string that represents a valid IMS
default subsystem identifier in the RECON header record. You use the
INIT.RECON or CHANGE.RECON command to set the default subsystem identifier in
the RECON header record. If you have not specified a default in the RECON
header record, you must specify SSID.
Examples of Using the NOTIFY.PRILOG (for OLDS) Command

Here are some examples of using the NOTIFY.PRILOG (for OLDS) command.
Example of Creating a PRIOLDS for an Online Subsystem OLDS: In this

example, you create a PRIOLDS for an OLDS that belongs to IMS online subsystem
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 to RECON: In this

example, you create a PRIOLDS for two OLDSs that belong to the IMS online
subsystem IMSA. Both OLDSs are closed. The first STARTIME parameter specifies
the time stamp of the opening of the primary OLDS. The DSN parameter indicates
that information that is added relates to the opening of the OLDS. NXTOLDS
indicates an OLDS switch. The second STARTIME parameter and second DSN
indicate the start time and DSN of the next OLDS. The third STARTIME parameter
indicates the start time of the OLDS to be closed. The RUNTIME parameter is the
time stamp of the closing volume.
NOTIFY.PRILOG SSID(IMSA) STARTIME(812171212120) OLDS(DFSOLP01) -
DSN(IMS.OLDP01) LASTREC(4999)

DSN(IMS.OLDP02) NXTOLDS(DFSOLP02)
RUNTIME(932191010101)
/*
Example of Creating a PRILOG to Record 2 OLDSs Opening and Closing: In

this example, you create a PRILOG to record the opening and closing of two
OLDSs. 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)
OLDS(OLDS001) LASTREC(4999)+
NXTOLDS(OLDS002) DSN(IMS.OLDS.A02) STARTIME(930140930000) FIRSTREC(5000)
OLDS(OLDS002) STARTIME(930140930000) +
RUNTIME(930141030000) LASTREC(9999)
NOTIFY.PRILOG (for RLDS)

Use a NOTIFY.PRILOG command to add information about a primary RLDS (or a
primary SLDS that a batch subsystem created) to 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 log
processing exit routines. If you are processing DBDSs with IMS, you should not
need to use this command under normal operating conditions. You must specify a
NOTIFY.ALLOC command for each DBDS for which change records might exist on
the primary RLDS being added.
This command adds or completes a data set entry in a PRILOG record. If you are
modifying an existing completed data set entry, you should use the
CHANGE.PRILOG(RLDS) command.
NOTIFY.PRILOG (for RLDS) Syntax

NOTIFY.PRILOG DSN(name) STARTIME(time_stamp)
RUNTIME(time_stamp)

0 CHKPTID(chkptid) 1
CHKPTCT( value ) FILESEQ( value )

LOCAL RLDS

LOGTOKEN(number) NONLOCAL SSID(name) 3400
UNIT( unittype )


VOLSER(volser)
Parameters for NOTIFY.PRILOG (for RLDS)

DSN
Specifies the data set name of the primary RLDS for which a log record is
being created in RECON.
RUNTIME
Specifies the time stamp of a close or end-of-volume (EOV) operation for
the specified primary RLDS. The time stamp must be in standard form (see
These two parameters are used in conjunction with the STARTIME and
VOLSER parameters to identify what type of primary-recovery-log-data set
entry is to be added to RECON.
Table 15 indicates which parameter combinations are required for each type of
primary-recovery-log-data-set entry.
Definitions:
RLDS Open
Starting to use an RLDS and inserting a starting time.
RLDS EOV
RLDS end of volume (EOV) notification from the operating system.
This is analogous to an OLDS Switch.
RLDS Close
Stopping the use of an RLDS (inserting a stop time)
Table 15. 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 command
for open, zero or more EOVs, and close.
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 126.
CHKPTCT(0 | value)
Optional parameter you use to specify the number of checkpoints completed
on the 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 to
recover a Fast Path area with concurrent image copy.
CHKPTID(chkptid)
Optional parameter you use to specify the oldest checkpoint ID for an active
partition specification table (PST) on an RLDS volume. The checkpoint ID must
be in the standard form for a time stamp (see “Standard Time Stamp Format”
on page 126).
FILESEQ(1 | value)
Optional parameter you use to specify the file sequence number of the primary
RLDS that is identified. You can specify this parameter only if you have
specified the VOLSER parameter.
FIRSTREC(number)
first log record of the RLDS. For the first RLDS of the PRILOG, it corresponds
subsystem.
FIRSTREC is required if DSN is specified and is invalid if RUNTIME is
specified.
v A decimal number
GSG(gsgname)
that produced the RLDS.
GSG is required if NONLOCAL or LOGTOKEN is specified.
INTERIM
be created. Before you issue the NOTIFY.PRILOG INTERIM command, you must
create a corresponding primary recovery log record.
LASTREC(number)
last 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 into
the PRILOG record and, if necessary, into the GSG record. It is valid only on
an RLDS OPEN command; otherwise, it is ignored.
Log tokens are numeric, assigned sequentially within PRILOG records for the
same GSG, and used during recovery to ensure that all logs produced by
members of the GSG have been included. The highest token assigned to any
PRILOG 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 the
same GSG, if any.
v Must be less than that contained in the next PRILOG record for the same
GSG, if any.
v Must not be more than one greater than the high PRILOG token contained
in the specified GSG record.
LOCAL | NONLOCAL
Mutually exclusive, optional parameters you use to specify where the RLDS
data was originally created. LOCAL is used if the RLDS was created by an
active IMS subsystem of the local service group. NONLOCAL is used if the
RLDS was originally created by an active IMS subsystem of the non-local
service group and transported to the tracking site.
LOCAL or NONLOCAL need only be specified when creating the PRILOG
record. The LOCAL and NONLOCAL keywords are ignored on subsequent
NOTIFY.PRILOG invocations for the PRILOG record.
If NONLOCAL is specified, none of the keywords CHKPTID, FILESEQ, UNIT,
or VOLSER can be specified (the data sets must be cataloged) on any
NOTIFY.PRILOG invocation for the PRILOG record.
RLDS
Optional parameter you use to specify that an RLDS record is to be created or
updated.
SSID(name)
The SSID is an eight-character alphanumeric string that represents a valid IMS
Optional parameter you use to specify the unit type of the RLDSs. You only
specify the UNIT parameter if you specify the DSN parameter. The unit type
can be up to eight alphanumeric characters long.
VOLSER(volser)
Optional parameter you use to specify the volume serial number of the log

volume 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) Command

Here are some examples of using the NOTIFY.PRILOG (for RLDS) command.
Example of Adding Primary RLDS Information to RECON: In 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 relates to the
opening of the primary RLDS. The STARTIME parameter specifies the time stamp
of the opening of the primary RLDS. The first RUNTIME parameter specifies the
time stamp of the EOV of the first volume of the primary RLDS. The second
RUNTIME parameter specifies the time stamp of the closing volume of the
primary RLDS.
//NFYPRILG JOB
.
.
.
//SYSIN DD *
NOTIFY.PRILOG RLDS STARTIME(820670201010) -
VOLSER(VOL001) DSN(PRILOG1) FIRSTREC(001)
VOLSER(VOL002) RUNTIME(820670202020)
LASTREC(9999) RUNTIME(820670303030)
/*
Example of Adding Interim-Primary RLDS Information to RECON: In this

example, information about the interim-primary RLDS is to be added to RECON.
The STARTIME parameter specifies the time stamp of the opening of the interim
primary RLDS.
//NFYPRILG JOB
.
.
.
//SYSIN DD *
DSN(DSNIRLDS) -
VOLSER(VOL008) -
FIRSTREC(077) -
INTERIM
/*
Example of Creating a PRILOG Record for 2 Tracking Log DSs: In this example,
the sequence of NOTIFY.PRILOG commands create a PRILOG record 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)

Use a NOTIFY.PRILOG command to add information about a primary SLDS or
TSLDS to 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 log processing exit routines.
If you are processing DBDSs with IMS, you should not need to use this command
under normal operating conditions. You must specify a NOTIFY.ALLOC command for
each DBDS for which change records might exist on the primary SLDS being
added.
This command adds or completes a data set entry in the PRISLD or PRITSLDS
record. If you are modifying an existing completed data set entry, you should use
the 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 the
corresponding RLDS. Use NOTIFY.PRILOG (for RLDS) to add information about a
SLDS that a batch subsystem creates, because DBRC considers such a data set to be
an RLDS.
NOTIFY.PRILOG (for SLDS and TSLDS) Syntax

NOTIFY.PRILOG SLDS DSN(name) STARTIME(time_stamp)
TSLDS RUNTIME(time_stamp)

CHKPTCT(value) CHKPTID(chkptid) 1
FILESEQ( value )
LOCAL

FIRSTREC(number) GSG(gsgname) INTERIM LASTREC(number) NONLOCAL

SSID(name) 3400 VOLSER(volser)
UNIT( unittype )
Parameters for NOTIFY.PRILOG (for SLDS and TSLDS)

SLDS
Required parameter you use to specify that a record is to be created or
updated for a SLDS.
Important: If you do not specify SLDS or TSLDS, the default is RLDS (see
“NOTIFY.PRILOG (for RLDS)” on page 321).
TSLDS
updated for 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 321).

DSN
Specifies the data set name of the primary SLDS or TSLDS for which a log
record is being created in RECON.
RUNTIME
Specifies the time stamp of a close or EOV operation for the specified
primary SLDS or TSLDS. The time stamp must be in standard form (see
These two parameters are used in conjunction with the STARTIME, FIRSTREC,
LASTREC, and VOLSER parameters to identify what type of
primary-system-log-data-set entry is to be added to RECON. Table 16 indicates
which parameter combinations are required for each type of
primary-system-log-data set entry.
Definitions:
SLDS Open
Starting to use an SLDS and inserting a starting time.
SLDS EOV
SLDS end of volume (EOV) notification from the operating system.
This is analogous to an OLDS Switch.
SLDS Close
Stopping the use of an RLDS (inserting a stop time)
Table 16. Parameters of NOTIFY.PRILOG (SLDS or TSLDS) Command for Open, EOV, and
Close
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.PRILOG
command for open, zero or more EOVs, and close.
Required parameter you use to specify the starting time of a primary SLDS or
TSLDS. Use the log start time from the subsystem record or the PRILOG
CHKPTCT(value)
on the SLDS or TSLDS volumes. You specify a value for each SLDS or TSLDS
volume 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)
PST on an SLDS or TSLDS volume. The checkpoint ID must be in the standard
form for a time stamp (see “Standard Time Stamp Format” on page 126).
FILESEQ(1 | value)
Optional parameter you use to specify the file sequence number of the primary
SLDS or TSLDS that is identified. You specify this parameter only if you have
also specified the VOLSER parameter.
FIRSTREC(number)
first log record of the SLDS or TSLDS. For the first SLDS of the PRISLD or
TSLDS of the PRITSLDS, FIRSTREC corresponds to the first log record that
was written during initialization of the IMS subsystem.
specified.
v A decimal number
GSG(gsgname)
that produced the SLDS or TSLDS.
GSG is required if NONLOCAL is specified.
INTERIM
be created.
LASTREC(number)
last log record of the SLDS or TSLDS.
(that is, on a CLOSE call). LASTREC is invalid if DSN is specified.
v A decimal number
LOCAL | NONLOCAL
Mutually exclusive, optional parameters you use to specify where the SLDS or
TSLDS data was originally created. LOCAL is used if the SLDS or TSLDS was
created by an active IMS subsystem of the local service group. NONLOCAL is

used if the SLDS or TSLDS was originally created by an active IMS subsystem
of the non-local service group and transported to the tracking site.
LOCAL or NONLOCAL need only be specified when creating the PRISLDS or
PRITSLDS record. The LOCAL and NONLOCAL keywords are ignored on
subsequent NOTIFY.PRILOG invocations for the PRISLD or PRITSLDS record.
NOTIFY.PRILOG invocation for the PRISLD or PRITSLDS record.
SSID(name)
The SSID is an eight-character, alphanumeric string that represents a valid IMS
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. The
unit type can be up to eight alphanumeric characters.
VOLSER(volser)
Optional parameter you use to specify the volume serial number of the log
volume being recorded for the identified primary SLDS or TSLDS. For an EOV
notification, this volume serial number is that of the volume being started.
Note: You must use the VOLSER parameter during SLDS or TSLDS open and
EOV.
Example of Adding Primary SLDS Information to RECON

In this example, information about a primary SLDS is to be added to RECON. The
VOLSER and DSN parameters indicate that the information to be added relates to
the opening of the primary SLDS. The STARTIME parameter specifies the time
stamp of the opening of the primary SLDS. The first RUNTIME parameter specifies
the time stamp of the EOV of the first volume of the primary SLDS. The second
RUNTIME parameter specifies the time stamp of the closing volume of the
primary SLDS.
//NFYPRILG JOB
.
.
.
//SYSIN DD *
NOTIFY.PRILOG SLDS STARTIME(820670201010) -
VOLSER(VOL004) DSN(PRILOG4) FIRSTREC(7000)
VOLSER(VOL005) RUNTIME(820670202020)
RUNTIME(820670303030) LASTREC(8889)
/*
NOTIFY.RECOV
Use a NOTIFY.RECOV command to add information about recovery of a specified
DBDS or DEDB area to RECON. You must use this command whenever you
perform the recovery of a DBDS or DEDB area in any way other than using the
Database Recovery utility (for example, by restoring the DASD volume on which

NOTIFY.RECOV
the DBDS or area resides). In addition, you can notify DBRC when you recover a
DBDS or DEDB area using the Database Recovery utility.
When specifying the RCVTIME parameter to inform DBRC of a time-stamp

recovery, RECON must contain a record of the image copy data set that you used
to restore the DBDS or DEDB area. The image copy record can be either a standard
or a nonstandard image copy. If it is a nonstandard image copy, then its time
stamp cannot fall within the range of an existing time-stamp recovery (the time
between the RECOV TO and RUN times). The time stamp of the image copy
record must be equal to that specified in the RCVTIME parameter of the
NOTIFY.RECOV command.
| For a receive, specify both the RCVUSID and RUNUSID parameters. Specify the
| same usid value for both parameters: the update set identifier (usid) of the image
| copy that was used for recovery. For a time-stamp recovery, specify the RCVUSID
| parameter with the usid value that the database was recovered to, and specify the
| RUNUSID parameter with the usid that was current when the recovery occurred.
| Future recoveries will ignore all records associated with usid values between those
| specified for the RCVUSID and RUNUSID parameters.
In a data sharing environment, after you notify DBRC of a nonstandard recovery

or an IMS recovery, DBRC turns off the recovery-needed flag and decreases the
counter in the appropriate DBDS and DB records in RECON.
Related Reading: See IMS Version 9: Operations Guide for more information about
recovery in a data sharing environment.
Restriction for HALDBs: This command is not allowed for ILDS or Index DBDSs
of HALDB partitions.
NOTIFY.RECOV Syntax
NOTIFY.RECOV DBD(name) DDN(name)
AREA(name) RCVTIME(time_stamp) RCVUSID(usid)
CURRENT DBDS

RUNUSID(usid) ADDN(name) RUNTIME(time_stamp) TRACK
PITR
Parameters for NOTIFY.RECOV

DBD(name)
DEDB area.
Restriction for HALDBs: When using the NOTIFY.RECOV command for
Mutually exclusive, required parameters you use to specify the ddname of the
DBDS or DEDB area for which DBRC is to add the database recovery record to
RECON.
ADDN(name)
Optional parameter you use to specify the ADS DD name of the ADS for
which a Fast Path DEDB area recovery record is being added to RECON.

NOTIFY.RECOV
You can specify this parameter only when you specify the AREA(name)
parameter.
CURRENT | RUNTIME(time_stamp)PITR
Mutually exclusive, optional parameters you use to specify the time stamp at
which the DBDS or DEDB area was recovered.
CURRENT
Specifies that the current time stamp is to be used as the time stamp of the
recovery. You can add the recovery information to RECON in a later step
of the same job that performs the recovery if you specify CURRENT.
RUNTIME
Specifies the actual time stamp of a recovery of the DBDS or DEDB area.
The time stamp must be in standard form (see “Standard Time Stamp
The optional PITR parameter specifies a point-in-time recovery. You must
use the RCVTIME parameter if you use PITR.
DBDS | TRACK
Mutually exclusive, optional parameters you use to specify the type of IMS
recovery that was done on a DBDS or DEDB area.
DBDS
Specifies that the recovery was a full recovery or a time-stamp recovery.
TRACK
Specifies that the recovery was a track recovery.
If you specify this parameter and the RCVTIME parameter, the command fails.
RCVTIME(time_stamp)
Optional parameter you use to specify the point in time to which the DBDS or
DEDB area was restored. It can be any time when the DBDS or area was not
being updated, that is, a time that is not covered by an active ALLOC record in
RECON.
If you do not specify the RCVTIME parameter, you are notifying DBRC of a
full recovery.
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 RUNTIME parameter with the PITR
parameter.
Restriction: Do not use the RCVTIME parameter when recovering from a
nonstandard image copy at a tracking subsystem.
See 251 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 by
RSR 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) at
the 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.

NOTIFY.RECOV
RUNUSID must be specified for recovery of an RSR-covered database or DEDB

area.
Example of Adding DBDS Recovery Information to RECON

In this example, information about recovery of a specified DBDS is to be added to
RECON. The RUNTIME parameter specifies the time stamp of the recovery of the
DBDS. The PITR parameter specifies a point-in-time recovery. The RCVTIME
parameter 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.
RECOV
RUN = 1997.135 10:15:36.6 -08:00 * RUN USID = 0000000005
RECOV TO= 1997.135 09:05:29.7 -08:00 RECOV TO USID = 0000000004
POINT-IN-TIME
NOTIFY.REORG
Use a NOTIFY.REORG command to add a record to RECON about the reorganization
of the database to which an identified DBDS belongs.
The information in the reorganization record is used by DBRC to determine which

image copy data sets, change accumulation data sets, and log data sets are valid as
input to a subsequent recovery of the identified DBDS.
Restrictions:
v This command should not be used following the reorganization of a Fast Path
DEDB. Such databases can be recovered after a reorganization.
v This command turns on the flag needed by the image copy process in the DBDS
record. You must either run an image copy or issue the CHANGE.DBDS ICOFF
command to turn off the flag.
v This command can also be used to record in RECON the equivalent of an image
copy data set that was created for the HISAM Reorganization Reload utility. Use
this 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 image
copy data set that was created as part of the processing by the HISAM
Reorganization Reload utility.
v You must specify a NOTIFY.REORG command for each DBDS in the database that
was reorganized. A DD statement for the IMS DBDLIB data set must be
provided in the job stream of the NOTIFY.REORG command.
v The NOTIFY.REORG command, and database reorganization in general, are invalid
for databases at an RSR tracking site.
v The NOTIFY.REORG command is not allowed for ILDS or Index DBDSs of HALDB
partitions.

NOTIFY.REORG
NOTIFY.REORG Syntax
CURRENT
NOTIFY.REORG DBD(name) DDN(name)
RUNTIME(time_stamp)

1 1 ICDSN(name) ICDSN2(name)
FILESEQ( value ) FILESEQ2( value )
OFFLINE

ONLINE RECDCT(value)
NORECOV
RECOV

3400 3400 ,
UNIT( unittype ) UNIT2( unittype )
VOLLIST( volser )

, USID(value)
VOLLIST2( volser )
Parameters for NOTIFY.REORG

DBD(name)
Required parameter you use to identify the database name of the DBDS that
was reorganized.
Restriction for HALDBs: When using the NOTIFY.REORG command for
DDN(name)
Required parameter you use to identify the data set ddname of the DBDS that
was reorganized.
CURRENT | RUNTIME(time_stamp)
Mutually exclusive, optional parameters you use to specify the time stamp of
the reorganization of the identified DBDS.
CURRENT
Specifies that the current time stamp is to be placed in the reorganization
record. You can specify a NOTIFY.REORG command as a later step in the
same job that performs the reorganization if you specify CURRENT.
RUNTIME
Specifies that the actual time stamp of the reorganization is to be placed in
the reorganization record. The time stamp must be in standard form (see
FILESEQ(1 | value)
identified DBDS that was included in the logs that were used as input to a run
of the HISAM Reorganization Reload utility. The description of the ICDSN

NOTIFY.REORG
parameter contains information about the log data set with which this
parameter is associated. You use this parameter only when the VOLLIST
parameter has also been specified.
FILESEQ2(1 | value)
identified DBDS when it was included in the logs that were used as input to
the HISAM Reorganization Reload utility. The description of the ICDSN2
parameter contains information about the log data set with which this
parameter is associated. You use this parameter only when the VOLLIST2
parameter has also been specified.
ICDSN(name)
Optional parameter you use to specify the data set name of the image copy
data set that was created as part of a HISAM reorganization of a database. (If
you 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 data
sets.)
You can specify an ICDSN parameter only if the corresponding DBDS was
identified 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
image copy data set that was created as part of a HISAM reorganization of a
database. (If you 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 data sets.)
You can specify an ICDSN2 parameter only if you have specified an ICDSN
parameter.
| OFFLINE | ONLINE
| Mutually exclusive, optional parameters that specify whether the
| reorganization is a HALDB OLR or an offline reorganization.
| OFFLINE
| Specifies that the DBDS was reorganized offline.
| ONLINE
| Specifies that the reorganization is a HALDB OLR.
| STOPTIME(time_stamp)
| Optional parameter that specifies the time when a HALDB
| OLR completed successfully.
| NORECOV | RECOV
| Mutually exclusive, optional parameters that specify whether
| the online reorganization can be used as input for recovery.
| NORECOV Specifies that the HALDB OLR cannot be used
| as input to recovery.
| RECOV Specifies that the HALDB OLR may be used as
| input to recovery.
RECDCT(value)
Optional parameter you use to specify the number of records that are
contained in the identified DBDS. value must be a decimal number from 1 to
2 147 483 647.

NOTIFY.REORG
the image copy data set resides. The unit type can be up to eight alphanumeric
characters.
the duplicate image copy data set resides. The unit type can be up to eight
VOLLIST(volser)
Optional parameter you use to specify the volume serial numbers of the
volumes on which the image copy data set identified by the ICDSN keyword
resides. You can specify up to 255 volume serial numbers for volser; each volser
can be up to six alphanumeric characters.
VOLLIST2(volser)
Optional parameter you use to specify the volume serial numbers of the
volumes on which the duplicate image copy data set, identified by the ICDSN2
parameter, resides. You can specify up to 255 volume serial numbers for volser;
each can be up to six alphanumeric characters.
USID(value)
or area when the reorganization occurred.
USID is required if the database or area is assigned to a global service group. If
the database or area is not assigned to a GSG, USID is optional.
Example Adding DBDS Reorganization Information to RECON

In this example, information about a reorganization of a specified DBDS is to be
added to RECON. The DBDLIB data set is specified, because DBRC requests a
search of it to verify that the reorganization occurred. The names of two image
copy data sets for the reorganized DBDS are given. They both follow the data set
naming convention, and a list of volumes is provided for both image copy data
sets.
//NFYREORG JOB
.
.
.
//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)

Use a NOTIFY.SECLOG command to add information about a secondary OLDS to
RECON and to manually create an ISECOLDS record in RECON. RECON must
already contain a PRIOLDS record with the same SSID and STARTIME. This is
information that could not be added from the IMS log data exit routines. This
command is not normally required.
NOTIFY.SECLOG (for OLDS) Syntax

NOTIFY.SECLOG OLDS(ddname) DSN(name) STARTIME(time_stamp)
RUNTIME(time_stamp)



NXTOLDS(ddname) SSID(name)
Parameters for NOTIFY.SECLOG (for OLDS)

OLDS(ddname)
updated in RECON for the OLDS.
ddname is the ddname that the IMS online control region used when it used the
OLDS.
DSN
Specifies the data set name of the secondary OLDS for which an online log
record is being created in RECON.
RUNTIME
Specifies the time stamp of an open or close operation of the specified
secondary OLDS. The time stamp must be in standard form (see “Standard
Time Stamp Format” on page 126).
DSN and RUNTIME are used in conjunction with the STARTIME, FIRSTREC,
LASTREC, and NXTOLDS parameters to identify which type of secondary
online-log-data-set entry is to be added to RECON. Table 17 indicates the
keyword combinations that correspond to the type of secondary-online-log
data-set entry.
Table 17. 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.SECLOG command
for open, switch, and close operations.
Required parameter you use to specify the starting time of a secondary OLDS.
on page 126).
parameters in the NOTIFY.SECLOG command.
FIRSTREC(number)
first log record of the OLDS. For the first OLDS of the SECLOG, FIRSTREC
corresponds to the first log record that was written during initialization of the
IMS subsystem.

FIRSTREC is required for OLDS OPEN and SWITCH commands. It specifies the
first log record sequence number on the OLDS being opened. It is invalid for a
CLOSE command.
v A decimal number
GSG(gsgname)
that produced the OLDS.
GSG is required if LOGTOKEN is specified.
INTERIM
be created. Before you create an interim log data set, you must create a
secondary OLDS.
LASTREC(number)
last log record of the OLDS.
LASTREC is required for the OLDS CLOSEcommand. It is optional for the
SWITCH command; if it is omitted, the FIRSTREC value minus 1, is recorded for
the OLDS 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 OLDS
switch. The current OLDS is closed and an IMS online control region opens a
new OLDS. ddname is the DD statement of the OLDS being opened. You
specify the OLDS being closed with the OLDS(ddname) parameter. Use the
DSN parameter to specify the data set name of the OLDS being opened. Use
the STARTIME parameter to specify the close time of the OLDS being closed
and the open time of the OLDS being opened.
SSID(name)


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

Here are some examples of using the NOTIFY.SECLOG (for OLDS)command.
Example of Creating the ISECOLDS Record That Corresponds to the OLDS: In

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 OLDSs: In this

example, you create a SECOLDS record for two secondary OLDSs that belong 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 the OLDS. NXTOLDS indicates an OLDS switch. The second STARTIME
parameter and second DSN indicate the start time and DSN of the next OLDS. The
third STARTIME parameter indicates the start time of the OLDS to be closed. The
RUNTIME parameter is the time stamp of the closing volume.
NOTIFY.SECLOG SSID(IMSA) STARTIME(812171212120) OLDS(DFSOLS01)-
DSN(IMS.OLSS01)
DSN(IMS.OLSS02) NXTOLDS(DFSOLS02)
RUNTIME(932191010101)
NOTIFY.SECLOG (for RLDS)

Use a NOTIFY.SECLOG command to add information about a secondary RLDS to
RECON and to manually create an ISECLOG record in RECON. RECON must
already contain a PRILOG with the same SSID and STARTIME. This is information
that could not be added from the IMS log data exit routines. This command is not
normally required.
This command adds or completes a data set entry in the Primary Log record. If
you are modifying an existing completed data set entry, you should use the
CHANGE.SECLOG (RLDS)command.
NOTIFY.SECLOG (for RLDS) Syntax

NOTIFY.SECLOG DSN(name) STARTIME(time_stamp)
RUNTIME(time_stamp)


LOCAL


RLDS SSID(name) 3400 VOLSER(volser)
UNIT( unittype )
Parameters for NOTIFY.SECLOG (for RLDS)

DSN
Specifies the data set name of the secondary RLDS for which a recovery
log record is being created in RECON.
RUNTIME
Specifies the time stamp of an open, close, or EOV operation of the
specified secondary RLDS. The time stamp must be in standard form (see
DSN and RUNTIME are used in conjunction with the STARTIME and VOLSER
parameters to identify which type of secondary recovery log data set entry is
to be added to RECON. Table 18 indicates the keyword combinations that
correspond to the type of secondary recovery log data set entry.
Table 18. 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 command
for open, zero or more ends-of-volume, and close processing.
Required parameter you use to specify the starting time of a secondary RLDS.
on page 126).
If you issue a subsequent STARTIME parameter, that time is the start time of
the volume. See Table 18 for a description of the use of this parameter with
other parameters in the NOTIFY.SECLOG command.
CHKPTCT(0 | value)
on the 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)
PST on an RLDS volume. The checkpoint ID must be in standard form for a
time stamp (see “Standard Time Stamp Format” on page 126).
FILESEQ(1 | value)
secondary RLDS that is identified. You specify this parameter only if you have
also specified the VOLSER parameter.
FIRSTREC(number)
first log record of the RLDS. For the first RLDS of the SECLOG, it corresponds
subsystem.
specified.
v A decimal number
GSG(gsgname)
that produced the RLDS.
INTERIM
be created.
LASTREC(number)
last log record of the RLDS.
(that is, on a Close call). LASTREC is invalid if DSN is specified.
v A decimal number
LOCAL | NONLOCAL
Mutually exclusive, optional parameters you use to specify where the RLDS
data was originally created. LOCAL is used if the RLDS was created by an
active IMS subsystem of the local service group. NONLOCAL is used if the

RLDS was originally created by an active IMS subsystem of the non-local

service group and transported to the tracking site.
LOCAL or NONLOCAL need only be specified when creating the SECLOG
record. The LOCAL and NONLOCAL keywords are ignored on subsequent
NOTIFY.SECLOG invocations for the SECLOG record.
NOTIFY.SECLOG invocation for the SECLOG record.
RLDS
Optional parameter you use to specify that a record is to be created or updated
in RECON for an IMS RLDS.
SSID(name)
the secondary RLDSs reside. You only specify the UNIT parameter if you
specify the 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
recovery log volume that is being recorded for the identified secondary RLDS.
For an EOV notification, this volume serial number is that of the volume being
started. Table 18 on page 339 identifies when you use the VOLSER parameter.
Examples of Using the NOTIFY.SECLOG (for RLDS) Command

Here are some examples of using the NOTIFY.SECLOG (for RLDS) command.
Example of Adding Secondary RLDS Information to RECON: In this example,

information about a secondary RLDS is to be added to RECON. The STARTIME
parameter identifies the secondary RLDS by its opening time stamp. The VOLSER
and DSN parameters indicate that the information to be added relates to the
opening of the primary RLDS. The first RUNTIME parameter specifies the time
stamp of the EOV of the secondary RLDS. The second RUNTIME parameter
specifies the time stamp of the closing of the secondary RLDS.
//NFYSECLG JOB
.
.
.
//SYSIN DD *
NOTIFY.SECLOG RLDS STARTIME(820670201010) -
DSN(DSN003) VOLSER (VOL001)
RUNTIME(820680204500) VOLSER(VOL002)
RUNTIME(820682030000)
/*

Example of Adding Interim Secondary RLDS Information to RECON: In this

example, information about the interim secondary RLDS is to be added to RECON.
The STARTIME parameter specifies the time stamp of the opening of the
interim-secondary RLDS, and the RUNTIME parameter specifies the time stamp of
the closing of the interim-secondary RLDS.
//NFYSECLG JOB
.
.
.
//SYSIN DD *
NOTIFY.SECLOG RLDS RUNTIME(822561630000)-
STARTIME(822541234561) INTERIM
/*
NOTIFY.SECLOG (for SLDS and TSLDS)

Use a NOTIFY.SECLOG command to add information about a secondary SLDS or
TSLDS to RECON and to manually create an ISECSLDS record in RECON. RECON
must already contain a primary log data set record with the same SSID and
STARTIME. This is information that could not be added from the log data exists of
the IMS system. This command is not normally required.
This command adds or completes a data set entry in the Primary or Secondary Log
record. If you are modifying an existing completed data set entry, use the
CHANGE.SECLOG (for SLDS) command or the CHANGE.SECLOG (for TSLDS) command.
NOTIFY SECLOG (for SLDS and TSLDS) Syntax

NOTIFY.SECLOG SLDS DSN(name) STARTIME(time_stamp)
TSLDS RUNTIME(time_stamp)

LOCAL


SSID(name) 3400 VOLSER(volser)
UNIT( unittype )
Parameters for NOTIFY SECLOG (for SLDS and TSLDS)

SLDS
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 321 for more information on the RLDS
parameter.
TSLDS
Required 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 321 for more information on the RLDS
parameter.

DSN
Specifies the data set name of the secondary SLDS or TSLDS for which a
system log record is being created in RECON.
RUNTIME
Specifies the time stamp of an open, close, or EOV operation of the
specified secondary SLDS. The time stamp must be in standard form (see
DSN and RUNTIME are used in conjunction with the STARTIME and VOLSER
parameters to identify which type of secondary system log data set entry is to
be added to RECON. Table 19 indicates the keyword combinations that
correspond to the type of secondary system log data set entry.
Table 19. 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.SECLOG
command for open, zero or more ends-of-volume, and close processing.
Required parameter you use to specify the starting time of a secondary SLDS
or TSLDS. The time stamp must be in standard form (see “Standard Time
parameters in the NOTIFY.SECLOG command.
CHKPTCT(0 | value)
on the 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)
PST on an SLDS or TSLDS volume. The checkpoint ID must be in standard
form for a time stamp (see “Standard Time Stamp Format” on page 126).
FILESEQ(1 | value)
secondary SLDS or TSLDS that is identified. You specify this parameter only if
you specify the VOLSER parameter.

FIRSTREC(number)
first log record of the SLDS or TSLDS. For the first SLDS or TSLDS of the
SECSLD or SECTSLDS, FIRSTREC corresponds to the first log record that was
written during initialization of the IMS subsystem.
specified.
v A decimal number
GSG(gsgname)
that produced the SLDS or TSLDS.
INTERIM
be created.
LASTREC(number)
last log record of the SLDS.
(that is, on a close call). LASTREC is invalid if DSN is specified.
v A decimal number
LOCAL | NONLOCAL
Mutually exclusive, optional parameters you use to specify where the SLDS or
TSLDS data was originally created. LOCAL is used if the SLDS or TSLDS was
created by an active IMS subsystem of the local service group. NONLOCAL is
used if the SLDS or TSLDS was originally created by an active IMS subsystem
of the non-local service group and transported to the tracking site.
LOCAL or NONLOCAL need only be specified when creating the SECSLD or
SECTSLDS record. The LOCAL and NONLOCAL keywords are ignored on
subsequent NOTIFY.SECLOG invocations for the SECSLD or SECTSLDS record.
NOTIFY.SECLOG invocation for the SECSLD or SECTSLDS record.

SSID(name)
the secondary SLDSs reside. You only specify the UNIT parameter if you
specify the 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 system
log volume that is being recorded for the identified secondary SLDS. For an
EOV notification, this volume serial number is that of the volume being
started. Table 19 on page 343 identifies when you use the VOLSER parameter.
Example of Adding Secondary SLDS Information to RECON

In this example, information about a secondary SLDS is to be added to RECON.
The STARTIME parameter identifies the secondary SLDS by its opening time
stamp. The VOLSER and DSN parameters indicate that the information to be
added relates to the opening of the secondary SLDS. The first RUNTIME
parameter specifies the time stamp of the EOV of the secondary SLDS or TSLDS.
The second RUNTIME parameter specifies the time stamp of the closing of the
secondary SLDS or TSLDS.
//NFYSECLG JOB
.
.
.
//SYSIN DD *
NOTIFY.SECLOG SLDS STARTIME(820670201010) -
SSID(IMSC) DSN(DSN006) VOLSER(VOL009)
RUNTIME(820680204500) VOLSER(VOL003)
RUNTIME(820682030000)
/*
NOTIFY.SUBSYS
Use a NOTIFY.SUBSYS command to create a subsystem entry in RECON. A check is
made to ensure that a subsystem entry for the specified subsystem does not exist
in RECON. This command is not normally required.
NOTIFY.SUBSYS Syntax
NORMAL ONLINE ENDRECOV
NOTIFY.SUBSYS SSID(name)
IRLMID(name) ABNORMAL BATCH STARTRCV
Parameters for NOTIFY.SUBSYS

SSID(name)
Required parameter you use to specify the name of the subsystem for which

NOTIFY.SUBSYS
information is to be added. The SSID is an eight-character alphanumeric string

that represents a valid z/OS and IMS subsystem identification name.
IRLMID(name)
Optional parameter you use to specify the name of the IRLM with which the
subsystem is communicating. The IRLMID is a five-character alphanumeric
string.
If IRLMID is not specified, the subsystem is not using an IRLM.
NORMAL | ABNORMAL
Mutually exclusive, optional parameters you use to specify the status of the
subsystem.
NORMAL
Specifies that the previous run of the subsystem ended normally and that
the subsystem is to continue normal processing.
ABNORMAL
Specifies that the previous run of the subsystem ended abnormally and
recovery processing is required.
ONLINE | BATCH
Mutually exclusive, optional parameters you use to specify the type of
subsystem from which notification is made.
ONLINE
Specifies that notification is made from an online subsystem.
BATCH
Specifies that notification is made from a batch subsystem.
STARTRCV | ENDRECOV
Mutually exclusive, optional parameters you use to specify the sign-on state of
the subsystem.
STARTRCV
Specifies that the subsystem has signed on for recovery-start processing.
ENDRECOV
Specifies that the subsystem has signed on normally or that a sign-on
recovery-complete call was successful.
Example of Adding a New Subsystem Record to RECON

In this example, a new subsystem record identified by the SSID parameter is added
to RECON. In addition, the subsystem record is marked as online.
//NOTIFYSS JOB
.
.
.
//SYSIN DD *
NOTIFY.SUBSYS SSID(IMS34) ONLINE
/*
NOTIFY.UIC
Use a NOTIFY.UIC command to add information to RECON about a nonstandard
image copy data set related to the DBDS or DEDB area that is identified in the
command. A nonstandard image copy data set is one that was not created by the
supported image copy utility such as, one created via a tape dump of the DASD
volume that contains the identified DBDS or DEDB area. Using the NOTIFY.UIC
command is the only way you can record in RECON the existence of nonstandard
image copy data sets.

NOTIFY.UIC
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 Database
Recovery utility (see Chapter 2, “Database Recovery Control Utility
(DSPURX00),” on page 27 for more information).
v This command is not allowed for ILDS or Index DBDSs of HALDB partitions.
| v The NOTIFY.UIC command will fail if it is attempting to record an image copy of
| a HALDB that has an online reorganization in progress. This is because an
| image copy of a HALDB cannot be taken while the HALDB is being reorganized
| online and the reorganization has not completed (either it is in progress or was
| terminated).
NOTIFY.UIC Syntax
CURRENT
NOTIFY.UIC DBD(name) DDN(name)
AREA(name) RUNTIME(time_stamp) UDATA(‘string‘)

USID(number)
Parameters for NOTIFY.UIC

DBD(name)
DEDB area for which the nonstandard image copy data set was created.
Restriction for HALDBs: When using the NOTIFY.UIC command for HALDBs,
name must specify the name of a HALDB partition.
Mutually exclusive, required parameters you use to identify, by its name, the
DBDS or DEDB area for which the nonstandard image copy data set was
created.
CURRENT | RUNTIME(time_stamp)
Mutually exclusive, optional parameters you use to specify the time stamp of
the creation of the nonstandard image copy data set.
CURRENT
Specifies that the current time stamp is to be used as the time stamp of the
creation of the specified image copy data set. You can create the
nonstandard image copy data set and record its creation in RECON as
separate steps of a single job if you specify CURRENT.
RUNTIME
Specifies the actual time stamp of the creation of the identified
nonstandard image copy data set. The time stamp must be in standard
UDATA(’string’)
Optional parameter you use to specify up to 80 bytes of information about the
identified, nonstandard image copy data set. You can use the variable field of
this parameter to describe how the nonstandard image copy data set was
created.
Restrictions string must:

NOTIFY.UIC
v Be in character format in order to be visible in a listing of the RECON data

set.
v Be enclosed in parentheses.
v Appear in single quotation marks.
USID(number)
Optional parameter you use to specify the value of the update set identifier of
the database or area when the image copy data set was created.
USID is required if the database or area is assigned to a GSG.
Example of Adding Nonstandard ICDSN Information to RECON

In this example, information about a nonstandard image copy data set is to be
added to RECON. The RUNTIME parameter specifies the time stamp of the
creation of the nonstandard image copy data set. The UDATA parameter specifies
the user data to be recorded in the record in RECON that is updated by this
command.
//NFYUIC JOB
.
.
.
//SYSIN DD *
NOTIFY.UIC DBD(DB1) DDN(DD1) -
RUNTIME(820670201010) -
UDATA('DUMP OF VOLUME VOL001 AT 820670201010')
/*

Chapter 15. RESET Command
Use a RESET.GSG command to remove obsolete recovery information from an
original active site RECON.
In This Chapter:
v “RESET.GSG”
RESET.GSG
“RESET.GSG Usage” contains the details for the RESET.GSG command.
RESET.GSG Usage
Use a RESET.GSG command after an unplanned RSR takeover to remove obsolete
recovery information about RSR-covered databases from the original active site
RECON. For each database or area that is assigned to the specified global service
group (GSG), all IC, UIC, ALLOC, RECOV, and REORG records are deleted. In
addition, all subsystem records of the GSG and related database authorization
information along with all OLDS, RLDS, or SLDS records are deleted. Affected CA
records 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 the
z/OS AMS REPRO command, with its normal defaults, in order to create the backup
copy. Any restrictions applicable to the normal use of the REPRO command apply
also to this command.
Attention: Note that if your RECON RECORDSIZE is greater than 32K that
IDCAMS REPRO can handle the RECORDSIZE as long as the output data set is
NOT a sequential file (such as a tape file). Keeping the RECONs on DASD works
well.
If any failure occurs while the RESET.GSG command is processing, but after the
backup 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.
RESET.GSG Syntax
RESET.GSG GSGNAME(gsgname) BOTH
RECON1
RECON2

RESET.GSG
Parameters for RESET.GSG

GSGNAME(gsgname)
Required parameter you use to specify the GSGNAME.
BOTH | RECON1 | RECON2
Mutually exclusive, required parameters you use to specify which copy of the
RECON to use.
BOTH
Indicates that the RECON is to be copied to the data sets specified by the
BACKUP1 and BACKUP2 DD statements.
RECON1
Indicates that the RECON is to be copied to the data set specified by the
BACKUP1 DD statement.
RECON2
Indicates that the RECON is to be copied to the data set specified by the
BACKUP2 DD statement.
Example of the RESET.GSG Command

In the example, the RECON is copied to the BACKUP1 data set, and then the
obsolete information is deleted.
//
. JOB
.
.
//BACKUP1 DD . . .
//SYSIN DD *
RESET.GSG GSGNAME(IMSGSG1) RECON1
/*

Part 3. DBRC Application Programming Interface (API)
Reference
| Chapter 16. Using the DBRC API . . . . . . 353 Output from Query Requests . . . . . . . . 361
| Writing an Application to Access the DBRC API 353 Query Requests Reference . . . . . . . . . 362
| Establishing the DBRC API Environment . . . 354 Backout Query . . . . . . . . . . . . 363
| Ending the DBRC API Environment . . . . . 354 Database Query . . . . . . . . . . . 367
| Addressing and Residency Mode When Using Group Query . . . . . . . . . . . . 390
| the DBRC API . . . . . . . . . . . . 354 Log Query . . . . . . . . . . . . . 399
| Address Space Control (ASC) Mode and State OLDS Query . . . . . . . . . . . . 408
| When Using the DBRC API . . . . . . . 354 RECON Status Query . . . . . . . . . 413
| How the DBRC API Uses Registers . . . . . 354 Subsystem Query . . . . . . . . . . . 417
| Including EQU Statements In Your DBRC API
| Application . . . . . . . . . . . . . 354 | Chapter 18. DBRC Release Buffer Request . . 423
| Coding Parameters In Your DBRC API | RELBUF Request . . . . . . . . . . . . 423
| Application . . . . . . . . . . . . . 355 | RELBUF Usage . . . . . . . . . . . . 423
| Macro Versions of the DBRC API Macro . . . 356
| The DBRC API Token . . . . . . . . . 356 | Chapter 19. DBRC Start Request . . . . . . 427
| Macro Forms of the DSPAPI Macro . . . . . 356 | STARTDBRC Request. . . . . . . . . . . 427
| Runtime Considerations of the DBRC API . . . . 357 | STARTDBRC Usage . . . . . . . . . . 427
| Accessing the DSPAPI Macro . . . . . . . 357
| Accessing the RECON Data Sets . . . . . . 358 Chapter 20. DBRC Stop Request . . . . . . 431
| Time-Stamp Format for DBRC Requests . . . 358 STOPDBRC Request . . . . . . . . . . . 431
| How DBRC Uses the Output Data Set . . . . 359 STOPDBRC Usage. . . . . . . . . . . 431
| Using the API In an IMSplex . . . . . . . 359
Chapter 17. DBRC Query Request. . . . . . 361

|
| Chapter 16. Using the DBRC API

| The DBRC application programming interface (API) is a release-independent,
| assembler macro interface to DBRC that customer-written application programs use
| to obtain services from DBRC. The application obtains these services by issuing
| DBRC API requests to DBRC, and DBRC returns the results to an area in storage
| where the application can retrieve them. The services available through the DBRC
| API are to:
| v Initialize the API and start DBRC (see Chapter 19, “DBRC Start Request,” on
| page 427)
| v Obtain information that DBRC maintains in the RECON data sets (see
| Chapter 17, “DBRC Query Request,” on page 361)
| v Return buffer storage (see Chapter 18, “DBRC Release Buffer Request,” on page
| 423)
| v Shutdown DBRC and the API (see Chapter 20, “DBRC Stop Request,” on page
| 431)
| The API is provided with IMS in the DSPAPI macro. A sample application program
| (DSPAPSMP) that uses the DBRC API is included in the IMS.ADFSSMPL (also
| known as IMS.SDFSSMPL) library.
| Note: All DBRC API requests must be issued under the same TCB where the
| DBRC start request (STARTDBRC) was issued. Any request that is issued
| under a different TCB fails with reason code X’C900000A’.
| Prerequisite Knowledge: To write a program that uses the DBRC API, you must
| have a working knowledge of:
| v Assembler language programming
| v z/OS and the services it supplies
| v IMS
| v DBRC
| Related Reading: For information about assembler language programming, see

| High Level Assembler for MVS & VM & VSE Programmer’s Guide and High Level
| Assembler for MVS & VM & VSE Language Reference.
| In This Chapter:
| v “Writing an Application to Access the DBRC API”
| v “Runtime Considerations of the DBRC API” on page 357
|
| Writing an Application to Access the DBRC API
| The general structure of an application that uses the DBRC API is as follows:
| 1. Include the API DSECTS (DSPAPI FUNC=DSECT)
| 2. Initialize the API, start DBRC, establish a connection to the RECON data sets,
| and receive the API token (DSPAPI FUNC=STARTDBRC)
| 3. Issue one or more Query requests (DSPAPI FUNC=QUERY)
| 4. Process the information returned from the Query requests
| 5. Return buffer storage (DSPAPI FUNC=RELBUF)

| 6. Terminate DBRC and the DBRC API (DSPAPI FUNC=STOPDBRC)
| The following sections discuss some of the programming considerations for

| applications that access the DBRC API.
| v “Establishing the DBRC API Environment”
| v “Ending the DBRC API Environment”
| v “Addressing and Residency Mode When Using the DBRC API”
| v “Address Space Control (ASC) Mode and State When Using the DBRC API”
| v “How the DBRC API Uses Registers”
| v “Including EQU Statements In Your DBRC API Application”
| v “Coding Parameters In Your DBRC API Application” on page 355
| v “Macro Versions of the DBRC API Macro” on page 356
| v “The DBRC API Token” on page 356
| v “Macro Forms of the DSPAPI Macro” on page 356
| Establishing the DBRC API Environment

| Your application program establishes the API environment using the DSPAPI
| FUNC=STARTDBRC macro. This macro function initializes the API, creates a
| connection to the DBRC RECON data sets, and returns the API token. This token
| must be specified for all subsequent API calls. See “The DBRC API Token” on page
| 356 for information about the API token.
| Ending the DBRC API Environment

| After it has completed its work with DBRC, your application program must end
| the API environment using the DSPAPI FUNC=STOPDBRC macro. This macro
| function allows DBRC to terminate, deallocates any data sets that DBRC had
| allocated, and frees storage allocated to the API environment.
| Addressing and Residency Mode When Using the DBRC API

| Your application must invoke the DBRC API in 31-bit addressing mode and can
| reside either above or below the 16 MB line. Parameter addresses passed to the
| API can be above or below the 16 MB line unless otherwise stated in a macro
| description. Parameter addresses returned to the user by the API likewise can be
| above or below the 16 MB line.
| Address Space Control (ASC) Mode and State When Using the
| DBRC API
| Your application must be in primary ASC mode to invoke the API services. Cross
| memory mode is not supported. The application can run in either problem
| program state or supervisor state, and can also run as an APF authorized program.
| How the DBRC API Uses Registers

| General purpose registers 0, 1, 14, and 15 can be changed by the API. Register 13
| must contain the address of a standard (18 word) save area. The contents of
| registers 2-13 are unchanged by the API.
| Including EQU Statements In Your DBRC API Application

| Use the DSECT function of a DSPAPI request to include equate (EQU) statements
| and constants used by the DSPAPI macro in your program. The syntax for the
| DSECT function of a DSPAPI request is:

| DSPAPI FUNC=DSECT
|
| Coding Parameters In Your DBRC API Application

| Parameters specified on the DSPAPI macro are either literals, addresses, or values.
| You can pass an address or a parameter value by using a register, a symbol, or a
| literal.
| Use a register
| To use a register, you must load the address of a symbol or value into one
| of the general purpose registers, then use that register (enclosed in
| parentheses) for the parameter in the DSPAPI request. Use only registers in
| the range 2-12. Register notation does not work with MF=L because this
| form does not produce executable code.
| Here is an example of passing an address using a register:
| LA 5,OUTPUTAD
| DSPAPI FUNC=QUERY,OUTPUT=(5),...
| .
| .
| .
| OUTPUTAD DS A
| This example generates the following instruction:

| ST 5,DSPAPI_Plist_Output
| Use a symbol
| To use a symbol name, you must define a named area of storage that either
| contains the desired value, or will receive a returned address or value, then
| use that symbol name for the parameter in the DSPAPI request.
| Here is an example of using a symbol name:
| DSPAPI FUNC=QUERY,OUTPUT=OUTPUTAD,..
| .
| .
| .
| OUTPUTAD DS A
| This example generates the following instructions:

| LA 0,OUTPUTAD
| Use a literal
| You can use literals for certain parameter values, for example time stamps.
| To use a literal, pass the literal as a hex string for the parameter in the
| DSPAPI request.
| Here is an example of using a literal:
| DSPAPI FUNC=QUERY,TYPE=LOG, C
| STARTIME==XL12'1980030F191212009999028D'
| This example generates the following instructions:

| LA 0,=XL12'198030F191212009999028D'
| Name Fields
| Unless specifically noted, name fields are 8-character fields, left justified and
| padded with blanks.
Chapter 16. Using the DBRC API 355

| Macro Versions of the DBRC API Macro
| The functions provided by the DSPAPI macro have a version associated with them
| because parameter lists can change from one release to the next (parameter lists are
| discussed in “Macro Forms of the DSPAPI Macro”). To use the parameters
| associated with a version, you must specify that version number or a later version.
| If you specify an earlier version level, the parameter is not accepted by the macro
| and an MNOTE error message is issued at assembly time. If parameters have a
| version dependency, the parameter descriptions with each request type identify the
| version number required.
| The DBRC API Token

| The API token is a four-byte field used to relate a series of API requests. It is
| returned to your program when a DSPAPI FUNC=STARTDBRC macro is issued.
| This token must be supplied on all other macro calls associated with this instance
| of STARTDBRC. The token is no longer valid after a DSPAPI FUNC=STOPDBRC
| macro call.
| Macro Forms of the DSPAPI Macro

| There are four different macro forms for the DSPAPI macro: Standard (S), List (L),
| Modify (M), and Execute (E), with two variations, COMPLETE and NOCHECK.
| The List, Modify, and Execute forms are usually used in combinations when
| writing reentrant programs or when the application issues multiple requests. The
| following are explanations about when and why to use each form.
| Standard Form
| Use the standard form of the macro (MF=S or MF=S,list) to generate and
| modify an inline parameter list. If your program is reentrant, do not use
| the standard form of the macro because reentrant code cannot be modified.
| With few exceptions, if you use the standard form of the macro in writing
| reentrant code, the execution of the code results in an abend. The standard
| form of the macro does three things. It:
| v Creates an inline parameter list
| v Modifies the parameter list with the parameters specified on the request
| v Sends the request to the API
| Using the standard form, you can optionally assign a label to the generated
| parameter list by specifying MF=(S,list) where list specifies the name of the
| label assigned to the parameter list created by this form of the macro. The
| standard MF=S form of the macro is the default.
| List Form
| Use the list form of the macro (MF=L,list) to generate a labeled, inline
| parameter list. This list is populated with the parameter values specified
| on the macro. The list form does not modify an existing list and does not
| send a request to the API. In effect, the list form creates a template that can
| be used as the target of a modify form or an execute form (the real list you
| plan to use). If the parameter list is generated in reentrant code, it cannot
| be modified. Therefore, you must obtain enough storage to hold the
| parameter list and use this storage as the target of the modify or list form.
| list specifies the name of the label assigned to the parameter list created by
| this form of the macro.
| Note: The expansion of the list form does not contain any executable
| instructions. Therefore, you cannot use register notation in the list
| form.

| Modify Form
| Use the modify form of the macro (MF=M,list,COMPLETE | NOCHECK)
| to change the values specified on the macro in the parameter list specified
| by the list parameter. The modify form does not generate a parameter list
| and does not issue requests to DBRC.
| list Can be a symbol or a general purpose register in the range 2 to 12
| and specifies the address of the parameter list to be modified.
| COMPLETE
| Specifies that DBRC will use defaults (for the parameters that have
| defaults) for all parameters that are not in the list and will perform
| validity checking for the parameters that are specified in the list.
| COMPLETE is the default.
| NOCHECK
| Specifies that the parameter list has been checked and that DBRC
| should use the list as is. No validity checking is performed.
| Execute Form
| Use the Execute form of the macro (MF=E,list,COMPLETE | NOCHECK)
| to:
| v Modify a parameter list (generated by the List form) with new and
| additional allowable parameters you might not have specified on the
| List form
| v Issue a request to the API
| You can change the parameters on the macro with each subsequent
| invocation of the Execute form of the macro.
| list Can be a symbol or a general purpose register in the range 2 to12
| and specifies the address of the parameter list to be used.
| COMPLETE
| Specifies that DBRC will use defaults (for the parameters that have
| defaults) for all parameters that are not in the list and will perform
| validity checking for the parameters that are specified in the list.
| COMPLETE is the default.
| NOCHECK
| Specifies that the parameter list has been checked and that DBRC
| should use the list as is. No validity checking is performed.
|
| Runtime Considerations of the DBRC API
| The following sections discuss the runtime considerations for the DBRC API.
| v “Accessing the DSPAPI Macro”
| v “Accessing the RECON Data Sets” on page 358
| v “Time-Stamp Format for DBRC Requests” on page 358
| v “How DBRC Uses the Output Data Set” on page 359
| v “Using the API In an IMSplex” on page 359
| Accessing the DSPAPI Macro

| Allocate IMS.SDFSRESL as either a JOBLIB or STEPLIB in your program’s JCL
| because the API (DSPAPI) is distributed with IMS.

| Accessing the RECON Data Sets
| While the API is running, it uses up to 3 RECON data sets allocated by the DD
| names RECON1, RECON2, and RECON3. See Chapter 4, “Initializing and
| Maintaining the RECON Data Set,” on page 55 for a complete understanding of
| the RECONs. The RECONs can be allocated:
| v Dynamically by the API when the DSPAPI FUNC=STARTDBRC request is issued
| (recommended)
| v Dynamically by your application program
| v Through your JCL
| If the API allocates the RECONs, they are deallocated when the DSPAPI
| FUNC=STOPDBRC request is issued. Before the API can allocate the RECONs,
| MDA members must have been created for RECON1, RECON2, and RECON3. See
| “Dynamic Allocation Macro (DFSMDA)” in the IMS Version 9: Utilities Reference:
| System for more information about creating MDA members. These members must
| exist in either a library allocated as //IMSDALIB or in the //JOBLIB or
| //STEPLIB libraries. The API searches in //IMSDALIB (if it exists) first for the
| MDA members.
| The IMS libraries concatenated to JOBLIB or STEPLIB are usually APF Authorized.
| If your program runs APF Authorized and the library containing the MDA
| members is not APF Authorized, allocate it using IMSDALIB as the DD name.
| Requirement: All jobs accessing a set of RECON data sets must allocate the same
| data set by the same DD name. For example, RECON1=dsn1, RECON2=dsn2, and
| RECON3=dsn3. Failure to follow this convention causes serious damage to the
| RECONs.
| The API uses only one set of RECONs between a FUNC=STARTDBRC request and
| its associated FUNC=STOPDBRC request. Your program, however, can use
| multiple sets of RECONs by deallocating the RECONs after the FUNC=STOPDBRC
| request and then allocating a new set of RECONs before issuing the next
| FUNC=STARTDBRC request. In order for this to work, your program must
| dynamically allocate the RECONs.
| Time-Stamp Format for DBRC Requests

| The format for time stamps associated with DBRC requests (either input or output)
| are in the following packed decimal UTC time format:
| yyyydddFhhmmsstxxxxxfqqs
| Where:
| yyyy Is the year (0000 to 9999)
| ddd Is the day (000 to 366)
| F Is a hexadecimal character for padding purposes (X'F')
| hh Is the hour (0 to 23)
| mm Is the minute (0 to 59)
| ss Is the second (0 to 59)
| t Is the tenth of a second (0 to 9)
| xxxxx Low-order digits ignored by DBRC
| fqqs Time zone offset where:
| f Flag bits, normally zero for UTC representation
| qq Quarter hours (32/4=8)
| s Sign (D is negative, C is positive)

| DBRC ignores the value of the offset field in time stamps provided on Query
| requests.
| How DBRC Uses the Output Data Set

| While running under the API, DBRC might put out messages and other
| information to a data set defined by the DD name SYSPRINT, or by a DD name
| you specify. This output data set might be on tape, DASD, a printer, or routed
| through the output stream (SYSOUT). The data set might be allocated by your
| program through JCL or dynamically allocated prior to invoking the API. If your
| program already uses the DD name SYSPRINT, you can specify an alternate DD
| name for the API to use (see Chapter 19, “DBRC Start Request,” on page 427). The
| attributes for this data set are RECFM=FBA, LRECL=121. Do not specify the
| blocksize because DBRC will use a system determined blocksize (the system
| determines an optimal blocksize for the device).
| Using the API In an IMSplex

| If the set of RECONs used by your job belong to an IMSplex, you must either pass
| the PLEX name as a parameter on your EXEC JCL statement or use the SCI
| Registration Exit (DSPSCIX0). To specify the parameter on your EXEC statement,
| code IMSPLEX=imsplex_name. For example:
| //STEP1 EXEC PGM=MYPROG,PARM='MYPARM1=EXAMPLE,IMSPLEX=PLEX1'
| You do not need to specify PARM if your installation uses the SCI Registration Exit
| (DSPSCIX0). See IMS Version 9: Customization Guide for more information about this
| exit.

Chapter 17. DBRC Query Request
Use the DBRC Query request (DSPAPI FUNC=QUERY) along with the TYPE
parameter to retrieve the following types of information from the RECON:
v Backout (TYPE=BACKOUT) - See “Backout Query” on page 363.
v Database (TYPE=DB) - See “Database Query” on page 367. This variation of
QUERY returns database registration and status information for:
– Full Function databases
– Fast Path databases
– HALDB databases
– DBDS or area information and supporting recovery-related information for
each DBDS or area (allocation, image copy, recovery, and reorganization)
v Group and member information - See “Group Query” on page 390 for the
following group types:
– Change Accumulation (TYPE=CAGROUP). CA execution information can also
be returned.
– DBDS (TYPE=DBDSGROUP).
– Database (TYPE=DBGROUP).
– Recovery (TYPE=RECOVGROUP).
– Global Service Group (TYPE=GSGROUP).
v Log, Recovery and System Log Data Set (TYPE=LOG) - See “Log Query” on
page 399.
v Online Log Data Set (TYPE=OLDS) - See “OLDS Query” on page 408.
v RECON status (TYPE=RECON) - See “RECON Status Query” on page 413. This
variation of QUERY returns RECON header information, as well as the status of
the RECON configuration.
v Subsystem (TYPE=SUBSYS) - See “Subsystem Query” on page 417.
Related Reading: See “Records in the RECON Data Set” on page 63 for a
description of the information available in the RECON data set, and “Fields
Present in a Listing of a RECON by Record Type” on page 532 for a description of
the individual fields present in each RECON record type.
In This Chapter:
v “Output from Query Requests”
v “Query Requests Reference” on page 362
Output from Query Requests

The requested information is returned to the calling application in a chain of one
or more blocks in storage. The pointer to the beginning of this chain is returned in
the area specified by the OUTPUT parameter of the Query request.
The storage for these blocks is not preallocated by the calling application. DBRC
will acquire private storage for these blocks. It is the responsibility of the calling
application to free this storage using the Buffer Release request (DSPAPI
FUNC=RELBUF). For more information about freeing this storage, see Chapter 18,
“DBRC Release Buffer Request,” on page 423.

QUERY
Figure 15 illustrates the general format of the output from a Query request. The
sample DSECT that follows Figure 15 describes in detail the fields of the storage
blocks and their relationship to each other.
|
| Figure 15. General Format of Query Output
|
Each storage block begins with a standard header mapped by DSPAPQHD, as
illustrated in Figure 16.
OFFSET OFFSET
DECIMAL HEX TYPE LENGTH NAME (DIM) DESCRIPTION
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 32 APQHD
0 (0) CHARACTER 8 APQHD_EYECATCHER Output area eyecatcher
8 (8) SIGNED 4 APQHD_LENGTH Block length, hdr + data
12 (C) SIGNED 2 APQHD_BLKTYPE Block type
14 (E) SIGNED 2 * Reserved
16 (10) ADDRESS 4 APQHD_DEPPTR Ptr to block dependent
20 (14) ADDRESS 4 APQHD_NEXTPTR Ptr to next block of the same type
24 (18) UNSIGNED 4 APQHD_BLKOFFSET Offset to block data
28 (1C) SIGNED 4 APQHD_VERSION Version of output block
Figure 16. DSECT of DSPAPQHD - QUERY Output Block Header
Query Requests Reference

The following sections contain an overview of, the syntax for, and parameter
descriptions for each query request.
In this section :
v “Backout Query” on page 363
v “Database Query” on page 367
v “Group Query” on page 390
v “Log Query” on page 399
v “OLDS Query” on page 408
v “RECON Status Query” on page 413
v “Subsystem Query” on page 417

QUERY TYPE=BACKOUT
Backout Query
The Backout query (DSPAPI FUNC=QUERY TYPE=BACKOUT) request is used to
retrieve backout information from RECON for a specific subsystem or all
subsystems.
Syntax for the TYPE=BACKOUT Query Request

| DSPAPI FUNC=QUERY TYPE=BACKOUT TOKEN=address
| name
| SSID=* MF=S
| OUTPUT=output
SSID=subsystem_ID MF=(S,list)
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

RETCODE=returncode RSNCODE=reasoncode VERSION=number
|
Parameters for the TYPE=BACKOUT Query Request

The following are the possible parameters for QUERY TYPE=BACKOUT.
name Optional symbol you can specify. If used, begins in column 1.
TYPE=BACKOUT
Specifies that backout information is requested.
TOKEN=symbol | (2 - 12)
Required parameter that specifies the address of a 4-byte field that was
returned on the FUNC=STARTDBRC request.
SSID=* | symbol | (2 - 12)
Specifies the subsystem name for the backout being queried. The default
value (SSID=*) requests all of the backout information.
MF=S | L | M | E
Optional parameter that specifies the macro form of the request. See
“Macro Forms of the DSPAPI Macro” on page 356 for the details of the
parameter values.
OUTPUT=symbol | (2 - 12)
Required parameter that specifies a field to receive a pointer to the first
block of backout information blocks. See “Output for TYPE=BACKOUT
QUERY Request” on page 365 for a detailed description of the information
blocks returned.
The output address is zero if no output was built. This can occur if nothing
in the RECON satisfies the request or if an error occurs before any output
could be built.
The storage for the output blocks is not preallocated. DBRC acquires
private storage for these blocks. The requesting application is responsible
Chapter 17. DBRC Query Request 363

QUERY TYPE=BACKOUT
for freeing this storage by using the Buffer Release request (DSPAPI
FUNC=RELBUF), specifying the returned output address.
RETCODE=symbol | (2 - 12)
Optional parameter that specifies a place in storage to receive the return
code. If specified as a symbol, the symbol must be the label of a word of
storage. If specified as a register, the register must contain the address of a
word of storage. If not specified, the return code is placed in register 15.
RSNCODE=symbol | (2 - 12)
Optional parameter that specifies a place in storage to receive the reason
word of storage. If not specified, the reason code is placed in register 0.
VERSION=1.0 | number
Optional parameter that specifies the version number of the parameter list
to be generated by this request.
To use the parameters associated with a version, you must specify the
number of that version or a later version. If you specify an earlier version
level, the parameter is not accepted for processing and an error message is
issued at assembly time. If parameters have a version dependency, the
parameter descriptions with each request type identify the version number
required.
The default version is 1.0.
| Return and Reason Codes for the TYPE=BACKOUT Query

| Request
| Table 20 contains most of the return and reason codes for TYPE=BACKOUT query
| requests. The other possible return and reason codes relate to DBRC, not the query
| request. For a list of these return and reason codes, see “DBRC Service Aids” in the
| IMS Version 9: Diagnosis Guide and Reference.
| Table 20. Return and Reason Codes for TYPE=BACKOUT Query Requests
| Return Codes Reason Codes Meaning
| X'00000000' X'00000000' Request completed successfully.
| Warning
| X'00000008' X'D87000001' No backout records exist.
| Severe Error
| X'0000000C' X'C9000001' Invalid TOKEN. The TOKEN block passed to the
| API is not recognized as a TOKEN created by a
| FUNC=STARTDBRC call.
| Storage Error
| X'00000028' X'D87000001' Error obtaining storage for BACKOUT block.
| X'00000028' X'D91000001' An error occurred processing the request. DBRC
| will release storage that was obtained up to this
| point. However, another error was encountered
| during the attempt to release storage.
| Internal Error
| X'0000002C' all DBRC internal error. Refer to “Database Recovery
| Control Service Aids” in the IMS Version 9:
| Diagnosis Guide and Reference for further
| information.

QUERY TYPE=BACKOUT
| Table 20. Return and Reason Codes for TYPE=BACKOUT Query Requests (continued)
| Parameter Error
| X'00000030' X'C9000001' Parameter error. The function (FUNC) specified in
| the parameter list passed to the API is invalid.
| X'00000030' X'C9000002' Invalid TOKEN field address. The address of the
| field containing the API TOKEN failed validity
| checking. The address specifies storage not owned
| by the calling program.
| X'00000030' X'C9000003' Invalid RETCODE field address. The address of
| the field to contain the API RETCODE failed
| validity checking. The address specifies storage
| not owned by the calling program.
| X'00000030' X'C9000004' Invalid RSNCODE field address. The address of
| the field to contain the API RSNCODE failed
| X'00000030' X'C9000005' Invalid OUTPUT field address. The address of the
| field to contain the OUTPUT address failed
| X'00000030' X'C9000010' Invalid SSID field address. The address of the
| field containing the SSID failed validity checking.
| The address specifies storage not owned by the
| calling program.
| X'00000030' X'D80000001' Parameter error. Missing or invalid OUTPUT
| parameter.
|
| Output for TYPE=BACKOUT QUERY Request

Figure 17 illustrates the format of the output from a QUERY TYPE=BACKOUT
request. Figure 18 on page 366 is a sample DSECT describes in detail the fields of
the storage blocks and their relationship to each other.
|
| Figure 17. Format for QUERY TYPE=BACKOUT Output
|

QUERY TYPE=BACKOUT
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 48 DSPAPQBO
0 (0) CHARACTER 8 APQBO_SSID Subsystem identifier
8 (8) UNSIGNED 4 APQBO_FIRSTUOR Offset of first UOR entry
12 (C) UNSIGNED 4 APQBO_LASTUOR Offset of last UOR entry
16 (10) CHARACTER 12 APQBO_TIMEFIRST Earliest UOR time
28 (1C) CHARACTER 12 APQBO_TIMELAST Latest UOR time
40 (28) BIT(8) 1 APQBO_FLAGS Backout flags
1... .... APQBO_SAVER SAVUOR call during restart
41 (29) CHARACTER 3 * Reserved
44 (2C) SIGNED 4 APQBO_UORCOUNT Number of UORs
==============================================================================
The following structure maps the unit of recovery entries.
There is one such entry for each unit of recovery (i.e. there
are apqbo_UORcount entries). Each unit of recovery entry
contains the offset within the backout block to the previous
and following entries. Field apqbo_PrevUOR is the offset of
the previous entry and apqbo_NextUOR is the offset of the
following entry. For the first unit of recovery (UOR) entry,
apqbo_PrevUOR will be zero. Similarly, apqbo_NextUOR will be
zero for the last entry. Addressability to the first UOR entry
is given by:
rfy apqbo_UORentry based(addr(DSPAPQBO) + apqbo_FirstUOR)
Addressability to the last UOR entry is given by:
rfy apqbo_UORentry based(addr(DSPAPQBO) + apqbo_LastUOR)
Addressability to the next UOR entry, if one exists (that is:
apqbo_NextUOR not equal to 0), is given by:
rfy apqbo_UORentry based(addr(DSPAPQBO) + apqbo_NextUOR)
Similarly, to address the previous entry (when apqbo_PrevUOR
not equal to 0):
rfy apqbo_UORentry based(addr(DSPAPQBO) + apqbo_PrevUOR)
Once addressability has been established to a UOR entry,
addressability to the ith database for this UOR is given by:
rfy apqbo_DBent
based(addr(apqbo_UORentry) + apqbo_DBoffset
+ (i-1) apqbo_DBLength)
==============================================================================
Figure 18. DSECT of DSPAPQBO (Part 1 of 2)

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 64 APQBO_UORENTRY Unit of Recovery entry
0 (0) CHARACTER 64 APQBO_PREFIX Prefix section
0 (0) UNSIGNED 4 APQBO_NEXTUOR Offset of next UOR entry
4 (4) UNSIGNED 4 APQBO_PREVUOR Offset of previous UOR entry
8 (8) UNSIGNED 4 APQBO_DBOFFSET Offset to DB entries
12 (C) CHARACTER 12 APQBO_UORTIME Time stamp for this UOR
24 (18) CHARACTER 8 APQBO_UORPSB PSB name
32 (20) BIT(16) 2 APQBO_UORFLAGS
1... .... APQBO_DEFBO Deferred backout - dynamic backout failure
.1.. .... APQBO_INFLT Inflight UOR
..1. .... APQBO_INDOU Indoubt UOR
...1 .... APQBO_BMP BMP UOR
.... 1... APQBO_BOCAN BBO identified candidate
.... .1.. APQBO_COLDN Cold start ended for UOR
.... ..1. APQBO_BBOK Backed out OK by BBO
.... ...1 APQBO_CMD UOR modified by command
33 (21) 1... .... APQBO_BATCH Batch IMS UOR
40 (28) CHARACTER 16 APQBO_RTOKN Recovery token
40 (28) CHARACTER 8 APQBO_RTSSID SSID for this token
48 (30) CHARACTER 8 APQBO_UORID Unique UOR ID
56 (38) SIGNED 4 APQBO_DBCOUNT Number of DBs for this UOR
60 (3C) UNSIGNED 2 APQBO_DBLENGTH Length of each DB entry
62 (3E) CHARACTER 2 * Reserved
OFFSET OFFSET
======== ================= ======== ============== ===============================
0 (0)STRUCTURE 16 APQBO_DBENT Database entry
0 (0)CHARACTER 8 APQBO_DBNAME Database name
8 (8)BIT(8) 1 APQBO_DBFLAGS Flags
1... .... APQBO_DBOUT UOR backed out for this DB
.1.. .... APQBO_DBDEF Dyn backout failure this DB
CONSTANTS
LEN TYPE VALUE NAME DESCRIPTION

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQBO APQBO_EYECATCHER
Figure 18. DSECT of DSPAPQBO (Part 2 of 2)
Database Query
The Database Query request (DSPAPI FUNC=QUERY TYPE=DB) is used to
retrieve information from the RECON concerning one or more registered
databases. This information includes the following database types:
v Full Function
v Fast Path DEDB
v HALDB (returns information about the HALDB master and all of its partitions)
Optionally, you can request data set and area information. If you do, you have the
option of requesting recovery-related information for the data set or area. This
includes allocation, image copy, recovery, and reorganization information.
Syntax for the TYPE=DB Query Request

DDN=NULL
DSPAPI FUNC=QUERY TYPE=DB TOKEN=address
name DDN=ddname
DDN=*
QUERY TYPE=DB
LIST=NONE LOC=SPEC
DBNAME=dbname
, DBLIST=namelist LOC=FIRST
LOC=NEXT
LIST=( ALLOC )
IC
RECOV
REORG
LIST=ALL
MF=S
OUTPUT=output
MF=(S,list) RETCODE=returncode
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

RSNCODE=reasoncode VERSION=number
Parameters for the TYPE=DB Query Request

The following are the possible parameters for QUERY TYPE=DB.
TYPE=DB
Specifies that RECON information for one or more databases is requested.
| DBNAME=symbol | (2 - 12)
| Specifies the name of the database whose information is being queried.
| This can be the name of a Full Function database, a Fast Path DEDB, or a
| HALDB.
| You must specify a DBNAME or DBLIST if you do not specify LOC=FIRST.
| DBLIST=symbol | (2 - 12)
Specifies the list of database names whose information is being queried.
Each name in the list can be the name of a Full Function database, a Fast
Path DEDB, or a HALDB.
The list consists of a header and one or more eight-character list entries.
The header consists of a fullword containing the number of entries in the
list. The name entries are left justified and are padded with blanks.
| You must specify a DBNAME or DBLIST if you do not specify LOC=FIRST.
| DDN=symbol | (2 - 12) | * | NULL
Optional parameter that specifies the DD name of the data set or area. An
asterisk (* without quotes) can be specified to request information about all
DBDSs or areas. If DBLIST contains more than one database, specifying a
specific DD name is ignored and treated as if DDN=* was specified.

QUERY TYPE=DB
Information is returned for all DBDSs or areas. The same is true if a

specific ddname is requested with a HALDB master specified in the
DBNAME parameter.
| If you specify DDN=NULL, no DBDS or area information is returned.
| DDN=NULL is the default.
| LIST=(ALLOC | IC | RECOV | REORG) | ALL | LIST=NONE
| Optional parameter that specifies the type (or types) of supporting
| information to be included in the query output for the specified DBDS or
| area. If DDN is not specified, this information is returned for all DBDSs or
| areas in the database. One or more of the specific values, separated by
| commas, can be included in the list: ALLOC (allocation records), IC (image
| copy records), RECOV (recovery records), or REORG (reorganization
| records). LIST=ALL specifies that all supporting information is requested.
| If you specify LIST=NONE, no supporting information is returned.
| LIST=NONE is the default.
| LOC=FIRST | NEXT | SPEC
Optional parameter that specifies that the request is for the specified, the
first, or the next database defined in the RECON.
DBNAME=dbname is required when you specify LOC=NEXT, but it is not
allowed for LOC=FIRST.
| Databases are in alphanumeric order. The next database might not
| necessarily be of the same type as the database name specified in the
| DBNAME parameter. The value in the DBNAME parameter is used as the
| base of the search and does not need to be a name of a database registered
| in the RECON.
| LOC=SPEC is the default.
MF=S | L | M | E
parameter values.
block of a possible chain of database information blocks. See “Output for
TYPE=DB Query Request” on page 372 for a detailed description of the
information blocks returned.
could be built.

QUERY TYPE=DB

required.
| Return and Reason Codes for the TYPE=DB Query Request

| Table 21 contains most of the return and reason codes for TYPE=DB query
| Table 21. Return and Reason Codes for TYPE=DB Queries
| Partial Success
| X'00000004' X'D8200001' One or more databases in DBLIST is not
| registered in the RECON. A “DB not found” data
| block with an eyecatcher of DSPAPQNF is built
| for each database that was not found. The block
| is in the chain of blocks returned.
| Warning
| X'00000008' X'D8200001' None of the databases in the DBLIST are
| registered in the RECON. No information blocks
| are returned.
| X'00000008' X'D8200002' The specified database is not registered in the
| RECON. No information blocks are returned.
| X'00000008' X'D8210002' The specified DBDS or Area is not registered in
| the RECON. No information blocks are returned.
| Severe Error
| Storage Error
| X'00000028' X'D8200001' Error obtaining storage for IMSDB block.
| X'00000028' X'D8200002' Error obtaining storage for HALDB block.
| X'00000028' X'D8200003' Error obtaining storage for FPDEDB block.
| X'00000028' X'D8200004' Error obtaining storage for DB not found block
| (DBNOTFND).
| X'00000028' X'D8210001' Error obtaining storage for DBDS block.
| X'00000028' X'D8210002' Error obtaining storage for AREA block.

QUERY TYPE=DB
| Table 21. Return and Reason Codes for TYPE=DB Queries (continued)
| X'00000028' X'D8210003' Error obtaining storage for RCVINFO block.
| X'00000028' X'D8210004' Error obtaining storage for ALLOC block.
| X'00000028' X'D8210005' Error obtaining storage for IC block.
| X'00000028' X'D8210006' Error obtaining storage for REORG block.
| X'00000028' X'D8210007' Error obtaining storage for RECOV block.
| X'00000028' X'D8220001' Error obtaining storage for PART block.
| point. Another error was encountered, however,
| Internal Error
| information.
| Parameter Error
| X'00000030' X'C9000008' Invalid DBNAME or DBLIST address. The
| address of the field containing the DBNAME or
| DBLIST failed validity checking. The address
| specifies storage not owned by the calling
| program.
| X'00000030' X'C9000009' Invalid DDN address. The address of the field
| containing the DDN failed validity checking. The
| address specifies storage not owned by the calling
| program.
| parameter.
| X'00000030' X'D8200001' Parameter error. LOC parameter is not allowed
| with DBLIST.
| X'00000030' X'D8200002' Parameter error. DBNAME parameter is not
| allowed with LOC=FIRST.

QUERY TYPE=DB
| Table 21. Return and Reason Codes for TYPE=DB Queries (continued)
| X'00000030' X'D8200003' Parameter error. DBNAME parameter is required
| with LOC=NEXT.
| X'00000030' X'D8200004' Parameter error. DBNAME or DBLIST is required.
| X'00000030' X'D8200005' Parameter error. Count of databases in DBLIST is
| zero.
| X'00000030' X'D8200006' Parameter error. Database information is being
| requested for a HALDB partition. DBNAME or
| DBLIST contains a partition name.
|
| Output for TYPE=DB Query Request

The following sections have figures that illustrate the format of output from a
QUERY TYPE=DB requests. The sample DSECTs that follow the figures describe in
detail the fields of the storage blocks and their relationship to each other.
Full Function Output: Figure 19 shows the fields of the DSPAPQDB block.
|
| Figure 19. Format of QUERY TYPE=DB (Full Function) Output
|
| The DBDS information is returned only if DDN is specified.
| Figure 20 on page 373 describes the fields contained in the DSPAPQDB block
| shown in Figure 19. Figure 21 on page 374 describes the fields contained in the SS
| data (DSPAPQSL). Refer to Figure 29 on page 383 for an illustration of the fields of
| the DBDS output.
|

QUERY TYPE=DB
| OFFSET OFFSET
| DECIMAL HEX TYPE LENGTH NAME (DIM) DESCRIPTION
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE 96 DSPAPQDB
| 0 (0) CHARACTER 8 APQDB_DBNAME Database name
| 8 (8) UNSIGNED 4 APQDB_SSLIST Offset to SS list (DSPAPQSL), zero is no SS auth'd
| 12 (C) SIGNED 4 *(3) Reserved
| 24 (18) UNSIGNED 2 APQDB_IRCNT IC receive needed counter
| 26 (1A) BIT(8) 1 APQDB_AUFLAG Authorization flags
| 1... .... APQDB_BKFLG Backout needed flag
| .1.. .... APQDB_PAFLG Prohibit authorization
| ..1. .... APQDB_RDFLG Read only SS auth
| ...1 .... APQDB_NONRV Non-recoverable
| 27 (1B) CHARACTER 5 APQDB_IRLMAU IRLMID of auth SS
| 32 (20) SIGNED 2 APQDB_RCVCTR Recovery needed count
| 34 (22) SIGNED 2 APQDB_ICCTR IC needed count
| 36 (24) SIGNED 2 APQDB_ICRECCTR IC recommended counter
| 38 (26) UNSIGNED 1 APQDB_SHRLVL Share level of DB
| 39 (27) UNSIGNED 1 APQDB_HELDAU Held auth state
| 1... .... APQDB_HAUBIT High order bit flag
| 40 (28) UNSIGNED 2 APQDB_DMBNUM Global DMB number
| 42 (2A) SIGNED 2 APQDB_SSNUM # of SS auth DB
| 44 (2C) UNSIGNED 2 APQDB_SSENTLEN Length of each SS entry
| 46 (2E) UNSIGNED 1 APQDB_CACCSS Access state for chg auth
| 47 (2F) UNSIGNED 1 APQDB_CANCDD Encode state for chg auth
| 48 (30) UNSIGNED 1 APQDB_CAHELD Held state for chg auth
| 49 (31) CHARACTER 3 * Reserved
| 52 (34) UNSIGNED 2 APQDB_EQECNT Total EQE count
| 54 (36) BIT(16) 2 APQDB_RSRFLG Flags
| 1... .... APQDB_RCVTRK Recovery level tracking
| .1.. .... APQDB_TRKSPN Tracking is suspended
| ..1. .... APQDB_PURBIT Suspended by time
| ...1 .... APQDB_ICNDIS IC needed disabled option
| 56 (38) CHARACTER 8 APQDB_GSGNAME Global Service Group name
| 64 (40) UNSIGNED 4 APQDB_USID Last alloc USID
| 68 (44) UNSIGNED 4 APQDB_AUSID Last authorized USID
| 72 (48) UNSIGNED 4 APQDB_RUSID Last received USID
| 76 (4C) UNSIGNED 4 APQDB_HUSID Hardened by tracker USID
| 80 (50) UNSIGNED 4 APQDB_RNUSID Receive needed USID
| 84 (54) CHARACTER 8 APQDB_RECOVGRP Recovery Group name
| 92 (5C) CHARACTER 4 * Reserved
|
| CONSTANTS
|
| LEN TYPE VALUE NAME DESCRIPTION
| ===== ========= ================= =============== ===============================
| 8 CHARACTER DSPAPQDB APQDB_EYECATCHER
|
| Figure 20. DSECT of DSPAPQDB
|

QUERY TYPE=DB
DSPAPQSL
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 16 DSPAPQSL
0 (0) CHARACTER 16 APQSL_SSINFO Subsystem list entry
0 (0) CHARACTER 8 APQSL_SSNAME Subsystem ID
8 (8) UNSIGNED 1 APQSL_ACCESS Access intent
9 (9) UNSIGNED 1 APQSL_NCDDST Encoded state
10 (A) BIT(8) 1 APQSL_SSFLGS Flags
1... .... APQSL_SSROLE 0 - Active SS, 1 - Tracking SS
.1.. .... APQSL_SSXRFC 1 - XRF Capable
11 (B) BIT(8) 1 * Reserved
12 (C) CHARACTER 4 APQSL_BKINFO Backout information
12 (C) SIGNED 2 APQSL_BKCTR Backout needed count
14 (E) SIGNED 2 APQSL_BKNUM Backout done count
CONSTANTS

===== ========= ================= =============== ===============================
Possible access intent values (apqsl_ACCESS)

====================================================================================
1 HEX 01 APQSL_ACCRO READ-GO
1 HEX 02 APQSL_ACCRD READ
1 HEX 03 APQSL_ACCUP UPDATE
1 HEX 04 APQSL_ACCEX EXCLUSIVE
Figure 21. DSECT of DSPAPQSL
Fast Path DEDB Output:

QUERY TYPE=DB
|
| Figure 22. Format of QUERY TYPE=DB (Fast Path DEDB) Output
|
The area information is returned only if DDN is specified. Recovery information
(RCVINFO) is only returned if the LIST parameter is specified.
Figure 23 on page 376, Figure 24 on page 377, and Figure 25 on page 379 describe
the fields contained in the DSPAPQFD and DSPAPQAR blocks shown in Figure 22.
Refer to Figure 31 on page 385 for an illustration of the Recovery Information
output fields.

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 38 DSPAPQFD
0 (0) CHARACTER 8 APQFD_DBNAME Database name
8 (8) SIGNED 4 *(4) Reserved
24 (18) SIGNED 2 APQFD_RCVCTR Recovery Needed Counter
26 (1A) SIGNED 2 APQFD_ICCTR IC Needed Counter
28 (1C) SIGNED 2 APQFD_ICRECCTR IC Recommended Counter
30 (1E) UNSIGNED 2 APQFD_DMBNUM Global DMB number
32 (20) UNSIGNED 2 APQFD_EQECNT Total EEQE count
34 (22) SIGNED 2 APQFD_AUTHDAREAS Number of Areas authorized
36 (24) UNSIGNED 1 APQFD_SHRLVL Share Level
37 (25) BIT(8) 1 APQFD_FLAGS Flags
1... .... APQFD_PAFLG Prohibit authorization
.1.. .... APQFD_NONRV Non-recoverable
..1. .... APQFD_ICNDIS IC needed disabled option
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQFD APQFD_EYECATCHER
Figure 23. DSECT of DSPAPQFD

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 196 DSPAPQAR
0 (0) CHARACTER 8 APQAR_DBNAME Database name
8 (8) CHARACTER 8 APQAR_AREANAME Area name
16 (10) UNSIGNED 4 APQAR_EEQELIST Offset to EEQE list
(DSPAPQEL), zero if no EEQEs
20 (14) UNSIGNED 4 APQAR_SSLIST Offset to SS list (DSPAPQSL),
zero if no SS auth'd
24 (18) UNSIGNED 4 APQAR_ADSLIST Offset to ADS list, zero if
none registered
28 (1C) SIGNED 4 * Reserved
32 (20) UNSIGNED 1 APQAR_SHRLVL Share level of DB
33 (21) UNSIGNED 1 APQAR_HELDAU Held auth state
1... .... APQAR_HAUBIT High order bit flag
34 (22) UNSIGNED 2 APQAR_DMBNUM Global DMB number
36 (24) SIGNED 2 APQAR_SSNUM # subsytems authd to Area
38 (26) UNSIGNED 2 APQAR_SSENTLEN Length of each SS entry
40 (28) UNSIGNED 1 APQAR_CACCSS Access state for CHG AUTH
41 (29) UNSIGNED 1 APQAR_CANCDD Encoded state for CHG AUTH
42 (2A) UNSIGNED 1 APQAR_CAHELD Held state for CHG AUTH
43 (2B) CHARACTER 5 APQAR_IRLMAU IRLMID of auth SS
48 (30) BIT(16) 2 APQAR_FLAGS
1... .... APQAR_RECYC REUSE image copies
.1.. .... APQAR_ICREC Image Copy Recommended
..1. .... APQAR_IC Image Copy Needed
...1 .... APQAR_ICNDIS IC needed disabled option 1 =
IC Needed Disabled
.... 1... APQAR_RECOV Recovery needed
.... .1.. APQAR_INPRO HSSP CIC in progress
.... ..1. APQAR_GT240 M/C FP GT240 area DEDB
.... ...1 APQAR_VSO VSO flag
49 (31) 1... .... APQAR_PREOP PREOPEN flag
.1.. .... APQAR_PRELD PRELOAD flag
..1. .... APQAR_LKASD VSO CF buffer lookaside
...1 .... APQAR_MAS VSO area resides in multi-area
CF structure
.... 1... APQAR_RRGAL REORG since last ALLOC, only
set if RSR-covered
.... .1.. APQAR_TSRAL TS recov since last ALLOC, only
set if RSR-covered
50 (32) BIT(8) 1 APQAR_RSRFLAGS Remote Site Recovery flags
1... .... APQAR_RCVTRK Recovery Level Tracking
.1.. .... APQAR_TRKSPN Tracking was suspended
..1. .... APQAR_PURBIT Suspended by time
...1 .... APQAR_RCVRQ Receive Required
51 (33) BIT(8) 1 APQAR_AUFLAG Authorization flags
1... .... APQAR_PAFLG Prohibit authorization
.1.. .... APQAR_NONRV Non-recoverable
52 (34) BIT(8) 1 APQAR_DSORG Data set organization
1... .... APQAR_VSAM 1 = VSAM, 0 = NON-VSAM
.1.. .... APQAR_INDEX 0 = Non-indexed (OSAM or ESDS),
1 = Indexed(ISAM or KSDS)
..11 1111 * Reserved - zeroes
Figure 24. DSECT of DSPAPQAR (Part 1 of 2)

QUERY TYPE=DB
53 (35) CHARACTER 1 APQAR_DBORG IMS DB organization

54 (36) CHARACTER 8 APQAR_GSGNAME GSG Name
64 (40) UNSIGNED 4 APQAR_USID Last ALLOC USID
68 (44) UNSIGNED 4 APQAR_AUSID Last authorized USID
72 (48) UNSIGNED 4 APQAR_RUSID Last received USID
76 (4C) UNSIGNED 4 APQAR_HUSID Hardened USID
80 (50) UNSIGNED 4 APQAR_RNUSID Receive needed USID
84 (54) CHARACTER 8 APQAR_RECOVGRP Recovery Group name
92 (5C) CHARACTER 8 APQAR_CAGRPNAME Change Accum group name
100 (64) UNSIGNED 2 APQAR_GENMX Max number of ICs that may be
predefined for this area
102 (66) UNSIGNED 2 APQAR_GENNO Number of available ICs for this area
104 (68) UNSIGNED 2 APQAR_USDIC Number of ICs used
106 (6A) SIGNED 2 APQAR_EEQECOUNT EEQE count
108 (6C) UNSIGNED 2 APQAR_EEQELENGTH EEQE entry length
110 (6E) UNSIGNED 1 APQAR_NOADS # of ADS in the area
111 (6F) UNSIGNED 1 APQAR_AVADS # of available ADS
112 (70) UNSIGNED 2 APQAR_ADSLENGTH ADS entry length
116 (74) CHARACTER 40 APQAR_JCL GENJCL members
116 (74) CHARACTER 8 APQAR_ICJCL Image copy member
124 (7C) CHARACTER 8 APQAR_OIJCL Online IC member
132 (84) CHARACTER 8 APQAR_RCJCL Recovery member
140 (8C) CHARACTER 8 APQAR_DFJCL DEFLTJCL member
148 (94) CHARACTER 8 APQAR_RVJCL Receive JCL member
156 (9C) UNSIGNED 2 APQAR_RTPRD IC retention period
158 (9E) UNSIGNED 2 APQAR_DSID IMS data set ID
160 (A0) UNSIGNED 4 APQAR_DSSN Data set sequence number
164 (A4) CHARACTER 16 APQAR_CFST1 VSO CF Structure 1
180 (B4) CHARACTER 16 APQAR_CFST2 VSO CF Structure 2
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 56 APQAR_ADSLT Area Data Set List
0 (0) CHARACTER 8 APQAR_ADSDD DDNAME of the ADS
8 (8) CHARACTER 44 APQAR_ADSDN DSN of the ADS
52 (34) BIT(8) 1 APQAR_ADSBT
1... .... APQAR_ADSAV Avail status of ADS
.1.. .... APQAR_ADSFM Format status of create util
..1. .... APQAR_ADSCP Copy status of create util
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQAR APQAR_EYECATCHER
Figure 24. DSECT of DSPAPQAR (Part 2 of 2)

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 13 DSPAPQEL
0 (0) CHARACTER 13 APQEL_EEQEENTRY EEQE descriptor entry
0 (0) BIT(8) 1 APQEL_EQEFG EEQE flags
1... .... APQEL_ERTL Toleration error
.1.. .... APQEL_ERRD Read error
..1. .... APQEL_ERWT Write error
...1 .... APQEL_ERUS DBRC user modified
.... 1... APQEL_ERPM DBRC permanent error
.... .1.. APQEL_INDT Indoubt EEQE
.... ..1. APQEL_CIIND Index CI indicator
1 (1) CHARACTER 4 APQEL_EQE EEQE
5 (5) CHARACTER 8 APQEL_SSID SSID which owns the EEQE
Figure 25. DSECT of DSPAPQEL
HALDB (Master and All Partitions) Output:
|
| Figure 26. Format of QUERY TYPE=DB (HALDB Master and Partitions) Output
|
The DBDS information is returned only if DDN is specified.
Figure 27 on page 380, Figure 28 on page 381, and Figure 21 on page 374 describe
the fields contained in the DSPAPQHB and DSPAPQHP blocks shown in Figure 26.

QUERY TYPE=DB
Refer to Figure 29 on page 383 for an illustration of the fields of the DBDS output.
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 60 DSPAPQHB
0 (0) CHARACTER 8 APQHB_DBNAME HALDB name
24 (18) BIT(8) 1 APQHB_FLAGS Flags
1... .... APQHB_NONRV Non-recoverable
.1.. .... APQHB_ICNDIS IC needed disabled
..1. .... APQHB_OLRCAP HALDB is OLR capable
25 (19) BIT(8) 1 APQHB_ORG DB organization
1... .... APQHB_PSINDEX PSINDEX DB
.1.. .... APQHB_PHIDAM PHIDAM DB
..1. .... APQHB_PHDAM PHDAM DB
...1 .... APQHB_OSAM OSAM DB
.... 1111 * Reserved
26 (1A) UNSIGNED 1 APQHB_SHRLVL Share level
27 (1B) UNSIGNED 1 APQHB_DSGCNT # DS Group members
28 (1C) UNSIGNED 2 APQHB_DMBNUM Global DMB number
30 (1E) UNSIGNED 2 APQHB_PARTID Current Partition ID
32 (20) SIGNED 2 APQHB_PART# Number of parts in HALDB
34 (22) UNSIGNED 2 APQHB_VERSION# Version number
36 (24) CHARACTER 8 APQHB_PSNAME Name of Part Sel Routine
44 (2C) CHARACTER 8 APQHB_GSGNAME GSG name
52 (34) CHARACTER 8 APQHB_RECOVGRP Recovery Group name
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQHB APQHB_EYECATCHER
Figure 27. DSECT of DSPAPQHB

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 192 DSPAPQHP
0 (0) CHARACTER 8 APQHP_HALDBNAME HALDB name
8 (8) CHARACTER 8 APQHP_PARTNAME Partition name
16 (10) UNSIGNED 4 APQHP_SSLIST Offset to SS list (DSPAPQSL),
zero if no SS auth'd
20 (14) UNSIGNED 4 APQHP_KEYSTRING Offset to KEYSTRING
(apqhp_PString), zero is no
key/string
24 (18) UNSIGNED 4 APQHP_DSGINFOOFFSET
Offset to data set group
information
28 (1C) SIGNED 4 * Reserved
32 (20) CHARACTER 44 *
32 (20) CHARACTER 37 APQHP_DSNBASE Base Partition DSN
76 (4C) CHARACTER 18 APQHP_HDAM PHDAM fields
76 (4C) CHARACTER 8 APQHP_RMNAME Randomizing module name
84 (54) SIGNED 4 APQHP_RBN Max relative block number
88 (58) SIGNED 4 APQHP_BYTES Max # of bytes
92 (5C) UNSIGNED 2 APQHP_ANCHR # of root anchor points
94 (5E) UNSIGNED 1 APQHP_FBFF Free block frequency factor
95 (5F) UNSIGNED 1 APQHP_FSPF Free space percentage factor
96 (60) UNSIGNED 2 APQHP_PARTID Partition ID
98 (62) SIGNED 2 APQHP_PSTLN Length of Part Key/String,
apqhp_PString
100 (64) UNSIGNED 2 APQHP_DSGINFOLEN
Length of each
apqhp_DSGinfo entry
102 (66) UNSIGNED 1 APQHP_DSGCNT DSG count
103 (67) BIT(8) 1 APQHP_FLAGS Flags
1... .... APQHP_PINIT Partition must be initialized
.1.. .... APQHP_ORDBDS 0=A-J/1=M-V DBDS active
..1. .... APQHP_OLRON OLR active
...1 .... APQHP_DISAB Partition Disabled
.... 1... APQHP_MVDBDS 1 = M-V DBDS exist
.... .1.. APQHP_OLRCAP Partition is OLR capable
============================================================================
If the Partitioned DB uses high keys, i.e. no Partition
Selection routine, the next two fields are used to sort the
partitions in key sequence.
============================================================================
104 (68) CHARACTER 8 APQHP_PREV DDN of previous partition
112 (70) CHARACTER 8 APQHP_NEXT DDN of next partition
120 (78) CHARACTER 8 APQHP_OLRIMS Owning IMS for OLR
128 (80) UNSIGNED 2 APQHP_IRCNT IC receive needed counter
130 (82) BIT(8) 1 APQHP_AUFLAG Authorization flags
1... .... APQHP_BKFLG Backout needed
.1.. .... APQHP_PAFLG Prohibit authorization
..1. .... APQHP_RDFLG Read only SS auth
...1 .... APQHP_NONRV Non-recoverable
Figure 28. DSECT of DSPAPQHP (Part 1 of 2)

QUERY TYPE=DB
| 131 (83) CHARACTER 5 APQHP_IRLMAU IRLM ID of auth SS

| 136 (88) SIGNED 2 APQHP_RCVCTR Recovery needed count
| 138 (8A) SIGNED 2 APQHP_ICCTR IC needed count
| 140 (8C) UNSIGNED 1 APQHP_SHRLVL Share level of DB
| 141 (8D) UNSIGNED 1 APQHP_HELDAU Held auth state
| 1... .... APQHP_HAUBIT High order bit flag
| 142 (8E) UNSIGNED 2 APQHP_DMBNUM Global DMB number
| 144 (90) SIGNED 2 APQHP_SSNUM # of SS auth DB
| 146 (92) UNSIGNED 2 APQHP_SSENTLEN Length of each SS entry
| 148 (94) UNSIGNED 1 APQHP_CACCSS Access state for chg auth
| 149 (95) UNSIGNED 1 APQHP_CANCDD Encode state for chg auth
| 150 (96) UNSIGNED 1 APQHP_CAHELD Held state for chg auth
| 152 (98) UNSIGNED 2 APQHP_EQECNT Total EQE count
| 154 (9A) BIT(16) 2 APQHP_RSRFLG Flags
| 1... .... APQHP_RCVTRK Only recov level trackng
| .1.. .... APQHP_TRKSPN Tracking is suspended
| ..1. .... APQHP_PURBIT Suspended by time
| ...1 .... APQHP_ICNDIS IC needed disabled option
| .... 1... APQHP_NOHKEY High key required
| 156 (9C) CHARACTER 8 APQHP_GSGNAME GSG name
| 164 (A4) UNSIGNED 4 APQHP_USID Last alloc USID
| 168 (A8) UNSIGNED 4 APQHP_AUSID Last authorized USID
| 172 (AC) UNSIGNED 4 APQHP_RUSID Last received USID
| 176 (B0) UNSIGNED 4 APQHP_HUSID Hardened by tracker USID
| 180 (B4) UNSIGNED 4 APQHP_RNUSID Receive needed USID
| 184 (B8) SIGNED 2 APQHP_ICRECCTR IC Recommended Counter
| 186 (BA) UNSIGNED 2 APQHP_VERSION# Version number
| 188 (BC) UNSIGNED 1 APQHP_OLRACTHARDCTR
| OLR curs active count
| 189 (BD) UNSIGNED 1 APQHP_OLRINACTHARDCTR
| OLR curs inact count
| 190 (BE) UNSIGNED 2 APQHP_REORG# Partition reorg #
| 192 (C0) CHARACTER 8 APQHP_OLRBytes OLR Bytes moved
| 200 (C8) CHARACTER 8 APQHP_OLRSegs OLR Segments moved
| 208 (D0) CHARACTER 4 APQHP_OLRRoots OLR Root Segments
|
| OFFSET OFFSET
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE 2 APQHP_DSGINFO Data set group information
| 0 (0) UNSIGNED 2 APQHP_BLKSZ DS block size, OSAM only
|
| OFFSET OFFSET
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE * APQHP_PSTRING Partition Key/String
|
| CONSTANTS
|
| ===== ========= ================= =============== ===============================
| 8 CHARACTER DSPAPQHP APQHP_EYECATCHER
Figure 28. DSECT of DSPAPQHP (Part 2 of 2)
DBDS Output:

QUERY TYPE=DB
|
| Figure 29. Format of QUERY TYPE=DB (DBDS) Output
|
Recovery information (RCVINFO) is returned only if the LIST parameter is
specified.
Figure 30 on page 384 and Figure 25 on page 379 describe the fields contained in
the DSPAPQDS block shown in Figure 29. Refer to Figure 31 on page 385 for an
illustration of the Recovery Information output fields.

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 160 DSPAPQDS
0 (0) CHARACTER 8 APQDS_DBNAME Database name
8 (8) CHARACTER 8 APQDS_DDNAME DD name
16 (10) UNSIGNED 4 APQDS_EEQELIST
Offset to EEQE list
(DSPAPQEL), zero if no EEQEs
32 (20) CHARACTER 44 APQDS_DSN Data set name
76 (4C) UNSIGNED 2 APQDS_RTPRD IC retention period
78 (4E) UNSIGNED 2 APQDS_DSID Data set ID number
80 (50) UNSIGNED 4 APQDS_DSSN Data set sequence number
84 (54) UNSIGNED 4 APQDS_RUSID Recovered-to USID(trkr)
88 (58) BIT(8) 1 APQDS_FLAGS BINARY ZEROS
1... .... APQDS_RECYC REUSE image copies
.1.. .... APQDS_ICREC Image Copy Recommended
..1. .... APQDS_RCVRQ Receive required
...1 .... APQDS_IC Image Copy Needed
.... 1... APQDS_RECOV Recovery Needed
.... .1.. APQDS_NONRV Non-recoverable
89 (59) BIT(8) 1 APQDS_DSORG Data set organization
1... .... APQDS_VSAM 1 = VSAM, 0 = NON-VSAM
.1.. .... APQDS_INDEX 0 = Non-indexed (OSAM or ESDS),
1 = Indexed(ISAM or KSDS)
..11 1111 * Reserved - zeroes
90 (5A) CHARACTER 1 APQDS_DBORG IMS DB organization
91 (5B) UNSIGNED 1 * Reserved
92 (5C) UNSIGNED 2 APQDS_GENMX Max number of ICs that may be
predefined for this area
94 (5E) UNSIGNED 2 APQDS_AVAILIC#
Number of available ICs for
this area
96 (60) UNSIGNED 2 APQDS_USEDIC# Number of ICs used
98 (62) SIGNED 2 APQDS_EEQECOUNT
EEQE count
100 (64) UNSIGNED 2 APQDS_EEQELENGTH
EEQE entry length
102 (66) BIT(8) 1 APQDS_FLG1 Flags
1... .... APQDS_RRGAL REORG since last ALLOC, only
set if RSR-covered
.1.. .... APQDS_TSRAL TS recov since last ALLOC, only
set if RSR-covered
103 (67) BIT(8) 1 APQDS_FLG2 DBDS type flags
1... .... APQDS_PART TYPEPART record
.1.. .... APQDS_PDATA TYPEPART subtype DATA
..1. .... APQDS_PILE TYPEPART subtype ILE
...1 .... APQDS_PINDX TYPEPART subtype Index
104 (68) CHARACTER 8 APQDS_CAGRPNAME
Change Accum group name
112 (70) CHARACTER 40 APQDS_JCL GENJCL members
112 (70) CHARACTER 8 APQDS_ICJCL Image copy member
120 (78) CHARACTER 8 APQDS_OIJCL Online IC member
128 (80) CHARACTER 8 APQDS_RCJCL Recovery member
136 (88) CHARACTER 8 APQDS_DFJCL DEFLTJCL member
144 (90) CHARACTER 8 APQDS_RVJCL Receive JCL member
152 (98) CHARACTER 8 APQDS_ODDN OLR partner DBDS
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQDS APQDS_EYECATCHER
Figure 30. DSECT of DSPAPQDS

QUERY TYPE=DB
Recovery Information (RCVINFO) Output:
|
| Figure 31. Format of QUERY TYPE=DB (RCVINFO) Output
|
Recovery information (RCVINFO) is returned only if the LIST parameter is
specified. The pointers will be zero if either the specific information does not exist
or it wasn’t requested.
Figure 32 on page 386, Figure 33 on page 386, Figure 34 on page 387, Figure 35 on
page 388, and Figure 36 on page 389 describe the fields contained in the
DSPAPQRI block shown in Figure 31.

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 32 DSPAPQRI
0 (0) CHARACTER 8 APQRI_DBNAME Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQRI_DDNAME DD name or
8 (8) CHARACTER 8 APQRI_AREANAME
Area name
16 (10) ADDRESS 4 APQRI_ALLOCPTR
ptr to ALLOC chain
20 (14) ADDRESS 4 APQRI_ICPTR ptr to IC chain
24 (18) ADDRESS 4 APQRI_RECOVPTR
ptr to RECOV chain
28 (1C) ADDRESS 4 APQRI_REORGPTR
ptr to REORG chain
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQRI APQRI_EYECATCHER
Figure 32. DSECT of DSPAPQRI
| OFFSET OFFSET
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE 88 DSPAPQAL
| 0 (0) CHARACTER 8 APQAL_DBNAME Database name
| 8 (8) CHARACTER 8 *
| 8 (8) CHARACTER 8 APQAL_DDNAME DD name or
| 8 (8) CHARACTER 8 APQAL_AREANAME Area name
| 16 (10) CHARACTER 12 APQAL_ALLOCTM Allocation time
| 28 (1C) CHARACTER 12 APQAL_DALTM Deallocation time
| 40 (28) CHARACTER 12 APQAL_STRTM Log start time
| 52 (34) UNSIGNED 4 APQAL_DSSN Field for DSSN value
| 56 (38) UNSIGNED 4 APQAL_USID Update set identifier
| 60 (3C) CHARACTER 8 APQAL_ALRID LRID of begin-upd rec
| 68 (44) CHARACTER 8 APQAL_DLRID LRID of end-upd rec
| 76 (4C) CHARACTER 8 APQAL_SLRID Last LRID applied if suspended
| 84 (54) BIT(8) 1 APQAL_FLAGS Flags
| 1... .... APQAL_TSUSP Tracking is suspended
| .1.. .... APQAL_NAPPL No records applied
| ..1. .... APQAL_CICPT Fuzzy ic purge time
| CONSTANTS
|
| ===== ========= ================= =============== ===============================
| 8 CHARACTER DSPAPQAL APQAL_EYECATCHER
Figure 33. DSECT of DSPAPQAL

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 64 DSPAPQIC
0 (0) CHARACTER 8 APQIC_DBNAME Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQIC_DDNAME DD name or
8 (8) CHARACTER 8 APQIC_AREANAME
Area name
16 (10) CHARACTER 12 APQIC_STARTIME
IC start time, packed decimal
28 (1C) CHARACTER 12 APQIC_STOPTIME
IC stop time, packed decimal
40 (28) BIT(8) 1 APQIC_TYPE IMAGE COPY TYPE
1... .... APQIC_BATCH BATCH
.1.. .... APQIC_CIC CONCURRENT
..1. .... APQIC_USERIC USER IMAGE COPY
...1 .... APQIC_ONLINE ONLINE
.... 1... APQIC_SMSIC SMS IC w/ DB exclusive
.... .1.. APQIC_SMSCC SMS IC w/ DB shared
41 (29) BIT(8) 1 APQIC_STATUS IC status flags
1... .... APQIC_AVAIL Available IC
.1.. .... APQIC_IC1 Image Copy 1 exists
..1. .... APQIC_IC2 Image Copy 2 exists
...1 .... APQIC_ERR1 Error on image 1
.... 1... APQIC_ERR2 Error on image 2
.... .1.. APQIC_EMP2 Image 2 defined and unused
42 (2A) BIT(8) 1 APQIC_FLAGS
1... .... APQIC_HSINP HSSP CIC in progress
.1.. .... APQIC_CAT Catalogued IC (HSSP)
43 (2B) CHARACTER 1 * Reserved
44 (2C) CHARACTER 2 *
44 (2C) UNSIGNED 2 APQIC_OFF1 Offset to image 1 data
44 (2C) UNSIGNED 2 APQIC_OFFU Offset to user IC data
46 (2E) UNSIGNED 2 APQIC_OFF2 Offset to image 2 data
48 (30) UNSIGNED 4 APQIC_CNT12 Record count
52 (34) UNSIGNED 4 APQIC_USID Update set ID
56 (38) UNSIGNED 2 APQIC_LEN12 Length of image 1/2 data
56 (38) UNSIGNED 2 APQIC_LENU Length of user IC data
58 (3A) CHARACTER 6 * Reserved
Figure 34. DSECT of DSPAPQIC (Part 1 of 2)

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 64 APQIC_IC12 Data for image 1 or 2
0 (0) CHARACTER 44 APQIC_DSN12 Data set name
44 (2C) UNSIGNED 2 APQIC_FILE File sequence number
46 (2E) CHARACTER 8 APQIC_RUT12 Unit device type
54 (36) UNSIGNED 2 APQIC_VOLCT # of volumes predefined
56 (38) UNSIGNED 2 APQIC_VOLUS # of volumes used
58 (3A) UNSIGNED 2 APQIC_VOLLISTLEN
Length of each volume list
entry in apqic_VOLS
60 (3C) UNSIGNED 4 APQIC_VOLLISTOFFSET
Offset to volume list
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) CHARACTER 6 APQIC_VOLS List of VOLSERs
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 80 APQIC_USER Data for user IC
0 (0) CHARACTER 80 APQIC_UDATA User supplied data
CONSTANTS

===== ========= ================= =============== ===============================
1 DECIMAL 255 APQIC_MAXV max # volumes
8 CHARACTER DSPAPQIC APQIC_EYECATCHER
Figure 34. DSECT of DSPAPQIC (Part 2 of 2)
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 49 DSPAPQRV
0 (0) CHARACTER 8 APQRV_DBNAME Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQRV_DDNAME DD name or
8 (8) CHARACTER 8 APQRV_AREANAME
Area name
16 (10) CHARACTER 12 APQRV_RUNTIME The time at which the DBDS was
recovered.
28 (1C) CHARACTER 12 APQRV_ENDTIME Partial recovery only, the time
to which the DBDS was restored
40 (28) UNSIGNED 4 APQRV_FUSID First undone USID
44 (2C) UNSIGNED 4 APQRV_LUSID Last undone USID
48 (30) BIT(8) 1 APQRV_FLAGS Flags
1... .... APQRV_PITR Point In Time Recovery
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQRV APQRV_EYECATCHER
Figure 35. DSECT of DSPAPQRV

QUERY TYPE=DB
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 60 DSPAPQRR
0 (0) CHARACTER 8 APQRR_DBNAME Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQRR_DDNAME DD name or
8 (8) CHARACTER 8 APQRR_AREANAME
Area name
16 (10) CHARACTER 12 APQRR_RUNTIME The time at which the DBDS was
reorganized.
28 (1C) CHARACTER 12 APQRR_STOPTIME
Stoptime of online reorg
40 (28) BIT(8) 1 APQRR_FLAGS
1... .... APQRR_ONL 1=ONLINE/0=OFFLINE reorg
.1.. .... APQRR_RECOV 1=May be used for recovery
44 (2C) UNSIGNED 4 APQRR_USID Associated USID
48 (30) CHARACTER 12 APQRR_PITR Stoptime moved - PITR
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQRR APQRR_EYECATCHER
Figure 36. DSECT of DSPAPQRR
| Database Not Found Output:

|
|
|
| Figure 37. Format of QUERY TYPE=DB (Database Not Found) Output
|
| This output block is returned when some of the databases specified in the DBLIST
| block could not be found in the RECON. One block is returned for each database
| that could not be found. The database name is included in the data area of this
| block.
| When a database is not found, the macro call receives a return code of four
| (RC=4). If none of the databases in the list are found (RC=8), no output blocks are
| returned.
| Figure 38 on page 390 describes the fields contained in the DSPAPQNF block
| shown in Figure 37.
|

QUERY TYPE=xxxxGROUP
| OFFSET OFFSET
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE 8 DSPAPQNF
| 0 (0) CHARACTER 8 APQNF_DBNAME DB name
|
| Figure 38. DSECT of DSPAPQNF
|
Group Query
The Group query (DSPAPI FUNC=QUERY TYPE=xxxxGROUP) request is used to
retrieve group and member information for one of the following types of groups
registered in RECON:
v DBDS group (TYPE=DBDSGROUP)
v DB group (TYPE=DBGROUP)
v Recovery group (TYPE=RECOVGROUP)
v CA group (TYPE=CAGROUP)
v Global service group (TYPE=GSGROUP)
Syntax for the TYPE=xxxxGROUP Query Request

| DSPAPI FUNC=QUERY TYPE=DBDSGROUP
| name TYPE=DBGROUP
TYPE=RECOVGROUP
CAINFO=NO
TYPE=CAGROUP
CAINFO=YES
TYPE=GSGROUP
| NAME=* MF=S
| TOKEN=address OUTPUT=output
NAME=name MF=(S,list)
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

|
Parameters for the TYPE=xxxxGROUP Query Request

The following are the possible parameters for QUERY TYPE=xxxxGROUP.
TYPE=DBDSGROUP | DBGROUP | CAGROUP | RECOVGROUP |
GSGROUP
Specifies the type of group for which information is requested.
CAINFO= YES | NO
Optional parameter that specifies whether CA execution information is to
be included with the CAGROUP information. CAINFO is only valid with

TYPE=CAGROUP. CAINFO defaults to NO when TYPE=CAGROUP is

specified, indicating that only the CA group member information is
requested.
| If CAINFO=NO is specified or if CAINFO=YES is specified and no CA
| execution information exists, the block dependent pointer (apqhd_depptr)
| in the header of the CAGROUP block will be zero.
NAME= * | symbol | (2 - 12)
Optional parameter that specifies the name of the group being queried.
The default (NAME=*) requests information about all groups of the
specified type.
MF=S | L | M | E
parameter values.
block of a possible chain of group information blocks. See “Output for the
TYPE=xxxxGROUP Query Request” on page 393 for a detailed description
of the information blocks returned.
could be built.
required.

| Return and Reason Codes for the TYPE=xxxxGROUP Query

| Request
| Table 22 contains most of the return and reason codes for TYPE=xxxxGROUP
| query requests. The other possible return and reason codes relate to DBRC, not the
| query request. For a list of these return and reason codes, see “DBRC Service Aids”
| in the IMS Version 9: Diagnosis Guide and Reference.
| Table 22. Return and Reason Codes for TYPE=xxxxGROUP Query Requests
| Warning
| X'00000008' X'D8300001' No group records of the requested type exist in
| the RECON.
| Severe Error
| Storage Error
| X'00000028' X'D8300001' Error obtaining storage for CAGROUP block.
| X'00000028' X'D8300002' Error obtaining storage for GSG block.
| X'00000028' X'D8300003' Error obtaining storage for DBDSGRP, DBGRP, or
| RECOVGRP block.
| X'00000028' X'D8310001' Error obtaining storage for CA block.
| Internal Error
| information.
| Parameter Error

| Table 22. Return and Reason Codes for TYPE=xxxxGROUP Query Requests (continued)
| X'00000030' X'C9000008' Invalid NAME field address. The address of the
| field containing the NAME failed validity
| parameter.
| X'00000030' X'D8300001' Parameter error. CAINFO=YES is only allowed
| with TYPE=CAGROUP.
|
| Output for the TYPE=xxxxGROUP Query Request

The next few sections illustrate the format of the output from a QUERY
TYPE=xxxxGROUP requests. Following the figures that graphically describe the
layout of the output are sample DSECTs that describe in detail the fields of the
storage blocks and their relationship to each other.
Output for QUERY TYPE=DBDGROUP, DBGROUP, and RECOVGROUP:
|
| Figure 39. Format for QUERY TYPE=DBDSGROUP, DBGROUP, RECOVGROUP Output
|

OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 32 DSPAPQDG
0 (0) CHARACTER 8 APQDG_GROUPNAME
Group name
8 (8) UNSIGNED 4 APQDG_MEMBERINFO
Offset to group member list
12 (C) UNSIGNED 2 APQDG_MEMBERLEN
Length of group member entry
14 (E) SIGNED 2 APQDG_MEMBERCOUNT
Number of group members
28 (1C) CHARACTER 4 * Reserved
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 16 APQDG_MEMBER List of group members
0 (0) CHARACTER 16 APQDG_DBDSG DBDS group
0 (0) CHARACTER 8 APQDG_DBDSG_DBNAME
Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQDG_DBDSG_DDNAME
DD name or
8 (8) CHARACTER 8 APQDG_DBDSG_AREANAME
AREA name
0 (0) CHARACTER 16 APQDG_DBG DB group
0 (0) CHARACTER 8 *
0 (0) CHARACTER 8 APQDG_DBG_DBNAME
Database name or
0 (0) CHARACTER 8 APQDG_DBG_AREANAME
AREA name
8 (8) CHARACTER 8 * Not used
0 (0) CHARACTER 16 APQDG_RECOVG Recovery group
0 (0) CHARACTER 8 APQDG_RECOVG_DBNAME
Database name
8 (8) CHARACTER 8 APQDG_RECOVG_AREANAME
AREA name, null if
not Fast Path
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQDG APQDG_EYECATCHER
Figure 40. DSECT of DSPAPQDG
Output for QUERY TYPE=CAGROUP:

|
| Figure 41. Format for QUERY TYPE=CAGROUP Output
|
The CA block is only returned when CAINFO=YES is specified and records of a
change accumulation exist in the RECON.

OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 48 DSPAPQCG
0 (0) CHARACTER 8 APQCG_GROUPNAME
Group name
8 (8) UNSIGNED 4 APQCG_MEMBERINFO
12 (C) UNSIGNED 2 APQCG_MEMBERLEN
14 (E) SIGNED 2 APQCG_MEMBERCOUNT
24 (18) SIGNED 2 APQCG_GRPMAX Maximum number of CAs that may
be predefined for this CA group
26 (1A) SIGNED 2 APQCG_AVAILCA#
Number of available CA data
sets for this group
28 (1C) SIGNED 2 APQCG_USEDCA# Number of used CA data sets
30 (1E) BIT(8) 1 APQCG_FLAGS Flags
1... .... APQCG_REUSE Reuse CA data sets
31 (1F) CHARACTER 1 * Reserved
32 (20) CHARACTER 8 APQCG_CAJCL GENJCL CAJCL member name
40 (28) CHARACTER 8 APQCG_DFJCL DEFLTJCL member name
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 16 APQCG_MEMBER List of group members
0 (0) CHARACTER 8 APQCG_DBNAME Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQCG_DDNAME DD name or
8 (8) CHARACTER 8 APQCG_AREANAME
AREA name
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQCG APQCG_EYECATCHER
Figure 42. DSECT of DSPAPQCG

| OFFSET OFFSET
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE 96 DSPAPQCA
| 0 (0) CHARACTER 8 APQCA_GROUPNAME
| Group name
| 8 (8) UNSIGNED 4 APQCA_MEMBERINFO
| Offset to group member list
| 12 (C) UNSIGNED 2 APQCA_MEMBERLEN
| Length of each member entry
| 14 (E) SIGNED 2 APQCA_MEMBERCOUNT
| Number of group members
| 16 (10) UNSIGNED 4 APQCA_VOLINFO Offset to volume information
| 20 (14) SIGNED 4 * Reserved
| 24 (18) CHARACTER 44 APQCA_DSN Data set name
| 68 (44) CHARACTER 12 APQCA_STOPTIME
| Packed decimal date/time - for
| predefined datasets, represents
| record creation time.
| Otherwise, it is the stoptime
| of the last logtape volume used
| as input to the Change
| Accumulation utility that
| produced this CA as output. If
| the CA run included an
| 'incomplete log subset' it is
| the start time of the first
| truncated log volume.
| 80 (50) CHARACTER 12 APQCA_RUNTIME CA run time
| 92 (5C) BIT(8) 1 APQCA_FLAGS Flags
| 1... .... APQCA_ERROR Error on data set
| .1.. .... APQCA_SUBSET Subset of logs used for CA
| ..1. .... APQCA_COMMAND
| SUBSET/COMP has been set or
| reset with an external cmd
| 93 (5D) CHARACTER 3 * Reserved
|
| OFFSET OFFSET
| ======== ======== ========= ======== ============== ===============================
| 0 (0) STRUCTURE 56 APQCA_MEMBER List of group members
| 0 (0) CHARACTER 8 APQCA_MEM_DBNAME
| Database name
| 8 (8) CHARACTER 8 *
| 8 (8) CHARACTER 8 APQCA_MEM_DDNAME
| DD name or
| 8 (8) CHARACTER 8 APQCA_MEM_AREANAME
| AREA name
| 16 (10) UNSIGNED 4 APQCA_MEM_DSSN
| Data Set sequence number
| 20 (14) UNSIGNED 4 APQCA_MEM_USID
| USID of last change
| accumulated
| 24 (18) CHARACTER 8 APQCA_MEM_LRID
| LRID of last change accumulated
| 32 (20) CHARACTER 12 APQCA_MEM_PURGETIME
| Purge time
| 44 (2C) CHARACTER 6 APQCA_MEM_LSN Lock sequence number
| 50 (32) BIT(8) 1 APQCA_MEM_FLAGS
| Member flags
| 1... .... APQCA_MEM_NOCHG
| No changes accumulated
| .1.. .... APQCA_MEM_INDOUBT
| Indoubt EEQEs accumulated
| ..1. .... APQCA_MEM_INCOMP
| Incomplete CA
|
| Figure 43. DSECT of DSPAPQCA (Part 1 of 2)
| Chapter 17. DBRC Query Request 397
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 24 APQCA_VOL_DATA Volume data
0 (0) UNSIGNED 2 APQCA_VOL_FILESEQ
File sequence number
2 (2) CHARACTER 8 APQCA_VOL_UNIT
Unit type
10 (A) UNSIGNED 2 APQCA_VOL_COUNT
Number of VOLSERs defined
12 (C) UNSIGNED 2 APQCA_VOL_USED
Number of VOLSERs used
14 (E) SIGNED 2 APQCA_VOL_LENGTH
Length of each VOLSER
16 (10) UNSIGNED 4 APQCA_VOL_OFFSET
Offset to VOLSER
information
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 6 APQCA_VOLSER List of VOLSERs
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQCA APQCA_EYECATCHER
| Figure 43. DSECT of DSPAPQCA (Part 2 of 2)
Output for QUERY TYPE=GSGROUP:
|
| Figure 44. Format for QUERY TYPE=GSGROUP Output
|

QUERY TYPE=LOG
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 80 DSPAPQGG
0 (0) CHARACTER 8 APQGG_GROUPNAME
Group name
8 (8) UNSIGNED 4 APQGG_MEMBERINFO
12 (C) UNSIGNED 2 APQGG_MEMBERLEN
14 (E) SIGNED 2 APQGG_MEMBERCOUNT
24 (18) UNSIGNED 4 APQGG_SDSN# SLDS DSN sequence number
28 (1C) UNSIGNED 4 APQGG_PTOKEN Current PRILOG token
32 (20) UNSIGNED 4 APQGG_MPTOK Min required PRILOG token
36 (24) UNSIGNED 4 APQGG_TTOKN Planned takeover token
40 (28) CHARACTER 12 APQGG_LOGTIME Current log start time
52 (34) CHARACTER 12 APQGG_HITIME Highest time ever received from
the active site
64 (40) CHARACTER 8 APQGG_TSNAME Tracking subsystem ID
72 (48) BIT(8) 1 APQGG_FLAGS
1... .... APQGG_ACTTKO Active takeover in progress
.1.. .... APQGG_1STSIGNON
Indicates the first signon of
an active subsystem after an
RSR takeover
..1. .... APQGG_TRKTKO Tracker takeover in progress
...1 .... APQGG_RESET RESET.GSG issued
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 16 APQGG_MEMBER List of group members
0 (0) CHARACTER 8 APQGG_SGNAME Service group name
8 (8) CHARACTER 1 APQGG_SGROLE Role 'A' OR 'T'
9 (9) BIT(8) 1 APQGG_SGFLAGS Flags
1... .... APQGG_SGLOCAL
1 = local SG
10 (A) CHARACTER 6 * Reserved
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQGG APQGG_EYECATCHER
Figure 45. DSECT of DSPAPQGG
Log Query
The Log query (DSPAPI FUNC=QUERY TYPE=LOG) request is used to retrieve log
information from RECON for a specific instance of a subsystem.
If the request is for non-RSR logs or RSR active subsystem logs, information from
the following RECON records is returned:
v PRILOG
v LOGALL
v SECLOG (if applicable)
v PRISLDS (if applicable)
v SECSLDS (if applicable)

QUERY TYPE=LOG
If the request is for RSR tracking subsystem logs, information from the following
RECON records is returned:
v PRITSLDS
v SECTSLDS (if applicable)
Syntax for the TYPE=LOG Query Request

DSPAPI FUNC=QUERY TYPE=LOG TOKEN=address STARTIME=time
name
| LOC=SPEC TRACKER=NO

LOC=PREV TRACKER=YES SSID=subsystem
LOC=NEXT SSID=subsystem_ID
OUTPUT=output
RETCODE=returncode RSNCODE=reasoncode
| MF=S VERSION=1.0

MF=(S,list) VERSION=number
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
Parameters for the TYPE=LOG Query Request

The following are the possible parameters for QUERY TYPE=LOG.
TYPE=LOG
Specifies that log information is requested.
STARTIME=symbol | (2 - 12)
Required parameter that specifies the time-stamp field containing the start
time of the log requested. The time is a packed decimal time stamp in UTC
format.
| LOC=PREV | NEXT | SPEC
Optional parameter that specifies that the request is for the log with a
specified start time (LOC=SPEC), a start time preceding the specified start
time (LOC=PREV), or a start time following the specified start time
(LOC=NEXT). The STARTIME parameter is used as the base of the search
and does not need to be the start time of a log in RECON.
| LOC=SPEC is the default.
| SSID=symbol | (2 - 12)
| Optional parameter that specifies the subsystem name for the log being
| queried. The SSID parameter is required for RSR tracking subsystem log

QUERY TYPE=LOG
| queries (TRACKER=YES). For other queries, you can only specify the SSID
| parameter when you request the previous or next log of a specific
| subsystem, that is, you specify LOC=PREV or LOC=NEXT.
TRACKER=YES |NO
Optional parameter that specifies whether log information is being
requested for an RSR tracking subsystem or not. Specify TRACKER=YES to
request the RSR tracker’s log information. Specify TRACKER=NO to
request log information from a non-RSR subsystem or an active subsystem
of an RSR system. TRACKER=NO is the default.
MF=S | L | M | E
parameter values.
block of a possible chain of log information blocks. See “Output for the
TYPE=LOG Query Request” on page 403 for a detailed description of the
could be built.
required.
| SSID=symbol | (2-12)
| Optional parameter that specifies the subsystem name for the log being
| queried. The SSID parameter is required for RSR tracking subsystem log
| queries (TRACKER=YES). Otherwise, you can only specify the SSID

QUERY TYPE=LOG
| parameter when you request the previous or next log of a specific

| subsystem, that is, you specify LOC=PREV or LOC=NEXT.
| Return and Reason Codes for the TYPE=LOG Query Request

| Table 23 contains most of the return and reason codes for TYPE=BACKOUT query
| Table 23. Return and Reason Codes for TYPE=LOG Query Requests
| Warning
| X'00000008' X'D8400001' No previous or next log record of the requested
| log type - PRILOG or PRITSLDS.
| X'00000008' X'D8400002' The specified log record of the requested log type
| - PRILOG or PRITSLDS - does not exist.
| Severe Error
| Storage Error
| X'00000028' X'D8400001' Error obtaining storage for LOGINFO block.
| X'00000028' X'D8400002' Error obtaining storage for PRILOG, SECLOG,
| PRISLDS, SECSLDS, PRITSLDS, or SECTSLDS
| block.
| X'00000028' X'D8400003' Error obtaining storage for LOGALL block.
| Internal Error
| information.
| Parameter Error

QUERY TYPE=LOG
| Table 23. Return and Reason Codes for TYPE=LOG Query Requests (continued)
| calling program.
| X'00000030' X'C9000001' Invalid STARTIME field address. The address of
| the field containing the STARTIME failed validity
| parameter.
| X'00000030' X'D8400001' Parameter error. STARTIME parameter is
| required.
| X'00000030' X'D8400002' Parameter error. SSID is required with
| TRACKER=YES.
| X'00000030' X'D8400003' Parameter error. SSID parameter is not allowed
| for active logs (TRACKER=NO) unless specified
| with LOC=PREV or NEXT.
|
| Output for the TYPE=LOG Query Request

The following sections have figures that illustrate the format of output from a
QUERY TYPE=LOG requests. The sample DSECTs that follow the figures describe
in detail the fields of the storage blocks and their relationship to each other.
Log Information Output:

QUERY TYPE=LOG
|
dep next block
DSPAPQLI length LOGINFO version
ptr ptr offset
...
0
SSID STARTTIME PRILOG LOGALL SECLOG PRISLDS SECSLDS PRITSLDS SECTSLDS
SECTSLDS block
PRITSLDS block
SECSLDS block
PRISLDS block
SECLOG block
LOGALL block
PRILOG block
|
| Figure 46. Format for QUERY TYPE=LOG Log Information Output
|
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 48 DSPAPQLI
0 (0) CHARACTER 8 APQLI_SSID Log SSID
8 (8) CHARACTER 12 APQLI_STARTTIME
Log start time
20 (14) ADDRESS 4 APQLI_PRILOGPTR
ptr to PRILOG block
24 (18) ADDRESS 4 APQLI_LOGALLPTR
ptr to LOGALL block
28 (1C) ADDRESS 4 APQLI_SECLOGPTR
ptr to SECLOG block
32 (20) ADDRESS 4 APQLI_PRISLDSPTR
ptr to PRISLDS block
36 (24) ADDRESS 4 APQLI_SECSLDSPTR
ptr to SECSLDS block
40 (28) ADDRESS 4 APQLI_PRITSLDSPTR
ptr to PRITSLDS block
44 (2C) ADDRESS 4 APQLI_SECTSLDSPTR
ptr to SECTSLDS block
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQLI APQLI_EYECATCHER
Figure 47. DSECT of DSPAPQLI
TYPE=LOG Output for PRILOG, SECLOG, PRISLDS, SECSLDS, PRITSLDS,

and SECTSLDS:

QUERY TYPE=LOG
|
| Figure 48. Format for QUERY TYPE=LOG Output for PRILOG, SECLOG, PRISLDS, SECSLDS, PRITSLDS, and
| SECTSLDS
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 96 DSPAPQLG
0 (0) UNSIGNED 4 APQLG_FIRSTLOGDS Offset to first log DS entry
4 (4) UNSIGNED 4 APQLG_LASTLOGDS Offset to last log DS entry
16 (10) CHARACTER 8 APQLG_SSID Subsystem ID
24 (18) CHARACTER 12 APQLG_STARTTIME Log start time
36 (24) CHARACTER 12 APQLG_ENDTIME Log end time
48 (30) SIGNED 4 APQLG_DSNCOUNT Number of data sets
52 (34) UNSIGNED 1 APQLG_RELVL Log Release Level
53 (35) BIT(8) 1 APQLG_FLAGS1 Flags
1... .... APQLG_ONLINE Online log
.1.. .... APQLG_LSTAR Last OLDS has been archived
..1. .... APQLG_LSTNA Last OLDS has not been archived
...1 .... APQLG_GAP There is a gap in this log
.... 1... APQLG_PRGAP There is a gap in a prev log
54 (36) BIT(8) 1 APQLG_FLAGS2 Flags
1... .... APQLG_TRKNG Tracking log data set
.1.. .... APQLG_NTERM IMS subsystem has terminated normally
..1. .... APQLG_BKLOG Batch backout log
56 (38) CHARACTER 8 APQLG_FIRSTLRID Id of first log record
64 (40) UNSIGNED 4 APQLG_PTOKEN PRILOG token
68 (44) CHARACTER 8 APQLG_GSGNAME GSG name
76 (4C) CHARACTER 12 APQLG_CHKPT0 Checkpoint 0 time
Figure 49. DSECT of DSPAPQLG (Part 1 of 2)

QUERY TYPE=LOG
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 120 APQLG_DS_ENTRY Data set entry
0 (0) UNSIGNED 4 APQLG_DS_NEXT Offset to next log DS entry
4 (4) UNSIGNED 4 APQLG_DS_PREV Offset to prev log DS entry
8 (8) UNSIGNED 4 APQLG_DS_VOLINFO Offset to DS volume info
12 (C) CHARACTER 44 APQLG_DS_DSNAME Data set name
56 (38) CHARACTER 12 APQLG_DS_STARTTIME DS start time
68 (44) CHARACTER 12 APQLG_DS_ENDTIME DS end time
80 (50) BIT(8) 1 APQLG_DS_FLAGS1 Flags
1... .... APQLG_DS_ERR I/O Error
.1.. .... APQLG_DS_DUMMY Log compressed, 1st DS dummy
..1. .... APQLG_DS_RSTBG Restart begin
...1 .... APQLG_DS_RSTEN Restart end
.... 1... APQLG_DS_COLD Cold start
.... .1.. APQLG_DS_NOBMP ERE NOBMP
.... ..1. APQLG_DS_SAVER Backout UORs saved
.... ...1 APQLG_DS_NOID Backouts not identified
81 (51) BIT(8) 1 APQLG_DS_FLAGS2 Flags
1... .... APQLG_DS_TRKARCH Tracking log DS archived
.1.. .... APQLG_DS_TRKFEOV Tracking log closed FEOV
82 (52) CHARACTER 2 APQLG_DS_DFLG3 Reserved
84 (54) CHARACTER 8 APQLG_DS_FLRID First log record ID
92 (5C) CHARACTER 8 APQLG_DS_LLRID Last log record ID
100 (64) UNSIGNED 4 APQLG_DS_LASTBLKSEQNO Last block seq number
104 (68) CHARACTER 8 APQLG_DS_UNITTYPE Unit type name
112 (70) UNSIGNED 2 APQLG_DS_FILESEQ File sequence no
114 (72) UNSIGNED 2 APQLG_DS_VOLCOUNT Number of volumes
116 (74) UNSIGNED 1 APQLG_DS_CKPTCOUNT Number of chkpts on DSN
117 (75) BIT(8) 1 APQLG_DS_CHKPTTYPES CHKPT types.
1... .... APQLG_DS_SIMPL SIMPLE checkpoint
.1.. .... APQLG_DS_SNAPQ SNAPQ checkpoint
..1. .... APQLG_DS_DUMPQ DUMPQ checkpoint
...1 .... APQLG_DS_PURGE PURGE checkpoint
.... 1... APQLG_DS_FREEZ FREEZE checkpoint
118 (76) UNSIGNED 2 * Reserved
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 48 APQLG_DSVOLUME Volume information
0 (0) UNSIGNED 4 APQLG_DSVOL_NEXT Offset to next volume
4 (4) CHARACTER 6 APQLG_DSVOL_SER VOLSER
10 (A) UNSIGNED 1 APQLG_DSVOL_CKPTCT Volume chkpt count
11 (B) CHARACTER 1 * Reserved
12 (C) CHARACTER 12 APQLG_DSVOL_ENDTIME Volume end time
24 (18) CHARACTER 12 APQLG_DSVOL_CPTID Checkpoint ID
36 (24) CHARACTER 6 APQLG_DSVOL_LOCKSN Lock Sequence Number
42 (2A) CHARACTER 6 * Reserved
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQLG APQLG_EYECATCHER
Figure 49. DSECT of DSPAPQLG (Part 2 of 2)
TYPE=LOG Output for LOGALL:

QUERY TYPE=LOG
|
| Figure 50. Format for QUERY TYPE=LOG Output for LOGALL
|
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 48 DSPAPQLA
0 (0) UNSIGNED 4 APQLA_DBDSAREAINFO
Offset to allocated
DBDS/Area list
16 (10) CHARACTER 12 APQLA_PRILOGTIME
PRILOG time
28 (1C) BIT(8) 1 APQLA_FLAGS Flags
1... .... APQLA_NONREGD
Non-registered DB updated
29 (1D) UNSIGNED 3 APQLA_DBDSAREACOUNT
Number of DBDS/Areas
allocated on this log
32 (20) UNSIGNED 4 APQLA_DBDSAREALEN
Length of DBDS/Area entry
36 (24) CHARACTER 12 APQLA_EARLIESTALLOC
Earliest ALLOC time for
this log
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 32 APQLA_DBDSAREA List of allocated DBDSs and
Areas
0 (0) CHARACTER 8 APQLA_DBNAME Database name
8 (8) CHARACTER 8 *
8 (8) CHARACTER 8 APQLA_DDNAME DD name or
8 (8) CHARACTER 8 APQLA_AREANAME
AREA name
16 (10) CHARACTER 12 APQLA_FIRSTALLOC
Earliest ALLOC time for this
DBDS/Area on this log
28 (1C) SIGNED 2 APQLA_ALLNO Number of ALLOCs for this
DBDS/Area on this log
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQLA APQLA_EYECATCHER
Figure 51. DSECT of DSPAPQLA

QUERY TYPE=OLDS
OLDS Query
The OLDS query (DSPAPI FUNC=QUERY TYPE=OLDS) request is used to retrieve
online log data set information from the RECON for a specific subsystem or all
subsystems.
Syntax for the TYPE=OLDS Query Request

| DSPAPI FUNC=QUERY TYPE=OLDS TOKEN=address
| name
| SSID=* MF=S
| OUTPUT=output
SSID=subsystem_ID MF=(S,list)
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

|
Parameters for the TYPE=OLDS Query Request

The following are the possible parameters for QUERY TYPE=OLDS.
TYPE=OLDS
Specifies that online log data set information is requested.
SSID=* | symbol | (2 - 12)
Specifies the subsystem name for the backout being queried. The default
(SSID=*) requests all of the OLDS information.
MF=S | L | M | E
parameter values.
block of a possible chain of OLDS information blocks. See “Output for the
TYPE=OLDS Query Request” on page 410 for a detailed description of the
could be built.

QUERY TYPE=OLDS
required.
| Return and Reason Codes for the TYPE=OLDS Query Request

| Table 24 contains most of the return and reason codes for TYPE=OLDS query
| Table 24. Return and Reason Codes for TYPE=OLDS Query Requests
| Warning
| X'00000008' X'D8500001' No PRIOLDS records exist.
| Severe Error
| Storage Error
| X'00000028' X'D8500001' Error obtaining storage for OLDS block.
| Internal Error
| information.
| Parameter Error

QUERY TYPE=OLDS
| Table 24. Return and Reason Codes for TYPE=OLDS Query Requests (continued)
| calling program.
| parameter.
|
| Output for the TYPE=OLDS Query Request

Figure 52 on page 411 illustrates the format of the output from a QUERY
TYPE=BACKOUT request. Figure 53 on page 412 is a sample DSECT describes in
detail the fields of the storage blocks and their relationship to each other.

QUERY TYPE=OLDS
|
| Figure 52. Format for QUERY TYPE=OLDS Output
|

QUERY TYPE=OLDS
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 48 DSPAPQOL
0 (0) UNSIGNED 4 APQOL_OLDSINFO
Offset to OLDS list
16 (10) CHARACTER 8 APQOL_SSID Subsystem ID
24 (18) UNSIGNED 2 APQOL_OLDSLEN Length of OLDS entry
26 (1A) SIGNED 2 APQOL_OLDSCOUNT
Number of OLDS entries
28 (1C) CHARACTER 12 APQOL_CHKPT0 Checkpoint 0 time
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 128 APQOL_OLDSENTRY
OLDS entry
0 (0) CHARACTER 8 APQOL_DDNAME the OLDS DD name
8 (8) CHARACTER 44 APQOL_DSNAM OLDS data set name
52 (34) CHARACTER 12 APQOL_OPENTIME
OLDS open time
64 (40) CHARACTER 12 APQOL_CLOSETIME
Close time
76 (4C) CHARACTER 12 APQOL_PRILOGTIME
Start time of associated
PRILOG
88 (58) CHARACTER 8 APQOL_FLSN LSN of first record in OLDS
96 (60) CHARACTER 8 APQOL_LLSN LSN of last record in OLDS
104 (68) BIT(8) 1 APQOL_FLAG1
1... .... APQOL_RSTBG Restart begin
.1.. .... APQOL_RSTEN Restart end
..1. .... APQOL_COLD Cold start
...1 .... APQOL_NOBMP ERE NOBMP
.... 1... APQOL_SAVER Backout UORs saved
.... .1.. APQOL_NOID Backouts not identified
.... ..1. APQOL_TRKNG OLDS created by tracking SS
105 (69) BIT(8) 1 APQOL_FLAG2 OLDS flags
1111 .... APQOL_STAT OLDS status
1... .... APQOL_INUSE OLDS is in use
.1.. .... APQOL_ARNED Archive needed
..1. .... APQOL_ARSCH Archive scheduled (GENJCL)
...1 .... APQOL_ARSTD Archive job started
.... 1... APQOL_CLERR Close error on OLDS
.... .1.. APQOL_FEOV Force EOV at archive
.... ..1. APQOL_DUMMY OLDS not used due to I/O err
.... ...1 APQOL_PRVCE Close error on previous OLDS
106 (6A) UNSIGNED 1 APQOL_RELVL Log release level
107 (6B) UNSIGNED 1 APQOL_GAVER GENJCL.ARCHIVE version
108 (6C) BIT(32) 4 APQOL_BLOCKSEQNO
Block sequence number
112 (70) CHARACTER 8 APQOL_ARJOB Name of the archive job
Generated by GENJCL.ARCHIVE
120 (78) CHARACTER 6 APQOL_LOCKSEQNO
Lock sequence number
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQOL APQOL_EYECATCHER
Figure 53. DSECT of DSPAPQOL

QUERY TYPE=RECON
RECON Status Query

The RECON status query (DSPAPI FUNC=QUERY TYPE=RECON) request is used
to retrieve information pertaining to the RECON data sets. This includes RECON
header information, as well as the status of each RECON data set.
Syntax for the TYPE=RECON Query Request

| DSPAPI FUNC=QUERY TYPE=RECON TOKEN=address
| name
| MF=S
| OUTPUT=output
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

|
Parameters for the TYPE=RECON Query Request

The following are the possible parameters for QUERY TYPE=RECON.
TYPE=RECON
Specifies that RECON status information is requested.
MF=S | L | M | E
parameter values.
Required parameter that specifies a field to receive a pointer to the RECON
status information block. See “Output for the TYPE=RECON Query
Request” on page 415 for a detailed description of the information blocks
returned.
could be built.

QUERY TYPE=RECON

required.
| Return and Reason Codes for the TYPE=RECON Query Request

| Table 25 contains most of the return and reason codes for TYPE=RECON queries.
| The other possible return and reason codes relate to DBRC, not the query request.
| For a list of these return and reason codes, see “DBRC Service Aids” in the IMS
| Version 9: Diagnosis Guide and Reference.
| Table 25. Return and Reason Codes for TYPE=RECON Queries
| Severe Error
| Storage Error
| X'00000028' X'D8100001' Error obtaining storage for the RECON block.
| Internal Error
| information.
| Parameter Error

QUERY TYPE=RECON
| Table 25. Return and Reason Codes for TYPE=RECON Queries (continued)
| parameter.
|
| Output for the TYPE=RECON Query Request

Figure 54 illustrates the format of the output from a QUERY TYPE=RECON
request. Figure 55 on page 416 is a sample DSECT describes in detail the fields of
the storage blocks and their relationship to each other.
|
| Figure 54. Format for QUERY TYPE=RECON Output
|

QUERY TYPE=RECON
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 560 DSPAPQRC
0 (0) CHARACTER 44 APQRC_DATA Initialized with "RECOVERY
CONTROL DATASET"
44 (2C) UNSIGNED 4 APQRC_RECONINFO Offset to RECON data set
info
56 (38) UNSIGNED 2 APQAR_RECONINFOLEN Length of each RECON dataset info element
58 (3A) UNSIGNED 1 APQRC_RECONCOUNT # of RECON dataset elements
59 (3B) CHARACTER 1 * Reserved
60 (3C) BIT(8) 1 APQRC_FLAGS Process flags...
1... .... APQRC_NOCHK 1= NOCHECK log tape dsn check
.1.. .... APQRC_CHK17 1= CHECK17 log tape dsn check
..1. .... APQRC_CHK44 1= CHECK44 log tape dsn check
...1 .... APQRC_LSTLG 1= list log DSN
.... 1... APQRC_INUPG Upgrade in progress.
61 (3D) BIT(8) 1 APQRC_FLAG2 More flags...
1... .... APQRC_FORCE 1 = FORCER, 0 = NOFORCER
.1.. .... APQRC_CATDS 1=CA|IC|LOGS cataloged
..1. .... APQRC_TRACE 1 = ext. GTF trace on
...1 .... APQRC_CMDSAF SAF enabled
.... 1... APQRC_CMDEXIT Cmd auth exit enabled
64 (40) CHARACTER 136 APQRC_CLEAN Fields needed for cleanup
64 (40) SIGNED 4 APQRC_CSET 0 = updates not in progress,
>0 = update in progress
68 (44) SIGNED 4 APQRC_TYPE Type of update
72 (48) CHARACTER 32 APQRC_OKEY Key of original record
104 (68) CHARACTER 32 APQRC_BKEY Key of base record that is in
the process of being changed
136 (88) CHARACTER 32 APQRC_NKEY Key of new record
168 (A8) CHARACTER 16 APQRC_DBID DBID of DBDS
168 (A8) CHARACTER 8 APQRC_DBD DBD name
176 (B0) CHARACTER 8 APQRC_DDN DD name
184 (B8) CHARACTER 8 APQRC_CAGRP CA group name
192 (C0) CHARACTER 8 APQRC_DDNEW New DBDS DD name
200 (C8) UNSIGNED 2 APQRC_DMBNO DMB sequence number
202 (CA) UNSIGNED 2 APQRC_LASTREUSEDDMB# Last reused DMB number, valid
only when apqrc_DMBNO is 32767
204 (CC) CHARACTER 7 APQRC_INITTOKEN Recon init. token
211 (D3) CHARACTER 8 APQRC_CMDHLQ Cmd auth high lvl qual
219 (DB) UNSIGNED 1 APQRC_MVERS Minimum IMS version
220 (DC) BIT(8) 1 APQRC_NWFLG Fields needed for RECON I/O
error(s)
Figure 55. DSECT of DSPAPQRC (Part 1 of 2)

QUERY TYPE=SUBSYS
1... .... APQRC_NEW 1=STARTNEW, 0=NONEW

221 (DD) CHARACTER 3 * Reserved
224 (E0) CHARACTER 8 APQRC_SSIDN SSID for DASD
232 (E8) CHARACTER 8 APQRC_DASDU Unit type for DASD
240 (F0) CHARACTER 8 APQRC_TAPEU Unit type for tape
248 (F8) CHARACTER 24 APQRC_TIME
248 (F8) CHARACTER 2 APQRC_TZDEF Input offset default
250 (FA) CHARACTER 5 APQRC_TMFMT Time format options
255 (FF) CHARACTER 1 * Reserved
256 (100) SIGNED 2 APQRC_TPREC Time-stamp precision
258 (102) CHARACTER 12 APQRC_LOGRT Minimum log retention period
270 (10E) SIGNED 2 APQRC_TZNUM Number of entries in time zone label table
272 (110) CHARACTER 8 APQRC_TZTBL(32) Time zone label table
528 (210) BIT(16) 2 APQRC_TROPT DBRC trace options
530 (212) CHARACTER 5 APQRC_IMSPLEX IMSplex name
540 (21C) UNSIGNED 4 APQRC_SIZW_DSNUM SIZEALERT dsnum
544 (220) UNSIGNED 4 APQRC_SIZW_VOLNUM SIZEALERT volnum
548 (224) UNSIGNED 4 APQRC_SIZW_PERCENT SIZEALERT percent
552 (228) UNSIGNED 4 APQRC_LOGW_DSNUM LOGALERT dsnum
556 (22C) UNSIGNED 4 APQRC_LOGW_VOLNUM LOGALERT volnum
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 53 APQRC_RECONDS_INFO
0 (0) CHARACTER 8 APQRC_RECONDS_DDNAME RECON DD name
8 (8) CHARACTER 44 APQRC_RECONDS_DSNAME RECON DS name
52 (34) BIT(8) 1 APQRC_RECONDS_STATUS RECON DS status
1... .... APQRC_RECONDS_COPY1 COPY 1
.1.. .... APQRC_RECONDS_COPY2 COPY 2
..1. .... APQRC_RECONDS_SPARE Spare
...1 .... APQRC_RECONDS_DISCARDED Discarded
.... 1... APQRC_RECONDS_UNAVAIL Unavailable
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQRC APQRC_EYECATCHER
Figure 55. DSECT of DSPAPQRC (Part 2 of 2)
Subsystem Query
The Subsystem query (DSPAPI FUNC=QUERY TYPE=SUBSYS) request is used to
retrieve subsystem information from the RECON for a specific subsystem or all
subsystems.
Syntax for the TYPE=SUBSYS Query Request

| DSPAPI FUNC=QUERY TYPE=SUBSYS TOKEN=address
| name

QUERY TYPE=SUBSYS
| SSTYPE=ALL
TRACKER=NO
SSTYPE=ONLINE
SSTYPE=BATCH
SSID=*
TRACKER=YES

TRACKER=NO
SSID=subsystem_ID
TRACKER=YES
| MF=S
OUTPUT=output
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

Parameters for the TYPE=SUBSYS Query Request

The following are the possible parameters for QUERY TYPE=SUBSYS.
TYPE=SUBSYS
Specifies that subsystem information is requested.
SSID=* | symbol | (2 - 12)
Specifies the name of the subsystem being queried. The default (SSID=*)
requests information about all of the subsystems..
| SSYTYPE=ONLINE | BATCH | ALL
Optional parameter that specifies the type of subsystem for which
information is being requested. You cannot specify this parameter
if you also specify a specific subsystem name for the SSID
parameter or if you specify TRACKER=YES. SSTYPE=ALL is the
default.
| TRACKER=YES |NO
| Optional parameter that specifies whether log information is being

QUERY TYPE=SUBSYS
| requested for an RSR tracking subsystem. Specify TRACKER=YES

| to request the RSR tracker’s log information. Specify
| TRACKER=NO to request log information from a non-RSR
| subsystem or an active subsystem of an RSR system.
| TRACKER=NO is the default.
MF=S | L | M | E
parameter values.
block of a possible chain of subsystem information blocks. See “Output for
the TYPE=SUBSYS Query Request” on page 421 for a detailed description
of the information blocks returned.
could be built.
required.
| Return and Reason Codes for the TYPE=SUBSYS Query Request

| Table 26 contains most of the return and reason codes for TYPE=SUBSYS query
| Table 26. Return and Reason Codes for TYPE=SUBSYS Query Requests

QUERY TYPE=SUBSYS
| Table 26. Return and Reason Codes for TYPE=SUBSYS Query Requests (continued)
| Warning
| X'00000008' X'D8600001' No subsystem record of the requested type, active
| or tracker, exists.
| X'00000008' X'D8600002' No batch or online subsystem records exist.
| Severe Error
| Storage Error
| X'00000028' X'D8600001' Error obtaining storage for SUBSYS block.
| Internal Error
| information.
| Parameter Error
| calling program.
| parameter.
| X'00000030' X'D8600001' Parameter error. SSTYPE=ONLINE or BATCH can
| not be specified on requests for a specific SSID or
| for a tracking subsystem request
| (TRACKER=YES).
|

QUERY TYPE=SUBSYS
| Output for the TYPE=SUBSYS Query Request

| Figure 56 illustrates the format of the output from a QUERY TYPE=SUBSYS
| request. Figure 57 is a sample DSECT describes in detail the fields of the storage
| blocks and their relationship to each other.
|
| Figure 56. Format for QUERY TYPE=SUBSYS Output
|
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 64 DSPAPQSS
0 (0) CHARACTER 8 APQSS_SSID Subsystem identifier
8 (8) UNSIGNED 4 APQSS_AUTHLIST Offset to authd DB/Area list
12 (C) SIGNED 4 APQSS_AUTHCOUNT Number of authorized DB/Areas
16 (10) UNSIGNED 2 APQSS_AUTHLEN Length of auth entry
24 (18) CHARACTER 12 APQSS_LOGTIME Start time of log
36 (24) UNSIGNED 1 APQSS_RELLVL Subsystem release level
'71'X=V7R1,'81'X=V8R1
'91'X=V9R1, etc.
37 (25) CHARACTER 1 APQSS_COEXLVL Coexistence level
38 (26) UNSIGNED 1 APQSS_IRLMCT IRLM status count
40 (28) CHARACTER 8 APQSS_GSGNAME Global Service Group name
48 (30) CHARACTER 5 APQSS_IRLMID IRLM ID of SS
53 (35) CHARACTER 5 APQSS_IRLMBK IRLM ID of backup SS
58 (3A) BIT(8) 1 APQSS_FLAGS Flags
1... .... APQSS_TYPE 1=Online | 0=batch
.1.. .... APQSS_ABTERM Abnormal termination
..1. .... APQSS_RCVPRC Recovery processing started
...1 .... APQSS_BKSIGN Backup SS signed on
.... 1... APQSS_IRLMFL IRLM failure
.... .1.. APQSS_COMMFL COMM failure
.... ..1. APQSS_SYSFL SYS failure
.... ...1 APQSS_ACTVST Status of active SS when backup exists, 1=abterm
59 (3B) BIT(8) 1 APQSS_FLAGS2 FLAGS 2
1... .... APQSS_SHRING Sharing covered DBs
.1.. .... APQSS_TRKER Subsystem is a Tracker
..1. .... APQSS_TRKTRM TRACKER has terminated
...1 .... APQSS_TRCKED SSID is tracked
.... 1... APQSS_FRSTSO 1ST signon after RSR takeover is in progress
.... .1.. APQSS_XRFCAP SS is XRF capable
.... ..11 * Reserved
60 (3C) SIGNED 2 APQSS_BCKTKN Backup recovery token
Figure 57. DSECT of DSPAPQSS (Part 1 of 2)

QUERY TYPE=SUBSYS
OFFSET OFFSET
======== ======== ========= ======== ============== ===============================
0 (0) STRUCTURE 32 APQSS_AUTHNAME Names of authd DB/Areas
0 (0) CHARACTER 8 APQSS_DBNAME DB name
8 (8) CHARACTER 8 APQSS_AREANM If FP, Area name
16 (10) UNSIGNED 1 APQSS_SHRLVL Share level
17 (11) UNSIGNED 1 APQSS_DBACCS Access intent
18 (12) UNSIGNED 1 APQSS_DBNCOD Encoded state
19 (13) UNSIGNED 1 APQSS_DBSTAT DB status flags
20 (14) UNSIGNED 2 APQSS_DBEQCT DB EQE count
22 (16) SIGNED 2 APQSS_GLBDMB Global DMB number
24 (18) BIT(8) 1 APQSS_AUTHFLAGS Flags
1... .... APQSS_NRDBUP Nonrecov DB/Area updated
.1.. .... APQSS_COVRD DB covered by GSG
..1. .... APQSS_NRECV Non-recoverable DB/Area
...1 .... APQSS_ORDBDS 0=A-J/1=M-V ACTIVE
.... 1... APQSS_OLRON 0 = no OLR active
.... .1.. APQSS_OLROWR 0 = no OLR owner
.... ..1. APQSS_OLROWD 0 OLR not owned by SS
CONSTANTS

===== ========= ================= =============== ===============================
8 CHARACTER DSPAPQSS APQSS_EYECATCHER
Figure 57. DSECT of DSPAPQSS (Part 2 of 2)

|
| Chapter 18. DBRC Release Buffer Request

| Use the DBRC release buffer request (DSPAPI FUNC=RELBUF) to release storage
| that was acquired as a result of a DBRC query request. The query request returns a
| chain of one or more blocks containing the requested information. It is the caller’s
| responsibility to ensure that the storage DBRC allocated for these blocks is freed.
| In This Chapter:
| v “RELBUF Request”
|
| RELBUF Request
| “RELBUF Usage” contains the details for the release buffer request.
| RELBUF Usage
| Syntax for the RELBUF Request
| DSPAPI FUNC=RELBUF TOKEN=address BUFFER=buffer
| name
| MF=S
|
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
| VERSION=1.0
|
|
| Parameters for the RELBUF Request

| The following are the possible parameters for RELBUF.
| name Optional symbol you can specify. If used, begins in column 1.
| TOKEN=symbol | (2 - 12)
| Required parameter that specifies the address of a 4-byte field that was
| returned on the FUNC=STARTDBRC request.
| BUFFER=symbol | (2 - 12)
| Required parameter that specifies a field containing the address of the first
| block of a chain of one or more information blocks to release. This storage
| was acquired by DBRC in order to satisfy another DBRC request.
| RETCODE=symbol | (2 - 12)
| Optional parameter that specifies a place in storage to receive the return
| code. If specified as a symbol, the symbol must be the label of a word of

RELBUF
| storage. If specified as a register, the register must contain the address of a

| word of storage. If not specified, the return code is placed in register 15.
| RSNCODE=symbol | (2 - 12)
| Optional parameter that specifies a place in storage to receive the reason
| word of storage. If not specified, the reason code is placed in register 0.
| MF=S | L | M | E
| Optional parameter that specifies the macro form of the request. See
| “Macro Forms of the DSPAPI Macro” on page 356 for the details of the
| parameter values.
| VERSION=1.0 | number
| Optional parameter that specifies the version number of the parameter list
| to be generated by this request.
| To use the parameters associated with a version, you must specify the
| number of that version or a later version. If you specify an earlier version
| level, the parameter is not accepted for processing and an error message is
| issued at assembly time. If parameters have a version dependency, the
| parameter descriptions with each request type identify the version number
| required.
| The default version is 1.0.
| Return and Reason Codes for RELBUF

| Table 27 contains the return and reason codes for the RELBUF request.
| Table 27. Return and Reason Codes for RELBUF
| Partial Success
| X'00000004' X'D9000001' There was no storage to free. An address of zero
| was passed in the BUFFER parameter.
| Severe Error
| Storage Error
| X'00000028' X'D9100001' An error occurred attempting to release storage.
| Parameter Error
| X'00000030' X'C9000001' Parameter error. The function (FUNC) specified
| in the parameter list passed to the API is invalid.
| checking. The address specifies storage not
| owned by the calling program.

RELBUF
| Table 27. Return and Reason Codes for RELBUF (continued)

| X'00000030' X'C9000007' Invalid BUFFER address. The address of the
| BUFFER to be released failed validity checking.
| calling program.
| X'00000030' X'D9100001' The header of a storage block to be freed is
| invalid.
| X'00000030' X'D9100002' The length of a storage block to be freed is not
| greater than zero.
|
|
Chapter 18. DBRC Release Buffer Request 425

|
| Chapter 19. DBRC Start Request

| Use the DBRC start request (STARTDBRC) to initialize the DBRC API and to start
| DBRC.
| In This Chapter:
| v “STARTDBRC Request”
|
| STARTDBRC Request
| “STARTDBRC Usage” contains the details for the DBRC start request.
| STARTDBRC Usage
| Syntax for the STARTDBRC Request
| DSPAPI FUNC=STARTDBRC
| name SYSPRINT=ddname
| MF=S
|
MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
| VERSION=1.0
|
|
| Parameters for STARTDBRC

| The following are the possible parameters for STARTDBRC.
| name Optional symbol you can specify. If used, begins in column 1.
| TOKEN=symbol | (2 - 12)
| Required parameter that specifies the address of a 4-byte field to receive
| the API token. This token must be included in all subsequent requests
| associated with this STARTDBRC request.
| SYSPRINT= symbol | (2 - 12)
| Optional parameter that specifies the DDname of an output data set to be
| used for messages. If omitted, the default name SYSPRINT is used.
| RETCODE=symbol | (2 - 12)
| Optional parameter that specifies a place in storage to receive the return
| word of storage. If not specified, the return code is placed in register 15.

STARTDBRC
| RSNCODE=symbol | (2 - 12)
| Optional parameter that specifies a place in storage to receive the reason
| word of storage. If not specified, the reason code is placed in register 0.
| MF=S | L | M | E
| Optional parameter that specifies the macro form of the request. See
| “Macro Forms of the DSPAPI Macro” on page 356 for the details of the
| parameter values.
| VERSION=1.0 | number
| Optional parameter that specifies the version number of the parameter list
| to be generated by this request.
| To use the parameters associated with a version, you must specify the
| number of that version or a later version. If you specify an earlier version
| level, the parameter is not accepted for processing and an error message is
| issued at assembly time. If parameters have a version dependency, the
| parameter descriptions with each request type identify the version number
| required.
| The default version is 1.0.
| Return and Reason Codes for STARTDBRC

| Table 28 contains most of the return and reason codes for the STARTDBRC request.
| The other possible return and reason codes relate to DBRC, not the request. For a
| list of these return and reason codes, see “DBRC Service Aids” in the IMS Version
| 9: Diagnosis Guide and Reference.
| Table 28. Return and Reason Codes for the STARTDBRC Request
| Severe Error
| X'0000000C' X'C9000002' DBRC could not successfully initialize during
| phase 0 of DBRC initialization
| X'0000000C' X'C9000003' DBRC could not successfully initialize during
| phase 1 of DBRC initialization.
| X'0000000C' X'C9000004' A z/OS LOAD failed for the DBRC module
| DSPCRTR0.
| X'0000000C' X'C9000005' STORAGE request failure. The API cannot obtain
| storage necessary to complete the request.
| X'0000000C' X'C9000012' STARTDBRC has been previously issued without
| an intervening STOPDBRC.
| Parameter Error
| X'00000030' X'C9000001' Parameter error. The function (FUNC) specified
| in the parameter list passed to the API is invalid.
| field to contain the API TOKEN failed validity
| checking. The address specifies storage not
| owned by the calling program.

STARTDBRC
| Table 28. Return and Reason Codes for the STARTDBRC Request (continued)
| X'00000030' X'C9000006' Invalid SYSPRINT field address. The address of
| the field containing the SYSPRINT DD name
| failed validity checking. The address specifies
| storage not owned by the calling program.
|
Chapter 19. DBRC Start Request 429

STARTDBRC

|
Chapter 20. DBRC Stop Request

Use the DBRC stop request (STOPDBRC) to terminate the DBRC API and to stop
DBRC.
In This Chapter:
v “STOPDBRC Request”
STOPDBRC Request
“STOPDBRC Usage” contains the details for the release buffer request.
STOPDBRC Usage
Syntax for the STOPDBRC Request
DSPAPI FUNC=STOPDBRC TOKEN=address
name
| MF=S

MF=(L,list)
,COMPLETE
MF=(M,list )
,NOCHECK
,COMPLETE
MF=(E,list )
,NOCHECK
VERSION=1.0

Parameters for STOPDBRC

The following are the possible parameters for STOPDBRC.

STOPDBRC
MF=S | L | M | E
parameter values.
required.
Return and Reason Codes for STOPDBRC

Table 29 contains the return and reason codes for the STOPDBRC request. The
other possible return and reason codes relate to DBRC, not the request. For a list of
these return and reason codes, see “DBRC Service Aids” in the IMS Version 9:
Diagnosis Guide and Reference.
Table 29. Return and Reason Codes for the STOPDBRC Request
Return Codes Reason Codes Meaning
X'00000000' X'00000000' Request completed successfully.
Severe Error
X'0000000C' X'C9000001' Invalid TOKEN. The TOKEN block passed to the
API is not recognized as a TOKEN created by a
FUNC=STARTDBRC call.
Parameter Error
X'00000030' X'C9000001' Parameter error. The function (FUNC) specified
in the parameter list passed to the API is invalid.
X'00000030' X'C9000002' Invalid TOKEN field address. The address of the
field containing the API TOKEN failed validity
checking. The address specifies storage not
owned by the calling program.
X'00000030' X'C9000003' Invalid RETCODE field address. The address of
the field to contain the API RETCODE failed
validity checking. The address specifies storage
not owned by the calling program.
X'00000030' X'C9000004' Invalid RSNCODE field address. The address of
the field to contain the API RSNCODE failed
validity checking. The address specifies storage
not owned by the calling program.

Part 4. Appendixes

Appendix A. Symbolic Keywords Recognized by DBRC
Table 30 through Table 36 on page 442 show the symbolic keywords that DBRC
recognizes in the IBM-supplied skeletal JCL execution members.
Table 30 shows the keywords that all supported utilities recognize.
Table 31 on page 436 through Table 36 on page 442 show the keywords that each
individual utility recognizes.
These tables and the figures in “IBM-Supplied Skeletal JCL Execution Members” on
page 443 are presented in alphabetical order of the GENJCL commands:
v GENJCL.ARCHIVE, which generates JCL for the Log Archive utility. See “Log
Archive Utility (ARCHJCL)” on page 436 for a list of the symbolic keywords
supported by the utility and see “GENJCL.ARCHIVE” on page 221 for details
using the command.
v GENJCL.CA, which generates JCL for the Database Change Accumulation utility.
See “Database Change Accumulation Utility (CAJCL)” on page 437 for a list of
the symbolic keywords supported by the utility and see “GENJCL.CA” on page
225 for details of the command usage.
v GENJCL.CLOSE, which generates JCL for the Log Recovery utility. See “Log
Recovery Utility (LOGCLJCL)” on page 438 for a list of the symbolic keywords
supported by the utility and see “GENJCL.CLOSE” on page 229 for details of
the command usage.
v GENJCL.IC and GENJCL.OIC, which generates JCL for the Database Image Copy
utilities. See “Database Image Copy Utility, Database Image Copy Utility 2, and
Online Database Image Copy Utility (ICJCL and OICJCL)” on page 438 for a list
of the symbolic keywords supported by the utilities and see “GENJCL.IC” on
page 233 and “GENJCL.OIC” on page 242 for details of the commands usage.
v GENJCL.RECEIVE, which generates JCL for the Database Recovery utility. See
“Database Recovery Utility- Receive (ICRCVJCL)” on page 440 for a list of the
symbolic keywords supported by the utility and see “GENJCL.RECEIVE” on
page 247 for details of the command usage.)
v GENJCL.RECOV, which also generates JCL for the Database Recovery utility. See
“Database Recovery Utility-Recovery (RECOVJCL)” on page 442 for a list of the
symbolic keywords supported by the utility and see “GENJCL.RECOV” on page
251 for details of the command usage.)
All Supported Utilities

Table 30 explains the symbolic keywords recognized by all the supported utilities.
Table 30. Symbolic Keywords for All Supported Utilities
Keyword Description
%RCNDSN1 Name of the RECON1 data set if RECONs are allocated by JCL. Set to null if RECONs are
dynamically allocated.

Symbolic Keywords
Table 30. Symbolic Keywords for All Supported Utilities (continued)

Keyword Description
%STPNO The current step number. The step number is set to 0 if the JOB parameter was specified on the
GENJCL command. The step number is increased by 1 when DBRC first encounters it in a skeletal
JCL execution member. The step number remains at that value while the execution member is
processed. As the keyword is encountered in the remaining skeletal JCL, the current value is
substituted.
The JCL execution member can be processed again because of a multi-step generation, or because
the subsequent GENJCL command specifies NOJOB. When it is processed again the step number is
increased by 1 from its current value when the keyword is first encountered in the next skeletal
JCL execution member. This increase takes place before the keyword value is substituted.
%TIME The time of day, in the form hhmmss.
%GRPINDX The DBDS group member index. This keyword is set only when a DBDS group is specified,
implicitly or explicitly, on the GENJCL command. (A DBDS group can be specified on the
GENJCL.IC, GENJCL.OIC, GENJCL.RECOV, and GENJCL.USER commands.)
When you specify a DBDS group, the keyword is initialized to 1. It is then increased by 1 as each
successive group member is processed.
%CNTR A counter controlled by DBRC. The counter is set to 0 whenever the first GENJCL command is
issued or a JOB statement is reproduced from the skeletal JCL execution member JOBJCL. DBRC
increases the counter by 1 each time the keyword is encountered in a skeletal JCL execution
member.
The JCL execution member can be processed again because of a multi-step generation, or because
the subsequent GENJCL command specifies NOJOB. If so, the counter continues to increase from its
current value when the keyword is encountered in next skeletal JCL execution member. This
increase takes place 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 31 explains the symbolic keywords recognized by the Log Archive utility.
Table 31. Symbolic Keywords for Log Archive Utility
Keyword Description
%SSID The subsystem ID, which is set from the SSID parameter on the GENJCL.ARCHIVE command. If the
SSID parameter is not specified, the default subsystem ID is used. The default subsystem ID is set
by you in the INIT.RECON or CHANGE.RECON command. If no default subsystem ID was specified,
the command fails.
%DDNAMES The ddnames of the OLDSs that are to be archived. If ALL is specified or used as the default on the
GENJCL.ARCHIVE command, the ddnames of all unarchived OLDSs are determined from RECON.
Otherwise, the ddnames specified 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.
%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

Symbolic Keywords
Table 31. Symbolic Keywords for Log Archive Utility (continued)

Keyword Description
%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 32 explains the symbolic keywords recognized by the Database Change
Accumulation utility.
Table 32. 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 accumulation data set is used,
%DSLLGTM is set to the volume stop time of the last-accumulated log volume.
%CAODSN The data set name of the input change accumulation data set. This keyword is set to null if no
existing change accumulation data set is defined in RECON for the CA group.
%CAOUNIT The unit type of the input change accumulation data set. This keyword is set to null if no existing
change accumulation data set is defined in RECON for the CA group.
%CAOVOLS The volume serial number list of the input change accumulation data set. This keyword is set to
null if there is no existing change accumulation data set is defined in RECON for the CA group.
%CAOFSEQ The file sequence number of the input change accumulation data set. This keyword is set to null if
no existing change accumulation data set is defined in RECON for the CA group.
%CANDSN The data set name of the output change accumulation data set. If REUSE is specified for the CA
group, the keyword is set from information in RECON. If NOREUSE is specified, DBRC generates a
data set name. The generated name is:
IMS.cagrpname.CA.CAhhmmss
where cagrpname is the CA group name, and hhmmss is the current time of day.
%CANUNIT The unit type of the output change accumulation data set. If REUSE is specified for the CA group,
the keyword is set from information in RECON. If NOREUSE is specified, this keyword is set from
the UNIT parameter on the GENJCL.CA command. If UNIT is not specified, the keyword is set to 3400.
%CANVCNT The number of volumes in the output change accumulation data set. If REUSE is 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 the GENJCL.CA command.
%CANVOLS The volume serial number list of the output change accumulation data set. If REUSE is 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 the GENJCL.CA command.
Appendix A. Symbolic Keywords Recognized by DBRC 437

Symbolic Keywords
Table 32. Symbolic Keywords for Database Change Accumulation Utility (continued)
Keyword Description
%CABFSEQ The file sequence number of the output change accumulation data set. If REUSE is specified for the
CA group, the keyword is set from information in RECON. 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 Change Accumulation utility.
Note: %CADB0 always generates DB0 control statements with the time stamps in UTC format
(indicated by an offset of zeroes).
Log Recovery Utility (LOGCLJCL)

Table 33 explains the symbolic keywords recognized by the Log Recovery utility.
Table 33. Symbolic Keywords for Log Recovery Utility
Keyword Description
%SSID The subsystem ID, which is set from the SSID parameter on the GENJCL.CLOSE command. If the
SSID parameter is not specified, the default subsystem ID is used. The default subsystem ID is set
by you in the INIT.RECON or CHANGE.RECON command. If no default subsystem ID is specified, the
command fails.
%CDDNAME The ddname of the OLDS to be closed. This keyword is set from the OLDS parameter on the
GENJCL.CLOSE command. If GENJCL.CLOSE did not specify an OLDS, 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 set to NO, this keyword is
set to the ddname of the OLDS used immediately after the 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 by providing a last
block sequence number for base point information.
Database Image Copy Utility, Database Image Copy Utility 2, and

Online Database Image Copy Utility (ICJCL and OICJCL)
Table 34 explains the symbolic keywords recognized by the Database Image Copy
utilities.
Table 34. Symbolic Keywords for Database Image Copy Utilities
Keyword Description
%PSB The PSB name, which is set from the PSB parameter on the GENJCL command. This keyword is
applicable only for the Database Online Image Copy utility.

Symbolic Keywords
Table 34. Symbolic Keywords for Database Image Copy Utilities (continued)
Keyword Description
%DBNAME The database name, which is set from the DBD parameter on the GENJCL command.
%DBDDN The DBDS ddname, which is set from the DDN parameter on the GENJCL command.
%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 is applicable only for the
Database Image Copy utility.
%DBADSAV For DEDBs, set to AVAIL if RECON indicates that the ADS is available, or UNAVAIL if the ADS is
unavailable. For other types of databases, this keyword is set 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 or 2 from the COPIES
parameter on the GENJCL command.
%MDBNAME The HALDB master name, if this is a DBDS of a HALDB partition. This keyword is set to NULL for
non-HALDBs.
%SMS Indicates whether a Database Image Copy 2 (DFSUMDT0) image copy data set is being used for the
requested utility execution. If used, the keyword is set to 1; otherwise, the keyword is set to 0.
%ICDDN1, The DD name of the first image copy data set. If multiple image copy data sets are produced,
%ICDDN2, %ICDDN2, %ICDDN3, and %ICDDN4 are similarly set.
%ICDDN3,
%ICDDN4
%ICSYSIN The Database Image Copy utility control statement. Columns in the statement are set 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 is produced.
40-43 Checkpoint interval (applicable only for Online Database Image Copy utility).
All other columns are set to blanks.
%ICDSN1, The data set name of the image copy data set is %ICDSN1.
%ICDSN2,
%ICDSN3, If NOREUSE is specified for the DBDS, DBRC generates the following data set name:
%ICDSN4 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 Sameds is specified for a group of DBDSs, DBRC generates the following data set name:
IMSVS.GROUP.grpname.IC.IChhmmss
where :
v grpname is the name specified in the GROUP or DBD parameter
v hhmmss is the current time of day
If multiple image copy data sets are to be produced, %ICDSN3, or %ICDSN4 are set similarly.

Symbolic Keywords
Table 34. Symbolic Keywords for Database Image Copy Utilities (continued)
Keyword Description
%ICUNIT1, The unit type of the image copy data set. If NOREUSE is specified for the DBDS, %ICUNIT1 is set from
%ICUNIT2, the UNIT parameter on the command. If multiple image copy data sets are to be produced, %ICUNIT2,
%ICUNIT3, %ICUNIT3, or %ICUNIT4 are set similarly.
%ICUNIT4
%ICFSEQ1, The file sequence number of the image copy data set. If NOREUSE is specified for the DBDS, %ICFSEQ1 is
%ICFSEQ2, set to 1. If multiple image copy data sets are to be produced, %ICFSEQ2, %ICFSEQ3, or %ICFSEQ4 are
%ICFSEQ3, set similarly.
%ICFSEQ4
%ICVOLS1, The volume serial number of the image copy data set. If NOREUSE is specified for the DBDS, %ICVOLS1
%ICVOLS2, is set from the VOLLIST parameter on the command. If multiple image copy data sets are to be
%ICVOLS3, produced, %ICVOLS2, %ICVOLS3, or %ICVOLS4 are set similarly.
%ICVOLS4
%ICVCNT1, The number of volumes of the image copy data set. If NOREUSE is specified for the DBDS, %ICVCNT1 is
%ICVCNT2, set to the number of volumes specified on the VOLLIST parameter on the command. If multiple image
%ICVCNT3, copy data sets are to be produced, %ICVCNT2, %ICVCNT3, or %ICVCNT4 is set similarly.
%ICVCNT4
%SMSGRP A numeric value indicating the status of group processing:
Column Setting
0 One job step is being generated for each DBDS and/or area.
Otherwise a single job is being generated to copy multiple DBDSs and/or areas
(Image Copy 2, GROUP or DB without DDN, and ONEJOB were specified). This
means that the skeletal JCL member will be processed more than once per job step
generated.
1 Processing the only member of the group
2 Processing the first of multiple members
3 Processing an intermediate member
4 Processing the last member
%SMS1DS A numeric value indicating whether Sameds was specified:
Column Setting
0 Sameds was not specified
1 Sameds was specified
%GROUP A character value containing the value of the GROUP parameter, or the value of the DBD parameter
if DDn was omitted (an implied group)--otherwise null.
Database Recovery Utility- Receive (ICRCVJCL)

Table 35 explains the symbolic keywords recognized by the Database Recovery
(Receive) utility.
Table 35. Symbolic Keywords for Database Recovery (Receive) Utility
Keyword Description
%DBNAME The database name of the DBDS to be covered. %DBNAME is set from the DBD parameter on the
GENJCL.RECEIVE command.
%DBDDN The ddname of the DBDS, %DBDDN is set from the DDN parameter on the GENJCL.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.

Symbolic Keywords
Table 35. Symbolic Keywords for Database Recovery (Receive) Utility (continued)
Keyword Description
%DBUSID The update set identifier for the DBDS.
%ALLUSID The update set identifier of the most-recent ALLOC record for the DBDS.
non-HALDBs.
%DSLLGTM is set to the volume stop time of the last-accumulated log volume. Otherwise, the
keyword value is set to image copy time.
%ICDSN The data set name of the image copy data set. Set to null if the USEDBDS parameter is specified on
the GENJCL.RECEIVE command. Otherwise, set from the image copy record for the DBDS.
%ICUNIT The unit type of the image copy data set. Set to null if the USEDBDS parameter is specified on the
GENJCL.RECEIVE command. Otherwise, set from the image copy record for the DBDS.
%ICVOLS The volume serial number list of the image copy data set. Set to null if the USEDBDS parameter is
specified on the GENJCL.RECEIVE command. Otherwise set from the image copy record for the
DBDS.
%ICFSEQ The file sequence number of the image copy data set. Set to null if the USEDBDS parameter is
specified on the GENJCL.RECEIVE command. Otherwise, set from the image 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 change accumulation is
available for the DBDS. Otherwise, set from the change accumulation record.
%CAUNIT The unit type of the change accumulation data set. Set to null if no change accumulation is
%CAVOLS The volume serial number list of the change accumulation data set. Set to null if no change
accumulation is available for the DBDS. Otherwise, set from the change accumulation record.
%CAFSEQ The file sequence number of the change accumulation data set. Set to null if no change
%OLDFLRID The log record sequence number (log record ID) of the first log record in the OLDS.
%OLDLLRID The log record sequence number (log record ID) of the last log record in the OLDS. 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 the SLDS.
%SLDFSEQ The file sequence number of the SLDS.
%SLDLLRID The log record sequence number (log record ID) of the last log record in the SLDS. 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 a tracking 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 IMS subsystem.
%SLDUNIT Set to null if the SLDS data was created by an active IMS subsystem at a tracking 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 a tracking 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 an active IMS
subsystem at a tracking site. RLDSs received from an active site are always cataloged.
%LOGVOLS The volume serial numbers of the log data set. Set to null if the RLDS data was created by an
active IMS subsystem at a tracking site. RLDSs received from an active site are always cataloged.

Symbolic Keywords
Table 35. Symbolic Keywords for Database Recovery (Receive) Utility (continued)
Keyword Description
%LOGSEL Set to YES if any log data sets are selected by the select group; in this case, the delete group
following the select group is deleted. Otherwise, the %LOGSEL keyword 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 the RLDS.
%LOGLLRID The log record sequence number (log record ID) of the last log record in the RLDS. 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 a tracking 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 IMS subsystem.
%RVSYSIN The Database Recovery utility control statement. Columns in the statement are set as follows:
Column Setting
1 S
4-11 Database name
13-20 Data set or area ddname
22-29 DFSUDUMP
Database Recovery Utility-Recovery (RECOVJCL)

Table 36 explains the symbolic keywords recognized by the Database Recovery
(Recover) utility.
Table 36. Symbolic Keywords for Database Recovery Utility - Recovery (RECOVJCL)
Keyword Description
| %DBNAME The database name of the DBDS to be recovered. %DBNAME is set from the DBD parameter on the
GENJCL.RECOV command.
%DBDDN The ddname of the DBDS; %DBDDN is set from the DDN parameter on the GENJCL.RECOV command.
%DBDSN The data set name of the DBDS; %DBDSN is set from the DBDS record of the DBDSs.
%DBDSAM Set to VSAM for a VSAM DBDS. Otherwise, set to null.
non-HALDBs.
%DSLLGTM is set to the volume stop time of the last-accumulated log volume. 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 for the requested utility
execution. Set to 1 if yes; otherwise, set to 0.
%ICDSN The data set name of the image copy data set. Set to null if the USEDBDS parameter is specified on the
GENJCL.RECOV command. Otherwise, set from the image copy record for the DBDS.
%ICUNIT The unit type of the image copy data set. Set to null if the USEDBDS parameter is specified on the
GENJCL.RECOV command. Otherwise, set from the image copy record for the DBDS.
%ICVOLS The volume serial number list of the image copy data set. Set to null if the USEDBDS parameter is
specified on the GENJCL.RECOV command. Otherwise, set from the image copy record for the DBDS.
%ICFSEQ The file sequence number of the image copy data set. Set to null if the USEDBDS parameter is
specified on the GENJCL.RECOV command. Otherwise, set from the image copy record for the DBDS.

Symbolic Keywords
Table 36. Symbolic Keywords for Database Recovery Utility - Recovery (RECOVJCL) (continued)
Keyword Description
%CADSN The data set name of the change accumulation data set. Set to null if no change accumulation is
%CAUNIT The unit type of the change accumulation data set. Set to null if no change accumulation is available
for the DBDS. Otherwise, set from the change accumulation record.
%CAVOLS The volume serial number list of the change accumulation data set. Set to null if no change
%CAFSEQ The file sequence number of the change accumulation data set. Set to null if no change accumulation
is available for the DBDS. Otherwise, set from the change accumulation 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, the delete group
following the select group is deleted. Otherwise, the %LOGSEL keyword is set to NO, and a DD DUMMY
%RCSYSIN The Database Recovery utility control statement. Columns in the statement are set 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 was specified on the
GENJCL.RECOV command. Otherwise, blank.
44 C, if the USEDBDS parameter was specified on the GENJCL.RECOV command.
Otherwise, blank.
%RCVFULL Indicates whether full recoveries are to be generated. When set to YES, full recoveries are generated.
If the RCVTIME parameter was specified on the GENJCL.RECOV command, %RCVFULL is set to NO.
IBM-Supplied Skeletal JCL Execution Members

This section lists and describes each of the skeletal JCL execution members that are
provided by IBM. This skeletal JCL generates executable JCL for running the
applicable utilities:
v “The JOB Statement” on page 444
v “Log Archive Utility JCL (ARCHJCL)” on page 444
v “Database Change Accumulation Utility JCL (CAJCL)” on page 450
v “Log Recovery Utility JCL (LOGCLJCL)” on page 453
v “Database Image Copy Utility JCL (ICJCL)” on page 455
v “Online Database Image Copy Utility JCL (OICJCL)” on page 461
v “Database Recovery Utility JCL-Image Copy Receive-Tracking Site (ICRCVJCL)”
on page 463
v “Database Recovery Utility JCL (RECOVJCL)” on page 465

IBM-Supplied Skeletal JCL
v “Sample JCL for HALDB INDEX/ILDS Rebuild Utility (DSPUPJCL)” on page

470
Related Reading: Instructions on what you must do before using the skeletal JCL
execution members are in “Using IBM-Supplied Skeletal JCL” on page 84.
The JOB Statement

The IBM-supplied skeletal JCL execution member for the JOB statement is named
JOBJCL. 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 by
| your installation. In addition, you can add JOBLIB, STEPLIB, and JES control
| statements to JOBJCL. The default job name can be modified. If you use this
| supplied JOB statement, the job name is generated as JThhmmss, where hhmmss is the
| time (hour, minute, second) that the JCL was generated.
Log Archive Utility JCL (ARCHJCL)

The IBM-supplied skeletal JCL execution member for the Log Archive utility is
named ARCHJCL. ARCHJCL is used when the GENJCL.ARCHIVE command is issued.
Figure 58 on page 445 is a listing of ARCHJCL. A description of the statements in

ARCHJCL follows Figure 58 on page 445.

Note: The following is the OLDS archive EXEC statement.

%DELETE (%ARCSLDS EQ 'YES')
//AR%STPNO EXEC PGM=DFSUARC0,PARM='%SSID'
%ENDDEL
Note: 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
%DELETE (%RCNDSN1 EQ '')
//RECON1 DD DSN=%RCNDSN1,DISP=SHR
%ENDDEL
%ENDDEL
%ENDDEL
Note: 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),
//RLDSDD1 DD DSN=IMS.RLDSP.%SSID.D%ARDATE.T%ARTIME.V%ARVERS,
// UNIT=3400,VOL=(,,,99),
//RLDSDD2 DD DSN=IMS.RLDSS.%SSID.D%ARDATE.T%ARTIME.V%ARVERS,
// UNIT=3400,VOL=(,,,99),
%ENDDEL
Figure 58. IBM-Supplied Skeletal JCL for the Log Archive Utility (Part 1 of 3)

Note: The following lines are used to archive primary SLDSs.

%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),
%ENDDEL
Note: The following lines are used to archive secondary SLDSs.
%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),
//RLDSDD2 DD DSN=IMSVS.RLDS2.%SSID.D%ARDATE.T%ARTIME,
// UNIT=3400,VOL=(,,,99),
%ENDDEL
Note: The following lines are common to both processes.
//SYSIN DD *
SLDS FEOV(08000)
COPY DDNOUT1(RLDSDD1) DDNOUT2(RLDSDD2) DBRECOV
/*

Note: The following lines are used for the SLDSs process
//****************************************************************
//* *
//* 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
You can modify this JCL to suit your needs. It is important to maintain the position
of the output DD statements (DFSSLOGP and RLDSDD1) or (DFSSLOGS and
RLDSDD2) with respect to the correct %SELECT group. So, the DD statements for
the primary output data sets (DFSSLOGP and RLDSDD1) must follow the
%SELECT SLDS(%SSID,ALL) select group and precede the %SELECT SSLDS(%SSID,ALL)
select group.
Restrictions:
v The %ARVERS keyword is not supported for the SLDS archive process and must
not be used.
| v Do not use the FREE=CLOSE JCL parameter on the DFSSLOGP DD statement.
| The data set is dynamically deallocated and using FREE=CLOSE will produce
| unpredictable results.
EXEC Statement
The %STPNO keyword is replaced with the current step number; then the current
step number is increased by 1. The %SSID keyword is replaced with the ID of
the IMS subsystem that created the OLDSs.
The DD Statements
STEPLIB DD Statement
DBRC makes no changes to this statement.
SYSPRINT DD Statement
RECONn DD Statements
The 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 names
that are used when the GENJCL command is executed.
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 the name
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 is deleted.
OLDS DD Statements
The DD statements for the OLDSs that are to be archived are generated with a
select group. The %SSID keyword identifies the subsystem ID. The %DDNAMES
keyword identifies the OLDSs. A DD statement is generated for each specified
OLDS. The OLDS ddname replaces the %OLDSDDN keyword. The data set name
replaces the %OLDSDSN keyword.
DFSSLOGP DD Statement
This DD statement defines the primary SLDS to be created. The subsystem ID
replaces the %SSID keyword. The %ARDATE and %ARTIME keywords are replaced
with the date (yyddd) and time (hhmmsst) from the open time stamp of the
oldest OLDS being archived. The %ARVERS keyword is replaced with the archive
version number (nn) of the oldest OLDS being archived.
DFSSLOGS DD Statement
This DD statement defines the secondary SLDS that is to be created. The
subsystem ID replaces the %SSID keyword. The %ARDATE and %ARTIME keywords
are replaced with the date (yyddd) and time (hhmmsst) from the open time
stamp of the oldest OLDS that is being archived. The %ARVERS keyword is
replaced with 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 the
skeletal JCL execution member.
RLDSDD1 DD Statement
This DD statement defines the primary RLDS that is to be created. The
replaced with 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 DD
statement from the execution member. If this statement is deleted, the utility
control COPY statement must be deleted from the SYSIN data. DBRC does not
verify that the SYSIN data matches the DD statements.
This DD statement defines the secondary RLDS that is to be created. The
replaced with the archive version number (nn) of the oldest OLDS being
archived.
If you are not using RLDS logging, delete this statement from the execution
member. If this statement is deleted, the DDNOUT2(RLDSDD2) parameter must be

deleted from the utility control COPY statement in the SYSIN data. DBRC does
not verify that the SYSIN data matches the DD statements.
SYSIN DD Statement
DBRC makes no changes to the SYSIN DD statement or to the utility control
statements in the SYSIN data.
DFSSLDSP DD Statements
The DD statements for the primary SLDSs that are to be archived are
generated with a select group. The %SSID keyword identifies the subsystem ID.
A DD statement is generated for each unarchived SLDS. The SLDS data set
name replaces the %SLDSDSN keyword.
DFSSLDSS DD Statements
The DD statements for the secondary SLDSs that are to be archived are
generated with a select group. The %SSID keyword identifies the subsystem ID.
A DD statement is generated for each unarchived SLDS. The SLDS name
replaces the %SLDSDSN keyword.
DFSSLOGP DD Statement
This DD statement defines the primary SLDS that is to be created. The
stamp of the oldest OLDS or SLDS that is being archived. The %ARVERS
keyword is replaced with the archive version number (nn) of the oldest OLDS
being archived.
DFSSLOGS DD Statement
This DD statement defines the secondary SLDS that is to be created The
that is being archived.
If you are not using dual SLDS logging, delete these DD statements and the
DD2 DD statements from the skeletal JCL execution member.
This DD statement defines the primary RLDS that is to be created. The
stamp of the oldest OLDS or SLDS being archived. The %ARVERS keyword is
replaced with the archive version number (nn) of the oldest OLDS being
archived.
If you are not using an RLDS, delete these statements, the RLDSDD2 DD
statements, and the DD3 and DD4 DD statements from the execution member.
If these statements are deleted, the utility control COPY statement must be
deleted from the SYSIN data. DBRC does not verify that the SYSIN data
matches the DD statements.
This DD statement defines the secondary RLDS that is to be created. The
that is being archived.

If you are not using dual logging, delete these statements and the DD4 DD
statements from the execution member. If these statements are deleted, the
DDNOUT2(RLDSDD2) parameter must be deleted from the utility control
COPY statement in the SYSIN data. DBRC does not verify that the SYSIN data
matches the DD statements.
Database Change Accumulation Utility JCL (CAJCL)

The IBM-supplied skeletal JCL execution member for the Database Change
Accumulation utility is named CAJCL. CAJCL is used when the GENJCL.CA
command is issued. You can specify an execution member other than CAJCL by
using the CAJCL parameter on the INIT.CAGRP or CHANGE.CAGRP commands.
Figure 59 on page 451 is a listing of CAJCL. A description of the statements in

CAJCL follows Figure 59 on page 451.

//CA%STPNO EXEC PGM=DFSUCUM0,PARM='CORE=100000',REGION=800K

//*
//*
//* JCL FOR CHANGE ACCUMULATION
//*
//STEPLIB DD DSN=IMS.RESLIB,DISP=SHR
%DELETE (%RCNDSNl EQ '')
//RECON1 DD DSN=%RCNDSNl,DISP=SHR
%ENDDEL
%ENDDEL
%ENDDEL
//SYSOUT DD SYSOUT=A
//SORTLIB DD DSN=SYS1.SORTLIB,DISP=SHR
//SORTWK01 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 59. IBM-Supplied Skeletal JCL for the Database Change Accumulation Utility
EXEC Statement
step number is increased by 1.
The DD Statements

IMS DD Statement
SYSOUT DD Statement
SORTLIB DD Statement
SORTWKn DD Statements
DBRC makes no changes to these statements.
DFSUCUMO DD Statement
This statement identifies a previously created change accumulation data set
that is used as input.
Two delete groups are used to generate this DD statement. If no existing
change accumulation data set is defined in RECON for the CA group, the
value of the %CAODSN keyword is null. Thus, the first delete group is deleted,
and the DFSUCUMO DD statement is generated as DUMMY,DCB=BLKSIZE=100.
If an input change accumulation data set is defined in RECON, the %CAODSN
keyword 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 keywords
relating 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 Statement
This DD statement identifies the output change accumulation data set. Other
keywords 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 Statement
This DD statement identifies the IMS log data sets that are to be used as input
to the Database Change Accumulation utility. A select group selects the
required log data sets. %CAGRP identifies the CA group for which log data sets
are to be selected. All log volumes that are not previously processed for the
CA group are selected. 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 %LOGSEL
keyword in the next delete group is YES; this causes the delete group to be
deleted. Otherwise, the %LOGSEL keyword is set to NO, and a DD DUMMY
DFSUDD1 DD Statement
The DFSUDD1 DD statement identifies the optional output log data set that is
produced by the Database Change Accumulation utility. DBRC does not record
the optional output log data set; therefore, the skeletal JCL execution member
specifies the DFSUDD1 DD statement as DUMMY.
SYSIN DD Statement
DB0 Control Statements
A DB0 control statement is generated for each DBDS in the CA group.
For a detailed description of the DB0 control statement, see “DB0 Statement”
under “Database Change Accumulation Utility (DFSUCUM0)” in the IMS
Version 9: Utilities Reference: Database and Transaction Manager.
Log Recovery Utility JCL (LOGCLJCL)

| The IBM-supplied skeletal JCL execution member for the Log Recovery utility is
| named LOGCLJCL. The LOGCLJCL member is used to generate the JCL necessary
| that allows the Log Recovery utility (DFSULTR0) to close an OLDS from the
| WADS. For all other uses of the Log Recovery utility, see the IMS Version 9: Utilities
| Reference: System.
LOGCLJCL is used when the GENJCL.CLOSE command is issued.
Figure 60 on page 454 is a listing of LOGCLJCL. A description of the statements in

LOGCLJCL follows Figure 60 on page 454.

//CL%STPNO EXEC PGM=DFSULTR0,PARM='IMSID=%SSID'

//*
//*
//* JCL FOR LOG RECOVERY UTILITY
//*
%DELETE (%RCNDSNl EQ '')
%ENDDEL
%ENDDEL
%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 60. IBM-Supplied Skeletal JCL for the Log Recovery Utility
EXEC Statement
step number is increased by 1. The %SSID keyword is replaced with the ID of
the IMS subsystem that created the OLDS that is to be closed.


OLDS DD Statement
This DD statement identifies the OLDS that is to be closed. A select group is
used to select the OLDS. The %SSID keyword identifies the subsystem ID, and
the %CDDNAME identifies the OLDS by its DD name. The OLDS type, primary or
secondary, replaces the %OLDSTYP keyword. The resulting ddname is DFSOLP or
DFSOLS. The %OLDSDSN keyword is replaced with the data set name of the OLDS.
WADS DD Statement
This statement is provided only as a model. You must change it before using
the skeletal JCL execution member.
The supplied DFSWADS0 DD statement must be replaced with DD statements
DFSWADS0 through DFSWADSn. n+1 is the number of WADSs that the online IMS
control region uses. The WADS DD statements are contained in a select group
that is controlled by the keyword %WADS. The GENJCL.CLOSE command processor
sets the value of the %WADS keyword to YES if the OLDS is to be closed using
the WADS. The command processor sets the value to NO if the OLDS is to be
closed using the next OLDS. The WADS DD statements are, therefore, deleted if
the OLDS is to be closed using the next OLDS.
Next OLDS DD Statements
If the OLDS is to be closed using the next OLDS, these DD statements identify
the next OLDSs. These statements are contained in a delete group that is
controlled by the %WADS keyword. Thus, if the OLDS is to be closed using the
WADS, these statements are deleted. A select group is used in order to select
the next OLDSs. The %SSID keyword identifies the subsystem ID. The %NDDNAME
keyword identifies the next OLDS by ddname. The OLDS type, primary or
secondary, replaces the %OLDSTYP keyword. The resulting ddname is DFSNOLP or
DFSNOLS. The %OLDSDSN keyword is replaced with the data set name of the
OLDS.
Prior OLDS DD Statements
If an immediately prior OLDS exists, the corresponding DD statement
identifies the immediately prior OLDS. These statements are contained in a
delete group that is controlled by the %PDDNAME keyword. If its value is not null,
a select group is used in order to select the immediately prior OLDS. The
resulting ddname is DFSPOLP or DFSPOLS. Processing of the other keywords is as
described under Next OLDS DD Statements, above.
SYSIN DD Statement
DBRC makes no changes to the SYSIN DD statement or to the utility control
statements in the SYSIN data.
Database Image Copy Utility JCL (ICJCL)

The IBM-supplied skeletal JCL execution member for the Database Image Copy
and Database Image Copy 2 utility is named ICJCL.
ICJCL is used when the GENJCL.IC command is issued. The ICJCL may be
processed more than once for each job step in the output JCL. You can specify an
execution member other than ICJCL by using the ICJCL parameter on the
INIT.DBDS or CHANGE.DBDS commands.
The JCL is divided into three parts:

First part (from the EXEC statement through the IMS DD statement)
Contained in delete groups controlled by keyword %SMSGRP so that they
are processed only once per job.
Second part (from the %DBADDN DD statement through the %ICDDN4 DD
statement)
Processed once for each DBDS or area to be copied in a job step. The
second set of %ICDDNn DD statements are deleted if Sameds was
specified on the GENJCL command.
Third part (SYSIN DD statement and the %ICSYSIN statement)
Contained in a delete group controlled by keyword %SMSGRP so that they
are processed only for the last (or only) DBDS or area to be copied in a job
step.
Figure 61 on page 457 is a listing of ICJCL. A description of the statements in

ICJCL follows Figure 61 on page 457.

%DELETE (%SMSGRP NE '

//*-----| These comments are useful for modifying the skeletal
//*-----| member, but are confusing when generated in the
//*-----| output jcl. Force them to be deleted.
//*-----|
//*-----| New variables for GENJCL.IC:
//*-----| One DBDS per step:
//*-----| %SMSGRP = 0 - Not SMS or not Group
//*-----| %SMS1DS = 0 - Not SMS or not Group or not ONEDS
//*-----|
//*-----| Multiple DBDSs per step:
//*-----| %SMSGRP = 1 - SMS + Group + only member
//*-----| %SMSGRP = 2 - SMS + Group + first member
//*-----| %SMSGRP = 3 - SMS + Group + not first or last
//*-----| %SMSGRP = 4 - SMS + Group + last member
//*-----| %SMS1DS = 1 - %SMSGRP > 0 + ONEDS
//*-----------------------------------------------------------------
//*-----| Section 1 is used only once per step
//*-----------------------------------------------------------------
%ENDDEL
%DELETE (%SMSGRP GT '2')
//IC%STPNO EXEC PGM=%PGMIC,REGION=800K,
// PARM='%PARMX'
//*
//*
//* THE IMS/ESA DATA BASE RECOVERY CONTROL FEATURE.
//*
//* JCL FOR IMAGE COPY.
//*
%ENDDEL
%DELETE (%RCNDSN1 EQ '' | %SMSGRP GT '2')
%ENDDEL
%ENDDEL
%ENDDEL
%DELETE (%SMSGRP GT '2')
//IMS DD DSN=IMSVS.DBDLIB,DISP=SHR
%ENDDEL
%DELETE (%SMSGRP NE '')
Figure 61. IBM-Supplied Skeletal JCL for the Database Image Copy Utility and the Database
Image Copy 2 Utility (Part 1 of 3)

//*-----------------------------------------------------------------
//*-----| Single output data set if SMS and ONEDS
//*-----------------------------------------------------------------
%ENDDEL
%DELETE (%SMSGRP GT '2' | %SMS1DS NE '1')
//%ICDDN1 DD DSN=%ICDSN1,UNIT=%ICUNIT1,
// VOL=(PRIVATE,,,%ICVCNT1,SER=(%ICVOLS1)),
// LABEL=(%ICFSEQ1,SL),
// DISP=(NEW,KEEP)
%ENDDEL
%DELETE (%COPIES LT '2' | %SMSGRP GT '2' | %SMS1DS NE '1')
// DISP=(NEW,KEEP)
%ENDDEL
%DELETE (%COPIES LT '3' |%SMSGRP GT '2' | %SMS1DS NE '1')
// DISP=(NEW,KEEP)
%ENDDEL
%DELETE (%COPIES LT '4' |%SMSGRP GT '2' | %SMS1DS NE '1')
// DISP=(NEW,KEEP)
%ENDDEL
//*-----------------------------------------------------------------
//*-----| Section 2 is used once per DBDS (any value of %SMSGRP)
//*-----------------------------------------------------------------
%ENDDEL
%SELECT DBDS((%DBNAME,%DBDDN))
%DELETE (%DBADSAV NE 'AVAIL')
//%DBADDN DD DSN=%DBDSN,DISP=%CICDISP
%ENDDEL
%DELETE (%DBADSAV NE '' | %MDBNAME NE'')
//%DBDDN DD DSN=%DBDSN,DISP=%CICDISP
%ENDDEL
%ENDSEL
//*-----------------------------------------------------------------
//*-----| Output data sets not included if SMS + Group + ONEDS
//*-----------------------------------------------------------------
%ENDDEL
%DELETE (%SMS1DS EQ '1')
%ENDDEL
%DELETE (%SMS EQ '1' | %SMS1DS EQ '1')
// DISP=(NEW,KEEP),DCB=BUFNO=10
%ENDDEL
%DELETE (%SMS NE '1' | %SMS1DS EQ '1')
// DISP=(NEW,KEEP)
%ENDDEL

%DELETE (%COPIES EQ '1' | %SMS EQ '1' | %SMS1DS EQ '1')

%ENDDEL
%DELETE (%COPIES EQ '1' | %SMS NE '1' | %SMS1DS EQ '1')
// DISP=(NEW,KEEP)
%ENDDEL
%DELETE (%COPIES LE '2' | %SMS EQ '1' | %SMS1DS EQ '1')
%ENDDEL
%DELETE (%COPIES LE '2' | %SMS NE '1' | %SMS1DS EQ '1')
// DISP=(NEW,KEEP)
%ENDDEL
%DELETE (%COPIES LE '3' | %SMS EQ '1' | %SMS1DS EQ '1')
%ENDDEL
%DELETE (%COPIES LE '3' | %SMS NE '1' | %SMS1DS EQ '1')
// DISP=(NEW,KEEP)
%ENDDEL
//*-----------------------------------------------------------------
//*-----| Section 3 is used once per step (%SMSGRP = 0, 1, or 4
//*-----------------------------------------------------------------
%ENDDEL
%DELETE (%SMSGRP EQ '2'| %SMSGRP EQ '3')
//SYSIN DD *
%ICSYSIN
/*
%ENDDEL
v This member may be processed more than once for each job step in the output
JCL.
v All statements in the first part of the JCL, from the EXEC statement through the
IMS DD statement, are in delete groups controlled by keyword %SMSGRP so
that they are processed only once per job step.
v The first set of %ICDDn DD statements identify the single output data set for a
group of image copies. It is in a delete group controlled by the %SMS1DS
keyword so that it is output only when Sameds was specified in the GENJCL
command.
v The second part of the JCL, from the %DBADDN DD statement through the
%ICDDN4 DD statement, is processed once for each DBDS or area to be copied
in a job step. The %ICDDNn DD statements are deleted if Sameds was specified
on the GENJCL command.

v The third part of the JCL, the SYSIN DD statement and the %ICSYSIN
statement, are in a delete group controlled by keyword %SMSGRP so that they
are processed only for the last (or only) DBDS or area to be copied in a job step.
EXEC Statement
step number is increased by 1.
IMS DD Statement
%DBADDN DD Statement
This statement identifies the available ADS that is to be used. The %DBADDN
keyword is replaced with the ddname of the ADS. The %DBDSN keyword is
replaced with the ADS name.
%DBDNN DD Statement
This statement identifies the DBDS that is to be copied. The %DBDDN keyword is
replaced with the ddname of the DBDS. The %DBDSN keyword is replaced by
the data set name of the DBDS.
%ICDDN1 DD Statement
These statements identify the first image copy data set that is produced by an
Image Copy utility. Other keywords relating to the image copy data set are
replaced as follows:
%ICDSN1 Data set name
%ICVCNT1 Volume count
%ICVOLS1 Volume serial number list
%ICUNIT1 Unit type
%ICFSEQ1 File sequence number
%ICDDN2 | 3 | 4 DD Statement
These statements identify the subsequent images that are produced by the
Image Copy utility. This DD statement is within a delete group that is
controlled by the %COPIES keyword. The %COPIES keyword is set to 1 if a single
image copy data set is to be produced or to a 2, 3, or 4 if multiple image copy
data sets are to be produced. If %COPIES is 1, the group is deleted.

The %ICDSNx, %ICVCNTx, %ICVOLSx, %ICUNITx, and %ICFSEQx keywords are

replaced with the same type of information as is shown under the %D1OU0 DD
statement just preceding. x can be either 2, 3 or 4.
SYSIN DD Statement
%ICSYSIN Statement
The Image Copy utility control statement replaces the %ICSYSIN keyword.
The %ICSYSIN statement is required. If the %ICSYSIN statement is deleted, the
GENJCL.IC command fails. Multiple control statements are generated if you are
processing a group.
Online Database Image Copy Utility JCL (OICJCL)

The IBM-supplied skeletal JCL execution member for the Online Image Copy
utility is named OICJCL. OICJCL is used when the GENJCL.OIC command is issued.
You can specify an execution member other than OICJCL by using the OICJCL
parameter on the INIT.DBDS or CHANGE.DBDS commands.
Figure 62 is a listing of OICJCL. A description of the statements in OICJCL follows

Figure 62.
//OIC%STPNO EXEC PGM=DFSRRC00,PARM='BMP,DFSUICP0,%PSB,,MASTER',

// REGION=700K
//* THE IMS/VS DATA BASE RECOVERY CONTROL FEATURE.
//*
//* JCL FOR ONLINE IMAGE COPY.
//*
//STEPLIB DD DSN=IMSVS.SDFSRESL,DISP=SHR
%ENDDEL
%ENDDEL
%ENDDEL
// DISP=(NEW,KEEP)
%DELETE (%COPIES EQ '1')
// DISP=(NEW,KEEP)
%ENDDEL
//DFSUCKPT DD DSN=IMSVS.%DBNAME.%DBDDN.CHECKPT.IC%TIME,
// UNIT=SYSDA,SPACE=(TRK,1),DISP=(NEW,CATLG)
//SYSIN DD *
%ICSYSIN
/*
Figure 62. IBM-Supplied Skeletal JCL for the Online Database Image Copy Utility
EXEC Statement

step number is increased by 1. The PSB name that is specified on the

GENJCL.OIC command replaces the %PSB keyword.
IMS DD Statement
This statement identifies the first image copy data set that is produced by the
Image Copy utility. Other keywords relating to the online image copy data set
are replaced as follows:
%ICDSN1 Data set name
%ICVCNT1 Volume count
%ICVOLS1 Volume serial number list
%ICUNIT1 Unit type
%ICFSEQ1 File sequence number
This statement identifies the duplicate image copy data set that produced by
the Image 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 data set is to be produced or to 2 if duplicate image copy data sets are to
be produced. If %COPIES is 1, the group is deleted.
The %ICDSN2, %ICVCNT2, %ICVOLS2, %ICUNIT2, and %ICFSEQ1 keywords are
replaced with the same type of information as is shown under the %D1OUO DD
statement just preceding.
DFSUCKPT DD Statement
The DFSUCKPT DD statement identifies the optional online image copy
checkpoint data 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 not
specified in the IBM-supplied skeletal JCL. You must supply these if
checkpoint data sets are to be used.
The DFSUCKPT DD statement is optional. If checkpoint data sets are not to be
used by the Online Image Copy utility, the statement can be deleted.
SYSIN DD Statement
%ICSYSIN Statement
The 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 specify
an execution member other than ICRCVJCL by using the RECVJCL parameter on the
INIT.DBDS or CHANGE.DBDS commands.
Figure 63 on page 464 is a listing of ICRCVJCL. A description of the statements in

ICRCVJCL follows Figure 63 on page 464.

//RCV%STPNO EXEC PGM=DFSRRC00,REGION=1300K,

// PARM='UDR,DFSURDB0,%DBNAME',,,,,,,,,,,,,,,,,,,,,%GSGNAME'
//*
//*
//* JCL FOR IMAGE COPY RECEIVE
//*
%ENDDEL
%ENDDEL
%ENDDEL
//%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
//DFSULOG DD DUMMY
%ENDDEL
%DELETE (%CADSN NE '')
//DFSUCUM DD DUMMY
%ENDDEL
//DFSVSAMP DD *
1024,4
4096,4
//SYSIN DD *
%RVSYSIN
/*
Figure 63. IBM-Supplied Skeletal JCL for the Database Recovery Utility - Tracking Site
EXEC Statement
step number is increased by 1. The %DBNAME keyword is replaced with the
database name of the DBDS or area that is being received.
The DD Statements


IMS DD Statement
%DBDDN DD Statement
The %DBDDN keyword is replaced by the ddname of the DBDS that is being
received. The %DBDSN keyword is replaced by the data set name of the DBDS or
area.
Delete groups control the remainder of the %DBDDN DD statement. The access
method of the DBDS controls the content of the delete groups. If the access
method is VSAM, DISP=OLD is generated. Otherwise, the UNIT, VOL, SPACE, DISP,
and DCB parameters are generated.
DFSUDUMP DD Statement
This DD statement identifies the image copy data set that is to be received. The
%ICDSN, %ICUNIT, %ICVOLS, and %ICFSEQ keywords are set from the appropriate
fields in the image copy RECON record.
DFSUCUM DD Statement
This DD statement is always listed as DUMMY at the tracking site.
This DD statement is always listed as DUMMY at the tracking site.
DFSVSAMP DD Statement
The DFSVSAMP DD statement identifies information that is required by the DL/I
buffer handler. DBRC makes no changes to these statements.
SYSIN DD Statement
This DD statement contains database recovery statements that control the
processing.
%RVSYSIN Statement
DBRC replaces the %RVSYSIN keyword.
Database Recovery Utility JCL (RECOVJCL)

The IBM-supplied skeletal JCL execution member for the Database Recovery utility
is named RECOVJCL. RECOVJCL is used when the GENJCL.RECOV command is
issued. You can specify an execution member other than RECOVJCL by using the
RECOVJCL parameter on the INIT.DBDS or CHANGE.DBDS commands.
Figure 64 on page 466 is a listing of RECOVJCL. A description of the statements in

RECOVJCL follows Figure 64 on page 466.

%DELETE (%MDBNAME NE '')

// PARM='UDR,DFSURDB0,%DBNAME,,,,,,,,,,,,,,,,,,,%GSGNAME'
%ENDDEL
%DELETE (%MDBNAME EQ '')
// PARM='UDR,DFSURDB0,%MDBNAME,,,,,,,,,,,,,,,,,,%GSGNAME'
%ENDDEL
//*
//*
//* THIS JCL ORIGINIATES FROM THE USER'S 'JCLPDS' LIBRARY.
//*
//* JCL FOR RECOVERY.
//*
//STEPLIB DD DSN=IMSVS.SDFSRESL,DISP=SHR
%ENDDEL
%ENDDEL
%ENDDEL
//%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 64. IBM-Supplied Skeletal JCL for the Database Recovery Utility (Part 1 of 2)

%DELETE (%ICCAT EQ 'YES')

// UNIT=%ICUNIT,
// VOL=(PRIVATE,,,,SER=(%ICVOLS)),
// LABEL=(%ICFSEQ,SL),
%ENDDEL
%DELETE (%ICDSN EQ '' | %SMS EQ '1')
%ENDDEL
%DELETE (%ICDSN EQ '' | %SMS EQ '0')
// DISP=(OLD,KEEP)
%ENDDEL
%DELETE (%ICDSN NE '')
//DFSUDUMP DD DUMMY
%ENDDEL
//DFSVDUMP DD DUMMY
%DELETE (%CADSN EQ '')
//DFSUCUM DD DSN=%CADSN,UNIT=%CAUNIT,
// VOL=(PRIVATE,,,,SER=(%CAVOLS)),
// LABEL=(%CAFSEQ,SL),
%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
//DFSULOG DD DUMMY
%ENDDEL
%DELETE (%TRACK EQ 'NO')
//DFSTRCV DD DSN=??????,
// DISP=OLD
%ENDDEL
//DFSVSAMP DD *
1024,4
4096,4
//SYSIN DD *
%RCSYSIN
/*
Figure 64. IBM-Supplied Skeletal JCL for the Database Recovery Utility (Part 2 of 2)
EXEC Statement
step number is increased by 1. For HALDB, the HALDB master name,
%MDBNAME, of the DBDs being recovered is used in the EXEC statement. For all
others, the database name, %DBNAME, is used.
The DD Statements

IMS DD Statement
%DBDDN DD Statement
The %DBDDN keyword is replaced by the ddname of the DBDS that is being
recovered. The %DBDSN keyword is replaced by the data set name of the DBDS.
Delete groups control the remainder of the %DBDDN DD statement. The access
method of the DBDS controls the content of the delete groups. If the access
method is VSAM, DISP=OLD is generated. Otherwise, the UNIT, VOL, SPACE, DISP,
and DCB parameters are generated.
DFSUDUMP DD Statement
This DD statement identifies the image copy data set, if any, that is to be used
for recovery. Delete groups, which are controlled by the %ICDSN keyword, are
used to generate this DD statement.
If the USEIC parameter was specified or if it was the default, on the
GENJCL.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 is
deleted. Other keywords within the first delete group are unchanged.
If the USEDBDS or USEAREA keyword was specified on the GENJCL.RECOV
command, the DFSUDUMP DD statement is generated as DUMMY.
DFSVDUMP DD Statement
The DFSVDUMP DD statement is always generated as DUMMY.
DFSUCUM DD Statement
This DD statement identifies the change accumulation data set, if any, to be
used as input to recovery. Delete groups, which are controlled by the %CADSN
keyword, are used to generate the DFSUCUM DD statement. If the DBDS belongs
to a CA group, the %CADSN keyword is set to the data set name of the
most-recent change accumulation data set. If the DBDS does not belong to a
CA group or if no usable change accumulation data set exists, the %CADSN
keyword is set to null.
v If the %CADSN keyword is null, the DFSUCUM DD statement is generated as
DUMMY.
v If the %CADSN keyword is not null, the DFSUCUM DD statement identifies the
change accumulation data set.
Other keywords relating to the change accumulation data set are replaced as
follows:
%CAVOLS Volume serial number list
%CAUNIT Unit type

%CAFSEQ File sequence number

This DD statement identifies the log data sets that are to be used as input to
the Database Recovery utility.
A select group selects the required log data sets. The %DBNAME and %DBDDN
keywords 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 the
change accumulation data sets, are selected. Other keywords relating to the log
data 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, and
the following delete group is deleted. Otherwise, the %LOGSEL keyword is NO,
and a DD DUMMY statement is generated.
DFSTRCV DD Statement
The DFSTRCV DD statement identifies the DBDS for which one or more tracks is
being recovered. If the TRACK parameter was not specified on the GENJCL
command, this statement does not appear in the generated JCL.
You must modify the DFSTRCV DD statement to include in it the appropriate
data set name and unit information. You can modify it in either the skeletal
JCL or generated JCL.
The DFSVSAMP DD statement identifies information required by the DL/I buffer
handler. DBRC makes no changes to these statements.
SYSIN DD Statement
processing.
%RCSYSIN Statement
DBRC replaces the %RCSYSIN keyword.
%RCVFULL
The %RCVFULL keyword indicates what type of recovery is being generated. It is
set to NO when the RCVTIME parameter (time-stamp recovery) is specified on the
GENJCL.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
flag in the DBDS record following a time-stamp recovery. You could add the
following JCL to the end of your RECOVJCL skeletal JCL member to
accomplish this.
%DELETE (%RCVFULL EQ 'YES')
//RCV%STPNO EXEC PGM=DSPURX00
%ENDDEL
%DELETE (%RCVFULL EQ 'YES' | %RCNDSN1 EQ '')
%ENDDEL
%ENDDEL


%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 or prime index data sets (or both) of a
HALDB partition.
The Database Recovery utility and the image copy utilities cannot be used on ILDS
and prime index data sets. The GENJCL.RECOV, GENJCL.RECEIVE, GENJCL.IC, and
GENJCL.OIC commands fail when attempted specifically for ILDS and prime index
data sets. GENJCL commands on groups, either explicit (using the GROUP
keyword) or implicit (DBD with no DDN keyword), do not generate any JCL for
ILDS or prime index data sets. These data sets are ignored. GENJCL.USER can
specify ILDS and prime index data sets. The ILDS and prime index data sets are
not ignored for this command.
After a time-stamp recovery of a HALDB partition (the data DBDSs of the HALDB
partition), the applicable ILDS or prime index data sets (or both) must be rebuilt.
There is no specific GENJCL support for these data sets, but the GENJCL.USER
command can be used. 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')
Figure 65 on page 471 is a listing of DSPUPJCL. A description of the statements in

DSPUPJCL follows Figure 65 on page 471.

//UPREC%STPNO EXEC PGM=DFSRRC00,REGION=1300K,

// PARM='ULU,DFSPREC0,%MDBNAME,,,,,,,,,,,,,,,,,,,Y,N'
//*
//*************************************************************************
//*
//* KEYWORDS ARE REPLACED BY THE GENJCL FUNCTION.
//*
//* User JCL for rebuilding the Index and/or ILDS data
//* sets for a Partition of a HALDB.
//*
%ENDDEL
%ENDDEL
%ENDDEL
//DFSVSAMP DD DSN=IMS.VSAM.PARM(OPTIONS),DISP=SHR
//SYSIN DD *
PARTITION=%DBNAME,RECOVTYP=%RCVTYP
/*
Figure 65. IBM-Supplied Skeletal JCL for the HALDB Index/ILDS Rebuild Utility
EXEC Statement
step number is increased by 1. The %MDBNAME keyword is replaced with the
HALDB master name of the DBDS that is being recovered.
The DD Statements
IMS DD Statement
The DFSVSAMP DD statement identifies information required by the DL/I buffer
handler. DBRC makes no changes to these statements.
SYSIN DD Statement
processing.

PARTITION=%DBNAME
This statement indicates the HALDB partition name of the ILDS or prime
index data sets being rebuilt. For a description of the %DBNAME keyword values,
see the IMS Version 9: Utilities Reference: Database and Transaction Manager.
RECOVTYP=%RCVTYP
This statement indicates which type of data sets (ILDS or prime index) are
being rebuilt. For a description of the %RCVTYP keyword values, see the IMS
Version 9: Utilities Reference: Database and Transaction Manager.

Appendix B. Sample Listings from the RECON Data Set
The following listings show the format and content of various records from an
example RECON data set, as they were listed by LIST.RECON commands.
In This Appendix:
v “Sample Listing of LIST.HISTORY Output” on page 474
v “Sample Listing of a RECON at the Active Site” on page 479
v “Sample Listing of a RECON at the Tracking Site” on page 508
v “Fields Present in a Listing of a RECON by Record Type” on page 532
The LIST command causes the RECON to be read.
The sample listings illustrate:

v These records: PRILOG, PRISLD, PRIOLD, LOGALL, GSG, SSYS, and
BACKOUT
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
- RECOV records
To find the DSECTS defining the formats of the RECON records in DBRC in
ADFSMAC and SDFSMAC, run the generate job with SDFSMAC=ALL. The member
names are:
Member Name
RECON Record DSECTS
DSPALLRC ALLOC record
DSPBKORC BACKOUT record
DSPCAGRC CAGRP record
DSPCHGRC CA record
DSPDBHRC DB record
DSPDGRC DBDSGRP record
DSPDSHRC DBDS record
DSPGSGRC Global Service Group record
Sample RECON Listing Active Site
DSPIMGRC IC record
DSPLGARC LOGALL record
| DSPLOGRC PRILOG / SECLOG/PRISLD / SECSLD / PRITSLDS / SECTSLDS
| record
DSPOLDRC PRIOLD / SECOLD record
DSPPTNRC HALDB Partition record
DSPRCNRC HEADER record
DSPRCR1 HEADEREXT record
DSPRCVRC RECOV record
DSPRRGRC REORG record
| DSPRDTRC RECON DMB Table record
DSPSSRC SUBSYS record
Sample Listing of LIST.HISTORY Output

You use the LIST.HISTORY command to produce a history of activity for DBDSs or
DEDB areas. You can produce a RECON listing using LIST.HISTORY from either an
active or a remote site. Figure 66 on page 475 is an example of LIST.HISTORY
output that includes a time line.

LIST.HISTORY Sample
| IMS VERSION 9 RELEASE 1 DATA BASE RECOVERY CONTROL PAGE 0001

| LIST.HISTORY DBD(DIVNTZ02) DDN(DBHVSAM1)
| 04.194 12:54:37.9 LISTING OF RECON PAGE 0002
| -------------------------------------------------------------------------------
| DB
| DBD=DIVNTZ02 IRLMID=*NULL DMB#=1 TYPE=IMS
| SHARE LEVEL=3 GSGNAME=**NULL** USID=0000000005
| AUTHORIZED USID=0000000005 RECEIVE USID=0000000005 HARD USID=0000000005
| RECEIVE NEEDED USID=0000000000
| DBRCVGRP=**NULL**
| FLAGS: COUNTERS:
| BACKOUT NEEDED =OFF RECOVERY NEEDED COUNT =0
| READ ONLY =OFF IMAGE COPY NEEDED COUNT =0
| PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =0
| RECOVERABLE =YES HELD AUTHORIZATION STATE=0
| EEQE COUNT =0
| TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0
| OFR REQUIRED =NO
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DBDS
| DSN=DIVNTZ02.FJXXS01K TYPE=IMS
| DBD=DIVNTZ02 DDN=DBHVSAM1 DSID=001 DBORG=HISAM DSORG=VSAM
| OTHER DDN=**NULL**
| CAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=1 DSSN=00000004
| NOREUSE RECOVPD=0 OTHER DDN=**NULL**
| DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCL
| RECVJCL=ICRCVJCL
| FLAGS: COUNTERS:
| IC NEEDED =OFF
| RECOV NEEDED =OFF
| RECEIVE NEEDED =OFF EEQE COUNT =0
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| ALLOC
| ALLOC =04.194 12:49:55.0 * ALLOC LRID =0000000000000000
| DSSN=0000000001 USID=0000000002 START = 04.194 12:49:23.7
| DEALLOC =04.194 12:50:19.8 DEALLOC LRID =0000000000000000
|
| IMAGE
| RUN = 04.194 12:50:08.4 * RECORD COUNT =183
| STOP = 04.194 12:50:10.5 ONLINE USID=0000000002
|
| IC1
| DSN=IMSVS.DIVNTZ02.DBHVSAM1.IC.IC125005 FILE SEQ=0001
| UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001
| VOLSER=222222
| ALLOC
| ALLOC =04.194 12:51:10.5 * ALLOC LRID =0000000000000000
| DSSN=0000000002 USID=0000000003 START = 04.194 12:49:23.7
|
| ALLOC
| ALLOC =04.194 12:52:21.5 * ALLOC LRID =0000000000000000
| DSSN=0000000003 USID=0000000004 START = 04.194 12:49:34.3
|
| ALLOC
| ALLOC =04.194 12:53:17.6 * ALLOC LRID =0000000000000000
| DSSN=0000000004 USID=0000000005 START = 04.194 12:49:34.3
| DSP0181I NO CAGRP RECORD FOUND
| DSP0181I NO CA RECORD FOUND
| DSP0181I NO REORG RECORD FOUND
| DSP0181I NO RECOV RECORD FOUND
|
| Figure 66. Sample LIST.HISTORY Output (Part 1 of 5)
|
Appendix B. Sample Listings from the RECON Data Set 475
LIST.HISTORY Sample
04.194 12:54:37.9 LISTING OF RECON PAGE 0004

-------------------------------------------------------------------------------
STOP = 04.194 12:53:54.0 #DSN=5
GSGNAME=**NULL**
STOP = 04.194 12:50:20.0 LAST DS LSN= 0000000000000535
VOLSER=000000 STOPTIME = 04.194 12:50:20.0

CKPTCT=1 CHKPT ID = 04.194 12:49:25.5
LOCK SEQUENCE#= BB81AF27002F
STOP = 04.194 12:51:31.0 LAST DS LSN= 0000000000000BDD
VOLSER=000000 STOPTIME = 04.194 12:51:31.0

CKPTCT=1 CHKPT ID = 04.194 12:50:20.1
LOCK SEQUENCE#= BB81AF6A7EC4
START = 04.194 12:51:31.0 FIRST DS LSN= 0000000000000BDE
STOP = 04.194 12:52:27.6 LAST DS LSN= 0000000000000D11
VOLSER=000000 STOPTIME = 04.194 12:52:27.6

CKPTCT=1 CHKPT ID = 04.194 12:51:31.1
LOCK SEQUENCE#= BB81AF6A7EC4
START = 04.194 12:52:27.6 FIRST DS LSN= 0000000000000D12
STOP = 04.194 12:53:53.6 LAST DS LSN= 0000000000000EC6
VOLSER=000000 STOPTIME = 04.194 12:53:53.6

CKPTCT=2 CHKPT ID = 04.194 12:52:27.7
LOCK SEQUENCE#= BB81AFDF9269
START = 04.194 12:53:53.6 FIRST DS LSN= 0000000000000EC7
STOP = 04.194 12:53:54.0 LAST DS LSN= 0000000000000F3E
VOLSER=000000 STOPTIME = 04.194 12:53:54.0

CKPTCT=0 CHKPT ID = 04.194 12:53:53.5
LOCK SEQUENCE#= BB81AFDF9269
-------------------------------------------------------------------------------
Figure 66. Sample LIST.HISTORY Output (Part 2 of 5)

LIST.HISTORY Sample

-------------------------------------------------------------------------------
START = 01.111 12:00:00.0 * SSID=IMS1 Version=9.1
STOP = 01.111 14:00:00.0 #DSN=2
GSGNAME=**NULL**
DSN=PRILOG1.DSN1 UNIT=3400
STOP = 01.111 13:00:00.0 LAST DS LSN= 0000000000000100
VOLSER=USER01 STOPTIME = 01.111 13:00:00.0

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
LOCK SEQUENCE#= 2E9800000000
STOP = 01.111 14:00:00.0 LAST DS LSN= 0000000000000200

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
START = 01.112 12:00:00.0 * SSID=IMS2 Version=9.1
STOP = 01.112 14:00:00.0 #DSN=2
GSGNAME=**NULL**
STOP = 01.112 13:00:00.0 LAST DS LSN= 0000000000000300

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
STOP = 01.112 14:00:00.0 LAST DS LSN= 0000000000000400

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0

LIST.HISTORY Sample

-------------------------------------------------------------------------------
STOP = 04.194 12:54:28.1 #DSN=5
GSGNAME=**NULL**
STOP = 04.194 12:50:19.7 LAST DS LSN= 000000000000010C
VOLSER=000000 STOPTIME = 04.194 12:50:19.7

CKPTCT=1 CHKPT ID = 04.194 12:49:36.9
START = 04.194 12:50:19.7 FIRST DS LSN= 000000000000010D
STOP = 04.194 12:51:30.5 LAST DS LSN= 000000000000025E
VOLSER=000000 STOPTIME = 04.194 12:51:30.5

CKPTCT=1 CHKPT ID = 04.194 12:50:19.8
START = 04.194 12:51:30.5 FIRST DS LSN= 000000000000025F
STOP = 04.194 12:52:28.2 LAST DS LSN= 0000000000000551
VOLSER=000000 STOPTIME = 04.194 12:52:28.2

CKPTCT=1 CHKPT ID = 04.194 12:51:30.6
LOCK SEQUENCE#= BB81AFA0F956
STOP = 04.194 12:54:27.5 LAST DS LSN= 0000000000000AA7
VOLSER=000000 STOPTIME = 04.194 12:54:27.5

CKPTCT=2 CHKPT ID = 04.194 12:52:28.2
LOCK SEQUENCE#= BB81AFFFFB0E
START = 04.194 12:54:27.5 FIRST DS LSN= 0000000000000AA8
STOP = 04.194 12:54:28.1 LAST DS LSN= 0000000000000B58
VOLSER=000000 STOPTIME = 04.194 12:54:28.1

CKPTCT=0 CHKPT ID = 04.194 12:54:27.4
LOCK SEQUENCE#= BB81AFFFFB0E
-------------------------------------------------------------------------------

LIST.HISTORY Sample

+------------------------------------------------------------------------------+
|Timeline for DBDS: DIVNTZ02 DBHVSAM1 Ref |
| USID=00000005 AUTHORIZED=00000005 Page|
| RECEIVE=00000000 HARD=00000005 0002|
+-Time------------+Events----+---+--+------------------------------------------+
| |IC | | | |
| |REORG | |US|Subsystem |
| |RECOV |CA |ID|Logs and Allocs |
+-----------------+----------+---+--+------------------------------------------+
04.194 12:49:23.7 IMS1 0004
04.194 12:49:34.3 | IMS2 0005
04.194 12:49:55.0 2 A | 0002
04.194 12:50:08.4 O | | | 0002
04.194 12:50:10.5 s | | |
04.194 12:50:19.7 | | s
04.194 12:50:19.8 2 D |
04.194 12:50:20.0 s |
04.194 12:51:10.5 3 A | 0002
04.194 12:51:30.5 | | s
04.194 12:51:30.6 3 D |
04.194 12:51:31.0 s |
04.194 12:52:21.5 4 | A 0002
04.194 12:52:27.6 | s |
04.194 12:52:27.7 4 | D
04.194 12:52:28.2 | s
04.194 12:53:17.6 5 | A 0003
04.194 12:53:53.6 | s |
04.194 12:53:54.0 | C |
04.194 12:54:27.5 | s
04.194 12:54:28.1 5 C
+-----------------+----------+---+--+------------------------------------------+
In the timeline, only the last digit of USID is shown.
IC: B = Batch, U = UIC, O = OIC, C = CIC, s = Stop
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 9
| Figure 66. Sample LIST.HISTORY Output (Part 5 of 5)
Related Reading: See “LIST.HISTORY” on page 298 for more information about
the LIST.HISTORY command.
Sample Listing of a RECON at the Active Site

The following sections contain RECON record listings from an active site in an
RSR environment. “Fields Present in a Listing of a RECON by Record Type” on
page 532 describes the fields that can be present in a listing of the RECON data
set.
In This Section:
v “RECON Status Record” on page 480
v “Log Records” on page 481
v “GSG Record” on page 490
v “SSYS Record” on page 491
v “BACKOUT Record” on page 491
v “CAGRP and CA Records” on page 492
v “DBGRP, DBDSGRP, and RECOVGRP Records” on page 493
v “DB (IMS) and Related Records” on page 494

v “DB (HALDB and PART) and Related Records” on page 496

v “DB (FP) and Related Records” on page 507
RECON Status Record

| LIST.RECON STATUS
| -------------------------------------------------------------------------------
| RECON
| RECOVERY CONTROL DATA SET, IMS V9R1
| DMB#=9 INIT TOKEN=04196F1616381F
| NOFORCER LOG DSN CHECK=CHECK17 STARTNEW=NO
| TAPE UNIT=3400 DASD UNIT=SYSDA TRACEOFF SSID=**NULL**
| LIST DLOG=YES CA/IC/LOG DATA SETS CATALOGED=NO
| MINIMUM VERSION = 7.1 CROSS DBRC SERVICE LEVEL ID= 00001
| LOG RETENTION PERIOD=00.000 00:15:00.0
| COMMAND AUTH=NONE HLQ=**NULL**
| SIZALERT DSNUM=15 VOLNUM=16 PERCENT= 95
| LOGALERT DSNUM=3 VOLNUM=16
| REORG NUMBER VERIFICATION=NO
| TIME STAMP INFORMATION:
|
| TIMEZIN = %SYS -LABEL- -OFFSET-
| PDT -07:00
| PST -08:00
|
| OUTPUT FORMAT: DEFAULT = LOCORG NONE PUNC YY
| CURRENT = LOCORG NONE PUNC YY
|
|
| IMSPLEX = ** NONE **
|
| -DDNAME- -STATUS- -DATA SET NAME-
| RECON1 COPY1 IMSTESTL.IMS.RECON1
| RECON3 SPARE IMSTESTL.IMS.RECON3
Figure 67. Sample Listing of a RECON at the Active Site - RECON Status

Log Records
| LIST.LOG
| -------------------------------------------------------------------------------
| START = 04.196 09:21:02.7 * SSID=SYS3 VERSION=9.1
| STOP = 04.196 09:28:46.7 #DSN=2
| GSGNAME=IMSGSG1
|
| DSN=IMSVS.RLDSP.SYS3.D04196.T0921027.V00 UNIT=SYSDA
| STOP = 04.196 09:24:54.6 LAST DS LSN= 000000000000044C
|
| VOLSER=000000 STOPTIME = 04.196 09:24:54.6
| CKPTCT=1 CHKPT ID = 04.196 09:21:04.5
|
| DSN=IMSVS.RLDSP.SYS3.D04196.T0924546.V00 UNIT=SYSDA
| START = 04.196 09:24:54.6 FIRST DS LSN= 000000000000044D
| STOP = 04.196 09:28:46.7 LAST DS LSN= 0000000000000689
|
| VOLSER=000000 STOPTIME = 04.196 09:28:46.7
| CKPTCT=2 CHKPT ID = 04.196 09:28:46.3
|
| LOGALL
| START = 04.196 09:21:02.7 *
| DEDBJN21 DB21AR1 1
|
| Figure 68. Sample Listing of a RECON at the Active Site - Log Records (Part 1 of 10)
|


-------------------------------------------------------------------------------
PRISLD RECORD SIZE= 464
START = 04.196 09:21:02.7 * SSID=SYS3 VERSION=9.1
STOP = 04.196 09:28:46.7 #DSN=2
GSGNAME=IMSGSG1
DSN=IMSVS.SLDSP.SYS3.D04196.T0921027.V00 UNIT=SYSDA
STOP = 04.196 09:24:54.6 LAST DS LSN= 000000000000044C
CHECKPOINT TYPES=80: SIMPLE=Y SNAPQ=N DUMPQ=N PURGE=N FREEZE=N
VOLSER=000000 STOPTIME = 04.196 09:24:54.6

CKPTCT=1 CHKPT ID = 04.196 09:21:04.5
START = 04.196 09:24:54.6 FIRST DS LSN= 000000000000044D
STOP = 04.196 09:28:46.7 LAST DS LSN= 0000000000000689
CHECKPOINT TYPES=88: SIMPLE=Y SNAPQ=N DUMPQ=N PURGE=N FREEZE=Y
VOLSER=000000 STOPTIME = 04.196 09:28:46.7

CKPTCT=2 CHKPT ID = 04.196 09:28:46.3
Figure 68. Sample Listing of a RECON at the Active Site - Log Records (Part 2 of 10)


-------------------------------------------------------------------------------
STOP = 04.196 09:47:18.5 #DSN=4
GSGNAME=IMSGSG1
DSN=**** COMPRESSED DATA SET **** UNIT=

STOP = 04.196 09:30:28.6 LAST DS LSN= 000000000000030A
DSN=IMSVS.RLDSP.SYS3.D04196.T0930286.V01 UNIT=SYSDA
START = 04.196 09:30:28.6 FIRST DS LSN= 000000000000030B
STOP = 04.196 09:31:00.8 LAST DS LSN= 00000000000004D9
VOLSER=000000 STOPTIME = 04.196 09:31:00.8

CKPTCT=1 CHKPT ID = 04.196 09:30:28.6
START = 04.196 09:31:00.8 FIRST DS LSN= 00000000000004DA
STOP = 04.196 09:31:21.2 LAST DS LSN= 00000000000005F7
VOLSER=000000 STOPTIME = 04.196 09:31:21.2

CKPTCT=1 CHKPT ID = 04.196 09:31:14.9
START = 04.196 09:31:21.2 FIRST DS LSN= 00000000000005F8
STOP = 04.196 09:47:18.5 LAST DS LSN= 0000000000000828
VOLSER=000000 STOPTIME = 04.196 09:47:18.5

CKPTCT=2 CHKPT ID = 04.196 09:47:18.1
LOGALL
START = 04.196 09:29:46.6 *
DBVHDJ05 CJVHDG1E 1


-------------------------------------------------------------------------------
STOP = 04.196 09:47:18.5 #DSN=4
GSGNAME=IMSGSG1
DSN=**** COMPRESSED DATA SET **** UNIT=

STOP = 04.196 09:30:28.6 LAST DS LSN= 000000000000030A
START = 04.196 09:30:28.6 FIRST DS LSN= 000000000000030B
STOP = 04.196 09:31:00.8 LAST DS LSN= 00000000000004D9
VOLSER=000000 STOPTIME = 04.196 09:31:00.8

CKPTCT=1 CHKPT ID = 04.196 09:30:28.6
STOP = 04.196 09:31:21.2 LAST DS LSN= 00000000000005F7
CHECKPOINT TYPES=40: SIMPLE=N SNAPQ=Y DUMPQ=N PURGE=N FREEZE=N
VOLSER=000000 STOPTIME = 04.196 09:31:21.2

CKPTCT=1 CHKPT ID = 04.196 09:31:14.9
STOP = 04.196 09:47:18.5 LAST DS LSN= 0000000000000828
VOLSER=000000 STOPTIME = 04.196 09:47:18.5

CKPTCT=2 CHKPT ID = 04.196 09:47:18.1


-------------------------------------------------------------------------------
START = 04.196 09:47:38.3 * SSID=BATCH1 VERSION=9.1
STOP = 04.196 09:47:39.5 #DSN=1
GSGNAME=IMSGSG1
DSN=BATCH1.UPDATEF.LOG UNIT=SYSDA
STOP = 04.196 09:47:39.5 LAST DS LSN= 000000000000009C
VOLSER=000000 STOPTIME = 04.196 09:47:39.5

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
LOGALL
START = 04.196 09:47:38.3 *
DHVNTZ02 HIDAM 1
DXVNTZ02 XDLBT04I 1
DIVNTZ02 DBHVSAM1 1
-------------------------------------------------------------------------------
SECLOG RECORD SIZE= 304
STOP = 04.196 09:47:39.5 #DSN=1
GSGNAME=IMSGSG1
DSN=IMSTESTL.IMS01.OLDSP1 UNIT=SYSDA
STOP = 04.196 09:47:39.5 LAST DS LSN= 000000000000009C

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0


-------------------------------------------------------------------------------
START = 04.196 09:47:50.4 * SSID=BATFPC VERSION=9.1
STOP = 04.196 09:47:57.6 #DSN=1
GSGNAME=**NULL**
DSN=IMSTESTM.BAT01.DBLOG1 UNIT=SYSDA
STOP = 04.196 09:47:57.6 LAST DS LSN= 00000000000000E4
VOLSER=222222 STOPTIME = 04.196 09:47:57.6

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
LOGALL
START = 04.196 09:47:50.4 *
DBOVLFPC VLOSAM01 1
-------------------------------------------------------------------------------
START = 04.196 09:48:07.6 * SSID=BATFPC VERSION=9.1
STOP = 04.196 09:48:08.4 #DSN=1
GSGNAME=**NULL** BBO
DSN=IMSTESTM.BBOFPC.BB1 UNIT=SYSDA
STOP = 04.196 09:48:08.4 LAST DS LSN= 000000000000002F
VOLSER=333333 STOPTIME = 04.196 09:48:08.4

CKPTCT=0 CHKPT ID = 00.000 00:00:00.0
LOGALL
START = 04.196 09:48:07.6 *
DBOVLFPC VLOSAM01 1


-------------------------------------------------------------------------------
STOP = 04.196 08:51:28.4 #DSN=1
GSGNAME=IMSGSG1
STOP = 04.196 08:51:28.4 LAST DS LSN= 00000000000002B9
VOLSER=000000 STOPTIME = 04.196 08:51:28.4

CKPTCT=1 CHKPT ID = 04.196 09:48:51.5
LOGALL
START = 04.196 09:48:49.8 *
DEDBDD01 DD01AR0 1
DHVNTZ02 HIDAM 1
DXVNTZ02 XDLBT04I 1
DIVNTZ02 DBHVSAM1 1
DBOHIDK5 CKOHIG1O 1
DXVHIDK5 CKVHIIXK 1
DBVHDJ05 CJVHDG1E 1
-------------------------------------------------------------------------------
STOP = 04.196 08:51:28.4 #DSN=1
GSGNAME=IMSGSG1
STOP = 04.196 08:51:28.4 LAST DS LSN= 00000000000002B9
VOLSER=000000 STOPTIME = 04.196 08:51:28.4

CKPTCT=1 CHKPT ID = 04.196 09:48:51.5


-------------------------------------------------------------------------------
STOP = 04.196 08:56:33.9 #DSN=2
GSGNAME=IMSGSG1
FIRST RECORD ID= 00000000000002BA PRILOG TOKEN= 5
START = 04.196 08:51:28.5 FIRST DS LSN= 00000000000002BA
STOP = 04.196 08:53:43.2 LAST DS LSN= 0000000000000444
VOLSER=000000 STOPTIME = 04.196 08:53:43.2

CKPTCT=2 CHKPT ID = 04.196 08:51:30.4
STOP = 04.196 08:56:33.9 LAST DS LSN= 00000000000006F3
VOLSER=000000 STOPTIME = 04.196 08:56:33.9

CKPTCT=2 CHKPT ID = 04.196 08:56:33.6
LOGALL
START = 04.196 08:51:28.5 *
DEDBDD01 DD01AR0 1

-------------------------------------------------------------------------------
STOP = 04.196 08:56:33.9 #DSN=2
GSGNAME=IMSGSG1
STOP = 04.196 08:53:43.2 LAST DS LSN= 0000000000000444
CHECKPOINT TYPES=C0: SIMPLE=Y SNAPQ=Y DUMPQ=N PURGE=N FREEZE=N
VOLSER=000000 STOPTIME = 04.196 08:53:43.2

CKPTCT=2 CHKPT ID = 04.196 08:51:30.4
STOP = 04.196 08:56:33.9 LAST DS LSN= 00000000000006F3
VOLSER=000000 STOPTIME = 04.196 08:56:33.9

CKPTCT=2 CHKPT ID = 04.196 08:56:33.6


-------------------------------------------------------------------------------
STOP = 04.196 08:55:33.4 #DSN=1
GSGNAME=IMSGSG1
STOP = 04.196 08:55:33.4 LAST DS LSN= 0000000000000205
VOLSER=000000 STOPTIME = 04.196 08:55:33.4

CKPTCT=2 CHKPT ID = 04.196 08:55:33.1
LOGALL
START = 04.196 08:55:03.1 *
DBDS ALLOC=0

-------------------------------------------------------------------------------
STOP = 04.196 08:55:33.4 #DSN=1
GSGNAME=IMSGSG1
DSN=IMSVS.SLDSP.IMS2.D04196.T0855031.V00 UNIT=SYSDA
STOP = 04.196 08:55:33.4 LAST DS LSN= 0000000000000205
VOLSER=000000 STOPTIME = 04.196 08:55:33.4

CKPTCT=2 CHKPT ID = 04.196 08:55:33.1
-------------------------------------------------------------------------------
PRIOLD
SSID=IMS2 # DD ENTRIES=1
STOP = 04.196 08:55:33.4 LAST DS LSN= 0000000000000205
VERSION=9.1


-------------------------------------------------------------------------------
PRIOLD
SSID=SYS3 # DD ENTRIES=4
STOP = 04.196 09:47:18.1 LAST DS LSN= 00000000000007AB
VERSION=9.1
STOP = 04.196 08:51:28.4 LAST DS LSN= 00000000000002B9
VERSION=9.1
STOP = 04.196 08:53:43.2 LAST DS LSN= 0000000000000444
VERSION=9.1
STOP = 04.196 08:56:33.9 LAST DS LSN= 00000000000006F3
VERSION=9.1
| Figure 68. Sample Listing of a RECON at the Active Site - Log Records (Part 10 of 10)
GSG Record
| -------------------------------------------------------------------------------
| GSG
| GSGNAME=IMSGSG1 #SGS=2 -SGNAME- -ROLE-
| STLSITE1 TRACKING LOCAL
| STLSITE2 ACTIVE
| CURRENT PRILOG TOKEN = 6 TAKEOVER TOKEN = 0
| MINIMUM PRILOG TOKEN = 1 DSN SEQ NUMBER = 0
| START TIME OF CURRENT LOG = 04.196 08:55:03.1
| HIGHEST ACTIVE SITE TIME = 00.000 00:00:00.0
| TRACKING SUBSYSTEM ID = **NULL**
| TAKEOVER IN PROGRESS
| DSP0180I NUMBER OF RECORDS LISTED IS 1
|
| Figure 69. Sample Listing of a RECON at the Active Site - GSG Record
|

SSYS Record
| -------------------------------------------------------------------------------
| SSYS
| SSID=SYS3 LOG START=04.201 07:39:28.9
| SSTYPE=ONLINE ABNORMAL TERM=OFF RECOVERY STARTED=NO BACKUP=NO
| TRACKED=NO TRACKER TERM=OFF SHARING COVERED DBS=NO
| IRLMID=**NULL** IRLM STATUS=NORMAL GSGNAME=IMSGSG1
|
| AUTHORIZED DATA BASES/AREAS=1 VERSION=9.1 XRF CAPABLE=NO
| ENCODED
| -DBD- -AREA- -LEVEL- -ACCESS INTENT- -STATE-
| DEDBDD01 DD01AR0 1 UPDATE 6
|
| Figure 70. Sample Listing of a RECON at the Active Site - SSYS Record
|
BACKOUT Record
| -------------------------------------------------------------------------------
| BACKOUT
| SSID=SYS3 #UORS=2
|
| RECOVERY TOKEN=E2E8E2F3404040400000000300000002
| TIME=04.196 09:49:19.0 PSB=PLVAPZ12
| INFLT BMP COLDEND
| ASSOCIATED DATA BASES=3
|
| BACKED DYN BKOUT
| -DBD- -OUT - -FAILURE-
| DHVNTZ02 NO NO
| DXVNTZ02 NO NO
| DIVNTZ02 NO NO
|
| TIME=04.196 09:49:19.1 PSB=PSBEJK05
| INFLT BMP COLDEND
|
| BACKED DYN BKOUT
| DBOHIDK5 NO NO
| DXVHIDK5 NO NO
| DBVHDJ05 NO NO
|
| Figure 71. Sample Listing of a RECON at the Active Site - BACKOUT Record
|

CAGRP and CA Records

| -------------------------------------------------------------------------------
| CAGRP
| GRPNAME=CAGRP1 GRPMAX=3 CA AVAIL=0 CA USED=1
| NOREUSE CAJCL=CAJCL DEFLTJCL=**NULL**
| #MEMBERS=4 -DBD- -DDN-
| DEDBJN21 DB21AR1
| DEDBJN21 DB21AR3
| DEDBJN21 DB21AR6
| DEDBJN21 DB21AR7
| -------------------------------------------------------------------------------
|
| CA
| DSN=IMSVS.CAGRP1.CA.CA165501 FILE SEQ=1
| CAGRP=CAGRP1 STOP = 04.196 09:24:54.6 *
| VOLSER=222222
| RUN = 04.196 08:55:39.9
| DBD=DEDBJN21 DDN=DB21AR1 PURGETIME = 04.196 09:22:45.2
| CHANGES ACCUMULATED=YES COMPLETE CA=YES INDOUBT EEQES=NO
| LSN = 000000000000 DSSN = 0000000001
| LRID = 00000000000003E4 USID = 0000000002
| LSN = 000000000000 DSSN = 0000000001
| LRID = 00000000000003FE USID = 0000000002
| LSN = 000000000000 DSSN = 0000000001
| LRID = 0000000000000418 USID = 0000000002
| LSN = 000000000000 DSSN = 0000000001
| LRID = 000000000000042D USID = 0000000002
|
| Figure 72. Sample Listing of a RECON at the Active Site - CAGRP and CA Records
|

DBGRP, DBDSGRP, and RECOVGRP Records

| -------------------------------------------------------------------------------
| DBGRP
| GRPNAME=DBGRP1 #MEMBERS=6 -DBD/AREA-
| DIVNTZ02
| DHVNTZ02
| DXVNTZ02
| DB21AR0
| DB21AR1
| DB21AR2
|
| DBDSGRP
| GRPNAME=FJKGRP #MEMBERS=5 -DBD- -DDN/AREA-
| DIVNTZ02 DBHVSAM1
| DIVNTZ02 DBHVSAM2
| DHVNTZ02 HIDAM
| DHVNTZ02 HIDAM2
| DXVNTZ02 XDLBT04I
|
| RECOVGRP
| GRPNAME=RCVGRP1 #MEMBERS=5 -DBD- -AREA-
| DIVNTZ02
| DHVNTZ02
| DXVNTZ02
| DEDBJN21 DB21AR0
| DEDBJN21 DB21AR1
|
| Figure 73. Sample Listing of a RECON at the Active Site - DBGRP, DBDSGRP, and
| RECOVGRP Records

DB (IMS) and Related Records

| -------------------------------------------------------------------------------
| DB
| DBD=DBOHIDK5 IRLMID=*NULL DMB#=3 TYPE=IMS
| DBRCVGRP=**NULL**
| FLAGS: COUNTERS:
| BACKOUT NEEDED =ON RECOVERY NEEDED COUNT =0
| EEQE COUNT =0
| OFR REQUIRED =NO
|
| ASSOCIATED SUBSYSTEM INFORMATION:
| ENCODED B/O NEEDED
| -SSID- -ACCESS INTENT- -STATE- -COUNT- -SS ROLE-
| SYS3 0 1 ACTIVE
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DBDS
| DSN=DBOHIDK5.CKXXI01O TYPE=IMS
| DBD=DBOHIDK5 DDN=CKOHIG1O DSID=001 DBORG=HIDAM DSORG=OSAM
| CAGRP=CAGRP2 GENMAX=2 IC AVAIL=0 IC USED=0 DSSN=00000001
| RECVJCL=ICRCVJCL
| FLAGS: COUNTERS:
| IC NEEDED =OFF
| IC RECOMMENDED =ON
| RECOV NEEDED =OFF
| -------------------------------------------------------------------------------
| ALLOC
| ALLOC =04.196 08:49:42.7 * ALLOC LRID =0000000000000000
| DSSN=0000000001 USID=0000000002 START = 04.196 09:48:49.8
|
| Figure 74. Sample Listing of a RECON at the Active Site - DB (IMS) and Related Records
| (Part 1 of 2)
|


-------------------------------------------------------------------------------
DB
DBD=DBVHDJ05 IRLMID=*NULL DMB#=2 TYPE=IMS
SHARE LEVEL=3 GSGNAME=**NULL** USID=0000000006
AUTHORIZED USID=0000000006 RECEIVE USID=0000000006 HARD USID=0000000006
RECEIVE NEEDED USID=0000000000
DBRCVGRP=**NULL**
FLAGS: COUNTERS:
BACKOUT NEEDED =ON RECOVERY NEEDED COUNT =0
READ ONLY =OFF IMAGE COPY NEEDED COUNT =0
PROHIBIT AUTHORIZATION=OFF AUTHORIZED SUBSYSTEMS =1
RECOVERABLE =YES HELD AUTHORIZATION STATE=0
EEQE COUNT =0
TRACKING SUSPENDED =NO RECEIVE REQUIRED COUNT =0
OFR REQUIRED =NO
ASSOCIATED SUBSYSTEM INFORMATION:

ENCODED B/O NEEDED
-SSID- -ACCESS INTENT- -STATE- -COUNT- -SS ROLE-
SYS3 0 1 ACTIVE
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=DBVHDJ05.CJXXD01E TYPE=IMS
DBD=DBVHDJ05 DDN=CJVHDG1E DSID=001 DBORG=HDAM DSORG=VSAM
CAGRP=CAGRP2 GENMAX=2 IC AVAIL=0 IC USED=2 DSSN=00000005
NOREUSE RECOVPD=0 OTHER DDN=**NULL**
DEFLTJCL=**NULL** ICJCL=ICJCL OICJCL=OICJCL RECOVJCL=RECOVJCL
RECVJCL=ICRCVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
RECEIVE NEEDED =OFF EEQE COUNT =0
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.196 09:30:57.0 * ALLOC LRID =0000000000000000
DSSN=0000000004 USID=0000000005 START = 04.196 09:29:46.6
DEALLOC =04.196 09:31:21.1 DEALLOC LRID =0000000000000000
ALLOC
ALLOC =04.196 08:49:43.0 * ALLOC LRID =0000000000000000
DSSN=0000000005 USID=0000000006 START = 04.196 09:48:49.8
IMAGE
RUN = 04.196 09:30:45.8 * RECORD COUNT =33
STOP = 00.000 00:00:00.0 BATCH USID=0000000004
IC1
DSN=IMSVS.DBVHDJ05.CJVHDG1E.IC.IC093043 FILE SEQ=0001
UNIT=SYSDA VOLS DEF=0001 VOLS USED=0001
VOLSER=222222
IMAGE
RUN = 04.196 09:31:42.8 * RECORD COUNT =33
STOP = 04.196 09:31:43.0 CONCUR USID=0000000005
IC1
DSN=IMSVS.DBVHDJ05.CJVHDG1E.IC.IC093140 FILE SEQ=0001
VOLSER=222222
Figure 74. 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

| -------------------------------------------------------------------------------
| DB
| DBD=DBOHIDK5 DMB#=5 CHANGE#=5 TYPE=HALDB
| SHARE LEVEL=3 GSGNAME=**NULL**
| DBRCVGRP=**NULL**
| PSNAME=**NULL** DBORG=PHIDAM DSORG=OSAM CURRENT PARTITION ID=00004
| FLAGS: COUNTERS:
| RECOVERABLE =YES PARTITIONS =4
| ONLINE REORG CAPABLE =YES DATA SET GROUP MEMBERS =2
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DB
| DBD=POHIDKA MASTER DB=DBOHIDK5 IRLMID=*NULL CHANGE#=2 TYPE=PART
| USID=0000000004 AUTHORIZED USID=0000000004 HARD USID=0000000004
| RECEIVE USID=0000000004 RECEIVE NEEDED USID=0000000000
| DSN PREFIX=IMSTESTS.DBOHIDK5 PARTITION ID=00001
| PREVIOUS PARTITION=**NULL** NEXT PARTITION=POHIDKB
| OLRIMSID=**NULL** ACTIVE DBDS=A-J
| REORG#=00000
| ONLINE REORG STATISTICS:
| OLR BYTES MOVED = 0
| OLR SEGMENTS MOVED = 0
| OLR ROOT SEGMENTS MOVED = 0
|
| 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 )
| K2000
| PARTITION HIGH KEY/STRING (HEX):
| D2F2F0F0F0404040404040404040404040404040404040404040404040404040
|
| OSAM BLOCK SIZE:
| A = 4096
| B = 4096
|
| FLAGS: COUNTERS:
| HELD AUTHORIZATION STATE=0
| EEQE COUNT =0
| OFR REQUIRED =NO OLR ACTIVE HARD COUNT =0
| PARTITION INIT NEEDED =NO OLR INACTIVE HARD COUNT =0
| OLREORG CURSOR ACTIVE =NO
| PARTITION DISABLED =NO
| ONLINE REORG CAPABLE =YES
| REORG INTENT =OFF
|
| Figure 75. Sample Listing of a RECON at the Active Site - DB (HALDB and PART) and
| Related Records (Part 1 of 11)
|

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.A00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAA DSID=001 DBORG=HIDAM DSORG=OSAM
CAGRP=**NULL** GENMAX=2 IC AVAIL=0 IC USED=0 DSSN=00000004
NOREUSE RECOVPD=0 OTHER DDN=POHIDKAM
DEFLTJCL=**NULL** ICJCL=PICJCL OICJCL=POICJCL RECOVJCL=PRECOJCL
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
IC RECOMMENDED =ON
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:03:22.4 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:03:20.4
ALLOC
ALLOC =04.194 11:04:10.1 * ALLOC LRID =0000000000000000
DSSN=0000000002 USID=0000000003 START = 04.194 11:04:06.6
ALLOC
ALLOC =04.194 11:09:03.6 * ALLOC LRID =0000000000000000
DSSN=0000000003 USID=0000000004 START = 04.194 11:07:30.7
ALLOC
ALLOC =04.194 11:19:31.3 * ALLOC LRID =0000000000000000
DSSN=0000000004 USID=0000000004 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:28.6 * USID = 0000000001
REORG#=00000
REORG
RUN = 04.194 11:03:02.2 * USID = 0000000001
REORG#=00000
REORG
RUN = 04.194 11:12:58.8 * USID = 0000000004
STOP = 04.194 11:13:06.2 ONLINE RECOV = NO
REORG
RUN = 04.194 11:19:31.3 * USID = 0000000004
REORG#=00000
STOP = 04.194 11:19:32.5 ONLINE RECOV = YES
REORG
RUN = 04.194 11:24:37.3 * USID = 0000000004
REORG#=00000
Figure 75. Sample Listing of a RECON at the Active Site - DB (HALDB and PART) and
Related Records (Part 2 of 11)


-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.B00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAB DSID=006 DBORG=HIDAM DSORG=OSAM
NOREUSE RECOVPD=0 OTHER DDN=POHIDKAN
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
IC RECOMMENDED =ON
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:03:22.3 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:03:20.4
ALLOC
ALLOC =04.194 11:04:10.0 * ALLOC LRID =0000000000000000
DSSN=0000000002 USID=0000000003 START = 04.194 11:04:06.6
ALLOC
ALLOC =04.194 11:09:03.7 * ALLOC LRID =0000000000000000
DSSN=0000000003 USID=0000000004 START = 04.194 11:07:30.7
ALLOC
ALLOC =04.194 11:19:31.8 * ALLOC LRID =0000000000000000
DSSN=0000000004 USID=0000000004 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:28.6 * USID = 0000000001
REORG
RUN = 04.194 11:03:02.2 * USID = 0000000001
REORG
RUN = 04.194 11:12:58.8 * USID = 0000000004
REORG
RUN = 04.194 11:19:31.3 * USID = 0000000004
REORG
RUN = 04.194 11:24:37.3 * USID = 0000000004


-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.L00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
RECOV NEEDED =OFF EEQE COUNT =0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.M00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAM DSID=001 DBORG=HIDAM DSORG=OSAM
NOREUSE RECOVPD=0 OTHER DDN=POHIDKAA
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
IC RECOMMENDED =ON
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:12:58.8 * ALLOC LRID =0000000000000000
DSSN=0000000004 USID=0000000004 START = 04.194 11:07:30.7
ALLOC
ALLOC =04.194 11:24:37.3 * ALLOC LRID =0000000000000000
DSSN=0000000005 USID=0000000004 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:12:58.8 * USID = 0000000004
REORG
RUN = 04.194 11:19:31.3 * USID = 0000000004
REORG
RUN = 04.194 11:24:37.3 * USID = 0000000004


-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.N00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAN DSID=006 DBORG=HIDAM DSORG=OSAM
NOREUSE RECOVPD=0 OTHER DDN=POHIDKAB
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
IC RECOMMENDED =ON
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:12:59.3 * ALLOC LRID =0000000000000000
DSSN=0000000004 USID=0000000004 START = 04.194 11:07:30.7
ALLOC
ALLOC =04.194 11:24:37.8 * ALLOC LRID =0000000000000000
DSSN=0000000005 USID=0000000004 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:12:58.8 * USID = 0000000004
REORG
RUN = 04.194 11:19:31.3 * USID = 0000000004
REORG
RUN = 04.194 11:24:37.3 * USID = 0000000004
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.X00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=POHIDKAY
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBOHIDK5.Y00001 TYPE=PART
DBD=POHIDKA DDN=POHIDKAY DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=POHIDKAX
FLAGS: COUNTERS:
-------------------------------------------------------------------------------


-------------------------------------------------------------------------------
DB
DBD=POHIDKB MASTER DB=DBOHIDK5 IRLMID=*NULL CHANGE#=3 TYPE=PART
USID=0000000004 AUTHORIZED USID=0000000004 HARD USID=0000000004
RECEIVE USID=0000000004 RECEIVE NEEDED USID=0000000000
DSN PREFIX=IMSTESTS.DBOHIDK5 PARTITION ID=00002
PREVIOUS PARTITION=POHIDKA NEXT PARTITION=POHIDKC
OLRIMSID=**NULL** ACTIVE DBDS=A-J
FREE SPACE:
FREE BLOCK FREQ FACTOR=0 FREE SPACE PERCENTAGE=0
PARTITION HIGH KEY/STRING (CHAR): (LENGTH=5 )

K4000
PARTITION HIGH KEY/STRING (HEX):
D2F4F0F0F0404040404040404040404040404040404040404040404040404040
OSAM BLOCK SIZE:

A = 4096
B = 4096
FLAGS: COUNTERS:
BACKOUT NEEDED =OFF RECOVERY NEEDED COUNT =0
HELD AUTHORIZATION STATE=0
EEQE COUNT =0
OFR REQUIRED =NO OLR ACTIVE HARD COUNT =0
PARTITION INIT NEEDED =NO OLR INACTIVE HARD COUNT =0
OLREORG CURSOR ACTIVE =NO
PARTITION DISABLED =NO
ONLINE REORG CAPABLE =YES
REORG INTENT =OFF
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKB DDN=POHIDKBA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------

ALLOC
ALLOC =04.194 11:03:25.4 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:03:20.4
ALLOC
ALLOC =04.194 11:04:10.8 * ALLOC LRID =0000000000000000
DSSN=0000000002 USID=0000000003 START = 04.194 11:04:06.6
ALLOC
ALLOC =04.194 11:08:38.8 * ALLOC LRID =0000000000000000
DSSN=0000000003 USID=0000000004 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:29.0 * USID = 0000000001
REORG
RUN = 04.194 11:03:02.6 * USID = 0000000001
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKB DDN=POHIDKBB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:03:25.5 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:03:20.4
ALLOC
ALLOC =04.194 11:04:13.5 * ALLOC LRID =0000000000000000
DSSN=0000000002 USID=0000000003 START = 04.194 11:04:06.6
ALLOC
ALLOC =04.194 11:08:39.3 * ALLOC LRID =0000000000000000
DSSN=0000000003 USID=0000000004 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:29.0 * USID = 0000000001
REORG
RUN = 04.194 11:03:02.6 * USID = 0000000001


-------------------------------------------------------------------------------
DBDS
DBD=POHIDKB DDN=POHIDKBL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKB DDN=POHIDKBX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DB
DBD=POHIDKC MASTER DB=DBOHIDK5 IRLMID=*NULL CHANGE#=4 TYPE=PART
PREVIOUS PARTITION=POHIDKB NEXT PARTITION=POHIDKD
FREE SPACE:

K6000
D2F6F0F0F0404040404040404040404040404040404040404040404040404040
OSAM BLOCK SIZE:

A = 4096
B = 4096
FLAGS: COUNTERS:
EEQE COUNT =0
REORG INTENT =OFF
-------------------------------------------------------------------------------


-------------------------------------------------------------------------------
DBDS
DBD=POHIDKC DDN=POHIDKCA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:08:14.8 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:29.5 * USID = 0000000001
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKC DDN=POHIDKCB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:08:14.8 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:29.5 * USID = 0000000001
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKC DDN=POHIDKCL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------


-------------------------------------------------------------------------------
DBDS
DBD=POHIDKC DDN=POHIDKCX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DB
DBD=POHIDKD MASTER DB=DBOHIDK5 IRLMID=*NULL CHANGE#=5 TYPE=PART
PREVIOUS PARTITION=POHIDKC NEXT PARTITION=**NULL**
FREE SPACE:

.....
FFFFFFFFFF404040404040404040404040404040404040404040404040404040
OSAM BLOCK SIZE:

A = 4096
B = 4096
FLAGS: COUNTERS:
EEQE COUNT =0
REORG INTENT =OFF
-------------------------------------------------------------------------------


-------------------------------------------------------------------------------
DBDS
DBD=POHIDKD DDN=POHIDKDA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:07:52.2 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:29.9 * USID = 0000000001
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKD DDN=POHIDKDB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.194 11:07:52.3 * ALLOC LRID =0000000000000000
DSSN=0000000001 USID=0000000002 START = 04.194 11:07:30.7
REORG
RUN = 04.194 11:02:29.9 * USID = 0000000001
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKD DDN=POHIDKDL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDKD DDN=POHIDKDX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------

DB (FP) and Related Records

| -------------------------------------------------------------------------------
| DB
| DBD=DEDBDD01 DMB#=8 TYPE=FP
| SHARE LEVEL=1
| FLAGS: COUNTERS:
| RECOVERY NEEDED COUNT =0
| IMAGE COPY NEEDED COUNT =0
| PROHIBIT AUTHORIZATION=OFF AUTHORIZED AREAS =0
| RECOVERABLE =YES EEQE COUNT =0
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DBDS
| DBD=DEDBDD01 AREA=DD01AR0 TYPE=FP
| SHARE LEVEL=1 DSID=00001 DBORG=DEDB DSORG=VSAM
| GSGNAME=IMSGSG1 USID=0000000003
| NOREUSE RECOVPD=0 NOVSO PREOPEN NOPRELOAD
| CFSTR1=**NULL** CFSTR2=**NULL** NOLKASID NOMAS
| DEFLTJCL=**NULL** ICJCL=ICJCL RECVJCL=ICRCVJCL RECOVJCL=RECOVJCL
| DBRCVGRP=**NULL**
| FLAGS: COUNTERS:
| IC NEEDED =OFF ADS AVAIL # =1
| RECOV NEEDED =OFF REGISTERED ADS # =1
| DATABASE LEVEL TRACK =YES EEQE COUNT =0
| RECEIVE NEEDED =OFF
| OFR REQUIRED =NO
| TRACKING SUSPENDED =NO
| HSSP CIC IN PROGRESS =NO
|
| ADS LIST:
| CREATE
| -ADS DDN--ADS DSN- -STAT- -RUNNING-
| DD01AR0 DD01AR0 AVAIL NO
| -------------------------------------------------------------------------------
| ALLOC
| ALLOC =04.196 09:48:51.8 * ALLOC LRID =0000000000000000
| DSSN=0000000001 USID=0000000002 START = 04.196 09:48:49.8
|
| ALLOC
| ALLOC =04.196 08:51:31.6 * ALLOC LRID =0000000000000000
| DSSN=0000000002 USID=0000000003 START = 04.196 08:51:28.5
|
| IMAGE
| RUN = 96.100 08:15:11.2 *
| STOP = 96.100 08:16:12.3 SMSCIC USID=0000000001
|
| IC1
| DSN=IMSVS.DEDBDD01.SMSCIC.DSN1 FILE SEQ=0001
| VOLSER=IMSCC1
|
| Figure 76. Sample Listing of a RECON at the Active Site - DB (FP) and Related Records
|

Sample RECON Listing Tracking Site
Sample Listing of a RECON at the Tracking Site

Beginning with Figure 77, the following figures comprise a listing of a RECON
from a tracking site in an RSR environment. “Fields Present in a Listing of a
RECON by Record Type” on page 532 describes the fields that can be present in a
listing of the RECON.
In This Section:
v “RECON Status Record”
v “Log Records” on page 509
v “GSG Record” on page 515
v “SSYS Record” on page 516
v “BACKOUT Record” on page 516
v “CAGRP and CA Records” on page 517
v “DBDSGRP Records” on page 518
v “DB (IMS) and Related Records” on page 519
v “DB (HALDB and PART) and Related Records” on page 521
v “DB (FP) and Related Records” on page 532
RECON Status Record

| -------------------------------------------------------------------------------
| RECON
| RECOVERY CONTROL DATA SET, IMS V9R1
| DMB#=8 INIT TOKEN=04196F1616485F
| NOFORCER LOG DSN CHECK=CHECK17 STARTNEW=NO
| TAPE UNIT=3400 DASD UNIT=SYSDA TRACEOFF SSID=**NULL**
| LIST DLOG=YES CA/IC/LOG DATA SETS CATALOGED=NO
| MINIMUM VERSION = 7.1 CROSS DBRC SERVICE LEVEL ID= 00001
| LOG RETENTION PERIOD=00.000 00:15:00.0
| COMMAND AUTH=NONE HLQ=**NULL**
| SIZALERT DSNUM=15 VOLNUM=16 PERCENT= 95
| LOGALERT DSNUM=3 VOLNUM=16
| REORG NUMBER VERIFICATION=YES
| TIME STAMP INFORMATION:
|
| TIMEZIN = %SYS -LABEL- -OFFSET-
| PDT -07:00
| PST -08:00
|
| OUTPUT FORMAT: DEFAULT = LOCORG NONE PUNC YY
| CURRENT = LOCORG NONE PUNC YY
|
|
| IMSPLEX = ** NONE **
|
| -DDNAME- -STATUS- -DATA SET NAME-
| RECON3 SPARE IMSTESTL.IMS.RECON3
|
| Figure 77. Sample Listing of a RECON at the Tracking Site - RECON Status Record
|

Log Records
|
| -------------------------------------------------------------------------------
| STOP = 04.196 09:28:46.6 #DSN=3
| GSGNAME=IMSGSG1 TRACKING
|
| DSN=IMSTESTL.RSR.RLDS1.N0000005
| STOP = 04.196 09:24:54.6 LAST DS LSN= 000000000000044C
| #DS CHECKPOINTS= 1 CHKPT ID = 00.000 00:00:00.0
|
| STOP = 04.196 09:28:46.4 LAST DS LSN= 0000000000000624
|
| STOP = 04.196 09:28:46.6 LAST DS LSN= 0000000000000689
|
| LOGALL
| START = 04.196 09:21:02.7 *
| -------------------------------------------------------------------------------
| PRISLD RECORD SIZE= 624
| STOP = 04.196 09:28:46.6 #DSN=3
| GSGNAME=IMSGSG1 TRACKING
|
| DSN=IMSTESTL.RSR.ARCH1.N0000004
| STOP = 04.196 09:24:54.6 LAST DS LSN= 000000000000044C
| CHECKPOINT TYPES=80: SIMPLE=Y SNAPQ=N DUMPQ=N PURGE=N FREEZE=N
|
| STOP = 04.196 09:28:46.4 LAST DS LSN= 0000000000000624
| CHECKPOINT TYPES=88: SIMPLE=Y SNAPQ=N DUMPQ=N PURGE=N FREEZE=Y
|
| STOP = 04.196 09:28:46.6 LAST DS LSN= 0000000000000689
|
| Figure 78. Sample Listing of a RECON at the Tracking Site - Log Records (Part 1 of 7)
|
|

CHECKPOINT TYPES=00: SIMPLE=N SNAPQ=N DUMPQ=N PURGE=N FREEZE=N

-------------------------------------------------------------------------------
STOP = 04.196 09:47:18.3 #DSN=4
GSGNAME=IMSGSG1 TRACKING
DSN=**** COMPRESSED DATA SET ****

STOP = 04.196 09:31:06.2 LAST DS LSN= 00000000000004D9
#DS CHECKPOINTS= 1
DSN=IMSTESTL.RSR.RLDS1.N0000023
STOP = 04.196 09:31:21.2 LAST DS LSN= 00000000000005F7
#DS CHECKPOINTS= 1 CHKPT ID = 04.196 09:31:14.9
STOP = 04.196 09:47:18.1 LAST DS LSN= 00000000000007BD
START = 04.196 09:47:18.1 FIRST DS LSN= 00000000000007BE
STOP = 04.196 09:47:18.3 LAST DS LSN= 0000000000000828
LOGALL
START = 04.196 09:29:46.6 *
DBDS ALLOC=0
-------------------------------------------------------------------------------
STOP = 04.196 09:47:18.3 #DSN=4
DSN=**** COMPRESSED DATA SET ****

STOP = 04.196 09:31:06.2 LAST DS LSN= 00000000000004D9
#DS CHECKPOINTS= 1
DSN=IMSTESTL.RSR.ARCH1.N0000022
STOP = 04.196 09:31:21.2 LAST DS LSN= 00000000000005F7
STOP = 04.196 09:47:18.1 LAST DS LSN= 00000000000007BD
START = 04.196 09:47:18.1 FIRST DS LSN= 00000000000007BE
STOP = 04.196 09:47:18.3 LAST DS LSN= 0000000000000828
Figure 78. Sample Listing of a RECON at the Tracking Site - Log Records (Part 2 of 7)

|
-------------------------------------------------------------------------------
STOP = 04.196 09:47:39.4 #DSN=1
STOP = 04.196 09:47:39.4 LAST DS LSN= 000000000000009C
LOGALL
START = 04.196 09:47:38.3 *
DHVNTZ02 HIDAM 1
DXVNTZ02 XDLBT04I 1
DIVNTZ02 DBHVSAM1 1
-------------------------------------------------------------------------------
STOP = 04.196 08:51:28.4 #DSN=2
STOP = 04.196 08:49:42.8 LAST DS LSN= 0000000000000235
STOP = 04.196 08:51:28.4 LAST DS LSN= 00000000000002B9
LOGALL
START = 04.196 09:48:49.8 *
DEDBDD01 DD01AR0 1
DHVNTZ02 HIDAM 1
DXVNTZ02 XDLBT04I 1
DIVNTZ02 DBHVSAM1 1
-------------------------------------------------------------------------------
STOP = 04.196 08:51:28.4 #DSN=2
STOP = 04.196 08:49:42.8 LAST DS LSN= 0000000000000235

STOP = 04.196 08:51:28.4 LAST DS LSN= 00000000000002B9
-------------------------------------------------------------------------------
STOP = 04.196 08:56:33.8 #DSN=5
STOP = 04.196 08:51:30.6 LAST DS LSN= 0000000000000378
DSN=IMSTESTL.RSR.SLDS1.N0000047
STOP = 04.196 08:53:43.2 LAST DS LSN= 0000000000000444
STOP = 04.196 08:53:43.3 LAST DS LSN= 00000000000004C2
START = 04.196 08:53:43.3 FIRST DS LSN= 00000000000004C3
STOP = 04.196 08:56:33.7 LAST DS LSN= 0000000000000692
STOP = 04.196 08:56:33.8 LAST DS LSN= 00000000000006F3
LOGALL
START = 04.196 08:51:28.5 *
DEDBDD01 DD01AR0 1


-------------------------------------------------------------------------------
STOP = 04.196 08:56:33.8 #DSN=5
STOP = 04.196 08:51:30.6 LAST DS LSN= 0000000000000378
STOP = 04.196 08:53:43.2 LAST DS LSN= 0000000000000444
STOP = 04.196 08:53:43.3 LAST DS LSN= 00000000000004C2
START = 04.196 08:53:43.3 FIRST DS LSN= 00000000000004C3
STOP = 04.196 08:56:33.7 LAST DS LSN= 0000000000000692
STOP = 04.196 08:56:33.8 LAST DS LSN= 00000000000006F3
-------------------------------------------------------------------------------
STOP = 04.196 08:55:33.3 #DSN=2
STOP = 04.196 08:55:33.2 LAST DS LSN= 00000000000001A4
START = 04.196 08:55:33.2 FIRST DS LSN= 00000000000001A5
STOP = 04.196 08:55:33.3 LAST DS LSN= 0000000000000205

LOGALL
START = 04.196 08:55:03.1 *
DBDS ALLOC=0
-------------------------------------------------------------------------------
STOP = 04.196 08:55:33.3 #DSN=2
STOP = 04.196 08:55:33.2 LAST DS LSN= 00000000000001A4
START = 04.196 08:55:33.2 FIRST DS LSN= 00000000000001A5
STOP = 04.196 08:55:33.3 LAST DS LSN= 0000000000000205
-------------------------------------------------------------------------------
PRIOLD
SSID=SYS3 # DD ENTRIES=2
STOP = 04.196 08:53:56.8 LAST DS LSN= 000000000000051E
VERSION=9.1
STOP = 04.196 08:57:01.5 LAST DS LSN= 00000000000007AF
VERSION=9.1


-------------------------------------------------------------------------------
PRITSLDS RECORD SIZE= 464
STOP = 04.196 08:57:01.5 #DSN=2
GSGNAME=IMSGSG1
STOP = 04.196 08:53:56.8 LAST DS LSN= 000000000000051E
VOLSER=000000 STOPTIME = 04.196 08:53:56.8

CKPTCT=1 CHKPT ID = 04.196 09:20:23.6
STOP = 04.196 08:57:01.5 LAST DS LSN= 00000000000007AF
VOLSER=000000 STOPTIME = 04.196 08:57:01.5

CKPTCT=1 CHKPT ID = 04.196 08:57:01.1
| Figure 78. Sample Listing of a RECON at the Tracking Site - Log Records (Part 7 of 7)
GSG Record
| -------------------------------------------------------------------------------
| GSG
| GSGNAME=IMSGSG1 #SGS=2 -SGNAME- -ROLE-
| STLSITE1 TRACKING
| STLSITE2 ACTIVE LOCAL
| CURRENT PRILOG TOKEN = 6 TAKEOVER TOKEN = 0
| MINIMUM PRILOG TOKEN = 1 DSN SEQ NUMBER = 52
| START TIME OF CURRENT LOG = 04.196 08:55:03.1
| HIGHEST ACTIVE SITE TIME = 04.196 08:56:33.8
| TRACKING SUBSYSTEM ID = SYS3
| TAKEOVER IN PROGRESS
|
| Figure 79. Sample Listing of a RECON at the Tracking Site - GSG Record
|

SSYS Record
| -------------------------------------------------------------------------------
| SSYS
| SSTYPE=TRACKER ABNORMAL TERM=OFF RECOVERY STARTED=NO BACKUP=NO
| TRACKED=NO TRACKER TERM=OFF SHARING COVERED DBS=NO
| GSGNAME=IMSGSG1
|
| AUTHORIZED DATA BASES/AREAS=3 VERSION=9.1 XRF CAPABLE=NO
| ENCODED
| DHVNTZ02 **NULL** 3 EXCLUSIVE 7
| DXVNTZ02 **NULL** 3 EXCLUSIVE 7
| DIVNTZ02 **NULL** 3 EXCLUSIVE 7
|
| SSYS
| SSTYPE=ONLINE ABNORMAL TERM=ON RECOVERY STARTED=NO BACKUP=NO
| TRACKED=YES TRACKER TERM=OFF SHARING COVERED DBS=NO
| IRLMID=**NULL** IRLM STATUS=NORMAL GSGNAME=IMSGSG1
|
| AUTHORIZED DATA BASES/AREAS=4 VERSION=9.1
XRF CAPABLE=NO
| ENCODED
| DEDBDD01 DD01AR0 1 UPDATE 6
| DHVNTZ02 **NULL** 3 UPDATE 6
| DXVNTZ02 **NULL** 3 UPDATE 6
| DIVNTZ02 **NULL** 3 UPDATE 6
| -------------------------------------------------------------------------------
|
| Figure 80. Sample Listing of a RECON at the Tracking Site - SSYS Record
|
BACKOUT Record
| -------------------------------------------------------------------------------
| BACKOUT
| SSID=SYS3 #UORS=1
|
| TIME=04.196 09:49:19.0 PSB=PLVAPZ12
| INFLT BMP
|
| BACKED DYN BKOUT
| DHVNTZ02 NO NO
| DXVNTZ02 NO NO
| DIVNTZ02 NO NO
|
| Figure 81. Sample Listing of a RECON at the Tracking Site - BACKOUT Record
|

CAGRP and CA Records

| -------------------------------------------------------------------------------
| CAGRP
| GRPNAME=CAGRP1 GRPMAX=3 CA AVAIL=0 CA USED=1
| NOREUSE CAJCL=CAJCL DEFLTJCL=**NULL**
| #MEMBERS=4 -DBD- -DDN-
| DEDBJN21 DB21AR1
| DEDBJN21 DB21AR3
| DEDBJN21 DB21AR6
| DEDBJN21 DB21AR7
| -------------------------------------------------------------------------------
|
| CA
| DSN=IMSVS.CAGRP1.CA.CA165501 FILE SEQ=1
| CAGRP=CAGRP1 STOP = 04.196 09:24:54.6 *
| VOLSER=222222
| RUN = 04.196 08:55:47.2
| LSN = 000000000000 DSSN = 0000000001
| LRID = 00000000000003E4 USID = 0000000002
| LSN = 000000000000 DSSN = 0000000001
| LRID = 00000000000003FE USID = 0000000002
| CHANGES ACCUMULATED=NO COMPLETE CA=YES INDOUBT EEQES=NO
| LSN = 000000000000 DSSN = 0000000000
| LRID = 0000000000000000 USID = 0000000000
| CHANGES ACCUMULATED=NO COMPLETE CA=YES INDOUBT EEQES=NO
| LSN = 000000000000 DSSN = 0000000000
| LRID = 0000000000000000 USID = 0000000000
|
| Figure 82. Sample Listing of a RECON at the Tracking Site - CAGRP and CA Records
|

DBDSGRP Records
| -------------------------------------------------------------------------------
| DBGRP
| GRPNAME=DBGRP1 #MEMBERS=6 -DBD/AREA-
| DIVNTZ02
| DHVNTZ02
| DXVNTZ02
| DB21AR0
| DB21AR1
| DB21AR2
|
| DBDSGRP
| GRPNAME=FJKGRP #MEMBERS=5 -DBD- -DDN/AREA-
| DIVNTZ02 DBHVSAM1
| DIVNTZ02 DBHVSAM2
| DHVNTZ02 HIDAM
| DHVNTZ02 HIDAM2
| DXVNTZ02 XDLBT04I
|
| RECOVGRP
| GRPNAME=RCVGRP1 #MEMBERS=5 -DBD- -AREA-
| DIVNTZ02
| DHVNTZ02
| DXVNTZ02
| DEDBJN21 DB21AR0
| DEDBJN21 DB21AR1
|
| Figure 83. Sample Listing of a RECON at the Tracking Site - DBDSGRP Records
|

DB (IMS) and Related Records

| -------------------------------------------------------------------------------
| DB
| DBD=DBOHIDK5 IRLMID=*NULL DMB#=2 TYPE=IMS
| DBRCVGRP=**NULL**
| FLAGS: COUNTERS:
| EEQE COUNT =0
| OFR REQUIRED =NO
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DBDS
| DSN=DBOHIDK5.CKXXI01O TYPE=IMS
| DBD=DBOHIDK5 DDN=CKOHIG1O DSID=001 DBORG=HIDAM DSORG=OSAM
| CAGRP=CAGRP2 GENMAX=2 IC AVAIL=0 IC USED=0 DSSN=00000000
| RECVJCL=ICRCVJCL
| FLAGS: COUNTERS:
| IC NEEDED =OFF
| RECOV NEEDED =OFF
| -------------------------------------------------------------------------------
| DSP0180I NUMBER OF RECORDS LISTED IS 2
| DSP0203I COMMAND COMPLETED WITH CONDITION CODE 00
| DSP0220I COMMAND COMPLETION TIME 04.198 08:57:56.2
| IMS VERSION 9 RELEASE 1 DATA BASE RECOVERY CONTROL PAGE 0004
| LIST.DB DBD(DHVNTZ02) DBDS
| -------------------------------------------------------------------------------
| DB
| DBD=DHVNTZ02 IRLMID=*NULL DMB#=5 TYPE=IMS
| SHARE LEVEL=3 GSGNAME=IMSGSG1 USID=0000000003
| DBRCVGRP=RCVGRP1
| FLAGS: COUNTERS:
| BACKOUT NEEDED =ON RECOVERY NEEDED COUNT =0
| OFR REQUIRED =NO
|
| SYS3 EXCLUSIVE 7 1 TRACKING
|
| Figure 84. Sample Listing of a RECON at the Tracking Site - DB (IMS) and Related Records
| (Part 1 of 2)
|

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=DHVNTZ02.FKXXI01E TYPE=IMS
DBD=DHVNTZ02 DDN=HIDAM DSID=001 DBORG=HIDAM DSORG=VSAM
RECVJCL=ICRCVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =04.196 09:47:39.0 * ALLOC LRID =0000000000000009
DSSN=0000000001 USID=0000000002 START = 04.196 09:47:38.3
ALLOC
ALLOC =04.196 09:49:18.9 * ALLOC LRID =0000000000000155
DSSN=0000000002 USID=0000000003 START = 04.196 09:48:49.8
IMAGE
RUN = 04.196 09:18:36.0 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000001
IC1
DSN=IMSTESTG.DHVNTZ02.HIDAM.BASE.IC FILE SEQ=0001
VOLSER=IMSRAW
RECOV
RUN = 04.196 09:18:47.9 * RUN USID = 0000000001
-------------------------------------------------------------------------------
DBDS
DSN=DHVNTZ02.FKXXI02E TYPE=IMS
DBD=DHVNTZ02 DDN=HIDAM2 DSID=002 DBORG=HIDAM DSORG=VSAM
RECVJCL=ICRCVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
IMAGE
RUN = 04.196 09:18:36.0 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000001
IC1
DSN=IMSTESTG.DHVNTZ02.HIDAM2.BASE.IC FILE SEQ=0001
VOLSER=IMSRAW
RECOV
RUN = 04.196 09:18:48.0 * RUN USID = 0000000001
Figure 84. Sample Listing of a RECON at the Tracking Site - DB (IMS) and Related Records
| (Part 2 of 2)

DB (HALDB and PART) and Related Records

| -------------------------------------------------------------------------------
| DB
| DBD=DBHIDJ03 DMB#=6 CHANGE#=5 TYPE=HALDB
| SHARE LEVEL=3 GSGNAME=IMSGSG1
| PSNAME=**NULL** DBORG=PHIDAM DSORG=OSAM CURRENT PARTITION ID=00004
| FLAGS: COUNTERS:
| RECOVERABLE =YES PARTITIONS =4
| ONLINE REORG CAPABLE =YES DATA SET GROUP MEMBERS =2
| REORG INTENT =OFF
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DBD=POHIDJA MASTER DB=DBHIDJ03 IRLMID=*NULL CHANGE#=2 TYPE=PART
| USID=0000000003 AUTHORIZED USID=0000000003 HARD USID=0000000003
| RECEIVE USID=0000000003 RECEIVE NEEDED USID=0000000000
| DBRCVGRP=**NULL**
| DSN PREFIX=IMSTESTS.DBHIDJ03 PARTITION ID=00001
| PREVIOUS PARTITION=**NULL** NEXT PARTITION=POHIDJB
| OLRIMSID=**NULL** ACTIVE DBDS=A-J
| REORG#=00000
| ONLINE REORG STATISTICS:
| OLR BYTES MOVED = 0
| OLR SEGMENTS MOVED = 0
| OLR ROOT SEGMENTS MOVED = 0
|
| 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 )
| J0200
| PARTITION HIGH KEY/STRING (HEX):
| D1F0F2F0F0404040404040404040404040404040404040404040404040404040
|
| OSAM BLOCK SIZE:
| A = 4096
| B = 4096
|
| FLAGS: COUNTERS:
| OFR REQUIRED =NO OLR ACTIVE HARD COUNT =0
| PARTITION INIT NEEDED =NO OLR INACTIVE HARD COUNT =0
| OLREORG CURSOR ACTIVE =NO
| PARTITION DISABLED =NO
| ONLINE REORG CAPABLE =YES
|
| IMS2 EXCLUSIVE 7 0 TRACKING
|
| Figure 85. Sample Listing of a RECON at the Tracking Site - DB (HALDB and PART) and
|

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBHIDJ03.A00001 TYPE=PART
DBD=POHIDJA DDN=POHIDJAA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =03.287 10:49:51.9 * ALLOC LRID =000000000000000C
DSSN=0000000001 USID=0000000002 START = 03.287 10:49:50.0
ALLOC
ALLOC =03.287 10:55:40.2 * ALLOC LRID =0000000000000012
DSSN=0000000002 USID=0000000003 START = 03.287 10:55:36.8
IMAGE
RUN = 03.287 11:22:19.0 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000003
IC1
DSN=IMSVS.POHIDJA.POHIDJAA.IC.IC112153 FILE SEQ=0001
VOLSER=222222
REORG
RUN = 03.287 10:49:13.7 * USID = 0000000001
RECOV
RUN = 03.287 11:47:59.9 * RUN USID = 0000000000
Figure 85. Sample Listing of a RECON at the Tracking Site - DB (HALDB and PART) and


-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBHIDJ03.B00001 TYPE=PART
DDN=POHIDJAB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =03.287 10:49:51.8 * ALLOC LRID =0000000000000008
DSSN=0000000001 USID=0000000002 START = 03.287 10:49:50.0
ALLOC
ALLOC =03.287 10:55:40.1 * ALLOC LRID =000000000000000D
DSSN=0000000002 USID=0000000003 START = 03.287 10:55:36.8
IMAGE
RUN = 03.287 11:23:05.7 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000003
IC1
DSN=IMSVS.POHIDJA.POHIDJAB.IC.IC112154 FILE SEQ=0001
VOLSER=222222
REORG
RUN = 03.287 10:49:13.7 * USID = 0000000001
RECOV
RUN = 03.287 11:54:13.3 * RUN USID = 0000000000
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBHIDJ03.L00001 TYPE=PART
DBD=POHIDJA DDN=POHIDJAL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DSN=IMSTESTS.DBHIDJ03.X00001 TYPE=PART
DBD=POHIDJA DDN=POHIDJAX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DB
DBD=POHIDJB MASTER DB=DBHIDJ03 IRLMID=*NULL CHANGE#=3 TYPE=PART
DBRCVGRP=**NULL**
DSN PREFIX=IMSTESTS.DBHIDJ03 PARTITION ID=00002
PREVIOUS PARTITION=POHIDJA NEXT PARTITION=POHIDJC
FREE SPACE:

J0400
D1F0F4F0F0404040404040404040404040404040404040404040404040404040
OSAM BLOCK SIZE:

A = 4096
B = 4096
FLAGS: COUNTERS:
DATABASE LEVEL TRACK =YES EEQE COUNT =0
ASSOCIATED SUBSYSTEM INFORMATION:

ENCODED B/O NEEDED
-SSID- -ACCESS INTENT- -STATE- -COUNT- -SS ROLE-
IMS2 EXCLUSIVE 7 0 TRACKING

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJB DDN=POHIDJBA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =03.287 10:49:56.6 * ALLOC LRID =0000000000000C62
DSSN=0000000001 USID=0000000002 START = 03.287 10:49:50.0
ALLOC
ALLOC =03.287 10:55:44.5 * ALLOC LRID =0000000000000992
DSSN=0000000002 USID=0000000003 START = 03.287 10:55:36.8
IMAGE
RUN = 03.287 11:23:42.4 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000003
IC1
DSN=IMSVS.POHIDJB.POHIDJBA.IC.IC112155 FILE SEQ=0001
VOLSER=222222
REORG
RUN = 03.287 10:49:14.0 * USID = 0000000001
RECOV
RUN = 03.287 12:01:41.5 * RUN USID = 0000000000


-------------------------------------------------------------------------------
DBDS
DBD=POHIDJB DDN=POHIDJBB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
ALLOC
ALLOC =03.287 10:49:55.4 * ALLOC LRID =0000000000000C2A
DSSN=0000000001 USID=0000000002 START = 03.287 10:49:50.0
ALLOC
ALLOC =03.287 10:55:44.4 * ALLOC LRID =000000000000092E
DSSN=0000000002 USID=0000000003 START = 03.287 10:55:36.8
IMAGE
RUN = 03.287 11:24:19.6 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000003
IC1
DSN=IMSVS.POHIDJB.POHIDJBB.IC.IC112155 FILE SEQ=0001
VOLSER=222222
REORG
RUN = 03.287 10:49:14.0 * USID = 0000000001
RECOV
RUN = 03.287 12:10:36.0 * RUN USID = 0000000000
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJB DDN=POHIDJBL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJB DDN=POHIDJBX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DB
DBD=POHIDJC MASTER DB=DBHIDJ03 IRLMID=*NULL CHANGE#=4 TYPE=PART
DBRCVGRP=**NULL**
PREVIOUS PARTITION=POHIDJB NEXT PARTITION=POHIDJD
FREE SPACE:
J0600
D1F0F6F0F0404040404040404040404040404040404040404040404040404040
OSAM BLOCK SIZE:

A = 4096
B = 4096
FLAGS: COUNTERS:

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJC DDN=POHIDJCA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
IMAGE
RUN = 03.287 11:24:57.2 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000001
IC1
DSN=IMSVS.POHIDJC.POHIDJCA.IC.IC112156 FILE SEQ=0001
VOLSER=222222
RECOV
RUN = 03.287 12:16:02.1 * RUN USID = 0000000000
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJC DDN=POHIDJCB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
IMAGE
RUN = 03.287 11:25:37.6 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000001
IC1
DSN=IMSVS.POHIDJC.POHIDJCB.IC.IC112156 FILE SEQ=0001
VOLSER=222222
RECOV
RUN = 03.287 12:20:52.3 * RUN USID = 0000000000


-------------------------------------------------------------------------------
DBDS
DBD=POHIDJC DDN=POHIDJCL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJC DDN=POHIDJCX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DB
DBD=POHIDJD MASTER DB=DBHIDJ03 IRLMID=*NULL CHANGE#=5 TYPE=PART
DBRCVGRP=**NULL**
PREVIOUS PARTITION=POHIDJC NEXT PARTITION=**NULL**
FREE SPACE:

.....
FFFFFFFFFF404040404040404040404040404040404040404040404040404040
OSAM BLOCK SIZE:

A = 4096
B = 4096
FLAGS: COUNTERS:

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJD DDN=POHIDJDA DSID=001 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
IMAGE
RUN = 03.287 11:26:12.4 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000001
IC1
DSN=IMSVS.POHIDJD.POHIDJDA.IC.IC112157 FILE SEQ=0001
VOLSER=222222
RECOV
RUN = 03.287 12:26:02.7 * RUN USID = 0000000000
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJD DDN=POHIDJDB DSID=006 DBORG=HIDAM DSORG=OSAM
RECVJCL=PRECVJCL
FLAGS: COUNTERS:
IC NEEDED =OFF
RECOV NEEDED =OFF
-------------------------------------------------------------------------------
IMAGE
RUN = 03.287 11:26:54.2 * RECORD COUNT =0
STOP = 00.000 00:00:00.0 BATCH USID=0000000001
IC1
DSN=IMSVS.POHIDJD.POHIDJDB.IC.IC112157 FILE SEQ=0001
VOLSER=222222
RECOV
RUN = 03.287 12:30:52.7 * RUN USID = 0000000000


-------------------------------------------------------------------------------
DBDS
DBD=POHIDJD DDN=POHIDJDL DSID=003 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
DBDS
DBD=POHIDJD DDN=POHIDJDX DSID=005 DBORG=INDEX DSORG=VSAM
OTHER DDN=**NULL**
FLAGS: COUNTERS:

DB (FP) and Related Records

| LIST.DB DBD(DEDBDD01) DBDS
| -------------------------------------------------------------------------------
| DB
| DBD=DEDBDD01 DMB#=7 TYPE=FP
| SHARE LEVEL=1
| FLAGS: COUNTERS:
| RECOVERY NEEDED COUNT =0
| IMAGE COPY NEEDED COUNT =0
| PROHIBIT AUTHORIZATION=OFF AUTHORIZED AREAS =0
| RECOVERABLE =YES EEQE COUNT =0
| -------------------------------------------------------------------------------
| -------------------------------------------------------------------------------
| DBDS
| DBD=DEDBDD01 AREA=DD01AR0 TYPE=FP
| SHARE LEVEL=1 DSID=00001 DBORG=DEDB DSORG=VSAM
| GSGNAME=IMSGSG1 USID=0000000003
| NOREUSE RECOVPD=0 NOVSO PREOPEN NOPRELOAD
| CFSTR1=**NULL** CFSTR2=**NULL** NOLKASID NOMAS
| DEFLTJCL=**NULL** ICJCL=ICJCL RECVJCL=ICRCVJCL RECOVJCL=RECOVJCL
| DBRCVGRP=**NULL**
| FLAGS: COUNTERS:
| IC NEEDED =OFF ADS AVAIL # =1
| RECOV NEEDED =OFF REGISTERED ADS # =1
| RECEIVE NEEDED =OFF
| OFR REQUIRED =NO
| TRACKING SUSPENDED =NO
| HSSP CIC IN PROGRESS =NO
|
| ADS LIST:
| CREATE
| -ADS DDN--ADS DSN- -STAT- -RUNNING-
| DD01AR0 DD01AR0 AVAIL NO
| -------------------------------------------------------------------------------
|
| ALLOC
| ALLOC =04.196 09:48:51.8 * ALLOC LRID =00000000000000FB
| DSSN=0000000001 USID=0000000002 START = 04.196 09:48:49.8
|
| ALLOC
| ALLOC =04.196 08:51:31.6 * ALLOC LRID =00000000000003B6
| DSSN=0000000002 USID=0000000003 START = 04.196 08:51:28.5
|
| Figure 86. Sample Listing of a RECON at the Tracking Site - DB (FP) and Related Records
|
Fields Present in a Listing of a RECON by Record Type
The following sections describe the fields that can be present in a listing of the
RECON by record type:
v “Fields Present in a RECON Record” on page 533
v “Fields Present in a Log Record” on page 537
v “Fields Present in a LOGALL Record” on page 539
v “Fields Present in an Online Log Record” on page 540

Fields in a RECON Listing
v “Fields Present in a GSG Record” on page 541

v “Fields Present in a SSYS Record” on page 542
v “Fields Present in a BACKOUT Record” on page 543
v “Fields Present in a CAGRP Record” on page 544
v “Fields Present in a CA Record” on page 544
v “Fields Present in a Data Group Record” on page 546
v “Fields Present in a DB (IMS) Record” on page 547
| v “Fields Present in a DB (HALDB) Record” on page 549
v “Fields Present in a DB (PART) Record” on page 550
v “Fields Present in a DB (Fast Path) Record” on page 554
v “Fields Present in a DBDS (non-Fast Path) Record” on page 555
v “Fields Present in a DBDS (Fast Path) Record” on page 556
v “Fields Present in an ALLOC Record” on page 560
v “Fields Present in an IMAGE Record” on page 561
v “Fields Present in a REORG Record” on page 562
v “Fields Present in a RECOV Record” on page 563
Examples of many of these fields appear in Figure 67 on page 480 and Figure 77 on
page 508.
Definition:
A group of lines refers to the lines following the referring statement whose row
spans the width of the table. The group of lines ends at the next statement that
spans the width of the table, unless otherwise specified.
Fields Present in a RECON Record

A RECON record’s fields and their corresponding line numbers are described in
Table 37.
Table 37. Fields Present in the RECON Record
Line
Record Type Number Field Contents
RECON 1
2 RECOVERY CONTROL DATA SET, IMS Identifies the version and release of the
VxRx RECON.
| 3 LAST USED DMB#= nnn nnn represents the DMB number last
assigned, if less than 32 767. If the DMB
number has reached 32 767, nnn represents
the last reused DMB. Only printed if greater
than zero.
INIT TOKEN= token The token assigned to this RECON when it
was initialized.
4 FORCER | NOFORCER Indicates whether databases must be
registered in RECON. FORCER indicates that
all databases must be registered.
NOFORCER indicates that all databases do
not need to be registered.
LOG DSN CHECK= The type of log data set name checking;
xxxxxx xxxxxx is CHECK17, CHECK44, or
NOCHECK.

Fields in a RECON Record
Table 37. Fields Present in the RECON Record (continued)

Line
STARTNEW= YES | NO When I/O errors exist on one of the
RECON, YES indicates that new jobs are to
start. NO indicates that no new jobs are to
start.
5 TAPE UNIT= unittype The default unit type for log data sets,
NOREUSE image copy data sets, and
NOREUSE change accumulation data sets
that reside on tape devices.
DASD UNIT= unittype The default unit type for log data sets,
NOREUSE image copy data sets, and
NOREUSE change accumulation data sets
that reside on DASD devices.
TRACEON | TRACEOFF TRACEON indicates DBRC is to produce
external GTF trace entries.
SSID= xxxxxxxx The IMS subsystem default name.
| TOTAL NUMBER OF RAPS The total number of RAPS or ROOTS (if not
| PROCESSED = value zero-PHDAM) .
| or
| TOTAL NUMBER OF ROOTS TO

| PROCESS = value
6 LISTDLOG= YES | NO Indicates whether the names of log data sets
deleted from RECON are to be listed.
CA | IC | LOG DATA SETS Indicates whether CA, IC, and log data sets
CATALOGED= YES | NO are to be treated as if they are cataloged. To
bypass volume serial checking of utility DD
statements, specify YES and the data set is
cataloged. If you specify NO (or the data set
is not cataloged), volume serial checking
takes place.
7 MINIMUM VERSION = x.x Indicates the minimum version of IMS that
is allowed to sign on using these RECONs.
| CROSS DBRC SERVICE LEVEL The current enabled service level ID as set
ID=nnnn by the CHANGE.RECON CDSLID()
command.
8 LOG RETENTION PERIOD= Indicates the minimum amount of time that
yy.ddd hh:mm:ss.t DBRC is to keep log records in RECON.
9 COMMAND AUTH=SAF | EXIT | Indication of the level of DBRC command
BOTH | authorization being performed.
NONE
HLQ=hlq name High level qualifier of the resource name
used to determine command authorization.
**NULL** is printed when command
authorization is not enabled.


Line
10 TRACE OPTIONS= This line is printed only if an IBM
options representative has instructed you to gather
documentation for problem analysis. It
indicates that an IBM representative has
provided instructions to enable DBRC trace
records to be written to the DBRC trace table
for problem analysis. The IBM representative
will have provided the options.
SIZALERT= xxxxxxxx xxxxxxxx xx The (optional) thresholds that trigger
messages to warn you that a record has
grown unnaturally large. Field values can be
dsnum, volnum and percent.
11 LOGALERT= xxxxxxxx xxxxxxxx The (optional) threshold that triggers the
DSP0287W message (warning you when you
just have time to shut down an online IMS
subsystem before it ABENDs due to the
PRILOG record exceeding RECORDSIZE).
Field values can be dsnum, volnum and
percent.
| 12 REORG NUMBER VERIFICATION=YES Identifies if reorganization number
| NO verification is performed for partition
databases.
The following line is printed only if a failure occurred during a multiple update to the RECON:
13 UPDATE TYPE= nnnn The type of multiple update that was in
progress.
DBID= xxxxxxxx xxxxxxxx Data set name and data set ddname of the
DBDS involved in the multiple update. Can
be blank.
CAGRP= xxxxxxxx Name of the CA group involved in the
multiple update. Contains blanks if no group
was involved.
NEW DDN= xxxxxxxx New ddname, if any, that was associated
with the DBDS that was involved in the
multiple update. Contains blanks if no new
name or DBDS was involved.
14 OLD RECORD KEY This field is printed only if the multiple
update involves a key change.
15 KEY TYPE= *xxxxx A description of the record type. The asterisk
(*) is printed only if the record is available
for future use (it is either new or scheduled
for reuse). Whenever an unrecognizable
record key type is found, BADTYP.KEY is
printed, together with the key in
hexadecimal characters.
DBD= xxxxxxxx, The database name and data set ddname of
DDN= xxxxxxxx a DBDS. If the record is PRILOG, SECLOG,
IPRI, or ISEC, the fields are printed as
**NULL**. If the record is a CAGRP or DB
record, the DBD field is **NULL**, and the
DDN field contains the name of the CA
group or database.


Line
TIME= time_stamp The time stamp of the key of the record.
16-17 NEW RECORD KEY This field is printed only if a new record key
is being added. Additional fields in this part
of the record are printed as shown in line 8.
18-19 BASE RECORD KEY This field is printed only if a new record key
is being changed. The remaining fields in
this part of the record are printed as shown
in line 8.
20-21 SSID= ssidname IRLMID= irlmidname Information about the multiple update.
SHARE LVL #= n #DB= n B/O#= n
22 FLAGS: A heading for the following lines.
23 RECOV= ON | OFF Information about the multiple update.
NORECOV= ON | OFF
ICON= ON | OFF
ICOFF= ON | OFF
24 NORMAL= ON | OFF Information about the multiple update.
ABNORMAL= ON | OFF
STARTRCV= ON | OFF
ENDRECOV= ON | OFF
25 READON= ON | OFF Information about the multiple update.
READOFF= ON | OFF
AUTH= ON | OFF
NOAUTH= ON | OFF
26 B/O DONE= ON | OFF Information about the multiple update.
PASS 1= ON | OFF
BACKOUT= ON | OFF
SHARELVL= ON | OFF
27 TIME STAMP INFORMATION: Heading for section containing RECON time
stamp information.
28 TIMEZIN= offset User-specified input time stamp offset
default. If no offset is specified, this field
displays %SYS meaning that the offset of the
z/OS clock is to be used.
-LABEL- -OFFSET- These column headings are printed if a Time
Zone Label Table has been defined.
29-nnn label offset The list of defined time zone offset labels
with their corresponding offset values.
30 OUTPUT FORMAT: Time-stamp output format settings.
DEFAULT= offset display form yearsize Default time-stamp output format settings.
31 CURRENT= Current time-stamp output format settings.
offset display form yearsize
32 IMSPLEX=imsplex_name The IMSplex name associated with the
RECON.
33 -DDNAME- -STATUS- -DATA SET Column headings for the following one to
NAME- three lines.


Line
34 RECON1 | RECON2 | The ddname, status, and data set name of
RECON3 the Copy1 RECON.
COPY1
dsname
35-36 RECON1 | RECON2 | These lines identify the ddname, status, and
RECON3 | COPY2 | data set name of the RECON backup
DISCARDED | SPARE | (Copy2), the RECON spare, and any
UNAVAILABLE RECONs that are not usable (DISCARDED).
dsname or blank A RECON that could not be accessed is
shown as UNAVAILABLE (unknown
dsname and status).
Fields Present in a Log Record

A log record’s fields, including types, and their corresponding line numbers are
described in Table 38.
Table 38. Fields Present in a Log Record
Record Type Line Number Field Contents
PRILOG or 1
SECLOG or
PRISLD or
SECSLD or
IPRI or ISEC or
IPRISL or
ISECSL or
PRITSLDS or
SECTSLDS or
IPRITSLD or
ISECTSLD
RECORD SIZE=nnnnnn The logical record size for PRILOG, SECLOG,
PRISLD, SECSLD, PRITSLDS, and SECTSLDS
records. This field is not present for other log
record types.
2 START= time_stamp* Time stamp of the start time (that is, original
open time) of the log data set. An asterisk (*)
indicates that this time stamp is part of the
record key.
SSID= ssidname The name of the IMS subsystem.
VERSION=version The version of the IMS subsystem that created
the log.
3 STOP= time_stamp Time stamp of the stop time (that is, close time)
of the log data set. Zeros indicate that the data
set is still open.
#DSN= nn The number of data sets in the log data set. A
value of zero indicates that no data set has been
created.
4 GSGNAME= gsgname Identifies the name of the GSG to which the
subsystem producing this log belongs.
The following 4 fields are printed if the condition in the contents column is true:

Fields in Log Records
Table 38. Fields Present in a Log Record (continued)

TRACKING This log data set was originally created by an
active IMS subsystem of the nonlocal service
group and transported to the tracking site.
GAP There is a gap in the log data sets of this record.
PREV-GAP There is a gap in a previous log record of the
same global service group.
BBO Identifies the log record as it was created by
batch backout. If the record was not created by
batch backout, this field is blank.
5 FIRST RECORD ID= lsn The log record sequence number of the first log
record that was written during initialization of
the IMS subsystem.
PRILOG TOKEN= n The numeric log token assigned sequentially to
PRILOG records for the same GSG.
6 EARLIEST CHECKPOINT= This line is printed only for online PRILOGs. It
time_stamp indicates the earliest checkpoint required by IMS
emergency restart (/ERE or /ERE BUILDQ).
Rows 7-13 apply to active log records and repeat for each log data set. Rows 7-10 apply to tracking records and
repeat for each log data set.
7 DSN= log.dsname The data set name of the log data set described
in this record. ****COMPRESSED DATA SET ****
indicates that PRILOG compression has
removed unneeded DSN entries.
ERR This field is printed if a previous command was
used to indicate that an error exists in the log
data set.
UNIT= unittype Unit type to be used for substitution during the
GENJCL process.
8 START= time_stamp Start time of the data set entry in the log data
set.
FIRST RECORD LSN= lsn The log record sequence number of the first log
record of the data set.
9 STOP= time_stamp Stop time of the data set entry in the log data
set. Zeros indicate that the data set is still open.
LAST RECORD LSN= lsn The log record sequence number of the last log
10 FILE SEQ= nnnn The file sequence number of the log data set.
This field is not printed for tracking logs.
#VOLUMES= nnn The number of volumes for each data set entry.
This field is not printed for tracking logs.
#DS CHECKPOINTS= n Count of checkpoint records in the log data set,
CHKPT ID= time_stamp and the checkpoint ID value. This field is
printed only for tracking logs.

Fields in Log Records
Table 38. Fields Present in a Log Record (continued)

CHECKPOINT TYPES=xx This line is printed only for SLDS records. xx is
SIMPLE= Y | N a hexadecimal representation of the checkpoint
SNAPQ = Y | N types contained on the log. The values for xx
DUMPQ = Y | N can be:
PURGE = Y | N
Bit 0 Simple checkpoint
FREEZE = Y | N
Bit 1 SNAPQ checkpoint
Bit 2 DUMPQ checkpoint
Bit 3 PURGE checkpoint
Bit 4 FREEZE checkpoint
Bit 5 - 7 Not used
For more information, see the note that follows
this table.
11 VOLSER= volser STOPTIME= Volume serial number and stop time. This field
(ACTIVE) time_stamp is not printed for tracking logs.
12 CKPTCT= n CHKPT ID= Checkpoint count and ID value.
(ACTIVE) time_stamp
13 LOCK SEQUENCE # = A unique number, issued sequentially, given to a
(ACTIVE) database resource to identify that it is in locked
by a requestor. A locked resource cannot be
used until the current requestor has finished
using it.
FEOV Indicates that the corresponding log data set at
the active site was closed by a /DBR with the
forced end of volume option. This field is
printed only for tracking PRILOGs.
Note: DBRC sets the CHECKPOINT TYPES bit values and also sets the Y or N
values. Y is set if at least one checkpoint of the given type starts on the data
set. There could be more than one checkpoint on the log and there is no
guarantee that there is a complete checkpoint on the log. The number of
checkpoints listed on the CHECKPOINT TYPES line might not be the same
number that is listed as the CKPTCT value. For example, there could be
three simple checkpoints on a log. Only SIMPLE=Y would be displayed and
CKPTCT or #DS CHECKPOINTS would have a value of two. CKPTCT or
#DS CHECKPOINTS would have a value of two because that is the
maximum allowed.
Fields Present in a LOGALL Record

A log allocation record’s fields and their corresponding line numbers are described
in Table 39.
Table 39. Fields Present in the LOGALL Record
LOGALL 1
2 START= time_stamp* The start time of the log data set that contains
change records for DBDSs included in this
record. If the asterisk (*) is present, it indicates
that this time stamp also occurs in the key of
the LOGALL record.

Fields in a LOGALL Record
Table 39. Fields Present in the LOGALL Record (continued)

3 EARLIEST ALLOC The start time of the oldest DBDS allocation for
TIME=time_stamp the log. The ALLOC record with the earliest
allocation time is for the DBDS that is listed first
in the following lines. If there are no DBDS
allocations for the log, zeroes are displayed.
4 DBDS ALLOC= nnnn The number of allocated DBDSs for this log data
set.
-DBD- -DDN- -ALLOC- These headings are printed only if the LOGALL
record contained records of each DBDS that was
allocated between the start and stop time
stamps of the log data set. The DBDSs are listed
in order of their earliest ALLOC time, starting
with the DBDS with the oldest allocation.
5-nnn dbdname ddname nnnn The database name, data set ddname, and
number of allocations of the DBDS during the
time span of the allocated log.
Fields Present in an Online Log Record

An online log record’s fields and their corresponding line numbers are described in
Table 40.
Table 40. Fields Present in an Online Log Record
PRIOLD or 1
SECOLD or
IPRIOL or
ISECOL
2 SSID= xxxxxxxx The name of the IMS subsystem.
# DD ENTRIES= n The number of ddnames in the OLDS.
3 EARLIEST CHECKPOINT= This line is printed only for PRIOLD records. It
time_stamp indicates the earliest checkpoint required by IMS
emergency restart (/ERE or /ERE BUILDQ).
4 DDNAME= ddname The ddname of the OLDS.
DSN=log-dsname The data set name of the OLDS.
5 START= time_stamp 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 of the first log
6 STOP= time_stamp Time stamp of the stop time (that is, close time)
of the log data set. Zeros indicate that the data
set is not closed.
LAST DS LSN= lsn The log record sequence number of the last log
7 STATUS= ARC NEEDED | The status of the DD entry in the OLDS record.
ARC STARTED | This field applies to the PRIOLDS record only.
ARC SCHED |
ARC COMPLT | ACTIVE

Fields in an Online Log Record
Table 40. Fields Present in an Online Log Record (continued)

ERROR= CLOSE | PREV Indicates a close error on an OLDS or on a
previous OLDS record. This field applies to the
PRIOLDS record only.
FEOV= YES | NO A specification of FEOV=YES forces an
end-of-output data set at the end of archiving
DFSOLP02. This is done to conform to the
recovery point established by the /DBR
command. This field applies to the PRIOLDS
record only.
AVAIL | UNAVAIL Identifies whether the OLDS is available for
regular use. UNAVAIL indicates that the data
set has invalid data or an I/O error. This field
applies to PRIOLDS or SECOLDS records only.
8 PRILOG TIME= time_stamp Time stamp of the time of the first OLDS the
subsystem used. This is also the start time of the
PRILOG and PRISLD records corresponding to
the subsystem invocation.
ARCHIVE JOB NAME= jobname Name of the archive job generated by the
GENJCL ARCHIVE function.
blank line These blank lines are printed as visual
separators only when the OLDS has more than
one DD entry. The format of each data set entry
is a repetition of lines 4 through 8 above.
Fields Present in a GSG Record

A global service group record’s fields and their corresponding line numbers are
Table 41. Fields Present in a GSG Record
GSG 1
2 GSGNAME= gsgname Identifies the name of the GSG.
#SGS= The number of service groups in this GSG.
-SGNAME- -ROLE- Headings for the following lines 3 through 10.
3-4 sgnamesgrole Service group name and service group role
(active or tracking).
LOCAL Identifies which service group is the local one of
the GSG.
5 CURRENT PRILOG TOKEN= The highest PRILOG token at the local site of
token this GSG.
TAKEOVER TOKEN= token The current PRILOG token at the time an RSR
takeover was initiated at the local site.
6 MINIMUM PRILOG TOKEN= The minimum PRILOG that is maintained at the
token local site of the GSG.
DSN SEQ NUMBER= number The initial DSN sequence number value for the
GSG group.
7 START TIME OF CURRENT The start time of the PRILOG with the current
LOG= time_stamp log token.

Fields in a GSG Record
Table 41. Fields Present in a GSG Record (continued)

8 HIGHEST ACTIVE SITE TIME= The highest time received from the active site.
time_stamp This field is only meaningful to the tracking site.
9 TRACKING SUBSYSTEM ID= Subsystem identification of the tracking
ssid subsystem. This field is null at the active site.
10 TAKEOVER IN PROGRESS This is printed when an RSR takeover has been
initiated at the local site.
Fields Present in a SSYS Record

A subsystem record’s fields and their corresponding line numbers are described in
Table 42.
Table 42. Fields Present in a SSYS Record
SSYS 1
2 SSID= ssidname The name of the IMS subsystem.
LOG START= time_stamp The earliest log data set start time associated
with this system or the log data set start time
created by batch backout.
3 SSTYPE= Indication of whether this is an IMS online,
ONLINE | BATCH batch, or tracking subsystem.
| TRACKER
ABNORMAL TERM= The value of this flag field is normally OFF. If it
ON | OFF is ON, the system has been abnormally ended
and database recovery is required.
RECOVERY STARTED= If the value of this field is YES, this subsystem
YES | NO has signed on for recovery-started processing.
Normally, this value is NO.
BACKUP= YES | NO If the value of this field is YES, there is an
alternate subsystem.
4 TRACKED= YES | NO Indicates whether this is the record of an active
subsystem being tracked by the tracking site.
TRACKER TERM= ON | OFF Indicates whether the tracking subsystem has
terminated. This field only applies to the
tracking subsystem record.
SHARING COVERED DBS= Indicates that this active subsystem is sharing
YES | NO RSR-covered databases.
5 IRLMID= xxxxxx The IRLM with which this subsystem is
communicating.
IRLM STATUS= Indicates the status of the IRLM. NORMAL
NORMAL | indicates no failure. This field does not apply to
IRLM FAILURE | an RSR tracking subsystem.
COMM FAILURE |
SYS FAILURE
GSG NAME= gsgname Identifies the name of the global service group
to which the subsystem belongs.
6 BACKUP IRLMID= irlmname Identifies the IRLM with which the alternate
subsystem is communicating. Listed only if an
alternate subsystem exists.

Fields in a SSYS Record
Table 42. Fields Present in a SSYS Record (continued)

BACKUP TOKEN= nnnn Identifies the backup token. Listed only if an
alternate subsystem exists.
7 AUTHORIZED Indicates that this subsystem is currently
DATABASES | authorized to n databases or areas.
AREAS=nnn
8 VERSION= n Identifies the IMS release level through which
the subsystem signed on.
XRF CAPABLE=NO|YES Identifies if the subsystem is XRF capable.
If the number of authorized databases or areas is not zero, the following lines (up to the BACKOUT record line) list
those that are currently authorized:
9-10 -DBD- -AREA- -LEVEL- Column headings for the following line or lines
-ACCESSINTENT- ENCODED that describe the currently authorized databases
-STATE- or areas.
11-nnn dbdname areaname sharelvl access This is the name of the database or area that is
encoded state currently authorized by this subsystem, the
share level, the access intent by this subsystem,
and the encoded state.
Fields Present in a BACKOUT Record

A backout record’s fields and their corresponding line numbers are described in
Table 43.
Table 43. Fields Present in a BACKOUT Record
BACKOUT 1
2 SSID= xxxxxxxx The name of the associated IMS subsystem.
#UORS= nn The number of units of recovery (UORs) in the
BACKOUT record.
3 RECOVERY TOKEN= 32 Describes a specific UOR.
hexadecimal digits
4 TIME= time_stamp The time stamp of the beginning of the UOR
(found in the X'5607' log record).
PSB= psbname Name of the PSB associated with the UOR.
5 CANDIDATE INFLT | INDT UOR indicators, one or more of which might be
BMP COLDEND CMD BATCH listed. CANDIDATE: UOR identified by BBO
utility prior to restart (COLDSTART | ACTIVE
control statement). Reset (to null) when
promoted to backout-needed status by IMS
restart. INFLT, In-flight UOR due to an IMS
failure. INDT, In-doubt UOR due to a CCTL or
DBCTL failure. BMP, UOR due to a BMP.
COLDEND, Cold start has ended. UOR can only
be resolved by BBO. CMD, UOR entry has been
modified by commands (CHANGE, DELETE,
NOTIFY). BATCH, UOR due to a dynamic
backout failure of DL/I batch.
6 ASSOCIATED DATABASES= nn Number of databases associated with the UOR.
7, 8 BACKED DYN BKOUT -DBD- Heading for the following list of associated
-OUT- -FAILURE databases.

Fields in a BACKOUT Record
Table 43. Fields Present in a BACKOUT Record (continued)

9-nnn dbname YES | NO YES | NO Database name. The first YES or NO indicates
whether the UOR has been backed out for the
database. The second YES or NO indicates
whether the UOR is the result of a dynamic
backout failure.
Fields Present in a CAGRP Record

A change accumulation group record’s fields and their corresponding line numbers
are described in Table 44.
Table 44. Fields Present in a CAGRP Record
CAGRP 1
2 GRPNAME= cagrpnam The name of the CA group.
GRPMAX= nnnn The maximum number of change accumulation
run records that can be associated with this
group, whether available or in use.
CA AVAIL= nnnn The number of available change accumulation
run records currently in RECON for this group.
CA USED= nnnn The number of in-use change accumulation run
records currently in RECON for this group.
3 REUSE | NOREUSE Indicates whether change accumulation data
sets can be reused and whether empty ones can
be created for subsequent use (REUSE) or not
(NOREUSE).
CAJCL= cajclmem The name of the member of a partitioned data
set that contains skeletal JCL for this CA group.
DEFLTJCL= member The name of the member of a partitioned data
set. This member contains the skeletal JCL
default values for the user-defined keywords to
be used for this CA group.
4 #MEMBERS= nnnn This number of DBDSs and areas that belong to
this CA group.
-DBD- -DDN- These headings and the following lines are
printed only if some DBDSs are members of this
group.
5-nnn dbdname ddname The database name and data set ddname of a
DBDS that is a member of this CA group.
Fields Present in a CA Record

A change accumulation record’s fields and their corresponding line numbers are
Table 45. Fields Present in a CA Record
CA 1

Fields in a CA Record
Table 45. Fields Present in a CA Record (continued)

2 *DSN= chge.accum.dsname The asterisk is printed if the change
accumulation data set identified in this record is
available for use. DSN= is the change
accumulation data set name that has been or
could be used as the output data set during a
run of the Database Change Accumulation
utility.
FILE SEQ= nnnn The file sequence number of the first volume of
this data set.
3 CAGRP= cagrpname Name of the CA group to which the change
accumulation record belongs.
UNIT= unittype Unit type to be used for substitution during the
GENJCL process.
4 CREATE | STOP= time_stamp* CREATE is printed if the data set is available for
future use. In this case, the time stamp is the
time that the record was created or made
available for recycling. STOP is printed for
in-use records. In this case, the time stamp is the
stop time of the last log volume that was
processed by the Database Change
Accumulation utility. If SUBSET is printed (see
line 6), the time stamp is the start time of the
first unselected log. The asterisk (*) indicates
that this time stamp is in the record key.
VOLS DEF= nnnn VOLS USED= The number of volumes that have been specified
nnnn for use by this change accumulation data set
and the number of volumes that were used in a
Database Change Accumulation utility run. For
available change accumulation data sets, if the
data set can be reused, this field contains the
same value as the VOLS DEF field. Otherwise, it
indicates the number of volumes that were
actually used.
5-nnn VOLSER= volser1, volser2,... Volume serial numbers of the volumes on which
the change accumulation data set resides or is to
reside. Only as many lines as necessary are used
to list the volume.
The following lines are printed only if the change accumulation data set has been used during a run of the Change
Accumulation utility (the change accumulation data set is no longer available):
6 RUN= time_stamp This time stamp represents the time of the run
of the Change Accumulation utility during
which this record was used.
ERR This indicates that you have marked the change
accumulation data set as unusable because of a
previous error.
SUBSET This indicates that a subset of logs were
processed when the CA was created.
* The asterisk (*) indicates that COMP or SUBSET
were specified in the CHANGE.CA or NOTIFY.CA
commands.
These headings are printed only if purge times exist in the record. If purge times exist, there is one line in the format
labeled below (7-9) for each DBDS in the CA group.

Fields in a CA Record
Table 45. Fields Present in a CA Record (continued)

7 DBD= dbdname The database name and data set ddname of the
DDN= ddname DBDS.
PURGETIME= time_stamp Change records occurring before this time stamp
for the corresponding DBDS have been ignored
by the Database Change Accumulation utility.
8 CHANGES ACCUMULATED= YES is printed if the Database Change
YES | NO Accumulation utility run accumulated any
changes for the corresponding DBDS. NO is
printed if no changes were found for DBDS.
COMPLETE CA= YES | NO YES is printed if the log subset for the
corresponding DBDS is complete. NO is printed
if the log subset for the DBDS is incomplete.
INDOUBT EEQES= YES is printed to indicate that in doubt EEQEs
YES | NO were accumulated for the corresponding DBDS.
NO is printed if no in doubt EEQEs were
accumulated.
9 LSN= lsn The lock sequence number of the last change
accumulated for the DBDS is listed.
DSSN= dssn The data set sequence number of the last change
accumulated for the DBDS is listed.
10 LRID= log_record_ID The last log record ID of the last change
accumulated for the DBDS is listed in this field.
USID= update_set_ID The last update set ID of the last change
accumulated for the DBDS is listed in this field.
Fields Present in a Data Group Record

A database data group record’s fields and their corresponding line numbers are
Table 46. Fields Present in the DBDSGRP Record
DBDSGRP 1 Type of group: DBDS, DB, or Recovery.
DBGRP or
RECOVGRP
2 GRPNAME= grpname Name of the group.
#MEMBERS= nnn Number of members belonging to the group.
-DBD- -DDN/AREA- Any or all of these headings can be printed,
-DBD/AREA- or -DBD- -AREA- depending on the group members that exist. For
DBDS groups, the heading is -DBD- -DDN/AREA-.
For DB groups, the heading is-DBD/AREA-. For
recovery groups, the heading is -DBD- -AREA-.
3-nnn dbdname ddname/areaname For DBDSGRP, dbdname = DB name,
ddname/areaname = DBDS name or area name.
For DBGRP, dbdname = DL/I DB name or DEDB
area name. ddname/areaname is blank. For
RECOVGRP, dbdname = DB name,
ddname/areaname = area name if DB is a DEDB,
or blank if DB is DL/I.

Fields in a DB (IMS) Record
Fields Present in a DB (IMS) Record

An IMS database record’s fields and their corresponding line numbers are
Table 47. Fields Present in the DB (IMS) Record
DB (IMS) 1
2 DBD= dbdname Name of the database.
IRLMID= xxxxx Identifies the IRLM when the share level of this
database is 2. This field is printed only when
SHARE LEVEL=2.
DMB#= nnn The value assigned when this database 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 which authorized
subsystems can share this database.
GSGNAME= gsgname Identifies the name of the GSG to which this
database belongs.
USID= n The highest update set identifier for this
database.
4 AUTHORIZED USID= n The identifier of the current update set that is
being applied to the database.
RECEIVE USID= n The update set identifier of the last image copy
received for this database. The update set ID
only applies to shadow databases at the tracking
site.
HARD USID= n The update set identifier of the latest changes
that were written to the database.
5 RECEIVE NEEDED USID= n This only applies to shadow databases at the
tracking site. If n is not zero, this indicates that
image copies with the identified USID are
required for the DBDSs marked “receive
needed”.
| 6 DBRCVGRP=rcvgrpnm The name of the recovery group to which this
database belongs, if any. Otherwise, **NULL** is
printed.
7 FLAGS: COUNTERS: This heading line is printed for lines 8 through
14, which describe the status of this database.
8 BACKOUT NEEDED= This flag indicates whether this database needs
ON | OFF to be backed-out by any subsystem.
RECOVERY NEEDED COUNT= This counter is the number of DBDSs that are
n associated with this database that need to be
recovered. The printed output of the DBDS
record indicates which DBDSs need recovery.
9 READ ONLY= ON | OFF Indicates whether this database can be
authorized for read processing only, or
authorized for read and update processing.

Table 47. Fields Present in the DB (IMS) Record (continued)

IMAGE COPY NEEDED A count of how many DBDSs that are associated
COUNT= n with this database require an image copy or
forward recovery. The printed output of the
DBDS records indicates which DBDSs require an
image copy.
10 PROHIBIT AUTHORIZATION= This flag indicates whether this database is
ON | OFF available for authorization processing. If the
database can be authorized, the value is OFF.
AUTHORIZED SUBSYSTEMS= The count of subsystems that have current
n authorization to this database.
11 RECOVERABLE= YES | NO An indication of whether the database is
recoverable (YES) or non-recoverable (NO).
HELD AUTHORIZATION This is the state derived by the database
STATE= n authorization call process in IMS. It represents
the composite use of the database by all
currently authorized subsystems. If n= 0, no
subsystem is authorized to use this database. If
n> 0, see line the 17 encoded state field below
for the subsystem encoded state. If n> 128,
block-level data sharing is in effect. Subtract 128
to determine the true held authorization state.
12 DATABASE LEVEL TRACK= Indicates the level of tracking for the database.
YES | NO YES is printed for database-readiness tracking.
NO indicates recovery-readiness tracking. This
is listed only if the database is contained in a
GSG.
EEQE COUNT= n Number of extended error queue elements for
this database.
13 TRACKING SUSPENDED= YES Indicates whether tracking has been suspended
| NO for this shadow database.
RECEIVE REQUIRED COUNT= Indicates how many of the DBDSs (for this
n shadow database) need image copies to be
received from the active site.
14 OFR REQUIRED= YES | NO Indicates whether online forward recovery is
required for this shadow database.
15 IC NEEDED DISABLED For this non-recoverable DB, image copies will
not be required after initial load (PROCOPT=L)
or REORG of the DBDS.
The following lines 16 through 19 are printed only when one or more subsystems are currently authorized to this
database:
16, 17, 18 ASSOCIATED SUBSYSTEM Headings for lines 18-nnn. These headings are
INFORMATION: -SSID- -AC printed if subsystems exist.
INTENT- ENCODED -STATE-
B/O NEEDED -COUNT- -SS
ROLE-
19-nnn ssidname The subsystem associated with this
authorization.
access intent The intended access for the subsystem: READ,
UPDATE, EXCLUSIVE, or READ-GO.

Table 47. Fields Present in the DB (IMS) Record (continued)

encoded state= n An internal value derived by IMS to indicate the
subsystem’s intended use of the database. The
values of n 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 database needs n backouts
by this subsystem.
ACTIVE | TRACKING Role of authorized subsystem
Fields Present in a DB (HALDB) Record

The record fields and their corresponding line numbers for a HALDB master are
| Table 48. Fields Present in the DB (HALDB) Record
| Record Type Line Number Field Contents
| DB (HALDB 1
| Master)
| 2 DBD=dbdname Name of the HALDB.
| DMB#=nnn The value assigned when this database was
| registered.
| CHANGE#=nnn The change version number. This is updated
| when the definition of the HALDB is changed.
| TYPE=HALDB Indicates that this is the HALDB master.
| 3 SHARE LEVEL=n The level of data sharing for which authorized
| subsystems can share any partition of this
| HALDB.
| GSGNAME=gsgname Identifies the name of the GSG to which this
| database belongs.
| HALDB Master DB belongs, if any. Otherwise,
| **NULL** is printed.
| 5 PSNAME=psname The name of the partition selection routine used
| by this HALDB, if any. Otherwise, **NULL** is
| printed.
| DBORG = dbaseorg The database and data set organization of the
| DSORG = dsetorg data DBDSs in this HALDB.
| CURRENT PARTITION ID = The partition ID of the latest partition defined
| nnnnn for the HALDB.
| 6 FLAGS: COUNTERS: This heading line is printed for line 6, which
| describes the status of this HALDB.
| 7 RECOVERABLE= The HALDB is recoverable or not.
| YES | NO
| PARTITIONS=n Number of partitions that exist for this HALDB.
| 8 ONLINE REORG CAPABLE= The HALDB is capable (or not) for online
| YES | NO reorganization. The ONLINE REORG CAPABLE
| = YES | NO flag is included in the master
| HALDB and in the DB partition record.

DB (HALDB) Record
| Table 48. Fields Present in the DB (HALDB) Record (continued)

| Data Set Group Members Number of data set group members
| IC NEEDED DISABLED For this non-recoverable DB, image copies will
| not be required after initial load (PROCOPT=L)
| or REORG of the DBDS.
|
Fields Present in a DB (PART) Record

The record fields and their corresponding line numbers for a HALDB partition
database are described in Table 49.
| Table 49. Fields Present in the DB (PART) Record
| DB (HALDB 1
| Partition)
| 2 DBD=dbdname Name of the HALDB partition.
| MASTER DB=HALDB master name Name of the HALDB master.
| IRLMID=xxxxx Identifies the IRLM name. This field is
| printed only when SHARE LEVEL>=2.
| CHANGE#=nnn The change version number is updated
| when the definition of the partition is
| changed.
| TYPE=PART Indicates a HALDB partition.
| 3 USID=n The highest update set identifier for this
| partition.
| AUTHORIZED USID=n The identifier of the current update set
| being applied to the partition.
| HARD USID=n The update set identifier of the latest
| changes written to the partition.
| 4 RECEIVE USID=n The update set identifier of the last image
| copy received for this partition, which
| applies only to shadow databases at the
| tracking site.
| RECEIVE NEEDED USID=n The update set identifier that indicates that
| image copies with the identified USID are
| required for the DBDSs marked “receive
| needed”, if n is not zero. It applies only to
| shadow databases at the tracking site.
| 5 DSN PREFIX=dsname The prefix name used for all data sets
| PARTITION ID=nnnnn The partition identifier.
| 6 PREVIOUS PARTITION= The names of the previous and next
| name partitions, for HALDBs using high keys.
| NEXT PARTITION=name
| 7 OLRIMSID=**NULL** The OLRIMSID field reflects the name of the
| IMS that owns the online reorganization.
| OLRIMSID is always null at the tracking
| site.
| 8 REORG#=number The reorganization number for the partition.

DB (PART) Record
| Table 49. Fields Present in the DB (PART) Record (continued)

| ACTIVE DBDS=A-J or If a HALDB online reorganization is in
| ACTIVE DBDS=M-V progress, “ACTIVE DBDS=A-J” or “ACTIVE
| DBDS=M-V” is displayed. The input data
| set is listed first and the output data set is
| listed second.
| 9 ONLINE REORG STATISTICS: If HALDB online reorganization has been
| stopped or completed, statistics are
| recorded.
| 10 OLR BYTES MOVED = n The total number of bytes moved to the
| output data sets.
| 11 OLR SEGMENTS MOVED = n The total number of segments moved to the
| output data sets.
| 12 OLR ROOT SEGMENTS MOVED = The total number of root segments moved to
| n the output data sets.
| 13-14 RANDOMIZER: Name of the randomizing module.
| NAME= Number of root anchor.
| ANCHOR= Maximum relative block number value that
| HIGH BLOCK#= the user wishes to allow a randomizing
| BYTES=nnnnnnnn module to produce for this DB.
| Maximum number of bytes of a DB record
| that can be stored into the root addressable
| area in a series of inserts unbroken by a call
| to another DB record.
| 15-16 FREE SPACE: Specifies that every nth control interval or
| FREE BLOCK FREQ FACTOR=nnn block in this data set group is left as free
| FREE SPACE PERCENTAGE=nn space during DB load or reorganization.
| Specifies the minimum percentage of each
| control interval or block that is to be left as
| free space.
| 17 PARTITION HIGH KEY/STRING Printable and hexadecimal formats of the
| (CHAR): partition high key/selection string. The
| (LENGTH=NNN) key/string is padded with blanks, so the
| hexadecimal format may contain extra X'40'
| characters beyond the length of the
| key/string (LENGTH= in line 10 lists the
| actual key/string length).
| 18 PARTITION HIGH KEY/STRING Printable and hexadecimal formats of the
| (HEX): partition high key/selection string. The
| key/string is padded with blanks, so the
| hexadecimal format may contain extra X'40'
| characters beyond the length of the
| key/string (LENGTH= in line 10 lists the
| actual key/string length).
| 19 OSAM BLOCK SIZE: OSAM block size is listed for each data set
| s = nnnnn group member defined. s is the data set
| group identifier A through J.
| 20 FLAGS: COUNTERS: This heading line is printed for lines 7
| through 14, which describe the status of this
| partition.
| 21 BACKOUT NEEDED=ON|OFF This flag indicates whether this partition
| needs backout by any subsystem.

DB (PART) Record

| RECOVERY NEEDED COUNT=n This counter is the number of DBDSs
| associated with this database that need to be
| recovered. The printed output of the DBDS
| record indicates which DBDSs need
| recovery.
| 22 READ ONLY=ON | OFF Indicates whether this partition can be
| authorized for read processing only, or
| authorized for read and update processing.
| IMAGE COPY NEEDED COUNT=n Count of how many DBDSs associated with
| this partition require an image copy or
| forward recovery. The printed output of the
| DBDS records indicates which DBDSs
| require an image copy.
| 23 PROHIBIT AUTHORIZATION=ON This flag indicates whether this partition is
| | OFF available for authorization processing. If the
| partition can be authorized, the value is
| OFF.
| AUTHORIZED SUBSYSTEMS=n The count of subsystems that have current
| authorization to this partition.
| 24 HELD AUTHORIZATION STATE=n The state derived by the database
| authorization call process in IMS,
| representing the composite use of the
| partition by all currently authorized
| subsystems. If n = 0, no subsystem is
| authorized to use this partition. If n > 0, see
| the table below for the subsystem encoded
| state. If n > 128, online image copy (OLIC) is
| in progress for a data set of this partition.
| 25 DATABASE LEVEL TRACK=YES | Indicates the level of tracking for the
| NO database. YES is printed for
| database-readiness tracking. NO indicates
| recovery-readiness tracking. This is listed
| only if the database is contained in a GSG.
| EEQE COUNT=n Number of extended error queue elements
| for this partition.
| 26 TRACKING SUSPENDED= Indicates whether tracking has been
| YES | NO suspended for this shadow database.
| RECEIVE REQUIRED COUNT=n Indicates how many of the DBDSs (for this
| shadow database) need image copies from
| the active site to be received.
| 27 OFR REQUIRED=YES | NO Indicates whether online forward recovery is
| required for this shadow database.
| OLR ACTIVE HARD COUNT=0 If the count is greater than zero, it reflects
| the number of HALDB online
| reorganizations that have started which have
| been recorded in the RECON but not yet
| hardened for this shadow database at the
| RSR tracking site.
| 28 PARTITION INIT NEEDED=YES | Indicates whether partition initialization is
| NO required for this HALDB partition.

DB (PART) Record

| OLR INACTIVE HARD COUNT=0 If the count is greater than zero, it reflects
| the number of HALDB online
| reorganizations that have completed which
| have been recorded in the RECON but not
| yet hardened for this shadow database at
| the RSR tracking site.
| 29 OLREORG CURSOR ACTIVE=NO The flag for OLREORG CURSOR ACTIVE is
| on when the paired sets of data sets are
| active. At the tracking site, the flag is on
| when the output data sets have been
| validated or created and that validation or
| creation process occurs within a hardened
| milestone.
| 30 PARTITION DISABLED=YES | NO A disabled partition is known only to DBRC
| and the Partition Definition Utility. A
| disabled partition can be enabled or deleted.
| 31 ONLINE REORG CAPABLE= YES | The partition is enabled (or not) for online
| NO reorganization. The ONLINE REORG
| CAPABLE = YES | NO flag is included in
| the master HALDB and in the DB partition
| records.
| 32 REORG INTENT= OFF | ON The REORG INTENT flag is used by online
| reorganization products (other than the
| HALDB Online Reorganization function that
| is delivered with IMS) to inform DBRC they
| are active (they intend to reorganize the
| database - REORG INTENT = ON) or
| inactive (REORG INTENT = OFF). When the
| REORG INTENT flag is set to ON, database
| authorization fails for other reorganization
| products, batch access, and online image
| copy processes. The REORG INTENT flag is
| included in DB partition records and is not
| included in HALDB master DB records.
| The following lines 33 through 36 are printed only when one or more subsystems are currently authorized to this
| partition:
| 33,34,35 ASSOCIATED SUBSYSTEM
| INFORMATION: -SSID- -ACCESS
| INTENT- ENCODED -STATE- B/O
| NEEDED -COUNT- -SS ROLE-
| 36-nnn ssidname The subsystem associated with this
| authorization.
| access intent The intended access for the subsystem:
| READ, UPDATE, EXCLUSIVE, or
| READ-GO.

DB (PART) Record

| encoded state=n An internal value derived by IMS to indicate
| the subsystem’s intended use of the
| partition. The values of n 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 needs n
| backouts by this subsystem.
| ACTIVE|TRACKING Role of authorized subsystem
Fields Present in a DB (Fast Path) Record

A Fast Path database record’s fields and their corresponding line numbers are
Table 50. Fields Present in the DB (Fast Path) Record
DB (Fast Path) 1
2 DBD= dbdname Name of the database.
DMB#= nnn The value assigned when this database was
registered.
TYPE= FP Indicates that the database being used is a Fast
Path DEDB.
subsystems can share this database.
4 FLAGS: COUNTERS: This heading line is printed for lines 4 through 6
describing status of this database.
5 RECOVERY NEEDED COUNT= This counter is the number of area data sets,
n associated with this database, that need to be
recovered. The printed output of the area data
set record indicates which area data sets need
recovery.
6 IMAGE COPY NEEDED Count of how many area data sets, associated
COUNT= n with this database, require an image copy or
forward recovery. The printed output of the area
data set records indicates which area data sets
require an image copy.
7 PROHIBIT AUTHORIZATION= This flag indicates whether this database is
ON | OFF available for authorization processing. If the
database can be authorized, the value is OFF.
AUTHORIZED AREAS= n The count of areas that are currently authorized.
8 RECOVERABLE= YES | NO An indication of whether the database is
recoverable (YES) or non-recoverable (NO).

Fields in DB (Fast Path) Record
Table 50. Fields Present in the DB (Fast Path) Record (continued)

EEQE COUNT= n Number of extended error queue elements for
this DEDB.
Fields Present in a DBDS (non-Fast Path) Record

A non-Fast Path database data set record’s fields and their corresponding line
numbers are described in Table 51.
Table 51. Fields Present in the DBDS (non-Fast Path) Record
DBDS 1
(non-Fast Path)
2 DSN= dsname Data set name of the DBDS.
TYPE= IMS Indicates that this is a DBDS rather than a FP
DEDB area.
TYPE= PART Indicates that this is a DBDS of a HALDB
partition.
3 DBD= dbdname The database name and data set ddname of the
DDN= ddname DBDS.
| DSID= nn The data set ID number that appears as part of
| the information in the DBDLIB data set about
| the DBDS. The DSID for the M-V and Y DBDSs
| has the high order bit turned on, which is
| ignored for printing.
DBORG= dbaseorg DSORG= The database and data set organization, as
dsetorg defined for the DBDS in the DBDLIB data set.
4 CAGRP= cagrpnam The name of the CA group to which this DBDS
belongs, if any. Otherwise, **NULL** is printed.
GENMAX= nnnn The maximum number of image copy data sets
to be maintained for this DBDS.
IC AVAIL= nnnn The number of available and in-use image copy
IC USED= nnnn data sets for the DBDS.
DSSN= nnnn The data set synchronization number that is
being used concurrently by sharing IMS
subsystems. A DSSN is used to reflect the
relative order in which changes are made to a
DBDS.
5 REUSE | NOREUSE REUSE is printed if you have specified in
RECON that image copy data sets are to be
reused for this DBDS.
RECOVPD= nnn This is the recovery period of the image copies.
| OTHER DDN=**NULL** The partner DBDS, if one exists. Otherwise
| **NULL** is printed.
The following fields in lines 6 through 11, identify the JCLPDS data set member names that are to be used in order to
generate IMS utility JCL for this DBDS:
6 DEFLTJCL= member The name of the PDS member containing the
skeletal JCL default values for the user-defined
keywords that are to be used for this DBDS.

Fields in a DBDS (non-Fast Path) Record
Table 51. Fields Present in the DBDS (non-Fast Path) Record (continued)
ICJCL= member The name of the skeletal JCL PDS member that
is to be used in order to generate JCL for the
Database Image Copy utility for this DBDS.
OICJCL= member The name of the skeletal JCL PDS member that
is to be used in order to generate a job for the
Online Database Image Copy utility for this
DBDS.
RECOVJCL= member The name of the skeletal JCL PDS member that
is to be used in order to generate JCL for the
Database Recovery utility for this DBDS.
7 RECVJCL= member The name of the skeletal JCL PDS member for
which the Database Recovery utility is to receive
an image copy for this DBDS at an RSR tracking
site.
8 FLAGS: COUNTERS: Heading for the following lines 9 through 11,
which describe the status of this DBDS.
9 IC NEEDED= ON | OFF Indicates whether an image copy needs to be
taken for the DBDS.
10 IC RECOMMENDED= ON Indicates that DBRC recommends an image
copy of the DBDS should be taken before using
the database.
11 RECOV NEEDED= ON | OFF Indicates whether the DBDS needs to be
recovered.
12 RECEIVE NEEDED = Indicates whether an image copy of this DBDS
ON | OFF needs to be received at the tracking site. This
indicator is only applicable in an RSR
environment at the RSR tracking site.
EEQE COUNT= n The number of extended error queue elements
for this DBDS.
The following, lines 13 through 15, are printed only if one or more extended error queue elements exist.
13, 14 ERROR QUEUE ELEMENTS: Heading for the following list of extended error
-EQERBA-EEQE TYPE-SSID- queue elements (lines 14-nnn).
15-nnn eeqe rba The relative byte address (RBA) of the EEQE.
eeqe type The type of extended error queue element.
ssid The ID of the subsystem that created the EEQE
(in doubt EEQEs only).
Fields Present in a DBDS (Fast Path) Record

A Fast Path database data set record’s fields and their corresponding line numbers
are described in Table 52.
Table 52. Fields Present in the DBDS (Fast Path) Record
DBDS (Fast 1
Path)
2 DBD= dbdname The database name and area name of the Fast
AREA= areaname Path DEDB.

Fields in a DBDS (Fast Path) Record
Table 52. Fields Present in the DBDS (Fast Path) Record (continued)
IRLMID= irlmname Identifies the IRLM when the share level of this
DEDB is 2. This field is printed only when
SHARE LEVEL=2.
TYPE= FP Identifies this database as a Fast Path DEDB.
subsystems can share this area.
DSID= nn The data set ID number that appears as part of
the information in the DBDLIB data set about
the area data set.
DBORG= dbaseorg DSORG= The database and data set organization, as
dsetorg defined for the area data set in the DBDLIB data
set.
4 GSGNAME= gsgname Identifies the name of the GSG to which this
area belongs.
USID= n The highest update set identifier for this area.
5 AUTHORIZED USID= n The identifier of the current update set that is
being applied to the area.
RECEIVE USID= n The update set identifier of the last image copy
that was received for this area. The update set
ID only applies to shadow areas at the tracking
site.
HARD USID= n The update set identifier of the latest changes
that were written to the area.
6 RECEIVE NEEDED USID= n This only applies to shadow areas at the
tracking site. If n is not zero, this indicates that
an image copy with the identified USID needs
to be received for this area.
7 CAGRP= cagrpnam The name of the CA group to which this area
belongs, if any. Otherwise, **NULL** is printed.
GENMAX= nnnn The maximum number of image copy data sets
to be maintained for this area.
IC AVAIL= nnnn The number of available image copy data sets,
IC USED= nnnn and the number of in-use image copy data sets
for the area.
DSSN= nnnn This is the data set synchronization number that
is being used concurrently by sharing IMS
relative order in which changes are made to an
area data set.
8 REUSE | NOREUSE REUSE is printed if you have specified in
RECON that image copy data sets are to be
reused for this area data set.
RECOVPD= nnn This is the recovery period of the image copies.
VSO | NOVSO Indicates whether the area resides in virtual
storage.
PREOPEN | NOPREOPEN Indicates whether the area is opened at control
region initialization or when the area is started.
PRELOAD | NOPRELOAD Indicates whether the VSO area is loaded into
the data space the next time it is opened.

9 CFSTR1= cfstr_name The name of the first coupling facility structure
for the area.
CFSTR2= cfstr_name The name of the second coupling facility
structure for the area.
LKASID | NOLKASID Indicates whether local data caching for the
specified area is used for buffer lookaside on
read requests.
| MAS | NOMAS Indicates whether (or not) the area is to reside
in a multi-area coupling facility structure.
10 DEFLTJCL= member The name of the member of the partitioned data
set that contains the skeletal JCL default values
that are to be used for the DEDB area.
ICJCL= member The name of the skeletal JCL PDS member that
is to be used in order to generate the JCL for the
Database Image Copy utility for this area data
set.
RECVJCL= member The name of the skeletal JCL PDS member for
which the Database Recovery utility is to receive
an image copy for this area data set at an RSR
tracking site.
RECOVJCL= member The name of the skeletal JCL PDS member that
is to be used in order to generate the JCL for the
Database Recovery utility for this area data set.
DBDS belongs, if any. Otherwise, **NULL** is
printed.
12 FLAGS: COUNTERS: This heading line is printed for lines 11 through
19 describing the status of this area.
13 PROHIBIT AUTHORIZATION= The value of this flag is OFF if the area is
ON | OFF available for authorization processing.
AUTHORIZED SUBSYSTEMS= The count of subsystems that have current
n authorization to this area.
14 HELD AUTHORIZATION This is the state derived by the database
STATE= n authorization call process in IMS. It represents
the composite use of the database by all
currently authorized subsystems. If n= 0, no
subsystem is authorized to use this database. If
n> 0, see the table below for the subsystem
encoded state. If n> 128, block-level data sharing
is in effect. Subtract 128 to determine the true
held authorization state.
15 IC NEEDED= ON | OFF Indicates whether an image copy needs to be
taken for the DEDB area.
ADS AVAIL #= n Indicates the number of available ADS in this
area record.
16 IC RECOMMENDED= ON Indicates that DBRC recommends an image
copy of the area should be taken before it is
used.
17 RECOV NEEDED= ON | OFF Indicates whether the areas associated with the
DEDB should be recovered.

REGISTERED ADS #= n Indicates how many area data sets for this area
are registered in RECON.
18 DATABASE LEVEL TRACK = Indicates the level of tracking for the area. YES
YES | NO is printed for database-readiness tracking. NO
indicates recovery-readiness tracking. This is
listed only if the area is contained in a GSG.
EEQE COUNT= n The number of extended error queue elements
for this DEDB area.
19 RECEIVE NEEDED = Indicates whether an image copy of this area
ON | OFF needs to be received at the tracking site. This
indicator is only applicable in an RSR
environment at the RSR tracking site.
20 OFR REQUIRED= YES | NO Indicates whether online forward recovery is
required for this shadow area.
21 TRACKING SUSPENDED= YES Indicates whether tracking has been suspended
| NO for this shadow area.
22 HSSP CIC IN PROGRESS= YES Indicates whether an HSSP concurrent image
| NO copy is in progress.
The following lines, 23 through 25, are printed only if one or more error queue elements exist.
23 ERROR QUEUE ELEMENTS: Heading for the following list of error queue
24 -EQERBA-EEQE TYPE-SSID- elements.
25-nnn eeqe rba The type of extended error queue element.
eeqe type The type of extended error queue element.
ssid The ID of the subsystem that created the EEQE
(in doubt EEQEs only).
If the number of registered area data sets is not zero, the following lines 26 through 28 list those area data sets that
are currently registered in this area record:
26 ADS LIST: -ADS DDN- -ADS These lines, 26 through 28, represent the column
27 DSN- -STAT- CREATE headings for the following line 29.
28 -RUNNING-
The following line (29) is repeated for each area data set that is registered for this area.
29-nn adsddn adsdsn AVAIL indicates that the area data set is
AVAIL | UNAVAIL available. UNAVAIL indicates that the area data
YES | NO set is unavailable. YES indicates that the area
data set is being used. NO indicates that the
area data set is not being used.
The following lines nn+1 through nn+3,are printed only when one or more subsystems are currently authorized to
this area:
nn+1 nn+2 ASSOCIATED SUBSYSTEM Lines nn+1 through nn+3 represent the column
nn+3 INFORMATION -SSID- headings for the following lines nn+3-mm.
-ACCESS INTENT- ENCODED
-STATE- -SS ROLE-
The following line nn+3-mm, is repeated for each subsystem that has authorization for this database.
nn+3-mm ssidname The subsystem associated with this
authorization.
access intent The intended access for the subsystem: READ,
UPDATE, EXCLUSIVE, or READ-GO.

encoded state= n An internal value derived by IMS to indicate the
subsystem’s intended use of the database. The
values of n are as follows: 1 - Read only 2 -
Read share 3 - Multiple update 4 - Read
exclusive 5 - Batch update 6 - Single update 7 -
Exclusive
ACTIVE | TRACKING Role of the authorized subsystem.
Fields Present in an ALLOC Record

An allocation record’s fields and their corresponding line numbers are described in
Table 53.
Table 53. Fields Present in the ALLOC Record
ALLOC 1
2 ALLOC= time_stamp* The time stamp for a time that the DBDS was
allocated during the run of an IMS system. An
asterisk (*) indicates that it is part of the record
key.
ALLOC LRID= n The log record sequence number of the begin
update log record. The value for n is 0 for
ALLOC records that are created at the active
site.
3 DSSN= nnnn This is the data set synchronization number that
is being concurrently used by sharing IMS
relative order in which changes are made to a
DBDS or area.
USID= n The update set identifier. An update set is a
collection of updates that are made to the
database or area while it is continuously
updated by one or more IMS subsystems.
START= time_stamp The start time of the log data set that was
logging change records when this DBDS was
allocated.
4 DEALLOC= time_stamp The time stamp of a specific deallocation. This
field is printed only if a specific deallocation
time is in the record. If the DBDS was allowed
to remain allocated to the closing of the log data
set, this line is not printed.
DEALLOC LRID= n The log record sequence number of the
end-update log record. This field is only printed
if a specific deallocation time exists.
5 TRACKING SUSPENDED AT This will only be printed for shadow databases
RECORD: suspend lrid that are being tracked at the tracking site. The
TRACKING SUSPENDED NO suspend lrid indicates the current tracking log
RECORDS APPLIED position.

Fields in an IMAGE Record
Fields Present in an IMAGE Record

An image record’s fields and their corresponding line numbers are described in
Table 54.
Table 54. Fields Present in the IMAGE Record
IMAGE 1
2 * The asterisk (*) is printed to the left of the
record type only if the image copy data sets that
are defined in this record are available for the
first time for future use (they have never been
used before).
CREATE | RUN= time_stamp* CREATE is printed if the image copy data set
has never been used. Otherwise, RUN is
printed. RUN is the time stamp of the start of
processing of the database image copy utilities
that used this image copy data set. The asterisk
(*) indicates that the time stamp is part of the
key of this record.
RECORD COUNT= nnnnnnnn The number of records contained in the image
copy data set. This field is printed only for
in-use image copy data sets; it does not apply to
nonstandard or system managed storage image
copy data sets.
USER IC This is printed for any nonstandard image copy.
USID= n This is only listed here for a nonstandard image
copy.
3 USERDATA= cccccccc... This line is printed in this format for a
nonstandard image copy data set. The characters
following USERDATA= comprise the character
string you kept in the record to describe the
nonstandard image copy data set.
STOP= This field contains either zeros or the stop time
time_stamp of an Online Database Image Copy utility run.
This field applies to standard image copy data
sets, but is not printed for available image copy
data sets.
| ONLINE | BATCH | CONCUR This field indicates the type of image copy.
| | SMSCIC | SMSNOCIC ONLINE indicates that this image copy was
| produced by an online database image copy
| utility. BATCH indicates a batch image copy
| from the Database Image Copy utility. CONCUR
| indicates that a concurrent image copy was run.
| SMSCIC indicates a concurrent image copy that
| is produced by the Database Image Copy 2
| utility. SMSNOCIC indicates a consistent image
| copy that is produced by Database Image Copy
| 2 utility.
| This field is not printed for available image

| copy data sets.
USID= n This is only listed here for a standard image
copy. This is the value of the update set
identifier of the database or area when the
image copy was taken.

Fields in an IMAGE Record
Table 54. Fields Present in the IMAGE Record (continued)

4 IN PROGRESS This line is listed when an HSSP concurrent
image copy is currently in progress.
5 IC1 | IC2 IC1 and accompanying lines are always printed,
followed by IC2 and accompanying lines, if a
duplicate image copy data set exists.
6 DSN= ic-dsname ic-dsname is the data set name of this image
copy data set (IC1 or IC2).
FILE SEQ= nnnn The file sequence number of the image copy
data set on the first volume on which it resides.
This field is listed for non-HSSP image copies
only.
7 UNIT= unittype Unit type to be used for substitution during the
GENJCL process. This field is listed for non-HSSP
image copies only.
ERR | EMP ERR is printed if you have indicated that the
image copy data set is not to be used as input to
future utility runs. EMP is printed only for
duplicate image copy data sets that have not
been used, even though their corresponding
image copy data set has been used.
VOLS DEF= nnnn The number of volumes that have been specified
VOLS USED= nnnn for use by this image copy data set and the
number of volumes that have been used to
create the data set. The VOLS USED value
might be less than the specified VOLS DEF. For
available image copy data sets, the VOLS USED
value is 0.
This field is listed for non-HSSP image copies

only.
8-nn VOLSER= volser,... A list of the volume serial numbers of volumes
that contain the image copy data set. this field is
listed for non-HSSP image copies only.
Fields Present in a REORG Record

A reorganization record’s fields and their corresponding line numbers are
Table 55. Fields Present in the REORG Record
REORG 1
2 RUN= time_stamp* The time stamp you have supplied for the time
at which a reorganization occurred for this
DBDS. An asterisk (*) indicates that the time
stamp is part of the key of this record.
| USID= n This is the value of the update set identifier of
the database or area when the reorganization of
this DBDS occurred.
3 REORG#=number The reorganization number for the partition at
the time of the reorganization.

Fields in a REORG Record
Table 55. Fields Present in the REORG Record (continued)

| 4 STOP=time_stamp* STOP= is only present for online
reorganizations. STOP= is zero for online
reorganizations that have not yet completed.
| ONLINE RECOV= YES indicates the online reorganization was
YES | NO taken when this DBDS was the output data set
and the start time can be used as the purgetime
for recovery. NO indicates the online
reorganization was taken when this DBDS was
the input data set and cannot be used for
recovery.
| 5 OLDSTOPT = time_stamp If a point-in-time recovery (PITR) has been run
to the middle of a completed online
reorganization, the prior stop time of the online
reorganization is moved to this field.
OLDSTOPT= is only present if non-zero and is
used for diagnostic information only.
Fields Present in a RECOV Record

A recovery record’s fields and their corresponding line numbers are described in
Table 56.
Table 56. Fields Present in the RECOV Record
RECOV 1
2 RUN= time_stamp* The time stamp of a Database Recovery utility
run for this DBDS. The asterisk (*) indicates that
the time stamp is part of the key of this record.
RUN USID= n Listed only if a time-stamp recovery is being
described. This identifies the update set
identifier of the DBDS when the Database
Recovery utility was run.
3 RECOV TO= time_stamp This field indicates that a time-stamp recovery is
being described. The time-stamp recovery
restored the DBDS to the state it was in at the
time represented by the time stamp.
RECOV TO USID= n Listed only if a time-stamp recovery is being
described. This identifies the update set
identifier of the DBDS at the time to which the
DBDS was restored.

Fields in a RECOV Record

Appendix C. Resource Names for Command Authorization
DBRC uses a list of resource names for command authorization support. For more
information about command authorization, see “Preserving the Integrity of the
RECON Data Set with DBRC Command Authorization Support” on page 78.
Table 57 lists the resources that can be protected.

Table 57. Resource Names for Command Authorization
Verb Modifier Qualifier
BACKUP .RECON
CHANGE .ADS .dbname
CHANGE .BKOUT .ssid
CHANGE .CA .grpname
CHANGE .CAGRP .grpname
CHANGE .DB .dbname
CHANGE .DB .ALL
CHANGE .DBDS .dbname
CHANGE .DBDSGRP .grpname
CHANGE .IC .dbname
CHANGE .PART .dbname
CHANGE .PRILOG .OLDS
CHANGE .PRILOG .RLDS
CHANGE .PRILOG .SLDS
CHANGE .PRILOG .TSLDS
CHANGE .RECON .CATDS
| CHANGE .RECON .CDSLID
CHANGE .RECON .NOCATDS
CHANGE .RECON .CHECK17
CHANGE .RECON .CHECK44
CHANGE .RECON .NOCHECK
CHANGE .RECON .CMDAUTH
CHANGE .RECON .DASDUNIT
CHANGE .RECON .DUAL
CHANGE .RECON .REPLACE
CHANGE .RECON .FORCER
CHANGE .RECON .NOFORCER
CHANGE .RECON .IMSPLEX
CHANGE .RECON .NOPLEX
CHANGE .RECON .LISTDL
CHANGE .RECON .NOLISTDL
CHANGE .RECON .LOGALERT

Table 57. Resource Names for Command Authorization (continued)
CHANGE .RECON .LOGRET
CHANGE .RECON .MINVERS
| CHANGE .RECON .RESET
CHANGE .RECON .SIZALERT
CHANGE .RECON .SSID
CHANGE .RECON .STARTNEW
CHANGE .RECON .NONEW
CHANGE .RECON .TAPEUNIT
CHANGE .RECON .TIMEZONE
CHANGE .RECON .TIMEZIN
CHANGE .RECON .TIMEFMT
CHANGE .RECON .TRACEON
CHANGE .RECON .TRACEOFF
| CHANGE .RECON .TRACEOPT
CHANGE .RECON .UPGRADE
CHANGE .SG .gsgname
CHANGE .SUBSYS .ssid
CHANGE .SUBSYS .ALL
CHANGE .UIC .dbname
DELETE .ADS .dbname
DELETE .ALLOC .dbname
DELETE .BKOUT .ssid
DELETE .CA .grpname
DELETE .CAGRP .grpname
DELETE .DB .dbname
DELETE .DBDS .dbname
DELETE .DBDSGRP .grpname
DELETE .GSG .gsgname
DELETE .IC .dbname
DELETE .LOG .INACTIVE
DELETE .LOG .OLDS
DELETE .LOG .STARTIME
DELETE .LOG .TOTIME
DELETE .PART .dbname
DELETE .RECOV .dbname
DELETE .REORG .dbname
DELETE .SG .gsgname
DELETE .SUBSYS .ssid
DELETE .UIC .dbname
GENJCL .ARCHIVE .ssid

GENJCL .CA .grpname
GENJCL .CLOSE .ssid
GENJCL .IC .dbname
GENJCL .IC .grpname
GENJCL .OIC .dbname
GENJCL .OIC .grpname
GENJCL .RECEIVE .dbname
GENJCL .RECEIVE .grpname
GENJCL .RECOV .dbname
GENJCL .RECOV .grpname
GENJCL .USER .mbrname
GENJCL .USER .dbname
GENJCL .USER .grpname
INIT .ADS .dbname
INIT .CA .grpname
INIT .CAGRP .grpname
INIT .DB .dbname
INIT .DBDS .dbname
INIT .DBDSGRP .grpname
INIT .GSG .gsgname
INIT .IC .dbname
INIT .PART .dbname
INIT .RECON
INIT .SG .gsgname
LIST .BKOUT .ssid
LIST .BKOUT .ALL
LIST .CAGRP .grpname
LIST .CAGRP .ALL
LIST .DB .dbname
LIST .DB .ALL
LIST .DB .TYPEIMS
LIST .DB .TYPEFP
LIST .DB .TYPHALDB
LIST .DBDS .dbname
LIST .DBDS .grpname
LIST .DBDSGRP .grpname
LIST .DBDSGRP .ALL
LIST .GSG .gsgname
LIST .GSG .ALL
LIST .HISTORY .dbname
Appendix C. Resource Names for Command Authorization 567

LIST .HISTORY .grpname
LIST .LOG .ALL
LIST .LOG .ALLOLDS
LIST .LOG .OLDS
LIST .LOG .STARTIME
LIST .RECON
LIST .RECON .STATUS
LIST .SUBSYS .ONLINE
LIST .SUBSYS .ssid
LIST .SUBSYS .ALL
LIST .SUBSYS .BATCH
NOTIFY .ALLOC .dbname
NOTIFY .BKOUT .ssid
NOTIFY .CA .grpname
NOTIFY .IC .dbname
NOTIFY .PRILOG .OLDS
NOTIFY .PRILOG .RLDS
NOTIFY .PRILOG .SLDS
NOTIFY .PRILOG .TSLDS
NOTIFY .PRILOG .DPROP
NOTIFY .RECOV .dbname
NOTIFY .REORG .dbname
NOTIFY .SECLOG .OLDS
NOTIFY .SECLOG .RLDS
NOTIFY .SECLOG .SLDS
NOTIFY .SECLOG .TSLDS
NOTIFY .SECLOG .DPROP
NOTIFY .SUBSYS .ssid
NOTIFY .UIC .dbname
RESET .GSG .gsgname

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services 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, or service may be used. Any functionally equivalent product,
program, or service that does 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-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
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
believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
J46A/G4
555 Bailey Avenue
San Jose, CA 95141-1003
U.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 material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurement may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM’s future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which

illustrates 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
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample

programs are provided ″AS IS,″ without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
Each copy or any portion of these sample programs or any derivative work, must
include 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 rights
reserved.
If you are viewing this information softcopy, the photographs and color
illustrations may not appear.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the Web in the topic “Copyright
and trademark information” at http://www.ibm.com/legal/copytrade.shtml.
The following terms are trademarks or registered trademarks of other companies,

and have been used at least once in the IMS library:
v Adobe®, the Adobe logo, PostScript®, and the PostScript logo are either
registered trademarks or trademarks of Adobe Systems Incorporated in the
United States, and/or other countries.
v Microsoft®, Windows®, Windows NT®, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
v Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc., in
the United States, other countries, or both.
v Linux® is a registered trademark of Linus Torvalds in the United States, other
countries, or both.
v UNIX® is a registered trademark of The Open Group in the United States and
other countries.
Other company, product, or service names may be trademarks or service marks of

others.
Notices 571
Bibliography
This bibliography includes all the publications Title Acronym Order
cited in this book, including the publications in number
the IMS library. IMS Version 9: Command CR SC18-7814
v CICS Transaction System for z/OS CICS Supplied Reference
Transaction, SC34-5992 IMS Version 9: Common Queue CQS SC18-7815
Server Guide and Reference
v CICS Transaction System for z/OS IMS Database
IMS Version 9: Common CSL SC18-7816
Control Guide, SC34-6010 Service Layer Guide and
v DFSMS/MVS V1R5 MDFSMSdfp Advanced Reference
Services, SC26-4921 IMS Version 9: Customization CG SC18-7817
v High Level Assembler for MVS & VM & VSE Guide
Language Reference, SC26-4940 IMS Version 9: Database DBRC SC18-7818
Recovery Control (DBRC)
v High Level Assembler for MVS & VM & VSE Guide and Reference
Programmer’s Guide, SC26-4941 IMS Version 9: Diagnosis DGR LY37-3203
v z/OS MVS Planning: Global Resource Serialization, Guide and Reference
GC28-1759 IMS Version 9: Failure Analysis FAST LY37-3204
Structure Tables (FAST) for
v z/OS MVS Programming: Authorized Assembler
Dump Analysis
Services Reference, GC28-1763
IMS Version 9: IMS Connect CT SC18-9287
v z/OS DFSMS Access Method Services for Guide and Reference
Integrated Catalog Facility IMS Version 9: IMS Java Guide JGR SC18-7821
v z/OS V1R3 MVS Programming : Assembler and Reference
Services, Volume 1, SA22-7606 IMS Version 9: Installation IIV GC18-7822
Volume 1: Installation
v z/OS V1R3 MVS Programming : Assembler
Verification
Services, Volume 2, SA22-7607
IMS Version 9: Installation ISDT GC18-7823
Volume 2: System Definition
IMS Version 9 Library and Tailoring
IMS Version 9: Master Index MIG SC18-7826
Title Acronym Order and Glossary
number IMS Version 9: Messages and MC1 GC18-7827
IMS Version 9: Administration ADB SC18-7806 Codes, Volume 1
Guide: Database Manager IMS Version 9: Messages and MC2 GC18-7828
IMS Version 9: Administration AS SC18-7807 Codes, Volume 2
Guide: System IMS Version 9: Open OTMA SC18-7829
IMS Version 9: Administration ATM SC18-7808 Transaction Manager Access
Guide: Transaction Manager Guide and Reference
IMS Version 9: Application APDB SC18-7809 IMS Version 9: Operations OG SC18-7830
Programming: Database Guide
Manager IMS Version 9: Release RPG GC17-7831
IMS Version 9: Application APDG SC18-7810 Planning Guide
Programming: Design Guide IMS Version 9: Summary of SOC SC18-7832
IMS Version 9: Application APCICS SC18-7811 Operator Commands
Programming: EXEC DLI IMS Version 9: Utilities URDBTM SC18-7833
Commands for CICS and IMS Reference: Database and
IMS Version 9: Application APTM SC18-7812 Transaction Manager
Programming: Transaction IMS Version 9: Utilities URS SC18-7834
Manager Reference: System
IMS Version 9: Base Primitive BPE SC18-7813
Environment Guide and
Reference

Supplementary Publications
Title Order number
IMS TM Resource Adapter User’s Guide SC19-1211
and Reference
IMS Version 9 Fact Sheet GC18-7697
IMS Version 9: Licensed Program GC18-7825
Specifications
IRLM Messages and Codes GC19-2666
Publication Collections
Title Format
Order
number
IMS Version 9 Softcopy Library CD LK3T-7213
IMS Favorites CD LK3T-7144
Licensed Bill of Forms (LBOF): Hardcopy LBOF-7789
IMS Version 9 Hardcopy and and CD
Softcopy Library
Unlicensed Bill of Forms Hardcopy SBOF-7790
(SBOF): IMS Version 9
Unlicensed Hardcopy Library
OS/390 Collection CD SK2T-6700
z/OS Software Products CD SK3T-4270
Collection
z/OS and Software Products DVD SK3T-4271
DVD Collection
Accessibility Titles Cited in This

Library
Title Order number
z/OS V1R1.0 TSO Primer SA22-7787
z/OS V1R5.0 TSO/E User’s Guide SA22-7794
z/OS V1R5.0 ISPF User’s Guide, SC34-4822
Volume 1

Index
Special characters %ICUNIT3 keyword 460
%ICUNIT4 keyword 460
ACTIVE parameter
CHANGE.DB command 151
/NRESTART %ICUSID keyword 100 ADD parameter
INIT.DB 269 %ICVCNT keyword 100 CHANGE.CAGRP command 141
restart after IMS failure 24 %ICVCNT2 keyword 460 ADDDB parameter
/REPRO %ICVCNT3 keyword 460 CHANGE.DBDSGRP command 160
using for backup 73 %ICVCNT4 keyword 460 ADDEQE parameter
/REPRO command %ICVOLS keyword 100 CHANGE.DBDS command 154
restoring RECON data sets 76 %ICVOLS2 keyword 460 adding information to the RECON data
/RMGENJCL command %ICVOLS3 keyword 460 set
generating JCL 13 %ICVOLS4 keyword 460 allocation or deallocation 309
/RMxxxxxx commands %LOGDSN keyword 98 backout records 311
authorization of 122 %LOGETIM keyword 99 Database Change Accumulation
description 122 %LOGFRID keyword 99 utility 312
/START command %LOGFSEQ keyword 98 database data set or area
use of 17, 251 %LOGLRID keyword 99 recovery 329
%ALLDSSN keyword 102 %LOGMERG keyword 99 database reorganization 332
%ALLSEL keyword 102 %LOGONL keyword 99 image copy 314
%ALLTIME keyword 102 %LOGRMT keyword 99 nonstandard image copy data
%ALLUSID keyword 102 %LOGSEL keyword 99 sets 346
%CADSN keyword 101 %LOGSTIM keyword 98 primary online log data set 317
%CAFSEQ keyword 101 %LOGUNIT keyword 98 primary recovery log data set 321
%CALGTM keyword 101 %LOGVOLS keyword 98 primary system log data set 326
%CAODSN keyword 92 %OLDCTIM keyword 95 secondary online log data set 335
%CASEL keyword 101 %OLDFRID keyword 95 secondary recovery log data set 338
%CATIME keyword 101 %OLDLRID keyword 95 secondary system log data set 342
%CAUNIT keyword 101 %OLDOTIM keyword 95 subsystem 345
%CAVCNT keyword 101 %OLDSDDN keyword 95 tracking subsystem log data set 326
%CAVOLS keyword 101 %OLDSDSN keyword 95 ADDN parameter commands
%COPIES keyword 460 %OLDSSEL keyword 95 CHANGE.ADS 135
%DALTIME keyword 102 %OLDSTYP keyword 95 DELETE.ADS 205
%DBADSAV keyword 103 %PLGTIME keyword 102 INIT.ADS 264
%DBADSN keyword 103 %SELECT keyword 96 NOTIFY.RECOV 330
%DBDDN keyword 102, 103 description 88 ADDNNEW parameter
%DBDSN keyword 103 specifying the record types 89 CHANGE.ADS command 136
%DBDSNRV keyword 103 specifying the syntax 94, 103 ADSN parameter commands
%DBDSSEL keyword 103 %SET MEMBER keyword 88, 92 CHANGE.ADS 136
%DBNAME keyword 102, 103 %SET TIMEFMT keyword 88, 93 INIT.ADS 264
%DBTYPE keyword 103 %SLDCHKT keyword 97 ALL parameter
%DBUSID keyword 103 %SLDETIM keyword 96 commands
%DDNAME keyword 89 %SLDFRID keyword 96 CHANGE.DB 144
%DELETE keyword 88, 91 %SLDFSEQ keyword 96 CHANGE.SUBSYS 201
%ENDDEL keyword 88, 91 %SLDLRID keyword 96 GENJCL.ARCHIVE 221
%ENDSEL keyword 88 %SLDRMT keyword 96 LIST.BKOUT 291
%IC2DSN keyword 100 %SLDSDDN keyword 96 LIST.CAGRP 292
%IC2FSEQ keyword 100 %SLDSSEL keyword 96 LIST.DB 293
%IC2SEL keyword 100 %SLDSTIM keyword 96 LIST.DBDSGRP 296
%IC2UNIT keyword 100 %SLDUNIT keyword 96 LIST.SUBSYS 306
%IC2VCNT keyword 100 %SLDVOLS keyword 96 description 144
%IC2VOLS keyword 100 %SSID keyword 87 allocation
%ICCAT keyword 100 %TIME keyword changes to processing 16
%ICDSN keyword 99 as a symbolic keyword 87 database record 71
%ICDSN2 keyword 460 description 436 log record 71
%ICDSN3 keyword 460 RECON data set 55
%ICDSN4 keyword 460 ALLTIME parameter
%ICFSEQ keyword 100
%ICSEL keyword 100 A AMS
NOTIFY.ALLOC command 309
%ICSTOP keyword 100 ABNORMAL parameter commands

See access method services (AMS)
%ICTIME keyword 100 CHANGE.SUBSYS 201
analyzing requirements for data sharing,
%ICTYPE keyword 99 NOTIFY.SUBSYS 346
assigning a sharing level with
%ICUNIT keyword 100 access method services (AMS) 73, 76
DBRC 17
%ICUNIT2 keyword 460

application programming interface
DBRC (Database Recovery Control)
ARSTART parameter
C
accessing RECON data sets 358 command 169 CADSN parameter commands
addressing and residency 354 assigning a sharing level with DBRC 17 CHANGE.CA 139
coding parameters 355 authorization commands INIT.CA 265
DSPAPI macro 353 CHANGE.DB 143, 145 NOTIFY.CA 312
ending the environment 354 CHANGE.DBDS 152, 155 CAJCL parameter
establishing the environment 354 authorization, changing database 114 commands
how to access 353 Automatic RECON Loss Notification CHANGE.CAGRP 141
overview 353 DSPSCIX0 184 INIT.CAGRP 267
prerequisite knowledge AVAIL parameter commands skeletal JCL execution member 450
required 353 CHANGE.ADS 136 calls from IMS to DBRC, elements of
QUERY request 361 CHANGE.PRILOG (for OLDS) 170 DBRC 4
runtime considerations 357 CHANGE.SECLOG (for OLDS) 189, catalog management of data sets in
sample application program 353 190 RECON 115
services available 353 INIT.ADS 264 CATDS
token 356 CHANGE.RECON 180
use in an IMSPlex 359 CATDS parameter commands
CHANGE.RECON 179
use of registers 354
using EQU statements 355
B INIT.RECON 285
BACKIRLM parameter commands category of records
ARCHIVE, GENJCL
CHANGE.SUBSYS 201 listing records 301
archiving OLDS 9
BACKOUT parameter CATIME parameter
ARCHIVED parameter
CHANGE.DB command 146 GENJCL.CA command 228
BACKOUT query CDSLID
command 169
description 363 CHANGE.RECON 181
archiving
output 365 CFSTR1 parameter CHANGE.DBDS
online log data sets, DBRC 8
parameters 363 command 154, 274
ARCHJCL skeletal JCL execution
return codes 364 CFSTR2 parameter CHANGE.DBDS
member 444
syntax 363 command 154, 274
area data sets
backout, BACKOUT record for change accumulation
INIT.ADS command 21
recovery 66 data set
AREA parameter
backout, with data sharing defining 265
commands
batch 22 naming convention 34
CHANGE.ADS 135
dynamic 22 selecting 101
CHANGE.DBDS 154
backup definition of 10
CHANGE.IC 162
creating a copy of RECON 133 group
CHANGE.UIC 203
database 35 changing information in the
DELETE.ADS 205
command for 37 RECON 140
DELETE.ALLOC 206
description 33 defining 47, 266
DELETE.DBDS 209
RECON data set 73 defining for future use 47
DELETE.IC 211
BACKUP.RECON command 73 deleting information from
DELETE.RECOV 216
description 133 RECON 208
DELETE.UIC 219
example 133 listing 292
GENJCL.IC 235
parameters reusing 47
GENJCL.OIC 243
BOTH 133 using 48
GENJCL.RECEIVE 248
RECON1 133 record
GENJCL.RECOV 252
RECON2 133 group 66
INIT.ADS 264
batch backout utility 22, 25 run 66
INIT.DBDS 272
adding backout records to stops processing logs, when 114
INIT.IC 278
RECON 311 change accumulation says nothing to
LIST.DBDS 295
changing backout records in process, when 114
LIST.HISTORY 299
RECON 136 change accumulation stops processing
NOTIFY.ALLOC 310
deleting from RECON 207 logs, when 114
NOTIFY.IC 315
limitations 23 Change Accumulation utility
NOTIFY.RECOV 330
SSID naming convention 113 See Database Change Accumulation
NOTIFY.UIC 347
batch environment utility (DFSUCUM0)
defining a data set 263
command CHANGE.ADS command 135
deleting information from
LIST.SUBSYS 306 CHANGE.BKOUT command 136
RECON 205
NOTIFY.SUBSYS 346 CHANGE.CA command 138
AREANEW parameter
NOTIFY.SUBSYS command 345 CHANGE.CAGRP command 140
CHANGE.DBDS command 155
batch job authorization 78 CHANGE.DB
ARNEEDED parameter
BKO (backout) parameter commands NOREORGI parameter 151
CHANGE.BKOUT 138 REORGI parameter 151
command 169
NOTIFY.BKOUT 311 CHANGE.DB command 143
ARSCHED parameter
BOTH parameter CHANGE.DBDS command 152
BACKUP.RECON command 133 CHANGE.DBDSGRP command 159
command 169
CHANGE.IC command 162

CHANGE.PART command 164 CIC (concurrent image copy) command (continued)
CHANGE.PRILOG command See concurrent image copy (CIC) valid DBRC log-related commands
changing RECON log control CIC parameter (continued)
records 8 commands GENJCL.CLOSE 9
for OLDS 169 GENJCL.IC 235 LIST.LOG 9
for RLDS 171 NOTIFY.IC 316 NOTIFY.PRILOG 9
for SLDS 175 for online image copy 38 NOTIFY.SECLOG 9
for TSLDS 175 CIC parameter, commands command authorization 78
CHANGE.RECON GENJCL.IC 235 using DSPDCAX0 80
parameters 180 NOTIFY.IC 316 using DSPDCAX0 and RACF 80
CHANGE.RECON command 179 CMDAUTH command syntax
allocating space for RECON data CHANGE.RECON 181 comment 123
sets 60 CMDAUTH parameter continuation characters 123
recovering RECONs 76 INIT.RECON 286 definition 123
reorganizing RECON 75 cold start description for DBRC utility 122
CHANGE.SECLOG command commands parameters 123
changing RECON log control CHANGE.BKOUT 136 separators 123
records 8 DELETE.BKOUT 207 commands
for OLDS 189 LIST.BKOUT 291 GENJCL.IC 50
for RLDS 191 multiple in a test environment 116 GENJCL.OIC 50
for SLDS 195 command NOTIFY.IC
for TSLDS 195 /DBDUMP database backup HALDB considerations 50
CHANGE.SG command 200 copies 37 NOTIFY.UIC
CHANGE.SUBSYS command 201 /ERESTART HALDB considerations 50
CHANGE.UIC command 202 restart after DBRC failure 25 COMP parameter commands
changes in allocation and restart after IMS failure 24 CHANGE.CA 140
deallocation 16 /NRESTART, restart after IMS NOTIFY.CA 314
changing information failure 24 complex expressions 92
area data set 135 /REPRO 73, 76 compression
backout records 136 /RMGENJCL 13 PRILOG 74, 110
CA group record 140 /START 251 concurrent image copy (CIC)
database 143 /START command 17 CIC parameter 235
database change accumulation BACKUP.RECON 73 database backup copies 38
utility 138 CHANGE.PART 164 registered database with DBRC 39
DBDS 152 CHANGE.PRILOG 8 restrictions 39
DBDSGRP 159 CHANGE.RECON 60 considerations
IC data set 162 CHANGE.RECON, recovering when using DBRC 33
nonstandard image copy data set 202 RECONs 76 contention, avoiding RECON 56
primary online log data set 169 CHANGE.SECLOG 8 continuation characters 123
primary RLDS 171 DELETE.LOG 74 control group, skeletal JCL 88
primary SLDS 175 GENJCL 13 control keywords, skeletal JCL 88, 103
primary TSLDS 175 GENJCL.ARCHIVE 9 CONTROLINTERVALSIZE keyword
RECON header record 179 GENMAX 40 DEFINE CLUSTER keywords 61
secondary online log data set 189 INIT.ADS 21 COPIES parameter commands
secondary RLDS 191 INIT.CAGRP 47 GENJCL.IC 234
secondary SLDS and TSLDS 195 INIT.DB 20 GENJCL.OIC 243
secondary subsystem entry 201 INIT.DBDS 20, 40 coupling facility structures (CFSTR1 |
service group 200 INIT.PART 280 2) 274
CHECK17 parameter commands INIT.RECON 56 CURRENT parameter commands
CHANGE.RECON 184 INIT.RECON, establishing RECON NOTIFY.RECOV 331
INIT.RECON 286 data sets 20 NOTIFY.REORG 333
CHECK44 parameter commands INIT.RECON, recovering NOTIFY.UIC 347
CHANGE.RECON 184 RECONs 76 CYLINDERS keyword
INIT.RECON 286 NOTIFY.UIC 35 DEFINE CLUSTER keywords 61
CHKINT parameter GENJCL.OIC online
command 243 /RMCHANGE command 122
CHKPTCT parameter commands
CHANGE.PRILOG (for RLDS) 172
/RMDELETE command 122
/RMGENJCL command 122
D
damaged RECON data set 75
CHANGE.PRILOG (for SLDS) 176 /RMINIT command 122
DASDUNIT parameter commands
CHANGE.SECLOG (for RLDS) 192 /RMLIST command 122
CHANGE.RECON 182
CHANGE.SECLOG (for SLDS) 196 /RMNOTIFY 122
INIT.RECON 286
NOTIFY.PRILOG (for RLDS) 322 valid DBRC log-related commands
data set allocation, RECON data set
NOTIFY.PRILOG (for SLDS and CHANGE.PRILOG 9
creating 60
TSLDS) 327 CHANGE.RECON 9
shared among multiple processors 57
NOTIFY.SECLOG (for RLDS) 339 CHANGE.SECLOG 9
data set, RECON 55
NOTIFY.SECLOG (for SLDS) 343 DELETE.LOG 9
data sets
GENJCL.ARCHIVE 9
A-through-J 50
Index 577
data sets (continued) Database Change Accumulation utility Database Change Accumulation utility
M-through-V 50 (DFSUCUM0) (continued) (DFSUCUM0) (continued)
data sharing 16 commands (continued) commands (continued)
assigning a sharing level with CHANGE.SECLOG (for NOTIFY.REORG 332
DBRC 17 RLDS) 191 NOTIFY.SECLOG (for OLDS) 335
batch backout 22 CHANGE.SECLOG (for SLDS and NOTIFY.SECLOG (for RLDS) 338
database integrity 17 TSLDS) 195 NOTIFY.SECLOG (for SLDS) 342
dynamic backout 22 CHANGE.SG 200 NOTIFY.UIC 346
forward recovery 24 CHANGE.SUBSYS 201 RESET.GSG 349
information in the RECON data CHANGE.UIC 202 description 43
set 17 DELETE.ADS 205 execution recorded by DBRC 47
levels of 16 DELETE.ALLOC 206 input 45
block level 16 DELETE.BKOUT 207 subset of log volumes 45
database level 16 DELETE.CA 207 valid log subset with DBRC 47
merging logs 47 DELETE.CAGRP 208 database change accumulation utility JCL
online reorganization 52 DELETE.DB 208 adding information to RECON 312
planning for recovery 21 DELETE.DBDS 209 changing information about a
record 72 DELETE.DBDSGRP 210 run 138
database DELETE.GSG 210 deleting information from
adding information to RECON 332 DELETE.IC 211 RECON 207
allocation record 71 DELETE.LOG (for OLDS) 212 generating a job 225
authorization, changing 114 DELETE.LOG (for RLDS) 212 skeletal JCL 450
backup 35, 43 DELETE.LOG (for SLDS) 212 database data set record 67
commands for 37 DELETE.RECOV 216 Database Image Copy 2 utility
backup copies DELETE.REORG 217 (DFSUDMT0) 37
/DBDUMP command 37 DELETE.SG 217 Database Image Copy utility
changing information 143 DELETE.SUBSYS 218 (DFSUDMP0) 37
data set groups, changing DELETE.UIC 218 adding information to RECON 314
information 159 GENJCL.ARCHIVE 221 creating data sets for future use 39
data set, changing information 152 GENJCL.CA 225 description 35
defining 268 GENJCL.CLOSE 229 execution recorded by DBRC 35
deleting information from GENJCL.IC 233 generating a job 233
RECON 208 GENJCL.OIC 242 maximum number of generations 40
integrity in data sharing 17 GENJCL.RECEIVE 247 nonstandard image copy data sets 43
listing 293 GENJCL.RECOV 251 recovery period 40
making HISAM copies 42 GENJCL.USER 257 reusing image copy data sets 41
making image copies 35 INIT.ADS 263 skeletal JCL 455
open exit 16 INIT.CA 265 database recovery
record 67 INIT.CAGRP 266 Database Image Copy 2 output
database allocation record 71 INIT.DB 268 format 38
Database Change Accumulation INIT.DBDS 271 defining groups 276
utility 44 INIT.DBDSGRP 276 groups 67
Database Change Accumulation utility INIT.GSG 277 database recovery control
(DFSUCUM0) INIT.IC 278 changing information 162
CA group INIT.RECON 284 changing partition information 164
defining 47 INIT.SG 289 data set, creating a backup copy 133
defining for future use 47 LIST.BKOUT 291 Database Recovery Control
reusing 47 LIST.CAGRP 292 See DBRC (Database Recovery
commands LIST.DB 293 Control)
BACKUP.RECON 133 LIST.DBDS 294 Database Recovery Control utility
CHANGE.ADS 135 LIST.DBDSGRP 296 (DSPURX00)
CHANGE.BKOUT 136 LIST.GSG 297 description 27
CHANGE.CA 138 LIST.HISTORY 298 generating a job 251, 257
CHANGE.CAGRP 140 LIST.LOG (for a category of GENJCL.RECOV command 251
CHANGE.DBDSGRP 159 records) 301 overview 27
CHANGE.IC 162 LIST.LOG (for a PRILOG database recovery records 65
CHANGE.PRILOG (for family) 300 database recovery with data sharing
OLDS) 169 LIST.RECON 304 batch 22
CHANGE.PRILOG (for NOTIFY.ALLOC 309 data sharing 24
RLDS) 171 NOTIFY.BKOUT 311 dynamic 22
CHANGE.PRILOG (for NOTIFY.CA 312 forward 24
SLDS) 175 NOTIFY.IC 314 managing system logs 47
CHANGE.PRILOG (for NOTIFY.PRILOG (for OLDS) 317 DB Groups 49
TSLDS) 175 NOTIFY.PRILOG (for RLDS) 321 DB header record
CHANGE.RECON 179 NOTIFY.PRILOG (for SLDS and HALDB 68
CHANGE.SECLOG (for TSLDS) 326 DB partition
OLDS) 189 NOTIFY.RECOV 329 HALDB 69

DB query DBDS (database data set) group DBRC (Database Recovery Control)
output 372 (continued) (continued)
overview 367 commands that specify (continued) database backup (continued)
parameters 368 GENJCL.USER 48 controlling the number of image
return codes 370 LIST.DBDS 48 copies managed 39
syntax 367 LIST.HISTORY 48 creating image copy data sets for
DB.INIT command defining 276 future use 39
defining databases 20 deleting information from Database Image Copy
DBD parameter commands RECON 210 (DFSUDMP0) 37
CHANGE.ADS 136 LIST command 296 Database Image Copy 2
CHANGE.BKOUT 138 record 67 (DFSUDMT0) 37
CHANGE.DB 144 using 48 guidelines 43
CHANGE.DBDS 154 DBDS, INIT command HISAM copies 42
CHANGE.IC 162 defining databases 20 methods 35
CHANGE.UIC 202 DBDS, INIT.DBDS command Online Database Image Copy
DELETE.ADS 205 specifying image copy (DFSUICP0) 38
DELETE.ALLOC 206 requirements 40 recovering a database 12
DELETE.DB 209 DBRC (Database Recovery Control) recovery period of image copy
DELETE.DBDS 209 See also Database Recovery Control data sets and GENMAX 40
DELETE.IC 211 utility (DSPURX00) reusing image copy data sets 41
DELETE.PART 215 active and spare RECON 62 Database Recovery Control utility
DELETE.RECOV 216 application programming interface (DSPURX00) 4
DELETE.REORG 217 accessing RECON data sets 358 DB query
DELETE.UIC 219 addressing and residence 354 output 372
GENJCL.IC 234 coding parameters 355 overview 367
GENJCL.OIC 242 DSPAPI macro 353 parameters 368
GENJCL.RECEIVE 247 ending the environment 354 return codes 370
GENJCL.RECOV 252 establishing the environment 354 syntax 367
GENJCL.USER 257 how to access 353 DBRC components 4
INIT.ADS 264 overview 353 DBRC log control 7
INIT.DB 268 QUERY request 361 DBRC parameter
INIT.DBDS 271 runtime considerations 357 IMSCTRL macro 19
INIT.IC 278 sample application program 353 DBRC procedure 20
LIST.DB 293 services available 353 defining to IMS 19
LIST.DBDS 295 tokens 356 description 33
LIST.HISTORY 298 use in an IMSPlex 359 generating JCL 5
NOTIFY.ALLOC 310 use of registers 354 GENMAX, resetting 109
NOTIFY.BKOUT 311 using EQU statements 355 GROUP query
NOTIFY.IC 314 assigning a sharing level 17 output 393
NOTIFY.RECOV 330 authorization, changing database 114 overview 390
NOTIFY.REORG 333 BACKOUT query parameters 390
NOTIFY.UIC 347 output 365 return codes 392
DBDS (database data set) return codes 364 syntax 390
A-through-J, L and X 51 calls from IMS 4 IMS procedures and 19
commands 252 catalog management of data sets 115 initial RECON access 62
GENJCL.RECOV 252 change accumulation says nothing to initializing the RECON data set 20
LIST.DB 294 process, when 114 log control 7
NOTIFY.RECOV 331 change accumulation stops processing log data sets 60
defining 271 logs, when 114 LOG query
listing 294 closing an open online PRILOG 111 output 403
M-through-V and Y 51 commands overview 399
qualifier 90 INIT.CA 47 parameters 400
RECON, deleting information INIT.CAGRP 47 return codes 402
from 209, 211 introduction 121 syntax 400
selecting DBDS records 101, 102 components 4 log records, deleting 112
DBDS (database data set) group controlling database recovery 11, 14, maintaining RECON records 73
commands that affect the definition 18 notifying that log data sets have
CHANGE.DBDSGRP 48 data sets moved 115
DELETE.DBDS 48 defining recovery OLDS query
DELETE.DBDSGRP 48 requirements 11 output 410
INIT.DBDSGRP 48 partitioned 5 overview 408
LIST.DBDSGRP 48 RECON 73 parameters 408
commands that specify RECON data set 4, 55 return codes 409
GENJCL.IC 48 SSYS record 72 syntax 408
GENJCL.OIC 48 use of output data set 359 online commands 122
GENJCL.RECEIVE 48 database backup 35 overview 3
GENJCL.RECOV 48 Concurrent Image Copy 38
Index 579
DBRC (Database Recovery Control) DBRC Command Authorization Support DEFLTJCL parameter (continued)
(continued) using both DSPDCAX0 and INIT.CAGRP 267
parameters RACF 80 INIT.DBDS 272
IMS.PROCLIB execution using DSPDCAX0 80 DELEQE parameter CHANGE.DBDS
parameter 19 DBTRACK parameter command 154
partitioned data set members 5 CHANGE.DB command 149 delete group 88
QUERY request CHANGE.DBDS command 158 delete log records, how to 112
BACKOUT 363 DDN parameter commands DELETE parameter commands
RECON data set CHANGE.DBDS 154 CHANGE.BKOUT 137
creating 60 CHANGE.IC 162 CHANGE.CAGRP 141
shared among multiple CHANGE.UIC 203 DELETE.ADS command 205
processors 57 DELETE.ALLOC 206 DELETE.ALLOC command 206
RECON data set, registering databases DELETE.DBDS 209 DELETE.BKOUT command 207
in 20 DELETE.IC 211 DELETE.CA command 207
RECON status query DELETE.RECOV 216 DELETE.CAGRP command 208
output 415 DELETE.REORG 217 DELETE.DB command 208
overview 413 DELETE.UIC 219 DELETE.DBDS command 209
parameters 413 GENJCL.IC 235 DELETE.DBDSGRP command 210
return codes 414 GENJCL.OIC 243 DELETE.GSG command 210
syntax 413 GENJCL.RECEIVE 248 DELETE.IC command 211
RECON, defining recovery GENJCL.RECOV 252 DELETE.LOG (for OLDS) command 212
requirements 11 GENJCL.USER 258 DELETE.LOG (for RLDS) command 212
recording change accumulations 47 INIT.DBDS 272 DELETE.LOG (for SLDS) command 212
recording image copies 35 INIT.IC 278 DELETE.PART command
recovery utilities 14 LIST.DBDS 295 DBD parameter 215
RELBUF query LIST.HISTORY 299 PART parameter 215
overview 423 NOTIFY.ALLOC 310 syntax 215
return codes 424 NOTIFY.IC 315 DELETE.RECOV command 216
syntax 423 NOTIFY.RECOV 330 DELETE.REORG command 217
request time-stamp format 358 NOTIFY.REORG 333 DELETE.SG command 217
share control 16 NOTIFY.UIC 347 DELETE.SUBSYS command 218
SLDS stop time, locating the last in DDNNEW parameter DELETE.UIC command 218
RECON data set 108 CHANGE.DBDS command 155 deleting a SSYS record 113
specifying when it is to be used 19 deadlock, avoiding RECON data set 57 deleting information
STARTDBRC request deallocation, changes to processing 16 all change accumulation group
overview 427 DEALTIME parameter command records 208
parameters 427 NOTIFY.ALLOC 310 all database data set records 209
return codes 428 DEDB Fast Path record 69 all database records 208
syntax 427 default members allocation record of database data
STOPDBRC request See skeletal JCL set 206
overview 431 DEFAULTS parameter commands area data set 205
parameters 431 GENJCL.ARCHIVE 222 backout record 207
syntax 431 GENJCL.CA 226 change accumulation run record 207
SUBSYS query GENJCL.CLOSE 230 database data set group records 210
output 421 GENJCL.IC 237 global service group records 210
overview 417 GENJCL.OIC 243 image copy data set records 211
parameters 418 GENJCL.RECEIVE 248 log records 112
return codes 419 GENJCL.RECOV 252 nonstandard image copy data
syntax 417 GENJCL.USER 258 sets 218
subsystem (SSYS) records 113 DEFINE CLUSTER keywords 60 online log data set records 212
system, considerations for a 33 CONTROLINTERVALSIZE 61 recovery log data set records 212
tailoring JCL 9 CYLINDERS 61 recovery run record 216
time stamp 126 FREESPACE 61 reorganization records 217
tips 107 INDEXED 61 service group records 217
variables 60 KEYS 61 subsystem records 218
when should you use it 5 NAME 61 system log data set records 212
DBRC (Database Recovery Control) NOWRITECHECK 62 deleting unnecessary RECON records 74
commands RECORDSIZE 62 DELMEM parameter,
Database Recovery Control utility SHAREOPTIONS 62 CHANGE.DBDSGRP command 160
(DSPURX00) 4 SPEED 62 DEQ macro 58
DBRC Command Authorization exit defining DFSUARC0 (Log Archive utility)
routine (DSPDCAX0) 80 DB groups 276 description 8
DBRC command authorization DBDS groups 276 DFSUCUM0 (Database Change
support 78 recovery groups 276 Accumulation utility)
using a security product 79 DEFLTJCL parameter See also Database Change
CHANGE.CAGRP 141 Accumulation utility (DFSUCUM0)
CHANGE.DBDS 155

DFSUCUM0 (Database Change DSPAPI FILESEQ parameter commands
Accumulation utility) (continued) accessing 357 (continued)
CA group forms CHANGE.IC 162
defining 47 execute 357 CHANGE.PRILOG (for RLDS) 173
defining for future use 47 list 356 CHANGE.PRILOG (for SLDS) 177
reusing 47 modify 357 CHANGE.SECLOG (for RLDS) 193
description 43 standard 356 CHANGE.SECLOG (for SLDS) 197
execution recorded by DBRC 47 versions 356 INIT.CA 265
input 45 DSPAPI macro INIT.IC 279
subset of log volumes 45 overview 353 NOTIFY.CA 313
DFSUDMP0 (Database Image Copy DSPAPSMP sample DBRC application NOTIFY.IC 315
utility) program 353 NOTIFY.PRILOG (for RLDS) 323
See Database Image Copy utility DSPDBHRC 68 NOTIFY.PRILOG (for SLDS and
(DFSUDMP0) partition DB record TSLDS) 328
DFSUICP0 (Online Database Image Copy HALDB 69 NOTIFY.REORG 333
utility) DSPDCAX0 80 NOTIFY.SECLOG (for RLDS) 340
See also Online Database Image Copy DSPDSHRC NOTIFY.SECLOG (for SLDS or
utility (DFSUICP0) partition DBDS records TSLDS) 343
creating data sets for future use 39 HALDB 69 FILESEQ2 parameter commands
description 35 DSPPTNRC CHANGE.IC 162
execution recorded by DBRC 35 HALDB partition record INIT.IC 279
DFSULTR0 (Log Recovery utility) HALDB 69 NOTIFY.IC 316
generating a job 229 DSPSCIX0 78 NOTIFY.REORG 334
DFSURUL0 (HISAM Reorganization DSPSCIX0 exit 184 FORCER parameter commands
Unload utility) DSPURX00 (Database Recovery Control CHANGE.RECON 183
for backup 42 utility) INIT.RECON 286
discarded RECON, replacing 77 See Database Recovery Control utility forward recovery with data sharing 24
DSECTs (DSPURX00) FPAREA parameter, GENJCL.RECOV
DSPAPQAL 386 DSSN parameter NOTIFY.ALLOC command 252
DSPAPQAR 376 command 310 FREESPACE keyword
DSPAPQDB 372 DSSTART parameter commands DEFINE CLUSTER keywords 61
DSPAPQDS 383 CHANGE.PRILOG (for RLDS) 172 FROMTIME parameter commands
DSPAPQEL 378 CHANGE.PRILOG (for SLDS) 177 LIST.HISTORY 299
DSPAPQFD 375 CHANGE.SECLOG (for RLDS) 192 LIST.LOG 303
DSPAPQHB 380 CHANGE.SECLOG (for SLDS) 197 functions of DBRC
DSPAPQHP 380 DUAL parameter CHANGE.RECON data sharing 7
DSPAPQIC 386 command 182 database recovery 7
DSPAPQLA 407 dump format 38 logs 7
DSPAPQLG 405 dynamic allocation 60 fuzzy image copies
DSPAPQLI 404 of RECON data set 60 definition of 36
DSPAPQOL 411 dynamic backout with data sharing 22
DSPAPQRC 415
DSPAPQRI 385 G
DSPAPQRR 388
DSPAPQRV 388
E GAP parameter, CHANGE.PRILOG (for
ENDRECOV parameter commands RLDS) 173, 174
DSPAPQSL 373
CHANGE.SUBSYS 202 Generalized Trace Facility (GTF) USR
DSPAPQSS 421
NOTIFY.SUBSYS 346 records 187
DSECTS
enqueue problems, causes of generating a job
DSPAPQCG 395
RECON 117 Change Accumulation utility 225
DSPAPQDG 393
error, RECON I/O 75 Database Image Copy utility 233
DSPAPQGG 398
execution members Database Recovery utility 251, 257
DSN commands
See JCL (job control language), skeletal Log Archive utility 221
CHANGE.DBDS 155
execution members explained Log Recovery utility 229
CHANGE.PRILOG (for OLDS) 170
exit Online Database Image Copy
CHANGE.PRILOG (for RLDS) 172
database open 16 utility 242
CHANGE.PRILOG (for SLDS) 176
RECON I/O 81 generating JCL 83
CHANGE.SECLOG (for OLDS) 190
generating user output 83
CHANGE.SECLOG (for SLDS) 196
GENJCL command, generating JCL 13
INIT.DBDS 272
NOTIFY.PRILOG (for OLDS) 318 F GENJCL commands, description 83
GENJCL.ARCHIVE command
NOTIFY.PRILOG (for RLDS) 322 failure and restart with data sharing 21
log control requirements in
NOTIFY.PRILOG (for SLDS) 326 Fast Path
RECON 9
NOTIFY.PRILOG (for TSLDS) 326 registering databases and DEDB
syntax 221
NOTIFY.SECLOG (for OLDS) 336 areas 17
TIMEFMT parameter 223
NOTIFY.SECLOG (for RLDS) 339 Fast Path DEDB record 69
GENJCL.CA command 225
NOTIFY.SECLOG (for SLDS) 342 FILESEQ parameter commands
CHANGE.CA 139
GENJCL.CLOSE command 229
Index 581
GENJCL.CLOSE command (continued) GRPNAME parameter commands ICDSN parameter commands (continued)
TIMEFMT parameter 231 (continued) reusing 41
GENJCL.IC 37 NOTIFY.CA 312 selecting 99
HALDB online reorganization 50 GRS macro 57 ICDSN2 parameter commands
GENJCL.IC command 233 GSG parameter commands CHANGE.IC 163
TIMEFMT parameter 238 CHANGE.PRILOG (for RLDS) 173 DELETE.IC 211
GENJCL.OIC 37 CHANGE.PRILOG (for SLDS) 177 INIT.IC 279
HALDB online reorganization 50 CHANGE.SECLOG (for RLDS) 193 NOTIFY.IC 316
GENJCL.OIC command 242 CHANGE.SECLOG (for SLDS) 197 NOTIFY.REORG 334
TIMEFMT parameter 245 GSGNAME parameter commands ICJCL parameter
GENJCL.RECEIVE command 247 CHANGE.DB 145 commands
TIMEFMT parameter 249 CHANGE.DBDS command 156 CHANGE.DBDS 156
GENJCL.RECOV command 251 GTF (Generalized Trace Facility) USR GENJCL.CA 226
parameters records 187 GENJCL.CLOSE 230
USEAREA 255 GENJCL.IC 237
USEDBDS 255 GENJCL.OIC 244
USEIC 255
USEOLRRG 255
H GENJCL.RECEIVE 248
GENJCL.RECOV 253
HALDB
RESTORE parameter 254 GENJCL.USER 258
DBRC commands supported 49
TIMEFMT parameter 254 INIT.DBDS 272
master (DSPDBHRC)
GENJCL.USER command 257 skeletal JCL execution member 455
DB header record 68
TIMEFMT parameter 259 ICOFF parameter CHANGE.DBDS
OLR coexistence support 51
GENMAX parameter command 156
partition 69
image copy data sets for future ICON parameter CHANGE.DBDS
partition DB record (DSPDBHRC) 69
use 39 command 156
partition DBDS records
of the INIT.DBDS command 272 ICRCVJCL parameter skeletal JCL
(DSPDSHRC) 69
resetting 109 execution member 463
partition record (DSPPTNRC)
specifying image copy ICREQ parameter CHANGE.DB
PHDAM 69
requirements 40 command 146
types of DBDSs 69
Global Resource Serialization macro 57 ICREQ parameter INIT.DB
HALDB partition
global service group command 269
registering 280
deleting information 210 ILDS (Indirect List Data Set) 48
header record, RECON data set 64
listing 297 Index/ILDS Rebuild Utility
hints and tips
record 70 (DFSPREC0) 14
using DBRC 107
resetting 349 image copies
adjusting GENMAX when it is
GROUP parameter commands 234 fuzzy 36
reached or is too high 109
GENJCL.IC 234 image copy 2 JCL 455
locating the last SLDS Stop Time in
GENJCL.OIC 242 image copy data set
RECON 108
GENJCL.RECEIVE 247 recovery period 40
PRILOG compression not
GENJCL.RECOV 252 Image Copy Group record 70
working 110
GENJCL.USER 257 Image Copy utility
PRILOG record sizes 111
LIST.DBDS 295 See also Database Image Copy utility
HISAM Reorganization Unload utility
LIST.HISTORY 298 (DFSUDMP0)
(DFSURUL0)
GROUP query See Online Database Image Copy
for backup 42
output 393 utility (DFSUICP0)
HISTORY command 298
overview 390 IMS recovery utilities 14
HSSP data set 42
parameters 390 IMS Structured Call Interface (SCI) 78
database registered with DBRC 42
return codes 392 IMS.PROCLIB 5
syntax 390 IMS.SDFSISRC 5
GRPMAX parameter commands IMSCTRL macro
CHANGE.CAGRP 141 I archiving OLDS 9
INIT.CAGRP 266 ICDSN parameter commands parameters 19
GRPMEM parameter INIT.CAGRP CHANGE.IC 163 IMSplex
command 266 creating for future use 39 use of DSPAPI 359
GRPNAME parameter commands defining 278 IMSPLEX
CHANGE.CA 139 duplicate, naming convention 34 CHANGE.RECON 183
CHANGE.CAGRP 141 INIT.IC 278 DSPSCIX0 184
CHANGE.DBDSGRP 160 maximum number of generations 40 IMSplex, DBRC support of 18
DELETE.CA 207 naming convention 34 INACTIVE parameter DELETE.LOG (for
DELETE.CAGRP 208 nonstandard 43 RLDS and SLDS) command 213
DELETE.DBDSGRP 210 NOTIFY.IC 315 Index/ILDS Rebuild utility
GENJCL.CA 226 NOTIFY.REORG 334 (DFSPREC0) 14
INIT.CA 265 RECON INDEXED keyword
INIT.CAGRP 267 adding information 329 DEFINE CLUSTER keywords 61
INIT.DBDSGRP 276 changing information 162 INIT.ADS command
LIST.CAGRP 292 record 70 description 263
LIST.DBDSGRP 296 recovery period 40 INIT.CA command 265

INIT.CAGRP command 266 JCLOUT parameter LIST.CAGRP command 292
INIT.DB command command GENJCL.ARCHIVE 222 LIST.DB command 293
description 268 skeletal JCL 84 LIST.DBDS command 294
INIT.DBDS command JCLPDS parameter LIST.DBDSGRP command 296
description 271 commands 222 LIST.GSG command 297
REUSE keyword 41 GENJCL.ARCHIVE 222 LIST.HISTORY command 298
INIT.DBDSGRP command 276 GENJCL.CA 226 LIST.LOG (for a category of records)
INIT.GSG command 277 GENJCL.CLOSE 230 command 301
INIT.IC command 278 GENJCL.IC 237 LIST.LOG (for a PRILOG family)
INIT.PART command 280 GENJCL.OIC 244 command 300
INIT.RECON command GENJCL.RECEIVE 248 LIST.RECON command
description 284 GENJCL.RECOV 253 description 304
establishing RECON data sets 20 GENJCL.USER 258 fields displayed by command 533
initializing the RECON data set 56 skeletal JCL 84 sample listing 473
recovering RECONs 76 job control language (JCL) LIST.SUBSYS command 306
INIT.SG command 289 See JCL (job control language) listing
initialize JOB parameter commands backout records 291
area data set 263 GENJCL.ARCHIVE 222 category of records 301
change accumulation data set 265 GENJCL.CA 226 change accumulation group 292
change accumulation group 266 GENJCL.CLOSE 230 database 293
database 268 GENJCL.IC 237 database data set 294
database data set 271 GENJCL.OIC 244 database groups 296
database data set groups 276 GENJCL.RECEIVE 248 database histories 298
global service group 277 GENJCL.RECOV 253 global service group 297
image copy data sets 278 GENJCL.USER 258 PRILOG family 300
RECON header records 284 JOBJCL RECON 304, 473
service group 289 skeletal JCL execution member 13, subsystem 306
initializing DBRC 444 LKASID parameter
DBRC procedure 20 CHANGE.DBDS command 157
IMSCTRL Macro 19 INIT.DBDS command 275
initializing the RECON data set 20
input/output error processing 75
K Local Shared Resources (LSR) option 61
log allocation record 71
KEYS keyword
INTERIM parameter commands Log Archive utility (DFSUARC0)
DEFINE CLUSTER keywords 61
DELETE.LOG (for OLDS) 212 description 8
keyword
DELETE.LOG (for RLDS and log control
%IC 460
SLDS) 214 valid API requests
%ICDSN2 460
NOTIFY.PRILOG (for OLDS) 319 Log query 10
%ICDSN3 460
NOTIFY.PRILOG (for RLDS) 323 OLDS query 10
%ICDSN4 460
NOTIFY.PRILOG (for SLDS and valid commands
%ICUNIT2 460
TSLDS) 328 CHANGE.PRILOG 9
%ICUNIT3 460
NOTIFY.SECLOG (for OLDS) 337 CHANGE.RECON 9
%ICUNIT4 460
NOTIFY.SECLOG (for RLDS) 340 CHANGE.SECLOG 9
%ICVCNT2 460
NOTIFY.SECLOG (for SLDS or DELETE.LOG 9
%ICVCNT3 460
TSLDS) 344 GENJCL.ARCHIVE 9
%ICVCNT4 460
INVALID parameter commands GENJCL.CLOSE 9
%ICVOLS2 460
CHANGE.CA 139 LIST.LOG 9
%ICVOLS3 460
CHANGE.IC 163 NOTIFY.PRILOG 9
%ICVOLS4 460
INVALID2 parameter NOTIFY.SECLOG 9
DEFINE CLUSTER 60
CHANGE.IC command 163 log data sets, records 64, 65
substitution 86
description 163 LOG query
keywords, symbolic
IRLM (Internal Resource Lock Manager) output 403
See symbolic keywords, JCL execution
data sharing 17 overview 399
member
database integrity 17 parameters 400
with batch backout 22 return codes 402
IRLMID parameter commands syntax 400
CHANGE.SUBSYS 201 L log records, deleting 112
NOTIFY.SUBSYS 346 level of sharing definitions 17 Log Recovery utility (DFSULTR0)
LIST parameter commands generating a job 229
GENJCL.ARCHIVE 223 log volumes, specifying
J GENJCL.CA 226
GENJCL.CLOSE 231
a subset 45
all 45
JCL (job control language)
GENJCL.IC 237 LOGCLJCL skeletal JCL execution
generated by DBRC 5
GENJCL.OIC 244 member 453
generating 83
GENJCL.RECEIVE 249 logging
skeletal execution members
GENJCL.RECOV 253 accumulating logs using
explained 5
GENJCL.USER 258 DFSUCUM0 43
tailoring for utilities 9
LIST.BKOUT command 291
JCL allocation 60
Index 583
logging (continued) NEWTIME parameter commands nonstandard image copy data sets
condensing logs using (continued) (continued)
DFSUCUM0 43 CHANGE.SECLOG (for SLDS) 197 RECON
LOGRET parameter NEWVOL parameter commands adding information 346
INIT.RECON 287 CHANGE.PRILOG (for RLDS) 173 changing information 202
LOGRET parameter of CHANGE.PRILOG (for SLDS) 177 deleting information 218
CHANGE.RECON 185 CHANGE.SECLOG (for RLDS) 193 NOOWNER parameter 149
LSR (Local Shared Resources option) 61 CHANGE.SECLOG (for SLDS) 197 NOPREL parameter CHANGE.DBDS
NOAUTH parameter command 157
CHANGE.DB 145 NOPREO parameter CHANGE.DBDS
M CHANGE.DBDS 155
NOBACK parameter CHANGE.DB
command 158
NORECOV parameter
macro
command 146 NOTIFY.REORG 334
DEQ 58
NOBACKUP parameter NORECOV parameter CHANGE.DBDS
DFP Record Management Services 58
CHANGE.SUBSYS command 201 command 158
DSPAPI
NOCATDS NOREORGI parameter
accessing 357
CHANGE.RECON 180 CHANGE.DB 151
forms 356
NOCATDS parameter commands NOREUSE parameter
overview 353
CHANGE.RECON 179 CA data set 47
versions 356
INIT.RECON 285 CHANGE.DBDS 156
GRS 57
NOCFSTR2 parameter CHANGE.DBDS command
IMSCTRL 9
command 155 CHANGE.CAGRP 142
OBTAIN 58
NOCHECK parameter image copy data sets for future
RESERVE 57
CHANGE.RECON 184 use 39
maximum number of generations, image
INIT.RECON 286 INIT.CAGRP 267
copy data sets, GENMAX
NODEFLT parameter commands INIT.DBDS 273
parameter 155, 272
CHANGE.CAGRP 141 NORMAL parameter commands
MAXOLDS parameter
GENJCL.CA 227 CHANGE.PRILOG (for OLDS) 170
GENJCL.ARCHIVE command 223
GENJCL.IC 238 CHANGE.PRILOG (for RLDS) 172
MEMBER parameter
GENJCL.OIC 244 CHANGE.PRILOG (for SLDS) 177
GENJCL.ARCHIVE command 223
GENJCL.RECOV 254 CHANGE.SECLOG (for OLDS) 190
GENJCL.CA 227
GENJCL.USER 259 CHANGE.SECLOG (for RLDS) 192
GENJCL.CLOSE 231
NOFORCER parameter commands CHANGE.SECLOG (for SLDS) 197
GENJCL.IC 237
CHANGE.RECON 183 CHANGE.SUBSYS 201
GENJCL.OIC 244
INIT.RECON 286 NOTIFY.SUBSYS 346
GENJCL.RECEIVE 249
NOICREQ parameter CHANGE.DB normal restart 24
GENJCL.RECOV 253
command 146 NOTCOVER parameter
GENJCL.USER 257
NOICREQ parameter INIT.DB CHANGE.DB command 145
INIT.DBDSGRP 276
command 269 CHANGE.DBDS command 156
members
NOJOB parameter commands nothing to process, when change
See skeletal JCL
GENJCL.ARCHIVE 222 accumulation says 114
merging logs 47
GENJCL.CA 226 NOTIFY.ALLOC command 309
MULTIJOB parameter commands
GENJCL.CLOSE 230 NOTIFY.BKOUT command 311
GENJCL.IC 237
GENJCL.IC 237 NOTIFY.CA command 312
GENJCL.OIC 244
GENJCL.OIC 244 NOTIFY.IC command
GENJCL.RECOV 253
GENJCL.RECEIVE 248 HALDB considerations 50
GENJCL.USER 259
GENJCL.RECOV 253 NOTIFY.PRILOG (for OLDS)
multiple
GENJCL.USER 258 command 317
cold starts in a test environment 116
NOLIST parameter commands NOTIFY.PRILOG (for RLDS)
GENJCL.ARCHIVE 223 command 321
GENJCL.CA 226 NOTIFY.PRILOG (for SLDS and TSLDS)
N GENJCL.CLOSE 231 command 326
NAME keyword GENJCL.IC 237 NOTIFY.RECOV command 329
DEFINE CLUSTER keywords 61 GENJCL.OIC 244 NOTIFY.REORG command 332
naming conventions GENJCL.RECEIVE 249 NOTIFY.SECLOG (for OLDS)
change accumulation data sets 34 GENJCL.RECOV 253 command 335
DBRC data sets 33 GENJCL.USER 258 NOTIFY.SECLOG (for RLDS)
duplicate image copy data sets 34 NOLKASID parameter command 338
image copy data sets 34 CHANGE.DBDS command 157, 275 NOTIFY.SECLOG (for SLDS)
SSIDs in RECON SSYS records, NONEW parameter commands 288 command 342
for 113 CHANGE.RECON 186 NOTIFY.SUBSYS command 345
SSIDs processed by batch backout, INIT.RECON 288 NOTIFY.UIC command
for 113 NONRECOV parameter, description 346
NEWTIME parameter commands CHANGE.DB 147 HALDB considerations 50
CHANGE.PRILOG (for RLDS) 173 nonstandard image copy data sets notifying DBRC that log data sets have
CHANGE.PRILOG (for SLDS) 177 description 43 moved 115
CHANGE.SECLOG (for RLDS) 193 NOVSO parameter 159

NOVSO parameter (continued) Online Database Image Copy utility JCL PRELOAD parameter CHANGE.DBDS
CHANGE.DBDS 159, 274 See OICJCL parameter command 157
NOWRITECHECK keyword online log data set PREOPEN parameter CHANGE.DBDS
DEFINE CLUSTER keywords 62 See OLDS (online log data set) command 158
NXTOLDS parameter commands online log data set (OLDS) PRILOG
NOTIFY.PRILOG (for OLDS) 320 records 65 closing an open online 111
NOTIFY.SECLOG (for OLDS) 337 ONLINE parameter 334 compression 110
ONLINE parameter commands compression, automatic 74
LIST.SUBSYS 306 PRILOG family
O NOTIFY.IC 316
NOTIFY.SUBSYS 346
listing records 300
procedures, installation 19
OBTAIN macro 58
online reorganization PSB parameter commands 138
OFFLINE parameter 334
data sharing 52 CHANGE.BKOUT 138
OICJCL parameter
DBRC commands supported 49 GENJCL.OIC 243
commands 157
maintaining recovery records 52 GENJCL.USER 259
CHANGE.DBDS 157
OLR coexistence support 51 NOTIFY.BKOUT 311
INIT.DBDS 273
process description 53 purge time, defined 46
skeletal JCL execution member 461
recommendations 54 PURGLIST parameter NOTIFY.CA
OLDS (online log data set)
records used 50 command 313
See also logging
REORG records 52
archiving DBRC 8
restrictions 54
changing information 169, 189
commands
RSR tracking system 52 Q
CHANGE.PRILOG 169 QUERY request
CHANGE.SECLOG 190 general format of output 362
DELETE.LOG (for OLDS) 212 P output
GENJCL.ARCHIVE 221 parameter BACKOUT 365
GENJCL.CLOSE 231 CIC 38 DB 372
NOTIFY.PRILOG (for OLDS) 318 DBRC for online IMS 19 GROUP 393
NOTIFY.SECLOG (for OLDS) 336 GENMAX 39 LOG 403
RECON NOREUSE 39, 47 OLDS 410
adding information 317, 335 record type 89 RECON status 415
deleting information 212 RECOVPD 40 SUBSYS 421
records 65 REUSE 39 output from 361
selecting in JCL 94 selection criteria 90 overview 361
OLDS query STARTNEW 76 SUBSYS 417
output 410 parameters parameters
overview 408 coding for DSPAPI macro 355 BACKOUT 363
parameters 408 DBRC application programming DB 368
return codes 409 interface 355 GROUP 390
syntax 408 NOOWNER 149 LOG 400
OLDVOL parameter commands NORECOV 334 OLDS 408
CHANGE.PRILOG (for RLDS) 173 OFFLINE 334 RECON status 413
CHANGE.PRILOG (for SLDS) 178 OLRBYTES 148 SUBSYS 418
CHANGE.SECLOG (for RLDS) 194 OLRCAP 147, 270 return codes
CHANGE.SECLOG (for SLDS) 198 OLRDBDS 149 BACKOUT 364
OLRBYTES parameter 148 OLRIMSID 149 DB 370
OLRCAP parameter 147, 270 OLRNOCAP 147, 270 GROUP 392
OLRDBDS parameter 149 OLRRGOFF 148 LOG 402
OLRIMSID parameter 149 OLRRGON 148 OLDS 409
OLRNOCAP parameter 147, 270 OLRROOTS 148 RECON status 414
OLRRGOFF parameter 148 OLRSEGS 148 SUBSYS 419
OLRRGON parameter 148 ONLINE 334 syntax
OLRROOTS parameter 148 RECOV 334 BACKOUT 363
OLRSEGS parameter 148 STOPTIME 334 DB 367
ONEJOB parameter commands PART parameter GROUP 390
GENJCL.IC 237 DELETE.PART 215 LOG 400
GENJCL.OIC 244 partition DB record (DSPDBHRC) OLDS 408
GENJCL.RECOV 253 HALDB RECON status 413
GENJCL.USER 259 TYPE=PART 69 SUBSYS 417
online commands 122 partition DBDS records (DSPDSHRC) types
Online Database Image Copy utility HALDB BACKOUT 363
(DFSUICP0) 38 types of DBDSs 69 DB 367
creating data sets for future use 39 partition record (DSPPTNRC) GROUP 390
description 35 HALDB LOG 399
execution recorded by DBRC 35 PHDAM 69 OLDS 408
generating a job 242 PDS members 5 RECON status 413
Index 585
R RECON I/O exit routine 81
RECON initialization token (RIT) 16
recovery (continued)
DBRC 33
RCVTIME parameter RECON Loss Notification 78 defining groups 276
GENJCL.RECOV 254 RECON record types 63 description 77
NOTIFY.RECOV 331 RECON status query groups 67
RCVTRACK parameter output 415 in data sharing
CHANGE.DB command 149 overview 413 planning procedures 21
CHANGE.DBDS command 158 parameters 413 without DBRC 24
READOFF parameter CHANGE.DB return codes 414 log data set
command 149 syntax 413 deleting information 212
READON parameter CHANGE.DB RECON1 parameter, BACKUP.RECON log data set, adding information to
command 149 command 133 RECON 321, 338
RECDCT parameter commands record log information 7 maintaining records 52
CHANGE.IC 163 record type parameter 89 overview 3
NOTIFY.IC 317 records period, of image copy data sets 40
NOTIFY.REORG 334 BACKOUT 66 point-in-time 11
RECON change accumulation group 66 process overview 10
allocation 55 change accumulation run 66 RECON data set 76
DSECTS 473 data sharing 72 record 72
initialization 56 database 67 time stamp 11
sample listing 473 database allocation 71 recovery control
RECON data set database data set 67 data set
accessing with DSPAPI 358 database data set group 67 commands to generate JCL and
active 62 database recovery 65 user-defined output 83
ALLOC record 71 DBDS group 67 listing 304
availability 56 DEDB 69 recovery control data set
backup 73 deleting unnecessary 73 See also RECON
changing log control records 8 global service group 70 I/O error processing 75
concurrent image copy data set 39 HALDB online reorganization 50 records 63
contention problems 56 image copy 70 replacing discarded RECON 77
creating 60 in RECON data set 63 recovery functions for DBDSs 7
data sharing record types 72 log allocation 71 recovery log data set
data-sharing records 17 log data set 64 See RLDS (recovery log data set)
Database Image Copy 2 data set 37 maintaining RECON 73 recovery log data set (RLDS)
defining 55 online reorganization 50 records 64
defining requirements in 11 RECON data set header 64 recovery period, definition of 40
description 55 recovery 72 recovery records, database 65
dynamic allocation 60 reorganization 71 recovery utilities 14
enqueue problems, causes of 117 subsystem 72 RECOVJCL parameter
extending 60 RECORDSIZE keyword commands
header records 64 DEFINE CLUSTER keywords 62 CHANGE.DBDS 158
HSSP image copy data set 42 RECOV parameter INIT.DBDS 273
initial access 62 NOTIFY.REORG 334 skeletal JCL execution member 465
LOGALL record 71 RECOVABL parameter RECOVPD parameter 40
maintaining 72 CHANGE.DB 147 INIT.DBDS 274
maintaining records 73 INIT.DB 269 RECOVPD parameter commands
overview 55 RECOVER commands 14 CHANGE.DBDS 159
preserving integrity of 78 recoverable databases INIT.DBDS 274
records, maintaining 73 CHANGE.DB command 36 RECTIME parameter commands
recovering 76 Image Copy utilities 36 CHANGE.CA 139
recovery record types 65 INIT.DB command 36 CHANGE.IC 162
registering databases 20 recovering a database CHANGE.UIC 203
REORG record 71 archiving log records 9 DELETE.ALLOC 206
reorganizing 74 batch support 22 DELETE.CA 208
replacing a discarded 77 DBRC role 12 DELETE.IC 211
replacing damaged 75 dynamic backout 22 DELETE.RECOV 216
retrieving log-related information process 12 DELETE.REORG 217
from 9 recovery facilities 22 DELETE.UIC 219
security considerations 62 setting up recovery mechanisms 21 RECVJCL parameter CHANGE.DBDS
serialization 57 without DBRC 24 command 159
shared among multiple processors 57 Recovering the RECON registering databases in the RECON data
spare 62 RECON Loss Notification 78 set 20
subsystem (SSYS) record 72 recovery RELBUF query
tracking changes to 81 CHANGE.DBDS 158 overview 423
upgrading 27 concepts 10 RELBUF request
version migration 27 database data set or area, adding parameters 423
VSAM CREATE mode 60 information to RECON 329 return codes 424
RECON data sets, both are unusable 76

RELBUF request (continued) RIT (RECON initialization token) 16 skeletal JCL (continued)
syntax 423 RLDS (recovery log data set) 171 default members explained 85
Remote Site Recovery (RSR), DBRC accumulating changes using execution members
support DFSUCUM0 43 ARCHJCL 444
See RSR commands 172 CAJCL 450
Removing an SSYS from DB CHANGE.PRILOG (for ICJCL 455
Authorization 114 RLDS) 172 ICRCVJCL 463
REORG record CHANGE.SECLOG (for LOGCLJCL 453
fields used in online RLDS) 191 OICJCL 461
reorganization 52 NOTIFY.PRILOG (for RLDS) 324 RECOVJCL 465
RECON data set 71 NOTIFY.SECLOG (for RLDS) 341 execution members explained 85
reorganization of the RECON data set deleting information from generating JCL and user-defined
adding information 332 RECON 212 output 83
deleting information 217 records 64 IBM-supplied 84, 443
reorganization record 71 selecting 98 writing your own 85, 107
reorganizing RECON, using ROLB call 22 SLDS (system log data set)
CHANGE.RECON 74 RSR 18 accumulating changes using
REORGI parameter online reorganization 52 DFSUCUM0 43
CHANGE.DB 151 RUNTIMES parameter commands adding information to RECON 326,
REPLACE parameter CHANGE.RECON CHANGE.PRILOG (for RLDS) 174 342
command 182 CHANGE.PRILOG (for SLDS) 178 CHANGE.PRILOG (for SLDS) 175
REPRO function of VSAM AMS, offline CHANGE.SECLOG (for RLDS) 194 CHANGE.SECLOG (for SLDS) 195
reorganization 75 CHANGE.SECLOG (for SLDS) 198 changing information 175, 195
requests NOTIFY.CA 312 deleting information from
DBRC Query 361 NOTIFY.IC 315 RECON 212
backout 363 NOTIFY.PRILOG (for OLDS) 318 NOTIFY.PRILOG (for SLDS) 326
database 367 NOTIFY.PRILOG (for RLDS) 322 NOTIFY.SECLOG (for SLDS) 342
group 390 NOTIFY.PRILOG (for SLDS) 326 records 64
log 399 NOTIFY.PRILOG (for TSLDS) 326 selecting 96
OLDS 408 NOTIFY.REORG 333 SLDS stop time, locating the last in
RECON status 413 NOTIFY.SECLOG (for OLDS) 336 RECON data set 108
subsystem 417 NOTIFY.SECLOG (for RLDS) 339 SMS concurrent image copy, SMSCIC
DBRC Release Buffer 423 NOTIFY.SECLOG (for SLDS) 342 parameter 235
return codes 424 NOTIFY.UIC 347 SMSCIC (SMS concurrent image
syntax 423 copy) 235
DBRC Start Request SMSCIC parameter command,
overview 427
parameters 427
S GENJCL.IC 235
space requirements, RECON data set 55
sample DBRC application program
return codes 428 specifying log retention intervals,
(DSPAPSMP) 353
syntax 427 CHANGE.RECON 185
sample listing of RECON
DBRC Stop Request SPEED keyword
Active Site 479
overview 431 DEFINE CLUSTER keywords 62
tracking site 508
parameters 431 SSID parameter commands
security, command 78
syntax 431 CHANGE.BKOUT 137
select group, skeletal JCL 88
RESERVE command, during backup 73 CHANGE.DB 150
selection criteria parameter 90
RESERVE macro 57 CHANGE.PRILOG (for OLDS) 170
serialization
RESET.GSG command 349 CHANGE.PRILOG (for SLDS) 178
of RECON data set 57
resetting the GENMAX parameter 109 CHANGE.RECON 185
strategies 58
restart in data sharing CHANGE.SECLOG (for OLDS) 190
service group
after an IMS failure 24 CHANGE.SECLOG (for SLDS) 198
changing information 200
after DBRC failure 25 CHANGE.SUBSYS 201
deleting information 217
emergency, after DBRC failure 25 DELETE.BKOUT 207
service utilities
emergency, after IMS failure 24 DELETE.LOG (for OLDS) 212
control statement parameters 89
normal 24 DELETE.SUBSYS 218
share control 7
RESTORE parameter GENJCL.ARCHIVE 223
share level, in DBRC 17
GENJCL.RECOV 254 GENJCL.CLOSE 231
SHARELVL parameter
restrictions GENJCL.USER 259
CHANGE.DB 150
concurrent image copy (CIC) 39 INIT.RECON 288
INIT.DB 280
online reorganization 54 LIST.BKOUT 291
specification descriptions 17
REUSE parameter commands LIST.LOG (for a category of
SHAREOPTIONS keyword
CHANGE.CAGRP 142 records) 304
DEFINE CLUSTER keywords 62
CHANGE.DBDS 156 LIST.LOG (for a PRILOG family) 301
sharing level, assigning one with
INIT.CAGRP 267 LIST.RECON 305
DBRC 17
INIT.DBDS 41, 273 LIST.SUBSYS 306
size calculation for SSYS record 114
REUSE parameter, image copy data sets NOTIFY.BKOUT 311
skeletal JCL 463
for future use 39 NOTIFY.PRILOG (for OLDS) 320
coding execution members 86, 103
reusing image copy data sets 41 NOTIFY.PRILOG (for RLDS) 324
data set 85
Index 587
SSID parameter commands (continued) subsystem (SSYS) record (continued) symbolic keywords (continued)
NOTIFY.PRILOG (for SLDS and initializing during IMS restart 72 JCL execution member (continued)
TSLDS) 329 size calculation 114 %OLDSDSN 95
NOTIFY.SECLOG (for OLDS) 337 working with 113 %OLDSSEL 95
NOTIFY.SECLOG (for RLDS) 341 symbolic keywords %OLDSTYP 95
NOTIFY.SECLOG (for SLDS) 344 See also symbolic keywords, JCL %PLGTIME 102
NOTIFY.SUBSYS 345 execution member %SLDETIM 96
standard form of time stamps, parameters control keywords 86 %SLDFRID 96
of DBRC commands 126 %DELETE 88, 91 %SLDFSEQ 96
START command %ENDDEL 88, 91 %SLDLRID 96
use of 17, 251 %ENDSEL 88 %SLDRMT 96
STARTDBRC request %SELECT 88, 94 %SLDSDDN 96
overview 427 %SET MEMBER 88, 92 %SLDSSEL 96
parameters 427 %SET TIMEFMT 88, 93 %SLDSTIM 96
return codes 428 description 85, 88, 103 %SLDUNIT 96
syntax 427 JCL execution member %SLDVOLS 96
STARTIME parameter commands %ALLSEL 102 %SSID 87
CHANGE.PRILOG (for RLDS) 172 %ALLTIME 102 %TIME 87
CHANGE.PRILOG (for SLDS) 176 %ALLUSID 102 symbolic keywords 86, 102
CHANGE.SECLOG (for RLDS) 191 %CADSN 101 recognized by DBRC 435
CHANGE.SECLOG (for SLDS) 196 %CAFSEQ 101 user-defined 87
DELETE.LOG (for RLDS and %CALGTM 101 symbolic keywords, JCL execution
SLDS) 213 %CAODSN 92 member
NOTIFY.ALLOC 310 %CASEL 101 substitution 83
NOTIFY.PRILOG (for OLDS) 318 %CATIME 101 symbolic keywords
NOTIFY.PRILOG (for RLDS) 322 %CAUNIT 101 %SLDCHKT 97
NOTIFY.PRILOG (for SLDS and %CAVCNT 101 syntax diagram
TSLDS) 327 %CAVOLS 101 how to read 124
NOTIFY.SECLOG (for OLDS) 336 %DALTIME 102 syntax, DBRC command 122
NOTIFY.SECLOG (for RLDS) 339 %DBADDN 103 system log data set
NOTIFY.SECLOG (for SLDS) 343 %DBADSAV 103 See SLDS (system log data set)
STARTNEW parameter %DBDDN 102, 103 system log data set (SLDS)
commands 186 %DBDSDEL 103 records 64
CHANGE.RECON 186 %DBDSN 103 system log management, with data
INIT.RECON 288 %DBDSNRV 103 sharing 47
usage 76 %DBNAME 102, 103 system logs, with data sharing 47
STARTRCV parameter commands %DBTYPE 103
CHANGE.SUBSYS 202 %DBUSID 103
NOTIFY.SUBSYS 346
STATUS parameter LIST.RECON
%DDNAME 89
%ICCAT 100
T
TAPEUNIT parameter commands
command 305 %ICDSN 99
CHANGE.RECON 186
STOPDBRC request %ICFSEQ 100
INIT.RECON 289
overview 431 %ICSEL 100
tasks of DBRC 4
parameters 431 %ICSTOP 100
time qualifier 90
syntax 431 %ICTIME 100
time stamp 126
STOPTIME 334 %ICTYPE 99
conversions and examples 130
STOPTIME parameter commands %ICUNIT 100
DBRC commands affected by
CHANGE.IC 164 %ICUSID 100
format 131
NOTIFY.CA 312 %ICVCNT 100
format for DBRC requests 358
NOTIFY.IC 317 %ICVOLS 100
recovery 11
SUBSET parameter commands %LOGDSN 98
specifying zero values 130
CHANGE.CA 140 %LOGETIM 99
standard default settings for
NOTIFY.CA 314 %LOGFRID 99
values 131
SUBSYS query %LOGFSEQ 98
standard format 126
output 421 %LOGLRID 99
overview 417 %LOGMERG 99
two-digit year input 130
parameters 418 %LOGONL 99
TIMEFMT parameter
return codes 419 %LOGRMT 99
GENJCL.ARCHIVE 223
syntax 417 %LOGSEL 99
GENJCL.CA 227
subsystem %LOGSTIM 98
GENJCL.CLOSE 231
changing information 201 %LOGUNIT 98
GENJCL.IC 238
listing 306 %LOGVOLS 98
GENJCL.OIC 245
RECON 218 %OLDCTIM 95
GENJCL.RECEIVE 249
adding information 345 %OLDFRID 95
GENJCL.RECOV 254
deleting information 218 %OLDLRID 95
GENJCL.USER 259
subsystem (SSYS) record %OLDOTIM 95
TIMEFMT parameter sublist
deleting a 113 %OLDSDDN 95
CHANGE.RECON 188

TIMEFMT parameter sublist (continued) UNIT parameter commands (continued) VOLLIST parameter commands
default settings 130 INIT.IC 279 (continued)
order of precedence of the NOTIFY.CA 314 CHANGE.SECLOG (for RLDS) 194
subparameters 129 NOTIFY.IC 317 CHANGE.SECLOG (for SLDS) 199
TIMEZIN parameter CHANGE.RECON NOTIFY.PRILOG 329 GENJCL.CA 228
command 188 NOTIFY.PRILOG (for RLDS) 324 GENJCL.IC 239
TIMEZONE parameter, NOTIFY.REORG 334 GENJCL.OIC 246
CHANGE.RECON command 187 NOTIFY.SECLOG (for RLDS) 341 INIT.CA 265
TOTIME parameter commands NOTIFY.SECLOG (for SLDS) 345 INIT.IC 279
DELETE.LOG (for RLDS and UNIT2 parameter commands NOTIFY.CA 313
SLDS) 213 CHANGE.IC 163 NOTIFY.IC 317
GENJCL.ARCHIVE 222 GENJCL.OIC 245 NOTIFY.REORG 335
LIST.HISTORY 299 INIT.IC 279 VOLLIST2 parameter commands
LIST.LOG 303 NOTIFY.IC 317 CHANGE.IC 164
TRACEOFF parameter CHANGE.RECON NOTIFY.REORG 335 GENJCL.IC 239
command 186 UOR (unit of recovery) parameter GENJCL.OIC 246
TRACEON parameter CHANGE.RECON commands INIT.IC 279
command 186 CHANGE.BKOUT 137 NOTIFY.IC 316
TRACK parameter NOTIFY.RECOV NOTIFY.BKOUT 311 NOTIFY.REORG 335
command 331 UORTIME parameter CHANGE.BKOUT VOLNUM parameter GENJCL.CA
TRACKING parameter command 137 command 228
CHANGE.DB command 151 USEAREA parameter, GENJCL.RECOV VOLSER parameter commands
CHANGE.SUBSYS command 202 command 255 NOTIFY.PRILOG (for RLDS) 324
TSLDS (tracking subsystem log data set) USEDBDS parameter, GENJCL.RECOV NOTIFY.PRILOG (for SLDS and
adding information to RECON 326 command 255 TSLDS) 329
CHANGE.PRILOG (for TSLDS) 175 USEIC parameter, GENJCL.RECOV NOTIFY.SECLOG (for RLDS) 341
CHANGE.SECLOG (for TSLDS) 195 command 255 NOTIFY.SECLOG (for SLDS) 345
changing information 175 USEOLRRG parameter, GENJCL.RECOV VSAM (Virtual Storage Access Method)
NOTIFY.PRILOG (for TSLDS) 326 command 255 create mode 60
TYPEFP parameter commands USERKEYS parameter VSAM AMS (access method services)
CHANGE.DB 150 GENJCL.ARCHIVE command 224 offline reorganization 75
INIT.DB 270 GENJCL.CA 227 restoring RECON data sets 76
LIST.DB 293 GENJCL.CLOSE 231 VSO parameter
TYPEIMS parameter commands GENJCL.IC 238 CHANGE.DBDS 159, 274
CHANGE.DB 150 GENJCL.OIC 245
INIT.DB 270 GENJCL.RECEIVE 249
LIST.DB 293 GENJCL.RECOV 255
GENJCL.USER 260
USERRCOV parameter,
U CHANGE.DB 147
using DBRC, considerations for 33
UCF (Utility Control Facility) with data
USR records, GTF (Generalized Trace
sharing 24
Facility) 187
UDATA parameter commands
utilities
CHANGE.UIC 203
Database Recovery Control
NOTIFY.UIC 347
(DSPURX00) 27
UIC, NOTIFY.UIC
DBRC (DFSURDB0) 24
updating the RECON data set 35
VSAM AMS 75, 76
UNAUTH parameter
Utility Control Facility (UCF) 24
CHANGE.DB command 151
utility control statement
restrictions 143
INIT.CA 47
using 143
INIT.CAGRP 47
UNAVAIL parameter commands
CHANGE.ADS 136
CHANGE.PRILOG (for OLDS) 170
CHANGE.SECLOG (for OLDS) 190 V
INIT.ADS 264 valid log subset, in data sharing to
UNIT parameter commands compress the size 47
CHANGE.CA 139 VALID parameter commands
CHANGE.IC 163 CHANGE.CA 139
CHANGE.PRILOG (for RLDS) 174 CHANGE.IC 163
CHANGE.PRILOG (for SLDS) 179 VALID2 parameter CHANGE.IC
CHANGE.SECLOG (for RLDS) 194 command 163
CHANGE.SECLOG (for SLDS) 199 VOLLIST parameter commands
GENJCL.CA 227 CHANGE.CA 139
GENJCL.IC 238 CHANGE.IC 164
GENJCL.OIC 245 CHANGE.PRILOG (for RLDS) 174
INIT.CA 266 CHANGE.PRILOG (for SLDS) 179
Index 589

Program Number: 5655-J38
Printed in USA
SC18-7818-03
Spine information:
IMS DBRC Guide and Reference Version 9

DFSDBRG 4

Uploaded by

Copyright:

Available Formats

DFSDBRG 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DFSDBRG 4

Uploaded by

Copyright:

Available Formats

IMS

Database Recovery Control (DBRC) Guide

Database Recovery Control (DBRC) Guide

© Copyright IBM Corp. 1974, 2007 iii

| Chapter 18. DBRC Release Buffer Bibliography . . . . . . . . . . . . 573

iv DBRC Guide and Reference

© Copyright IBM Corp. 1974, 2007 v

vi DBRC Guide and Reference

© Copyright IBM Corp. 1974, 2007 vii

Before using this book, you should understand:

How to Use This Book

© Copyright IBM Corp. 1974, 2007 ix

IBM Product Names Used in This Information

x DBRC Guide and Reference

Accessibility Features for IMS Version 9

Note: The Information Management Software for z/OS Solutions Information

About This Book xi

Related Accessibility Information

IBM and Accessibility

How to Send Your Comments

xii DBRC Guide and Reference

Changes to This Book for IMS Version 9

© Copyright IBM Corp. 1974, 2007 xiii

Library Changes for IMS Version 9

The IMS Version 9 information is now available in the Information Management

New and Revised Titles

xiv DBRC Guide and Reference

© Copyright IBM Corp. 1974, 2007 1

Chapter 6. Hints and Tips for DBRC . . . . . 107

2 DBRC Guide and Reference

© Copyright IBM Corp. 1974, 2007 3

RECON Data Set

Database Recovery Control Utility (DSPURX00)

v List the information in the RECON data set

When Should You Use DBRC?

Chapter 1. Overview of DBRC 5

| Communicating with DBRC

| The following is a list of the DBRC batch commands:

| DBRC API Requests

| The following is a list of the DBRC API requests:

6 DBRC Guide and Reference

Recording and Controlling Log Information

The IMS logs consist of the:

Figure 1. Logs Produced for Recovery and Restart

Chapter 1. Overview of DBRC 7

DBRC also provides unit-of-recovery management for all attached subsystems.

Attention: If registered databases are updated without DBRC control, DBRC

Changing Log Records in the RECON Data Set

8 DBRC Guide and Reference

Related Reading: See Member DFSVSMxx in the IMS Version 9: Installation

Recommendation: Whether you use automatic archiving or invoke archiving

DBRC Log-Related Commands

Chapter 1. Overview of DBRC 9

Related Reading: See the command chapters in Part 2, “DBRC Command

The Basic Steps of Database Recovery

Figure 2. IMS Database Recovery process

10 DBRC Guide and Reference

v Database reorganization data sets

DBRC also records information about: