Hi Angel,
Some suggestions that would not involve any new interface, which I think is what Dan has in mind.
All of these solutions would require that OPS/REXX know the name of the Element and its Endevor location (ENV/SYSTEM/SUBSYS/STAGE):
- If you know the name of the data set where the Element is housed, OPS/REXX can read the data set just like any other data set.
- If the Element output component is compressed, there is an Endevor utility to read it into plain text.
- If the name data set where the Element is housed is unknown, there is an existing Endevor API that OPS/REXX can use to RETRIEVE the Element.
Just some ideas ... Dan might have other ideas.
Regards,
John
------------------------------
Broadcom, Inc
------------------------------
Original Message:
Sent: 08-18-2019 12:32 PM
From: Angel Vatakis-Boles
Subject: Interfacing with Endevor
Hi Dan,
Yes we are interested in a different way. We keep production JCL that CA7 uses housed within Endevor. Along with the JCL element, we keep documents within Endevor that contain instructions on what to do during a job failure. (restartt job, page out, wait next day, etc). Our automation team wants a way for OPS/MVS to be able to read the Endevor element and/or the output component file that contains this information. This document can then be included as part of the incident that is created. But OPS/MVS wants to do the READ.
We have Endevor 18.0.12 installed, but the webservices are not yet operational (just brought it up on our sysplex for sysprogs only). .
Original Message:
Sent: 08-17-2019 06:42 PM
From: Joseph Walther
Subject: Interfacing with Endevor
Is anyone interfacing OPS/MVS with Endevor ? If so, please describe how you are doing it ?
If not, would anyone be interested in an interface with Endevor, such that...
- When a program Abends, OPS/MVS is able to find the Endevor footprint
- The footprint identifies the Endevor Element and Package and developer userid
- OPS/MVS sends an email to the userid with detailed Endevor information