Skip to main content

Preface

InfoVic1 and InfoVic2 are two complementary and independent INFO-RECOVERY options.

InfoVic1 checks the execution of all actions of IMS database recovery.

InfoVic2 checks the execution of all actions of DB2 tablespace recovery.

InfoVic1 and InfoVic2 together check the execution of recovery operations of IMS databases and DB2 tablespaces.

The following options are provided:

  • to set checkpoints on IMS databases and/or DB2 tablespaces: VIC points

  • to execute recovery processing on IMS databases and/or DB2 tablespaces:

    • physical recovery to get back to the last known state of data

    • logical recovery to get back to a synchronized VIC point

  • to automatically execute operator commands in an IMS environment and/or DB2:

    • START (RW, RO,. ..)

    • STOP

    • Switch log

  • to view the chronological account of backup operations, synchronization, and recovery of a set of IMS databases and/or DB2 tablespaces.

This document applies to users who want to implement InfoVic1 and/or InfoVic2.

It assumes that InfoVic1 and/or InfoVic2 have been installed according to the procedure described in the installation manual HR104.

Most of the function parameters are common to both the IMS and DB2 environments; therefore, the functions are described in common paragraphs. Specific parameters of an environment are referenced.

INFO-RECOVERY

INFO-RECOVERY is composed of four complementary and independent software packages:

  • InfoRec1

    InfoRec1 supervises, along with DBRC, all data sets associated with IMS recovery:

    • image copy

    • change accum

    • log

  • InfoRec2

    InfoRec2 supervises, along with the DB2 catalog, all data sets associated with DB2 recovery:

    • image copy

    • incremental image copy

    • log

  • InfoVic1

    InfoVic1 includes all functions associated with IMS recovery:

    • application checkpoint

    • IMS automatic operator

    • physical recovery

    • application recovery to a checkpoint

    • "MAP" of the activity

  • InfoVic2

    InfoVic2 includes all functions associated with DB2 recovery:

    • applicative checkpoints

    • DB2 automatic operator

    • physical recovery

    • application recovery to a checkpoint

    • "MAP" of the activity

The combination of InfoVic1 and InfoVic2 mixes DB2 and IMS checkpoints and repositions IMS databases and DB2 tablespaces to these checkpoints.

General Description​

INFO-RECOVERY is a RECOVERY control automaton that generates JCL and controls its execution.

It executes under TSO-ISPF and uses ISPF tables and skeletons.

The JCL is generated under specific conditions.

  • according to the user requirements that specify:

    • the function to execute

    • the subsystem (IMS and/or DB2) on which it has to be applied

    • the databases to process

    • the execution parameters

  • according to a default parameter library: the parmlib;

The user can also act on the JCL generation:

  • by requesting the execution of CLIST or REXX procedures

  • by providing its own generation skeletons

The generated JCL can be saved in a file or submitted directly by INFO-RECOVERY.

In this case, the generator job of the JCL will be called "GENERATING JOB", the current step of the generating job will be called "MOTHER STEP", and the submitted job will be called "GENERATED JOB".

The generating job can control the execution of the generated job. It can wait until the end of the execution of the generated job to continue its own execution (see Generated Job Control). In this case, the good or bad execution of the generated job will provoke the good or bad execution of the mother step.

The control of the execution allows for the execution of image copy at the beginning of an application job, and for the continued execution of the application job only when the image copy is executed.

The sequence of INFO-RECOVERY operations is explained in paragraph: Execution.

PARMLIB​

The PARMLIB is essential to INFO-RECOVERY. The PARMLIB contains these components:

  • JCL generation skeletons

  • Description of the IMS or DB2 site see the Installation Guide of INFO-RECOVERY, HR104

  • Default processing parameters for various functions

  • Standard CLIST of the product

  • ISPF panels

  • Members that allow execution of SQL statements

InfoRec​

The InfoRec component is common to all INFO-RECOVERY software.

It includes services and general utilities.

  • The INFO-RECOVERY software installation: see HR104 reference manual.

  • The INFO-RECOVERY functions execute in batch mode as well as under ISPF-TP through InfoRec:

    In batch mode, only an EXEC card and a SYSIN card are necessary. Under ISPF-TP, the call is made by a simple SELECT PGM with no modification of the logon procedures. Issuing modes in batch and under ISPF-TP are explained in paragraphs BATCH Execution and Execution under TSO/ISPF.

  • Management of the different environments. It is possible to manage different environments and to chain them in order to create a hierarchy to receive the new versions of the software. See manual HR104.

Execution​

warning

Do not execute INFOVIC programs during the execution of a CHANGE.RECON UPGRADE command.

Whatever the executed INFO-RECOVERY software is, the operating mode is always identical.

  1. Request analysis and JCL generation parameter preparation.

    1. Identify the requested function and the subsystem (IMS and/or DB2) on which it has to run.

      For example, perform image copy on all the tablespaces of the DB2 "DB2P".

    2. Create the list of databases to process:

      Identify databases named in SYSIN, accessing the reference file of the subsystem (RESLIB for IMS and/or the catalog for DB2),

    3. Identify the function parameters.

      They specify JCL generation parameters. For example, execute an image copy on disc or on tape.

  2. Execution of CLIST or REXX procedures of the site

    They allow the modification of the list of objects and generation parameters.

  3. Skeletons inclusion and generation of JCL and/or sysin of utilities that will insure the execution of the requested function,

  4. JCL submitting or dynamic call of the function, and controlled execution of the function or the JCL.

The operating mode of INFO-RECOVERY can be schematized as follows:

Inforec operating mode scheme

BATCH Execution​

In batch mode as well as in interactive, the execution of INFO-RECOVERY is requested by the call of the module CSXEXEC.

In batch mode, the necessary JCL is the following:


//S1 EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
// PARM=(FUNCTION,\'Funcname\'\[,Name,\'Value\'\])
//SYSIN DD *
Parameters of the requested function

When executed in batch mode, the module CSXEXEC receives two types of parameters:

  1. The execution parameter defines the function to execute

  2. The SYSIN file specifies on what databases to execute the function and detailed parameters of the function.

Parameters​

CSXEXEC receives a succession of (Name,Value) pairs, where Name is the name of a variable and Value its value. The value has to be coded between apostrophes.

Expected variables follow:

{wrapper="1" role="DL"}

  • FUNCTION

    This parameter is mandatory; it specifies the name of the function to execute: CS1VIC, CS1IC, etc....

  • IMSID

    This parameter is optional; it specifies the IMS subsystem on which the function will execute. The subsystem has to be defined in parmlib member IMSIDS.

    For a data sharing environment, the name of the IMS group can be specified. The group of IMSs must have been defined in member IMSDSGS of the PARMLIB.

    If this parameter is omitted, INFO-RECOVERY will work on the default IMS subsystem (as defined in parmlib member SYSIDS). The special value IMSID,'NONE' allows for skipping all IMS-related allocations; it may only be used for mixed DL1/DB2 functions for those executions in which only DB2 selection parameters are entered.

  • DB2ID

    This parameter is optional; it specifies the DB2 subsystem on which the function will execute. The subsystem has to be defined in parmlib member DB2IDS.

    You may specify the name of the DB2 group if data sharing is used on your site. If such is the case, the DB2 group must have been defined in member DB2DSG of the PARMLIB. INFO-RECOVERY will select the DB2 sub-system (inside the group) according to the system where the execution takes place.

    If this parameter is omitted, INFO-RECOVERY will work on the default DB2 subsystem (as defined in parmlib member SYSIDS). The special value DB2ID,'NONE' allows for skipping all DB2-related allocations; it may only be used for mixed DL1/DB2 functions for those executions in which only IMS selection parameters are entered.

  • DEBUG

    This parameter is optional. If any problem occurs, the DEBUG function allows the user to trace the Clist (or REXX) procedures, the INFO-RECOVERY skeletons, and the commands passed to the subsystem (IMS/DB2). Values: 'Y' or 'N' (default).

The example below shows the execution of a FULL IMAGE COPY (CS1FIC function) on the DB2 DB2E:

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1FIC',DB2ID,'DB2E')
 //SYSIN   DD *
  Parameters of the CSIFIC function

Execution of an IMS image copy processing on the default IMS, with tracing of Clist and IMS commands.

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1IC',DEBUG,'Y')
 //SYSIN     DD *
  Parameters of the CS1IC function

SYSIN​

The SYSIN file specifies variables that will manage the execution of the requested function.

  • Indication variables:

    On what databases and/or what tablespaces the function must be executed?

  • Execution variables:

    How the function has to be executed?

Format​

The SYSIN sets variables with the following syntax:

 VARIABLE=value

note

  1. The character '*' in column 1 indicates a comment.

  2. The blank character (' ') after the value indicates that the rest of the line is a comment.

  3. The name of the variable must not begin in column 1. First column is reserved for the label followed by a blank.

  4. A comma (',') behind the value of a variable connects the variable to the next variable and creates groups of variables. There will be as many executions of the function as there are groups of variables.

  5. It is easier to read the SYSIN when starting the line with the indication variable: variable "DB" for IMS and variables "TS" and "DBSET" for DB2.

  6. To address 128 character long names, it is possible to enter them into 2 exist lines: End with the character "+" followed by a blank, start the next line into column 2. This possibility only exists to cut the character variable type. The maximum number of character for the value of a variable is 160 characters.

The different execution variables and the associated syntax are described in chapters covering each function.

Default Values​

It is not necessary to systematically enter all execution variables of a function into the Sysin:

For each INFO-RECOVERY function, a member of the same name is associated in the parmlib library.

It has the same syntax as the SYSIN file.

It contains the definition of all variables necessary for the execution of the function.

It sets the default customization of the function for the site. (see: Customizing INFO-RECOVERY).

The example below shows the execution of a FULL IMAGE COPY (function CS1FIC) of tablespaces from the DB2 DB2E and which name starts with CLI:

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1FIC',DB2ID,'DB2E')
 //SYSIN   DD *
  TS=(CLI*)

In this example, no execution parameter was specified. The values found in member CS1FIC of the Parmlib will be used.

User Variables​

User variables can also be specified in SYSIN and can also be used in REXX procedures (or CLIST) or in user skeletons (see: User Variables).

The Other Data Sets​

Below is the list of optional DD cards and their use:

CSXPRINT

Checking the printing of messages. By default they are dynamically sent to SYSOUT=*.

CSXPLIB

Using a PARMLIB other than the default parmlib. The example below illustrates a VIC JCL where the parmlib has been forced:

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1VIC',IMSID,'IMST')
 //CSXPLIB DD   DSN=INFOREC.V1R0.CSBPLIB,DISP=SHR
 //SYSIN   DD   *
   DB=(DBCLI*),ID=CLI01             <===... vic client database

CSXULIB

To add a user parmlib (see: User Configuration under ISPF/TP). The use of CSXULIB redefines ISPF objects used by the software and the default customization of the function. A member of the parmlib is then "masked" by a member with the same name existing in the user library.

The example below illustrates a RECOV JCL where a user library has been added:

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1RECOV',IMSID,'IMST')
 //CSXULIB   DD DSN=userid.INFOREC.USERLIB,DISP=SHR
 //SYSIN     DD *
   DB=(DBCLI*),ID=CLI01,TEST=Y      <===... test of recovery

JCLOUT

All functions that generate JCL accept a TEST= parameter, allowing to print (TEST=Y) or to submit (TEST=N) the generated JCL. It is possible to write the generated JCL into a data set instead of submitting it by adding a JCLOUT DD statement.

The example below illustrates a JCL of RECOV where the submit has been routed to the library specified in JCLOUT:

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1RECOV',IMSID,'IMST')
 //JCLOUT    DD DSN=userid.INFOREC.JCLOUT(MYRECOV),DISP=SHR
 //SYSIN     DD *
   DB=(DBCLI*),ID=CLI01,TEST=N    <===... Recov JCL copied to JCLOUT

Execution under TSO/ISPF​

As for the batch mode, the CSXEXEC module initializes the INFO-RECOVERY environment.

In CLIST, the starting command is the following:

 ISPEXEC SELECT PGM(CSXEXEC) NEWAPPL(CSX)

Inside a menu, the starting is requested as follows:

 &ZSEL = 'PGM(CSXEXEC) NEWAPPL(CSX)'

The execution of one of the two previous commands results in the display of the main INFO-RECOVERY menu:


INFO-RECOVERY - Primary Panel
COMMAND ===\>
1 INFOREC1 - Control DL1 recovery files
2 INFOREC2 - Control DB2 recovery files
V INFOVIC - IMS/DB2 data recovery
C CONFIG - User Profile Configuration
E EDIT - Edit current parmlib
P PARMLIB - Parmlib Management
T TERMINAL - Display logical terminal
J JOBS - Submitted jobs log
I INSTALL - Installation functions
N NOTES - Show INFO-RECOVERY changes

Available options:

  • InfoRec1, control of IMS recovery data sets, is described in the InfoRec1 User Manual: HR101,

  • InfoRec2, control of DB2 recovery data sets, is described in the InfoRec2 User Manual: HR102,

  • InfoVic1 and InfoVic2, execution of the DB2 and IMS recovery, are described in the HR103 User Manual,

  • Option C (configuration), allows the ISPF user to define its own environment: which IMS or DB2 to execute functions,...

    This option is described in annex: User Configuration under ISPF/TP.

  • Option E (edit) allows access to EDIT the current PARMLIB and to modify default parameters.

  • Option P (parmlib) and option I (installation) are described in the Installation Manual HR104.

  • Option T (terminal) accesses the logical terminal that draws all function executions and associated sysouts. It is described in paragraph Logical Terminal.

  • Option J (jobs) accesses the list of jobs submitted under the control of an INFO-RECOVERY session.

  • Option N allows viewing of product modifications.

Customizing INFO-RECOVERY​

All functions of INFO-RECOVERY are managed by ISPF variables. Associated with the ISPF skeletons, they generate the JCL for each function.

INFO-RECOVERY uses three types of variables:

  • System variables,

  • Site variables,

  • Function variables;

INFO-RECOVERY allows the use of a fourth type of variable: user variables.

Depending on their type, variables can be found in these locations:

  • Within call parameters of CSXEXEC in batch mode or user configuration in interactive mode

  • Within information provided during the call:

    SYSIN File in batch mode or function screen in interactive mode;

  • In the parmlib library,

  • Or directly generated by INFO-RECOVERY.

If a variable is specified both in SYSIN and PARMLIB, the value specified in SYSIN will be used.

If a variable is specified neither in SYSIN nor in PARMLIB, INFO-RECOVERY will use its own defaults.

System Variables​

System variables are non-updatable variables that are generated automatically during each execution. They cannot be specified in the user parmlib or in the SYSIN file.

Example: variable HHMMSSD that is used for the generation of an image copy dsname. This variable contains the execution timestamp specified in tenth of seconds.

The list of system variables and their meaning is described in paragraph: System Variables.

Site Variables​

Site variables define to INFO-RECOVERY the site's execution configuration and general conditions.

Their values can be specified in call parameter, in the SYSIN file or in the parmlib of INFO-RECOVERY.

6 members of the parmlib provide variables for the site:

  • SYSIDS describes all MVS systems using the products

  • IMSIDS describes IMS systems using the products

  • DB2IDS describes DB2 systems using the products

  • PRODUCTS describes installed products

  • CUSTOM describes the global INFO-RECOVERY customization

  • CTRLRUN checks the status of batch CSXEXEC

The format of these members is described in the Appendix. Modification rules are detailed in the Installation Manual HR104.

Function Variables​

Function variables are used to specify execution parameters of a function.

Their values can be specified in the SYSIN file or in the parmlib of INFO-RECOVERY in a member having the same name as the function.

Several variables are associated with each function. They are described in chapters that explain the function.

The user is informed about the:

  • indication variables

  • execution variables

After the first installation, parmlib members associated with functions contain a customization adapted to the most frequent use of INFO-RECOVERY and they only need to be modified for sophisticated tests (see adjustment paragraphs and complements for each function).

During re-installations or further upgrades, the customization is preserved and the new parameters are automatically added. This modification is dated. The list of all members that have been automatically modified may be viewed with the option 'Note' on the main INFO-RECOVERY menu.

User Variables​

User variables can be entered into the SYSIN file or in the parmlib member corresponding to the function.

These variables may be used by ISPF skeletons and REXX procedures (CLIST).

The example below illustrates the execution of a RECOVERY (function CS1RECOV) of IMS IMST databases which name begins with DBX, and specifies the user parameter USERDEST (this parameter is supposed to allow the routing of sysouts to a particular printer).

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1RECOV',IMSID,'IMST')
 //SYSIN     DD *
   DB=(DBX*),USERDEST=rmt27

Calling User Procedures​

As indicated previously in paragraph Execution, INFO-RECOVERY allows the execution of user REXX or CLIST procedure.

Corresponding members can be found in the PARMLIB or in a library declared in the member SYSIDS of the parmlib (variable SYSPROC or SYSEXEC).

The calling mode of these procedures is specified in Calling User Procedures.

Generated Job Control​

JOB Card​

It is possible to determine the JOBNAME and other characteristics of the JOB generated by modifying generation variables of the JOB card.

It is built using the standard clist JOBCARD, the member CUSTOM of the parmlib, and the ISPF skeleton CSKJOBC (parmlib). It is also possible to redefine its own JOB card by copying this last member in a declared user library. The copy will then 'mask' the original item (see the Installation Manual of INFO-RECOVERY HR104).

The example below illustrates all control options:

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1FIC',DB2ID,'DB2E')
 //SYSIN     DD *
   TS=CATALOG,TEST=N,           <===... Full Image Copy
     JOBNAME=MYJOB,                 ... jobname
     CLASS=A,                       ... job CLASS
     MSGCLASS=X,                    ... MSGCLASS
     TYPRUN=SCAN,                   ... TYPRUN
     USER=userid,                   ... USER
     PSW=password,                  ... user PSW
     NTUSER=userid,                 ... NOTIFY
     ACCOUNT=account                ... ACCOUNT

Checking the Execution​

Jobs submitted by INFO-RECOVERY functions may be checked using option JOBCHECK=Y/N. The default value of this option is specified in the CUSTOM member of the parmlib. This option may be specified at any time by adding the jobcheck= parameter prior to the execution of a function.

When job control is requested, the request ensures that all generated jobs will be finished before it ends. Therefore, the work may be checked as a single task. If one of the generated jobs abends, the request also abends to report the problem. (see "RC" to issue a return code instead of an abend 4001).

When executing an INFO-RECOVERY function in batch mode, the maximum waiting time for the start is specified using option JOBQTIME=(HHMM). The default value of this option and the period of the waiting cycle JOBWAIT=(seconds) are specified in the CUSTOM member. If the delay has expired, the job is PURGED. If the job starts, it will run until it ends (normal or abend).

When leaving the ISPF panels of INFO-RECOVERY, the product will purge all QUEUED jobs (keep the RUNNING jobs). If you return to INFO-RECOVERY before the end of these jobs, INFO-RECOVERY will recognize the jobs. If not, their status will be UNKNOWN.

A generated job with the option JOBCHECK=Y will abend if the generating job is missing or has been purged.

The status of the submitted job may be any of these:

  • QUEUED- The job is waiting for its execution.

  • RUNNING- The job is active.

  • ENDED- The job is over.

  • ABENDED- The job abended.

  • UNKNOWN- The job status is unknown. Case of the active jobs left by the generating job.

  • PURGED- The waiting job has been deleted as a result of the deletion of the request. In this case, the selected job will detect that the waiting job is missing and will issue its own purge.

Under ISPF, it is possible to directly access SDSF for a specific job using selection code S.

Execution Results​

When executing CSXEXEC in batch mode, the following abends can be issued:

  • ABEND 4001 in case of an incorrect execution of the CSXEXEC function,

  • ABEND 4002 in case of a system abend (non-ISPF)

  • ABEND 4003 in case of an ISPF error.

Carefully examine the execution report to find the messages explaining the reason for the error.

The user may also request to issue a return code instead of an abend 4001 bu specifying the parameter RC= in the member CUSTOM of the parmlib (for all batch executions) or in SYSIN (for a specific execution). The default value of the RC= parameter is 0 (no conversion).

InfoVic - Application Recovery

Select Option V on the INFO-RECOVERY main menu to display the InfoVic1/2 menu.


INFOVIC - Primary Panel
COMMAND ===\>
1 VIC - Virtual Image Copy on DB(s)/TS(s)
2 MAP - Map DB(s)/TS(s)
3 RECOV - Recover on DB(s)/TS(s)
A AOP - Automatic Operator Program

The specified options correspond to the following functions:

  • CS1VIC corresponds to virtual image copy.

  • CS1RECOV corresponds to recovery.

  • CS1MAP corresponds to map of the recovery.

  • CS1AOP corresponds to automatic operator.

These functions are described in the following chapters.

CS1VIC - Virtual Image Copy

Purpose​

The CS1VIC function creates checkpoints (VIC point) which are used when recovering a set of databases. It is a synchronous function, dependent on applications scheduling.

On return from the command, a valid VIC type recovery point has been created. Note that this function does not generate JCL and that it is used to be directly inserted into application JCL chains as a security step.

The insertion of a VIC step in operation JCL chains limits any operational loss.

The effective recovery to a VIC type recovery point will be examined in the chapter describing the CS1RECOV function.

This function ensures:

  • selection in the DBRC RECON dataset of those IMS databases and selection in the DB2 catalog of those DB2 tablespaces that match the selection criteria. .

  • awaiting the end of DL1 batch jobs or current BMP, as well as the end of DB2 locks

  • creation of a brief moment without update at the level of the IMS TP, DBRC, and DB2 by commands:

    • /DBD then /STA under IMS

    • LOCK, QUIESCE, then COMMIT under DB2

  • creation of a VIC point in the VIC RECON for the set of databases and association of the given identifier with the parameter ID=

The message below is displayed if the operation was successful:

 VIC TS yymmddhhmmssd WITH ID mytry IS SUCCESSFUL

The two main steps in the execution of a VIC are:

  • the Look step , where the function searches the possible batch jobs or BMPs in update on IMS databases as well as the long duration locks on DB2 tablespaces;

    If any are found, the function will wait until the end of these batch/locks before executing the VIC.

  • the VIC Start and End step , the only phase where databases are inaccessible for updating; The duration of this interruption is specified, allowing the operator to find the best compromise between a maximum of VIC backups and a minimum of user constraints.

Syntax​

The variables used to execute the CS1VIC function are described below.

