Reliant for VSE CSI-RECOV

Transcription

1 Reliant for VSE CSI-RECOV CICS VSAM RECOVERY INSTALLATION AND OPERATIONS GUIDE Release 4.0 (COPYRIGHT 2003, CSI INTERNATIONAL, INC.) CSI-RECOV is a proprietary product of CSI International, Inc. It cannot be reproduced, changed, copied, or stored in any form (including, but not limited to, copies on magnetic media) without the express prior written.

2 Original Printing...04/01/2003 Last Revised...04/01/2003

3 TABLE OF CONTENTS GETTING STARTED...1 Preface...3 How Should I Use This Manual?...3 Disclaimer...3 Introduction...5 What is Recovery?...7 What Part is provided by CICS?...7 What Part is provided by CSI-JOURNAL?...7 What Part is provided by CSI-RECOV?...7 What Part is provided by CSI-ARMAN?...7 What Part is provided by DL/I?...8 Will the Process work when I need it?...8 Features of CSI-RECOV...9 Terminology...11 Migration Requirements...13 Installation...16 Customizing CSI-RECOV...19 CSIRECDJ (Default CICS Journal I/O module)...20 CSIRECDB (Default Journal Backup I/O module)...21 CSIRECDD (Default DL/I Log I/O module)...22 Generating a Custom I/O Module...23 PREPARING CICS FOR RECOVERY...27 Overview of CICS Journaling...29 Journal Functions of CICS...30 Journal File Alternatives...30 One Journal Dataset vs Two...31 Disk vs Tape Journals...32 One Journal vs Many...33 CICS Journal Recommendations...34 Installing Journaling in your System...36 Defining your Journal Control Table (JCT)...36 Initializing your Journal File for CICS...40 Activating Automatic Journaling (CICS FCT)...42 Add Journal Support to the CICS PCT, PPT and SIT Tables...43 Add Journal File JCL to your CICS Startup Jobstream...44 Writing an EOF Mark on Tape Journals...46 USING CSI-RECOV...47 Considerations...49 Accumulating Journal Data...49 A Typical Failure/Recovery Cycle...50 Recovery with Non-journaled Batch Updates...51 VSAM Share Option Coordination of Data File Backups and Journal Files...52 VSAM Recovery Scenario (Manual)...53 VSAM Recovery Scenario (Using CSI-ARMAN)...54 DL/I Recovery Scenario...55

4 TABLE OF CONTENTS Journal Backup JCL Recovery JCL Commands and Operands Syntax Commands INPUT Command OUTPUT Command SELECT Command SORTOPTION Command ATTRIBUTE Command AUTO Command Reports generated by CSIRECOV Parameter Edit Report Output Print Report Summary Reports VSAM Output Error Report VERIFICATION SYSTEM System Components Compiling the Verification Programs Modifying CICS Tables for Verification Testing Modifying CICS Startup JCL Modifying Verification JCL Run Jobstream CSIRECV Run On-line Verification Program Run Jobstream CSIRECV Problem Determination for Verification System MESSAGES APPENDIX A How To Code Commands (Syntax) APPENDIX B Journal Backup Record Formats

5 GETTING STARTED Page 1

6

7 Preface This manual is written to help you install, verify, and implement CSI-RECOV, the CICS VSAM Recovery System from CSI International, Inc. How Should I Use This Manual? If you already have CICS Journaling installed you can skip the section "Preparing CICS for Recovery". However, we feel that it would be to your advantage to quickly review this section. If you are now using a previous release of CSI-RECOV, please refer to the section "Migration Requirements". To implement the enhancements provided in this release, you may need to change some of your existing JCL. Once CICS journaling has been installed you may install and customize CSI- RECOV. This is covered in the section "Installation". Once CICS journaling and CSI-RECOV have been installed, we strongly suggest that you verify the entire process, as explained in the section "Verification and Testing". Then prepare a recovery Jobstream as outlined in the section "Using CSI- RECOV" so that you will be prepared for recovery of one or more files when necessary. Disclaimer The techniques and procedures outlined in this manual have been thoroughly tested on our development site. However, you should check all procedures in depth and modify them as needed for your own installation. Preface Page 3

8

9 Introduction CSI-RECOV is a system designed to recover VSAM files updated by CICS/VS or batch applications, if VSAM changes are journaled. Journal files created by CICS/VS (SMF or standard format) or CSI-JOURNAL, the VSAM Batch Journaling system from CSI International, Inc. can be used as input to CSI- RECOV. This system can be used to recreate a file's condition prior to a disk failure, head crash or file deletion, using a file backup and the appropriate journals. CSI-RECOV can also be used to manage DL/I journal records. DL/I journal records from your CICS System Journal and batch DL/I journal logs from batch DL/I programs can be combined with VSAM journal records and maintained on a single journal backup file until such time as a DL/I recovery or "changeaccum" process is required. CSI-RECOV can then generate a single DL/I log dataset that can be input to your standard DL/I utilities. CICS JOURNALS JOURNAL BACKUPS JOURNAL BACKUPS JOURNAL REPORTS CSI-RECOV BATCH JOURNALS VSAM DATASETS DL/I LOGS DL/I LOGS Overview of CSI-RECOV Introduction Page 5

10 These are the benefits that you get from using CSI-RECOV: You do not have to code custom recovery routines. CSI-RECOV will recreate any VSAM file, provided that a current backup and journal are available. Users will not have to re-enter data after a failure. One or more VSAM files can be recovered at the same time. Complete reporting ensures accuracy and verification. CSI-RECOV can be used in conjunction with CSI-ARMAN, the Automated Recovery Manager from CSI International, Inc. to provide integrated control of your VSAM Backup and Recovery processing. The application programmers need not include specialized "change-log" logic in their CICS/VS programs if the IBM-supplied automatic journaling feature of CICS is used. This feature, along with CSI-RECOV, is all that is needed to provide VSAM file recovery. If you have both VSAM and DL/I datasets, you can backup and manage all journal records for both your VSAM and DL/I datasets in a single CSI- RECOV Journal Backup dataset. In summary, CSI-RECOV can save your company time and money when a VSAM dataset is lost or damaged. Recovery can be a manageable process, when it is planned for, and CSI-RECOV makes the process easy. Page 6 Introduction

