Chuck,
I see a similar pattern on my other LPARs, including a new "guest" partition.
It appears that some of the journals in QRECOVERY are created before the LPAR name is set in CHGNETA.
I ran the command you listed earlier in this thread, with the only difference being the library, QRECOVERY, not QSYS.
CHGJRN JRN(QRECOVERY/QDBJRNXRFQ) JRNRCV(*GEN)
Most journals have a new journal receiver created with more frequent time period.
If not, should this be part of a normal maintenance, possibly included in QSTRUP?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, July 14, 2014 3:54 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Journal receivers
On 14-Jul-2014 12:38 -0500, Steinmetz, Paul wrote:
I found something interesting.
On my production LPAR, PENCOR05, I see:
QDBJXQ0001 *JRNRCV QRECOVERY
However, it was created on my R&D LPAR, Pencor06, I'm confused about
that. It almost matches the date I migrated from P5 to P7, which was a
total system restore, 2 days later, 05/06/12.
Creation information:
Creation date/time . . . . . . . . . : 05/04/12 18:30:41
Created by user . . . . . . . . . . : QSYS
System created on . . . . . . . . . : PENCOR06
And presumably the "Save/Restore information" is all blank(s). If so...
Objects in the QRECOVERY library are solely for the purpose of the OS [essentially to reflect the current operational\recovery status of the installed\active system and IPL], so whatever is stored in the "System created on" attribute of the Object Information Record\Repository (OIR), is immaterial. The objects are thus never saved as part of B&R, and should never be [saved and then] restored to the same or another system\partition. The point at which some of the objects in that library [as External Objects for which an OIR is maintained] are /created/ for a release [or IPL or phase\era\whatever] legitimately may be generated such the OIR may not be consistent with other objects that are instead /installed/ either with the release or with maintenance.
Aside from possibly improper restore activity... That seemingly anomalous attribute is likely easily explained by the history of the storage location for the Network Attributes (see CHGNETA), most probably as it existed at the time of the D-Mode IPL. Had that storage area contained the actual [not a pending] name of PENCOR06 instead of the new\eventual name PENCOR05, then the latter name value likely would have been assigned sometime later in that D-Mode IPL, overwriting the old value. That change would occur later than when the /recovery/ object [in this case, a *JRNRCV object] was required to be established [for the purposes of the OS]. Note: the Journal Receiver object is created before the Journal object; the *JRN may [and likely does?] share the same System Created On attribute as the *JRNRCV.
If the SAVSYS or DSLO being used to install the partition that would eventually become PENCOR05 had originated on a system named PENCOR06, then the latent name information from the Network Attributes would be a probable [and acceptable\legitimate] effect given that NetAtr storage area was restored or existed\remained-on-disk prior to the creation of that new *JRNRCV object, and that *JRNRCV object was created [and assigned the value from that storage location, by the Librarian (LI) component] before the [re]assignment of the partition name to the new value of PENCOR05.
--
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.
midrange.com