The user can request the modification of default values of the function by modifying the member CS1VIC of the parmlib.



* comment
DB=(criterion,.), DB search criterion or \...
DBDSGRP=dbdsgrp, \... DBDS group criterion
PSB=(criterion,.), PSBLIB search criterion
TS=(criterion,.), TS search criterion
EXTS=(criterion,..), EXTS exclusion criteria
PLAN=(criterion,.), PLAN search criterion or \...
PKLIST=(criterion,..), \... PACKAGE search criterion
ID=id, id of VIC point attached (lg \<= 8 c.)
TSSET=Y/N, extend or not selection to full
* tablespace sets
DBSET=dbset, database search restriction (SQL syntax)
AUTHID=authid, creator search restriction (SQL syntax)
DSSEL=dssel, selection of TS partitions
TBLOCKS=Y/N, perform LOCK table before QUIESCE or not
NONRECOV=Y/N, process or not non-recoverable DBs
HALDB=Y/N, include or not the HALDB databases for
* processing
DISPLAY=Y/N, display the search result or not
*
WAIT=wait, wait during non critical sections
RWAIT=rwait, wait during critical sections
RETRY=retry, Retry during non critical sections
MAXTIME=maxtime, max time during critical sections
FAILED=failed, number of tests of VIC and/or START
MSG=Y/N, sending out a WAIT message or not
WTO=Y/N, sending out a WAIT WTO or not
ARCHLOG=Y/N, request or not of an unconditional OLDS
SWITCH and archiving of DB2 log
SWITCH=Y/N, request or not of an OLDS SWITCH
ARC=Y/N, wait or not of the end of the archiving
ARCTIME=arctime max time for the archive execution
ARLGT=arc-log-time max time for executing the -ARCHIVE LOG command
* comment
DB=(criterion,.), next set of parameters
\...

Specific IMS Parameters​

{wrapper="1" role="DL"}

  • DB= (criterion,.)

    DB= specifies the set of databases where the VIC point must be set in case the DBDSGRP parameter is not mentioned. Each criterion can be either specific or generic.

    The HALDB databases (dbmaster and/or partition) are also included for processing except if the parameter HALDB(N) is specified.

    Parameters DB= and PSB= can be used simultaneously.

  • DBDSGRP=dbdsgrp

    DBDSGRP= specifies the set of databases where the VIC point must be set as well as the databases associated to the DBDS group mentioned; if the DBDSGRP parameter is specified, the DB parameter is ignored. Parameters DBDSGRP= and PSB= can be used simultaneously.

  • PSB=(criterion,...)

    PSB= specifies the set of databases where the VIC point must be set as well as the databases associated to the PSBs mentioned; the PSB names may be generic. The PSBLIB (which dsname is found in parmlib member IMSIDS) is searched to establish the list of databases those PSBs work on. Parameter PSB= can be used together with DB= or DBDSGRP= parameter.

  • SWITCH=Y/N

    SWITCH= requests the switch of OLDS that will be performed if updates of selected DBs are not archived.

    Default parameter:

    N, if DBRCFORC=N indicated in IMSIDS

    Y, if DBRCFORC=Y and LEVEL < 510 indicated in IMSIDS

  • ARC=Y/N

    ARC= indicates whether the function has to await the end of the archiving or not. Default parameter: Y

  • ARCTIME=arctime

    ARCTIME= is the maximum wait duration of archiving. Default parameter: 1800

  • TBLOCKS=Y/N

    performs a QUIESCE of the selected TS without a previous execution of the LOCK TABLE ... IN SHARE MODE statements. This way, the performance is improved but the risk that the QUIESCE fails is increased because updates can start simultaneously.

    Default parameter: Y

  • NONRECOV=Y/N

    NONRECOV= specifies whether non-recoverable databases must also be processed.

    Default parameter: N

  • NULPRLOG=REFUSED/ACCEPTED

    Process of the case where an active PRILOG recording (not a log stop time) is not associated to a (DSN NULLFILE).

    • REFUSED: the situation (non-logged modification on undetermined database) is considered as crippled. The VIC process stops in an error and the VIC-011E message is emitted to report the origin of the issue.

    • ACCEPTED: the situation is ignored and the VIC treatment continues.

      Default parameter: REFUSED

  • HALDB=Y/N

    Specifies if the processing must include (Y) or not include (N) HALDB databases of IMS Version 7 (when performing a generic research on the name of the dbmaster or the name of the partition)

    Default parameter: Y Specific DB2 Parameters

Specific DB2 parameters​

  • TS=(criterion,..)

    TS= specifies a list of tablespace names patterns. Tablespaces referenced in the DB2 catalog whose name matches one of the patterns are included in the list of tablespaces on which the requested function is to be performed.

    note

:

The criterion is only used for base tablespaces. For base tablespace, the VIC point always incorporates the selected tablespace, all the auxiliary tablespaces and LOB tablespace; there is no control on the auxiliary tablespaces and LOB tablespaces names. VIC points for base tablespace names which they are related is conform to generic criteria.

Precisely:

  • A name pattern means a generic name according to SQL LIKE syntax: special characters are the percent sign % and the underscore sign _; additionally, an asterisk * is transformed into a % sign.

  • For a pattern in the form dbname.tsname, tablespaces selected are those whose database name matches the dbname pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

  • For a pattern in the form tsname, tablespaces selected are those whose database name matches the DBSET pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

  • If TS=CATALOG is specified, the function will be performed on catalog tablespaces.

  • If TS=% or TS=* is specified, no catalog tablespace will be selected.

The database name often occurs as the first index column on catalog tables read by the function. Therefore, better performance in reading from the DB2 catalog will be achieved if the database name pattern is specified with as much precision as possible, either through the DBSET parameter, or through the qualifier in a list item of the form dbname.tsname.

If TS parameter is specified, the list of tablespaces matching TS, DBSET and AUTHID patterns is established. Tablespaces accessed by application plans specified through PLAN= parameter or by packages specified through PKLIST= parameter may be added to the list. If TSSET=Y is specified, the list is then extended to all tablespaces related through referential integrity to any tablespace in the list. The final list is the list of tablespaces participating to the VIC point.

