search cancel

DMS Backup/archive and nested COND=() clauses

book

Article ID: 242335

calendar_today

Updated On:

Products

Disk Backup and Restore - MVS

Issue/Introduction

Some jobs including a step of DMS Backup/archive, execute AMSSORT step instead of flushing it as it has the COND=ONLY set but the job doesn't have any previous step that abends.

AMSSORT should be flushed but it is executed and ends RC=04.

Here an example:

if the job executed simply references the DMS Proc without any COND=() operand in the step, then all is OK :

....
       89 //STEPDMS1 EXEC DMS
....

AMSSORT STEPDMS1 - STEP WAS NOT RUN BECAUSE OF COND = ONLY
AMSSORT STEPDMS1 - STEP WAS NOT EXECUTED.
....

If the job executed references the DMS Proc with also a COND=() operand in the step:

....

 89 //STEPDMS1 EXEC DMS,COND=(0,LT,FTP1.RASAB5)

then, the AMSSORT step that is present in the DMS Proc is executed with RC=04 even if it reports COND=ONLY in the step and none of the previous steps abended.

Environment

Release :  

Component : Disk Backup and Restore

Resolution

This behavior occurs because also in the DMS Proc , for each step there is another COND=() present, so, in order to have the two nested COND statements honored correctly (the COND=() in the job step and each COND=() in the DMS Proc steps) , it is necessary to correct the COND=() clause at job step level as follows:

//STEPDMS1 EXEC DMS,COND.DMS=(0,LT,FTP1.RASAB5),                            
//        COND.AMSSORT=((0,LT,FTP1.RASAB5),ONLY),                        
//        COND.AMSEXEC=((0,LT,FTP1.RASAB5),ONLY),                        
//        COND.SORT1=((0,LT,FTP1.RASAB5),EVEN),                          
//        COND.PRINT=((0,LT,FTP1.RASAB5),EVEN),

so that the job step COND clause is repeated to reference each of the DMS Proc steps and it is mixed with the referenced Proc step COND=() clause.

Additional Information

More details can be found at the following IBM link:

On an EXEC statement that calls a procedure