11 What is Recovery? Recovery is a process that restores a damaged file to the state it was in prior to the point of damage. Damage may be caused by hardware or software failure, or by human error, and the extent of the file damage can vary from a single record in one file to many files in several systems. Accordingly, the recovery process could be different each time a failure occurs. What Part is provided by CICS? CICS provides the facility to record file change data in separate datasets called journals. The section "Preparing CICS for Recovery" will give you detailed instructions on how to prepare your CICS system for this facility. A companion product, CSI-JMASTER, from CSI International, Inc. can be used to provide automatic backup, and overwrite protection for your CICS journals. What Part is provided by CSI-JOURNAL? CSI-JOURNAL provides a batch journaling facility that is analogous to CICS journaling. It allows you to recover the VSAM updates made in a batch environment without re-running the batch jobs. Refer to the CSI-JOURNAL Installation and Operations Guide for more information. What Part is provided by CSI-RECOV? CICS will not use these journal records to re-apply changes when a file has been destroyed. This is where CSI-RECOV comes in. After you have restored the VSAM file (or files) from the latest backup tape, CSI-RECOV will re-apply changes made since the latest backup. What Part is provided by CSI-ARMAN? CSI-ARMAN maintains a "Recovery Control File", containing all of the information necessary to generate the jobstreams required to perform the following: Introduction Page 7

12 VSAM backups CICS journal backups Journal accumulations VSAM Recoveries The companion products; CSI-RECOV, CSI-JOURNAL, and CSI-JMASTER communicate with CSI-ARMAN, providing the the necessary information to the Recovery Control File, to enable the required jobstreams to be generated. Together, these four products provide an integrated, and automated VSAM Recovery System. What Part is provided by DL/I? CSI-RECOV can be used to backup and managed journal records generated by DL/I, however, CSI-RECOV does not perform the actual recovery of your DL/I datasets. You still use the standard DL/I recovery utilities. When a DL/I recovery is required, you use CSI-RECOV to extract the required DL/I journal records from your CSI-RECOV Journal Backup dataset to a separate DL/I log dataset that can be used by your DL/I recovery and/or "change-accum" utilities. Will the Process work when I need it? After you have installed CSI-RECOV it may be a long time before you need to use it, if ever, and you may therefore not get around to testing CSI-RECOV or the CICS journaling process. To help you verify that the entire recovery process will work, we have provided you with software and procedures that will ensure the correct execution of all the steps involved in this recovery process: the CICS journaling, your backup and restore system, and the CSI-RECOV software. This verification process should be run after you have installed CSI-RECOV, and whenever a new release of CICS is installed. The section "Verification and Testing" describes this process in detail. Page 8 Introduction

13 Features of CSI-RECOV Single program execution for all CSI-RECOV functions. Any number of CICS journals or journal backups can be input to CSI- RECOV. Sorting requirements can be specified for any combination of inputs. The sort is invoked from within CSI-RECOV reducing I/O to journal files. Any or all input journal records can be printed, written to journal backup file(s) or used to recover VSAM datasets during a single execution of CSI- RECOV. CSI-RECOV provides comprehensive journal management support, including: printing, copying, merging, and automatic aging/purging of journal records. Multiple journal records for the same VSAM key are logically combined during recovery to reduce I/O to your VSAM datasets. CICS journals can be in standard or SMF format. If SMF format is used, the CICS release and APPLID will automatically be extracted by CSI-RECOV. Backward or 'BACKOUT' recovery can be specified to replace the 'before' images on your VSAM datasets. A 'NOUPDATE' mode can be used to simulate a recovery without actually updating your VSAM datasets. Forward, Backout and Noupdate recovery can all be performed against different VSAM datasets during a single execution. All types of VSAM datasets can be processed, KSDS, RRDS, ESDS, including Empty files. Complete selection control over which journal records will be processed. CSI-RECOV can be used in conjunction with CSI-ARMAN, the Automated Recovery Manager from CSI International, Inc. to provide integrated control of your VSAM Backup and Recovery processing. Introduction Page 9

14 Journal records generated by DL/I can be backed up and managed by CSI- RECOV. When a DL/I recovery or "change-accum" is required, a DL/I log dataset can be generated by CSI-RECOV to be used by your standard DL/I recovery utilities. Batch DL/I logs can be standard sequential, VSAMmanaged-SAM, or VSAM ESDS datasets. CSI-RECOV provides extensive statistical and error reporting for all of its Journal Management and VSAM Recovery functions. CSI-RECOV can generate a "reduced" Journal Backup format containing only the data changed in the "before" and "after" image journal records. This feature is intended to improve journal transmission efficiency for off-site archiving or simply to save disk space. A complete verification system is supplied with CSI-RECOV to test your CICS journaling installation and VSAM file Backup/Restore processing. It will give you the confidence that recovery WILL work when it is needed. Step by step instructions are provided in the CSI-RECOV documentation to assist you in adding journaling support to your CICS systems. Page 10 Introduction

