ESP Workload Automation

 View Only
  • 1.  DSTRIG on a event level not working

    Posted Jun 08, 2017 01:18 PM

    Hi All,

     

    Recently we had a need to setup DSTRIG on an event level like we usually do though the dataset is created the event doesn't seem to recognize the dataset creation.

     

    DSTRIG PARAMETER on EVENT:

     

    DSTRIG EI.EA500050.GEN820.TRIGGER

     

    The dataset is being created using the utility UT9996 program and copy contention from the already created dataset to the newly created trigger dataset. 

     

    //EA0040 EXEC PGM=UT9996,COND=(2,EQ,EA0030)
    //*********************************************************************
    //** COPY DATE INTO SI820 TRIGGER FILE TO RELEASE SI JOBS 501 & 511 **
    //*********************************************************************
    //INPUT DD DSN=EI.EA500020.SI820,DISP=SHR
    //OUTPUT DD DSN=EI.EA500040.SI820.TRIGGER,
    // DISP=(NEW,CATLG,DELETE),
    // UNIT=(WORK,2),SPACE=(27920,(10,5),RLSE,,ROUND),
    // DCB=(LRECL=80,BLKSIZE=27920,RECFM=FB)
    //PRINT DD SYSOUT=*
    //SYSUDUMP DD SYSOUT=A



  • 2.  Re: DSTRIG on a event level not working
    Best Answer

    Posted Jun 08, 2017 01:50 PM

    Hi Guna, 

    NOTE: The datasets that you showed for the event and UT9996 program are not the same name. 

    EI.EA500050.GEN820.TRIGGER

    EI.EA500040.SI820.TRIGGER

     

    NOTE2:

    I am not sure what the UT9996 program does but it needs to more than a BR14 to allocate a dataset.  This is because allocating a dataset does not open and close the file. Try it with an IEBGENR.  

     

    Don

     



  • 3.  Re: DSTRIG on a event level not working

    Posted Jun 08, 2017 10:53 PM

    Sorry, I copied a different step here. There is a similar step EA0050 that creates the EI.EA500050.GEN820.TRIGGER file.

    We will update the JCL to create the dataset using the IEBGENER.

     

    Thanks for your help!!

     



  • 4.  Re: DSTRIG on a event level not working

    Posted Jun 14, 2017 08:27 PM

    We have used IEBGENER to create the trigger dataset and still, the event doesn't seem to recognize the dataset. 

     

    //EA0050 EXEC PGM=IEBGENER,COND=(3333,EQ,EA0030)
    //*********************************************************************
    //* COPY DATE INTO GEN820 TRIGGER FILE TO RELEASE GEN JOBS 500 & 510 **
    //*********************************************************************
    //SYSUT1 DD DSN=EI.EA500020.GEN820,DISP=SHR
    //SYSUT2 DD DSN=EI.EA500050.GEN820.TRIGGER,
    // DISP=(NEW,CATLG,DELETE),
    // UNIT=(WORK,2),SPACE=(27920,(10,5),RLSE,,ROUND),
    // DCB=(LRECL=80,BLKSIZE=27920,RECFM=FB)
    //SYSIN DD DUMMY
    //SYSOUT DD SYSOUT=*
    //SYSPRINT DD SYSOUT=*
    //SYSUDUMP DD SYSOUT=A
    //SYSABOUT DD SYSOUT=A
    //*



  • 5.  Re: DSTRIG on a event level not working

    Posted Jun 15, 2017 08:07 AM

    Hi Guna, 

    I think it is best to open a case on this.  We can walk through the steps. 

     

    Maybe some debug ideas...You probably have done these. Thinking out loud here.

    1) Did the step really run?  (look at the job log) 

    2) Did the dataset really get created? ( go to 3.4 )

    3) What does the event look like? 

    4) Look in the log to see if the event triggered. ( It is possible the application has an error in it or something. ) 

    5) Other.....



  • 6.  Re: DSTRIG on a event level not working

    Posted Jun 16, 2017 08:08 AM

    Have you confirmed that the job running on the correct system that the DSTRIG is defined for?



  • 7.  Re: DSTRIG on a event level not working

    Posted Jun 20, 2017 05:48 PM

    Hi Rick/Don,

     

    Thanks for your assistance. 

     

    We figured out that the job creating the trigger files is submitted on SYSTEM1 and routed to an SYSTEM2 for actual execution, both SYSTEM1 and SYSTEM2 shares DASD.And as soon as the job is completed the information is routed back to SYSTEM1 and ESP considers the job as a success.

     

    This made us believe the dataset is being created on SYSTEM1, whereas it is being created on SYSTEM2.

    Hence we made necessary changes to allow the job to execute on SYSTEM1, the issues seems to have resolved.