|
|
|
NMFIND provides you, the user of the NMFIND script, with emergency mode processing for a simple reason. As the coder of NMFIND in your automation, you have no control over the methods that are used to notify the person you need to reach, and many methods can take a long time to complete.
For example, the LongVoice method, which invokes NMVOICE and tells it to try to call the person 20 times at intervals of 5 minutes and let the phone ring 10 times on each try, can take over 100 minutes to complete before returning control to NMFIND. Thus, even if there were other methods to be tried after the LongVoice method, they are not attempted for over 100 minutes. This is unacceptable when you need a response in a short amount of time.
Emergency mode processing circumvents this problem by providing you with a way to specify the amount of time each method can hold up the process of getting notification to someone who can handle the problem for which you invoked NMFIND. Emergency mode processing (using the EMERGENCYWAIT and FAILUREREXX operands) also gives you a way to specify the maximum amount of time you want to wait before attempting some other means (besides NMFIND) of obtaining a solution to a problem.
When you specify EMERGENCYINTVL(n), NMFIND always starts new actions approximately n seconds apart. Even if all prior actions have completed so that none are running, NMFIND waits for the time interval to expire before starting a new action. NMFIND starts actions asynchronously on Windows by issuing the START command. Thus, each action runs as a separate process, using far more system resources than running all the actions synchronously inside a single process. Therefore, use this feature sparingly.
Before starting a new action, NMFIND checks all prior actions to see whether the request has been satisfied. If the contact had the "perform all active methods" flag set to OFF, the success of a single action satisfies the request. If the contact had the "perform all active methods" flag set to ON, all the actions that belong to the contact have to succeed before the request is satisfied. After the request is satisfied, NMFIND does not submit any new actions.
Because NMFIND submits new actions without regard to the completion of prior actions, NMFIND can end up with several actions running simultaneously. Therefore, NMFIND's normal behavior of quitting after the first successful action completes is somewhat modified. After an action completes successfully, new actions are not submitted, but actions that are already running are allowed to complete normally.
If NMFIND is only telling asynchronously (no ASK operand was specified), the first time NMFIND succeeds in telling the message, it considers the NMFIND request to be complete. When NMFIND considers the request complete, it stops starting new actions, but actions that it has already started continue to run and may eventually succeed in telling the message to the person who was supposed to be notified. Thus, more than one person can receive the message. In the synchronous case, only one person receives the message.
If a question is being asked asynchronously, the first answer received from someone is considered to be the answer to the question (even if that person was not the first person that NMFIND attempted to notify). After the question is answered, no new actions are started, but actions that were previously started continue to run. If another action subsequently succeeds in reaching someone, then that person hears the TELL message, the ASK question and answers, and the answer that was chosen, but NMFIND does not allow the person to answer the question.
| Copyright © 2012 CA. All rights reserved. |
|