When should the Alertdef or Job Monitor be used?
The advantage of using a Job Monitor tracking model with a JOB ABEND.
ltm model1
MODEL ? MODEL1 DEFINED AT 99.99 ON WED DDMMYYYY BY USER
P-NODES - EXEC
HISTFILE ? HIST1, INDEX(10), TRACK, NOPRINTDATA
MONITOR - PROD
JOB ABEND - PROD.NOTIFY_ABENDS
Example: If you set up the tracking model above to trigger the event PROD.NOTIFY_ABENDS every time a job abends or completes with a bad condition code. To start monitoring a new job for failures all you have to do is create or alter a tracked job definition for the job to point to the MODEL1 tracking model. ESP does not have to submit or schedule the jobs in order to track the jobs with the tracking model, so you can monitor jobs that are not explicitly scheduled with ESP. You can use wildcards in prefixed tracked job definitions.
The disadvantage of this tracking model approach is that it does not give notifications on overdue jobs. You only get notifications for MVS batch jobs from the tracking model above - you get nothing for distributed jobs, because distributed jobs do not cause any SMF records to be produced and as a consequence cause the JOBABEND or JOBFAIL appendage associated with the tracking model to be invoked.
The advantage of using the alerts is that you can potentially have more granularity than in the scenario above. You can set up different alerts for different classes of jobs or for different types of notifications - you can have one alert for abends and another alert for overdue jobs. Of course you have to put a NOTIFY statement that identifies the alert and the monitor points the NOTIFY statement is watching for in each ESP procedure. The alert/notify process can detect failures of distributed jobs as well as failures of MVS jobs. ESP alerts do not live over restarts of the ESP address space so you have to keep track of the alerts that you have defined and make certain you read them in with the ESP initialization parameters every time you restart the ESP address space.