Role of DBRC in recovery of IMS Database

Database recovery, in its simplest form, is the restoration of a database after its (partial) destruction due to some failure. In order to facilitate this process, some forward planning needs to be done. Periodically, a copy of the data in the database is saved. This copy is normally referred to as a backup or image copy. These image copies can reside on DASD or cartridges. Though this process can be done anytime, it is normally done when there is no other database activity at the same time.

IMS DB Jobs

IMS DB Jobs

This creates a complete backup. There are other strategies for taking a database backup, but they will not be discussed in this book. In addition to taking an image copy of the database(s), all changes made to the data in the database can be logged and saved, at least until the next image copy. These changes are contained in data sets called log data sets. This provides a complete recovery environment so that no data is lost in the event of a system or application failure.

There is an IMS facility called database recovery control (DBRC) which provides database integrity and can be used to help ensure that there is always a recovery process available. The use of DBRC to control database backup and recovery is not mandatory, but is highly recommended.

When you need DBRC recovery in IMS DB

  1. A DLI batch update job fails after making at least one database update.
  2. A failure has occurred on a physical DASD device.
  3. A failure has occurred in a database recovery utility.
  4. A failure of dynamic backout or batch backout utility has occurred.
  5. An IMS online system failure and emergency restart has not been completed.

Why financial Banks Accessing Mainframe Applications from Mobile

Mainframe z13

IOT for Smart Cities

IOT for Smart Cities

included powerful features in Accessing Mainframe Applications from mobile.

  • On the fly data encryption when data transfers from mobile in the reaching of Mainframe
  • Handles huge volume of data coming from various mobile devices

  • On the fly data analytics, while data coming from mobile devices

Recently Citi bank started mobile applications to have access to Mainframe. Because Mainframe is trusted computing service for all world leading banks.   And strong security is one of the plus point. Definitely the above features in z13 architecture helps all world leading banks to go for Mainframe access with mobile devices.

How File Read in CICS with UPDATE Option Maintains Integrity

CICS follows data integrity in different ways for different file types.

CICS File UPDATE

CICS File UPDATE

UPDATE guarantees read integrity. The mechanism used to ensure data integrity depends on the type of file resource:

  • For a VSAM file accessed in RLS mode, the record to be updated is locked by the SMSVSAM server.
  • For a VSAM file accessed in non-RLS mode, the record to be updated is locked by CICS and, in addition, the control interval containing the record is held in exclusive control by VSAM.
  • For a VSAM file accessed in non-RLS mode, and log(UNDO), CICS holds a record lock until the task syncpoints.
  • For a BDAM file, the record to be updated is held in exclusive control by BDAM.
  • For a user-maintained data table, the record to be updated is locked by CICS.
  • For a CICS-maintained data table, the record to be updated is locked by CICS and, in addition, the control interval containing the record is held in exclusive control by VSAM. The VSAM control interval lock is required because changes to the data table are reflected in the source data set, which is accessed in non-RLS mode.

JCL: GDG Create, Delete, Alter, GDGs all Examples

GDG Sample JCLs

