DB2/MVS - Chkpt/restart

[bobl...@sierra.net]

I trying to get info on the various DB2 batch checkpoint/restart products (for MVS).

So far I've got info on the following vendors..

Relational Architects (SmartRestart)
CDB Software (something restart)
BMC Software (something restart)

I think there are a couple more - maybe a vendor or product called 'Quickstart'?

Anyway, if you worldwide experts know of other products/vendors or have comments on the products
mentioned above, I will be forever indebted.

Thanks in advance!

Bob Lewis

[Kelly Bert Manning]

Terry Doner (don...@inforamp.net) writes:

> In <4277nj$f...@jobes.sierra.net>, bobl...@sierra.net writes:
>>I trying to get info on the various DB2 batch checkpoint/restart products (for MVS).

>> ...

>>Anyway, if you worldwide experts know of other products/vendors or have comments on the products
>>mentioned above, I will be forever indebted.
>

> This is a little off the wall to many people, but we use IMS to provide check-point
> restart facilties. I have heard that some sites have bought IMS/TM solely for that
> purpose.
>
> Works for us.
>
> Terry Doner
> Senior Systems Consultant
> Toronto-Dominion Bank
> Toronto, Ontario, Canada
> voice: (416) 944-5227
> fax : (416) 944-6288
> email : don...@tdbank.ca
>
IMS will coordinate IMS Checkpoints with DB2 Syncpoints, even in a
non-message oriented Batch Messsage Processing Program, but I'm not
sure how much that would by you.

Last time I checked the CURSOR WITH HOLD option wasn't supported in IMS,
which might be a consideration.

The main that IMS checkpoint/restart might provide is repositioning GSAM
output(QSAM or VSAM datasets). I avoid GSAM for input and do my own
reposoning using record counts saved in the checkpoint save area(s).

There are also technical challenges that show up if you use GSAM for
repositioning QSAM output datasets. IMS provides restartability by
writing any partially updated buffers to tape or disk when a checkpoint
is taken. This can leave many short blocks on the disk or tape, giving
poor media utilization and high EXCP counts writing it and reading it back.

It can also give some headaches if you run out space and use a QSAM logical
record copy utility to copy to a larger dataset, or if your systems disk space
managment processes use a logical record copy to move the dataset to another
location between the time the first run fails and the time that you restart.
This condenses any short blocks into full length ones, making it
impossible for IMS to reposition to the right location for a restart.

You also have to provide your own data backup by doing duplicate inserts
to a pair of GSAM outputs. When I use GSAM I use 2 outputs, a pair of
tapes, or a tape and a disk. If the application requires more than 1
sequential output dataset I stick on a subfile prefix code and run the
output through a file split, eg. SYNCSORT with OUTFILs.

This seems to avoid the high EXCP count and poor media utilization
issues, while keeping the tape drive count down and steering clear of
disk dataset logical record copy headaches.

[Terry Doner]

[Terry Doner]

In <DEI2I...@freenet.carleton.ca>, bo...@FreeNet.Carleton.CA (Kelly Bert Manning) writes:

>IMS will coordinate IMS Checkpoints with DB2 Syncpoints, even in a
>non-message oriented Batch Messsage Processing Program, but I'm not
>sure how much that would by you

The key benefit you get is that IMS tracks your position in your input and output files
- if you use GSAM.

It also co-ordinates commits with our resource managers (IMS-DB , MQSeries, or any
other DB that so allows - like Oracle.)

>Last time I checked the CURSOR WITH HOLD option wasn't supported in IMS,
>which might be a consideration.

Check again. CURSOR WITH HOLD has always been supported in IMS environments that
made sense. Primarily - non-message driven BMP and DLI. It is not supported in the
on-line transaction environment (The thread may disappear which would toss the HOLD
position.)

>The main that IMS checkpoint/restart might provide is repositioning GSAM
>output(QSAM or VSAM datasets). I avoid GSAM for input and do my own
>reposoning using record counts saved in the checkpoint save area(s).

We do GSAM on input as well. IMS Provides it, and it works.

>There are also technical challenges that show up if you use GSAM for
>repositioning QSAM output datasets. IMS provides restartability by
>writing any partially updated buffers to tape or disk when a checkpoint
>is taken. This can leave many short blocks on the disk or tape, giving
>poor media utilization and high EXCP counts writing it and reading it back.

This can be a problem and can be controlled by making wise choices for check-point
frequency and block-size. Unless you 'logged' the QSAM write there aren't very many
other techniques. (I supppose they could re-use the IMS concept of WADS for GSAM files
to ensure only full blocks are written. ...)

>It can also give some headaches if you run out space and use a QSAM logical
>record copy utility to copy to a larger dataset, or if your systems disk space
>managment processes use a logical record copy to move the dataset to another
>location between the time the first run fails and the time that you restart.
>This condenses any short blocks into full length ones, making it
>impossible for IMS to reposition to the right location for a restart.

This is true. Does anybody know if other restart products circumvent this problem. If so
that may be a key advantage.

>You also have to provide your own data backup by doing duplicate inserts
>to a pair of GSAM outputs. When I use GSAM I use 2 outputs, a pair of
>tapes, or a tape and a disk. If the application requires more than 1
>sequential output dataset I stick on a subfile prefix code and run the
>output through a file split, eg. SYNCSORT with OUTFILs.

Although this works, don't see why you *have* to. IEBGENR copy with RECFM=U
would suffice. (They key is to maintain short blocks.) If you don't need your back-up
copy for restart, then standard copy facilities would work fine.