RE: Recovery Time estimate for abnormal system end due to DASD usage

See inline responses.

Celebrating 10-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: RE: Recovery Time estimate for abnormal system end due to DASD
usage

Most our files are journaled and SMAPP is set at the default of 70min.
The DSPRCYAP screen shows a 46min estimate for recovery.
How accurate is that?

Well, it is "estimated" time, so it's not totally accurate, but for that
part of IPL recovery it's close enough.

Recovery of the access paths is a big part of IPL right, so if we had
crashed, would the IPL been done in an hour or so (assuming the
46min est was still in effect)?

Probably :)

Or maybe two hours is the activity at the time had the SMAPP estimate
up to 70min.

70 min limit tells the system to manage access path recovery in such a
manner that IPL access path recovery is minimized to that time.

I found a message in the archives that mentions the possibility that an
IPL doesn't clean off enough temp space for the IPL to complete which
means the only recovery is a full system restore.
Is that still a possible scenario?

That was definitely true in the past. If your runaway job was eating up
permanent storage (i.e. non-QTEMP file), rather than temp storage (i.e.
QTEMP workfile, SQL query internal structs, Java heap storage etc.)
There are other internal OS temporary structures that are always cleaned up
at IPL time and make "some" space available, but as you said, it may not be
enough to complete an IPL.
That said, things change constantly with the OS so perhaps new releases
handle this differently. Comments anyone?

As for scratching the system... not sure... perhaps IBM support has ways to
clean up things and help avoid system scratch and reload.
My experience has been that "running out of DASD" type of crash does not
require full system scratch.