Re: OMS/400 and Shared Access Paths

In that scenario, order is moot. Either the access path for SHARED1 or the access path for LOGICAL1, needs to be built at the target system. In that manner the second created can share the first created. However as a mirror copy, the order of creation is best maintained matching the source system, and even better that the files should be restored, so...

To avoid the requirement to create the [shared] access path [i.e. to restore it instead], the data needs to be restored with the logicals or restored over the already existing files. This is required because the access paths are saved with the data, not with the logical; i.e. saved only with the physical file when using ACCPTH(*YES).

In an HA product either the replay of the request for creating logical file SHARED1 needs to be done [which per above, means the access path must be created] first, or I believe you may want to find a /refresh/ feature instead of an individual object /save/ [and /restore/] feature.

Regards, Chuck

Jonathan Mason wrote:

Has anybody had any experience with OMS/400 and saving/restoring
shared access paths?

We have the situation where an access path is shared and the access
path owner has a name that comes after the LF that is sharing the
access path. E.g. SHARED1 owns the access path and LOGICAL1 makes
use of it.

As a result when saving the objects using OMSSAVOBJ logical file
LOGICAL1 is saved before SHARED1. This causes a problem when
restoring is made to the target system as SHARED1 doesn't exist so
the access path isn't restored and is rebuilt on next use and as the
physical file in question has 1.7 billion records it takes a little
while to complete.

I'm not that familiar with OMS/400, and was wondering if there would
be any problems with stopping the access path rebuild using the
EDTRBDAP command and then using RSTOBJ to re-restore the access path
directly from the OMS tape created using the OMSSAVOBJ command?

Any thoughts or suggestions would be gratefully welcome.