× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



+1 on audit receivers not in Q* libs.

For the audit journal, I usually create a lib called AUDJRN or AUDRCV or
AUDIT (you get the idea) and then make the receivers AUDRCVxxxx - there's a
neato free journal cleanup utility out on the net somewhere that you can use
to clean up based on age, size, saved, etc - I'll put that on if the system
isn't using a HA solution that does automatic cleanup or if the customer
doesn't have a policy for manual audit journal receiver save and purge.

-jch

On Thu, Dec 10, 2009 at 5:26 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.