Using Notification Manager › Creating Your Own Invocation Programs › Runtime Parameters

Runtime Parameters

NMFIND allows the programs it calls to hand it parameter strings to be stored and then passed as part of the parameter list to every subsequent program it calls. These parameters are called runtime parameters. The strings passed to NMFIND must adhere to the standard REXX program parameter format, as follows:

• They must be in the form keyword or keyword(value)
• If the value specified contains parentheses, the entire value string must be enclosed in single or double quotes

There are no further restrictions on the values passed to NMFIND. NMFIND does not do anything with the values. It simply stores and forwards them.

This feature is used, for example, by the NMVOICE program to pass the name of the file that contains the record and forward .vox file. Recall that NMVOICE provides the ability for a person called by Notification Manager to record a message to be heard by all subsequent people that Notification Manager calls during a particular invocation of NMFIND. When a person asks to record a message, NMVOICE generates a unique file name and then stores the message in it. To have subsequent calls to NMVOICE (by NMFIND) find this file, NMFIND provides NMVOICE with a facility that enables it to pass the file name to every subsequent call to NMVOICE. NMFIND does not even know that it is storing the name of a voice file. It simply stores a parameter string that it knows should be passed on to all subsequent calls it makes.

If you plan to use this feature in your own programs, be aware of the following:

• NMFIND passes these values to all subsequent programs it calls. Thus, you should expect to see parameters in your program that you did not explicitly define to Notification Manager.
• The parameter strings are cumulative. For example, if program A passes back APARM(A) and program B passes back BPARM1(B1) and BPARM2, all subsequent programs called by NMFIND see the string APARM(A) BPARM1(B1) BPARM2.
• NMFIND does not allow you to modify strings after you have passed them back. Thus, you cannot change a parameter value once it is passed to NMFIND—you can only override or ignore it. For example, if NMFIND calls program A and it passes back APARM(A1), and then it calls A again and A decides that the value of APARM should be A2, it cannot tell NMFIND to dispose of the APARM(A1) value. It can only tell NMFIND to add another string, APARM(A2), and then code its handling for APARM to only use the last value found.

Your code must use the REXX external data queue (REXX XDQ) facility to pass parameter strings back to NMFIND. The format of the command is:

PUSH "NEWPARMS: string"

where string contains keyword(value) pairs or one or more keyword names. There must be a blank after NEWPARMS:. In the preceding example, program A's code would look something like this:

PUSH "NEWPARMS: APARM(A)"

Program B's code would look something like this:

tval = "B1"
PUSH "NEWPARMS: BPARM1("||tval||") BPARM2"

Again, keep in mind that this facility is used by all methods that NMFIND invokes (even NMVOICE and NMPAGE) and that your code may not be the only method that is invoked by NMFIND. Thus, your code must be able to discard any parameters it finds in the parameter string that it does not understand. Also, you must be careful to choose names that will not conflict with the names chosen by the programmers of other methods. All methods that CA supplies use parameters whose names start with "_NM". Do not use this prefix on any runtime parameters that you pass back to NMFIND. For examples of how to handle this type of parameter, see the NMVOICE program.