The special value TS=VIC specifies that the list of tablespaces to restore must match to all the tablespaces that participated at the VIC point defined by ID and TIMESTAMP parameters. This list is reconstituted from the information memorized in CS2RECON file.

  • EXTS=(criterion,.)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • IX=(criterion,...

    Specifies a list of indexspaces to be saved. The IX parameter works exactly the the same way as the TS parameter but only for indexes defined in COPY=Y in the DB2 catalog.

  • DBSET=dbset

    DBSET= is used as a default dbname pattern for each item in the list TS= in the form tsname; see the description of TS= parameter. Default parameter: %

  • TBLOCKS=Y/N

    Allows to perform the QUIESCE of chosen TS without previous execution of LOCK TABLE...IN SHARE MODE orders. In this case, the performances will be improved, but this also increases the risk that QUIESCE fails due to updates that can start simultaneously. For the TS of the catalogue (when TS=CATALOG is coded), this parameter has no effect: the N value is forced.

    Default parameter: Y

  • AUTHID=authid

    AUTHID= is used as a creator's name pattern for each item in the list TS=; see the description of TS= parameter. Default parameter: %

  • DSSEL=dssel

    indicates that the VIC point must be set for the specified partition (of the partitioned tablespaces) and all the non-partitioned tablespaces that were selected for the processing.

    Default parameter: ALL

  • PLAN=(criterion,.)

    PLAN= specifies a set of tablespaces where the VIC point must be set adding a list of specific or generic application plans names: all tablespaces accessed by application plans which names match the specified criterion are selected.

    PLAN= and TS= parameters can be used together, unless TS=CATALOG is specified (using PLAN= is not allowed in this special case). Even if the tablespaces from the catalog are accessed by a PLAN, those are systematically excluded of the treatment. Parameters PLAN= and PKLIST= cannot be used simultaneously.

  • PKLIST=(collid.package,...)

    PKLIST= specifies a set of tablespaces where the VIC point must be set adding a list of specific or generic package names: all tablespaces accessed by application packages which qualified name matches the specified criterion are selected. The qualified package names must have the format collid.package, where collid is a collection selection criterion and package is a package selection criterion. Note that the more precise each collid criterion is, the more efficient the corresponding SQL order will be (indeed, the collection name appears as an index column on the catalog table SYSIBM.SYSPACKDEP).

    PKLIST= and TS= parameters can be used together, unless TS=CATALOG is specified (using PKLIST= is not allowed in this special case). Even if the tablespaces from the catalog are accessed by a PACKAGE, those are systematically excluded of the treatment. Parameters PLAN= and PKLIST= cannot be used simultaneously.

  • TSSET=Y/N

    TSSET= [allows the inclusion of all tablespaces (obtained by treating the TS and EXTS parameters) that fulfill the reference integrity requirements: all tablespaces with a table linked by a reference integrity constraint to a tablespace table in the defined list are added to the list.

    • Y: search the tablespace set for the reference integrity constraint.

      note

:

Specifying TSSET=Y ensures that the VIC point will concern tablespace sets.

  • N: : no search for this tablespace set.

Default parameter: N

note

:

The relations with the LOBS and XML auxiliary tablespaces are not taken into consideration through this parameter, but through the AUXTS parameter.

  • ARLGT=nnn

    Specifies the value of the parameter TIME of the command -ARCHIVE LOG MODE(QUIESCE). Value 001 to 999.

    Default parameter: 420 Parameters Common to IMS and DB2

  • ID=id

    ID= identifies the VIC point to create. This identifier will be used during a recovery request.

  • DISPLAY=Y/N

    DISPLAY= lists on SYSOUT the selected databases and tablespaces.

    Default parameter: N

  • WAIT=wait

    WAIT= indicates the maximum wait time during the non-critical sections (see complements).

    Default parameter: 10

  • RWAIT=rwait

    RWAIT= is the maximum wait time during the critical sections (see complements).

    Default parameter: 1

  • RETRY=retry

    RETRY= is the number of retries to perform during the non-critical sections (see complements);

    Default parameter: 6

  • MAXTIME=maxtime

    MAXTIME= is the maximum execution time during the critical sections (see complements).

    Default parameter: 60

  • FAILED=failed

    FAILED= is the number of tries in case of failure of the VIC (see complements) and/or the IMS /START command. When the VIC point has been realized, the CS1VIC restarts IMS databases by issuing a command /START. It checks that the command is accepted by IMS by issuing a command /DIS. If databases are not restarted after a certain time that depends on parameters WAIT and RETRY, the function CS1VIC re-issues the command /START by decrementing the parameter FAILED.

    Default parameter: 1

  • MSG=Y/N

    MSG= sends a message when the function starts waiting.

    Default parameter: Y

  • WTO=Y/N

    WTO= sends a console message when the function starts waiting.

    Default parameter: N

  • ARCHLOG=Y/N

    ARCHLOG= requests an unconditional switch of OLDS and an archiving of the DB2 log. This parameter is ignored for DB2 if its level is less than V2R3. For IMS, this parameter overrides the SWITCH parameter, if they are both set.

    Default parameter: N

Examples​

Virtual image copy of only one database IMS DBCLI01 with the identifier CLIBEGIN:

 DB=DBCLI01,ID=CLIBEGIN

Virtual image copy of the IMS databases DBCLI01, DBCLI02 with the identifier CLIMAJ:

 DB=(DBCLI01,DBCLI02),ID=CLIMAJ

Virtual image copy of all IMS databases beginning with DBCLI as well as all DB2 tablespaces beginning with TSCLI with the identifier CLIALL:

 DB=DBCLI*,TS=TSCLI*,ID=CLIALL

Virtual image copy of all IMS databases starting with DBCLI or with DBPRO and all tablespaces in databases DB%DB2 which names start with TSCLI or TSPRO, with the identifier CLIPRO:

 DB=(DBCLI*,DBPRO*),TS=(TSCLI*,TSPRO*),DBSET=DB%DB2,ID=CLIPRO

Virtual image copy of all IMS databases and all tablespaces except those of the catalog with the identifier ALL:

 DB=*,TS=*,ID=ALL

Tuning of the wait time at 45 * 20"=15' (long duration lock for DB2 or batch/BMP in progress for IMS):

 DB=DBCLI*,TS=DBCLIDB2.TSCLI*,ID=CLI01,WAIT=20,RETRY=45

Tuning of critical periods: 180"=3' maximum with a polling of 2 ":

 DB=DBCLI*,TS=TSCLI*,ID=CLI01,RWAIT=2,MAXTIME=180

Tuning of the number of tests: 3 tests maximum (batch example):

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //           PARM=(FUNCTION,'CS1VIC',IMSID,'IMSE',DB2ID,'DB2E')
 //SYSIN     DD *
  DB=DBCLI*,TS=TSCLI*,ID=CLI01,FAILED=3

A Sample Case​

To properly show the different cases found during the insertion of VIC steps in JCL chains, let us examine a small CLI application to be protected.

We suppose that databases DBCLIA and DBCLIB of this application have an IMS component and a DB2 component, and that they are the only ones which names start with DBCLI: a generic criterion may be used.

The operator executes a batch chain that includes two JOBS: JCLIC and JCLIP.

  • JCLIC includes:

    • a CS1 step to update the database DBCLIA,

    • an editing step CS2 to read databases DBCLIA and DBCLIB;

  • JCLIP includes:

    • a PS1 step to update the database DBCLIB and to only read the database DBCLIA.

To manage an abnormality in one or both jobs, see the illustration below:

 JCLIC
   CS0  Step VIC, DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLICS0
   CS1  Step update DBCLIA
   CS2  Step editing DBCLIA, DBCLIB
 JCLIP
   PS1  Step update DBCLIB, fetch DBCLIA

Possible errors are:

  • If step CS1 is supposed to be critical before step PS1 is executed, a recovery of database DBCLIA to the VIC point VCLICS0, using function CS1RECOV, allows the user to re-submit JCLIC.

  • If step CS1 is supposed to be critical after step PS1 has executed, restore both, DBCLIA and DBCLIB, to the VIC VCLICS0 and then re-submit both jobs.

  • If step PS1 is supposed to be critical, a recovery of DBCLIB at VIC VCLICS0 allows the user to only re-submit JCLIP.

Notice that, although the VIC involves two databases, it is possible to restore to this VIC only a subset of the databases.

We do not recommend to work like this:

  • First, the validity of this type of recovery (see JCL modification).

  • Second, in this situation it is always possible to split the set of databases described in the VIC into several smaller subsets and to fit the VIC step for each subset as close as possible to the corresponding update step. Thus, DBCLIB must have a VIC just before PS1 and not in CS0, because this database is not updated before PS1.

This exercise for our example gives the following result:

 JCLIC
   CS0  Step VIC, DB=DBCLIA,TS=*,DBSET=DBCLIA,ID=VCLICS0
   CS1  Step update DBCLIA
   CS2  Step editing DBCLIA, DBCLIB
 JCLIP
   PS0  Step VIC, DB=DBCLIB,TS=*,DBSET=DBCLIB,ID=VCLIPS0
   PS1  Step update DBCLIB, fetch DBCLIA

Let's examine the different cases of possible errors:

  • If step CS1 is supposed to be critical before step PS1 is executed, a recovery of database DBCLIA to the VIC point VCLICS0, using function CS1RECOV, allows the user to re-submit JCLIC.

  • If step CS1 is supposed to be critical after step PS1 is executed, it is necessary to restore DBCLIB to the VIC VCLIPS0, DBCLIA to the VIC VCLICS0, and to re-submit both jobs.

  • If step PS1 is supposed to be critical, a recovery of DBCLIB to the VIC VCLIPS0 allows the user to re-submit JCLIP.

Considering the above, we recommend the following three rules for the installation and the use of VICs:

  1. Rule of location: A VIC step must always be executed before an update step, not after it. Indeed, if a job step is supposed to be critical, the update activity of the step also is supposed to be critical; the VIC step then provides a consistent recovery point before the critical step.

  2. Rule of optimization: Only the databases that will be updated in the following step should be included in the VIC step. This induces an optimization of the virtual image copy because their duration is proportional to the number of databases.

  3. Rule of recovery: If a step is supposed to be critical whereas the rule of location is correctly applied, it is sufficient to retrace the chain of steps depending on the step in error, from the most recent to the oldest, and to include a request of recovery for each VIC step found.

    Thus in the example above, supposing CS1 to be critical after the end of JCLIP forces to trace PS1, PS0 (DBCLIB to the VIC JCLIP), CS2, CS1, CS0 (DBCLIA to the VIC JCLIC). Thus, the request of recovery must include DBCLIB to the VIC JCLIP, and DBCLIA to the VIC JCLIC.

However, in the beginning optimization should not be considered as the most important aspect. The installation of VICs has to be done application by application, using generic criteria whenever possible. This method provides the advantage of being very clear and easily to be applied.

Additional benefits of using generic criteria are provided by the following rule:

  • Rule of automation: The CS1RECOV function does not restore tablespaces or databases that have not been updated since the point of recovery indicated. We, therefore, recommended to let the CS1RECOV function automatically find databases to be restored and therefore to indicate, at the level of VICs, the greatest database sets (generic criteria).

Notice that, although there might be a conflict between this last rule and the optimization rule, in practice it is always necessary to enforce the automation rule even to the detriment of the optimization rule.

The optimization must be implemented only in cases requiring security but might slow down user services (VIC during TP sessions). Be aware that enforcing optimization requires a more rigorous implementation of VIC points in JCL chains and more rigorous recovery orders and/or procedures. Also, when chains evolve, these procedures might to be updated.

As a rule in the long term, the optimization is not an advantage but rather a constraint because a successful recovery system provides strength and automation.

The rules and/or procedures of recovery to be applied and/or maintained must be easy, clear, and precise. One of the main benefits to use INFO-RECOVERY is to allow the user to only think about "What to do" and not "How to do": the CS1RECOV function automatically performing any recovery request to a VIC point.

Refer to the example below that is now modified according to the rules above:

 JCLIC
   CS0  Step VIC, DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLICS0
   CS1  Step update DBCLIA
   CS2  Step editing DBCLIA, DBCLIB
 JCLIP
   PS0  Step VIC, DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLIPS0
   PS1  Step update DBCLIB, fetch DBCLIA

Let's examine the different cases of possible errors:

  • If the CS1 step is supposed to be critical (whether before or after PS1), a recovery of databases DBCLI* with the function CS1RECOV to the VIC point VCLICS0 recaptures the work. In reality, only the database DBCLIA will effectively be restored if PS1 has not been executed, while the two databases will be restored if PS1 has been executed.

  • If the step PS1 is supposed to be critical, a recovery of the databases DBCLI* to the VIC VCLIPS0 will restore effectively only the database DBCLIB.

Complements​

Setting VIC Parameters​

It is possible to modify VICs as described below:

  • The parameters RWAIT= and MAXTIME= control critical sections of VIC.

    A critical section is time interval during which it is impossible to update data.

    • The RWAIT= represents the maximum wait time of the IMS or DB2 reply following a command from the automatic operator. In an IMS environment, RWAIT=3 is a value we recommend, while RWAIT=1 has to be specified in a DB2 environment for optimal performance.

    • The MAXTIME= represents the maximum allowable constraint for users when running the VIC.

      The minimum value of MAXTIME is equal to: 3 * IMS+2 * DB2+2 * RTIME

      where IMS is the number of selected IMS databases and DB2 the number of selected DB2 tablespaces. The difference between the minimum and the specified value is the tolerance left to the VIC. This tolerance has to be important if the objective is to ensure the VIC. It can be low if the provoked interrupt is critical and getting the VIC is optional.

  • When a VIC fails (ex: maxtime reached), the databases are automatically restarted.

    It is possible to request a new try of the VIC.

    The maximum number of trys is set by the parameter FAILED=.

    As long as this value is not reached, the VIC makes a new attempt.

    If the objective is to ensure the VIC, a great value of this parameter is preferable (in practice 3 is sufficient).

    If the interrupt is critical, the value 1 prevents a new try.

  • When a batch, an active BMP, or a long duration DB2 lock is detected at the level of the look step of a VIC, the VIC waits if this actor is updating one of the databases concerned with the VIC.

    The wait time is set by the parameter WAIT=. After this time, an examination is made to find out if the locking cause is still present.

    If it is not, the VIC restarts at the beginning.

    Otherwise, the wait cycle is resumed. The total number of successive wait cycles is set by the parameter RETRY=. Thus, WAIT * RETRY gives the total locking time of a batch (or a BMP) accepted for this VIC. This potential wait of a VIC step automatically absorbs all operational delay. It does not imply user constraint because the activity of databases is not interrupted during the look step.

  • If DB2 tablespaces are selected, the function issues a standard DB2 QUIESCE. When the number of tablespaces is important, since the QUIESCE supports a limited number of tablespaces (approximately 240), the function can execute several QUIESCE of 200 tablespaces each.

Competing for Access to IMS Databases involved in the VIC Processing​

CS1VIC searches if BMPs in update are running on IMS databases required for the VIC point. If any, the function waits for the end of these. If none, the function issues the command /DBD for all databases participating in the VIC point, then verifies the good execution of the command.

The function records the timestamp and restarts databases by issuing the command /START. This command may be refused by IMS if a BMP fetch has already started.

This is why CS1VIC verifies the good execution of the command /START and issues it again in case of non-reply by IMS. The restart of the command /START is set by the parameter FAILED. As long as the value is not reached, the function tries to restart databases. When the value is reached and the databases are not activated, the function CS1VIC abends (abend 4001).

Using Virtual Image Copies for Recovery on the Backup Site​

A VIC point can be associated with a switch of the IMS log and of the DB2 log (from V2R3 on); this is useful in view of a transfer of all objects of recovery to another site.

In this case (ARCHLOG=Y), the function performs an unconditional switch of OLDS (whether or not it contains updates on selected databases), without waiting for the end of the archiving job, and executes the DB2 -ARCHIVE LOG MODE(QUIESCE) command.

Accessing the DB2 Catalog​

The ACCESS= parameter in parmlib member DB2IDS or in the command specifies whether the DB2 catalog should be read through SQL statements (ACCESS=SQL) or through direct VSAM access (ACCESS=FAST or QFAST), with a QUIESCE beforehand of those tablespaces in the DB2 catalog concerned by the statement (ACCESS=QFAST) or without this QUIESCE (ACCESS=FAST). Direct access to the catalog (FAST or QFAST) is advised if SQL performance when reading the DB2 catalog are poor; VSAMCAT parameter in parmlib member DB2IDS should then be correctly set.

CS1RECOV - Recovery

Purpose​

The CS1RECOV function executes the recovery of one or more databases (IMS databases or DB2 tablespaces). It is a synchronous function, dependent of applications scheduling.

IMS databases to restore are found in the DBRC RECON dataset and tablespaces in the DB2 catalog according to the provided criteria.

Function CS1RECOV allows the physical restoration (entire), and, in the IMS framework, the recovery to an approximate timestamp with automatic search of a valid point of recovery for the set of databases.

CS1RECOV also allows to return to VIC points set by the operator. In that case, the function searches the VIC-RECON dataset for the timestamp - and RBA with DB2- of the VIC point mentioned, then determines the recovery strategy from information in the DBRC RECON dataset, the DB2 catalog, the MVS catalog, and VIC-RECONs. Only those databases (or tablespaces) that have been updated since the VIC point was taken will be restored (DB2 tablespaces are always restored).

CS1RECOV also considers the indexes of DB2 tablespaces. A recover at VIC point systematically leads to a rebuild of the indexes. From DB2 Version 6 and above (allowing the processing of image copies for indexes), CS1RECOV can perform a recover processing of indexes that are provided with image copies and that are not necessarily related to tablespaces (to be recovered).

The function builds the recovery JCL from an ISPF skeleton, either CSSRECOV or CSSRECFR (for IMS) and an XPROC procedure, CSRRECOV (for DB2).

The use of generic criteria develops recovery orders that are simple and supportive of the evolution of applications. Their use is encouraged by the fact that the CS1RECOV function can alone establish the list of databases and tablespaces that participated in the VIC point specified (see the special value "VIC" for parameters DB= and TS=). This automatic mode makes it easy to integrate this function in the application chain.

It is, therefore, the main tool justifying the installation of recovery mechanisms. It lets the operator easily repair databases by canceling periods of erroneous operation, if necessary.

Syntax​

The variables to execute the CS1RECOV function are listed below.

The user can request the modification of default values of the function by modifying the member CS1RECOV of the parmlib.



* comment
DB=(criterion,.), DB search criterion or \...
DBDSGRP=dbdsgrp, \... DBDS group criterion
TS=(criterion,.), TS search criterion
EXTS=(criterion,..), EXTS exclusion criteria
IX=(criterion,.), IX search criterion
ID=id, id of the VIC point (how far to do the
* recovery
TIMESTAMP=yyqqqhhmmssthmiju\[offset\],
* timestamp (how far to do the recovery)
TEST=Y/N, print (Y, default) or submit (N) of the
* generated JCL
DBSET=dbset, database search restriction (SQL syntax).
AUTHID=authid, creator search restriction (SQL syntax).
DSSEL=dssel, selection of TS partitions
FORCE=Y/N/DL1/DB2 to force or not the recovery
* on the DBs that have not been
* updated since the last recovery
FORCERN=Y/N to force or not the recovery
* on the DBs having the flag
* \"recovery needed\"
FORCERP=Y/N to force or not the recovery
* on the TSs that are in the
* \"recovery pending\" status
IXALL=Y/N, recover or not all indexes (even in
* case of physical recover of ts)
RECOVIX=Y/N, perform RECOVER INDEX if possible
NONRECOV=Y/N, process or not a user skeleton for
* updated since the last recovery
HALDB=Y/N, include or not the HALDB databases for
* processing
SECLOG=Y/N, use or not the secondary logs of IMS
SECIC=Y/N, use or not the secondary ICs of IMS
DISPLAY=Y/N, display or not the result of the
* search
FLUSH=Y/N, stop or not the processing in case
* of an error
DLIABEND=, suppress abended BATCHs if DELETE
ICSITE=L/R/C, recover with image copy of specified site
SKELETON=skeleton, skeleton name
CLIST=clist, clist to use
PROC=proc, name of the XPROC procedure used
LDSU=ldsu, allocation unit of the new LDS
LDSP=ldsp, primary allocation
LDSS=ldss, secondary allocation
CAU=cau, allocation unit of the new CAs
CAP=cap, primary allocation of the new CAs
CAS=cas, secondary allocation
WRKU=wrku, allocation unit of work files
WRKP=wrkp, primary allocation of work files
WRKS=wrks, secondary allocation
DFSVSM=dfsvsm, member DFSVSAMP of the IMS proclib to use
*


ICTUNIT=ictunit, unit of tape ICs non cataloged
LGTUNIT=lgtunit, unit of tape LOGs non cataloged
UICHS=Y/N, high speed UIC indicator
EVENT=, event of a job management system
AUTO=Y/N, automatic option for /DBR and archive
NOTP=notp, option notp AOP: C/R/W
* the following options are used if
* AUTO=Y :
WAIT=wait, wait when DB in use
RETRY=retry, number of tests when DB in use
MSG=Y/N, sending out a WAIT message
WTO=N/N, sending out a WAIT WTO
DBRTIME=dbrtime, time for the execution of all the
* /DBR
RWAIT=rwait, wait for the IMS answer
ARCTIME=arctime, time for execution of all the
* archives
FAILED=failed, number of tries when unsuccessful
*
AMSLIB=amslib, dsname of the libr. which contains the
* AMS delete/define of DBs
Uservariable=, any user variable like=\"\...\" a title
*
* comment
*
DB=(criterion,.), next set of parameters
\...

Specific DL1 parameters​

{wrapper="1" role="DL"}

  • DB= (criterion,.)

    DB= specifies the set of databases on which to do the recovery in the case when DBDSGRP is not mentioned. Each criterion can be either specific or generic.

    The HALDB databases (dbmaster and/or partition) are also included for processing except if the parameter HALDB(N) is specified.

    The special value DB=VIC specifies that the list of databases that are to be recovered must be established from information in CS1RECON describing the relevant VIC point (indicated through ID= and TIMESTAMP= parameters): bases to restore are bases that participated in this VIC point.

  • DBDSGRP=dbdsgrp

    DBDSGRP= specifies the set of databases on which to do the recovery as the set of databases associated to the DBDS group mentioned; if DBDSGRP parameter is specified, the DB parameter is ignored.

  • NONRECOV=Y/N

    NONRECOV= specifies whether non-recoverable databases must also be processed. If NONRECOV=Y is specified, non-recoverable databases will be described in the three ISPF tables TDBNRV, TDSNRV and TINDX, which can be used in a file tailoring of user skeleton CSSRCVNR.

    Default parameter: N

  • HALDB=Y/N

    Specifies if the processing must include (Y) or not include (N) HALDB databases of IMS Version 7 (when performing a generic research on the name of the dbmaster or the name of the partition)

    Default parameter: Y

  • SECLOG=Y/N

    this parameter is used to specify that the recover is to be performed using the secondary logs of IMS. Default parameter: N

  • SECIC=Y/N

    this parameter is used to specify that the recover is to be performed using the secondary ICs of IMS. Default parameter: N

  • REUSEIC=Y/N

    • Y: allows the use of an IC to perform many RECOV.

    • N: an IC is usable only one time. If many RECOV are performed on the same TIMESTAMP, the upcoming RECOV use previous IC with a LOG application.

  • DLIABEND= /DELETE

    If DLIABEND=DELETE is specified, the recovery job generated will include a step performing a control of all subsystems referenced by DBRC and a deletion of those abended batchs records for which all authorized databases have been restored to a point preceding the abend.

    Default parameter: blank

  • FORCERN=Y/N

    In the event of a return to the VIC point or to the given timestamp, this parameter is used to force the recovery of those DL1 data bases that are in a "recovery needed" status even though there were no modifications notified by DBRC. This parameter is ignored if FORCE=Y or DL1.

    Default parameter : N

  • LGTUNIT=lgtunit

    LGTUNIT= is the allocation unit of the LOGs tapes that are not systematically catalogued. When this parameter is set to blank that means that the secondary LOGs are always catalogued. Default parameter: blank

  • LDSU=ldsu

    LDSU= is the allocation unit of the new LDS created for executing the recovery. Default parameter: TRK

  • LDSP=ldsp

    LDSP= is the primary allocation in the unit mentioned above. Default parameter: 100

  • LDSS=ldss

    LDSS= is the secondary allocation in the unit mentioned above. Default parameter: 300

  • CAU=cau

    CAU= is the allocation unit of the new CAs created for executing the recovery. Default parameter: TRK

  • CAP=cap

    CAP= is the primary allocation in the unit mentioned above. Default parameter: 50

  • CAS=cas

    CAS= is the secondary allocation in the unit mentioned above. Default parameter: 150

  • DFSVSM=dfsvsm

    DFSVSM= requests the use of a specific member DFSVSAMP to control the buffering during the recovery activities. Default parameter: DFSVSM00

  • UICHS=Y/N

    UICHS= regroups the UIC reloads (see complements); Default parameter: Y

  • NOTP=notp

    NOTP= controls the execution of the automatic operator when the IMS TP is not active (see: CS1AOP - Automatic Operator).

    Default parameter: &NOTP &NOTP means that it is necessary to take the value indicated as a parameter of CSXEXEC.

  • DBRTIME=dbrtime

    DBRTIME= is the maximum time in seconds for the execution of all the /DBR used for executing the recovery. Default parameter: 120

  • ARCTIME=arctime

    ARCTIME= is the maximum time for the execution of all the archives (see complements). Default parameter: 1800

  • AMSLIB=amslib

    AMSLIB= is the dsname of the library that contains AMS statements (delete/define) for VSAM DBs in case where they must be specified (see complements). The library contains one member by database; the member name is the DBD name of the corresponding database.

    Default parameter: blank

Specific DB2 parameters​

{wrapper="1" role="DL"}

  • TS=(criterion,..)

    TS= specifies a list of tablespace names patterns. Tablespaces referenced in the DB2 catalog whose name matches one of the patterns are included in the list of tablespaces on which the requested function is to be performed.

    Precisely:

    • A name pattern means a generic name according to SQL LIKE syntax: special characters are the percent sign % and the underscore sign _; additionally, an asterisk * is transformed into a % sign.

    • For a pattern in the form dbname.tsname, tablespaces selected are those whose database name matches the dbname pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

    • For a pattern in the form tsname, tablespaces selected are those whose database name matches the DBSET pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

    • If TS=CATALOG is specified, the function will be performed on catalog tablespaces.

    • If TS=% or TS=* is specified, no catalog tablespace will be selected.

The database name often occurs as the first index column on catalog tables read by the function. Therefore, better performance in reading from the DB2 catalog will be achieved if the database name pattern is specified with as much precision as possible, either through the DBSET parameter, or through the qualifier in a list item of the form dbname.tsname.

The special value TS=VIC specifies that the list of tablespaces that are to be recovered must be established from information in CS2RECON describing the relevant VIC point (indicated through ID= and TIMESTAMP= parameters): tablespaces to restore are those that participated in this VIC point.

  • EXTS=(criterion,.)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • IX=(criterion,...

    Specifies a list of indexspaces to be saved. The IX parameter works exactly the the same way as the TS parameter but only for indexes defined in COPY=Y in the DB2 catalog.

  • DBSET=dbset

    DBSET= is used as a default dbname pattern for each item in the list TS= in the form tsname; see the description of TS= parameter. Default parameter: %

  • AUTHID=authid

    AUTHID= is used as a creator's name pattern for each item in the list TS=; see the description of TS= parameter. Default parameter: %

  • DSSEL=dssel

    DSSEL= indicates that the recovery has to cover the specified partition of the partitioned tablespaces and also the non-partitioned tablespaces that were selected for this processing.

    This parameter is accepted for the physical and applicative recovery (the name of the VIC point is provided).

    Default parameter: ALL

  • ICSITE=L/R/C

    This parameter is only available from DB2 version 4 and above, it is used to specify that the recover is to be performed with the image copies of the specified site. L = Localsite, R = Recoverysite, C = Current site. Default parameter: C

  • FORCERP=Y/N

    in the event of a return to the VIC point, this parameter is used to force the recovery of those tablespaces that are in a "recovery pending" status even though there were no modifications. This parameter is ignored if FORCE=Y or DB2. Default parameter: N

  • IXALL=Y/N

    This parameter is taken into account in case of a physical recovery, meaning that neither the TIMESTAMP parameter nor the ID parameter were specified in the CS1RECOV command.

    It is used to request the recovery of all indexes in addition to the recovery of the tablespaces.

    note

:

The indexes are always recovered when performing an applicative recovery (ID and/or TIMESTAMP) or if TS=CATALOG has been specified.

Default parameter: N

  • RECOVIX=Y/N

    Requires the RECOVERY of the indexes instead of REBUILDing them if this is possible (Indexspaces defined as COPY=N regarding the DB2 catalog).

    Default parameter: N Parameters common to IMS and DB2

  • TSSET=Y/N

    [allows the inclusion of all tablespaces (obtained by treating the TS and EXTS parameters) that fulfill the reference integrity requirements: all tablespaces with a table linked by a reference integrity constraint to a tablespace table in the defined list are added to the list.

    • Y: research of the tablespace set for the referential integrity constraint.

    • N: Do not search this tablespace set.

    Default parameter: N

    note

:

The relations with the LOBS or XML or historical tablespaces are not taken into consideration through this parameter, but through the AUXTS parameter.

  • AUXTS=WITHBASE/INLIST

    Indicates how auxiliary tablespaces (LOB, XML or historical) to include in the treatment are designated:

    • WITHBASE: the auxiliary tablespace are implicitly designated through the base tablespace name they depend. All LOB, XML or historical tablespace depending from a base tablespace designated with TS parameter (excepting the ones which names corresponds to EXTS criterion) is treated.

      note

:

In this case, the TS parameter only indicates the base tablespaces names.

  • INLIST: the auxiliary tablespaces are directly defined by their name through the TS parameter. All auxiliary tablespaces which correspond to the name criteria indicated by the TS parameter are processed.

    note

:

In this case, the TS parameter indifferently designates base tablespaces or LOBs or XML tablespaces. If the list defines both a base tablespace and some of its auxiliaries, they are nevertheless individually processed..

Default parameter: WITHBASE

  • CLONE=A/N/Y/B

    • N (No): only the 'BASE' instance is processed.

    • Y (Yes): only the 'CLONE' instance is processed.

    • B (Both): both 'BASE' and 'CLONE' instances are processed.

    • A (Any): If a VIC point is required, process the required instance, that may be different for each tablespace (both instances may also be required for one tablespace).

    Default parameter: A

    note

:

  • If CLONE=B is required and the VIC point contains only one instance for a tablespace, the standard error concerning the request for a tablespace external to the VIC point will be generated.

  • CLONE=N is the only possible value if TS=CATALOG.

Common parameters to DL1 and DB2​

  • ID=id

    The ID parameter identifies the VIC point to return to. This VIC point must have been created during a previous execution of the CS1VIC function. Default parameter: NONE

  • TIMESTAMP=yyqqqhhmmssthmiju[offset]

    TIMESTAMP= is the date and the hour for which to perform the recovery.

    If ID is present, TIMESTAMP specifies the ID to return to(see example).

    If ID is absent and the default value below is specified, it indicates a physical recovery.

    If ID is absent and TIMESTAMP is different from the default, there is, in IMS, a search of the nearest point of admissible recovery to this timestamp. In DB2, this combination is rejected.

    The century is automatically determined so that the specified TIMESTAMP belongs to a range starting 70 years before and 29 years after the current date.

    The offset indicates the time difference from local time. The default time is the time difference from local time of the used system. The offset is coded in the forms of ±hh:mm in the time slot -11:45 to +14:45,the mm permitted values are: - 00

    • 15 - 30 - 45 -

    Default parameter: 993692359599

  • FORCE=Y/N/DL1/DB2

    FORCE= forces the recovery of DBs and/or TSs that have not been updated since the last recovery (case of erroneous recovery). Values Y or N are for both DB2 and IMS.

    DL1 means that recovery is to be forced for IMS databases only, DB2 means that recovery is to be forced for DB2 tablespaces only,

    Default parameter: N

  • DISPLAY=Y/N

    DISPLAY= lists on SYSOUT the selected databases and tablespaces. Default parameter: N

  • FLUSH=Y/N

    FLUSH=Y stops the processing in case of a problem. Default parameter: N

  • SKELETON=skeleton

    SKELETON= is the name of the standard skeleton attached to the function. It specifies a user skeleton.

    The CSSRECOV skeleton executes the recovery without DBRC.

    The CSSRECFR skeleton executes the recovery under DBRC; this skeleton is mandatory in case of a recovery of databases using concurrent image copies 2. Default value:

    • CSSRECOV, if DBRCFORC=N indicated in IMSIDS

    • CSSRECFR, if DBRCFORC=Y indicated in IMSIDS

  • CLIST=clist

    CLIST= is the name of the standard clist attached to the function. It calls a user clist before the generation of the JCL.

    Default parameter: CSURECOV

  • PROC=proc

    PROC= is the name of the XPROC procedure attached to the function.

    Default parameter: CSRRECOV

  • WRKU=wrku

    CSRRECOV= is the unit of work file allocation used during the recovery.

    Default parameter: TRK

  • WRKP=wrkp

    WRKP= is the primary allocation in the unit mentioned above.

    Default parameter: 50

  • WRKS=wrks

    WRKS= is the secondary allocation in the unit mentioned above.

    Default parameter: 150

  • ICTUNIT=ictunit

    ICTUNIT= is a unit of allocation of non-cataloged tape ICs (TAPE,. ..). Specify the special value &TAPEGRP to require the use of the default tape unit specified in the member CUSTOM of the parmlib.

    Default parameter: &TAPEGRP

  • EVENT=

    EVENT= automatically adds, at the end of the job, a notification step to the job management system at the site of an event with the specified name. It lets the operator plan on this event.

  • AUTO=Y/N

    AUTO= makes it possible to automatically issue the command /DBR. If Y, it is possible to customize the execution of the automatic operator with the following parameters.

    Default parameter: N

  • WAIT=wait

    WAIT= is the wait time of the function when the database is in use (see AOP); Default parameter: 60

  • RETRY=retry

    RETRY= is the number of tries after unsuccessful attempt when a DB is in use (see AOP).

    Default parameter: 15

  • MSG=Y/N

    MSG= sends a message when the function begins to wait.

    Default parameter: Y

  • WTO=Y/N

    WTO= sends a message console when the function begins to wait.

    Default parameter: Y

  • RWAIT=rwait

    RWAIT= is the maximum wait time during critical sections of the automatic operator, for example, waiting for the IMS reply (see AOP).

    Default parameter: 15

  • FAILED=failed

    FAILED= is the maximum number of failures allowed for the AOP function.

    Default parameter: 3

Examples​

Recovery of the IMS database DBCLI01 to the VIC point identified by CLIBEGIN:

 DB=DBCLI01,ID=CLIBEGIN      <===... visu. of the JCL (TEST=Y)
 DB=DBCLI01,ID=CLIBEGIN,     <===... submit of the JCL (TEST=N )
    TEST=N

Physical recovery of two IMS databases DBCLI01, DBCLI02 (no parameters ID= and TIMESTAMP=).

 DB=(DBCLI01,DBCLI02)                 <===...    manual (AUTO=N)
 DB=(DBCLI01,DBCLI02),AUTO=Y     <===...      automatic (AUTO=Y)
 DB=(DBCLI01,DBCLI02),AUTO=Y,TEST=N  <===... with submit of JCL

Recovery of all IMS databases beginning with DBCLI before January the 7th of 1989, 19h35. A recovery point previous to this date is automatically sought for. Such a point, if it is found, must have the same properties as a VIC: all databases were in fetch only at this point.

 DB=DBCLI*,TIMESTAMP=890071935000

Recovery of all IMS databases beginning with DBCLI and all tablespaces in database DBCLIDB2 whose name begins with TSCLI to the first VIC point CLIALL found before January the 10th of 1989, 08h12 (batch example):

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //           PARM=(FUNCTION,'CS1RECOV,IMSID,'IMSE',DB2ID,'DB2E')
 //SYSIN     DD *
  DB=DBCLI*,TS=DBCLIDB2.TSCLI*,ID=CLIALL,TIMESTAMP=890100812000

Recovery of all databases beginning with DBCLI or DBPRO to the VIC CLIPRO. The size of temporary change accumulation created by the recovery is altered. Another DFSVSAMP is used:

 DB=(DBCLI*,DBPRO*),ID=CLIPRO,CAU=CYL,CAP=25,CAS=10,
 DFSVSM=DFSVSM01

Recovery to the VIC PRO04 of databases beginning with DBPRO; the name of the generated JOB as well as its execution class are forced:

 DB=(DBPRO*),ID=PRO04,JOBNAME=JRCVPRO,CLASS=R

Recovery to the VIC PRO12 of all tablespaces in database DBCLIDB2 whose name begins with TSPRO or TSCLI with an automatic call to the AOP to lock the access to tablespaces before restarting them after the recovery:

 TS=(TSCLI*,TSPRO*),DBSET=DBCLIDB2,ID=PRO12,AUTO=Y

Recovery to the VIC PRO15 of DL1 databases that participated to this VIC and of tablespaces beginning with TSPRA (a subset of the set of tablespaces that participated in VIC PRO15):

 DB=VIC,TS=TSPRA*,ID=PRO15

Complements​

If you do the recovery in manual mode, you have to induce an archiving of non-archived IMS updates for two reasons:

  • On the one hand, if a necessary archiving is not done (/DBR DB NOFEOV), it is possible to have the following situation: The current OLDS contains updates concerning periods before and after recovery. The archiving of this OLDS leads to an aberration.

  • The second reason is, although it is possible for archived updates to be canceled by the recovery, storing them correctly allows to cancel the recovery, if needed, by a recovery of the recovery (thus returning to the initial situation).

The option AUTO=Y allows the automatic recovery, i.e., the deallocation TP of databases, the archiving of non-archived updates if necessary, and the construction of the recovery JCL, including the TP restarting of databases.

A delete/define is automatically generated before the recovery step for each database unless the user indicates, through parameter AMSLIB=, a library containing one member of the database containing the AMS (delete/define) of this database. In the case of IMS UIC (Faver), the delete/define is useless.

Adjustments of timing are identical to those of the VIC. The parameters DBRTIME= and ARCTIME= are the maximum durations allocated respectively to the deallocation of databases and to the waiting for the end of the possible archiving job.

The CS1RECOV function never waits for a spontaneous switch and immediately forces the switch if updates must be archived. Indeed, a recovery operation means the situation is urgent and forcing is justified. As it is a very rare occurrence, there are no consequences. The DB2 tablespaces are forced in UTILITY access during the recovery and restarted at the end.

It is possible to request the roundup of the reloads IMS UIC (FAVER) through the option UICHS=Y (High Speed).

The CS1RECOV function is specially designed to automatically solve backup problems. Indeed, INFO-RECOVERY in general creates DUAL objects (ICs, UICs, FICs, IICs, CAs, etc. ..) and, in absence of a necessary object, tries to use an equivalent object (see Nomenclature Convention).

From DB2 V2R3 on, the CS1RECOV function can use all the image copies referenced in the DB2 catalog. According to the parameter SITETYPE specified in the member DB2IDS of the parmlib, the CS1RECOV function chooses an image copy corresponding to the type of the DB2 site: LOCAL or RECOVERY. In case of absence of a primary image copy (uncataloged file), the function will take into account the secondary image copy, if it is cataloged.

The CS1RECOV function can apply an optimization to the level of the choice of ICs, UICs, or CAs, according to the value of the parameter OPTIMIZE (Y/N) indicated in the member IMSIDS. The optimization can lead to the use of objects created after the recovery date. Indeed, if a IC, UIC, or CA represents the state of a database required for the recovery, it is given priority. For example, suppose that a database has been saved Monday evening, modified Tuesday and saved Thursday at mid-day.

If, on Friday, we request a recovery to Tuesday evening, it would be better to use the Thursday's backup if no modification had been done between Tuesday evening and Thursday. Generally, it is highly recommended to use the CS1MAP function to see what the RECOV function suggests.

The recovery is notified to DBRC. Also it is taken into account if a new recovery request is performed. Furthermore, a recovery request at a timestamp a little bit inferior to the execution timestamp of a preceding recovery cancels the latter. It is called a recovery of the recovery.

If a recovery is performed, it is necessary to stop the activity of change accumulation on affected databases until the next image copy and to make an FIC on DB2 tablespaces that have been restored.

These restrictions are respectively linked to DBRC (for more information, consult DBRC Guide and Reference, section Restriction on Using the Change Accumulation Utility) and DB2 (DB2 Command and Utility Reference).

If the recovery is managed manually, it is important to take into account these orders. To be sure they are well respected and to be able to use the recovery in applicative chains, it is necessary on the one hand to condition the planning of CAs on the non-post of a recovery event for the involved application.

This event can be used to start a reserved job of ICs, planned in a way that it does not constrain users. The end of this job conditions then the purge of the event locking the CAs. On the other hand, a recovery step should be followed by a FIC step on restored tablespaces (see the description of CS1FIC in the InfoRec2 documentation

  • HR102).

Recovery and Automation​

The CS1RECOV function automatically includes the recovery of databases.

It also includes the deallocation of databases of the TP, a possible archiving of modifications on these databases still in OLDS of the TP, and the generation of the recovery JCL, including the restarting of databases in the TP.

It is thus conceivable to anticipate steps of recovery conditioned on an anomaly in application chains. These steps will serve as automatic repairers, always leaving the databases in good shape.

It is possible also, as the operation is synchronous, to consider a "minimum service" chain instead of the chain in error.

If we go back to the case study seen in chapter CS1VIC, this can be implemented in the following way:

 JCLIC
   CS0  Step VIC, DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLICS0
   CS1  Step update DBCLIA
   CSR  Step RECOV,COND="CS1 invalidation detection",
                     DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLICS0
   CS2  Step editing DBCLIA, DBCLIB
 JCLIP
   PS0  Step VIC, DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLIPS0
   PS1  Step update DBCLIB, fetch DBCLIA
   PSR  Step RECOV,COND="PS1 invalidation detection",
                     DB=DBCLI*,TS=*,DBSET=DBCLI%,ID=VCLIPS0

When recovering partitioned IMS databases (HALDB using IMS Version 7), the CS1RECOV function automatically generates, after the recovery of the data files, the Rebuild of the primary index and of the ILDS data files.

Generating JCL​

The CS1RECOV function gets all necessary information for the recovery from the RECON dataset of DBRC and the DB2 catalog.

The VIC RECON (one for each IMS and for each DB2) is used only to obtain the relationship between the VIC id, the timestamp, and the RBA.

The function determines the best strategy for recovery and provides the necessary information to create the recovery JCL in the form of ISPF variables and tables. These elements are described in subsequent sections.

For the IMS part, it first calls a CLIST, CSURECOV, allowing an external handling of extracted information, and then it calls a skeleton, CSSRECOV, to generate the adequate JCL.

The clist CSURECOV optimizes settings of tape volumes. It also supports IC FAVER if notified with the following user data (which is the case, in standard, with InfoRec1):

        ----5---10----
 UDATA('FAVER    UICdsname')

The clist accesses ISPF variables provided by the function by means of a VGET:

 ISPEXEC VGET (         -
               variable -
                       ) SHARED

and updates them by means of a VPUT :

It modifies or adds supplementary attributes to entries of tables (TDBDS, TCA or TLDS) by means of statements TBGET and TBPUT.

For DB2, it calls the procedure of XPROC type CSRRECOV that generates the necessary JCL from the skeleton CSSRECTS.

The JCL generated by this skeleton allocates non-DASD image copy files on entry according to the tape unit type and the number of available such tape units specified in parameters TDEVTYPE= and TDEVNUM= of parmlib member DB2IDS.

A number of tape units equals to one plus the average number of tape IICs for tablespaces to restore should be made available to INFO-RECOVERY. When there are not enough tape units to mount all IICs, DB2 RECOVER uses the log instead of the unmounted IICs.

Variables of the Recovery​

The following table describes ISPF variables created by the function CS1RECOV.

Name Lg. Pool Skeleton Description FLDB2CAT 1 shared CSSRECTS variable assigned by the function, indicates if the recovery concerns the DB2 catalog or applicative TS

FLPHYREC 1 shared CSSRECTS variable assigned by the function, physical recovery indicator

LDSTS 1 shared CSSRECOV variable assigned by the function, indicates the necessity to cut OLDS

RECOVRBA 12 shared CSSRECTS variable assigned by the function, global RBA of recovery. For the DB2 versions previous to V11, the 12 useful characters are 00000000cccccccccccc for DB2 not in Data Sharing and 00cccccccccccc000000 for the DB2 in Data Sharing.

RECOVTS 12 shared CSSRECOVCSSRECFR variable assigned by the function, global timestamp of recovery

TSFLCATL 1 shared CSSRECTS variable assigned by the function, indicates the necessity ofcataloging FIC/IICs

TSFLRENA 1 shared CSSRECTS variable assigned by the function, indicates the necessity of renamingFIC/IICs

: Variable of CS1RECOV

The ISPF Tables​

CS1RECOV builds the ISPF tables:

  • TDBDS, describing IMS databases selected with objects of recovery;

  • TCA, describing CAgroups implied in the processing

  • TLDS, describing IMS LOG files necessary for the recovery

  • TXILDS, describing ILDS/INDEX files of HALDB databases

  • TDBTS, describing selected tablespaces

  • TTSIC, describing image copies (FICs and IICs) necessary for the recovery

  • TDSN, describing the files constituting the databases

  • if non-recoverable databases are to be processed, CS1RECOV furthermore builds the following tables:

    • TDBNRV, similar in structure to TDBDS, while describing non-recoverables databases

    • TDSNRV, similar in structure to TDSN, while describing the files constituting the non-recoverables databases

    • TINDX, describing the relationship data-index for all selected databases

The TDBDS Table​

Format of a TDBDS table entry:

Name Description DBD name DBD

DDN ddname

CADATE local date stop CA format DATE (dd/mm/yyyy)

CADSN CA dsname

CAFSEQ number of sequence CA/volume

CAGRP CA group

CANVOL number of CA volumes

CAOFFS offset for CADATE-CATIME-CATS format (±hhmm)

CAPCARD card of CA purge if present for this DBDS

CATIME local hour stop CA format TIME (hh: mm:ss.d)

CATS local timestamp stop CA format TS (yyyyqqqhhmmssthmiju)

CAVOLS volumes 1 to 5 CA in the format (VVVV, VVVV, VVVV, VVVV,VVVV)

CAVOLS2 volumes 6 to 10 CA

CAVOLS3 volumes 11 to 15 CA

CAVOLS4 volumes 16 to 20 CA

DBRDATE date recovery DBDS format DATE (dd/mm/yy)

DBRTIME hour recovery DBDS format TIME (hh: mm:ss.d)

DBRTS date recovery DBDS format TS (yyqqqhhmmssd)

DBMASTER DBMASTER name (if HALDB)

DSN dsname

FLCA Y/N:indicator CA

FLLDS Y/N:indicator LDS

ICDATE local date IC format DATE (dd/mm/yy)

ICDSN dsname IC

ICFLCAT indicator cataloged IC Y/N

ICFSEQ number of sequence IC/volume

ICNVOL number of volumes IC

ICOFFS offset for ICDATE-ICTIME-ICTS format (±hhmm)

ICTIME local hour IC format TIME (hh:mm:ss.d)

ICTS local timestamp IC format TS (yyyyqqqhhmmssthmiju)

ICUIC Y/N:indicator User IC

ICUICDA data User IC

ICVOLS volumes 1 to 5 of the IC in the format (VVVV, VVVV, VVVV,VVVV, VVVV)

ICVOLS2 volumes 6 to 10 of the IC

ICVOLS3 volumes 11 to 15 of the IC

ICVOLS4 volumes 16 to 20 of the IC

REFSLDS LDS reference table name for this DBDS

REFUSE Use reference table name for this DBDS

: TDBDS table

The TCA Table​

Format of a TCA table entry:

Name Description CAGRP CA group

CADATE local stop time local CA format DATE (dd/mm/yy)

CADMYFL Y/N:CA old dummy flag

CADSN CA dsname

CAFSEQ number of sequence CA/volume

CANVOL number of volumes CA

CAOFFS offset for CADATE-CATIME-CATS format (±hhmm)

CARLDS LDS reference table for this CA

CATIME local stop time CA format TIME (hh:mm:ss.d)

CATS stop time local CA format TS (yyyyqqqhhmmssthmiju)

CAVOLS volumes 1 to 5 CA in the format (VVVV, VVVV, VVVV, VVVV,VVVV)

CAVOLS2 volumes 6 to 10 CA

CAVOLS3 volumes 11 to 15 CA

CAVOLS4 volumes 16 to 20 CA

: TCA table

The TLDS Table​

Format of a TLDS table entry:

Name Description LDSSDT ts start LDS (internal format)

LDSSSID subsystem id LDS

LDSDSN dsname LDS

LDSNVOL number of LDS volumes

LDSVOLS volumes 1 to 5 LDS in the format (VVVV, VVVV, VVVV, VVVV,VVVV)

LDSVOLS2 volumes 6 to 10 LDS

LDSVOLS3 volumes 11 to 15 LDS

LDSVOLS4 volumes 16 to 20 LDS

LDSFSEQ number of sequence LDS/volume

LDSSTS local start time LDS format TS (yyyyqqqhhmmssthmiju)

LDSSDATE local start time LDS format DATE (dd/mm/yy)

LDSSTIME local start time LDS format TIME (hh:mm:ss.d)

LDSETS local stop time LDS format TS (yyyyqqqhhmmssthmiju)

LDSEDATE stop time LDS format DATE (dd/mm/yy)

LDSETIME local stop time LDS format TIME (hh:mm:ss.d)

LDSSEOFFS offset for LDSEDATE-LDSETIME-LDSETS format (±hhmm)

LDSTFL Y/N:LDS must be truncated by CS1LDSTS

LDSTSEQ number identifying a truncated LDS

: Table TLDS

The TXILDS Table​

Format of a TXILDS table entry:

Name Description DBD name DBD (name of the partition)

DDN ddname

DBMASTER name of the dbmaster

DBPARTYP ILE/INDX specifies the type of the ILDS data file or the primary index

DSN dsname

: Table TXILDS

The TDBTS/TDBIX Tables​

Format of a TDBTS/TDBIX table entry:

Name Description DBNAME Database name

TSNAME Tablespace/Indexspace name

CREATOR Creator name

: Tables TDBTS/TDBIX

The TTSIC/TIXIC Tables​

Format of a table entry TTSIC/TIXIC:

DBNAME Database name TSNAME Tablespace name

DSNUM file or partition number

ICDATE time IC format DATE (dd/mm/yy)

ICTIME time IC format TIME (hh:mm:ss.d)

ICDSN dsname IC

TSCLONE existence (Y) or (N) of cloned objects

TSINSTAN instance of base object

ICLOGGED object updates are written in the LOG (Y) or aren't (N)

ICFLCAT indicator cataloged IC Y/N

ICFLSEC IC secondary flag Y/N

ICFLTAPE indicator tape IC Y/N

ICFSEQ number of sequence IC/volume

ICFVOL first volume IC

ICNVOL number of volumes IC

ICSDSN dsname of the secondary image copy

ICTYPE type of the image copy F/I

ICBACKUP code of the image copy, set from V2R3 on

ICUNIT IC unit

ICVOLS volumes 1 to 5 IC in the format (VVVV, VVVV, VVVV, VVVV,VVVV)

ICVOLS2 volumes 6 to 10 IC

ICVOLS3 volumes 11 to 15 IC

ICVOLS4 volumes 16 to 20 IC

: TTSIC/TIXIC Tables

The TDSN Table​

Format of a table entry TDSN:

Name Description DSN dataset name

DSVOL dataset volume

DSALCP primary allocation

DSALCS secondary allocation

DSALCUN allocation space unit BLK/TRK/CYL

DSBLKSZ blksize (0 if recfm unknown)

DSBUSED number of blocks used

DSCC control character A/M or ? (Ansi/Machine)

DSCDATE creation date (dd/mm/yy)

DSCTIME creation time (hh:mm:ss.d)

DSCTS creation timestamp (yyqqqhhmmssd)

DSCUSED number of cylinders used

DSCZT creation timestamp in ZT format (yymmddhhmmssd)

DSDATA data component dataset name

DSDCISZ data component CI size

DSDGSHR data component systems share option

DSDLSHR data component regions share option

DSDPSP data component primary allocation

DSDRESZ data component maximum record size

DSDSSP data component secondary allocation

DSDUSP data component allocation space unit BLK/TRK/CYL

DSDVOLS data component volumes

DSEXTCT number of extents

DSFLBLK blocked records indicator (Y/N)

DSFLDER erase option for data component indicator (Y/N)

DSFLDOR ordered option for data component indicator (Y/N)

DSFLDPA spanned records in data component indicator (Y/N)

DSFLDRE reuse option for data component indicator (Y/N)

DSFLDSP speed or recovery option for data component indicator (Y/N)

DSFLDUN unique or suballocation option for data component indicator (Y/N)

DSFLDWC writecheck option for data component indicator (Y/N)

DSFLEMP empty file indicator (Y/N)

DSFLIDX index component indicator (Y/N)

DSFLIIM imbed option for index component indicator (Y/N)

DSFLIOR ordered option for index component indicator (Y/N)

DSFLIRE reuse option for index component indicator (Y/N)

DSFLIRP replicate option for index component indicator (Y/N)

DSFLIUN unique or suballocation option for index component indicator (Y/N)

DSFLIWC writecheck option for index component indicator (Y/N)

DSFLSPA spanned records indicator (Y/N)

DSFRECA freespace per CA

DSFRECI freespace per CI

DSICISZ index component CI size

DSIGSHR index component systems share option

DSILKEY key length

DSILSHR index component regions share option

DSINDEX index component dataset name

DSIOKEY key offset in a record

DSIPSP index component primary allocation

DSISSP index component secondary allocation

DSIUSP index component allocation space unit BLK/TRK/CYL

DSIVOLS index component volumes

DSLRECL lrecl (0 if recfm unknown)

DSORG dataset organization VS/PS/PO/DA/IS (Vsam/Seq./Pds/Dir.Acc./Isam)

DSRDATE date of last access to dataset (dd/mm/yy)

DSRECFM recfm du fichier F/V/U or ? si inconnu

DSRTIME time of last access to dataset (hh:mm:ss.d)

DSRTS timestamp of last access to dataset (yyqqqhhmmssd)

DSRZT timestamp of last access to dataset (yymmddhhmmssd)

DSTUSED number of tracks used

DSULREF user who last accessed the dataset

DSUNIT volume unit type

DSXDATE expiration date (dd/mm/yy)

DSXTIME expiration time (hh:mm:ss.d)

DSXTS expiration timestamp (yyqqqhhmmssd)

DSXZT expiration timestamp (yymmddhhmmssd)

: TDSN table

The TINDX Table​

Format of a TINDX table entry:

Name Description DBINDX database name

DDNAME file ddname

DBDATA name of the data base

DBITYPE DBINDX database type (D-data or P-primary index or S-secondary index)

DSNAME dsname corresponding to DDNAME

FLNRCV flag: DBINDX is recoverable Y/N

: Table TINDX

CS1CHECK

Purpose​

The CS1CHECK function is used to check referential integrity of data after a recovery at the previous checkpoint, of tablespaces that belong to a whole regarding referential integrity.

This function is synchronous and depends on the applications planning. It should be executed immediately after the recovery of the tablespaces at the VIC point.

Inserting the CS1CHECK function into JCL will limit data loss due to an automatic transfer into a CHECK PENDING status of all non-recovered tablespaces but that are related to recovered tablespaces for referential integrity reasons.

The CS1CHECK function as the CS1RECOV function rebuilds the list of tablespaces that have participated to the VIC point.

It also allows the user to determine the list of tablespaces (if TSSET=Y) that are related to a certain tablespace (recovered) by referential integrity rules.

The CS1CHECK function generates the CHECK JCL using the XPROC: CSRCHECK procedure.

When systematically executing this function being implemented in the recovery mechanism, the tablespaces that successfully were checked will automatically be accessible to other applications with an exact list of all detected abnormalities.

Syntax​

The CS1CHECK function is only available for a DB2 environment.

The variables used to execute the CS1CHECK function are described below.

The user may modify the default values in the CS1CHECK member of the parmlib.



* comment
TS=(criterion.), TS search criterion
EXTS=(criterion,..), EXTS exclusion criteria
ID=id, VIC point id
TIMESTAMP=yyqqqhhmmssthmiju\[offset\],
* to identify the VIC point
DBSET=dbset, search criterion of database
AUTHID=authid, search criterion of creator
TSSET=Y/N, extent or not the selection to
* complete tablespace sets
DISPLAY=Y/N, display the search result or not
*
AUXTS=WITHBASE/INLIST, includes or not LOBs, XML and
* historical table space in the treatment
TEST=Y/N, print (Y, def) or submit (N) of the
* generated JCL
PROC=proc, name of the XPROC procedure used
WRKU=wrku, allocation unit of work files
WRKP=wrkp, primary allocation of work files
WRKS=wrks, secondary allocation
\...

Parameters Description​

  • TS= (criterion,...)

    specifies a list of tablespace name models. The tablespaces from the DB2 catalog and which names correspond to one of these models are included into the selection of tablespaces where the requested function is to be executed.

    That means:

    • A model name is a generic name according to the LIKE SQL syntax; the special characters are the percentage % and the underline _; furthermore the asterisk * is translated to percentage %.

    • A model from the list like dbname.tsname allows the selection of tablespaces where the name of the database corresponds to the dbname model, the name of the tablespace corresponds to the tsname model, and the name of the creator corresponds to the AUTHID model.

    • A model from the list like tsname allows the selection of tablespaces where the name of the database corresponds to the DBSET model, the name of the tablespace corresponds to the tsname model and the name of the creator corresponds to the AUTHID model.

    • The value "CATALOG" is not supported.

    • If TS=% or TS=* is specified, no catalog tablespace will be selected.

Most of the times the database name is the first index column on the catalog tables that are read by the function.

Therefore, better performance in reading the DB2 catalog can be reached if the name of the database is specified as precisely as possible, either using the DBSET parameter or using the qualifier inside an element of the list like dbname.tsname

The special value TS=VIC allows the user to specify that the list of tablespaces to be recovered must correspond to all tablespaces that have participated to the VIC point defined by the ID and TIMESTAMP parameters; this list will be rebuild using stored information from the CS2RECON file.

{wrapper="1" role="DL"}

  • EXTS=(criterion,.)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • EXTS=(criterion,.)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • ID=id

    allows the identification of the mentioned VIC point (if TS=VIC) to relocate all the tablespaces that have participated at this VIC point.

    Default parameter: none.

  • TIMESTAMP=yyqqqhhmmssthmiju[offset]

    refers to the date and time which we want to perform the recovery;

    if ID is present, TIMESTAMP allows to precise the ID in which to return (see example);

    if ID is absent and the default value below is mentioned, a physical recovery is indicated.

    if ID is absent and TIMESTAMP is different from the default value, there is in DL1 a research of an eligible recovery point which is also the closest to this timestamp; in DB2, this combination is rejected. The TIMESTAMP parameter can be precised til the millionth of a second. l

    The year is entered with the two last digits. The century is determined so that the year is integrated in a sliding window, between 70 years before and 29 years after the current year.

    If the 17 characters of the parameter are not all entered, this one is completed by zeros at the right of the parameter.

    The offset indicates the time lag from local time. By default, it is the time lag from the local time of the system used. The offset is coded under the form ±hh:mm, within the slot -11:45 to +14:45, mm permitted values are: l - 00 - 15 - 30 - 45​

    Default parameter: 59365235959999999

  • DBSET=dbset

    DBSET= is the generic name of the database that is used in addition to the TS= list; refer to the TS parameter description.

    Default parameter: %

  • AUTHID=authid

    AUTHID= is the generic name of the creator that is used for the selection in addition to the TS= list;

    Default parameter: %

  • TSSET=Y/N

    allows the user to extend the selection of obtained tablespaces to a whole set of tablespaces regarding referential integrity: any tablespace having a table that is related by a referential integrity condition to a table of a tablespace on the list will be added to the list.

    The TSSET=Y parameter is used to ensure that the CHECK DATA applies to tablespace sets.

    Default parameter: N

    note

:

The relation with the LOBS and XML auxiliary table spaces and the historical table spaces are not taken into consideration through this parameter, but through the AUXTS parameter.

  • DISPLAY=Y/N

    to specify in the SYSOUT the selected databases and tablespaces.

    Default parameter: N

  • AUXTS=WITHBASE/INLIST

    indicates how auxiliary tablespaces (LOB, XML or historical table spaces) to include in the treatment are designated:

    • WITHBASE: the auxiliary tablespace are implicitly designated through the base tablespace name they depend. All LOB, XML or historical tablespace depending from a base tablespace designated with TS parameter (excepting the ones which names corresponds to EXTS criterion) is treated. In this case, the TS parameter only indicates the names of base tablespaces.

    • INLIST: the auxiliary tablespaces are directly defined by their name through the TS parameter. All auxiliary tablespaces which correspond to the name criteria indicated by the TS parameter are processed.

      In this case, the TS parameter indifferently designates base tablespaces or LOBs or XML tablespaces. If the list defines both a base tablespace and some of its auxiliaries, they are nevertheless individually processed..

  • TEST=Y/N

    this parameter is used to print (TEST=Y) or to submit (TEST=N) the generated JCL.

  • PROC=proc

    name of the XPROC procedure associated to the function; Default parameter: CSRCHECK

  • WRKU=wrku

    allocation unit for work files (DB2) used by the CHECK DATA; Default parameter: TRK

  • WRKP=wrkp

    primary allocation for work files (DB2) expressed in the unit given by WRKU; Default parameter: 50

  • WRKS=wrks

    secondary allocation for work files (DB2) expressed in the unit given by WRKU; Default parameter: 150

Examples​

  • Referential integrity check of all data related to the data of the tablespace DBCLIENT that was just recovered (batch example):

     //C1   EXEC  PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
     //         PARM=(FUNCTION,'CS1CHECK',DB2ID,'DB2E')
     //SYSIN  DD*
         TS=DBCLIENT,TSSET=Y

  • Check of all tablespaces which tables are related by referential integrity conditions to a table of a tablespace participating to the last VIC point PRO12 that was found prior to January 10th 1998, 08h15 (batch example):

     //S1   EXEC  PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
     //         PARM=(FUNCTION,'CS1CHECK',DB2ID,'DB2E')
     //SYSIN  DD*
         TS=VIC,TSSET=Y,ID=PRO12,TIMESTAMP=98010015000

  • Consistency check of data related to data of all tablespaces of the VIC point INF05:

     TS=VIC,ID=INF05,TSSET=Y

The ISPF Table​

The CS1CHECK function builds the ISPF table:

  • TDBTS, describing the selected tablespaces;

The TDBTS/TDBIX Tables​

Entry in the TDBTS/TDBIX tables:

Name Description DBNAME name of the database

TSNAME name of the tablespace/indexspace

CREATOR name of the creator

: TDBTS/TDBIX Tables

CS1MAP - Recovery Map

Purpose​

The MAP function makes it possible to verify that recovery mechanisms are installed in accordance with recovery objectives set by the operator. It presents, in the form of a recovery map, a bird's eye view of operations over a certain period of time with regard to a given objective and one or more databases (IMS bases or DB2 tablespaces). It is an asynchronous function, independent of applications scheduling.

It identifies databases which do not meet the objective that has been set. This objective is the maximum amount of potentially wasted operations time, e.g., 12 hours. This means that, whatever the case, possible recoveries would have limited any loss of work to a maximum of 12 hours for all selected databases.

If the objective is not met, the MAP function will draw the user's attention with a message (under TSO) or an abend 4001 (in batch). If the MAP function does not give an abend, the objective is achieved, indicating the adequacy of the recovery mechanisms.

It is advisable to schedule the MAP function on a regular basis, through the job management system, for each application.

Combining the use of generic specifications with the triggering of the MAP function by the job management system is a guarantee that the adequacy of recovery mechanisms is properly and regularly verified, as any discrepancy will be identified by an abend of the MAP function.

The function consists of selecting IMS databases defined in the DBRC RECON dataset whose name corresponds to the given generic specification as well as the tablespaces defined in the DB2 catalog for the indicated databases.

Then it constructs the recovery map for all databases and displays it on the screen.

The result is a recovery map, showing all important events related to the selected databases.

A column is attached to each base, according to an association scheme summarized in a table on the right-hand side of the report.

The meaning of the different characters is as follows:

  • U

    U corresponds (for the databases referenced by the column) to the periods during which a base is tagged by IMS with an intent to update.

    The tag is affixed at the time of the first update and is removed after all updating entities, batch programs, or teleprocessing have ended their activities.

    During teleprocessing, commands /DBD or /DBR also remove the intent to update.

  • .

    The dot is an update possibility for a DB2 tablespace. Indeed, as opposed to DBRC, the allocation/deallocation notion does not exist in the DB2 environment and a tablespace can be considered in update at anytime.

  • R

    An R in the column corresponding to a base indicates a "spontaneous" recovery point, i.e., a point suitable for a so-called "timestamp recovery" controlled by DBRC or DB2. It is, for example, an off-line image copy, or a FIC/IIC in reference mode, or a QUIESCE.

  • V

    A V indicates a VIC point.

  • L

    An L (LOSS) marks out a period during which the objective set for the maximum extent of work potentially wasted due to an error is no longer achievable.

  • T

    A T in the column corresponding to a base indicates a "tunnel" mode. It means that the updates are hidden by the recovery (See complements).

  • "-"

    A "-" corresponds for the DB2 tablespaces to a VIC point that became unusable, following the materialization of a definition change.

  • M

    A M indicates for the DB2 tablespaces, the materialization of a definition change following an ALTER TABLESPACE order execution. It is not possible to execute a RECOVER to an earlier day to this operation.

Beginnings and endings of batch programs and IMS-TP sessions are indicated. This makes it possible to relate specific operational activities to database updating periods.

Syntax​

The execution variables of the CS1MAP function are listed below.

The user can request the modification of default values of the function by modifying the member CS1MAP of the parmlib.



* comment
DB=(criterion,\...), DB search criterion or \...
DBDSGRP=dbdsgrp, \... DBDS group criterion
TS=(criterion,\...), TS search criterion
EXTS=(criterion,..), EXTS exclusion criteria
TSSET=Y/N, extent or not the selection to
* complete tablespace sets
AUXTS=WITHBASE/INLIST, include or not LOBS and XML in the treatment
DAYS=days, period on which to do the MAP
TIMESTAMP=yyqqqhhmmssthmiju\[offset\],
* possibility to simulate the timestamp
DBSET=dbset, database search criterion
AUTHID=authid, creator search criterion
NONRECOV=Y/N, process or not non-recoverable DBs
HALDB=Y/N, include or not the HALDB databases for
* processing
DISPLAY=Y/N, display the result of the search
* or not
MAXLOSS=maxloss, max period of use before LOSS warning
* (format DDHHMM).
*
* characters to format the printing
*
* box characters
*
TLC=AC,TMC=34,TRC=BC, high left, central and right
MLC=EC,MMC=8F,MRC=EB, middle left central and right
BLC=AB,BMC=CC,BRC=BB, low left central and right
HC=3D,VC=41, horizontal and vertical dashes
*
* recovery characteristics
*
UC=3E, \"in use\"
UCC=4B \"possibly in use\"
TC=3F, \"tunnel\"
*
COLS=cols, listing format
LINES=lines, idem
HIGH=Y/N, overstrike for \"R\" et \"V\"
CHARS=chars, Font for 3800 (NONE for 1403).
* comment
DB=(criterion,\...), next set of parameters
\...

Specific IMS parameters​

{wrapper="1" role="DL"}

  • DB= (criterion,...)

    DB= specifies the set of databases for the execution of the MAP command in the case when DBDSGRP is not mentioned. Each criterion can be either specific or generic.

    The HALDB databases (dbmaster and/or partition) are also included for processing except if the parameter HALDB(N) is specified.

  • DBDSGRP=dbdsgrp

    DBDSGRP= specifies the set of databases for the execution of the MAP command as the set of databases associated to the DBDS group mentioned; if DBDSGRP parameter is specified, the DB parameter is ignored.

  • NONRECOV=Y/N

    NONRECOV= specifies whether non-recoverable databases must also be processed.

    Default parameter: N

  • HALDB=Y/N

    Specifies if the processing must include (Y) or not include (N) HALDB databases of IMS Version 7 (when performing a generic research on the name of the dbmaster or the name of the partition)

    Default parameter: Y

{wrapper="1" role="DL"}

  • TS=(criterion,..)

    TS= specifies a list of tablespace names patterns. Tablespaces referenced in the DB2 catalog whose name matches one of the patterns are included in the list of tablespaces on which the requested function is to be performed.

    Precisely:

    • A name pattern means a generic name according to SQL LIKE syntax: special characters are the percent sign % and the underscore sign _; additionally, an asterisk * is transformed into a % sign.

    • For a pattern in the form dbname.tsname, tablespaces selected are those whose database name matches the dbname pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

    • For a pattern in the form tsname, tablespaces selected are those whose database name matches the DBSET pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

    • If TS=CATALOG is specified, the function will be performed on catalog tablespaces.

    • If TS=% or TS=* is specified, no catalog tablespace will be selected.

The database name often occurs as the first index column on catalog tables read by the function. Therefore, better performance in reading from the DB2 catalog will be achieved if the database name pattern is specified with as much precision as possible, either through the DBSET parameter, or through the qualifier in a list item of the form dbname.tsname.

If the TS parameter is present, the list of tablespaces satisfying the TS, DBSET and AUTHID research criteria is created. This list can be possibly completed by tablespaces on which the mentioned plans are working via PLAN=, or mentioned package via PKLIST=. If TSSET parameter is worth Y, the list is then extended to the whole tablespaces bound by a referential integrity constraint to a tablespace of the list. The final list is the list of tablespaces taking part in the VIC point. The special value TS=VIC indicates that the list of tablespaces to restore must correspond to all the tablespaces that took part to the VIC point defined by the ID and TIMESTAMPS parameters ; this list will be reconstituted from information memorized in the CS2RECON file.

  • EXTS=(criterion,...)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • EXTS=(criterion,.)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • IX=(criterion,...)

    Specifies a list of indexspaces to be saved. The IX parameter works exactly the the same way as the TS parameter but only for indexes defined in COPY=Y in the DB2 catalog.

  • DBSET=dbset

    DBSET= is used as a default dbname pattern for each item in the list TS= in the form tsname; see the description of TS= parameter. Default parameter: %

  • AUTHID=authid

    AUTHID= is used as a creator's name pattern for each item in the list TS=; see the description of TS= parameter. Default parameter: % Parameters common to IMS and DB2

  • TSSET=Y/N

    allows the inclusion of all tablespaces (obtained by treating the TS and EXTS parameters) that fulfill the reference integrity requirements: all tablespaces with a table linked by a reference integrity constraint to a tablespace table in the defined list are added to the list.

    • Y: search the tablespace set for the reference integrity constraint.

    • N: no search for this tablespace set.

    Default parameter: N

    note

:

The relations with the LOBS and XML auxiliary tablespaces are not taken into consideration through this parameter, but through the AUXTS parameter.

  • AUXTS=WITHBASE/INLIST

    indicates how the auxiliary tablespaces (LOB, XML or historical table spaces) to process are defined.

    • WITHBASE: the auxiliary tablespaces are implicitly defined by the name of the base tablespace on which they depend. Any LOB, XML or historical tablespace depending on a base tablespace defined with the TS parameter (except for tablespaces corresponding to the EXTS parameter) is processed

      note

:

In this case, the TS parameter only indicates the base tablespaces names.

  • INLIST: the auxiliary tablespaces are defined directly by their name through the TS parameter. All auxiliary tablespaces which correspond to the name criteria indicated by TS parameter are processed.

    note

:

In this case, the TS parameter indifferently designates base tablespaces or LOBs, XML or historical tablespaces. If the list defines both a base tablespace and some of its auxiliaries, they are nevertheless individually processed.

Default parameter: WITHBASE

  • DAYS=days

    DAYS= period to analyze. It precedes the date indicated by the TIMESTAMP.

    Default parameter: 7

  • TIMESTAMP=yyqqqhhmmssthmiju[offset]

    TIMESTAMP= specifies the date the map ends.

    The offset indicates the time difference from local time. The default time is the time difference from local time of the used system. The offset is coded in the forms of ±hh:mm in the time slot -11:45 to +14:45,the mm permitted values are: - 00 - 15 - 30 - 45 -

    Default parameter: 993692359599

  • DISPLAY=Y/N

    DISPLAY= lists on SYSOUT the selected databases and tablespaces.

    Default parameter: N

  • MAXLOSS=maxloss

    MAXLOSS= specifies the recovery objective in terms of the maximum amount of potentially wasted operations time for a possible recovery of updated bases.

    Default parameter: 010000

  • TLC=AC, TMC=34, TRC=BC

    These parameters indicate graphic characters to format the result table (TOPLEFT, TOPMIDDLE, TOPRIGHT). They are used in batch processing.

    Default parameters: TLC=TMC=TRC=4E

  • MLC=EC, MMC=8F, MRC=EB

    These parameters indicate graphic characters to format the result table (MIDDLELEFT, MIDDLEMIDDLE, MIDDLERIGHT); They are used in batch processing.

    Default parameters: MLC=MMC=MRC=4E

  • BLC=AB, BMC=CC, BRC=BB

    These parameters indicate graphic characters to format the result table (BOTTOMLEFT, BOTTOMMIDDLE, BOTTOMRIGHT); They are used in batch processing.

    Default parameters: BLC=BMC=BRC=4E

  • HC=3D, VC=41

    These parameters indicate graphic characters to format the result table (HORIZONTAL, VERTICAL) They are used in batch processing.

    Default parameters: HC=60 and VC=4F

  • UC=3E

    This parameter indicates a graphic character for the update periods ('U'); The black cursor may be used. It is used in batch processing.

    Default parameter: E4

  • UCC=4B

    UCC= indicates the graphic character for the possible update periods ('.') for the tablespaces. The gray cursor may be used. It is used in batch processing.

    Default parameter: 4B

  • CC=3F

    CC= indicates the graphic character for the "tunnel" periods when the updates are hidden by the recovery (see complements). The hatched or the vertical dotted cursor may be used. They are used in batch processing.

    Default parameter: E3

  • COLS=cols

    COLS= indicates the number of columns in the listing. It is used in batch processing.

    Default parameter: 132

  • LINES=lines

    LINES= indicates the number of lines in the listing. It is used in batch processing.

    Default parameter: 60

  • HIGH=Y/N

    HIGH= allows overprinting for the R and V characters. It is used in batch processing.

    Default parameter: N

  • CHARS=chars

    CHARS= indicates the character font used in batch mode and in batch processing.

In TSO mode, graphic characters are ignored and a 3270 display map is built, using the characters mentioned in Purpose above.

Default parameter: NONE for 1403

In BATCH mode, you can add a MAPDD DD statement to control map sysout.

Examples​

MAP for all databases beginning with CLI, with an objective of two days of maximum loss. The period analyzed is the last 15 days:

 DB=DBCLI*,DAYS=15,MAXLOSS=020000

MAP for two databases, DBCLI01 and DBCLI02, with an objective of 6 hours and 45 minutes of maximum loss:

 DB=(DBCLI01,DBCLI02),MAXLOSS=000645

MAP for bases CLI* and PRO* with an objective of 12 hours of maximum loss. The MAP covers a period ending January 7, 1989 at 16h and 50m.:

 DB=(DBCLI*,DBPRO*),MAXLOSS=001200,TIMESTAMP=890071650000

MAP for tablespaces in database DBCLIDB2 whose name begins with TSCLI* or TSPRO* for 10 days (batch sample):

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1MAP',DB2ID,'DB2E')
 //SYSIN     DD *
  TS=(TSCLI*,TSPRO*),DBSET=DBCLIDB2,DAYS=10

MAP Report Samples​

Map report for a DB2 subsystem.

|A
| YYYYQQQ DATE TIME EVENT ID IS |A|B|C|D|E| +---------------------+ |
+---------------------------------------------------------+-+-+-+-+-+ | DBD/DB DDN/TS | |

| 2007025 25/01/2007 11:44:59.468412 FIC 0003E825E1A5 B1 |R| | | | | |AA DBCLIENT CLIEN1 | |
| 2007025 25/01/2007 11:44:59.468412 IN USE STATE ... |.| | | | | |AB DBCLIENT CLIEN2 | |
| 2007025 25/01/2007 11:44:59.480744 END OF USE | | | | | | |AC DBCLIENT L@CLICAR | |
| 2007025 25/01/2007 11:44:59.480744 FRC 0003E825E1A5 B1 |R| | | | | |AD DBCLIENT L@CLIPHO | |
| 2007025 25/01/2007 11:44:59.480744 IN USE STATE ... |.| | | | | |AE DBCLIENT XCLI0000 | |
| 2007025 25/01/2007 11:45:00.069700 FIC 0003E825E1A5 |.|R| | | | +---------------------+ |
| 2007025 25/01/2007 11:45:00.069700 IN USE STATE ... |.|.| | | | |
| 2007025 25/01/2007 11:45:00.074678 END OF USE |.| | | | | |
| 2007025 25/01/2007 11:45:00.074678 FRC 0003E825E1A5 |.|R| | | | |
| 2007025 25/01/2007 11:45:00.074678 IN USE STATE ... |.|.| | | | |
| 2007025 25/01/2007 11:45:00.649296 FIC 0003E825E1A5 B1 |.|.|R| | | |
| 2007025 25/01/2007 11:45:00.649296 IN USE STATE ... |.|.|.| | | |
| 2007025 25/01/2007 11:45:00.654639 END OF USE |.|.| | | | |
| 2007025 25/01/2007 11:45:00.654639 FRC 0003E825E1A5 B1 |.|.|R| | | |
| 2007025 25/01/2007 11:45:00.654639 IN USE STATE ... |.|.|.| | | |
| 2007025 25/01/2007 11:45:01.241504 FIC 0003E825E1A5 B1 |.|.|.|R| | |
| 2007025 25/01/2007 11:45:01.241504 IN USE STATE ... |.|.|.|.| | |
| 2007025 25/01/2007 11:45:01.247432 END OF USE |.|.|.| | | |
| 2007025 25/01/2007 11:45:01.247432 FRC 0003E825E1A5 B1 |.|.|.|R| | |
| 2007025 25/01/2007 11:45:01.247432 IN USE STATE ... |.|.|.|.| | |
| 2007025 25/01/2007 11:45:01.741013 FIC 0003E825E1A5 |.|.|.|.|R| |
| 2007025 25/01/2007 11:45:01.741013 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:01.746628 END OF USE |.|.|.|.| | |
| 2007025 25/01/2007 11:45:01.746628 FRC 0003E825E1A5 |.|.|.|.|R| |
| 2007025 25/01/2007 11:45:01.746628 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:05.445179 FIC 0003E8294587 C2 |R|.|.|.|.| |
| 2007025 25/01/2007 11:45:05.445179 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:05.451241 END OF USE | |.|.|.|.| |
| 2007025 25/01/2007 11:45:05.451241 FRC 0003E8294587 C2 |R|.|.|.|.| |
| 2007025 25/01/2007 11:45:05.451241 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:06.024441 FIC 0003E8294587 C2 |.|.|R|.|.| |
| 2007025 25/01/2007 11:45:06.024441 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:06.030135 END OF USE |.|.| |.|.| |
| 2007025 25/01/2007 11:45:06.030135 FRC 0003E8294587 C2 |.|.|R|.|.| |
| 2007025 25/01/2007 11:45:06.030135 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:06.595274 FIC 0003E8294587 C2 |.|.|.|R|.| |
| 2007025 25/01/2007 11:45:06.595274 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 11:45:06.600667 END OF USE |.|.|.| |.| |
| 2007025 25/01/2007 11:45:06.600667 FRC 0003E8294587 C2 |.|.|.|R|.| |
| 2007025 25/01/2007 11:45:06.600667 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 12:20:23.883393 QUI 0003E82BF4D7 B1 |R|.|R|R|.| |
| 2007025 25/01/2007 12:20:23.883393 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 12:20:42.068770 QUI 0003E82C9306 |.|R|.|.|R| |
| 2007025 25/01/2007 12:20:42.068770 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 13:22:23.029693 QUI 0003E8329292 B1 |R|.|R|R|.| |
| 2007025 25/01/2007 13:22:23.029693 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 14:03:03.339738 QUI 0003E8A7F917 B1 |R|.|R|R|.| |
| 2007025 25/01/2007 14:03:03.339738 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 14:29:10.281114 QUI 0003E8C58B3C B1 |R|.|R|R|.| |
| 2007025 25/01/2007 14:29:10.281114 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 14:29:10.980000 VIC FB07025A BC |V|.|V|V|.| |
| 2007025 25/01/2007 15:38:40.534998 QUI 0003E9F36E5A C2 |R|.|R|R|.| |
| 2007025 25/01/2007 15:38:40.534998 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 15:39:03.427609 QUI 0003E9F4094B B1 |R|.|R|R|.| |
| 2007025 25/01/2007 15:39:03.427609 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 16:55:02.058274 END OF USE | |.|.|.|.| |
| 2007025 25/01/2007 16:55:02.058274 IIC 0003EBCD206A B1 |R|.|.|.|.| |
| 2007025 25/01/2007 16:55:02.058274 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 16:55:02.063617 END OF USE | |.|.|.|.| |
| 2007025 25/01/2007 16:55:02.063617 IRC 0003EBCD206A B1 |R|.|.|.|.| |
| 2007025 25/01/2007 16:55:02.063617 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 16:55:04.815346 FIC 0003EBCE94A1 C2 |R|.|.|.|.| |
| 2007025 25/01/2007 16:55:04.815346 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 16:55:04.820982 END OF USE | |.|.|.|.| |
| 2007025 25/01/2007 16:55:04.820982 FRC 0003EBCE94A1 C2 |R|.|.|.|.| |
| 2007025 25/01/2007 16:55:04.820982 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 17:05:15.682641 QUI 0003EBCF7074 B1 |R|.|R|R|.| |
| 2007025 25/01/2007 17:05:15.682641 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 17:05:17.053743 QUI 0003EBD006FE C2 |R|.|R|R|.| |
| 2007025 25/01/2007 17:05:17.053743 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 17:07:55.575624 IIC 0003EBD5B729 B1 |R|.|.|.|.| |
| 2007025 25/01/2007 17:07:55.575624 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 17:07:55.584566 END OF USE | |.|.|.|.| |
| 2007025 25/01/2007 17:07:55.584566 IRC 0003EBD5B729 B1 |R|.|.|.|.| |
| 2007025 25/01/2007 17:07:55.584566 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 17:07:58.756564 FIC 0003EBD72688 C2 |R|.|.|.|.| |
| 2007025 25/01/2007 17:07:58.756564 IN USE STATE ... |.|.|.|.|.| |
| 2007025 25/01/2007 17:07:58.775012 TUNNEL ENTRY ... C2 |T|.|.|.|.| |
| 2007025 25/01/2007 17:07:58.775012 FRC 0003EBD72688 C2 |R|.|.|.|.| |
| 2007025 25/01/2007 17:07:58.775012 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 13:44:32.912550 RCV 0003ED8564F1 B1 |/|.|.|.|.| |
| 2007026 26/01/2007 14:11:09.965435 RCV 0003ED86E59B C2 |/|.|.|.|.| |
| 2007026 26/01/2007 15:06:20.411977 FIC 0003EE5644BC B1 |R|.|.|.|.| |
| 2007026 26/01/2007 15:06:20.411977 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:20.419310 END OF USE | |.|.|.|.| |
| 2007026 26/01/2007 15:06:20.419310 FRC 0003EE5644BC B1 |R|.|.|.|.| |
| 2007026 26/01/2007 15:06:20.419310 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:20.975991 END OF USE |.| |.|.|.| |
| 2007026 26/01/2007 15:06:20.975991 FIC 0003EE5644BC |.|R|.|.|.| |
| 2007026 26/01/2007 15:06:20.975991 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:20.984672 END OF USE |.| |.|.|.| |
| 2007026 26/01/2007 15:06:20.984672 FRC 0003EE5644BC |.|R|.|.|.| |
| 2007026 26/01/2007 15:06:20.984672 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:21.651519 FIC 0003EE5644BC B1 |.|.|R|.|.| |
| 2007026 26/01/2007 15:06:21.651519 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:21.660146 END OF USE |.|.| |.|.| |
| 2007026 26/01/2007 15:06:21.660146 FRC 0003EE5644BC B1 |.|.|R|.|.| |
| 2007026 26/01/2007 15:06:21.660146 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:22.221639 FIC 0003EE5644BC B1 |.|.|.|R|.| |
| 2007026 26/01/2007 15:06:22.221639 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:22.226761 END OF USE |.|.|.| |.| |
| 2007026 26/01/2007 15:06:22.226761 FRC 0003EE5644BC B1 |.|.|.|R|.| |
| 2007026 26/01/2007 15:06:22.226761 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:22.796227 END OF USE |.|.|.|.| | |
| 2007026 26/01/2007 15:06:22.796227 FIC 0003EE5644BC |.|.|.|.|R| |
| 2007026 26/01/2007 15:06:22.796227 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:22.801462 END OF USE |.|.|.|.| | |
| 2007026 26/01/2007 15:06:22.801462 FRC 0003EE5644BC |.|.|.|.|R| |
| 2007026 26/01/2007 15:06:22.801462 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:26.536191 FIC 0003EE599A2E C2 |R|.|.|.|.| |
| 2007026 26/01/2007 15:06:26.536191 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:26.541670 END OF USE | |.|.|.|.| |
| 2007026 26/01/2007 15:06:26.541670 FRC 0003EE599A2E C2 |R|.|.|.|.| |
| 2007026 26/01/2007 15:06:26.541670 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:27.157396 FIC 0003EE599A2E C2 |.|.|R|.|.| |
| 2007026 26/01/2007 15:06:27.157396 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:27.165371 END OF USE |.|.| |.|.| |
| 2007026 26/01/2007 15:06:27.165371 FRC 0003EE599A2E C2 |.|.|R|.|.| |
| 2007026 26/01/2007 15:06:27.165371 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:27.755517 FIC 0003EE599A2E C2 |.|.|.|R|.| |
| 2007026 26/01/2007 15:06:27.755517 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:06:27.764873 END OF USE |.|.|.| |.| |
| 2007026 26/01/2007 15:06:27.764873 FRC 0003EE599A2E C2 |.|.|.|R|.| |
| 2007026 26/01/2007 15:06:27.764873 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:32:55.562255 QUI 0003EF096AFE B1 |R|.|R|R|.| |
| 2007026 26/01/2007 15:32:55.562255 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:32:56.360000 VIC FB07026A BC |V|.|V|V|.| |
| 2007026 26/01/2007 15:36:20.121606 QUI 0003EF226548 B1 |R|.|R|R|.| |
| 2007026 26/01/2007 15:36:20.121606 IN USE STATE ... |.|.|.|.|.| |
| 2007026 26/01/2007 15:36:21.415351 QUI 0003EF22FC44 C2 |R|.|R|R|.| |
| 2007026 26/01/2007 15:36:21.415351 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 10:12:52.360307 IRC 0003F063E436 B1 |R|.|.|.|.| |
| 2007029 29/01/2007 10:12:52.360307 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 10:12:55.272554 IRC 0003F0659785 C2 |R|.|.|.|.| |
| 2007029 29/01/2007 10:12:55.272554 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 10:30:45.415425 QUI 0003F06690E8 B1 |R|.|R|R|.| |
| 2007029 29/01/2007 10:30:45.415425 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 10:30:45.711734 QUI 0003F0672B84 C2 |R|.|R|R|.| |
| 2007029 29/01/2007 10:30:45.711734 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 10:35:29.966807 IRC 0003F068E285 B1 |R|.|.|.|.| |
| 2007029 29/01/2007 10:35:29.966807 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 10:35:32.657243 IRC 0003F06A9739 C2 |R|.|.|.|.| |
| 2007029 29/01/2007 10:35:32.657243 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 11:44:31.563556 QUI 0003F06DC3FC B1 |R|.|R|R|.| |
| 2007029 29/01/2007 11:44:31.563556 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 11:44:31.897822 QUI 0003F06E5CFE C2 |R|.|R|R|.| |
| 2007029 29/01/2007 11:44:31.897822 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 11:47:08.183925 IRC 0003F0701F79 B1 |R|.|.|.|.| |
| 2007029 29/01/2007 11:47:08.183925 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 11:47:11.437710 IRC 0003F071D436 C2 |R|.|.|.|.| |
| 2007029 29/01/2007 11:47:11.437710 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 12:14:00.996921 IIC 0003F0701F79 B1 |R|.|.|.|.| |
| 2007029 29/01/2007 12:14:00.996921 IN USE STATE ... |.|.|.|.|.| |
| 2007029 29/01/2007 12:14:03.533490 IRL 0003F071D436 C2 |R|.|.|.|.| |
| 2007029 29/01/2007 12:14:03.533490 IN USE STATE ... |.|.|.|.|.| |
| 2007031 31/01/2007 17:22:30.070000 MAP FLASH TIME |.|.|.|.|.| |
| -------------------------------------------------------+-+-+-+-+-+ |
| MEANS: |


| "R"=RECOVERY TIMESTAMP AUTHORIZED BY DBRC/DB2 |
| "S"=ONLINE IMAGE COPY OR FIC/IIC WITH SHRLEVEL=SHARE |
| "/"=RECOVERY RUN TIME OR LOAD/RELOAD/REORG OF A DB2 TS WITH LOG=NO |
| "U"=IN USE FOR UPDATE |
| "."=CAN HAVE BEEN USED FOR UPDATE |
| "L"=IN USE FOR UPDATE AND LOSS WARNING CONDITION REACHED |
| "T"=HAS BEEN USED BUT UNDER TUNNEL CREATED BY A RECOVERY |
| "V"=VIC RECOVERY TIMESTAMP |
| "M"=MATERIALIZATION OF PENDING DEFINITION CHANGE |
| "-"=RECOVERY NOT POSSIBLE FROM THIS POINT (DUE TO A LATER MATERIALIZATION/...) |
| "="=LOAD/RELOAD/REORG OF A DB2 TS WITH LOG=YES |
| CRE - TABLESPACE CREATION |
| FIC - FULL PRIMARY IMAGE COPY DATA SET AT THE LOCAL SITE ONLY |
| FRC - FULL PRIMARY IMAGE COPY DATA SET AT THE RECOVERY SITE ONLY |
| FRL - FULL PRIMARY IMAGE COPY DATA SETS AT THE RECOVERY AND LOCAL SITE |
| FLC - FULL PRIMARY IMAGE COPY ISSUED FROM THE FLASH COPY UTILITY |
| IIC - INCREMENTAL PRIMARY IMAGE COPY DATA SET AT THE LOCAL SITE ONLY |
| IRC - INCREMENTAL PRIMARY IMAGE COPY DATA SET AT THE RECOVERY SITE ONLY |
| IRL - INCREMENTAL PRIMARY IMAGE COPY DATA SETS AT THE RECOVERY AND LOCAL SITE |
| MPC - MATERIALIZATION OF PENDING DEFINITION CHANGE |
| ** VALUES FOR "IS" COLUMN : |
| B1: BASE OBJECT WITH INSTANCE NUMBER 1 |
| B2: BASE OBJECT WITH INSTANCE NUMBER 2 |
| C1: CLONE OBJECT WITH INSTANCE NUMBER 1 |
| C2: CLONE OBJECT WITH INSTANCE NUMBER 2 |
| BC: BASE+CLONE OBJECTS (FOR VIC ONLY) |
                                 DB2 example
MAP Report for a DL1 subsystem with no QUIESCE DB2 event
| |A| |B| |
| YYQQQ DATE TIME EVENT ID |A|B|C|D|E|F|G|H|I|J|K|.|A|B|C|D|E|F|G| | DBD DDN |
+---------------------------------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +------------- |
| 90236 23/08/90 13:25:49.0 IMSE STARTED | | | | | | | | | | | | | | | | | | | | |AB BACU01D DACU01D |
| 90236 23/08/90 21:59:20.6 IMAGE COPY | |R| | | | | | | | | | | | | | | | | | |AC BBSTCKD DBSTCKD |
| 90236 23/08/90 21:59:59.9 IMAGE COPY | | |R| | | | | | | | | | | | | | | | | |AD BBSTERD DDSTERD |
| 90236 23/08/90 22:00:28.1 IMAGE COPY | | | |R| | | | | | | | | | | | | | | | |AE BBSTERI DDSTERI |
| 90236 23/08/90 22:01:03.4 IMAGE COPY | | | | |R| | | | | | | | | | | | | | | |AF BBST01D DBST01D |
| 90236 23/08/90 22:01:09.8 IMAGE COPY | | | | | |R| | | | | | | | | | | | | | |AG BBST02I DBST02I |
| 90236 23/08/90 22:02:19.3 IMAGE COPY | | | | | | | | | |R| | | | | | | | | | |AH BBST03I DBST03I |
| 90236 23/08/90 22:03:38.5 IMAGE COPY | | | | | | |R| | | | | | | | | | | | | |AI BBST04D DBST04D |
| 90236 23/08/90 22:04:45.3 IMAGE COPY | | | | | | | | |R| | | | | | | | | | | |AJ BBST06D DDST06D |
| 90236 23/08/90 22:05:23.2 IMAGE COPY | | | | | | | |R| | | | | | | | | | | | |AK BBST11D DDST11D |
| 90236 23/08/90 22:23:29.4 IN USE STATE ... | | | | | | | | | | | | | | |.| | | | | | |
| 90236 23/08/90 22:23:40.2 IN USE STATE ... | | | | | | | | | | | | | |.|.| | | | | |... |
| 90236 23/08/90 22:23:45.3 IN USE STATE ... | | | | | | | | | | | | |.|.|.| | | | | |BA BDIU01D DDIU01D |
| 90236 23/08/90 22:59:20.6 IMAGE COPY | | | | | | | | | | | | |.|.|.|R| | | | |AK BBST11D DDST11D |
| 90236 23/08/90 22:59:59.1 IMAGE COPY | | | | | | | | | | | | |.|.|.| |R| | | | |
| 90236 23/08/90 23:00:28.9 IMAGE COPY | | | | | | | | | | | | |.|.|.| | |R| | |... |
| 90236 23/08/90 23:01:03.4 IMAGE COPY | | | | | | | | | | | | |.|.|.| | | |R| | |
| 90236 23/08/90 23:05:19.0 IMAGE COPY | | | | | | | | | | |R| |.|.|.| | | | | | |
| .... | | | | | | | | | | | | |.|.|.| | | | | +------------------- |
| 90237 24/08/90 08:01:48.1 IN USE STATE ... |.| | | | | | | | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:14:51.5 IN USE STATE ... |.|.| | | | | | | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:21:34.0 IN USE STATE ... |.|.|.| | | | | | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:21:36.0 IN USE STATE ... |.|.|.| |.| | | | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:21:37.3 IN USE STATE ... |.|.|.|.|.| | | | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:21:38.6 IN USE STATE ... |.|.|.|.|.|.| | | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:25:47.9 IN USE STATE ... |.|.|.|.|.|.|.| | | | | |.|.|.| | | | | |
| 90237 24/08/90 08:41:45.3 IN USE STATE ... |.|.|.|.|.|.|.|.| | | | |.|.|.| | | | | |
| 90237 .... |.|.|.|.|.|.|.|.| | | | |.|.|.| | | | | |
| 90237 |.|.|.|.|.|.|.|.| | | | |.|.|.| | | | | |
| 90238 |.|.|.|.|.|.|.|.| | | | |.|.|.| | | | | |
| 90239 .... |.|.|.|.|.|.|.|.| | | | |.|.|.| | | | | |
| 90239 26/08/90 09:40:24.2 END OF USE |.|.|.|.|.|.|.|R| | | | |R|.|.| | | | | |
| 90239 26/08/90 10:21:38.6 IN USE STATE ... |.|.|.|.|.|.|.| |.| | | | |.|.| | | | | |
| 90239 26/08/90 10:25:47.9 IN USE STATE ... |.|.|.|.|.|.|.| |.|.| | | |.|.| | | | | |
| 90239 26/08/90 10:41:45.3 IN USE STATE ... |.|.|.|.|.|.|.| |.|.|.| | |.|.| | | | | |
| 90239 26/08/90 10:45:01.4 VIC VPT1 |.|.|V|V|V|V|V|V|V|V|.| | |.|.| | | | | |
| 90239 .... |.|.|.| | | |.| |.|.|.| | |.|.| | | | | |
| 90240 27/08/90 07:04:16.8 IMSE ENDED |.|.|.| |.| |.| |.|.|.| | |.|.| | | | | |
| 90240 27/08/90 07:04:16.8 END OF USE |R|R|R| |R| |R| |R|R|R| | |R|R| | | | | |
| 90240 27/08/90 07:58:29.1 IMSE STARTED | | | | | | | | | | | | | | | | | | | | |
| 90240 27/08/90 08:00:08.5 IN USE STATE ... |.| | | | | | | | | | | | | | | | | | | |
| 90240 27/08/90 09:01:14.1 IN USE STATE ... |.|.| | | | | | | | | | | | | | | | | | |
| 90240 27/08/90 09:38:27.0 IN USE STATE ... |.|.|.| | | | | | | | | | | | | | | | | |
| 90240 27/08/90 09:38:38.0 IN USE STATE ... |.|.|.|.| | | | | | | | | | | | | | | | |
| 90240 27/08/90 22:59:20.6 IMAGE COPY |.|.|.|.| | | | | | | | | | | |R| | | | |
| 90240 27/08/90 22:59:59.1 IMAGE COPY |.|.|.|.| | | | | | | | | | | | |R| | | |
| 90240 27/08/90 23:00:28.9 IMAGE COPY |.|.|.|.| | | | | | | | | | | | | |R| | |
| 90240 27/08/90 23:01:03.4 IMAGE COPY |.|.|.|.| | | | | | | | | | | | | | |R| |
| ... |

MAP Report for a DL1 subsystem with QUIESCE DB events
| YYQQQ DATE TIME EVENT ID |A| +---------------------+ |
+--------------------------------------------------------+-+ | DBD/DB DDN/TS | | 
| 09019 19/01/2009 10:02:59.924201 IMAGE COPY |R| |AA IVPDB1 DFSIVD1 | |
| 09019 19/01/2009 10:46:20.671559 IM11 STARTED | | +---------------------+ |
| 09019 19/01/2009 11:08:31.877610 IN USE STATE ... |U| |
| 09019 19/01/2009 11:14:03.176468 END OF USE |R| |
| 09019 19/01/2009 11:14:03.176468 QUIESCE DB |U| |
| 09019 19/01/2009 11:14:03.176468 END OF USE |R| |
| 09019 19/01/2009 11:43:28.819663 MZLFB2 STARTED | | |
| 09019 19/01/2009 11:43:29.157016 IN USE STATE ... |U| |
| 09019 19/01/2009 11:43:29.318584 MZLFB2 ENDED |U| |
| 09019 19/01/2009 11:43:29.318584 END OF USE |R| |
| 09019 19/01/2009 14:16:45.971795 IN USE STATE ... |U| |
| 09020 20/01/2009 09:30:59.199584 END OF USE |R| |
| 09020 20/01/2009 09:30:59.199584 QUIESCE DB |U| |
| 09020 20/01/2009 09:30:59.199584 END OF USE |R| |
| 09021 21/01/2009 15:09:07.431918 IN USE STATE ... |U| |
| 09026 26/01/2009 14:38:18.500000 MAP FLASH TIME |U| |
+--------------------------------------------------------+-+ |
| MEANS: |
| "R"=RECOVERY TIMESTAMP AUTHORIZED BY DBRC/DB2 |
| "S"=ONLINE IMAGE COPY OR FIC/IIC WITH SHRLEVEL=SHARE |
| "/"=RECOVERY RUN TIME OR LOAD/RELOAD/REORG OF A DB2 TS WITH LOG=NO |
| "U"=IN USE FOR UPDATE |
| "."=CAN HAVE BEEN USED FOR UPDATE |
| "L"=IN USE FOR UPDATE AND LOSS WARNING CONDITION REACHED |
| "T"=HAS BEEN USED BUT UNDER TUNNEL CREATED BY A RECOVERY |
| "V"=VIC RECOVERY TIMESTAMP |
| "="=LOAD/RELOAD/REORG OF A DB2 TS WITH LOG=YES |
| FIC - FULL PRIMARY IMAGE COPY DATA SET AT THE LOCAL SITE ONLY |
| FRC - FULL PRIMARY IMAGE COPY DATA SET AT THE RECOVERY SITE ONLY |
| FRL - FULL PRIMARY IMAGE COPY DATA SETS AT THE RECOVERY AND LOCAL SITE |
| IIC - INCREMENTAL PRIMARY IMAGE COPY DATA SET AT THE LOCAL SITE ONLY |
| IRC - INCREMENTAL PRIMARY IMAGE COPY DATA SET AT THE RECOVERY SITE ONLY |
| IRL - INCREMENTAL PRIMARY IMAGE COPY DATA SETS AT THE RECOVERY AND LOCAL SITE |
                                 DL1 example

Complements​

A recovery done on a database is indicated by a / at the corresponding time on the map. Activities pertaining to the updating period are invalidated and displayed in the so-called "tunnel" mode, in which updates are hidden by the recovery. If the MAP function is used to simulate the situation preceding the recovery (parameter TIMESTAMP=,), the updating period that was canceled becomes entirely visible again.

INFO-RECOVERY users are advised to set, at the beginning, an objective of maximum loss that is not too small. Later on, they should try to reduce the maximum loss by modifying the schedule of recovery mechanisms.

Each time a new objective is set and recovery mechanisms have been adjusted accordingly, it is best to be sure that the new situation is stable before starting a new cycle of changes. The goal is to shorten columns of update produced by the map function, e.g., by cutting them in half with additional VIC steps. A balance should be found between the desirable protection against the potentially devastating effects of an error and the temporary inconvenience to users caused by protective measures.

It is useful to prepare as many maps as there are applications, as well as a general map covering all applications. The latter might reveal previously unsuspected simultaneous updates.

If the report is larger than 132 columns, MAP will print the missing part only after having printed all pages for columns 1 to 132. Thus, if the report is made up of 3 pages (vertically) and 240 columns (horizontally), the result will be printed as follows: three pages for columns 1 to 132, then three pages for columns 133 to 240. In this way, paper cutting to assemble the final report is minimized. (In this example, paper is cut only once).

If a laser printer is available at your site, you can use a font with graphic characters to highlight parts of the map. Parameters are available to define the 11 characters used for printing boxes.

CS1AOP - Automatic Operator

Purpose​

The CS1AOP function makes it possible to automatically perform IMS or DB2 operator actions for one or more DL/1 bases or DB2 tablespaces.

The CS1AOP function can be used in the following environments: IMS/DC, DBCTL, and IMS and DB2 data sharing. For a data sharing environment, the values IMSDSGid and DB2DSGid must be provided for the parameters IMSID and DB2ID in the PARMLIB.

The databases concerned are found in the RECON dataset and the tablespaces in the DB2 catalog.

CS1AOP can be used to automate IMS/DB2 commands required for the correct execution of recovery mechanisms.

For example, off-line image copies make it necessary to deallocate bases from teleprocessing, which implies that they must be restarted once image copies are made. This is taken care of by CS1AOP (see CS1IC in doc HR101). The FIC may be synchronized by declaring a UTILITY access on all tablespaces and by restarting these tablespaces (see CS1FIC in doc HR102).

The function is used implicitly by CS1RECOV and to automate recovery actions. Made available as a separate function, it provides INFO-RECOVERY users with an IMS/DB2 automatic operator covering a variety of requirements with regard to databases:

  • INQUIRY

  • UTILITY

  • DEALLOC

  • DISPLAY

  • SWITCH

  • START

  • READONLY

  • READINT

  • UPDATE

  • EXCL

Actions INQUIRY, UTILITY, and DEALLOC are preceded, if needed, by a wait for the end of batch programs in process. The section "complement" in the CS1VIC chapter contains a discussion of the wait mechanism.

A null action, DISPLAY, shows information available on the selected objects. The READONLY, READINT, UPDATE and EXCL can only be used in a local environment on an IMS system. Therefore, the IMSID parameter must contain the IMS name and not the name of the data sharing group (refer to chapter " Parameters").

A special action, SWITCH, will cause archiving of the IMS log only if updates on the selected databases are not archived. If all updates are already archived, the function does nothing. The action thus operates as a selective switch. The way it is implemented makes it possible to avoid collisions, should there be multiple asynchronous requests. A parameter allows the setting of a waiting time until the OLDS is spontaneously archived, before forcing the switch, if needed. There is an option to indicate whether the next action should wait for the successful completion of the archiving.

note

The option NOTP (NO TP) to the level of the parm of the card exec lets batch control the behavior of the function AOP when the IMS TP is not active. This option includes these:

  • C (CANCEL, def) to cancel the command AOP

  • W (WAIT) to wait for the beginning of the TP

  • R (REPLY) to request the operator to perform the action: wait or cancel

Under TSO, the value is always C.

The function will then select databases defined in the RECON dataset of DBRC, the name of which corresponds to the generic specification. In the same way, tablespaces of the specified databases are selected in the DB2 catalog.

It will then give the necessary commands for this set of databases, after having verified that they are free of any update intent on the part of a batch job or BMP or long duration lock. If such is the case, the function waits for the end of the batch or BMP, and the execution of commands is deferred.

The end of the operation is indicated by the message:

 AOP ENDED    THE mm/dd/yy AT hhmmssd

There are two important phases in the execution of the AOP:

  1. The Look step, during which the function looks for batches or BMPs updating the databases as well as long duration locks on DB2 tablespaces.

    If there are any, the function will wait until they end before actually executing the AOP.

  2. The AOP Start and End step, the phase in which the commands are executed.

Syntax​

The execution variables of the function CS1AOP are listed below.

The user can request modification of the default values of the function by modifying the member CS1AOP of the parmlib.



* comment
DB=(criterion,.), DB search criterion or \...
DBDSGRP=dbdsgrp, \... DBDS group criterion
TS=(criterion,.), TS search criterion
EXTS=(criterion,..), EXTS exclusion criteria
*
TSSET=Y/N extend the selection to TSSET (Default: N)
AUXTS=WITHBASE/INLIST include or not LOBs and XML and historical
* tablespace in the treatment
ACTION=action, action to execute
DBSET=dbset, database search criterion
AUTHID=authid, creator search criterion
DSSEL=dssel, selection of TS partitions
NONRECOV=Y/N, process or not non-recoverable DBs
HALDB=Y/N, include or not the HALDB databases for
* processing
DISPLAY=Y/N, display selected objects or not
WAIT=wait, wait during non critical sections
RWAIT=rwait, wait during critical sections
RETRY=retry, number of tests during non critical
* sections
MAXTIME=maxtime, max execution time of critical
* sections (seconds)
FAILED=failed, number of tries of the command
ARC=Y/N, wait for the execution of the
* archive or not
ARCTIME=arctime, max time of the archive (seconds).
MSG=Y/N, sending out of a WAIT message or not
WTO=N/N sending out of a WAIT WTO or not
* comment
DB=(criterion,.), next set of parameters
\...

Specific IMS parameters

{wrapper="1" role="DL"}

  • DB= (criterion,.)

    DB= specifies the set of databases for the execution of the AOP command in the case when DBDSGRP is not mentioned. Each criterion can be either specific or generic.

    The HALDB databases (dbmaster and/or partition) are also included for processing except if the parameter HALDB(N) is specified.

  • DBDSGRP=dbdsgrp

    DBDSGRP= specifies the set of databases for the execution of the AOP command as the set of databases associated to the DBDS group mentioned; if DBDSGRP parameter is specified, the DB parameter is ignored.

  • ARC=Y/N

    ARC= indicates if the function has to await the end of the archiving or not.

    Default parameter: Y

  • ARCTIME=arctime

    ARCTIME= is the maximum wait time mentioned above.

    Default parameter: 1800

  • NONRECOV=Y/N

    NONRECOV= specifies whether non-recoverable databases must also be processed.

    This parameter is valid from IMS level 310 on.

    Default parameter: N

  • HALDB=Y/N

    Specifies if the processing must include (Y) or not include (N) HALDB databases of IMS Version 7 (when performing a generic research on the name of the dbmaster or the name of the partition).

    Default parameter: Y

Specific DB2 parameters

{wrapper="1" role="DL"}

  • TS=(criterion,..)

    TS= specifies a list of tablespace names patterns. Tablespaces referenced in the DB2 catalog whose name matches one of the patterns are included in the list of tablespaces on which the requested function is to be performed.

    Precisely:

    • A name pattern means a generic name according to SQL LIKE syntax: special characters are the percent sign % and the underscore sign _; additionally, an asterisk * is transformed into a % sign.

    • For a pattern in the form dbname.tsname, tablespaces selected are those whose database name matches the dbname pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

    • For a pattern in the form tsname, tablespaces selected are those whose database name matches the DBSET pattern, whose name matches the tsname pattern and whose creator's name matches the AUTHID pattern.

    • If TS=CATALOG is specified, the function will be performed on catalog tablespaces.

    • If TS=% or TS=* is specified, no catalog tablespace will be selected.

      The special value TS=VIC allows you to only indicate the list of tablespaces to restore.

The database name often occurs as the first index column on catalog tables read by the function. Therefore, better performance in reading from the DB2 catalog will be achieved if the database name pattern is specified with as much precision as possible, either through the DBSET parameter, or through the qualifier in a list item of the form dbname.tsname.

  • EXTS=(criterion,.)

    specifies a list of tablespaces to be excluded from processing. The EXTS parameter has the same syntax then the TS parameter and allows you to exclude certain tablespaces from the list that has been obtained by using the TS parameter.

    The EXTS parameter is ignored in case of TS=CATALOG.

    Default: NONE

  • IX=(criterion,...

    Specifies a list of indexspaces to be saved. The IX parameter works exactly the the same way as the TS parameter but only for indexes defined in COPY=Y in the DB2 catalog.

  • DBSET=dbset

    DBSET= is used as a default dbname pattern for each item in the list TS= in the form tsname; see the description of TS= parameter. Default parameter: %

  • AUTHID=authid

    AUTHID= is used as a creator's name pattern for each item in the list TS=; see the description of TS= parameter. Default parameter: %

  • DSSEL=dssel

    a numeric value indicates that the VIC point has only to cover the specified partition. All selected tablespaces must be partitioned tablespaces.

    The value ALL means that all tablespaces (partitioned or non-partitioned) will be processed on a global level.

    Default parameter: ALL

  • IXALL=Y/N

    this parameters is used to request the execution of DB2 commands for all indexes, in addition to the tablespace.

    Default parameter: N Parameters common to IMS and DB2

  • TSSET=Y/N

    allows the inclusion of all tablespaces (obtained by treating the TS and EXTS parameters) that fulfill the reference integrity requirements: all tablespaces with a table linked by a reference integrity constraint to a tablespace table in the defined list are added to the list.

    • Y: search the tablespace set for the reference integrity constraint

    • N: no search for this tablespace set.

    Default parameter: N

    note

:

The relations with the LOBS and XML and historical auxiliary tablespaces are not taken into consideration through this parameter, but through the AUXTS parameter.

  • AUXTS=WITHBASE/INLIST

    indicates how the auxiliary tablespaces (LOB or XML) to process are defined.

    • WITHBASE: the auxiliary tablespaces are implicitly defined by the name of the base tablespace on which they depend. Any LOB or XML tablespace depending on a base tablespace defined with the TS parameter (except for tablespaces corresponding to the EXTS parameter) is processed.

      note

:

In this case, the TS parameter only indicates the base tablespaces names.

  • INLIST: the auxiliary tablespaces are defined directly by their name through the TS parameter. All auxiliary tablespaces which correspond to the name criteria indicated by TS parameter are processed.

    note

:

In this case, the TS parameter indifferently designates base tablespaces or LOBs or XML or historical tablespaces. If the list defines both a base tablespace and some of its auxiliaries, they are nevertheless individually processed.

ACTION=action :

ACTION= indicates the action to accomplish on the IMS database and/or the DB2 tablespace.

Action IMS command DB2 command DISPLAY /DIS -DIS

INQUIRY /DBD NOFEOV -START ACCESS (RO)

UTILITY /DBD NOFEOV -START ACCESS (UT)

UTILDEA /DBR NOFEOV -START ACCESS (UT)

DEALLOC /DBR NOFEOV -STOP

SWITCH /DBR dummydb FEOV n/a

START /STA -START ACCESS (RW)

READONLY /STA ACCESS (RO) -START ACCESS (RO)

READINT /STA ACCESS (RD) -START ACCESS (RO)

UPDATE /STA ACCESS (UP) -START ACCESS (RW)

EXCL /STA ACCESS (EX) -START ACCESS (RW)

: CS1AOP function table

{wrapper="1" role="DL"}

  • DISPLAY

    All tablespace locks are displayed.

  • INQUIRY

    All databases and all tablespaces are in INQUIRY mode.

  • UTILITY

    All databases are in INQUIRY and all tablespaces are in UTILITY mode.

  • UTILDEA

    All DBs are deallocated, and all tablespaces are in UTILITY.

  • DEALLOC

    All DBs and all tablespaces are deallocated (without SWITCH).

  • SWITCH

    A switch of OLDS is generated if the OLDS file contains updates of selected DBs.

    AOP waits for a spontaneous switch of OLDS during a period equal to the parameter WAIT * RETRY. If no switch interferes during this period, the switch will be forced.

  • START

    All DBs and all TS are "started".

  • READONLY

    All DBs are "started" with the access RO (fetch only) and all TS are in INQUIRY mode.

  • READINT

    All DBs are "started" with the access RD (fetch) and all TS are put in INQUIRY mode.

  • UPDATE

    All DBs are "started" with the access UP (update) and all TS are "started".

  • EXCL

    All DBs are "started" with the access EX ( exclusive use) and all TS are "started".

Default parameter: DISPLAY

  • DISPLAY=Y/N

    DISPLAY= lists on SYSOUT the selected databases and tablespaces.

    Default parameter: N

  • WAIT=wait

    WAIT= is the maximum wait time during non-critical sections (LOOK STEP).

    Default parameter: 10

  • RWAIT=rwait

    RWAIT= is the maximum wait time during critical sections, such as during periods where AOP can be a constraint for the other users (AOP start and end step).

    Default parameter: 1

  • RETRY=retry

    RETRY= is the number of tests during non-critical sections.

    Default parameter: 6

  • MAXTIME=maxtime

    MAXTIME= is the maximum execution time of critical sections (see above).

    Default parameter: 60

  • FAILED=failed

    FAILED= is the number of iterations of the command when it can't be executed.

    Default parameter: 1

  • MSG=Y/N

    MSG= sends a message when the function begins to wait.

    Default parameter: Y

  • WTO=Y/N

    WTO= sends a console message when the function begins to wait.

    Default parameter: N

Examples​

Stop of updates on databases DBCLI*:

 DB=DBCLI*,ACTION=INQUIRY

Archiving modifications on databases DBCLI01 and DBCLI02. If all updates on these databases have already been archived, the function is inactive:

 DB=(DBCLI01,DBCLI02),ACTION=SWITCH

Deallocation of DBCLI databases:

 DB=DBCLI*,ACTION=DEALLOC

Start of DBCLI* and DBPRO* databases (batch example):

 //S1      EXEC PGM=CSXEXEC,DYNAMNBR=50,REGION=2M,
 //             PARM=(FUNCTION,'CS1AOP',IMSID,'IMSE')
 //SYSIN     DD *
  DB=(DBCLI*,DBPRO*),ACTION=START

Stopping the update on partition n° 2 of the tablespace DBPARTA and all indexes related to this partition (partition n° 2 of the partitioned index XPART1 and the logical partition n° 2 of the non-partitioned index XPART2).

 TS=DBPARTA,IXALL=Y,DSSEL=2,ACTION=READONLY

Appendices

User Configuration under ISPF/TP​

Select option C (CONFIG) on the general menu of INFO-RECOVERY to modify default values. The following panel is displayed:


INFO-RECOVERY - User Profile Configuration
COMMAND ===\>
Parmlib library \....===\>
Imsid \...\...\...\.....===\>
db2id \...\...\...\.....===\>
Debug option \...\....===\> (Y/N) (Trace the clists and skeletons)
User library \...\....===\>
User option \...\.....===\> (Y/N) (Search ISPF objects in user library before)
Output kept size \...===\> (The number of output print pages to be kept)
Press Enter to validate a new configuration or PF3/15 for exit

Different values may be provided for the current parmlib, the target IMSID, or DB2ID may be modified.

Only the current user profile will be updated accordingly.

The special value IMSID,'NONE' avoids allocating an IMS environment and may only be used by users of mixed DL1/DB2 functions who do not need to access DL1 databases.

The special value DB2ID,'NONE' avoids allocating a DB2 environment and may only be used by users of mixed DL1/DB2 functions who do not need to access DB2 databases.

A DEBUG option traces user CLISTs if any problem occurs.

A user parmlib can be specified. This parmlib contains ISPF objects CLISTs, PANELs, MSGs, or SKELETONs, as well as customization members for INFO-RECOVERY functions that are specific to the user.

The scanning of this library is activated if "User option" is set to Y. In this case, a member found in the user library is used instead of a member in the parmlib with the same name.

Thus the user can define default parameters for the different functions of INFO-RECOVERY.

Members SYSIDS, IMSIDS, DB2IDS, PRODUCTS and CUSTOM cannot be masked by user members.

The printed output is displayed on a logical terminal where the number of pages can be defined by each user. When this number is reached, the first page is used again. The terminal is cyclic, and an automatic return to the first page is made at the end of the last page.

Edit​

The products parmlib contains all parameter values. Option E (EDIT) on the general INFO-RECOVERY menu allows a direct access to edit the current parmlib.

Remember that any change made to the parmlib is general for all users and therefore requires special care. The following member names are reserved names for the products:

  ##CHANGE -        List of changes to products
  #CSJ.... -        Installation jobs of products
  CSK..... -        Skeletons for installation of products
  CSL..... -        Dlibs description of products
  CSM..... -        ISPF msgs of products
  CSP..... -        ISPF panels of products
  CSQ..... -        SQL statements for products
  CSR..... -        XPROC procedures for products
  CSS..... -        Skeletons for use of products
  CSU..... -        Clists for use of products
  CSn..... -        Default members for CSn product functions
  CTRLRUN  -        Batch control run member
  CUSTOM   -        Global customization
  DB2IDS   -        Description of DB2s
  IMSIDS   -        Description of IMSs
  JOBCARD  -        JOB card user clist
  PRODUCTS -        Description of products
  SYSIDS   -        Description of MVSs

Logical Terminal​

The INFO-RECOVERY functions use a logical terminal to communicate with the user.

The logical terminal is displayed each time you select an INFO-RECOVERY function from the TP interface.

The illustration below shows a logical terminal:


INFO-RECOVERY - Logical Terminal
COMMAND ===\>
Page 1/1 Cols 1 to 80
CS1INIT - 91/09/05 12.10 PRODUCT INFOREC1

The execution of an INFO-RECOVERY function starts when entering its parameters into the command field of the logical terminal. The execution processes and the output report is displayed on the terminal. For example: enter TS=(mydb*.myts*),ID=MYVIC to start a VIC point processing.

The number of pages to preserve is set by the user using option C (CONFIG) on the main INFO-RECOVERY menu.

The following commands are available:

{wrapper="1" role="DL"}

  • PF7/19 (UP)

    to display the previous page

  • PF8/20 (DOWN)

    to display the next page

  • PF10/22

    to display the previous command

  • PF11/23

    to display the next command

  • ENTER

    to display columns 52 to 132 and to return to columns 1 to 80

During its execution, a command is automatically changed into a comment by inserting a *. To re-execute the command, blank out this character.

Calling User Procedures​

INFO-RECOVERY allows the user to call user CLISTs or REXX procedures

  • if they are located in the parmlib of INFO-RECOVERY (current parmlib or user parmlib).

  • if the two libraries of clists and REXX procedures are defined in the member SYSIDS of the parmlib by the following parameters:

    • PROCLIB for clists

    • EXECLIB for REXX procedures

These libraries will be allocated dynamically by INFO-RECOVERY with the ddnames:

  • SYSPROC and SYSEXEC in batch mode

  • PRLIB and EXLIB in interactive mode

Direct Call​

A clist or a REXX program can directly be called by a function of INFO-RECOVERY. How to do:

  • for the IMS environment

    indicate its name in the CLIST parameter

  • for the DB2 environment

    create an XPROC procedure in the parmlib with the following syntax: "EXEC=CLIST, NAME=clist or rexx procedure name" and to specify the name (CSR*) of this procedure in the PROC parameter of the function.

The search processing is performed within four libraries in the following order:

  1. user parmlib

  2. current parmlib

  3. library of user CLISTs

  4. library of user REXX programs

Indirect Call​

A later call using a clist belonging to the parmlib can be made according to the exection mode, either batch or interactive.

In batch mode, it is possible to call the clist or REXX proc. without specifying the dsname of the library that contains the member (by using %member). The search of the member will be made in SYSEXEC, and then in SYSPROC.

In interactive mode, calls have to contain dsnames of libraries (they are transmitted in CPRLIB and CEXLIB ISPF variables):

  • EXEC '&CPRLIB(clist)'

or

  • EXEC '&CEXLIB(rexx)' EXEC

If you don't want to mention the dsname of these libraries, you then need to allocate them in the TSO logon procedure.

Nevertheless, the last two calls are also valid in batch mode.

XPROC procedures​

The internal procedures of INFO-RECOVERY have their own syntax. These procedures exist in the INFO-RECOVERY parmlib (ex.: CSRFIC, CSRREC). They are called through the PROC= parameter.

XPROC procedures have four main functions:

  • File tailoring of ISPF skeletons

    "EXEC=FT, NAME=skeleton name"

  • Call of a clist or a REXX procedure

    "EXEC=CLIST, NAME=clist or rexx procedure name"

  • Call of an other XPROC procedure

    "EXEC=PROC, NAME=procedure name"

  • Execution of an SQL statement

    "EXEC=SQL, NAME=request name"

Nomenclature Convention​

INFO-RECOVERY generally allows the creation of DUAL objects (ICs, UICs, FICs, IICs, CAs, etc...). These objects are not necessarily referenced in DBRC (UIC, CA) or in DB2 catalog (dual FIC/IIC before V2R3).

INFO-RECOVERY sets the following convention: an object is missing if it is not cataloged (ICF). With this convention, INFO-RECOVERY searches to solve the problem created by the missing object and will use an equivalent if possible.

Thus, a missing primary IC requires the use of a secondary if it exists. For the LOGs, the analysis is less simple because INFO-RECOVERY may use the SLDS if no RLDS is available. If the substitution is not possible, INFO-RECOVERY will use not cataloged objects.

The automatic substitution mechanism is based on the nomenclature used by INFO-RECOVERY: the dsname of a dual object is derived from the dsname of the primary object by changing the ending character of the second index to S from P.

Job Scheduling​

INFO-RECOVERY functions are designed to be scheduled by operations staff using a job management system (JOBMS). This section covers requirements for the use of INFO-RECOVERY with a job management system.

Backup copy operations (IC or FIC) must be run in a relationship of mutual exclusivity with regard to application jobs updating the same data. Such a relationship is less strong than an explicit dependence. It means that an image copy and an application job cannot run at the same time. However, as there is no dependence, an interruption of the application will have no effect on the scheduling of the image copy and an interruption of the image copy will not affect the scheduling of the application. The goal achieved by the exclusivity is only to keep both types of operations efficient.

The security of an application is obtained by VIC steps which are synchronous with the application.

To achieve mutual exclusivity within the framework of INFO-RECOVERY, the users must use the option JOBCHECK=Y (default value in the CUSTOM member of the parmlib). Indeed, because of this option, the jobs generated by a function of INFO-RECOVERY are synchronized. The request will finish when the generated job is finished. Also, if one of the generated jobs abends, the request will abend as well. The function may be seen as one single task and easily scheduled.

The verification of the work performed by INFO-RECOVERY functions is controlled by JOBMS. Indeed, the requests are scheduled and known by JOBMS. Their execution is correct when all the generated jobs are correct (ABEND 4001 if one of the generated job abends). Thus, you only have to consult the result of the generated jobs in case of anomaly.

A constraint of the recovery is that within IMS, a recovery makes it necessary to refrain from any change accumulation activity until the next image copy (see the description of CS1RECOV in the INFOVIC documentation - HR103). This condition can be automatically satisfied using the following method:

  • A recovery event (abr. RE) is defined for each application.

  • Change accumulations are scheduled under condition non-RE for the corresponding application.

  • Image copies are scheduled with a reset of the RE condition of the corresponding application after the correct completion of the generated job.

  • Event RE is activated by a recovery.

Summary Table of ISPF Variables​

System Variables​

Name Length Pool Description BATCH 1 shared type of processing indicator (Y/N)

CSASID 4 shared address space identifier

CSFATHER 8 shared name of the generating job (TSO user in interactive mode)

CSMARKDL 7 shared current timestamp packed decimal

DEFJOBP 1 shared name of the generating job found in the clist JOBCARD

HHMMSSD 7 shared time of the execution

SYSID 4 shared identifier of the MVS system of execution

YYMMDD 6 shared date of execution

YYQQQ 5 shared date of execution

: System variables

Site Variables - All Products​

Name Length Pool Default Description CEXLIB 44 shared - user execlib indicated in the member SYSIDS of the current parmlib

CLASS 1 shared - job execution class, indicated in the member SYSIDS of the currentparmlib

CPLIB 44 shared - current parmlib used in the current execution

CPRLIB 44 shared - user proclib indicated in the member SYSIDS of the current parmlib

CULIB 44 shared - user parmlib indicated in the member CTRLRUN of the current parmlib

CUSER 1 shared - use indicator of user parmlib

CXLOAD 44 shared - loadlib indicated in the member PRODUCTS of the current parmlib

DEFACCNT < 142 shared - the account of the generated card job, indicated in the member CUSTOM

DEFJOB 1 shared - job name to submit. Set by clist JOBCARD at the beginning of the execution, will be taken into account in the JCL if JOBNAME is notset in the member CUSTOM.

DEFMSGCL 1 shared X MSGCLASS parameter of the generated job card, indicated in the memberCUSTOM

DISKGRP 8 shared SYSDA disk allocation unit of disk files generated by INFO-RECOVERY,indicated in the member CUSTOM

DISKMSYS 8 shared DFHSM name of the disk management system, indicated in the member CUSTOM

DISKUNIT 8 shared SYSALLDA DASD unit type, indicated in the member CUSTOM

DPLIB 44 shared - default parmlib referenced in the module CSXEXEC, (see manualHR104)

JOBCHECK 1 shared Y control indicator of submitted jobs (Y/N), mentioned in the member CUSTOM

JOBMSYS 8 shared UCC7 name of the job management system, indicated in the member CUSTOM

JOBNAME 8 shared blank job name of the generated job card, indicated in the member CUSTOM

JOBQTIME 4 shared 0005 maximum wait time for the start of the job, indicated in the memberCUSTOM

JOBWAIT 4 shared 10 cyclic wait time for the start of the job, indicated in the member CUSTOM

PERFORM 4 shared blank MVS non swapable performance group, indicated in the member CUSTOM

PRFPLIB 1 profile - current parmlib used in interactive execution

PRFULIB 1 profile - user parmlib indicated on the CONFIG panel - interactive execution

PRFUSER 1 profile - user parmlib indicator mentioned on CONFIG panel - interactive execution

PSW 8 shared blank PASSWORD parameter of the generated job card, indicated in the memberCUSTOM

RC 4 shared 0 value of return code that replaces the 4001 abend of the batch execution,indicated in the member CUSTOM;the default 0 means no conversion

SORTLIB 44 shared - sortlib indicated in the member SYSIDS of the current parmlib

TAPEGRP 4 shared 3480 tape allocation unit for tape files generated by INFO-RECOVERY,indicated in the member CUSTOM

TAPEMSYS 8 shared TLMS name of the tape management system, indicated in the member CUSTOM

TPLIB 44 shared - test parmlib indicated in the member PRODUCTS of the current parmlib

TYPRUN 1 shared blank TYPRUN parameter of the generated job card, indicated in the member CUSTOM

USER 7 shared blank USER parameter of the generated job card, indicated in the member CUSTOM

WORKGRP 8 shared SYSALLDA disk unit for allocation of work files, indicated in the member CUSTOM

XDATE 1 shared DD/MM/YY date format, the default can be changed by the parameter XDATE of the member PRODUCTS

: Site variables - all products

Site Variables - INFOREC1 and/or INFOVIC1 Products​

Name Length Pool Default Description ACBLIB 44 shared - dsname of the ACBLIB that contains the ACBs used by INFO-RECOVERY,indicated in the member IMSIDS

AGNAME 8 shared NONE authorized application group name for the processed IMS,indicated in the member IMSIDS

AMSLIB 44 shared - dsname of the AMS source library for RECONs files, indicated in the member IMSIDS

CS1RECON 44 shared - dsname of the specific RECON dataset of INFOVIC1, indicated in the member IMSIDS

DBDLIB 44 shared - dsname of the DBDLIB used by DBRC, indicated in the member IMSIDS

DBRCFORC 1 shared N DBRC mandatory indicator (Y/N), indicated in the member IMSIDS

DUMMYDB 8 shared SWITCH DBD used by the OLDS switch command, indicated in the member IMSIDS

DYNLIB 44 shared - dsname of the DYNLIB that corresponds to the processed IMS, indicated in the member IMSIDS

IMSAL 4 shared - cataloged alias of IC/CA dsnames, indicated in the member IMSIDS

IMSID 4 shared - identifier of the processed IMS system, indicated in the PARM listof CSXEXEC, otherwise default of the member SYSIDS

IMSLEVEL 4 shared 130 IMS version, indicated in the member IMSIDS

IMSPROC 44 shared - dsname of the PROCLIB that corresponds to the processed IMS, indicated in the member IMSIDS

OPTIMIZE 1 shared N optimization of IC choice parameter, indicated in the member IMSIDS

PRFIMSID 4 profile - identifier of the processed IMS system, indicated on the panelCONFIG - interactive execution

PSBLIB 44 shared - dsname of the PSBLIB that contains the PSBs used by INFO-RECOVERY,indicated in the member IMSID

RECONLIB 44 shared - dsname of the dynamic allocation library for RECONs files, indicatedin the member IMSIDS

RESLIB 44 shared - dsname of the RESLIB that corresponds to the processed IMS, indicatedin the member IMSIDS

: Site variables - INFOREC1 and/or INFOVIC1 products

Site variables - INFOREC2 and/or INFOVIC2 products​

Name Length Pool Default Description CS2RECON 44 shared - dsname of the specific RECON file of INFOVIC2, indicated in the member DB2IDS

DB2AL 4 shared - cataloged alias of FIC/IIC dsnames, indicated in the member DB2IDS

DB2BSDS 44 shared - dsname of the BSDS of the processed DB2, indicated in the member DB2IDS

DB2EXIT 44 shared - dsname of the EXITLIB of the processed DB2, indicated in the member DB2IDS

DB2ID 4 shared - identifier of the processed DB2 system, indicated in the PARM list of CSXEXEC, otherwise default of the member SYSIDS

DB2LIB 44 shared - dsname of the LOADLIB of the processed DB2, indicated in the memberDB2IDS

PLAN 7 shared CSnPLAN plan used by INFO-RECOVERY, indicated in the member DB2IDS

PRFDB2ID 4 profile - identifier of the processed DB2 system, indicated on the panel CONFIG - interactive execution

VSAMCAT 8 shared NONE cataloged alias of directory dsnames, indicated in the member DB2IDS

ACCESS 8 shared SQL access mode to the DB2 catalog, indicated in the member DB2IDS

SITETYPE 12 shared LOCALSITE type of current DB2 subsystem, indicated in the member DB2IDS

: Site variables - INFOREC2 and/or INFOVIC2 products

Parmlib Members Describing the Site's Characteristics.​

PRODUCTS​

Syntax​



P0 NAME=INFOREC, INFOREC product.
FUNCTION=(CSXEXEC, Function list
\...\.....,
\...\.....),
CLOAD=cload, Current loadlib dsname.
* Dsname of the MVSLOAD library
* (if first installation)
TEST=Y/N, Test mode Y/N.
TPLIB=tplib, Test parmlib dsname.
XDATE=format Date format.
*
PV NAME=INFOVIC, INFOVIC product.
FUNCTION=(function, Function list.
\...\.....,
\...\.....)
* Comment.
P1 NAME=INFOREC1, INFOREC1 product.
FUNCTION=(function, Function list.
\...\.....,
\...\.....)
* Comment.
P2 NAME=INFOREC2, INFOREC2 product.
FUNCTION=(function, Function list.
\...\.....,
\...\.....)

SYSIDS​

Syntax​



* Comment.
S1 SYSID=sysid, MVS sysid.
SYSAFF=sysaff, job execution system.
CLASS=A, A default class for this system.
ISPMLIB=ispmlib, ISP message library dsname.
ISRMLIB=isrmlib, ISR message library dsname.
ISPTLIB=isptlib, ISP tables library dsname.
ISRTLIB=isrtlib, ISR tables library dsname.
SORTLIB=sys1.sortlib, Sort library.
LINKLIB=linklib, User linklist library for CSXEXEC.
PROCLIB=proclib, User CLISTS library.
EXECLIB=execlib, REXX programs library.
DEFIMSID=imsid, Default IMSID on this MVS.
DEFDB2ID=db2id Default DB2ID on this MVS.
* Comment.
S2 SYSID=sysid, A second entry\...
\...

IMSIDS​

Syntax​



* Comment.
I1 IMSID=imsid, IMS imsid.
ALIAS=alias, cataloged alias for IC/CA dsn(s).
* (must be \<= 4 characters).
LEVEL=level, IMS level 810, 910, A10 for V10, B10 for V11
* C10 for V12 and D10 for V13
OPTIMIZE=Y/N, IC optimization choice.
DUMMYDB=dummydb, Dummy DB for OLDS switch.
PSBNAME=(psb1,\...), Pool list of AOP PSBs.
TRNNAME=(trn1,\...), The associated transactions.
AGNAME=agn, Application Group name.
DBRCFORC=Y/N, DBRC mandatory (Y/N).
DBCTL=Y/N, The automatic operator DBCTL
* to be used or not.
DBDLIB=dbdlib, IMS dbdlib dsname.
PSBLIB=psblib, IMS psblib dsname.
ACBLIB=acblib, IMS acblib dsname.
MACLIB=maclib, IMS maclib dsname.
PROCLIB=proclib, IMS proclib dsname.
RESLIB=reslib, IMS reslib dsname.
DYNLIB=dynlib, IMS DB dynamic allocation library
* dsname.
AMSLIB=amslib, AMS source library for
* RECONs datasets.
RECONLIB=reconlib, Recon dynamic allocation library
* dsname.
CS1RECON=cs1recon, VIC recon dsname. (One per DBRC)
CS1RECVO=cs1recvo VIC recon volume.
* Comment.
I2 IMSID=imsid, A second entry\...
\...

IMSDSGS - Description of the IMS Data Sharing Groups​

Syntax​



* Comment.
I1 IMSDSG=imsdsgid, IMS DATA SHARING GROUP.
ALIAS=alias, Cataloged alias for IC/CA dsn(s).
* (must be \<= 4 characters).
LEVEL=level, IMS level 810, 910, A10 for V10, B10 for V11
* C10 for V12 and D10 for V13
IMSREG=IMSG, control regions for BMP of group
* (IMSGROUP in DBC procedure)
SYSGRP=*ALL, system group name for route command
CRC=/, command recognition char (DEF.\"/\")
* (CMDCHAR in IMSCTRL MACRO)
OPTIMIZE=Y/N, IC optimization choice.
DUMMYDB=dummydb, Dummy DB for OLDS switch.
PSBNAME=(psb1,\...), Pool list of AOP PSBs.
TRNNAME=(trn1,\...), Associated transactions.
AGNAME=agn, Application Group Name.
DBRCFORC=Y/N, DBRC mandatory or not mandatory (Y/N)
DBCTL=Y/N, The DBCTL automatic operator.
* to be used or not.
SHRIWAIT=0 IMS DATASHARING WAIT TIME (SECONDS)
* FOR SWITCH (DEFAULT 0)
DBDLIB=dbdlib, IMS DBDLIB dsname.
PSBLIB=psblib, IMS PSBLIB dsname.
ACBLIB=acblib, IMS ACBLIB dsname.
MACLIB=maclib, IMS MACLIB dsname.
PROCLIB=proclib, IMS PROCLIB dsname.
RESLIB=reslib, IMS RESLIB dsname.
DYNLIB=dynlib, IMS DB dynamic allocation library
* dsname
AMSLIB=amslib, AMS source library for RECONs
* datasets.
RECONLIB=reconlib, RECON dynamic allocation library
* dsname.
CS1RECON=cs1recon, VIC RECON dsname (one per DBRC)
CS1RECVO=cs1recvo VIC RECON volume.
* Comment.
I2 IMSDSG=imsdsgid, A second entry\...
\...

THT - Local Time Description​

Syntax​

The THT member is used to allocate the CS1THTAB data set that is specific to IMS functions. INFO-RECOVERY uses this data set for IMS version 6 (or later) that works in NOCOEX-mode. The CS1THTAB data set is automatically created by the installation process (installation of INFOREC1 using the interactive menu).

The CS1THTAB data set is used to manage the local time/hour thus memorizing the local time/hour intervals defined by their offsets, in number of quarters of an hour, related to the universal time.

The CS1THTAB data set is not dual and does not need to be saved because INFO-RECOVERY can easily reconstruct this data set.


*
CS1THTAB=cs1thtab, dsname of the THTAB data set
*
CS1THTVO=cs1thtvo, volume of the THTAB data set
*

Description of the parameters​

{wrapper="1" role="DL"}

  • CS1THTAB=cs1thtab

    dsname of the CS1THTAB data set that is specific to INFOREC1 and INFOVIC; one single data set for the whole of IMS systems.

  • CS1THTVO=cs1thtvo

    volume associated with the CS1THTAB data set.

DB2IDS​

Syntax​



* Comment.
D1 DB2ID=db2id, DB2 db2id.
ALIAS=alias, Cataloged ALIAS of FIC/IIC dsn(s).
* (must be \<= 8 characters).
PLAN=CSnPLAN, Plan to be used for products
* n-parmlib.
OWNER=owner, owner of the plan.
DB2BSDS=db2bsds, BSDS dsname to be used for this
* db2id.
DB2EXIT=db2exit, DB2 exitlib dsname (contains DSNHDECP).
DB2LIB=db2lib, DB2 loadlib dsname.
VSAMCAT=vsamcat, Cataloged ALIAS for directory dsnames.
ACCESS=access, DB2 catalog access mode SQL/QFAST/FAST
DEFINENO=N, DEFINE NO option is used: Y/N
* for creating TS or IX.
SITETYPE=sitetype, DB2 site type LOCALSITE/RECOVERYSITE
TDEVTYPE=tdevtype, ICs tape unit type used with TDEVNUM
TDEVNUM=n, number of tape units of type TDEVTYPE
to be used for FICs/IICs input data sets
CS2RECON=cs2recon, VIC recon dsname. (One per DB2)
CS2RECVO=cs2recvo VIC recon volume.
* Comment.
D2 DB2ID=DB2ID, A second entry\...
\...

DB2DSGS - Defining DB2 Data Sharing Groups​

Define DB2 data sharing groups when using data sharing in your environment.

The name of the DB2DSG is used to identify the DB2 sub-system where under INFO-RECOVERY is executed according to the system where the job is started.

Syntax​



* Comment.
D1 DB2DSG=NONE, GROUP ATTACHMENT NAME
DB2NAME=(\...,\...,\...), DB2 LIST
SYSNAME=(\...,\...,\...), SYSTEM LIST
*
D2 DB2DSG=NONE, GROUP ATTACHMENT NAME
DB2NAME=(\...,\...,\...), DB2 LIST
SYSNAME=(\...,\...,\...), SYSTEM LIST
*

{wrapper="1" role="DL"}

  • DB2DSG=db2dsg

    identifier of the DB2 data sharing group (group attachment name); this name can be set into the DB2ID parameter of the EXEC card.

    Specify DB2DSG=NONE when using INFO-RECOVERY in a non-SYSPLEX environment.

  • DB2NAME=(db21,...)

    Specifies the list of the DB2 IDs that belong to the data sharing group mentioned above; these DB2 IDs are to be specified in the member DB2IDS.

  • SYSNAME=(sys1,...)

    Specifies the list of systems where the DB2s of the group are processed.

    sysn is related to db2n

CUSTOM​

Syntax​



* Comment.
JOBCHECK=Y/N CHECK jobs submitted by the
* Products (Y/N).
JOBWAIT=jobwait, Wait job queued time interval
* (seconds).
JOBQTIME=jobqtime, Max queue time for a job (HHMM).
PERFORM=perform, A non-swapable MVS perform group.
TAPEMSYS=tapemsys, TAPE management system.
DISKMSYS=diskmsys, DISK management system.
JOBMSYS=jobmsys, JOB management system.
UCC7PSW=, Reserved.
WORKGRP=workgrp, Default work group.
DISKGRP=diskgrp, Default disk group.
TAPEGRP=tapegrp, Default tape group.
DISKUNIT=diskunit, Dasd unit type (3350, 3380)
MAXPRIM=, Primary allocation for
* multivolume file (disk)
MAXUNIT=, Max number of disk volumes for
* one file (FIC).
TYPRUN=typrun, Clear the jobcard typrun value.
USER=user, Clear the jobcard user value.
PSW=psw, Clear the jobcard password value.
JOBNAME=jobname, Job name for the generated JCL.
RC=retcode, Return code that replaces abend 4001.
DEFACCNT=\"ACCOUNT\", Default accounting.
DEFMSGCL=defmsgcl Default MSGCLASS.

Purge of VIC RECON data sets​

There are three ways to delete RECON VIC file records :

{wrapper="1" role="DL"}

  • Automatic purge

    As new records on the RECON VIC data set are inserted, the newly obsolete records are automatically deleted. See the chapter « automatic purge » below.

  • Manual purge

    One can manually force the deletion of records which are not part of the automatic purge. See the chapter « manual purge » below.

  • Reset

    One can recreate the RECON VIC file associated to a DB2 or to an IMS.

    warning

:

As resetting the RECON VIC data set removes all the VIC points, only the VIC points created after the reset operation can be used for a RECOVER to a VIC point. For more details, see the chapter "INFOVIC - Installation" in the documentation INFO-RECOVERY Installation (HR104).

Automatic purge​

When a VIC point is taken for a DLI base or a DB2 tablespace, an automatic purge of old VIC points for this base or for this tablespace is performed.

The automatic purge only concerns the objects involved in the VIC point being taken.

The automatic purge removes the former VIC points that can no longer be used for a RECOVER to a VIC point, namely:

  • The VIC points older than the oldest Image Copy for DLI bases.

  • The VIC points older than the oldest Full Image Copy for DB2 tablespaces.

To ensure that the purge mechanism actually removes useless VIC points, it is important to run the CS1DLET1 and CS1DLET2 programs so that only the Image Copy and Full Image Copy meeting recovery requirements are kept.

Manual Purge​

The Manual Purge feature allows you to request the deletion from the VIC RECON data set of the records which are not deleted by the automatic purge.

For example, this is the case after the deletion of a DLI base or a DB2 tablespace DROP. Since there are no new VIC points on these objects, the existing VIC points persist in the VIC RECON data set.

Operating principle​

The manual purge feature affects all the VIC RECON data sets specified via the CS1RECON parameter from the IMSIDS and IMSDSGS members of the PARMLIB and the ones specified by for the CS2RECON parameter in the DB2IDS member regardless of the related subsystems (DL1 or DB2) being involved in a DLI plex or a DB2 data sharing group.

Use​

The JCL to execute for the manual purge can be found in the £CSJXCLR member of the PARMLIB displayed hereafter.



//JOBNAME JOB ACCOUNT,\'INFOREC CLEANUP\', MSGCLASS= ,CLASS= ,
// NOTIFY=&SYSUID
//*
//* £CSJXCLR - INFO-RECOVERY UTILITY TO DETETE OBSOLETE
//* RECORDS FROM THE CS1VIC RECON DATA SETS.
//*
//* BEFORE USING THIS PROCEDURE, SET THE JOB CARD PARAMETERS
//* AND THE FOLLOWING PARAMETERS :
//*
// SET INFPLIB= ??HLQ??.INFPLIB
// SET MONTHAGE=12
// SET SAVESUF=SAVE
// SET OUTCLASS=*
//*
//* INFPLIB : SPECIFY THE DSNAME OF THE PARMLIB.
//* MONTHAGE : AGE (IN MONTH). VIC POINT OLDER THAN THE AGE SPECIFIED
//* WILL BE REMOVED.
//* SAVESUF : SUFFIX TO ADD TO THE DSNAME OF RECON DATASET FOR
//* SAVING IT BEFORE DELETION.
//* OUTCLASS : OUTPUT CLASS FOR SYSOUT.
//*
//*******************************************************************
//* DO NOT CHANGE ANYTHING PAST THIS POINT
//*******************************************************************
//CLEANUP EXEC PGM=IKJEFT01,PARM=\'XECXCLR &MONTHAGE &SAVESUF\'
//SYSEXEC DD DISP=SHR,DSN=&INFPLIB
//SYSTSPRT DD SYSOUT=&OUTCLASS
//SYSPRINT DD SYSOUT=&OUTCLASS
//SYSTSIN DD DUMMY

Before submitting the JCL It is only authorized to amend the content of the JOB card and of the following parameters:

{wrapper="1" role="DL"}

  • INFPLIB.

    Name of the PARMLIB library : it is essential to specify the name of the library containing the currently edited £CSJXCLR member.

  • MONTHAGE.

    Specify the number of months for which you want to keep the VIC points. For example, with MONTHAGE=3, for a JCL executed on May 16th, 2012, the VIC points prior to May 16th, 2012 are deleted. The considered date for a VIC point is its GMT date.

    Default value: 12. This value is used if the parameter is absent or non-numerical.

    Minimal value: 1. This value is used if the coded parameter is numerical and smaller than this value.

  • SAVESUF.

    During the deletion, a backup copy of the VIC RECON data sets is made. The name of the backup cluster is obtained by adding a suffix to the name of the VIC RECON cluster. For example, for the INFOTEL.RECONVIC.IMSA cluster, the backup cluster is INFOTEL.RECONVIC.IMSA.SAVE. In case of failure, the backup cluster is kept. In case of success, the backup cluster is deleted at the end of the process.

  • OUTCLASS.

    Class for SYSOUT files.

Return code​

The list below shows the signification of the codes returned by the manual purge function:

  • 0.

    all the necessary purges have been performed

  • 4.

    the purge has not been performed. The exclusive use of RECON VIC failed.

  • 8.

    Errors have occurred. The VIC RECON data sets are not damaged. No manual operation is necessary for using InfoVic further.

  • 12.

    Fatal errors have occurred. The mandatory restore procedure of the VIC RECON is explained in the paragraph « In case of fatal error » below.

  • 20.

    Launch error. No operation is performed.

In case of fatal error​

The instructions below concern the case where the manual purge JCL ends with a code 12. In this case, the IC RECON data set is damaged and it must be restored from the backup before taking new VIC points or performing RECOVER to a VIC point for the concerned IMS or DB2 subsystem.

  1. Search in the report for the following messages: CSXCLR-110S or CSXCLR-111S. If the CSXCLR-110S message is found, this means the VIC RECON doesn't exist anymore. If the CSXCLR-111S message is found, this means the VIC RECON exists but some VIC points are missing.

  2. The preceding CSXCLR-100I message gives the name of the concerned VIC RECON data set, the name of the concerned IMS or DB2 system and the name of the PARMLIB member where the RECON has been found.

  3. Determine the name of the backup cluster by adding the relevant suffix (specified as the value for the SAVESUF parameter of the purge JCL) to the cluster name (for example: INFOTEL.RECONVIC.IMSA.SAVE).

  4. Restore the RECON with the following JCL:


    //RESTORE EXEC PGM=IDCAMS
    //VICRECON DD DSN=vic-recon,DISP=OLD
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD *
    DELETE vic-recon
    SET MAXCC = 0
    DEFINE CLUSTER(NAME(vic-recon) -
    MODEL(backup-recon))
    REPRO IDS(backup-recon) -
    ODS(vic-recon)

vic-recon designates the name of the damaged VIC RECON cluster.

backup-recon designates the name of the backup cluster previously determined.

The VICRECON DD card makes sure of the exclusive of the VIC RECON data set during the restore operation. If the cluster doesn't exist (if the message CSXCLR-110S was issued or if an error at the DEFINE on a previous restore operation attempt), this card must be set in comment.

In case of a failure, check the system messages. This JCL must be resubmitted till it ends successfully. To do so, you might need to modify the JCL, for example to specify the volume on which the cluster must be recreated.

  1. Once the restore operation has been carried out with success, you can delete the backup cluster, with the following JCL:

    //DELSAVE EXEC PGM=IDCAMS
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD *
    DELETE backup-recon
    //*