Re: Journal receivers

Chuck,

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

Threshold is 1500000 (K). I don't see keywords on DSPJRNRCV.

Based on threshold value, if it was not modified, then, this is normal. 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.

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.

If CHGJRN is used, is it best done before or after backup? Is restricted
state needed? Maybe this just doesn't matter. An application journal
receiver was detached that freed likely even more space. Is there a down
side to creating a new receiver and deleting the old one?

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. 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. He saved the
journal receiver, which does an implicit detach, so a new one has since
been created, which is MUCH smaller.

John McKee






On Mon, Jul 14, 2014 at 12:11 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 14-Jul-2014 09:48 -0500, John McKee wrote:

On Sat, Jul 12, 2014 at 8:23 AM, CRPence wrote:

On 11-Jul-2014 14:22 -0500, John McKee wrote:

<<SNIP>> Is there a process that is supposed to be run to detach
these receivers, or is that just done manually?

<<SNIP>>
Each journal environment for which those [system] receivers are
established, should include the Manage Receivers (MNGRCV) setting
of *SYSTEM and the Delete Receivers (DLTRCV) setting of *YES; refer
to the Work With Journal Attributes for the *JRN associated with
each of the noted\named Journal Receiver (*JRNRCV) objects. Thus
there should be only one journal receiver object that is
active\attached per journal object. The maximum size of the journal
receiver before deletion will be determined by the Receiver Size
Options of the journal and the Threshold attribute of the journal
receiver; see the Display Journal Receiver Attributes (DSPJRNA) for
the threshold and the associated Journal object.

<<SNIP>>

With the default journal environment, the request to Change Journal
(CHGJRN) to request attaching a new generated-name or an explicitly
named journal receiver will enable reducing the current storage for
a[n at least partially] full receiver to the storage of an empty
receiver. For example, the request to CHGJRN QSYS2/QSQJRN
JRNRCV(*GEN) would effect a new empty receiver with the next
receiver name and the previously attached receiver would be
detached and deleted.

I presented insufficient information. I thought the question was so
common that details would have been tedious.

from WRKJRNRCV:
Journal: QDBJRNXRFQ
Receiver: QDBJXQ0001
Attach date: 07/12/06
Size (K): 286884

No detach or save date.

from WRKJRNA:
Manage receivers: *SYSTEM
Delete receivers: *YES

What drew my attention was that the journal receiver was 0001.

Something is odd. Is there a system value that is potentially wrong?

I am unsure what is presumed to be odd.? Neither of the THRESHOLD() and
RCVSIZOPT() of the Journal Receiver were included in the given details;
perhaps the Size shown above, exceeds the Threshold? Were there messages
that were sent to the [history and\or] the MSGQ() for that journal, that
indicate a problem\oddity?

The manual process to detach the receiver would be the CHGJRN I offered;
for that specific journal [presuming the *JRN is in QSYS; otherwise,
correct the library name in the request]:

CHGJRN QSYS/QDBJRNXRFQ JRNRCV(*GEN)

--
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.