RE: Journal receivers

Is it possible the numbering has rolled over?

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee
Sent: Monday, July 14, 2014 7:48 AM
To: Midrange Systems Technical Discussion
Subject: Re: Journal receivers

I presented insufficient information. I thoughht 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?

Thanks,

John McKee


On Sat, Jul 12, 2014 at 8:23 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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

<<SNIP>>

Looking at other journal receivers, I see a few large ones in
QRECOVERY. Specifically, QDBJxxxxxx and QSQJRN0391. Biggest is
QDBJXQ0001.

I do not recall specifically the latter naming, but I am almost sure
I recall what the associated journal is for; the *DBXREF queue
(QDBXREFQ*
x/0AC4) journaling. With the associated Journal (*JRN) name, finding
[if there is any] more specific documentation\information would be easiest.

Is there a process that is supposed to be run to detach these

receivers, or is that just done manually?

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.

Note that the QRECOVERY library is omitted from the Backup phase of
B&R [thus effectively, the origin for the system library name prefix
paired with the word "RECOVERY"].

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. Of
course, over time, the receiver will again fill-up approaching the
maximum allowed size before system-managed change to a new receiver.
Although the journaling environments could be customized [from the
defaults], normally that would only be done to enable problem
investigation or to circumvent a problem with any negative effects per the defaults.

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

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