15 Terminology The following terms are used throughout this documentation to define specific items or processes. CICS Journal Any Journal dataset created by CICS in either standard or SMF format. This can also be a copied image of a CICS Journal dataset as long as its format is the same as that created by CICS. These datasets are input to CSI- RECOV via an INPUT JOURNAL Command. Batch Journal A Journal dataset created by CSI-JOURNAL. These datasets have the same format as OUTPUT BACKUP files created by CSI-RECOV. Therefore, Batch Journals are input to CSI-RECOV via an INPUT BACKUP Command. DL/I Log Any dataset created by CSI-RECOV by the use of an OUTPUT DLILOG Command, or by a batch DL/I program. This does not have the same format as a CICS Journal dataset, and can only be used as input to CSI- RECOV via an INPUT DLILOG Command. A DL/I Log generated by CSI-RECOV can be used as input to any of your standard DL/I recovery utilities. Journal Backup Any dataset created by CSI-RECOV by the use of an OUTPUT BACKUP Command. This does not have the same format as a CICS Journal dataset, and can only be used as input via an INPUT BACKUP Command. Forward Recovery The process of updating one or more VSAM datasets with the 'after' images created by CICS automatic journaling. The purpose of Forward Recovery is to return a VSAM file to the state is was in prior to a Disk loss. Introduction Page 11

16 Backout Recovery The process of updating one or more VSAM datasets with the 'before' images created by CICS automatic journaling. The purpose of Backout Recovery is to return a VSAM file to the state is was in prior to the updating performed by one or more CICS transactions. This process is NOT the same as CICS dynamic transaction backout. This process will NOT automatically determine 'inflight' transactions. Page 12 Introduction

17 Migration Requirements This section describes the changes you need to consider if you are migrating from an earlier release of CSI-RECOV. The changes are grouped by release level. You will not need to consider the changes for releases older than the one you are currently using. You will need to consider changes for all releases since the release you are currently using. Changes from Release 3.0 The load module names have been changed to a CSI prefix. Changes from Release 2.6 The INPUT JOURNAL Command default for the CICS release has been changed from 1.6 to 1.7. This new default will work correctly for all releases of CICS from 1.7 and above. If you are using CICS release 1.6 or below, you must change you INPUT JOURNAL Commands to include the 1.6 Operand. CSI-RECOV contains an integrated interface to CSI-ARMAN, the Automated Recovery Manager from CSI International, Inc. to provide integrated control of your VSAM Backup and Recovery processing. A new Command, AUTO has been added. This is used to activate the interface to CSI-ARMAN. New Operands have also been added to the INPUT and OUTPUT Commands to support this new interface. New Operands have been added to the SORTOPTION Command to specify the desired sorting sequence. These new Operands can be used for DL/I recovery, and for VSAM recovery that includes updates through a path or an alternate index. Migration Requirements Page 13

18 Changes from Release 2.5 CSI-RECOV can now generate a "reduced" format of the OUTPUT BACKUP dataset. The "reduced" record format contains only those bytes of data that were different between the "before" and "after" image journal record. This feature can provide as much as a 30% space reduction. During recovery, CSI- RECOV automatically detects whether you are using "full" or "reduced" formats and proceeds accordingly. Refer to the FORMAT Operand of the OUTPUT BACKUP Command for more information. CSI-RECOV can now support VSAM ESDS DL/I log files. A new Operand, ESDS has been added to the INPUT DLILOG Command. You must specify ESDS for each DL/I log that is VSAM ESDS. This Operand is required because CSI-RECOV cannot distinguish between VSAM ESDS and VSAMmanaged-SAM datasets. A new SELECT Operand, DATETIME has been added to simplify the specification of starting and/or ending ranges that involve both a Date and a Time. Changes from Release 2.4 The format of the Journal Backup dataset created using an OUTPUT BACKUP Command has changed. CSI-RECOV will accept Journal Backup datasets from all earlier releases, however, Journal Backups created by this release of CSI-RECOV cannot be read by earlier releases. CSI-RECOV can now manage DL/I journal records. If you are using CSI- RECOV to backup VSAM journal records from a CICS System Journal that also contains DL/I journal records, you may need to review your SELECT Commands to make sure that only the records you want are backed up by CSI-RECOV. CSI-RECOV will automatically read and select all VSAM and DL/I journal records found on a CICS System Journal unless specifically excluded via a SELECT or EXCLUDE Command or Operand. Refer to section "Commands and Operands" for more information. Two new Commands have been added to support DL/I Journal management. The INPUT DLILOG Command can be used to read DL/I logs created by batch DL/I programs. The OUTPUT DLILOG Command can be used to create a DL/I log for use by any of DL/I's standard recovery utilities. Page 14 Migration Requirements

19 A new Operand (WRAP) has been added to the INPUT JOURNAL Command. This new Operand specifies whether or not CSI-RECOV should extract journal records from beyond the "wrap-point" of a CICS Journal. The default is to not extract journal records from beyond the "wrap-point". If you have CICS Journals that can wrap, and you need CSI-RECOV to extract all journal records from those journals, you must specify the WRAP Operand. The default for Operand (MAXKEY) of the SORTOPTION Command has been changed from 234 to 232. Refer to the SORTOPTION Command to determine if you need to specify this Operand. Migration Requirements Page 15

20 Installation The CSI-RECOV programs described in this manual run under VSE, and are distributed on a 1600 BPI tape. When this tape is loaded into your Reader Queue, there will be one POWER job which will catalog the following modules to your libraries: Source Library Modules: E.CSIIOGEN A.CSIRECDB A.CSIRECDD A.CSIRECDJ C.CSIRECVI C.CSIRECVU C.CSIRECVC A.CSIRECV0 A.CSIRECV1 A.CSIRECV2 A.CSIRECV3 A.CSIRECJ1 I/O Module Customization Macro Backup I/O Module Sample Macro Call DLILOG I/O Module Sample Macro Call Journal I/O Module Sample Macro Call Verification Program Source to Initialize Files Verification Program Source to Update Files Verification Program Source to Check Files Verification CICS FCT Entries Verification CICS JCT Entries Verification JCL to Create Files Verification JCL to Recover Files Prototype Recovery JCL Note: In a VSE-SP library, these members are named member.sublib (eg. CSIIOGEN.E). Core Image Library: CSIRECOV CSIRECDB CSIRECDD CSIRECDJ CSIRECVI CSIRECVU CSIRECVC Forward Recovery Module Default Backup I/O Access Module Default DLILOG I/O Access Module Default Journal I/O Access Module Verification Program to Initialize Files Verification Program to Update Files Verification Program to Check Files Page 16 Installation

