Provide OMEGAMON Exceptions

Configuring and Installing Optional Components › Configuration Tasks for Optional Base Components › Set Up Interfaces to Tivoli OMEGAMON XE › Provide OMEGAMON Exceptions

Provide OMEGAMON Exceptions

Ensuring that the correct output is being written to the OxREPORT file requires some OMEGAMON customization. Customization includes choosing thresholds and options to create and define a profile. Use the OMEGAMON User Profile Facility to customize these parameters.

When using the AOF to automate OMEGAMON exceptions, note the following:

CA OPS/MVS must be started before OMEGAMON.
An OMEGAMON session must be active to feed the exception event process. If you have a dedicated mode terminal next to the console that is always left on the exception analysis screen, use that terminal to provide the exception data. If that terminal often displays other screens, then you risk missing important exceptions when the operators use it for other functions. CA OPS/MVS can monitor exceptions only while the exception analysis screen is active.
The simplest way to configure the interface is to have a dedicated session with exception analysis always active. However, this solution has two drawbacks, the first of which is mentioned in the previous paragraph. The second drawback is that it requires a locally attached 3270 device.

An alternative solution is to use the OMEGAMON VTAM interface with an EPI logical terminal. This solution is more complicated to configure, but it eliminates both of the problems associated with a dedicated 3270 terminal. The EPI session is hidden, so no one can walk up and change the screen. No real 3270 terminal is required, since the EPI is used as a virtual 3270.
Check the LROWS parameter of the OMEGAMON started task JCL to ensure that all exceptions fit on the logical screen that is written to the OxREPORT file. The default value for the LROWS parameter is two times the physical screen minus one; the maximum value is 999.
All exceptions must be unboxed, either by setting the BOX parameters to NO for all exceptions or by turning boxes off in the installation or user profile. You cannot alter the default profile. You can set some control options with the .SET command and you can set some exception thresholds using the XACB command, the XSET command, or both. Use these commands on the actual exception analysis screen for testing, but for production usage, place them in the installation or user profile so that they execute at OMEGAMON startup.
Note: OMEGAMON installation procedures and actual commands can vary from one platform to another. The commands referenced above may be specific to OMEGAMON for MVS. Consult the appropriate installation guide for the IMS, CICS, and DB2 releases.
Set the page limit for the OMEGAMON OxREPORT file to a high number. To do so, either specify .PLM 999999999 in a screen space or preferably use the PAGELIMIT option in the user profile.
The OMEGAMON logging facility must be turned on. You need to issue the LOGON command to OMEGAMON to tell it to write screens to the OxREPORT file.
OMEGAMON 7.1.0 and OMEGAMON II Configuration for dedicated terminals:

Create an initial screen space and enter the following commands on separate lines following the rules for creating OMEGAMON screen spaces (commands should start in column 2):
```
OUTP REPORT 
DDNM OPREPORT      (or whatever DDNAME is used in proc) 
.LOGOUT 
.LOGON
.FGO exscrn
```
exscrn

Specifies the name of the screen space containing the exception analysis command.

OMEGAMON II Configuration for OMVTAM:
1. Create an initial screen space and enter the following commands on separate lines following the rules for creating OMEGAMON screen spaces (commands should start in column 2):
```
OUTP REPORT
DDNM OPREPORT       (cannot be OMREPORT)
.LOGOUT
.LOGON
.FGO exscrn
```
2. Logon to OMVTAM:
```
LOGON APPLID(OMVTAM) DATA('FSCR=yyyy')
```
yyyy

Specifies the name of the screen space containing the commands described above. The purpose of the initial screen space (in either dedicated or VTAM mode) is to configure the logging facility when OMEGAMON starts. The .FGO command then transfers control to the exception analysis screen space, which then remains on the screen and drives the exception analysis process on a regular interval (the OMEGAMON session must be in auto-update mode).
Invoke exception analysis through one of these commands: LEXSY (for OM), LXIMS (for OI), or LCXSY (for OC). Place the command in column 1 and be sure to prefix it with an L. The L tells OMEGAMON to label the exception by putting its four-character name on the screen in addition to the message. These exception names are the message IDs that CA OPS/MVS uses to invoke its OMEGAMON rules.

At this point, you should see OMEGAMON messages appearing in OPSLOG, and you can enable rules to execute in response to them. Each exception generates a message each time the screen is refreshed, so you may want to review your exception thresholds and your refresh time to ensure that you do not flood OPSLOG with unimportant messages. Use the CA OPS/MVS BROWSEOMG parameter to keep OMEGAMON messages from appearing in OPSLOG. If you set the BROWSEOMG value to OFF, you can audit the occurrence of OMEGAMON messages that execute OMEGAMON rules by including a SAY statement or an ADDRESS WTO host command that reports the text of the exception message processed in the rules.

If you are licensed to use the OMEGAMON Exception Logging Facility (XLF), then you may want to consider using the XLFLOG DD as an alternative to the OMEGAMON report file. The XLFLOG has the advantage that it does not repeatedly generate exception events to CA OPS/MVS every OMEGAMON cycle. If you choose to use XLF, then you must customize the OMEGAMON exception analysis values for persist and limit.