Re: SMAPP is killing our 520

Unfortunately, the file I/O is to the logical files not the physicals so we 
can't do that . . .

"Chris Bipes" <chris.bipes@xxxxxxxxxxxxxxx> wrote in message 
news:mailman.278.1169761393.2713.midrange-l@xxxxxxxxxxxxxxx

Question:  Do you have all of your logical files created over the new
files you are converting to?  If so, remove their members and the system
will not have to maintain the access paths during the file writes.  You
will find that you can copy over the data much faster, then ADDLFM to
build your indexes after the conversion.  I generally write a CLP to
perform the ADDLFM and run it after the data transfer.  It is much
faster to build indexes over complete files than to maintain multiple
access paths during large conversion, thus file writes.

Christopher Bipes
Information Services Director
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
ChadB@xxxxxxxxxxxxxxxxxxxx
Sent: Thursday, January 25, 2007 1:13 PM
To: Midrange Systems Technical Discussion
Subject: Re: SMAPP is killing our 520


Must be some pretty hefty data conversion!

I'm not skilled enough on the database side to help you with specifics,
but i'm sure some others here are.  Alternatively, i'd call IBM support
and get the DB2 people on the line to describe what you're seeing.

A basic thing you could try to see if it makes a difference is to use
the CHGRCYAP command to scale your target recovery time back (increased
target recovery time) to a point that seems to impact your conversion
processes at an acceptable level.

It does seem to make sense that if the files being protected are
constantly in flux while being 'converted', the access paths being
protected by SMAPP are probably continually being processed for SMAPP
coverage.  I've never seen SMAPP have any real detrimental impact, but
i've never had a box that was purely converting files for very long,
either!