21 Minimum library space required: Source Statement Library: FBA Blocks = 380 LIBR Blocks = 190 Core Image Library: FBA Blocks = 560 LIBR Blocks = 280 Installation Step 1 Mount the distribution tape on a tape drive and enter the following POWER Command on the console: S RDR,cuu (cuu = tape drive address) This will load the POWER job CSIRECOV into your Reader Queue. Installation Step 2 Alter the POWER job (CSIRECOV) that was loaded in the reader queue to run in a partition that has labels established for linkediting. This job has a pause statement that allows you to enter a "LIBDEF" statement if necessary. A RDR,CSIRECOV,DISP=D,CLASS=? Installation Step 3 When job CSIRECOV starts up, it will pause allowing you to enter "// LIBDEF" statements. You must enter a "// LIBDEF" statement with the "TO=" option for a core image and source statement libraries unless they have already been set using permanent LIBDEFs. Installation Page 17

22 The following LIBDEF prompts are displayed on the System console: * <<<< FOR VSE 1.3.X USE THE FOLLOWING LIBDEFS >>>> * // LIBDEF CL,TO=USRCL? * // LIBDEF SL,TO=USRSL? * * <<<< FOR VSE 2.1.X USE THE FOLLOWING LIBDEF >>>> * // LIBDEF *,CATALOG=LIB?.SUBLIB?,SEARCH=LIB?.SUBLIB? * * RE-ENTER LIB?.SUBLIB? IN RESPONSE TO VSE MESSAGES * L032I LIBDEF MISSING FOR TO LIBRARY... * L146I ENTER THE LIBRARY.SUBLIBRARY... // PAUSE ENTER ABOVE LIBDEFS AS REQUIRED When the installation job is complete, review the printed output for errors. Common problems that may occur during the installation job are: One of the libraries has filled up and requires condensing. A LIBDEF statement was omitted or improperly declared. Install job was run in a partition not set up for Link Editing. Installation Step 4 Review the section "Customizing CSI-RECOV" to determine if the object modules cataloged in the Core Image Library in step 3 are suitable for your environment. If they are not, make the necessary changes. Installation Step 5 Verify the entire Journaling and Recovery process, as described in the section "Verification and Testing". Page 18 Installation

23 Customizing CSI-RECOV CSI-RECOV uses customizable I/O modules to access CICS journals, to read and write Journal Backup files and to read and write DL/I log files. Default I/O modules have been provided in both source and object form. Customization of these modules may be required to change Device types, Blocksizes, or other options defined below. Macro CSIIOGEN has been provided to customize the Default I/O modules or to generate additional I/O modules to be used for varying the formats of Journals and Journal backups created by CSI-RECOV. If you are generating your own I/O modules for multiple formats of journals or journal backups, the names used for your I/O modules should NOT begin with the letters CSI. If they do, CSI- RECOV may mistake your module name for one if its internal modules and error message CSIRECOV-13 or CSIRECOV-23 will result. Customization Page 19

24 CSIRECDJ (Default CICS Journal I/O module) Module CSIRECDJ is the default I/O module used by CSI-RECOV to access CICS journal files. The MODNAME Operand of the INPUT Command can be used to provide the name of a different I/O module. The default I/O module provided on the installation tape may not be suitable for your system. For example, the block size may be too large for the type of DASD you have, or your CICS journals may be on tape. To change the default I/O module, generate a custom module and catalog it as CSIRECDJ. Listed below are the Operands that were used to generate module CSIRECDJ: CSIIOGEN, X OPSYS=VSE, X BLKSIZE=32767, X IOAREAS=YES, X DEVICE=DISK, X SYSNBRI=SYS004, X LABEL=NO, X REWINDI=UNLOAD This macro call and its associated JCL are supplied in member A.CSIRECDJ. You may move this member to your text editor or code it manually as shown in the example later on. If you use the prototype in A.CSIRECDJ, be sure to change the default values as required for your system. Page 20 Customization

25 CSIRECDB (Default Journal Backup I/O module) Module CSIRECDB is the default I/O module used by CSI-RECOV to create and access journal backup files. The MODNAME Operand of the INPUT and OUTPUT Commands can be used to provide the names of different I/O modules. The default I/O module provided on the installation tape may not be suitable for your system. For example, the block size may be too large for the type of DASD you have, or you may decide to write your Journal Backup files to disk. To change the default I/O module, generate a custom module and catalog it as CSIRECDB Listed below are the Operands that were used to generate module CSIRECDB: CSIIOGEN, X OPSYS=VSE, X BLKSIZE=32767, X IOAREAS=YES, X DEVICE=TAPE, X SYSNBRI=SYS004, X SYSNBRO=SYS005, X LABEL=STD, X REWINDI=UNLOAD, X REWINDO=UNLOAD This macro call and its associated JCL are supplied in member A.CSIRECDB. You may move this member to your text editor or code it manually as shown in the example later on. If you use the prototype in A.CSIRECDB, be sure to change the default values as required for your system. Customization Page 21

26 CSIRECDD (Default DL/I Log I/O module) Module CSIRECDD is the default I/O module used by CSI-RECOV to create and access DL/I log files. The MODNAME Operand of the INPUT DLILOG Command can be used to provide the name of a different I/O module. This module is not required for VSAM ESDS DL/I log files. The default I/O module provided on the installation tape may not be suitable for your system. For example, the block size may be too large for the type of DASD you have, or you may decide to write your DL/I log files to disk. To change the default I/O module, generate a custom module and catalog it as CSIRECDD Listed below are the Operands that were used to generate module CSIRECDD: CSIIOGEN, X OPSYS=VSE, X BLKSIZE=32767, X IOAREAS=YES, X DEVICE=TAPE, X SYSNBRI=SYS004, X SYSNBRO=SYS005, X LABEL=STD, X REWINDI=UNLOAD, X REWINDO=UNLOAD This macro call and its associated JCL are supplied in member A.CSIRECDD. You may move this member to your text editor or code it manually as shown in the example later on. If you use the prototype in A.CSIRECDD, be sure to change the default values as required for your system. Page 22 Customization

27 Generating a Custom I/O Module To generate an I/O module, use the CSIIOGEN macro described below. An example of a job to generate and catalog an I/O module is shown at the end of this section. The following pages provide a detailed explanation of the CSIIOGEN macro and its Operands. How to enter CSIIOGEN, X OPSYS=VSE, X BLKSIZE=32767 nnnnn, X IOAREAS=NO YES, X DEVICE=DISK TAPE, X SYSNBRI=SYS004 SYSnnn, X SYSNBRO=SYS005 SYSnnn, X LABEL=NO STD, X REWINDI=UNLOAD REWIND NORWD, X REWINDO=UNLOAD REWIND NORWD NOTE: If you use a Disk/Tape Management System, you may be able to specify some of the CSIIOGEN options via the Management System's JCL. Customization Page 23

28 Explanation: OPSYS=VSE Must be set to the Operating System in use (in this case VSE). BLKSIZE=32767 nnnnn Maximum Blocksize of the dataset. This can be any value up to the track capacity of your device, (if CKD). The maximum that can be specified for any device type is For CICS journals, this field must contain the largest "BUFSIZE" value specified in the CICS JCT for the journal(s) to be processed by this I/O module. CSI- RECOV creates its journal backup datasets in VBS format (variable blocked spanned) which allows logical records to span multiple blocks. The record format in the DTF is "undefined", and CSI-RECOV does its own blocking. IOAREAS=NO YES Specifies whether or not to generate internal I/O areas. For VSE or later, specify "NO" for DISK and "YES" for TAPE. Prior to VSE 1.3.5, specify "YES" for both DISK and TAPE devices. If you are using the MVT Operating System from Software Persuits, specify "YES" for both DISK and TAPE devices. DEVICE=DISK TAPE Specifies the type of device containing the journal file. SYSNBRI=SYS004 SYSnnn For tape datasets. This is the SYSnnn to be used for accessing the tape drive during Input operations. This value can be overridden by the INPUT Command. Page 24 Customization

29 SYSNBRO=SYS005 SYSnnn For tape datasets. This is the SYSnnn to be used for accessing the tape drive during Output operations. This value can be overridden by the OUTPUT Command. LABEL=NO STD For tape datasets. This option defines whether or not the tape is labeled (specify STD for standard labeled tapes and NO for unlabeled tapes). REWINDI=UNLOAD REWIND NORWD For tape datasets. This option defines the action to occur when the tape is closed after Input operations. UNLOAD will rewind and unload the tape. REWIND will rewind the tape without unloading it. NORWD will leave the tape positioned as is. REWINDO=UNLOAD REWIND NORWD For tape datasets. This option defines the action to occur when the tape is closed after Output operations. UNLOAD will rewind and unload the tape. REWIND will rewind the tape without unloading it. NORWD will leave the tape positioned as is. Customization Page 25

30 EXAMPLE: The following example can be used to customize CSIRECDJ for VSE: // JOB jobname // OPTION CATAL PHASE CSIRECDJ,* // EXEC ASSEMBLY CSIRECDJ CSIIOGEN, OPSYS=VSE, DEVICE=TAPE, BLKSIZE=32767 END /* // EXEC LNKEDT /& X X X A complete macro prototype is provided in member A.CSIRECDJ. Page 26 Customization

31 PREPARING CICS FOR RECOVERY Page 27

32

33 Overview of CICS Journaling The points covered in this section are: Journaling Description and Considerations CICS Journal Recommendations Installing Journaling in your System The information in this section has been summarized from the following manuals. You may want to refer to these manuals for further information. CICS Resource Definition Guide - Journal Control Table CICS Resource Definition Guide - File Control Table CICS Resource Definition Guide - System Initialization Table CICS Installation and Operations Guide - Journal Data Sets CICS Performance Guide - Logging and Journaling. Note: The information presented in the following pages deal mostly with Disk Journals. If you choose to use Tape Journals, please refer to the IBM Manuals listed above. Preparing CICS for Recovery Page 29

34 Journal Functions of CICS CICS provides three types of Journaling functions: 1. Automatic Logging 2. Automatic Journaling 3. User Journaling Automatic Logging means logging done to the System Log, Journal ID is "01". This logging is for the Emergency Restart processing performed by CICS after a system abend. The log records, generated by Automatic Logging, are not used for Forward Recovery processing. Automatic Logging is specified via the "LOG" Operand of the CICS FCT. Automatic Journaling is a function of CICS File Control that creates "Before and/or After Images" of all records added, updated, or deleted. These journal records are written to any CICS Journal Although the System Log (journal 01) can be used for Automatic Journaling, we recommend that a separate journal be used (02-99). The following sections will explain why. The records created by Automatic Journaling are the input to CSI-RECOV processing. Automatic Journaling is specified via the "JREQ" and "JID" Operands of the CICS FCT. User Journaling refers to journal records formatted, written, and used by application programs. User journal records are not used by CSI-RECOV, although they may be written to the same CICS journal as the Automatic Journaling records if desired. Journal File Alternatives CICS provides a few basic alternatives when defining journal files, to allow you to tailor individual journals according to their use. Page 30 Preparing CICS for Recovery

