Skip to main content



The Concept of Check pointing is to Save the data permanently in the database till the Last Checkpoint in case of an Abend in the Program after taking a Checkpoint. In the case of an abend the DBA will automatically back out (reverse) the changes made to the Database after the Checkpoint. So if we RESTART the Program after an abend, the program will use the Last Check pointing Information for restarting. There are various ways for Checkpoint/Restart.

1. With the Help of a Restart File: -

This type of Check pointing will need a Restart File. In this type, while taking each Checkpoint we will store the Checkpoint ID, with the Necessary Save Area in CC5DAP database. The Checkpoint ID will be usually the Time at which that particular Checkpoint was taken. For Restarting this type of Programs, there will be two Steps.

The first step will put the Stored CC5DAP data corresponding to the Last Checkpoint to a Restart File.

The Second Step will read this Restart File, correctly gets positioned in the Database where the Last Checkpoint was taken (for e.g.:- if it is a Sequential execution in a database), and starts Execution from that point.

2. With the Help of a BMP(Batch Message Processing) Record:-

This is the Latest Technique being used for taking Checkpoint. In this case NO Restart File or CC5 Database is required for Restarting the Program in case of an abend. It uses a BMP Record to get back all the information about the last Checkpoint.

Here the Checkpoint Id will be 8 characters (4 character Program Identification ID + Sequence Id).

For e.g.: - if your Program is BMD001CP, you can put the Program Identification ID as 'BMD1'. The

Sequence Id contains the number of the Last Checkpoint.

(e.g.:- if it is the 19th Checkpoint, Sequence ID will be 0019).

During Restart of the Program, it will automatically read the corresponding BMP Record and gets all stored information regarding the Last Checkpoint.


sanjuu said…
awesome explanation..!!!

we can implement this tech nick in program also using commit frequence..:)

Popular posts from this blog


In DB2, the columns defined as NULL needs to be handled carefully else it will throw null exception error, in order to over come this error data type can be handled by using null indicator.
NULL is stored using a special one-byte null indicator that is "attached" to every nullable column. If the column is set to NULL, then the indicator field is used to record this. Using NULL will never save space in a DB2 database design - in fact, it will always add an extra byte for every column that can be NULL. The byte is used whether or not the column is actually set to NULL. The indicator variable is transparent to an end userConsider below Table :
Note :: Unless you specify NOT NULL, the default is to allow for NULLIn above table SN and SNAME columns holds null values by default, in order to handle these null variables we need to have NULL-INDICATORS declares in the Program as

How to Solve SOC7 Abend - with screen shots

Below process helps to find out the statement, caused the SOC7 error.

Check the Sysout of RUNJCL. This shows the error statement and lists offset valueTake the Offset Value 000003C0Got to respective Compilation Job listing, check the sysprint Search for the offset value 0003C0 (delete +00 -- initial 3 letters of Offset value and search for it) check below 2 screen shotsThis Offset value is listed under line no 0045 – which refers to Move statement.
Take this no. 045 and find for it in same sysprint. This points to the exact statement, caused SOC7 This 045 pints to the Move statement 1526, this is the exact line in the programCheck for the above line no. In source program. This points to the statement highlighted below. Check the statement, variable check-4, which is added to check-6. These are having different Picture clause.check-4 is alfhanumaric, holding some junk data, when this data is moved to Chcek-6 variable(of comp-3) creates SOC7 error.This is just an example to explain one ca…

DB2 Utilities and Commands (helpful for DB2 Certification)

• Utilities
– Image Copy
– CDB SuperCopy
– Quiesce
– Load
– CDB SuperLoad
– Check
– CDB SuperUnload
– Recover
– CDB SuperRestore
– Reorg
– CDB SuperReorg
– Runstats
– Report Recovery
– Repair

• Commands
– Display/Stop/Start Database
– Display/Term Utility

DB2 Logging

• DB2 Logs
– A ‘journal’ of all activity for a subsystem
– Undo/redo records for table updates
– Each event in the log is identified by its RBA(relative byte address)
– RBA denotes a point in time: the greater the RBA, the later in time the event occurred
– Data Sharing - LRSNs along with RBAs

– Some events:
• Full image copy
• Quiesce
• Load

Data Sharing

• Benefits of Data Sharing
– High availability
– Workload balancing
– Sysplex parallelism
– Better use of resources

Backing Up Tables

• Image Copy
– Backup for DB2 table spaces
– Can also copy index spaces
– Can perform full (all data) or incremental (changed data) copies
– Can prevent or allow updates by others during copy

• CDB SuperCopy
– Faster method of creating stan…