CA Endevor

Expand all | Collapse all

ESP and ENBP1000

Jump to Best Answer
  • 1.  ESP and ENBP1000

    Posted 04-16-2019 01:56 PM

    We are playing with #esp submitting #endevor pkgs and have run into a few snags and am in search of some "real world" feedback.

      

    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
    ADHOC:
    INVOKE 'TTAP.U44.PROD.APPLLIB($DEFAULT)'

    JCLLIB 'UCC7.JCL'
    JOB OENO703A   <<< ENBP1000 job
    /*@@ SPECIAL PACKAGE MOVE FOR DSYS IPL
    CCCHK RC(12:4095) FAIL
    TAG 'MF2_END'
    RUN ANYDAY
    RELEASE ADD(O703ENDA)
    ENDJOB

    JOB O703ENDA MANUAL  <<< INTRDR, C1BM3000,pkgid jobcard
    /* MANUAL TRACKING JOB TO VERIFY PROC SUBMITTED SUCCESSFULLY */
    TAG 'MF2_END'
    RUN ANYDAY
    ENDJOB

     

    ENBP1000 job is NOT pkg sweep, it contains multiple #submit #package pkgid SCL statements, therefore every pkg gets its own job with the same jobname

     

    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

    ROBPKG1 fails

    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?



  • 2.  Re: ESP and ENBP1000
    Best Answer

    Posted 04-17-2019 01:50 PM

    Hi Karen,

     

    I have a understanding of ESP(supported it a long time ago) and Support Endevor.   Anyway this would be a question for the ESP team. I expect that this is a question is about tracking jobs that are generated. As I remember ESP can do this. Notification can also be through Endevor Exit or through ESP. 



  • 3.  Re: ESP and ENBP1000

    Posted 04-17-2019 02:01 PM

    Interesting .. thanks Rich.  Still curious how others are doing it, assuming the Endevor admins “own” the package sweep job.



  • 4.  Re: ESP and ENBP1000

    Posted 04-17-2019 09:03 PM

    Hi Karen,

    We don't have a package sweep process in place (yet), but do have ESP.  The essence of your question appears to be notification for a failed job. We simply have a step at the bottom of each job that executes if RC GE 08 (in preceding step). This step executes a program that simply abends with a U9999, which forces an Incident Record to be cut in our Incident Management tool. Whenever such a ticket is generated, we also get an email notification for the open ticket. Lots of moving parts, but it works (most of the time)....Best, Dana