35 One Journal Dataset vs Two Each logical journal file (01-99) can be defined as having either one or two journal datasets, each referenced with a unique Dataset Name. A journal dataset must consist of a single extent, and may not be defined as a VSAM Managed SAM data set. With One Journal Dataset - If the journal becomes full, CICS will start over at the beginning, overwriting the data at the beginning of the journal. For the System Log, this is not a problem as long as the journal is large enough to contain all records required to recover from an abend of the longest running task that updates "protected resources". For journals required for Forward Recovery, this overwriting may not be a problem either, as long as the journal is large enough to contain all file updates since the previous backup of your dataset. Since the Forward Recovery Process normally involves a larger number of records, the option for two journal datasets is usually a better choice. You must specify the WRAP Operand on all INPUT JOURNAL Commands that are accessing CICS Journals that may have wrapped. If you do not specify the WRAP Operand, CSI-RECOV will stop reading the CICS Journal when the "wrap-point" is reached. Note: For journals on FBA devices, using a single journal dataset is not an option, because an end-of-file record is always written after each block of journal records, making the remainder of the file inaccessible. With Two Journal Datasets - When one journal dataset becomes full, CICS will switch to the beginning of the other dataset. This gives you the opportunity to backup the first dataset prior to the second dataset becoming full. When the second dataset becomes full, CICS will switch back to the first dataset. For Forward Recovery Journals, we recommend you define two journal datasets with the first dataset large enough to hold 1.5 times the number of updates created between dataset backups, with a second smaller dataset as a "Safety Net". This second dataset should be large enough to allow CICS to continue functioning without filling the dataset while the first dataset is being backed up and initialized. After CICS switches back to the first dataset, backup and initialize the second dataset. The first dataset should be maintained at a size that requires the second dataset to be rarely used. Preparing CICS for Recovery Page 31

36 Disk vs Tape Journals The first decision you will need to make is whether to use disk or tape journals. The following points should be considered: The System Log (Journal 01) is used for CICS Emergency Restart. This means that when CICS restarts after an abend, the log is read backwards to find all changes made by the tasks that were in-flight. The relatively slow speed of tape processing would thus delay the availability of CICS after a system abend. Tape is infinitely large. The journal can extend from volume to volume without overwriting any data. If you are expecting large amounts of journaled updates and have a limited amount of disk space, this may be important. A "one-dataset" tape journal implies a single drive, not a single volume. However, when a volume is filled, CICS update activity is suspended while the tape rewinds so that another volume can be mounted. You should never use a single tape journal if all your updates cannot fit on a single tape volume. A "two-dataset" tape journal implies that two tape drives are dedicated to the journal. When the first volume becomes full, CICS switches to the second drive and rewinds/unloads the first so that a new volume can be mounted. This is more efficient than the one-dataset tape, but requires two tape drives. Reliability of the device or media is also an important consideration. Tapes are not always as reliable as disks. Space utilization characteristics of some disk drives make them not very suitable for journals. A system log with its typically short blocks can require almost twice the disk space on a 3380 disk drive as it would on a 3350 disk drive. This is because a 3380 has a large overhead associated with each physical block that makes it very wasteful for small block sizes. Page 32 Preparing CICS for Recovery

37 One Journal vs Many CICS Emergency Restart requires the definition of a system log (Journal ID 01). The system log can also be used for journaling, but the following points should be considered: If journaling is combined with logging, Emergency Restart times can be increased due to the journal records that must be skipped to find the log records. Forward Recovery Journals are easier to keep in sync with dataset backups if they are reinitialized each time a backup is done. If system logs are initialized, CICS WARM STARTS and EMERGENCY RESTARTS cannot be performed. Preparing CICS for Recovery Page 33

38 CICS Journal Recommendations The following recommendations are based on the assumption that you will be using Automatic Logging for CICS Emergency Restart, and Automatic Journaling for forward recovery. They are also based on experience with many different systems, and will suit the requirements of most installations. Special situations (such as extremely high transaction rates) may require different techniques. These recommendations are intended to be used as a starting point, to be fine tuned as needed. The System Log If you are not using DL/I, we recommend defining a single dataset for the System Log. This should be initialized when first defined and then never reinitialized unless it is being moved or changed in size. This provides the most stable environment for CICS Warm Starts and Emergency Restarts. If you are using DL/I, refer to the CICS Installation and Operations Guide for instructions for creating and initializing the appropriate journaling environment for DL/I. Separate Journals for Forward Recovery The journal(s) used for Automatic Journaling should be separate from the system log. If you are using a disk, you should have two journal datasets (JTYPE=DISK2), with the first dataset large enough to hold 1.5 times the number of updates created between dataset backups. The second dataset can be smaller, and is a "safety net" to allow the primary dataset to be backed up and initialized if it becomes full. A Tape Journal Can be OK For Forward Recovery Journals Under The Following Conditions: All journaled activity can be contained on a single volume, or two drives can be allocated to the journal to allow switching to occur without causing performance problems. Page 34 Preparing CICS for Recovery

39 Placement of Journal Datasets: Since recovery may be required due to a DASD failure, we recommend that the journal datasets and the VSAM files reside on two different physical devices. VSAM DATASETS VSAM DATASETS JOURNALS JOURNALS If all of your disk devices have VSAM files requiring journaling, you must have multiple journal datasets to ensure that a VSAM file can be recovered after a DASD failure. Preparing CICS for Recovery Page 35

