Documentation for Automate

[Travis Bream]

I am working on a client that uses/used Automate. I got into OPS/MVS after Automate was already decommissioned so I don't have any experience with it and was kind of assuming I would never see it, but here we go. I tried finding documentation on how to use Automate and how to convert off of it but am coming up empty. Either I am just not searching the correct terms or the doc is nowhere to be found. Can anyone point me to some resources?

[Hennie Hermans]

Hi Travis,

OPS/MVS release 13.5 is the latest version that supports CA Automate Compatibility Mode... 
See this document : https://support.broadcom.com/external/content/release-announcements/CA-Automate-Compatibility-Mode-In-CA-OPS-MVS-End-of-Service/3404
If you still have Automate rules, you can still covert them to the new OPS/MVS rules in release 13.5 via the OPSVIEW option A - Automate rule translator.
See the manual : https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/13-5/using/using-opsview/other-opsview-options/access-the-automate-rules-translator-option-a.html

In OPS/MVS release 14.0 we removed this Automate rule translator option.. 

If you need any documentation on Automate, then you will need to check the OPS/MVS 13.5 manuals at this location:
https://techdocs.broadcom.com/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/13-5.html

Best regards
Hennie Hermans

------------------------------
Principal Support Engineer
CA Technologies, A Broadcom Company
------------------------------

[Dave Gorisek]

It looks like in 14.0 all the utilities to continue to allow those sites that chose to translate AutoMate/MVS rules (many moons ago prior to end of life for that product) into OPS rules AND continue to maintain them as they did in ATM (meaning externally write/enable/disable) have been removed. Telling you exactly how to proceed will depend on what ATM to OPS translation this site chose. Perhaps they just converted the AutoMate/MVS rules to OPS rules, auto-enabled those that were in the AutoMate/MVS MEMLIST member thus, no translation utilities are needed. If you are at 14.0 , then that must be the case, because nothing would be enabled. If at 13.5, then you need to first determine what type of translation was done. CABC would need to see your existing ATM* parms set up in OPS. Additionally does your OPSMVS proc have a //RULES DD? If so, then this more than likely means you cannot move to 13.5. There used to be a manual way back when that explained the different translation approaches/recommendations. You should see if CABC can dig it up and forward to you so you can better understand how this environment is currently running. The additional question to CABC (unless it is documented somewhere) is did they remove the command processor alias names (OSCMD,GETVAR,SETVAR,WTO,SQL,etc) that allowed the ATM TSO/REXX pgms to run in servers (this was done by an OPSMODE job against the OPS.LOAD). If this functionality was re moved then you will also need to convert all the old ATM TSO/E REXX pgms..

[Travis Bream]

Thank you both for the information however, I'd like to go a little deeper. The client is running 13.5 so I am "good" there. What I need to know is how Automate is architected. I need to know how to determine what rules they may still be running, exactly how to convert a rule, how to disable an automate rule from executing, how to interpret what a converted rule is doing in terms of why it put certain code into the rule. For example, the rules that I assume were translated have Global Variables in them that seem to really only be there because the converter put them there but they are in an IF statement in the )INIT section of the rule. It doesn't look like they really serve any purpose in the grand scheme of things but then, I don't know what other automation is hiding around the corner that may use these variables for something.

IF OPSVALUE('GLVTEMP0.ATMRULE.ATMRULES.XXXXXXX','E') = 'I' THEN                 
  GLVTEMP0.ATMRULE.ATMRULES.XXXXXXX = GLVTEMP0.ATMRULE.ATMRULES.ILR009E||,      
'$N$IAAAB '                                                                     
ELSE                                                                            
  GLVTEMP0.ATMRULE.ATMRULES.XXXXXXX = '$N$IAAAB '                               
!RTVL = OPSVALUE('GLVTEMP0.ATMLABEL.ILR009E_PAGE','U','ATMRULES.$N$IAAAB')      
!EVERY_next_date = 0            /* EVERY - ensure rule fires when 1st entered */
!EVERY_next_time = 0            /* EVERY - ensure rule fires when 1st entered */​

[Dave Gorisek]

The code that you listed was the code inserted by the translator to allow the environment to continue to control the converted/translated rules in the same manner that was performed in AutoMate/MVS (ADD,DELETE,COMMIT,UNCOMMIT) since the two different products had different control tools and rules created in different methods this code was added to allow the ATM control logic to continue. Under the covers, the translator utilities would obtain this control info (stored in variables) and perform the needed OPS rule control command against the converted rules. (ENABLE/DISABLE/SETAUTO/RESETAUTO). In ATM you could of had ATM.rules.DSN(ILR0009E) as a rule member name, but it could contain many different rules. Meaning in this one ATM rule you could have multiple MSGID rules...MSGID(IRL123) OSCMD(issue some command) WTO(issue some msg), MSGID(IRL345) OSCMD(issue come other cmd), etc. In ATM if you did F ATM,ADD/DELETE/COMMIT/UNCOMMIT RULES=IRL0009E, ATM would of course control all those rules in that member. Additionally, you could create an ATM rule with a label and then control by that rule within the rule member. So adding in ATM.rules.DSN(IRL0009E) - LBLDAVE: MSGID(IRL123) OSCMD(...), would allow you in ATM to control just the LBLDAVE rule in that one rule member. As you know in OPS, there is one rule per rule name. Since this site chose the option to translate rules and make sure the translation added code to control to control with the same ATM 'style', your converted rules have all this extra rule control. There is much under the cover logic added in converted rules to allow them to run in ATM style. You really need to get a hold of the ATM to OPS conversion manual to see what was really offered and what the results where based on the conversion option selected. Ideally CABC should provide this manual as I'm sure you wont be the only with 'questions' and not the only site where someone else did the conversion many moon moons ago, and the current automation personnel is not sure what/why/how...Since you have OPS/MVS background, your best approach here is just to look at the ATM source rule (either in the direct pds that is on //RULES DD in proc), or within the comments that were created in the translated rule and create the corresponding most efficient OPS rule ....Good Luck!

