Thank you Chuck for all the information. Many questions I had, but not
asked, were answered as well.
I do not know the specific process former boss used to detach and save
journal receiver. It was a vendor supplied command. Just never had to use
it before. We used to have operetors and this was done twice daily.
John McKee .
On Tue, Jul 15, 2014 at 8:24 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:
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
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
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
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
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 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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives