Re: Where are downloaded PTF's?

On 08-Aug-2016 13:50 -0500, Rob Berendt wrote:

Again, the "safest" way to clear them is with DLTPTF.

Or more simply, the /correct/ way to delete PTF Save Files is with the Delete PTF (DLTPTF) command. Some links to some past discussion:

[http://archive.midrange.com/midrange-l/201212/msg01145.html]
Subject: Re: installing ptf cume packages via *SERVICE/SAVF

[http://archive.midrange.com/midrange-l/201308/msg01071.html]
Subject: Re: Cleanup PTFs downloaded to *SERVICE

[http://archive.midrange.com/midrange-l/201004/msg00864.html]
Subject: Re: PTF Savefile

[http://archive.midrange.com/midrange-l/201308/msg00953.html]
Subject: Re: PTF install questions

Let me try to explain why.
Let's pretend you do a
DSPOBJD OBJ(qcnteddm) OBJTYPE(*PGM) DETAIL(*SERVICE)
and you do not see any ptf on it.
So (on 7.3) you order ptf SI59632.
When you temp apply that PTF it will save the original QCNTEDDM into
another save file. Let's say SH12345678 for example. Then it will
restore the new QCNTEDDM from save file QSI59632.

Unless the PTF feature had changed drastically, that description of what transpires for typical PTF apply processing for any *PGM objects is hokum.

The old object that is to be PTFed\replaced with a newer copy [that had been restored from the PTF save file, then renamed, and finally moved into the product library during Load PTF (LODPTF) processing] is essentially just renamed [again] to effect the Apply PTF (APYPTF) processing; the standard effect of APYPTF will *not* be to perform any SAVxxx processing [to make a backup copy] of the PTFed objects, as the /backup copy/ simply resides on disk with a different name just like the down-level object resided on disk with an alternative name.

The process did change within the past several releases to stop using library QRPLOBJ in which to place objects that are possibly\potentially still in-use pending an IPL; changed to instead use the libraries QPTFOBJ1 and QPTFOBJ2. But the /backup/ copies of a program still would reside as the object by another name, not as an object saved to a save file.

If you remove (not delete) PTF SI59632 it will restore QCNTEDDM from
SH12345678 to go back to the old version.
Now, if you permanently apply SI59632 it will delete SH12345678 and
that bridge is burned.

While there are some object[-type]s that will be shipped in a save file [e.g. non-/QSYS.LIB objects per inability to include both an effective SAV and effective SAVOBJ in one Save File object], delivered by having been saved into the PTF save file itself, I am confident such save file names will have a prefix such as QPZ1 or QPZ2. And the loss of anything that might have been saved previously into a QPZ save file per the permanent-apply action, is nothing different than the loss of any other PTF temporary objects; i.e. the /program-temporary-fix/ had since been made permanent, so there was no reason to maintain what was needed only /temporarily/.

That a Save File previously restored from a PTF save file might become effectively /orphaned/ due to the deletion of the PTF save file itself [per Delete File (DLTF)] should not be of great consequence [beyond the storage taken for not having been deleted by Delete PTF (DLTPTF)], because the object-naming for the temporary save file should make the object eligible for CLEANUP processing.

As for the possibility of data loss from deleting the PTF save files vs using DLTPTF, I am not so sure there is much of a concern; at least not so much for the permanent-apply scenario. For a scenario of a temporarily applied PTF, in which the _PTF save file_ is deleted, also should not be a concern. But if any _save files as PTF objects_ are deleted, rather than the _PTF save files_ themselves, then that could be problematic, if indeed those save files were used to make a backup of an older version of the object; however, I am thinking that those save-file objects would reside in the *product library*, not reside in QGPL where the PTF save files [that were registered with *SERVICE] would reside.? Thus, I do not see there should ever by any /safety/ issue with regard to data-loss when deleting actual PTF save files by means other than the DLTPTF.

What this is telling you is:
- Regularly permanently apply your PTF's to save space by removing
the backup copies.

While that action moves the renamed objects into another library, until an IPL, the storage is not reclaimed. And from what I recall, a PTF that arrived as a save file, registered with *SERVICE, does not get deleted with a perm-apply; that still awaits DLTPTF.?

- Do not clean up the backup copies yourself or you've screwed up
your ability to RMVPTF.

If only deleting save files that were registered with *SERVICE and by naming should be the various QS_##### [and QM_#####] *FILE objects with attribute=SAVF in library QGPL, then as alluded earlier, I am not sure there would be any harmful effect with [the ability to or] the action of Remove PTF (RMVPTF). The conspicuous problem with using DLTF vs DLTPTF, is that the PTFs that had been registered with *SERVICE would not get properly de-registered from *SERVICE, and thus remnants of their existence may appear in Display PTF (DSPPTF) output or in output of any PTF-category APIs.

- Do the DLTPTF regularly to clean up the save files containing the
'new copies'.

True enough, if those PTF save files are not being maintained for other purposes; e.g. to be sent to other systems.

Although I was under the impression that most installations would have PTF save files only rarely, primarily existing for the purpose of resolving the special value *SERVICE and which generally as the effect of having arrived via Send PTF Order (SNDPTFORD) to obtain specific fixes that were not otherwise obtained as images; i.e. loading from images is more typical than loading from *SERVICE? As apparently is the case for the OP. The other typical purpose, being to maintain a copy of PTFs [on a central system], for distribution to other systems.

- DLTPTF will also remove the members held in
WRKMBRPDM FILE(QGPL/QAPZCOVER)
or
WRKLNK OBJ('/QSYS.LIB/QGPL.LIB/QAPZCOVER.FILE/*')

As noted already in a prior reply, I expect the OP might want to invoke the following, as probable recovery; a bit less aggressive than the PTF(*ALL) in the first followup reply to the OP:

DLTPTF PTF(*SAVFONLY) LICPGM(*ALL)
RLS(*ALL) DLTDUPPTF(*YES)