RE: Re: Failure to permanently apply ptf's prior to an upgrade

Rob:

Normally I wouldn't expect any savefiles to be created just because I applied a 
PTF, though IFS stuff might work differently. Typically, I'd expect:

1. I download a PTF that will fix PGMA in lib LIBA.
2. This download results in savefile QPGMA in QGPL (made up name).
3. I LODPTF. This results in:
   a. New pgm PGMA being restored into lib QSRV.
   b. QSRV/PGMA gets temp named to Qxxxxxx.
   c. QSRV/Qxxxxxx is moved to lib LIBA.
4. I APYPTF *TEMP. This results in:
   a. Old pgm PGMA gets renamed to Qyyyyyy in LIBA.
   b. Qxxxxxx is renamed to PGMA in LIBA.

Ownership, authorities, etc., are then set accordingly. A RMVPTF would result 
in the reverse renaming. I didn't test this next, but when APYPTF *PERM is 
later run, object Qyyyyyy would either simply be deleted or moved to QRPLOBJ or 
something similar. (I don't recall the normal sequence.) No reason for the 
process not to just delete, I suppose.

Now, any PTF can have exit programs attached that are called during the 
process, and they can create savefiles or do anything they're written for. But 
it seems risky to create objects outside of the product library, especially 
objects that don't seem to be linked via the PTF index back to a PTF number. 
I.e., when you try DSPPTF, you don't get hits.

Further, the name of the savefile(s) fits what's expected from IBM PTFs, and it 
fits an older naming convention -- pre-V5.

My next step would be a DSPSAVF to see info about when the save occurred. That 
ought to tell everything needed to decide what to do with it. I'm thinking now 
that a simple DLTF is where it will lead.

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

>   9. RE: Re: Failure to permanently apply ptf's prior to an
>      upgrade (rob)
>
>That didn't work.  SCPTFID like 'SF%' turned up nothing.  Again, I think 
>it goes back to the difference between the save file downloaded and the 
>backup save file created so that one can do a RMVPTF.
>
>Subject
>RE: Re: Failure to permanently apply ptf's prior to an upgrade
>
>midrange-l-request@xxxxxxxxxxxx wrote:
>
>> wrote on Thu, 16 Feb 2006 13:36:56 GMT:
>>
>>> Object      Object    Object      Creation
>>>             Type      Attribute   Date 
>>> QSF56133J1  *FILE     SAVF         042299 
>>> QSF56133J2  *FILE     SAVF         042299 
>>> QSF56133J3  *FILE     SAVF         042299 
>>> 
>>
>>It's been a while since I ran into this sitution, but I'm pretty 
>>sure that if you do a DLTPTF SF56133 it will take care of these 
>>three files.  You can do the same for the remaining ones on your 
>>list and it will clean things up in a similar manner.
>
>I haven't done it much either and not recently. But I seem to recall the 
>DLTPTF can be very picky. For PTF savefile objects that are leftover from 
>previous releases, I think it needs to be told explicitly the correct 
>ProductId _and_ the correct VRM.
>
>Perhaps a DSPPTF *ALL *ALL *ALL to an *OUTFILE will list enough info that 

>a useful DLTPTF command can be entered?