Re: upgrade to v7r1 ii14482 recommend to delete USER_STG files

On 15-May-2014 15:46 -0500, Jim Franz wrote:

Preparing v6r1m1 to V7r1 on a partition.
Info APAR II14482 says:
<clip>
The following database PTFs are needed to avoid a database cross
reference file error condition during the upgrade to 7.1:

If you are upgrading from V6R1Mx - SI45174
SI47823
SI47825

If these PTFs are not applied to the previous release prior to the
upgrade, a RCLSTG SELECT(*DBXREF) may be required following the
install of the operating system in order to successfully install
several products that are dependent on the data in the cross
reference files.

For V6R1Mx you also need to take the following actions AFTER you have
applied PTFs (application of database PTFs can recreate these views):
*
DLTF QSYS2/USER_STG
DLTF SYSIBMADM/USER_STG
*
Failure to do so, will result in having to run RCLSTG SELECT(*DBXREF)
to repopulate cross reference column level information following the
upgrade to 7.1.
</clip>

So when exactly do I delete the 2 files - while on 6.1, after the
PTFs applied (they already are).?

I just don't understand the phrase:
"For V6R1Mx you also need to take the following actions AFTER you
have applied PTFs (application of database PTFs can recreate these
views):"
These PTFs were applied weeks ago, but Operations, but no file
deletions.

Inferring [and from memory] they are two distinct problems, both which have the same recovery action post-upgrade. As I understand: 1> The noted PTFs are preventive to the first of those issues that would require the Reclaim of the *DBXREF as recovery. 2> The second issue that would require the Reclaim of the *DBXREF as recovery has no preventive PTF, and instead depends on the user to delete the files prior to the upgrade; though I see no reason why a PTF would not be issued to resolved the second issue too. A PTF that withdraws the support for those VIEWs and effects deletion of those files could be effected by modifying the code that creates those files [program QSQSYSIBM as I recall] to no longer issue those two CREATE VIEW, then making a new PTF that is both described as preventive [and withdrawing that support] and has the PTF with file-creation code revision called-out as a pre-requisite.

Knowing how the those VIEW files are delivered [i.e. via a PTF that effectively submits a job to (re)create some files in QSYS2 and various libraries with prefix SYSIBM] and that the intended implication is that the existence of these files during the upgrade to IBM i 7.1 [v7r1] causes a failure in the upgrade of the System Database Cross-Reference file(s) [naming prefix QADB in QSYS] that is a based-on file of those VIEWs, my SWAG is that after any new PTF load\apply activity on the v6r1 system *since* the prior time those files were deleted, the Delete File (DLTF) requests should be repeated [in case any of the PTFs that was applied had effected the re-create of those VIEW files]; i.e. those two DLTF requests would be added to the System Change Management as part of post-PTF-apply processing until no longer on that release.

However, simply delaying the noted DLTF activity until just before the upgrade irrespective any PTF activity would suffice. Yet deleting them presently [assuming they are unneeded] ensures the action was done at that moment, and then if no PTF activity occurs since, then any IPL that might start an install would be prepared; e.g. on rare occasions a pwrdwn or crash might be followed by an unplanned install to a new release [rather than trying to IPL to the current release] which would make the DLTF activity difficult if not impossible.