MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2014

Re: QPTFOBJ1



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact