Re: Rebuilding PTF indexes (was RE: V3R2 LIC) -- MIDRANGE-L

I had the notes from this for a problem I had years ago - maybe back 
around V2R1 or V2R2.
I have not run it since then.

CAUTION - I see this warning in the two APAR's included below:


                !!! WARNING !!!
      DO NOT CALL QPZSYNC ON V3R1 OR HIGHER SYSTEMS
                !!! WARNING !!!





Actually, I don't believe it required a restricted state - just make sure 
no one else is running any  PTF jobs or licensed program installs/deletes 
at the same time.


You could just try reapplying the (reinstall the last cum package and see 
what that does).

The other method, which you would have to do anyway if this QPZSYNC screws 
up or can;t be used, is a reinstall of LIC (I don't think you need to do a 
SLIP install of the operating system too as your SS1 PTFs are showing up 
in DSPPTF, but I may be wrong) followed by reapplication of the PTF's.  If 
you install from your own SAVSYS that contained all the PTF's in the first 
place it may not be necessary to reinstall the PTF's.


PS - found this APAR SA24477 - note the warning in Circumvention section.
Note that logical file QAPZPTF4 was added at V3R1, so that may be the only 
reason for the caution not to use the circumvention (you could just delete 
QAPZPTF4 as well and try it if you feel lucky  ;-)   ) - but on the other 
hand, maybe QPZSYNC can REALLY screw things up at V3R1 and later (see 
below this the info for APAR SA31285 and the warning about QPZSYNC in the 
COMMENTS section there):


Item SA24477 


  APAR Identifier ...... SA24477      Last Changed..96/05/07  
  OSP-CMDDSPPTF  NO LIC PTFS AFTER OS REINSTALL
 
 
  Symptom ...... IN INCORROUT         Status ........... CLOSED  PER
  Severity ................... 1      Date Closed ......... 92/09/03
  Component .......... 5738SS100      Duplicate of ........
  Reported Release ......... 220      Fixed Release ............ 230
  Component Name 5738 OS/400 ROC      Special Notice
  Current Target Date ..              Flags
  SCP ...................
  Platform ............
 
  Status Detail: Not Available
 
  PE PTF List:
 
  PTF List:
  Release 220   : SF11157 available 92/09/16 (BASE )
 
 
  Parent APAR:
  Child APAR list:
 
 
  ERROR DESCRIPTION:
  See problem summary.
 
 
  LOCAL FIX:
 
 
  PROBLEM SUMMARY:
  The following steps will cause the PTF files to become out of
  sync with the PTF index:
 
  1.  V2R2 system is installed
  2.  PTFs loaded/applied to the Licensed Internal Code and the
      Operating System.
  3.  Only V2R2 Operating System is installed again.
 
  The PTF files have now been modified so they do not match the
  PTF index.  A DSPPTF will no longer display the Licensed
  Internal Code PTFs and the Licensed Internal Code PTFs cannot be
  loaded again.
 
  Note:  It is step 3 that will cause the sync problem.
 
 
  PROBLEM CONCLUSION:
  The restoring of PTF information will be modified to only change
  the PTF index and files when Licensed Internal Code has just
  been installed.
 
 
  TEMPORARY FIX:
 
 
  COMMENTS:
 
 
  MODULES/MACROS:   QPZSRD
 
 
  SRLS:      NONE
 
 
  RTN CODES:
 
 
  CIRCUMVENTION:
                  !!! NOTE !!!
  DO NOT USE THIS CIRCUMVENTION ON V3R1 OR HIGHER SYSTEMS!
 
  If a DMPSYSOBJ for the PTF index is performed for Licensed
  Internal Code and the index contains information and DSPPTF does
  not show the PTF, the information is out of sync.
  DMPSYSOBJ OBJ(QGPL) CONTEXT(*MCHCTX) OBJTYPE(*LIB) OFFSET(40)
  Where QGPL is the library that contains the index in question.
  (ie. QGPL is LIC 5738999, QSYS is 5738SS1, etc...)
  Do the following to recover:
     1.  Delete the logical file QUSRSYS/QAPZPTF3
     2.  Delete the logical file QUSRSYS/QAPZPTF2
     3.  Delete the physical file QUSRSYS/QAPZPTF
     4.  CALL PGM(QPZSYNC) PARM(C)
 
  During the CALL
     1.  The remaining PTF files are deleted from QUSRSYS.
     2.  New PTF files are put in QUSRSYS.
     3.  PTF information for installed products, PTF save files
         and cover letters will be obtained from the system and
         put into the new PTF files.
 
  A user may now perform a DSPPTF and will have all the current
  information.
 
 
  MESSAGE TO SUBMITTER: UPDATED 09/05/92



