The NMFIND program is the external interface for invoking Notification Manager to contact people. You tell it:
Optionally, you can tell Notification Manager to use a date or time that is different from the current one when searching the database to determine which methods to use when contacting the specified persons.
This command has the following format:
NMFIND {GROUP(group) | KEY(key) | NAME(name) | PERSON(person)} TELL(tell-text)
[ASK(question
[,answer1[::action1]
[,answer2[::action2]
[,...answer9[::action9]]]])]
[ACKNOWLEDGE(AP|UNI|APUNI[=host],string)]
[ACKNOWLEDGEAP(string)]
[ACKNOWLEDGEOPS(host,string)]
[ATTACHMENT(filename)]
[DATE(date)]
[DEBUG(YES|NO)]
[ESCALATIONWAIT(esc-wait-time)]
[EMERGENCYINTVL(e-interval)]
[EMERGENCYWAIT(e-wait-time)]
[FAILUREREXX(failure-action)]
[MTUP (A|profile)]
[TIME(time)]
[USERPARMS(parameter1(value1)[ parameter2(value2)]]
Specifies the name of the group to contact.
Specifies the key (numeric ID) of the group or person to contact.
The key is shown on the GUI and is returned by the LISTENTITY VOX command.
Specifies the name of the group or person to contact.
Specifies the name of the person to contact.
Specifies the string or voice file that you want to tell the contacted persons.
(Optional) Specifies the question and answer1, answer2, and so on arguments can each be either a string or a voice file.
The question is played to the person contacted first, and it is followed by each of the answer strings (there may be up to nine). The question cannot be omitted. NMFIND prefixes the words "Push 'n' for" to each answer. If you do not specify any answer strings, answer1 defaults to TRUE and answer2 defaults to FALSE.
The action1, action2, and so on arguments are optional. If they are supplied, each one is the name of the REXX program to be run if the associated answer is selected. These REXX program names must contain the associated file extension (.REX or .CMD). The full path to these REXX files may be omitted if the REXX program resides in either the Distrib directory or the Site\MyFiles\REXX directory.
Each REXX action program must set a return code on exit. The return code value can be either 0 or any number greater than 9.
(Optional) If specified, this parameter forces an acknowledgement message to be written to the CA NSM Event Console (UNI) or the CA Automation Point Message window (AP), or both (APUNI). If a host name is appended to this first parameter value by an equal sign (=), this CA NSM host receives the acknowledgement string. Otherwise, all CA NSM hosts configured by the Event Traffic Controller receive a copy of this acknowledgement message.
Note: The host value is only valid if the UNI or APUNI destination is specified. If an additional string is passed in through this parameter (string), this string is added to the acknowledgment text.
(Optional) If specified, this operand causes an acknowledge message to be written to the AP MSG window. This operand is the same as ACKNOWLEDGE(AP,string).
(Optional) If specified, this operand causes an acknowledge message to be written to the CA‑OPS/MVS host. For the acknowledgement message to be sent, the specified host must be currently configured and active.
(Optional) Specifies the user-supplied file that is to be attached to any notifications made using a method defined to send mail using the SENDMAIL command. The file must be accessible from the Notification Server that is issuing the SENDMAIL command. Only one file can be specified per NMFIND request. The maximum length of the filename (including path) is 512 characters.
Note: To use the ATTACHMENT option, you must configure the Notification Server to use SMTP for mail requests.
(Optional) Specifies the date, in the form mm/dd (no year), you want to use when determining how to get in touch with the specified person or group.
Default: The current date
(Optional) Determines whether debugging messages are to be generated. Values are:
Generate debugging messages.
Do not generate debugging messages.
Default: NO
(Optional) If you specify this operand, NMFIND works in emergency mode, submitting all actions to the operating system to be run asynchronously (as separate processes) from NMFIND. This allows you to have NMFIND attempt to contact several people simultaneously about the problem for which it was invoked. The number you specify is the number of seconds NMFIND should wait in between submitting actions.
Note: Use this operand sparingly because running NMFIND in emergency mode consumes a large amount of operating system resources. Use this operand only when you have a situation that requires the quickest response possible. For details, see the section Special Notes About Emergency Mode Processing in this chapter.
If you do not specify this operand, Notification Manager waits for each action (for example, voice notification) to succeed or fail before attempting the next action. (The actions are performed synchronously.)
(Optional) Specifies the number of hours to wait for an answer before executing the FAILUREREXX program.
Note: This operand is valid only when NMFIND is in emergency mode (see the description of the EMERGENCYINTVL operand).
Default: 1000 hours
(Optional) Tells NMFIND to wait until all notification methods at given level are exhausted before starting notification escalation. This operand specifies the number of seconds (esc-wait-time) that NMFIND is to wait before proceeding with an escalation. This allows you to give contacts additional time to respond. If there is a response during the wait period, the notification is considered successful and escalation will not take place.
Notes:
(Optional) Specifies the name of the REXX program to run when every action in the call tree fails or when the value specified for the EMERGENCYWAIT operand expires.
Note: The name of the REXX program passed in this parameter must include the file extension, if present.
(Optional) Use the Methods to Use Profile (MTUP) operand to specify which methods are attempted for a particular instance of an NMFIND notification request. The method type code for each method is defined in the Notification Manager database under the TYP parameter for the method. Before attempting to notify a contact using a scheduled method, Notification Manager compares the value its method type code with the profile specified on the MTUP operand. If the method type code is not part of the MTUP profile, notification is not attempted, and the next scheduled method is compared against the MTUP profile. If the method type code is part of the MTUP profile, then the notification is attempted using that method.
The values for this operand are:
Any combination of method type codes B through W.
All method types specified for all active schedules. No comparisons are made, and all methods are attempted.
Default: A
Consider the following scenario. Employee Terry Jones is entered into the Notification Manager database, and has two 24 x 7 time blocks defined. One time block uses EMail 1 as a method and the other uses Numeric Pager 1. An NMFIND without MTUP specified is issued for Terry Jones. The value of MTUP defaults to A, and no comparisons are made. By default, both the EMail 1 and Numeric Pager 1 methods are attempted. However, since certain messages are of lesser importance than others, the EMail 1 method notification alone may sometimes suffice. The TYP parameter of the EMail 1 method is E; and TYP parameter of the Numeric Pager 1 method is P. An NMFIND for Terry Jones can be issued with MTUP set to E. The EMail 1 method will be attempted (E is part of E), and Numeric Pager 1 method will not (P is not part of E). These results will occur conversely if you set MTUP to P.
MTUP can contain multiple letters. For example, in the scenario above, MTUP could be set to EP, allowing both methods to be attempted (E is part of EP, P is part of EP). Setting MTUP to EP in this case is the same as using the default setting.
Consider the next scenario. Another time block is added for Terry Jones. This time block is set to use Voice 1 method, and its TYP parameter has the value of V. If a call to Terry desires to use EMail 1 and Numeric Pager 1 methods, but not the Voice 1 method, MTUP could be set to EP to make this occur (E is part of EP, P is part of EP, V is not part of EP.).
To preview which methods will be attempted when MTUP is specified for a particular NMFIND request without issuing a notification, run the Notification Manager utility program, listMTUP.rex. You can find this utility in the subdirectory SAMPLE\NM in your CA Automation Point installation directory.
(Optional) Specifies the time you want to use when determining how to get in touch with the specified person or group. The format is military time format (00:00 to 23:59).
Default: The current time
(Optional) Specifies a list of method parameters whose associated values override any like-named parameters during the execution of NMFIND.REX. For example, assume this operand is defined as follows:
USERPARMS( SubjectText(UAP notification using NM))
The USERPARMS-defined value override the parameter SubjectText for any method using that parameter.
Examples:
Suppose you determined that when a particular JES is having difficulties you need to notify the lead JES systems programmer, Jim Smith. The CA Automation Point rule that trapped the error message from JES contains this clause:
REXX(NMFIND PERSON(JIM SMITH) TELL('JES is down'))
Notification Manager uses its database technology (based on a relational database) to determine the communications method it should use to contact Jim Smith, based on the time and day. Notification Manager proceeds to contact Jim Smith and relay the message according to the following:
Extending the previous example, suppose you have written a REXX program that obtains control whenever JES is down and you have determined that you do not know how to handle the situation. Thus, you want to allow Jim to specify what should be done about JES being down. You can code a call to Notification Manager within your REXX program as follows:
CALL NMFIND.REX "PERSON(JIM SMITH) TELL('JES is down')",
"ASK('What should I do', 'WARM START', 'COLD START')"
Your program receives a return code of 1 from NMFIND if Jim wants it to warm start JES (because WARM START is the first answer) and a return code of 2 if Jim wants it to cold start JES (because COLD START is the second answer).
Alternately, you may want to code REXX programs that handle various situations, and then code your automation so that Notification Manager invokes those programs based on the response it received from the person it calls. For example, you could code the following invocation of Notification Manager in your automation:
REXX(NMFIND PERSON(JIM SMITH) TELL('JES IS DOWN')
ASK('What should I do',
'WARM START'::JESSTART.REX WARM,
'COLD START'::JESSTART.REX COLD,
'IPL THE SYSTEM'::IPLSYS.REX)
Note: The example shown above is split across lines for presentation on the page. However, when you enter this code, it must be on a single line.
If Jim asks for a warm start, Notification Manager runs the JESSTART REXX program with a parameter of WARM. If Jim asks for a cold start, Notification Manager runs the JESSTART REXX program with a parameter of COLD. If Jim asks for a system IPL, Notification Manager runs the IPLSYS REXX program.
Notification Manager also supports group definition and notification. For example, if you define a group called CICS_SYS_PROGS, you could replace the PERSON(JIM SMITH) in the previous examples with GROUP(CICS_SYS_PROGS). Instead of attempting to contact just Jim Smith, Notification Manager systematically attempts to contact each member of the CICS_SYS_PROGS group until someone is successfully contacted. If you want, you can also tell Notification Manager to notify all members of the group by defining the group as a broadcast group.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|