High Disconnect Times in RMF with Incremental IC

Marc Matulis

High Disconnect Times in RMF with Incremental IC
We are experimenting with changing from Full to Incremental ImageCopies in
our PeopleSoft environment due to the volume of object growth with our
latest upgrade (Fin/SCM 8.9).

Environment: z/OS 1.4 - DB2 v7.1

We noticed that our RMF stats show "Excessive Disconnect Time On Volume
xxxxxx" for EVERY timeslice of the IC job when running Incremental. An
average 100sec timeslice shows 70% Active, 1% Connect, 69% Disconnect.

When run as a Full IC, the job seems to bounce between "Excessive Connect
Time", "Waiting To Use Processor" and "Excessive Disconnect Time" in RMF
with each timeslice.

The IC job is writing to a 3590 drive and all IC data fits on one tape.

Is there something about the behavior of an Incremental IC that causes the
delays on the tape device? Does an Incremental IC determine upfront what
TS's need to be copied (similar to a LISTDEV being processed), or is the
determination of what to IC made as each TS is processed? For what it's
worth, the IC job does use a LISTDEF.

The Incremental did run in about half the time of a Full, but still with a
Full estimated at 8 hours under PS Fin/SCM 8.9, we're going to have to work
on some other options too.

Thanks for any information/advice,

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm