Re: SYSSAV & Access Paths

["Lopez, Andrew" <alopez@xxxxxxxxxx>]

> message: 5
> date: Thu, 22 Jan 2004 10:34:04 -0600
> from: Jim Damato <jdamato@xxxxxxxxxxxxxxxxx>
> subject: RE: SYSSAV & Access Paths

....... 

> There's a thread out there from when Al Barsa originally discovered this
new
> undocumented feature.  I don't think there are any meaningful conclusions
> other than the fact that IBM missed the boat on this one.
> 
>  ACCPTH(*YES) becomes ACCPTH(*MAYBE) in V5R2
>  http://archive.midrange.com/midrange-l/200312/msg00316.html

Thanks for the link.  I had searched for "Access+Path" and was surprised at
the limited number of messages. I tend to forget the abbreviations when
searching....

> I'm surprised that "Saving the objects (via SAVLIB or SAVOBJ) with ACCPATH
> set to *YES works,"  If this is true you might retrieve and modify the CL
> for QMNSAVE to omit your work libraries on the SAVLIB *NONSYS, and add
them
> as a separate SAVLIB statement later in the stream.

This is what really caused us the problem.  Our initial tests showed the
problem with the access paths.  We first changed all of the files from
*AFTIPL to *NO for RECOVER to match files that were not having a problem.  I
then looked at QMNSAVE and ran that command (although I wildcarded the
libraries in question instead of using *NONSYS).  We then restored those
libraries and everything was fine.  My mistake was assuming that the change
to RECOVER was the fix.  
 
> You might instead retrieve and modify the GO RESTORE option 21 CL
(QMNRSTE)
> and include a call to a CL program to rebuild the indexes.  IMO - If I
were
> still able to use GO SAVE option 21 and GO RESTORE option 21 for my
Disaster
> Recovery procedures I'd rather include a step for rebuilding the indexes
> than hacking up the save and restore.

I definitely will not be modifying either GO RESTORE or GO SAVE.  The new
tape drive (3582) completes an entire SYSSAV in under 45 minutes.  While I
appreciate IBM's viewpoint of streamlining the save, we would just as soon
have the SAVE/RESTORE take longer, but require less modifications and user
interaction.  "Restore last monthly backup, restore last daily save, --->
run" is the kind of emergency plan I like.  Heck, with the 3582, I was
thinking of going to a nightly SYSSAV to shorten even that process.  Kind of
pointless now, however.  We'll just add a separate save of the libraries to
our daily saves.

Thanks for the help.