How to Begin Using the Product › Overview

Overview

This chapter provides a step-by-step approach to learning system automation techniques using CA OPS/MVS. You begin with the Automated Operations Facility (AOF) to create a rule that suppresses one type of z/OS system message. AOF lets you modify, test, enable, and disable the rule. In later lessons, you use other CA OPS/MVS facilities to establish more rules in different ways.

OPSVIEW is the main user interface to CA OPS/MVS. Through the OPSVIEW network of panels and user menus, you can communicate with and can use CA OPS/MVS.

The following OPSVIEW Primary Options Menu provides the starting point from which you enter all CA OPS/MVS facilities and functions:

CA OPS/MVS ------ CAxx ---  OPSVIEW Primary Options Menu  ----- Subsystem OPSA

 0  Parms      Set OPSVIEW and ISPF default values           User ID  - USER01
 1  OPSLOG     Browse OPSLOG                                 Time     - 12:43
 2  Editors    AOF Rules, REXX programs, SQL Tables          Release  - 12.2
 3  Sys Cntl   Display/Modify System Resources               SP       - 0
 4  Control    Control CA OPS/MVS
 5  Support    Support and Bulletin Board information
 6  Command    Enter JES2/MVS/IMS/VM commands directly
 7  Utilities  Run CA OPS/MVS Utilities
 A  AutoMate   CA AutoMate rules edit and control
 I  ISPF       Use ISPF/PDF services
 S  SYSVIEW    CA SYSVIEW
 T  Tutorial   Display information about OPSVIEW
 U  User       User-defined applications
 X  Exit       Exit OPSVIEW

 CA OPS/MVS Event Management and Automation
 Copyright © 2014 CA.  All rights reserved.

Review the lessons completely to help you gain a fundamental knowledge about how an automation rule works. The first lesson shows you how to suppress system messages that you do not want to see automatically. We start with this topic for the following reasons:

• Most system automaters start automating a system by suppressing unwanted messages.
• Rules that govern how message suppression operates can be fairly simple.
• After you establish a few message suppression, we can illustrate how several CA OPS/MVS facilities function by investigating how those rules affect your system.

For the purposes of the lessons in this chapter, ensure that a normal, fully qualified, partitioned data set without members has been allocated. Such a data set is used in the lessons to act as a repository for automation rules, each member of which is a rule, and for testing rules once they have been established. A good name for this test rule set could be userid.TEST.RULES.

For testing, you always use a test rule set, rather than a production rule set.

• If a Test Rule Set Does Not Exist

  Either proceed to Allocate a Test Data Set to establish your test rules library or ask your systems programmer to do it for you.

• If a Test Rule Set Exists

  Proceed to Purpose of These Lessons in this chapter.

Every computer application issues a message that can fall into two general categories:

• Messages that call for an operator action, such as replying to a WTOR, calling a customer engineer, or restarting a resource.
• Informational messages that do not call for operator action.

Informational messages can overwhelm the operator because these messages can make it difficult for an operator to see and respond to messages from the operator action category.

You can make the task of the operator more manageable by writing rules to suppress particular messages from displaying on the console, appearing in SYSLOG, or both. If you choose to only suppress a message, that message does not completely disappear; it is routed to SYSLOG, where it can be referenced as needed. If you prefer, you can choose to suppress and delete a message; it is not only suppressed from the console but also deleted from SYSLOG. However, even if you choose to suppress and delete a message, OPSLOG still records the message. OPSLOG is the powerful and flexible system log that CA OPS/MVS provides.