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 contact the person you need to reach, and many methods can take a long time to complete.
For instance, the LongVoice method, which invokes NMVOICE and tells it to try to call the person 20 times at intervals of five 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 complete 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 entity had the perform all active methods flag set to OFF, the success of a single action satisfies the request. If the entity had the perform all active methods flag set to ON, all the actions that belong to the entity have to succeed before the request is satisfied. Once 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, the NMFIND 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. Once 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 that they were supposed to contact. Thus, more than one person can receive the message. (In the synchronous case, only one person receives the message.)
If you are asking a question 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 contact). Once the question is answered, NMFIND does not start any new actions, but permits existing actions to 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 © 2014 CA Technologies.
All rights reserved.
|
|