sandiptcs
New User
.jpg)
Joined: 29 Nov 2006
Posts: 19
Location: amsterdam
|
|
|
|
Hello
My BMP program uses DB2 and writes into a sequential file. The program has a checkpoint and restart logic in it .Is it true that when checkpointing is issued it commits the records written to the file upto the last checkpoint and rollback all the records written after that.
If it is true then shall we use (MOD , CATLG CATLG) option so that in the event of an ABEND, if the program is restarted from the last checkpoint it will write records after that checkpoint i.e. apend to the already existing records in the file .
I am worried that it will not rollback records written to the file and so in the event of a restart it will write the same records twice
if it cannot rollback records written to a sequential file shall we use GSAM file to write records so that checkpoint restart is taken care of .
I found that even though we use GSAM file it doesnot reflect any rollback if an abend occurs and the reason i read somewhere is that we have toissue a symbolic checkpoint and not a basic checkpoint for a rollback to occur in a GSAM file. Any idea if this true !
Would like to know more about symbolic checkpoint then !
Any suggestion most welcome 
Thanks Sandip |
|
sdpk_ind
New User
Joined: 07 May 2006
Posts: 4
|
|
|
|
This is from ibm site...have a look at it...
GSAM IMS Symbolic Checkpoint Call
GSAM is useful if you need an application program that accesses z/OS? data sets to use the IMS? symbolic checkpoint call. The IMS symbolic checkpoint call makes restart easier than the z/OS basic checkpoint call. This IMS symbolic checkpoint call allows application programs to take checkpoints during processing, thereby allowing programs to restart from a checkpoint. A checkpoint call forces any GSAM buffers with inserted records to be written as short blocks. The primary advantage of taking checkpoints is that, if the system fails, the application programs can recover from a checkpoint rather than lose all your processed data. However, any application program that uses VSAM as an operating system access method and initially loads the database cannot be restarted from a checkpoint.
In general, always use DISP=OLD for GSAM data sets when restarting from a checkpoint even if you used DISP=MOD on the original execution of the job step. If you use DISP=OLD, the data set is positioned at its beginning. If you use DISP=MOD, the data set is positioned at its end.
Because GSAM databases are supported in a DCCTL environment, you may use them when you need to process sequential non-IMS data sets using a BMP program.
GSAM databases are loaded in the order in which you present records to the load program. You cannot issue DLET and REPL calls against GSAM databases; however, you can issue ISRT calls after the database is loaded but only to add records to the end of the data set. Records are not randomly added to a GSAM data set.
Although random processing of GSAM and SHSAM databases is possible, random processing of a GSAM database is done using a GU call qualified with a record search argument (RSA). This processing is primarily useful for establishing position in the database before issuing a series of GN calls.
Although SHSAM and SHISAM databases can be processed in any processing region, GSAM databases can only be processed in a batch or batch message processing region.
The following IMS options do not apply to GSAM databases:
Logical relationships
Secondary indexing
Segment edit/compression exit routine
Field-level sensitivity
Data Capture exit routines
Logging or reorganization
Multiple data set groups
If you have application programs that need access to both IMS and z/OS data sets, you can use SHSAM, SHISAM, or GSAM. Which one you use depends on what functions you need. |
|
