Using sequenced parameters

Many event handlers use sequenced parameters, which are parameters that are numbered sequentially. Any break in the numbering causes the parameters that are 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 can occur. Since sequenced parameters that appear after the break in numbering are ignored, the event handler might not produce the expected results. To avoid this problem, you can use the number sign character as a substitute for the sequence number when you define 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 by using the 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.