Check Point and Restart Logic

you cannot simulate an EXPLAIN of an SQL statement, nor a question mark somewhere in an SQL
statement simulates an EXPLAIN.

Provided you have access to a set of Explain Tables, you can execute an EXPLAIN statement for an
explainable SQL statement.
E.g., to explain "SELECT IBMREQD FROM SYSIBM.SYSDUMMYE WHERE IBMREQD > ?" you would use
something similar to
CODE: SELECT ALL
EXPLAIN PLAN SET QUERYNO=1234 FOR

SELECT IBMREQD
FROM
SYSIBM.SYSDUMMYE
WHERE IBMREQD > ?
SELECT SYSUT1-FILE ASSIGN TO SYSUT1 ORGANIZATION IS SEQUENTIAL

ACCESS MODE IS SEQUENTIAL FILE STATUS IS SYSUT1-STATUS.
FD SYSUT1-FILE DATA RECORD IS SYSUT1-RECORD RECORDING MODE is V
RECORD IS VARYING IN SIZE from 1 to 256 DEPENDING ON WS-RECORD-SIZE.
01 SYSUT1-RECORD PIC X(256).
FD SYSUT1-FILE
BLOCK CONTAINS 00000
DATA RECORD IS SYSUT1-RECORD
RECORDING MODE is V
RECORD IS VARYING IN SIZE from 1 to 256
DEPENDING ON WS-RECORD-SIZE.
01 SYSUT1-RECORD
PIC X(256).
=================================================================================
SYNCPOINT AND TWO-PHASE-COMMIT

The updates done by a task is automatically committed at task termination.
SYNCPOINT is used to commit portion of work completed without terminating
the task.
EXEC CICS SYNCPOINT END-EXEC.
During the program processing, if you want to roll back the changes made by
you, then you can code SYNCPOINT with ROLLBACK. This will backed out all
resource modifications done since the last sync point.
EXEC CICS SYNCPOINT ROLLBACK END-EXEC.
SYNCPOINT in CICS-DB2 environment is called as two-phase commit.

The changes made in the resources that are directly under the control of
CICS are committed in the first phase and the changes made to DB2
environment are committed in the second phase.
======================================================================
I need some calrifiactions on using SYNCPOINT. I have PGM A linking PGM B. PGM B links to PGM
C. I have some data base insertes in PGM B and in PGM C. In such a case, if I got sql error in PGM
C, i want to return to PGM B and then return to Program A and then issue
a SYNCPOINT ROLLBACK. In this case whtever the database changes that were done in PGM B
and PGM C will be rolled back. I do not want to use rollback/syncpoint in every linking program. I
would like to do either a syncpoint or rollback only in PGM A.I think the chages will be rolled
back, as the PGM A, PGM B, PGM C runs under the same task.PGM A will be triggered by the MQ.
So I want to issue a sysncpoint only after I have done all the changes including the MQ changes.
The queues are not persistent queus. I did a search through the forums. I got couple of postings
which are very close to my scenario. But in one posting it states that as soon as you return to the
calling program (to the linking program)by issuing CICS RETURN the changes will get committed
and the task will be ended. Will the PGM A, PGM B, PGM C runs under the same task or for each
linked program a seperate task will be created.
=======================================================\========================
The easiest solution in your case would be to issue a SYNCPOINT ROLLBACK whenever and in
whichever program you encounter the SQL error. That would rollback all the changes in your task.
If you want rollbacks to certain points in your task, you can use SAVEPOINTS.
Take an example where the amount for your loan is deducted directly from your personal bank
account.
There are two parts to this operation
1. Deduct amount from your personal account - This would require updating your personal bank
account file.
2. Add the amount to your loan account - This would required updating your loan account file.
If after performing step 1, i.e. deducting amount from your personal bank account, the task is
unable to perform the update of your loan account file, say because the file was closed to CICS. At
this point if you just abend the transaction, the money from your personal bank account is gone,
but it has not be added to your loan account.
To prevent such a thing, you would like to identify a single unit of work (UoW) within your
transaction. The unit of work in this case would be deducting from one a/c and adding to the
other.
At the beginning and end of each unit of work, you would do a syncpoint and a commit which
would marking the beginning and end of each UoW. During the processing of a UoW, if something
wrong happens, then you would issue a ROLLBACK saying none of the updates that have taken
place in this UoW have to happen because something has gone wrong. If everything goes fine,
then you would COMMIT the changes.
Now, for CICS to identify the beginning of each UoW, you would issue a SYNCPOINT at which point
it would take a backup of all resources to which it can rollback in the event a ROLLBACK command
has been issued.
Now the above example is a very simple one. But in much more complex operations you would
have mutiple resources, not just files and tables where updates happen constantly. Having
SYNCPOINTS during such situations would be more helpful.
=================================================================================
You can use this in Spufi, QMF, DSNTEP2, in your application program, wherever.
The output of that EXPLAIN is stored in the Explain Tables, from where you can query it,
see Interpreting data access by using EXPLAIN
NB-1: In your context, the question mark is a parameter marker. Parameter markers are replaced by
the values of host variables when the statement is executed. You may want to look at
the Application Programming and SQL Guide for some related information.
Before you start with check-point-restart, You need to know what is check-point restart -Checkpoint/Restart allows you quickly insert COMMITs and CHECKPOINTS into your DB2 batch job
streams in some instances without even editing your programs. These COMMITs will often
speed up DB2 batch programs and also free up DB2 resources for other production jobs that are
running at the same time. After COMMITS are added to your DB2 batch programs,
Checkpoint/Restart allows you to quickly restart any abended production job from the point of
failure. Checkpoint/Restart will reestablish all positioning and resources within the problem
program, including COBOL Working Storage and QSAM and VSAM file access; and then completes
any remaining application processing rather than rerunning the whole DB2 program from the
beginning.
Checkpoint Restart also provides a powerful Variable COMMIT Frequency Option that enables you
to dynamically tune DB2 batch jobs by changing their COMMIT frequency as they run. Database
Administrators can now dramatically speed up any jobs that need to be completed as soon as
possible prior to the online DB2 applications being restarted.
i would like to make the topic clear for you.

