SYSMDUMP Datasets in REORG Concurrent Jobs
search cancel

SYSMDUMP Datasets in REORG Concurrent Jobs

book

Article ID: 48105

calendar_today

Updated On:

Products

IDMS IDMS - Database

Issue/Introduction

When an abend occurs within a CA IDMS environment CA Technical Support will usually ask for a SYSMDUMP of the failing job. This is easily accomplished by inserting a SYSMDUMP DD statement within all job steps as a general practice or in the failing job step for the purpose of a recreation of the abend. However when running the REORG utility this becomes a more complicated process.

 

Environment

Release: All supported releases

Resolution

When an abend occurs within a CA IDMS environment CA Technical Support will usually ask for a SYSMDUMP of the failing job. This is easily accomplished by inserting a SYSMDUMP DD statement within all job steps as a general practice or in the failing job step for the purpose of a recreation of the abend. However when running the REORG utility this becomes a more complicated process.

The REORG utility performs an unload and reload process against a database and is designed to submit multiple concurrent jobs through the internal reader. These jobs will process various 'slices' of the database concurrently resulting in a reduction in the wall clock time required to perform the operation. It is the user's responsibility to supply skeleton JCL for these concurrent jobs through a file specified on the RORGJCL DD statement.

The skeleton JCL must be coded so that there are no dataset conflicts between these concurrently executing jobs that would cause them to single-thread within the operating system. This means that each job submitted must have a unique name assigned to its SYSMDUMP DD statement from those used by all of the other concurrent jobs. Even the use of a GDG dataset for the SYSMDUMP file will cause the jobs to single-thread against the first job submitted.

One way to address this problem is to take the skeleton JCL for the REORG concurrent jobs and define it as a JCL procedure or PROC. This PROC can be placed in-stream in the job's skeleton JCL that is placed into the REOGJCL file. Within the PROC you can use system symbols to replace all or portions of various JCL statements. In this scenario we will be using the following system symbols.

  • &JOBNAME Job name assigned to the current job
  • &LYYMMDD Current date
  • &LHHMMSS Current time

We can use the following statement with the JCL PROC to create a unique dataset name for the SYSMDUMP file for each concurrent job.

 

//SYSMDUMP DD  DSN=SYSM.&JOBNAME..D&LYYMMDD..T&LHHMMSS,   
 //                             DISP=(NEW,CATLG,DELETE),SPACE=(TRK,1235,RLSE), 
 //                             DCB=(RECFM=FB,LRECL=4160,BLKSIZE=4160),        
 //                             STORCLAS=IPCSDUMP

 

Unfortunately system symbols may not be allowed within standard batch jobs at your site so to be able to use these variables to generate unique dataset names we must use IBM utility EZACFSM1. This utility causes system symbols to be replaced within an input JCL stream and the modified JCL can be submitted to the internal reader. This means that the skeleton JCL placed in the RORGJCL file will be JCL for the EZACFSM1 utility with the JCL for the REORG concurrent job being the in-stream input to the utility. The following is an example of the JCL placed in the RORGJCL file for the submission of the concurrent jobs.

 

//WEI$     JOB 111200000,(WEILAND--1112),TIME=1439,                  
 // CLASS=A,MSGCLASS=X,USER=xxxxxxxx                                   
 //EZACFSM1  EXEC  PGM=EZACFSM1                                       
 //SYSOUT   DD  SYSOUT=(*,INTRDR)                                     
 //SYSIN    DD  DATA,DLM=QQ                                           
 //&JOBNAME  JOB 111200000,(WEILAND--1112),  ',                       
 //    MSGCLASS=X,MSGLEVEL=(1,1),                                     
 //    PASSWORD=,TIME=1439,                                           
 //    CLASS=A,USER=xxxxxxxx                                           
 //REORG  PROC                                                        
 //*------------------------------------------------------------------
 //*  REORG AUTOMATIC SUBMISSION JCL                     
 //*------------------------------------------------------------------
 //REOGAUTO EXEC PGM=IDMSBCF,REGION=0M                                
 //STEPLIB DD DISP=SHR,DSN=<yourHLQ>.DBA.LOADLIB          
 //        DD DISP=SHR,DSN=<yourHLQ>.CUSTOM.LOADLIB                
 //        DD DISP=SHR,DSN=<yourHLQ>.IDMS.LOADLIB                    
 //DCMSG   DD DISP=SHR,DSN=<yourHLQ>.SYSMSG.DDLDCMSG                             
 //RORGCTL DD DISP=SHR,DSN=<yourHLQ>.REORG.RORGCTL        
 //SYSJRNL  DD  DUMMY                                         
 //SYSOUT   DD  SYSOUT=*                                      
 //SYSOUD   DD  SYSOUT=*                                      
 //SYSDBOUT DD  SYSOUT=*                                      
 //SORTMSG  DD  SYSOUT=*                                      
 //SYSMDUMP DD  DSN=SYSM.&JOBNAME..D&LYYMMDD..T&LHHMMSS,   
 //             DISP=(NEW,CATLG,DELETE),SPACE=(TRK,1235,RLSE),
 //             DCB=(RECFM=FB,LRECL=4160,BLKSIZE=4160),       
 //             STORCLAS=IPCSDUMP                             
 //SYSLST   DD  SYSOUT=*                                      
 //SYSIDMS  DD  DSN=<yourHLQ>.REORG.SYSIDMS,DISP=SHR       
 //SYSIPT   DD  DSN=<yourHLQ>.REORG.SYSIPT,DISP=SHR        
//       PEND                                                
//   EXEC REORG                                              
QQ                                                           
//

 

It is important to be aware that JCL PROCs do not allow the use of in-stream files such as is typically used for SYSIDMS and SYSIPT. These DD statements should specify sequential datasets that contain the parameters normally specified as in-stream data within the JCL.

When the main REORG job submits the concurrent jobs it will modify the jobname specified on the RORGJCL member's jobcard to insure that each concurrent job has a unique name. This modified name will be passed to all occurrences of the system symbol &JOBNAME in the PROC causing each true REORG concurrent job to have a unique job name and using that value as a qualifier on the SYSMDUMP dataset's name.