Customization for initial Job Flow Monitor setup.
search cancel

Customization for initial Job Flow Monitor setup.


Article ID: 29078


Updated On:


CA 7 Workload Automation


It is imperative that you become current on CA 7/JFM maintenance. 

The JFM started task JCL should have REGION set to 0M and MEMLIMIT set to NOLIMIT, as well as having          
TIMELIMIT set to NOLIMIT.                  

 The JFM STC JCL should include a CEEOPTS DD card containing        
some critical tunings to the IBM defaults for the Language Environment;       
most noticeably, to demand freeing of any 64 bit storage obtained by a         
program running under the LE.  Please add the following card to your JFM      
STC JCL after modifying the dataset and member values to match your           
//CEEOPTS  DD DSN=&PREFIX..CNTL($JFMOPTS),DISP=SHR                            
Within the $JFMOPTS member, you should include the following tunings:         
DYNDUMP(ÝYour cai HLQ¨.JFM.ILEDUMP,DYNAMIC,TDUMP),                            
***NOTE: alter the HLQ in the DYNDUMP parameter to one acceptable for         
         your Sysplex...                                                      
In addition, within the JBFLWMN member we recommend altering the following MONITOR settings in order to observe       
minimum storage and CPU thrashing.  If you are also using CPM, you should not use WARM start for TYPE.  Once a   
performance baseline is established, you may alter SPAN and HISTORY as needed to reach an acceptable balance between performance and prepared  forcasting:                                                               
Next, within the JBFLWIP member, ensure you have the following card in addition to any QRYPORT cards, as it will further ensure that JFM handles start-up in the expected manner:                              
PORT(NAME(CPMPORT) NUMBER(NONE))                                          
Next, replace the SYSUDUMP DD card (if any) with a SYSMDUMP card in the JFM STC JCL.  If possible, ensure the dump     dataset is as large as possible in order to catch all of the contents of the address space along with the LEDATA blocks.  The following example allocation may be sufficient for most environments, but it is recommended that you consult with your Systems Programmer for details:                         
//SYSMDUMP DD DSN=EXAMPLE.JFM.SYSMDUMP,                                   
//            DISP=(NEW,DELETE,CATLG),                                    
//            MGMTCLAS=IPCSDUMP,                                          
//            STORCLAS=IPCSDUMP,                                          
//            DATACLAS=IPCSDUMP,                                          
//            UNIT=SYSDA,                                                 
//            SPACE=(CYL,(1000,500),RLSE),                                
//            DCB=(DSORG=PS,RECFM=FBS,LRECL=4160,BLKSIZE=24960)            
Also within the JFM started task JCL, alter or include the CAJFLOG card as follows, and replace the marked items as necessary for your environment or Systems Programmer recommendations:                        
//CAJFLOG  DD SYSOUT=$,SPIN=(UNALLOC,nnX)         <-- System messages     
 ~Where $ should be replaced with a SYSOUT class that can handle  off-loading large log chunks at a fast pace (e.g. CA-View)              
  ***NOTE: Do not use this syntax with SYSOUT=* as it will result in all log chunks being discarded!  If you must use the JES spool to hold the log, then omit the SPIN parameter entirely -  ~and nnX should be replaced with the numeric amount of lines  that will    trigger each spin-off event (e.g. 10M - meaning ten million)            
Once this is complete, you can alter the LOGLEVEL within the JBFLWAS member to be set to LOGLEVEL(3).  This will produce prodigious amounts of log, and so the previous SPIN allocation is necessary to make the output manageable.  It will, however, greatly increase our ability to pinpoint the cause behind your issue.  Once the issue has been resolved, you may revert to LOGLEVEL(0) and SYSOUT=* if you prefer.  

In addition, we would like you to issue a modify command to the JFM STC as soon as it has finished the IntialBuild for all tracked instances of CA7, and again just before any dump:                         
F <JFM STC name>,STATUS                                                   
This will display critical information about the current environment within JFM.                                                               
If you capture the following items at the time you see JFM peak in CPU usage, and maintain such high usage levels despite the work-flow ending or 15+ minutes passing, it will allow CA to assist in the investigation, if necessary:            
*) JFM STC output after issuing a STATUS command both after startup,  and just before taking a live SVCDUMP, then cancelling with another dump  (please make sure this includes all JES spool DDs! JESJCL, etc...)    
*) All SVCDUMPs and SYSMDUMPs for JFM STC formatted with the earlierer proscribed settings                                                   
    (don't forget to look under the HLQ of the user ID or whatever you    
     specified in the DYNDUMP run-time option)                            
 *) CA7 STC output from the same time period as the JFM STC with issues   
    (for all tracked instances of CA7)                                    
 *) CA7 SASSXTRK for the time period starting just before JFM rose in     
    resource usage, through the time the DUMP was taken in JFM            
    (for all tracked instances of CA7,plus a few hours before and after)   
Additional items that would be helpful diagnosing issues in general 
general (each taken after the DUMPs for the JFM STC, and again, for each  
tracked instance of CA7):                                                 
 *) CA7 SASSBK00 backup file                                           
 *) CA7 ARF IDCAMS REPRO file                                          
 *) CA7 VRM IDCAMS REPRO file                                          
 *) CA7 DMPQUE file                                                    
 *) CA7 VDMP file                                                      


Release: ESPSEV99000-11.3-CA-7-Extended Support Plus