[Travis Bream]

Thanks again for the information. An ATM to OPS conversion manual would indeed be very helpful.

I checked the OPSMAIN PROC and sure enough there is a HLQ.ATM.RULES data set in the RULES DD statement. There is also a HLQ.ATMRULES.RULES in the OPS/MVS rulesets which is where I am assuming all of the translated rules ended up. There are 2000+ rules in that data set and most have a generic name generated by a program. The ATM ruleset has 194.

My Next question would be, if all of the rules are translated out of ATM, what is the impact of upgrading to OPS/MVS 14.0? Are all the translated rules going to function in 14.0 or will there need to be another conversion done (gosh I hope not) to account for the ATM-like controls?

[Dave Gorisek]

You will not be able to go to 14.0 'if' the old ATM rule control is in place (MEMLIST to enable rules, OPAMCM* rules in ATMRULES ruleset are enabled which help simulate old ATM rule control, or if any ATM TSO/E pgms running that do F ATM,ADD/DELETE/DISABLE RULES=xxxx in the logic. Again, a review of your ATM parms and view of the OPSLOG would help CABC provide some better guidelines. Look at the ATMRULES ruleset...If there are no AE bits set to Y on the translated rules, then the ATM control compat mode (reading and processing of MEMLIST member) is being used which will of course fail since they removed all the OPAM* REXX pgms from OPS.REXX which were the ATM rule control utilities....

[Marcel van Ek]

The OPS/MVS 4.4 userguide had a remark:
For detailed information about the rules translator, see the manual called
Upgrading to CA-OPS/MVS II From CA-AutoMate/MVS 


I'm sure Broadcom may have some old digital copy of that lying around? I've looked, but I don't have it (anymore) :(

------------------------------
[JobTitle]
[CompanyName]
[Country]
------------------------------

[Dave Gorisek]

Forgot to mention as far as what converted rules are 'running' start with the ATM rules that were COMMITTED (start at IPL as OPS does with SETAUTO)...Look within the ATMRULES OPS ruleset which is where all the translated rules reside. There should be a member called MEMLIST....I believe you should either see the actual ATM rule name or the name of the hashed converted rules that were enabled at IPL time. Meaning for ATM.pds.RULES(DAVE) there may of been 5 rules...the translator would of created a DAVE member in the ATMRULES set, but it was just a pointer to the actual converted rules in that member with a common hashed name. So in ATMRULES you may see DAVE and in it the hashed names..suppose DAVE had 3 ATM rules..so you will see a common serialized hashed name...something like AAA@001, AAA@002, AAA@003....this of course then allowed any control to DAVE (such as DISABLE RULES=DAVE) to obtain all the individual rules of DAVE (AAA*) and AOF DISABLE AAA@*....So again, start with the rules that are enabled at startup. You could also filter on the OPS AOF enablement messages at start up time to see all the hashed rules that are enabled. Again, you are best to attempt to figure out what the ATM rule is doing (ATM rules language was very simple) and just create equivalent OPS rules or rule. Most ATM rules had rules that fired on the save event (MSGID(DAVE1) actions, MSGID(DAVE2) actions, etc)...so you would of course create one )MSG DAVE* rule with the most efficient/effective OPS logic to handle all the actions of DAVE1, DAVE2, etc.....

[Marcel van Ek]

I still have all the original Legent (paper) doc for autoMate/MVS somewhere, just for these cases.
maybe even in digital form, but I'd have to dig deep :)

Marcel van Ek
Atos

[Edit]

Also found some old quickrefs yesterday ;)

[Dave Gorisek]

Not sure how far along you have gotten on this issue/project, but while I was looking in the ops.CCLXSAMP dsn for some sample code, I noticed the sample member ATMRULES. Completely forgot about this sample pgm. It is available in any release (including 14.0) and will simply create a list of currently enabled/translated AutoMate/MVS rules, presenting output of the ATM rule name, the converted OPS rule, fire count and Rule specifier. Take a look if interested. Output of sample pgm is similar to:
ATMrule OPSrule       Type Count Specifier
DG1        DG1@AAAA TOD 0 *+10 MINUTES
SYMON @AJLAAAA CMD 0 SYMON*
SYMON @AJLAAAB CMD 0 SYMON*
SYMON @AJLAAAC MSG 0 SLS0076I*
SYMON @AJLAAAD MSG 22 IEF402I*
SYMON @AJLAAAE MSG 118 IEF450I*
SYMON @AJLAAAF MSG 118 IEF450I*