On 26-Jul-2014 21:54 -0500, rob@xxxxxxxxx wrote:
I have this library called QPTFOBJ1.
All the rest of my reply was composed prior to doing a web search;
presuming that was already done. Research will find that the library
objects named QPTFOBJ# [specifically QPTFOBJ1 and QPTFOBJ2] are
/incorrectly/ being saved; i.e. a defect.
However I did not review closely, for what might have been noted [in
what was found] about expected changes to the documentation\help-text
for the GO SAVE, SAVLIB, or BRMS; corrections to those may need to be
pursued separately as defects, to ensure those are also corrected, if
the dev fail to do so. The conspicuous APAR states nothing in that
regard, and a separate APAR conspicuously addressed only functional
aspects rather than docs, so entirely possible nothing will transpire
due to being overlooked per concentrating too much on one aspect.
<www.ibm.com/support/docview.wss?uid=nas213072a42e86dda6e86257b2800420afb>
SE55154 - OSP-INCORROUT DO NOT SAVE LIBRARIES QPTFOBJ1 AND QPTFOBJ2
<www.ibm.com/support/docview.wss?uid=nas2475af595c99ca5b586257b1000424088>
SE54834 - OSP-INCORROUT Messaging for libraries QPTFOBJ1 and QPTFOBJ2
Worth including, in full, I suppose [esp. given the Subject of this
topic]:
<www.ibm.com/support/docview.wss?uid=nas8N1019919>
TechNote (FAQ) Reference #: N1019919
"Question:
What is the purpose of the QPTFOBJ1 and QPTFOBJ2 IBM libraries?
Cause:
New libraries, QPTFOBJ1 and QPTFOBJ2, are used at IBM i R610 (with PTF
SI49671), R710 (with PTF SI49517), and later releases when PTFs are
permanently applied.
Answer:
When PTFs are permanently applied, they are renamed and moved to a
staging library. At releases previous to R610, this library was QRPLOBJ
and now it is QPTFOBJ1 or QPTFOBJ2. During each IPL, PTF management
toggles between using the QPTFOBJ1 and QPTFOBJ2 libraries for
permanently applied PTF objects, where 1 library is active and the other
is inactive. At IPL time, the inactive PTF library is cleared. At each
IPL, the systems alternates clearing these libraries.
The reason this support was added was because when users cleared the
QRPLOBJ library, some permanently applied PTF objects (programs) could
still be running or referenced and the clear would cause the system to
crash. Even when the user did not clear QRPLOBJ explicitly, when the
system applied delayed PTFs to early IPL code, the system could still
crash when the system cleared QRPLOBJ during an IPL. That is why two PTF
cleanup libraries were created and the system alternates between them.
NOTES:
1. Users are not allowed to clear, delete, save or restore these new
libraries as they only contain temporary IBM data.
2. When PTFs are perm applied, it is possible that the PTF's OPM
programs are still running. If a user wants to free up the storage, the
system should be IPLed to clear the QPTFOBJx libraries.
"
All the objects in it look like programs and save files from PTF'd
Domino and Sametime stuff. 7.1
I did an unload/reload, using BRMS, from a Power 6 to a Power 8.
Library QPTFOBJ1 is on the Power 8, but none of the objects are.
On the old system none of the objects have a save date/time.
In default\normal B&R, the non-system libraries named with a Q-prefix
would only be saved by a request to SAVLIB *NONSYS or SAVLIB *IBM. The
Library (LIB) parameter /special-value/ to indicate All User Libraries
(*ALLUSR) that is available on the Save Library (SAVLIB) requests would
*not* include that library named QPTFOBJ1.
And only explicit requests to SAVLIB the library, by [generic] name,
would effect a standard backup with the possibility of the history
included for the objects themselves. That is because even if the Update
History (UPDHST) was requested with UPDHST(*YES) on a *NONSYS save, then
the save timestamp would not have been updated; instead "If a group of
libraries is saved by specifying *NONSYS, *ALLUSR, or *IBM for the LIB
parameter, the date, time, and place are updated in the history
information for a data area in QSYS (data area QSAVLIBALL, QSAVALLUSR,
or QSAVIBM)." Note: the *NONSYS save is just an amalgam of *IBM and
*ALLUSR.
How the BRMS implements the *NONSYS, or its equivalent that was used
for unload\reload, might be other than an actual SAVLIB *NONSYS.? I
doubt, but, possibly that B&R feature could actually include saving the
library object; perhaps being only least somewhat consistent with the
*NONSYS, merely omitting the objects from the Q-prefixed library.?
Given a *IBM or *NONSYS save must have the QFILE as the first label\file
on the save, to allow non-BRMS save from that media, I would expect an
actual *NONSYS save must be the effect for BRMS.
The programs in QSYS2 do <ed: have save history>, so I am guessing
it's not one of these "well the whole library was saved so we're not
going to waste time updating individual objects" kind of things.
The QSYS2 is a quasi-user\quasi-system library; as part of the set of
libraries deemed /user/, that library is saved with the SAVLIB *ALLUSR
request; despite the Q-prefix naming. Again, the save history is
outside the object for such a save, so that there is history for this
library is unexpected unless saved explicitly\separately than with the
All-User save.
This also leads me to believe the issue was with the save, and not
the restore.
Per /history/ settings, I would not be too confident of drawing that
conclusion. I would check the BRMS logs, joblogs, and history logs for
the save activity, and then check the restore joblog and history logs of
the restore activity.
Let me guess, the library definition got restored as part of QSYS,
The restored library has its Object Information Record (OIR) created
in [inserted as a new entry into the storage maintained by] the new
library QSYS. The new library QSYS would AFaIK, have been /created/ on
the target system being installed; being the only *LIB object not /in/
the QSYS *LIB object, I am not sure of what is the
implementation\storage of its OIR.
but with a name like QPTFOBJ1, IBM couldn't decide if it was *IBM or
*ALLUSR and both ignored it.
Starting with the letter Q, the *IBM should include the library
irrespective any other attributes [except when explicitly excluded, as
noted in the documented list of (generic) library names that are
omitted], and the *ALUSR should omit the library irrespective any other
attributes [except when explicitly included, as noted in the documented
list of (generic) library names that are included].
Object domain . . . . . . . . . . . : *SYSTEM
Every *LIB object is /system domain/, such that only System State
programs can access the object directly; i.e. only methods provided via
the OS allow actions against the *LIB object.
Other attributes like "Created by user" and "System created on" would
be more telling in that regard. And in this case, if there is no
/restore/ activity recorded in the OIR, then that in conjunction, would
also be very telling.
Regardless, the logs for the save and restore are what really need to
be reviewed to figure out why the objects in the library QPTFOBJ1 were
not included, and on which end they were omitted or excluded.
Is this a problem?
Seems a suspect outcome. I would expect the Q-prefix library to have
been saved by a SAVLIB *IBM [or the equivalent work, if implemented
differently, only mimicked, by the BRMS]. And while the ability to
effect restore of the saved program objects might be questionable for a
variety of possible reasons [per not being /user/ programs], the save
files should have had no issue neither with save nor restore.
midrange.com
