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
normal.
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.
midrange.com
