On 14-Jul-2014 13:30 -0500, John McKee wrote:

I thought it odd since it has been 8 years and the receiver has not
changed. I did not know if that was typical.

A new Journal Receiver for a System Managed Journal need never be generated [not during the IPL nor while system-active in since that IPL] until *either* the storage Threshold *or* the Sequence Number exceeds a minimal threshold according to the Receiver Size Option. For lack of any need according to the system [managed attribute], a new receiver apparently legitimately was never generated. For what defines the need\desire of the system to generate a new receiver, see the help text for the Receiver Size Options (RCVSIZOPT) on the Create Journal (CRTJRN) and the Threshold (THRESHOLD) on the Create Journal Receiver (CRTJRNRCV).

Note: While I seem to recall a new receiver being generated on every IPL for some receivers, if even an accurate recollection, that would no longer be the case, and would have been a behavior eliminated many versions [not just releases] ago.

Threshold is 1500000 (K). I don't see keywords on DSPJRNRCV.
Based on threshold value, if it was not modified, then, this is

Hmmm... perhaps a poor choice by the dev; having failed to explicitly specify what is a desirable threshold, resulted in the newer\updated default of THRESHOLD(1500000) for the CRTJRNRCV being the effect. Thus /normal/, even if not [what IMO should have been an aim towards] a more aggressive choice for minimizing storage with a side effect of more generations. I am almost certain that we purposely chose to explicitly specify [a smaller] threshold for each of the other system-supplied database cross-reference journals [and for the QSQJRN in QSYS2]; I do not have authority to review the WRKJRNA and DSPJRNRCVA information of any of the system-supplied DB2\SQL journal environments to review for differences in their default setup.

We used to have full system backup weekly. Then that slipped to
every other week. May be heading back to weekly. Or not. There was
even talk of just plain skipping backup entirely.

The QRECOVERY is never [supposed to be] saved as part of any normal B&R strategy; for problem determination a request might be made by IBM development to save something from that library, but more likely just some object dumps would be requested. Thus whatever storage the journal receivers require on disk [plus and any other visible\external objects and even many internal objects such as the Start SQL (STRSQL) session objects], has no impact on the storage requirements for save to media nor can there by any impact on the journaling environment with regard to when backups occur.

As I recall the issue with storage [for this\your system] is not with regard to the overall disk requirements, but the media requirements for backups; the amount of media required to complete a full system save should fit on one cartridge.? Again, because nothing is saved from QRECOVERY [nor the library itself] as part of the "B" of B&R, then [expending any thought or action with regard to] reducing the storage for the various journal receivers in QRECOVERY, is purely folly.

Obvious to me is that current size of 286884 (K) is way below
threshold. Compared to other journal receivers, the size looked very
large despite being less than 300M.

Agreed. Significantly below the threshold.

If CHGJRN is used, is it best done before or after backup? Is
restricted state needed? Maybe this just doesn't matter.

No matter; the request to perform CHGJRN QRECOVERY/QDBJRNXRFQ JRNRCV(*GEN) can be done at any time. Again, because QRECOVERY is never saved, when backups are performed is not germane with respect to any objects in that library; whether a new receiver is generated or not, is of no consequence with regard to the backup.

An application journal receiver was detached that freed likely even
more space.

After the detached receiver was [saved\backed-up and then] deleted, only then will any storage be freed.

Is there a down side to creating a new receiver and deleting
the old one?

As MNGRCV(*YES) DLTRCV(*YES), the system-generated receiver will do both in just one request; as such, there is no need to deal with the hassle of setting up a proper[ly owned and authorized] journal receiver: CHGJRN QRECOVERY/QDBJRNXRFQ JRNRCV(*GEN)

The downside to creating a new receiver is if the journaling environment\ecosystem were to be re-established in a potentially problematic way; minimal assurance that the setup is not problematic, best to reset the owner of the new *JRNRCV to match the system-supplied object, revoke all private authorities from the new object using Revoke Object Authority (RVKOBJAUT), then grant the authorities using Grant Object Authority (GRTOBJAUT) to the new receiver from the old receiver as Reference Object (REFOBJ) before deleting the old journal receiver with Delete Journal Receiver (DLTJRNRCV).

Notably, to reduce the THRESHOLD(), the CRTJRNRCV is exactly what is desirable and required; the CHGJRN request would then name the new JRNRCV(), instead of using the JRNRCV(*GEN) [to ask the system to generate a new receiver with the same owner\authority as the active receiver].

One last question: Does activity not performed in library file
system get logged into a journal within the library file system? I
recently retrieved a large number of files from a VAX system. They
were stored outside of library file system. I only retrieved them in
order to use PKZIP. My impression was that the journal did not
include that activity.

If "the journal" refers specifically to the *JRN object QDBJRNXRFQ in QRECOVERY, then... No. The purpose of that specific journal is to journal the Data Queue objects QDBXREFQ* in QSYS; nothing else.

However, stream files [¿and directories?] can be journaled explicitly and object activity outside of the /QSYS.LIB file system may be included in specific or general object auditing. Auditing is implemented using a journal, but the *JRN object QAUDJRN is in QSYS; the journal entries are stored in journal receivers which also are [and can exist] only in the /QSYS.LIB file system.

Some time back, detach of journal receiver on vendor files had been
discontinued, and the receiver was very large. My former boss thought
my activity outside of library file system was responsible for the
large size.

If as in the prior described example the file data [from the VAX system] was placed outside the /QSYS.LIB, such that the data was placed in stream files (STMF) for which journaling or auditing was ended with ENDJRN, rather than the data being placed in members of database *FILE objects for which ENDJRNPF was used to discontinue journaling, then perhaps the receiver grew tracking that non-/QSYS.LIB activity.

He saved the journal receiver, which does an implicit detach, so a
new one has since been created, which is MUCH smaller.

I was unaware of an /implicit detach/ capability during save [consider that a /save/ really should not be _changing_ objects, else either the object on media and what should be the equivalent object on disk would never be the same, or the object on disk would always be changing even if the only action was merely to save]; as I recall, an active receiver being saved is diagnosed as effectively incomplete per msg CPF7080 "... saved while attached." And if the DLTRCV(*YES) were established, then the object would be implicitly deleted when detached, so one would need to have great confidence in their [one shot at using the chosen] media. What I recall, is that a new empty receiver would be generated upon restore.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page