Here's what we have set up:
ESP appl run under a "service id" that kicks off enbp1000 job contains a "manual job" entry for the endevor submitted intrdr pkg job
IF %ESPEVENT = 'ESPM2D.ADHOC' THEN JUMPTO ADHOC
APPL OENDO703 POST_OLDEST JOB_ANCESTOR_WAIT
JOB OENO703A <<< ENBP1000 job
/*@@ SPECIAL PACKAGE MOVE FOR DSYS IPL
CCCHK RC(12:4095) FAIL
JOB O703ENDA MANUAL <<< INTRDR, C1BM3000,pkgid jobcard
/* MANUAL TRACKING JOB TO VERIFY PROC SUBMITTED SUCCESSFULLY */
Works great for a single pkg, if the single pkg fails ENBP1000 validation checking, the appl is marked failed and the pkg is not submitted.
If the pkg passes muster and then fails during execution the appl is marked complete and the O703ENDA job is marked as failed in ESP. Once corrected, the pkg can be resubmitted manually thru the Endevor panels or restarted via the ESP interface.
We run into problems when submitting multiple pkgs
SUBMIT PACKAGE KTPKG1 .
SUBMIT PACKAGE ROBPKG .
SUBMIT PACKAGE GXQ0190419PREL12 .
This syntax will submit 3 O703ENDA jobs (jobcard defined to ENBP1000).
KTPKG1 is good
GXQ0 pkg is good.
KTPKG1 marks the event and manual job as complete.
During this particular test, the INTRDR jobcard contained NOTIFY=&SYSUID (which would be OENXP service id which isnt a real person)
Assuming the appl kicks off at 2am notify=O703 doesn't do any good either (each "scheduler" will have their own appl/enbp1000/scl members). Having the operator on deck edit the notify in the jobcard defeats the purpose of the automation
So the question is two fold:
For those of you who have a CA-7 or CA-ESP pkg sweep job using ENBP1000:
1) who gets the notifies when a pkg fails
2) if you are, how are you tracking the indvidual intrdr jobs via 7 or ESP?