Using Sequenced Parameters

Many event handlers use sequenced parameters, which are parameters that are numbered sequentially. Any break in the numbering causes the parameters defined after the break to be ignored. For example, the presStates sequenced parameter (presStates1, presStates2 ... presStatesN) is used by many event handlers.

Because the scheduler allows parameters to be conditionally included or excluded, unintended breaks in the numbering of sequenced parameters may occur. Since sequenced parameters that appear after the break in numbering are ignored, the event handler may not produce the expected results. To avoid this problem, use the optional number sign character as a substitute for the sequence number when defining sequenced parameters. The Transaction Server automatically assigns the proper sequence number suffix when the event is loaded.

The following example shows how to specify sequenced parameters using the optional number sign character:

<PARAMETER name="presStates#">LOADED,ISN_ALLOCATED</PARAMETER>
<PARAMETER name="presStates#" include="keyval">LOADED,REPAIRED</PARAMETER>
.
.
<PARAMETER name="presStates#">ENTRY_ALLOCATED</PARAMETER>

When the scheduler XML contains an include tag with keyval as one if its values, the Transaction Server assigns the name presStates1 to the first parameter, presStates2 to the second parameter, and presStates3 to the third. When the scheduler XML does not contain an include tag with keyval as one if its values, the Transaction Server assigns the name presStates1 to the first parameter and presStates2 to the third parameter. The include attribute on the second parameter causes it not to be loaded and no name is assigned.