ESP Workload Automation

 View Only
  • 1.  (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Broadcom Employee
    Posted Mar 15, 2016 11:22 AM

    PTF RO74243 introduces support for USS File trigger. There are some commonly asked questions.

    - After PTF RO74243 is applied, an system IPL is required.

    - PTF RO80514 should be applied together with RO74243, which may cause some fields of JOBMAP show wrong values.

    - No special settings on ESPPARM, SMF record type 92 subtype 11 and SMF record type 92 subtype 14 are needed; so the IBM SMF on the same lpar should gather the records.

    - It currently works when the USS file is Updated (default, like any close) or renamed.

    - Type 92, subtype 11 records are generated when a USS file is closed after creation or after updating. If a USS file is created, but no bytes have been written, the SMF record is rejected and no trigger occurs.

    - The folder to store the USS files can’t be /tmp/ directory, like /SYS1/tmp,  which is most likely mounted as TFS (D OMVS,F will show it). The temporary file system (TFS) is an in-memory physical file system that supports in-storage mountable file systems and is not written to DASD. So in the SMF record field SMF92CBW, it shows no bytes being written.

    - The command being issued to create/update/rename the files, needs to specify the same path and file name with same cases as on the DSTRIG/DSNAME. Like:

    ls –l >> /SYS1/usr/test

    DSTRIG USSDSTR

    DSNAME '/SYS1/usr/test' USS

    RUN DAILY

    ENDJOB

     

    Please refer to more detail on the doc " USS File Trigger Enhancement" on support online.



  • 2.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Posted Mar 16, 2016 02:34 PM

    Hi Lucy, question: on our chicago sysplex we have four lpars, AAAA, BBBB, CCCC, and DDDD.  Each lpar has its own separate uss/hfs file system (though the folders and file names will have many of the same names across all 4 lpars, they are totally separate entities).

    If our master ESP runs on lpar AAAA,  would we be able to incite a uss/hfs file trigger on AAAA's file system only  ??

    thanks,



  • 3.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Broadcom Employee
    Posted Mar 17, 2016 03:54 PM

    Hi Michael,

     

    Good question.

     

    I think one way to do it is, to turn on SMF record type 92 subtype 11 and SMF record type 92 subtype 14 ONLY on lpar AAAA. Then the USS activity on other lpars won't be gathered.

     

    Hope this helps,

     

    Lucy



  • 4.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Posted Mar 17, 2016 04:09 PM
      |   view attached

    Hi Lucy,  I don’t think we’d ever wish to turn smf off for any record type on any lpar, so I’m going to assume then that one can fire a uss file trigger only on the lpar the esp master is actually running on and no other lpar.

    Thanks & regards



  • 5.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Broadcom Employee
    Posted Mar 17, 2016 04:27 PM

    Hi Michael,

     

    Master with SMFINT ON in ESPPARM and proxies (they normally should have SMFINT ON) will be able to get the SMF data for USS file activities. So on ALL the four lpars, USS file activities can be monitored by ESP and therefore fire the event or complete DSTRIG wob.

     

    Except the folder and filename, can USS file trigger be limited by JOBNAME and/or user ID?

     

    Lucy

     

     



  • 6.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Posted Mar 17, 2016 04:45 PM
      |   view attached

    Our ESP master runs on lpar AAAA (and lpar AAAA has a full uss/hfs file system)

     

    We have a lot of Websphere apps that run on lpar CCCC and websphere uses a lot of uss files .

     

    If we code in a dstrig : DSNAME '/SYS1/usr/test' USS

    I assume ESP would monitor /SYS1/usr/test  only on the AAAA lpar because that’s where the ESP master is running.

     

    But if we actually were required in having a same-named /SYS1/usr/test uss file that resides on the CCCC lpar tripping the trigger, I’d think we’d be out of luck?

     

    Or a different scenario, let’s says we were interested in in uss file DSNAME '/SYS1/usr/test' USS  on the AAAA lpar and ESP Master is also on AAAA so it should be simple to induce a trigger….piece of cake I’d imagine.

     

    But what if someone updates the SYS1/usr/test file that is on lpar DDDD…….wouldn’t that alos induce the trigger to fire when that is not what was wanted?

     

    Maybe our set up I describe above is very one-off from the way most others do it, but I know for a fact that is our convention here, that whenever someone in an app team requests our MVS support to create a new uss/hfs file , let’s say named  /app/lucy    they usually always create that file on ALL 4 of our lpars, so having same-named uss files on different lpars is the norm here, not the exception for us……..so I think we’d only be able to safely use this nice feature if we knew that it did not reside on more than 1 lpar.



  • 7.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Broadcom Employee
    Posted Mar 18, 2016 11:46 AM

    Hi Michael,

    Firstly I understand that MVS support will create same USS folder across the 4 lpars, so that the users are not limited to access from one specific lpar. But I would not think file activities will be identical across the 4 lpars. For example, Websphere apps runs on lpar CCCC, and will update USS files on this lpar; but they shouldn't update files on the other 3 lpars. Right? Maybe other processes to populate the file activities to the other 3 lpars; then if the USERID or JOBNAME is different, you will be able to set up the DSTRIG so that it will only fire with the right USERID or JOBNAME.

     

    Secondly DSTRIG can't identify the lpar where the file activity occurs, maybe a good topic for enhancement request. So the 4 lpars are treated equal from user's point of view, even it's possible that the DSTRIG data from local lpar (AAAA in your case) where master resides may take less time.

     

    Hope following addresses your concerns:

    Q: If we code in a dstrig : DSNAME '/SYS1/usr/test' USS

    I assume ESP would monitor /SYS1/usr/test  only on the AAAA lpar because that’s where the ESP master is running. But if we actually were required in having a same-named /SYS1/usr/test uss file that resides on the CCCC lpar tripping the trigger, I’d think we’d be out of luck?

    A: ESP will monitor /SYS1/usr/test on all 4 lpars. If file activity for same USS file occurs on lpar CCCC, the DSTRIG will trigger too.

     

    Q: Or a different scenario, let’s says we were interested in in uss file DSNAME '/SYS1/usr/test' USS  on the AAAA lpar and ESP Master is also on AAAA so it should be simple to induce a trigger….piece of cake I’d imagine. But what if someone updates the SYS1/usr/test file that is on lpar DDDD…….wouldn’t that alos induce the trigger to fire when that is not what was wanted?

    A: Yes, the DSTRIG can fire if someone updates the SYS1/usr/test file that is on lpar DDDD. If the USERID who update the file on AAAA and CCCC are different, then you can add USERID for AAAA on DSTRIG, then the update on DDDD won't trigger the DSTRIG.

     

    Thanks,

     

    Lucy



  • 8.  Re: (Tech Tip) FAQs for USS file trigger on CA Workload Automation ESP Edition

    Posted Mar 18, 2016 11:51 AM
      |   view attached

    Thank you Lucy