Actually i have coded a cobol program which includes the chekpoint logic.
The jcl which runs for this program will unload records from some table
and store the data into one flat file. This file is used as input to the
program. The program will just read this input flat file and writes into outfile
flat file specified in the jcl.
After the unload is done, the input provided to the program has 333
records. when the program is running, if it abends at 50th record, the
checkpoint logic what am using in my program will help in capturing the
record which was processed succesfully just before the abend happened(
we specify something known as FREQUECY as an input to the checkpoint
logic i.e., FREQ(002) as an example). so an entry will be made in a table
called CKPT-TABLE i.e., 48th record is captured in this table as per the FREQ
(002) as an example.
so when we RESTART the program after solving the problem in the 50th
record which caused the abbend in the program, the program will run from
49 record.( the FREQ(002) does means that for every two records we are
COMMIT'ing the CKPT-TABLE to capture that record. i.e., when processing,
everying 2nd record in captured in the table for eg: when program picks up
2nd record it is saved in the table, again when it comes to 4th record, the
2nd record is replaced by 4th record in the CKPT_TABLE. similarly the 48th
was stored in the table!!).
My question is, when we restart the program how the checkpoint would
come to know that it has to start from 49th record!!?
as per i referred to some document, after every COMMIT the records will
be stored in something called as DB2-BUFFER-POOL'. as per the above
example i have shared, 48th record was commited and all those 48
records would be stored in BUFFER_POOL. the records wouldn't be written
to output file specified in the jcl untill all the 333 records got processed
successfully, untill then the records would go on stored in the buffer pool.
so how the chekpoint logic wil come to know that it has to start from 49th
record, whether it will refer the BUFFER POOL or INPUT FILE while getting
restart?

Check Point and Restart Logic

Uploaded by

Copyright:

Available Formats

Check Point and Restart Logic

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Check Point and Restart Logic

Uploaded by

Copyright:

Available Formats

you cannot simulate an EXPLAIN of an SQL statement, nor a question mark somewhere in an SQL

statement simulates an EXPLAIN.

EXPLAIN PLAN SET QUERYNO=1234 FOR

SELECT SYSUT1-FILE ASSIGN TO SYSUT1 ORGANIZATION IS SEQUENTIAL

SYNCPOINT AND TWO-PHASE-COMMIT

SYNCPOINT in CICS-DB2 environment is called as two-phase commit.

i would like to make the topic clear for you.

You might also like