DB2 - L

 View Only
  • 1.  Db2 z/OS 12 - I'm having a HOLDDATA nightmare

    Posted 10 days ago
    hey guys,

    I am REALLY having a HOLDDATA nightmare - due to one reason or another, we last applied maintenance to our Db2s about 6 months ago, and so have a huge number of PTFs to apply now.

    Imagine my shock-horror when I saw that out ++HOLD REASON(ACTION) list was about 6,000 lines!

    And then I noticed that for some unknown reason have included all the HOLD text for each PRE and SUP PTF, in the ++HOLD ACTION body of each PTF – I don't know if this is the case for the other products as well, but it certainly means >6,000 lines of HOLD data for our product, and a lot of replication to be sorted through.

    I mean I thought ENHANCED HOLDDATA just gave you the blasted details of whether the PTF was already there, and a list of pre- and co-requisites and dependencies, but I have never in my working life seen such a jumble, with the PTF ACTION text nested under the other one... 

    What would you do?


    Just to give you an example, I have included a few of the "duplicate" PTFs below:


    • UI71386
    • UI77402
    • UI77492
    • UI77516
    • UI77913


    For example:



    *----------------------- UI77711 (I - 13.11.2021) ----------------------

    * FMID HDBCC10 - DB2 BASE Z/OS                                         


    ++ HOLD(UI74139) SYSTEM DATE(21292) FMID(HDBCC10) REASON(ACTION)       




    R1xx                       CSI QUERY - SYSMOD ENTRY           Row 1 to 4 of 10

    ===>                                                          SCROLL ===> CSR


     To return to the previous panel, enter END .                                



     Primary Command: FIND                                                        


     Entry Type:  SYSMOD                              Zone Name: xxxxxxx         

     Entry Name:  UI77711                             Zone Type: TARGET          



       Type:    PTF                   Status: APP                                

       FMID:    HDBCC10                                                          

       Date/Time: 21.317   14:53:37   APP                                        




             -------- -------- -------- -------- -------- -------- --------      

    PRE      UI62080  UI65816  UI70412  UI73152  UI75102  UI77708                

    SUP      AH31959  AH34378  AH38175  AH41024  BH34378  CH34378  UI73328       

             UI74139  UI76481                                                    



    *----------------------- UI78178 (I - 03.01.2022) -----------------

    * FMID H0IHC10 - IBM DB2 Administration Tool for z/OS             




       Check existing CM batch JCL for CLASS                          

       in any of the job_card_line parameters and make                 

       any applicable adjustments.                                    




                 PTF UI77516 already installed/superseded in platform xxxxxxx



       Existing CM batch JCL should be checked for options that are   

       mutually exclusive to TARGET_TYPE = 'AUTO' and were previously 

       silently passing. Those jobs will now fail with the updated    

       error handling.                                                



    Stay safe and healthy, y'all

  • 2.  RE: Db2 z/OS 12 - I'm having a HOLDDATA nightmare

    Posted 10 days ago
    I recognize this PTF...UI74139. We actually ran into this problem with our DDF enclaves due to high performance DBATs. UI77711 is the PTF that "fixes" that issue, combined with a new WLM function. I wrote a blog post about it:


    The WLM code that interfaces with UI77711 may or may not be available yet. Not sure SMP/E would know about it since it's in a different SREL. So 77711 has to post the same warning as 74139.

    For giggles, I tried an APPLY CHECK for UI77711 on my own system, where 74139 is already on. It did NOT show the HOLDDATA for UI74139. So my guess is that your APPLY is bringing in both PTFs, and 77711 is superseding 74139...but the effect to the enclave management code is the same, so 77711 is set up to dig up the 74139 HOLD ACTION and display it to you, so you know about it.

    You can confirm this for yourself...the output from your APPLY CHECK should show UI74139 as superseded and UI77711 as APPLIED. Is that what you're seeing?

    Mark Wieczorkowski
    Db2 Systems Programmer
    Principal - Solipsistic, LLC

  • 3.  RE: Db2 z/OS 12 - I'm having a HOLDDATA nightmare

    Posted 9 days ago
    Hi Mark,

    that's not the issue, though thanks for taking the time to reply.

    The issue is: since when do I fid nested detailed HOLD ACTION data text inside superseding/co-requisite PTFs, instead of just a mention of PRE/CO/SUP in the APPLY CHECK header?


    Stay safe and healthy, y'all

  • 4.  RE: Db2 z/OS 12 - I'm having a HOLDDATA nightmare

    Posted 9 days ago

    I might be a bit confused about what you're saying. Does the HOLD ACTION for UI74139 appear twice? Or is it just that you're not used to seeing the HOLD ACTION for a supersedED PTF printed out under the supersedING PTF? If 6 months is a long time for you to go between services, you may NOT be used to that amount of superseding PTFs and HOLDs.

    Technically, UI74139 never went on your system, since 77711 superseded it. But 77711 includes the code-change made in 74139. So it has to display the HOLD ACTION for that code-change. It doesn't particularly matter whether the HOLD is printed out under 77711 or 74139, but you need to see it once.

    In your other case, UI78178 and UI77516 for the Admin Tool, you actually have two different HOLD ACTION texts. SMP/e isn't smart enough to read them and interpret them as "saying the same basic thing"...if it was, they wouldn't have to employ you. :) If that action is a common recommendation for that FMID, you may see it multiple times. But each SPECIFIC hold item should appear only once.

    This is pretty common. We try to be on a 6-month maintenance cycle for Db2, and there's always several PTFs that recommend the same action with different wording or for different reasons...for example, "Run DSNTIJRT" or "re-tailor your CLISTs". In fact, so many fixes were displaying HOLD ACTIONs that said, "REBIND to make this fix active for static packages" that IBM created a whole other HOLD class for it. (DB2BIND) They all tag back to different fixes, but the wording is virtually identical.

    Mark Wieczorkowski
    Db2 Systems Programmer, SSA/DCS
    Principal - Solipsistic, LLC

  • 5.  RE: Db2 z/OS 12 - I'm having a HOLDDATA nightmare