RE: SYSSAV & Access Paths

GO SAVE, option 21 runs CL program QMNSAVE.  The CL source may be retrieved.
The help text for option 21 will tell you the following:

This option runs the following commands: 
                                         
    ENDSBS SBS(*ALL) OPTION(*IMMED)      
    SAVSYS                               
===>SAVLIB LIB(*NONSYS) ACCPTH(*YES)     
    SAVDLO DLO(*ALL) FLR(*ANY)           
    SAV OBJ(('/*') ('/QSYS.LIB' *OMIT)   
      ('/QDLS' *OMIT) UPDHST(*YES)       
    STRSBS SBSD(controlling-subsystem)   

The retrieved CL source for QMNSAVE will tell you the same thing.  The full
system save is saving your work libraries using a SAVLIB with ACCPTH(*YES).
Despite the ACCPTH(*YES) V5R2 will not save the 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

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.

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.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>


-----Original Message-----
From: Lopez, Andrew [mailto:alopez@xxxxxxxxxx]
Sent: Thursday, January 22, 2004 6:35 AM
To: midrange-l@xxxxxxxxxxxx
Subject: SYSSAV & Access Paths


We upgraded to an 810 this past weekend and ran into a problem with the use
of a full system save/restore (GO SAVE, option 21 with GO RESTORE, option
21).

We have 55 work libraries that are used to store order entry information as
it is being keyed.   The data is copied into production files once the order
is confirmed.   Whenever we do a full system save, these files have no data.


I am told by IBM Help Line that access paths for empty files are not saved
in a SYSSAV as of V5R2.   Indeed, after doing the restore onto the new box,
our order entry package would generate an error for each file in each of the
work libraries.   While we could use EDTRBDAP, that is not acceptable in our
view for disaster recovery purposes.   We are not interested in creating a
CL to open the files and force the rebuild.  We want backups that, once
restored, cause the system to run as it did when the objects were saved.   

Saving the objects (via SAVLIB or SAVOBJ) with ACCPATH set to *YES works,
and if needed we will add this to our daily saves so that using GO RESTORE
option 21 and then overwriting with the latest daily will handle the
problem.   I can't say I'm thrilled by the prospect of backing up 55
libraries, with 37 files each, on a daily basis when they have no data in
them just to get the access paths.  My boss is not a fan of *IPL for the
RECOVER parameter.

So the question is, can I force the default behavior of a SYSSAV to save all
access paths?  The IBM tech I spoke with couldn't point me to anything.
The OS/400 Backup and Recovery Guide V5R1 was no help and there doesn't
appear to be a V5R2 revision.