We're using Control-M for job scheduling. We recently had to add some steps to (the end of) an existing job.
Before that, Control-M should restart the job on the *first* job step in any case, so the schedule definition looked like this: ! ON PGMST ANYSTEP PROCST CODES EXERR A/O * ! ! DO IFRERUN FROM $FIRST . TO . CONFIRM Y ! ! DO ! ! ON PGMST ANYSTEP PROCST CODES ***** A/O * ! ! DO SYSOUT OPT C PRM E FRM R ! ! DO SYSOUT OPT R PRM FRM ! ! DO ! Now, for the additional steps, a restart is to be done on specific steps depending on the step that had troubles. The changed scheduling definition looks like this: ! ON PGMST ANYSTEP PROCST CODES EXERR A/O * ! ! DO IFRERUN FROM $FIRST . TO . CONFIRM Y ! ! DO ! ! ON PGMST PVSLOG## PROCST CODES >C0000 U**** S*** JFAIL A/O * ! ! CODES ! ! DO IFRERUN FROM SORTLOG1 . TO . CONFIRM Y ! ! DO ! ! ON PGMST PVSLOG#2 PROCST CODES >C0000 U**** S*** JFAIL A/O ! ! CODES ! ! DO IFRERUN FROM PVSLOG#2 . TO . CONFIRM Y ! ! DO ! ! ON PGMST ANYSTEP PROCST CODES ***** A/O * ! ! DO SYSOUT OPT C PRM E FRM R ! ! DO SYSOUT OPT R PRM FRM ! ! DO ! We expected Control-M to propose "SORTLOG1" and "PVSLOG#2", resp., as the steps to restart on in the restart confirmation dialogue. We were astonished to see that "$FIRST" was proposed instead. The manual is not too specific about this. We understand that the "ON PGMST" are worked sequentially, i.e. top down. Therfore, we expected the step-specific IFRERUN to override the ANYSTEP IFRERUN, but it seems the latter is stronger than the former. Does anyone have more insight in how ANYSTEP, $EXERR, $FIRST and step-specific instructions related to each other? -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