40 Installing Journaling in your System The steps covered in this section are the following: 1. Defining your Journal Control Table (JCT) 2. Initializing your Journal File for CICS 3. Activating Automatic Journaling (CICS FCT) 4. Adding Journal Support to the CICS PCT, PPT and SIT Tables 5. Adding Journal File JCL to your CICS startup Jobstream 6. Writing EOF Mark on Tape Journals Defining your Journal Control Table (JCT) The CICS Journal Control Table (JCT) is the means by which you describe the physical journal files and their characteristics to CICS. The JCT is defined with three macro types: DFHJCT TYPE=INITIAL First Section of Table DFHJCT TYPE=ENTRY Occurs once for each journal file DFHJCT TYPE=FINAL Last Section of Table DFHJCT TYPE=INITIAL,SUFFIX=xx: Defines this table to CICS. The Value "xx" is specified in the System Initialization Table (SIT) on the "JCT=xx" Keyword. This allows multiple JCTs to exist on the same Load Library. Page 36 Preparing CICS for Recovery

41 DFHJCT TYPE=ENTRY: Defines each logical journal file to CICS. JFILEID=NN Gives a unique "ID" to each journal (02-99). JFILEID=SYSTEM is specified for Journal 01. This "ID" is used in the File Control Table (FCT) to designate which files should be logged to which journal. This "ID" is also used by CICS to form the DLBL for the JCL. JTYPE=DISK2 Defines type of Journal: - DISK or TAPE - ONE FILE or TWO FILES (for example: DISK1, DISK2, TAPE1, TAPE2) If only one disk file is used, CICS will wrap the file when full, overwriting the old journal records. However, for journals on FBA devices, using one disk file only is not an option, because an end-of-file record is always written after each journal record. If two disk files are used, CICS will flip/flop between them allowing your operators time to backup one file while the other is being used by CICS. Preparing CICS for Recovery Page 37

42 BUFSIZE=4089 Defines the largest block that can be written to this journal. This size must be determined by you, using the following criteria: (The minimum you can specify is): 80 + Largest Record Key + Largest Data Record for CICS 1.5 and Largest Record Key + Largest Data Record starting with CICS 1.7 The largest size is: for tape for FBA Tracksize or for CKD (whichever is smaller) For FBA devices the CISIZE for the journal must be at least 7 bytes larger than this value and must be a multiple of 512 if less than 8193 or a multiple of 2048 if greater than The recommended size is 2 to 2.5 times the average journal record, as long as this would provide room for the minimum (see above). The average size for a journal record is: 80 + average record key + average data record for CICS 1.5 and average record key + average data record starting with CICS 1.7 BUFSUV=4089 Normally not needed for Recovery Journals. If omitted, will default to value specified for "BUFSIZE". Page 38 Preparing CICS for Recovery

43 JOUROPT=RETRY Defines the actions taken by CICS upon encountering an error or a FULL condition on this journal. Any or all of the following options may be coded (in parentheses if more than one is specified): PAUSE Should be specified cautiously. It makes CICS wait for an Operator response prior to overwriting a journal. RETRY CRUCIAL INPUT Causes CICS to switch journal datasets if an I/O error occurs. Causes CICS to abend if an I/O error occurs and: this is a single dataset journal retry was not specified, or an I/O error also occurred on the other dataset Is required for Dynamic Transaction Backout and Emergency Restart. This specifies that input operations are allowed. OPEN=INITIAL Specifies that this journal should be opened at startup. DEVADDR=(SYSnnn,SYSmmm) Specifies the logical units for the first and second journal files DFHJCT TYPE=FINAL Defines the end of the JCT Table. Preparing CICS for Recovery Page 39

44 Initializing your Journal File for CICS Each journal file must be initialized before CICS can use it. This function is only required prior to the first use, but we recommend that it be done after each backup of the journal so that the contents of the journal will not be duplicated between journal backups. If "DISK2" or "TAPE2" is specified for "JTYPE", both journal files must be initialized. Disk Journals The JCL needed for initializing disk journals is as follows: // JOB INIT // DLBL JOURNAL,'your.journal.name',0,SD,CISIZE=ccccc // EXTENT SYSnnn,vol-id,1,0,rel-trk/blk,nbr-trks/blks // ASSGN SYSnnn,DISK,VOL=vol-id,SHR // LIBDEF CL,SEARCH=PRDCLB // EXEC DFHJCJFP,SIZE=AUTO /& NOTES: For FBA devices, the CISIZE must be at least 7 bytes larger than the JCT BUFSIZE and must be a multiple of 512 if less than 8193, or a multiple of 2048 if greater than For CKD devices, omit the CISIZE Operand. Page 40 Preparing CICS for Recovery

45 Tape Journals The JCL needed for initializing tape journals is as follows: // JOB INIT // ASSGN SYS010,CUU TAPE DRIVE // LIBDEF CL,SEARCH=PRDCLB // EXEC DFHFTAP /& Preparing CICS for Recovery Page 41

46 Activating Automatic Journaling (CICS FCT) You can activate automatic journaling by specifying the following Operands in the File Control Table (DFHFCT TYPE=DATASET) for each file that is to have Forward Recovery Support: JID=nn Where nn is the 'JFILEID' value of the journal file to be used for this dataset. Multiple files can share the same journal. The choice of how many journals to use should be based on the amount of update activity occurring and the resulting loss of performance from the contentions of too many updates being funnelled to the same journal. JREQ=(ASY,RU,WU,WN) Specifies the type of file operations to be written to the journal. Only the Update (WU) and Add (WN) functions are required for forward recovery. They cause the "after" images to be journaled. The (RU) option causes the "before" images to be journaled. This option is only required if you intend to use the FORMAT(REDUCED) Operand of the OUTPUT BACKUP Command, or if you want to be able to perform BACKOUT Recovery. The (ASY) option will cause the journal records only to be written when the buffer is full. This reduces the overhead related to journaling, but does not ensure that all updates are journaled prior to the dataset being altered. Omitting the (ASY) will guarantee that all updates will be written to the journal first, but will cause longer response times, and shorter journal blocks. (ASY should be used only for very high activity journals). Page 42 Preparing CICS for Recovery