GDG Sample JCLs

  1. Create a GDG file. This JCL calling IDCAMS will do it. In this example LIMIT(15) is the number of generations you wish to create and keep. Of course, change the GDG file name to your requirements:
    //STEP1 EXEC PGM=IDCAMS
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD *
    DEFINE GDG(NAME(STEWART.APPLY.LOG.GDGROUP1) –
    LIMIT(15) –
    NOEMPTY –
    SCRATCH)
    /*
  2. Create a model or template for the individual generations of data sets. Here the default DCB attributes for the Apply or Capture log were used. Note that the space is rather small (5 tracks) in this example so you might want to increase it.
    //STEP020 EXEC PGM=IEFBR14
    //GDGMODEL DD DSN=STEWART.APPLY.LOG.GDMODEL1,
    // DISP=(NEW,KEEP,DELETE),
    // UNIT=SYSDA,
    // SPACE=(TRK,5),
    // DCB=(LRECL=1024,RECFM=VB,BLKSIZE=6144,DSORG=PS)

  3. As a test you can create your first generation of data sets by running this JCL example. Each time you run this step a new generation of data set will be created in your group.
    //STEP010 EXEC PGM=IEBGENER
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD DUMMY
    //SYSUT1 DD *
    TEST DATA LINE 1
    TEST DATA LINE 2
    /*
    //SYSUT2 DD DSN=STEWART.APPLY.LOG.GDGROUP1(+1),
    // DISP=(NEW,CATLG,DELETE),
    // SPACE=(TRK,5),
    // DCB=STEWART.APPLY.LOG.GDMODEL1

After you have created several generations of log files an ISPF 3.4 display of your GDG would look like this:
STEWART.APPLY.LOG.GDGROUP1
STEWART.APPLY.LOG.GDGROUP1.G0003V00
STEWART.APPLY.LOG.GDGROUP1.G0004V00
STEWART.APPLY.LOG.GDGROUP1.G0005V00
.
.
.
STEWART.APPLY.LOG.GDMODEL1
The ISPF 3.4 screen header will also tell you how many generations of datasets you have. For example:
Data Sets Matching STEWART.APPLY.LOG.GDGROUP1.G* Row 1 of 15
There are 15 generations of the dataset.

  1. Because the Apply or Capture log file is not referenced by a DD statement you must use IEBGENER to copy your app.log or cap.log file to the GDG. Place this step ahead of your Apply or Capture JCL. This step creates a new generation of data in your group. Consider using the LOGREUSE=N parm when you start Capture or Apply so that each generation of the log is unique to the specific instance when Capture or Apply was run.
    //COPYLOG EXEC PGM=IEBGENER
    //SYSPRINT DD SYSOUT=*
    //SYSUT1 DD DSN=STEWART.DSN9.STEVE1.APP.LOG,
    // DISP=SHR
    //SYSUT2 DD DSN=STEWART.APPLY.LOG.GDGROUP1(+1),
    // DISP=(NEW,CATLG,DELETE),
    // SPACE=(TRK,5),
    // DCB=STEWART.APPLY.LOG.GDMODEL1
    //SYSIN DD DUMMY
    //SYSOUT DD SYSOUT=*
    //SYSUDUMP DD SYSOUT=*
  • If you need to delete your GDG, delete the individual data sets (G0003V00, G0004V00, etc.) and then run this IDCAM job to delete the GDG.
    //STEP010 EXEC PGM=IDCAMS
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD *
    DELETE (STEWART.APPLY.LOG.GDGROUP1) GDG FORCE
    /*

  • Finally, this example of a GDG was created with 15 generations of data sets using the LIMIT(15) parameter. If you wish to change the number of generations run this IDCAMS alter example where the number of generation is increased to 50. Use the GDG name in the ALTER statement that you created from Step 1.
    //STEP010 EXEC PGM=IDCAMS
    //SYSPRINT DD SYSOUT=*
    //SYSIN DD *
    ALTER STEWART.APPLY.LOG.GDGROUP1 LIMIT(50)
    /*
    The maximum value for LIMIT is 255.

    Ref:IBM

    How CICS RLS Mode handles during Files Updates

    This is possible by using RLS -Record Level Sharing

    Sysdump Vs Sysudump

                                             SYSDUMP Vs SYSUDUMP

    Record-level sharing (RLS) is a VSAM function, that enables VSAM data to be shared, with full update capability, between many applications running in many CICS regions.

    RLS Mode Other Advantage:

    With RLS, CICS regions that share VSAM data sets can reside in one or more MVS™ images within an MVS parallel sysplex. RLS also provides some benefits when data sets are being shared between CICS regions and batch jobs.

    If you open a file in RLS mode, locking takes place at the record level instead of the Control-Interval level, thus reducing the risk of deadlocks.

    CICS supports record-level sharing (RLS) access to the following types of VSAM data set:

    • Key sequenced data sets (KSDS). Note that if you are using KSDS, you cannot use the relative byte address (RBA) to access files.
    • Entry sequenced data sets (ESDS). Note that although RLS access mode is permitted for entry sequenced data sets (ESDS), it is not recommended, as it can have a negative effect on the performance and availability of the data set when you are adding records. (See Performance aspects of VSAM record-level sharing ).
    • Relative record data sets (RRDS), for both fixed and variable length records.