Item SA31285 


  APAR Identifier ...... SA31285      Last Changed..96/05/08  
  OSP-MSGCPF3616 DSPPTF MPTFI FILE NOT IN THE CORRECT STATE TO BE
  ABLE TO APPLY PTFS
 
  Symptom ...... MS MSGCPF3616        Status ........... CLOSED  UR5
  Severity ................... 2      Date Closed ......... 93/12/14
  Component .......... 5738SS100      Duplicate of ........
  Reported Release ......... 220      Fixed Release ............ 220
  Component Name 5738 OS/400 ROC      Special Notice
  Current Target Date ..              Flags
  SCP ...................
  Platform ............
 
  Status Detail: APARCLOSURE - APAR is being closed.
 
  PE PTF List:
 
  PTF List:
 
 
  Parent APAR:
  Child APAR list:
 
 
  ERROR DESCRIPTION:
  Customer has tried to load a PTF and they get MSGCPF3616. This
  is telling the user that the PTF is already loaded or the lic
  products is not installed. After research of the system the
  PTF is not loaded and the LICPGM is installed at the correct
  release. I had the user run CALL QPZSYNC PARM'C' and now the
  PTF shows as loaded. She does the apply and the system comes
  back and tells her that there are no PTFs available. The call
  program is called again and now all PTFs show up and the one
  is question is also loaded.
  If the user does a GO PTF OPT8 the PTF process works fine. The
  problem is occurring when she works with individual ptfs. It
  appears that we are doing something to create a problem with
  MPTFI files that needs a CALL QPZSYNC PARM'C' to put everything
  back in order.
 
 
  LOCAL FIX:
  The fix that at least keeps the cust going is to run the CALL
  QPZSYNC PARM 'C' program.
 
 
  PROBLEM SUMMARY:
  Customer has tried to load a PTF and they get MSGCPF3616. This
  is telling the user that the PTF is already loaded or the lic
  products is not installed. After research of the system the
  PTF is not loaded and the LICPGM is installed at the correct
  release. I had the user run CALL QPZSYNC PARM'C' and now the
  PTF shows as loaded. She does the apply and the system comes
  back and tells her that there are no PTFs available. The call
  program is called again and now all PTFs show up and the one
  is question is also loaded.
  If the user does a GO PTF OPT8 the PTF process works fine. The
  problem is occurring when she works with individual ptfs. It
  appears that we are doing something to create a problem with
  MPTFI files that needs a CALL QPZSYNC PARM'C' to put everything
  back in order.
 
 
  PROBLEM CONCLUSION:
 
 
  TEMPORARY FIX:
 
 
  COMMENTS:
  After attempts to reproduce the problem in the lab and
  inspection of the Load PTF and Apply PTF code in the areas where
  updates to the PTF Data Base Files occur, all have met with
  negative results.
  Part of the problem may have been caused by the calling of
  QPZSYNC. QPZSYNC was not meant to be called as an API. Since
  QPZSYNC does not do any error checking or locking and can take
  up to several hours to run, any PTF functions executed (such
  as DSPPTF) while QPZSYNC is still running will really destroy
  the PTF Data Base files.
  As a suggestion to customer, deletion of the QAPZPTF3,
  QAPZPTF2 and QAPZPTF files from QUSRSYS in that order followed
  by an IPL will rebuild the PTF Data Base Files. The rebuild
  will put everything in sync and the problem should disappear.
 
                !!! WARNING !!!
      DO NOT CALL QPZSYNC ON V3R1 OR HIGHER SYSTEMS
                !!! WARNING !!!
 
 
  MODULES/MACROS:
 
 
  SRLS:
 
 
  RTN CODES:
 
 
  CIRCUMVENTION:
 
 
  MESSAGE TO SUBMITTER:



...Neil





"Bale, Dan" <D.Bale@handleman.com>
2001/08/14 14:04

 
        To:     <midrange-l@midrange.com>
        cc:     <neilp@dpslink.com>
        Subject:        Rebuilding PTF indexes (was RE: V3R2 LIC)


Neil, where is this documented?  What releases is this available for? I've 
got a similar situation with a V4R3 box whose DSPPTF 5769999 screen starts 
out with the following column of PTF IDs:
RE98316 
RE98273 
RE98144 
RE98143 
RE98142 
QLL2924 
MF20589 
MF20583 
MF20515 
Nobody's ever been able to tell me what the RE entries are, but there are 
no TL entries and I find it hard to believe that we've been running this 
thing in production since who knows when without any cumes installed. 
FWIW, everything is either permanently installed or superseded.
Dan Bale 
IT - AS/400 
Handleman Company 
248-362-4400  Ext. 4952 
D.Bale@Handleman.com 
  Quiquid latine dictum sit altum viditur. 
  (Whatever is said in Latin seems profound.) 
-------------------------- Original Message -------------------------- 
-----Original Message----- 
From:   neilp@dpslink.com [SMTP:neilp@dpslink.com] 
Sent:   Tuesday, August 14, 2001 11:41 AM 
To:     midrange-l@midrange.com 
Subject:        Re: V3R2 LIC 
More likely the PTF index has somehow been destroyed. 
Try this (in a restricted state): 
 DLTF       FILE(QUSRSYS/QAPZPTF4) 
 DLTF       FILE(QUSRSYS/QAPZPTF3) 
 DLTF       FILE(QUSRSYS/QAPZPTF2) 
 DLTF       FILE(QUSRSYS/QAPZPTF) 
 CALL       PGM(QPZSYNC) PARM(C) 
...Neil 




Douglas Handy <dhandy1@bellsouth.net> 
Sent by: midrange-l-admin@midrange.com 
2001/08/14 11:09 
Please respond to midrange-l 
  
        To:     midrange-l@midrange.com 
        cc: 
        Subject:        Re: V3R2 LIC 

Pete, 
>when I did a  DSPPTF 5763999, it came up with no PTFs 
I just checked a 200-2031 machine at V3R2, and 5763-999 definately showed 
a long 
list of PTF's.  The highest numbers on that particular box were TL98139 
and 
MF18809.  I don't know if MF18809 was part of the CUME or not. 
The highest number for 5763-SS1 was TC98139.  All of these were 
permanently 
applied.  There were numerous superceded TL's and TC's before them. 
I believe 98139 was the last CUME issued for V3R2. 
Did the account never load a CUME?  That's scary.  At least they aren't on 

V3R1 
without a CUME... 
Doug