47 Add Journal Support to the CICS PCT, PPT and SIT Tables Make sure that the following entries are in your CICS PCT and PPT.: DFHPCT TYPE=GROUP,FN=JOURNAL DFHPPT TYPE=GROUP,FN=JOURNAL If you are using the CICS RDO facility, the above definitions are contained in GROUP DFHJRNL. The following entry must be added to your CICS SIT. The "xx" is the value specified for the SUFFIX=xx in the DFHJCT TYPE=INITIAL macro entry: DFHSIT JCT=xx, The following entries are only required in your CICS SIT if you are running CICS release 1.6 or earlier: DFHSIT JCP=1$, DFHSIT FCP=A$, 'AUTOJRN' support 'AUTOJRN' support Preparing CICS for Recovery Page 43

48 Add Journal File JCL to your CICS Startup Jobstream The Journal File JCL that you need to add to your CICS startup jobstream is shown below. // DLBL DFHJnnA,'your.journal.diska',0,SD,CISIZE=nnnn // EXTENT SYSnnn,vvvvvv,... // DLBL DFHJnnB,'your.journal.diskb',0,SD,CISIZE=nnnn // EXTENT SYSmmm,vvvvvv,... NOTES: nn in DFHJnnA is the two digit number from 'JFILEID=' in JCT'. DFHJnnB is only required if 'DISK2' is specified for 'JTYPE' in the JCT. For FBA devices, CISIZE must be at least 7 bytes larger than JCT BUFSIZE and must be a multiple of 512 if less than 8193, or a multiple of 2048 if greater than Page 44 Preparing CICS for Recovery

49 For Tape Journals // ASSGN SYSnnn,CUU First dataset drive // ASSGN SYSmmm,CUU Second dataset drive NOTES: SYSnnn and SYSmmm are the values specified in 'DEVADDR' in the JCT. SYSmmm is only required if 'TAPE2' is specified in 'JTYPE'. Preparing CICS for Recovery Page 45

50 Writing an EOF Mark on Tape Journals If a CICS abend or system failure should cause a non-system log journal tape to not be closed properly, a special CICS supplied program must be used to find the end of the journal and write an ending EOF mark. If this is not done, an I/O error or invalid data could be input to the Forward Recovery Program. The JCL to use to write EOF mark is shown below: // JOB EOFTAPE // ASSGN SYS010,CUU TAPE DRIVE // LIBDEF CL,SEARCH=PRDCLB // EXEC DFHTEOF /& Page 46 Preparing CICS for Recovery

51 USING CSI-RECOV Page 47

52

53 Considerations Before the description of the actual Recovery process, we have listed a number of issues to consider. Some of these issues may influence your approach to recovery, and we strongly recommend that you read the following section before setting up your Recovery JCL. Advance Preparations Recovering a lost file requires that you are prepared in advance. This means that CICS Journaling and CSI-RECOV have already been installed and tested, and that you have Recovery JCL ready before it is needed. Accumulating Journal Data The recovery process uses all journal records that were created after the time of the last VSAM file backup or DL/I image copy. The journal files themselves may be defined to be large enough to contain all of the update activity for this period of time, but if this is not feasible, each time CICS fills a journal file, the journal data must be archived to another dataset before it is overwritten. CICS journals can be backed up by CSI-RECOV by using the INPUT JOURNAL and OUTPUT BACKUP Commands. A companion product, CSI-JMASTER, from CSI, can be used to automatically submit the backup JCL each time CICS fills a journal file. CSI-JMASTER will also protect your journal data from being overwritten by CICS prior to the backup completing. If your CICS journal contains DL/I records that you want backed up, you either use the OUTPUT BACKUP Command or the OUTPUT DLILOG Command for generating your journal backup. The OUTPUT DLILOG Command generates a DL/I log dataset that can be read by any of the DL/I recovery utilities. The OUTPUT BACKUP Command generates a CSI-RECOV journal backup that can contain both VSAM and DL/I journal records. You can use the OUTPUT BACKUP dataset to manage all of your journal records until they are needed for a VSAM recovery or a DL/I change-accum process. Using CSI-RECOV (Considerations) Page 49

54 A Typical Failure/Recovery Cycle A complete cycle of events would often look like this: 1. Backup of data files 2. Journaled CICS updates 3. File damage (At this point, the recovery process would begin) 4. Restore files from backup 5. Use CSI-RECOV to re-apply journaled updates to your damaged VSAM dataset(s) The file has now been restored to the condition it was in just before damage occurred (point 3. above). Page 50 (Considerations) Using CSI-RECOV

55 Recovery with Non-journaled Batch Updates The recovery process gets more extensive if the journals do not include all updates to the files needing recovery. This could happen if non-journaled batch updates are involved. The cycle of events would look as follows: 1. Data files are backed up 2a. Journaled CICS updates 2b. Batch updates (not journaled) 2c. More journaled CICS updates 3. ***** File damage ***** 4. Restore files from backup 5a. Use CSI-RECOV to re-apply journaled updates from 2a. above 5b. Re-run batch updates 5c. Use CSI-RECOV to re-apply journaled updates from 2c. above. The file has now been restored to the condition it was in just before damage occurred (point 3. above). The above process can be simplified by journaling the VSAM updates made by batch programs. CSI International has a companion product, CSI-JOURNAL, that provides the Batch Journaling function without modification to any of your application programs. Contact us for more information if you have a need for this capability. Using CSI-RECOV (Considerations) Page 51