Re: SAVSYS running over an hour

R Bruce Hoffman wrote:

Hmmmm... in a galaxy far, far away...

I seem to recall that NO user objects should EVER be placed in
QSYS because they are either not saved or they can't be restored,
or both. Isn't that still true?

On 12/10/2009 03:52 PM, CRPence wrote:

As alluded in my prior post, journal receivers *should not* be placed in QSYS. Receivers are "user data", but like other user
created objects in QSYS, they will be accounted as part of the
OS and saved as part of the SAVSYS.

What will happen is presumably "undefined", such that no dependency should be implemented on an undocumented result; i.e. of what is saved and\or restored, beyond the OS. For that I would concur, that user objects should not be placed in QSYS. Or maybe there is some documentation, but I am not aware of any statement.

However IMO the more obvious reason to avoid QSYS for user objects is because as user objects.data, they are not saved & restored in the standard D/R as user data; i.e. *NONSYS and *ALLUSR are intended for that, plus those should be on a more timely basis. Thus if a reload must defer to an install from IBM media due to an error with the SAVSYS or for when a DR reload is performed as restore onto an existing installation [e.g. for convenience or by necessity, to a new release], unless separately saved from QSYS, those objects will not get restored to the target system.

I do know that some objects which are *not* part of the OS [according to the product information in the *SERVICE OIR] nor part of the "product definition" will be saved; e.g. journal receivers created by users and I believe the QHST* files also appear as user objects. I had created a database of users and of the save media, both in QSYS in order that for my scratch installs performed from the SAVSYS, the data would be there without any additional RSTxxx activity; that was in the lab on less-than production level [but not scratch & burn] systems, where the saves were weekly full save. I know my files were restored on several such scratch installs.

Regards, Chuck