I have some challenges when stopping the DB2 DDF function. It is expected for the DDF to stop immediately. However, lately I have had persistent threads that prevented this process to complete for upto 30 mins.
Are there any suggestions on how best to handle this process?
=DB2P- STOP DDF MODE(FORCE)
No checking done here
Then we start the DDF with the following command
No Checking done here
I sometimes see
DSNL024I =DB2P - DDF IS ALREADY IN THE PROCESS OF STOPPING
Not currently monitored for. This will be added to OPSMVS Msg rules
Then when the DDF Display is done with DETAILS it shows
DSNL080I =DB2P- DSNLTDDF DISPLAY DDF REPORT FOLLOWS: DSNL081I STATUS=STOPGF DSNL082I LOCATION LUNAME GENERICLU
Other than putting in a lot of code and checks and double checks, any easier way to handle this type of issue?
I am planning to implement R13.5 with SSM3 in the near future. Anything in there I can use?
If you are using SSM to control this task you may consider using the SSMCNTL sample rule and the FCYCLE function. If the current OPS release is 12.3 or older the SSMCNTL rule can be found in the CCLXSAMP library. If OPS is 13.0 or 13.5 then the sample rule can be found in the CCLXRULM library.
Please, read the comments section of this rule regarding the FCYCLE function. There are some actions that must be added to the action table for this function to work properly. The actions to be added are described in the label "Fcycle:" of the sample rule.
Basically, the FCYCLE function will stop a resource and restart only after it completes the shutdown.
The SSMCNTL rule works with both SSMV2 and SSMV3.
Carlos Mario Silveira Filho
Principal Support EngineerCA Technologies A Broadcom Company
So it sounds as if you are recycling just the DDF component of DB2 and not full DB2 stop/restart, is that correct? Either way, some version of the SHUTDB2 sample pgm could be utilized to perform cmd1, probe, issue cmd2, etc. We actually have added code to create a dynamic MSG rule on the DSNL006I event (DDF Stopped as a result of STOP DDF) that is used in the probe stage of SHUTDB2 to determine if MODE(FORCE) is required or should be bypassed and the logic move on to the next shutdown command (rather than issue DDF MODE(FORCE) and wait around again if it is not needed). Again, not sure of your exact details of the issue, but I'm sure SHUTDB2 can be used as a good template for whatever you are doing. As for comments of moving to SSM3 - pros and cons for moving off where you are with SSM (SSMv2) and depending on how much you customized SSM from out of the box functionality or how involved your SSM environment is, it may not be of any value to you. So just make sure you know what you gain and what you lose before going through the effort.
Basically we current do a LOG SUSPEND/STOP DDF/LOG RESUME/START DDF
This is for full volume dumps to be done later.
This particular instance, the DDF START failed on one DB2 system. We noticed later the DSNL024I message saying to could not be started because it was stopping. The DDF Stop command took almost 30 mins due to on TSO QMF user. When that user timed out, then the DDF Stop worked. But OPS/MVS no longer was monitoring for DDF Start up. I am looking to ensure that the DDF START command does work, or at least try to have OPS/MVS validate periodically that it is up. The DDF DISPLAY DETAILS would show STATUS=STARTED in our case STATS=STOPGF.
I don’t believe you will find any out-of-the-box sample to perform these exact procedures. While there is no magic button or easy method (without in depth code) there are enough samples that illustrate the main logic or foundation template of creating an ‘initiate and monitor’ application, such as the SHUTDB2, SHUTCICS,EOJXYS pgm. This main logic of course is driving an initial pgm to start the process or actions in a serialized approach (LOG SUSPEND, then when done/issued, STOP DDF, then when STATUS = STOPPED, next cmds, etc) needed to do ‘xyz’. Depending on the time for each process/action, a dynamic monitor TOD rule can be created to ‘continue’ the process (wakes up on some x mins interval for some allotted max time to monitor, perform next steps, alert of failures, indicate ‘all-done’.) This monitor and next step logic can be coded directly in the dynamic TOD rule, or simply re-drive the same pgm, passing a different argument to initiate a different ‘phase’ or phase1,phase2,phase3,etc logic based on the next firing interval for the TOD rule. The method of having the TOD rule drive the same program will allow you to create one focal application to do ‘xyz’ from start to finish.(rather than multiple pgms and rules). The number of phases in the pgm and the logic within each one will of course depend on the exact process (need to keep track of last actual command, query some variables set by events issued as a result of actions, etc). Sounds like a lot of work, but once you do get this ‘initiate and monitor’ template built to address this DDF automation, you will use it throughout all your ‘multi-process‘ automation. Hopefully this and a glance at the noted samples will get you going with creating this type of monitor application needed to resolve this issue.