We just set up the CA-7 MSMR for the CA-OPS/MVS API interface. I have an API Rule with spec )API CA7MSG and while this does process the events from CA-7 it doesn't seem to give me the granularity we require. Using ENF we were able to see the CA-7 message ID, SCRJ-12 for example. I don't see any way to see this in the API rule. The API.TEXT variable only gives me the last line of the message. Are there any other variables for CA-7? The CA-7 guide doesn't reference any nor does the CA-OPS guides.
Also, the CA-7 API rule I created appears to fire for each line of the message just like a MSG rule would for a multiple line message with the same MSG ID on each line. Is there anyway to control this?
At this moment I do not have answers to all your questions. however, I am working on setting up the CA 7 Edition Master Station Message Routing (MSMR) feature to pass job event information to the CA OPS/MVS Application Programming Interface (API) where rules can fire upon. As this might take some time to complete in our labs let me know if you are ok taking this whole subject in a support ticket. I still can post an update on this discussion once we complete our tests.
Once I have the interface up I will be following our documented instructions on how to debug API rule documented in this URL link:
An excerpt from this URL link reads:
The following are additional API rule debugging techniques:
So let me know what works best for you Travis.
Yes, we can open a ticket for this because I have been testing out things myself and have been noticing some strange reactions when processing API events from CA7MSG. I will open a ticket and attempt to describe what is happening. I have the OPSLOG set up to show API events and they are obviously being recorded otherwise my API rule wouldn't be doing anything. I am going to set up the DEBUGAPI parameter next.
Sounds like a plan Travis
Also wanted to confirm that both the CA 7 Edition 12.0 and CA OPS/MVS r12.2 products online guides does not describe the API variables available for this particular interface. Once we have the ticket under control I will investigate if this is something we should document in our CA OPS/MVS guides or if the other products, in this case CA 7 Edition, should document them.
It is CA-7 R11.3 Documentation and yes it is not in either documentation.
After working through the open ticket I was able to determine a few things. First, there is only one important API variable for the CA7MSG event. This variable is API.TEXT and it does indeed contain the entire message from CA-7. Part of my issue was that I was using a WTO with TEXTVAR to display what was in the message and it ended up being too long for TEXTVAR resulting in a RC=120 and no display of any of the first line of the message. This lead me to believe that I was missing something. Second, the example of the SMF0-19 rule in the manual does work properly but a few things should be noted. The events that come from CA-7 generate an API event in CA-OPS for every line of a message but the API rule will pick up the entire message with the first event. What this results in is an API rule that fires multiple times for each event (if it is more than one line). When I had first coded my test rule (not using the SMF0-19 example), I saw displays of the message text from my WTO for every line of the message. When I went back and looked at the SMF0-19 example I realized that the SELECT statement in the rule was controlling how many times the rule actually did something. The rule still fired for every line of the message but because of the SELECT, it only did something if the message included the message id, SMF0-19 and because the entire message is included in the API.TEXT variable in the first API event including the message ID all you need to do is parse out the message ID and check if it is something you wish to process. If it is, you send it off to whatever is going to process it and if not you just exit out of the rule. Any subsequent line beyond the first will not have the message ID included and thus will never be processed. It is similar to how )MSG rules process multiline messages and the hoops you have to jump through to get the entire message. Message rules however have some extra information that makes their processing a bit easier to control. The API events do not include this information and I will be posting an IDEA topic for the API events to include similar information.
Simple Example of API Rule. This is what I am going to set up to process CA-7 events. The msg_txt variable could be parsed before passing it to the REXX if needed and may be recommended if the event text is lengthy. This actually should make dealing with automation for something like an ABEND much easier to deal with.
PARSE VAR API.TEXT msg_id msg_txt
WHEN msg_id = "insert id to process here" THEN DO
PARSE VAR msg_txt var1 var2 var3
parm2pass = var1 var3
ADDRESS OSF "OI P(insert REXX here) A("parm2pass")"
As promised we were able to setup one of our labs systems to use both the CA 7 Edition Master Station Message Routing (MSMR) feature and the ENF interface. During the tests we used CCS r14.1 CA 7 r11.3 and CA OPS/MVS r12.2. We were able to receive from CA 7 and ENF job event related information in CA OPS/MVS via API and MSG events. Also as stated in the ticket we can confirm that the MSMR interface pass the whole event into a single API event and the ENF interface creates two MSG type events for the SMF0-19 events.
Both API and MSG rules can fire upon these events so logic on these rules needs to be added to consider this behavior.
These are the direct URL links to CA 7 Edition r11.3 and r12 for the sample API rule this product provides:
As you stated in your last entry the single environment variable API.TEXT created/used by the MSMR is the only one created so it might not be practical to document it other than its use in the sample API rule provided above.
Travis, thanks for reporting this subject in our Communities.