Dispatcher XPI functions

There are six XPI dispatcher functions. These are the DFHDSSRX calls ADD_SUSPEND, SUSPEND, RESUME, DELETE_SUSPEND, and WAIT_MVS, and the DFHDSATX call CHANGE_PRIORITY.

Usage of these dispatcher calls is very limited. Check the details supplied for each exit in Global user exit programs before using any functions.

Notes:
  1. You must issue an ADD_SUSPEND call to create a suspend token before you issue a SUSPEND or RESUME call.
  2. If a suspended task is canceled, the SUSPEND fails with a RESPONSE value of ‘PURGED’ and a REASON value of ‘TASK_CANCELLED’. A corresponding RESUME call returns with a RESPONSE value of ‘EXCEPTION’ and a REASON value of ‘TASK_CANCELLED’.
  3. If a suspended task is timed out, the SUSPEND fails with a RESPONSE value of ‘PURGED’ and a REASON value of ‘TIMED_OUT’. A corresponding RESUME call returns with a RESPONSE value of ‘EXCEPTION’ and a REASON value of ‘TIMED_OUT’.
  4. Dispatcher protocols require that you issue a RESUME even if the SUSPEND was purged (due to task cancel or time-out). You must issue one and only one RESUME for each SUSPEND call.

Synchronization protocols for SUSPEND and RESUME processing

This section describes the protocols that must be observed by users of XPI SUSPEND and RESUME processing, so that task purging can be handled effectively.

The normal synchronization protocol

In the normal case, synchronization involves two tasks and three operations. In the following sample operations, the tasks are A (the task that requests a service) and B (the task that processes a request from task A).

  1. Task A starts the request by:
  2. Task B performs the action by:
  3. Task A ends the interaction by:

This sequence looks like:

 The picture shows the sequence described in the preceding list. The sequence for Task A is: set parameters; resume Task B; suspend; get results. The sequence for Task B is: get parameters; process request; set results; resume Task A; detach.

Ignoring the Resume and Suspend, the execution amounts to:

 The picture shows the following sequence: set parameters; get parameters; process request; set results; get results.

where these actions are always sequential.

The synchronization protocol and task purge

If one of the tasks is to be purged, it is task A, because task A is the one suspended. In this case, execution of task A after the failed SUSPEND would be in parallel with task B; the proper serialization would be lost. If the program were left unchanged, Process request and Set results would be taking place at the same time as Get results, with unpredictable results.

One way of preventing this problem is to ensure that task A, if it is to be purged, does not do anything that could interfere with task B. (This may well mean that A must not detach, if doing so releases storage that B needs to access.) Because the only task that is now involved is task B, B is left with the responsibility of cleaning up for both tasks.

The sequence is:

 The picture shows the sequence described in the preceding text. The sequence for Task A is: set parameters; resume Task B; suspend-fail. The sequence for Task B is: get parameters; process request; resume-fail; clean up both.

Because task-purging is effective only if performed between SUSPEND and RESUME, Suspend-fail precedes Resume-fail. This means that, with the same constraints on serialization as in the normal synchronization protocol, the task-purge protocol can be logically reduced to:

 The picture shows the following sequence: set parameters; get parameters; process request; clean up.

The difference is that Set results and Get results are replaced by Clean up. It is vital that only these two sequences can happen; this means that both programs must be coded correctly. CICS® ensures that both tasks are told either that SUSPEND and RESUME processing worked, or that it failed.

The following shows the programming steps that conform to these rules:

Program for Task A                    Program for Task B
SET PARAMETERS; 
RESUME B;                             GET PARAMETERS;
SUSPEND A;                            PROCESS REQUEST;
                                      RESUME A;
if                                    if
  RESPONSE = OK                         RESPONSE ¬= OK
then                                  then
  GET RESULTS;                          CLEAN UP;
endif                                 endif

If both the SUSPEND and RESUME return ‘OK’, the example follows the rules for the normal synchronization; processing finishes at Get results. If neither SUSPEND nor RESUME returns ‘OK’, the example follows the rules for the task-purge protocol, and processing finishes at Clean up.

For further information about SUSPEND and RESUME processing, see the CICS Problem Determination Guide.

Alternative approach to task purge

The sequence described above is one method for dealing with the problem of task purge. Using this method, task B does not know, when it is processing the request, whether or not task A has been purged; this means that B must take great care in its use of resources owned by A (in case A has been purged). In some situations, this restriction may cause difficulties.

A different approach is as follows; if task A is to be purged:

  1. A communicates to B that it is no longer available, thus informing B not to use any resources owned by A.
  2. A performs its own clean-up processing (including issuing the RESUME call for the purged SUSPEND, as required by the dispatcher protocols), and abends.
  3. B performs its own clean-up processing.

The ADD_SUSPEND call

ADD_SUSPEND acquires a suspend token that can later be used to identify a SUSPEND/RESUME pair.

ADD_SUSPEND

DFHDSSRX [CALL,]
      [CLEAR,]
      [IN,
      FUNCTION(ADD_SUSPEND),
      [RESOURCE_NAME(name16 | string | 'string'),]
      [RESOURCE_TYPE(name8 | string | 'string'),]]
      [OUT,
      SUSPEND_TOKEN(name4 | (Rn)),
      RESPONSE(name1 | *),
      REASON(name1 | *)]

Start of changeThis command is threadsafe.End of change

RESOURCE_NAME(name16 | string | "string")
specifies a 16-character string that can be used to document and trace the resource involved in suspend and resume processing. You cannot use register notation to specify the address of the string.
name16
The name of the location where a 16-byte value is stored.
string
A string of characters without intervening blanks; if it is not 16 bytes long, it is extended with blanks or truncated as required.
"string"
A string of characters enclosed in quotation marks. Blanks are permitted in the enclosed string. If you want to document a name (label) in your program, use this form.
Note:
RESOURCE_NAME on ADD_SUSPEND supplies a default value which is used if RESOURCE_NAME is not specified on a SUSPEND call.
RESOURCE_TYPE(name8 | string | "string")
specifies an 8-character string that can be used to document and trace the resource involved in suspend and resume processing. You cannot use register notation to specify the address of the string.
name8
The name of the location where an 8-byte value is stored.
string
A string of characters without intervening blanks; if it is not 8 bytes long, it is extended with blanks or truncated as required.
"string"
A string of characters enclosed in quotation marks. Blanks are permitted in the enclosed string. If you want to document a name (label) in your program, use this form.
Note:
RESOURCE_TYPE on ADD_SUSPEND supplies a default value which is used if RESOURCE_TYPE is not specified on a SUSPEND call.
SUSPEND_TOKEN(name4 | (Rn))
returns a token assigned by the system to identify the SUSPEND/RESUME pair of operations used on the task.
name4
The name of a 4-byte field where the token is stored
(Rn)
A register into which the token value is loaded.

RESPONSE and REASON values for ADD_SUSPEND:

RESPONSE REASON
OK None
EXCEPTION None
DISASTER None
INVALID None
KERNERROR None
PURGED None
Note:
For more detail, refer to the explanation of RESPONSE and REASON in Making an XPI call.

The SUSPEND call

SUSPEND suspends execution of a running task. The task can be resumed in one of two ways. You can issue the XPI RESUME call, or the task is resumed automatically if the INTERVAL value that you specify on the DFHDSSRX macro expires. Suspended tasks can also be purged by the operator, or by an application, or by the deadlock time-out facility.

SUSPEND

DFHDSSRX [CALL,]
      [CLEAR,]
      [IN,
      FUNCTION(SUSPEND),
      PURGEABLE(YES|NO),
      SUSPEND_TOKEN(name4 | (Rn)),
      [INTERVAL(name4 | (Rn)),]
      [RESOURCE_NAME(name16 | string | 'string'),]
      [RESOURCE_TYPE(name8 | string | 'string'),]
      [TIME_UNIT(SECOND|MILLI_SECOND),]
      [WLM_WAIT_TYPE,]]
      [OUT,
      [COMPLETION_CODE(name1 | (Rn)),]
      RESPONSE(name1 | *),
      REASON(name1 | *)]

Start of changeThis command is threadsafe.End of change

COMPLETION_CODE (name1 | (Rn))
returns a user-defined "reason for action" code during suspend and resume processing.
name1
The name of a 1-byte area to receive the code. The value in this field is user-defined, and is ignored by CICS.
(Rn)
A register in which the low-order byte contains the completion code and the other bytes are zero.
INTERVAL(name4 | (Rn))
specifies in seconds or milliseconds the time after which the task is automatically resumed and given a RESPONSE value of ‘PURGED’ and a REASON value of ‘TIMED_OUT’. The time unit used on the INTERVAL option depends on the setting of the TIME_UNIT option. The INTERVAL value overrides any time-out (DTIMOUT) value specified for the transaction.
name4
The name of a 4-byte area, which is interpreted as a binary fullword.
(Rn)
A register containing the interval value, a binary fullword.
PURGEABLE(YES|NO)
specifies whether your code can cope with the request being abnormally terminated as a result of a purge. There are four types of purge, as shown in Table 17. Specifying PURGEABLE(NO) tells the dispatcher:
Table 17. SUSPEND call - RESPONSE(PURGED)
REASON TASK_CANCELLED TIMED_OUT
CONDITION PURGE FORCEPURGE DTIMOUT INTERVAL
PURGEABLE (NO) Canceled Proceeds normally Canceled Proceeds normally
PURGEABLE (YES) Proceeds normally Proceeds normally Proceeds normally Proceeds normally
Note:
A FORCEPURGE always assumes that the user wants the task to be purged, and so overrides the PURGEABLE(NO) option. If the user has set an INTERVAL, then this, too, overrides the PURGEABLE(NO) option.
RESOURCE_NAME(name16 | string | "string")
specifies a 16-character string that can be used to document and trace the resource involved in suspend and resume processing. You cannot use register notation to specify the address of the string.
name16
The name of the location where a 16-byte value is stored.
string
A string of characters without intervening blanks; if it is not 16 bytes long, it is extended with blanks or truncated as required.
"string"
A string of characters enclosed in quotation marks. Blanks are permitted in the enclosed string. If you want to document a name (label) in your program, use this form.
Notes:
  1. CICS does not use the RESOURCE_NAME information but includes it in trace entries, and displays it on appropriate CEMT screens to help you to see what your task is doing. CICS internal requests specify values, and you should use different values to avoid ambiguity. CICS internal request values are documented in the CICS Problem Determination Guide.
  2. If RESOURCE_NAME is not specified, the default value, if any, from ADD_SUSPEND is used.
RESOURCE_TYPE(name8 | string | "string")
specifies an 8-character string that can be used to document and trace the resource involved in suspend and resume processing. You cannot use register notation to specify the address of the string.
name8
The name of the location where an 8-byte value is stored.
string
A string of characters without intervening blanks; if it is not 8 bytes long, it is extended with blanks or truncated as required.
"string"
A string of characters enclosed in quotation marks. Blanks are permitted in the enclosed string. If you want to document a name (label) in your program, use this form.
Notes:
  1. CICS does not use the RESOURCE_TYPE information but includes it in trace entries, and displays it on appropriate CEMT screens to help you to see what your task is doing. CICS internal requests specify values, and you should use different values to avoid ambiguity. CICS internal request values are documented in the CICS Problem Determination Guide.
  2. If RESOURCE_TYPE is not specified, the default value, if any, from ADD_SUSPEND is used.
SUSPEND_TOKEN(name4 | (Rn))
specifies a token assigned by the system to identify the SUSPEND/RESUME pair of operations used on the task.
name4
The name of a location where you have a 4-byte token previously obtained as output from an ADD_SUSPEND call
(Rn)
A register containing the token value.
TIME_UNIT(SECOND | MILLI_SECOND)
specifies the time unit used on the INTERVAL option.
SECOND
The INTERVAL option specifies the number of seconds before timeout.
MILLI_SECOND
The INTERVAL option specifies the number of milliseconds before timeout.
WLM_WAIT_TYPE(name1)
specifies, in a 1-byte location, the reason for suspending the task. This indicates the nature of the task’s wait state to the MVS™ workload manager.

The equated values for the type of wait are as follows:

CMDRESP
Waiting on a command response.
CONV
Waiting on a conversation.
DISTRIB
Waiting on a distributed request.
IDLE
A CICS task, acting as a work manager, that has no work request that is allowed to service within the monitoring environment. For example, journaling code that suspends itself when there are no journaling I/O operations to perform.
IO
Waiting on an I/O operation or indeterminate I/O-related operation (locks, buffer, string, and so on).
LOCK
Waiting on a lock.
MISC
Waiting on an unidentified resource.
Note:
This is the default reason given to the wait if you suspend a task and do not specify the WLM_WAIT_TYPE parameter.
OTHER_PRODUCT
Waiting on another product to complete its function; for example, when the workload has been passed to DB2®.
SESS_LOCALMVS
Waiting on the establishment of a session in the MVS image on which this CICS region is running.
SESS_NETWORK
Waiting on the establishment of a session elsewhere in the network (that is, not on this MVS image).
SESS_SYSPLEX
Waiting on establishment of a session somewhere in the sysplex (that is, not on this MVS image).
TIMER
Waiting on the timeout of a timer (for example, a task that puts itself to sleep).

If you are running CICS in an MVS goal-mode workload management environment (that is, you are using goal-oriented performance management), you are recommended to specify the reason for suspending the task on the WLM_WAIT_TYPE parameter.

RESPONSE and REASON values for SUSPEND:

RESPONSE REASON
OK None
EXCEPTION None
DISASTER None
INVALID None
KERNERROR None
PURGED TASK_CANCELLED
TIMED_OUT

Notes:
  1. For more detail, refer to the explanation of RESPONSE and REASON in Making an XPI call.
  2. ‘TASK_CANCELLED’ means that the task has been canceled by operator action or by an application command.
  3. After a ‘PURGED’ response, the suspend token must not be reused in another SUSPEND until it has been reset by a RESUME corresponding to the purged SUSPEND.
  4. ‘TIMED_OUT’ means that the task has been automatically resumed because the specified INTERVAL (or the time-out value specified at task attach) has expired. The token, however, remains suspended and must be the object of a RESUME before it can be the object of a DELETE_SUSPEND.

The RESUME call

RESUME restarts execution of a task that is suspended or timed out. There must be only one RESUME request for each SUSPEND. However, because this is an asynchronous interface, a SUSPEND can be received either before or after its corresponding RESUME. You must ensure that you keep account of the SUSPEND and RESUME requests issued from your exit program.

RESUME

DFHDSSRX [CALL,]
      [CLEAR,]
      [IN,
      FUNCTION(RESUME),
      SUSPEND_TOKEN(name4 | (Rn)),
      [COMPLETION_CODE(name1 | (Rn)),]]
      [OUT,
      RESPONSE(name1 | *),
      REASON(name1 | *)]

Start of changeThis command is threadsafe.End of change

COMPLETION_CODE(name1 | (Rn))
specifies a user-defined "reason for RESUME" code during suspend and resume processing.
name1
The name of a 1-byte area to receive the code
(Rn)
A register, in which the low-order byte contains the completion code and the other bytes are zero.
SUSPEND_TOKEN(name4 | (Rn))
specifies a token assigned by the system to identify the SUSPEND/RESUME pair of operations used on the task.
name4
The name of a location where you have a 4-byte token previously obtained as output from an ADD_SUSPEND call
(Rn)
A register containing the token value.

RESPONSE and REASON values for RESUME:

RESPONSE REASON
OK None
EXCEPTION TASK_CANCELLED
TIMED_OUT
DISASTER None
INVALID None
KERNERROR None
PURGED None
Notes:
  1. For more detail, refer to the explanation of RESPONSE and REASON in Making an XPI call.
  2. ‘TASK_CANCELLED’ means that the task was canceled by operator action while it was suspended, and that the suspend token is available for use.

The DELETE_SUSPEND call

DELETE_SUSPEND releases a suspend token associated with this task.

DELETE_SUSPEND

DFHDSSRX [CALL,]
      [CLEAR,]
      [IN,
      FUNCTION(DELETE_SUSPEND),
      SUSPEND_TOKEN(name4 | (Rn)),]
      [OUT,
      RESPONSE(name1 | *),
      REASON(name1 | *)]

Start of changeThis command is threadsafe.End of change

SUSPEND_TOKEN(name4 | (Rn) )
specifies a token assigned by the system to identify the SUSPEND/RESUME pair of operations used on the task.
name4
The name of a 4-byte field, where the token obtained by an ADD_SUSPEND call has been stored
(Rn)
A register containing the token value previously obtained.

RESPONSE and REASON values for DELETE_SUSPEND:

RESPONSE REASON
OK None
EXCEPTION None
DISASTER None
INVALID None
KERNERROR None
PURGED None
Note:
For more detail, refer to the explanation of RESPONSE and REASON in Making an XPI call.

The WAIT_MVS call

WAIT_MVS requests a wait on an MVS event control block (ECB) or on a list of MVS ECBs. For example, you could issue the WAIT_MVS to wait for completion of an MVS task for which you have issued ATTACH and provided a task-completion ECB.

The dispatcher does not clear the ECBs when a WAIT_MVS request is received. If any ECB is already posted, control is returned immediately to the exit program with a response of ‘OK’.

A single ECB must not be the subject of more than one wait at a time. If any ECB is already being waited on when a WAIT_MVS request is received, the request is rejected. The RESPONSE code is ‘DSSR_INVALID’, and the REASON code ‘DSSR_ALREADY_WAITING’.

Note:
ECBs used in WAIT_MVS requests must never be "hand posted". They must be posted using the MVS POST macro.
WAIT_MVS

DFHDSSRX [CALL,]
      [CLEAR,]
      [IN,
      FUNCTION(WAIT_MVS),
      {ECB_ADDRESS(name4 | (Ra)) | ECB_LIST_ADDRESS(name4 | (Ra)),}
      PURGEABLE(YES|NO),
      [INTERVAL(name4 | (Rn)),]
      [RESOURCE_NAME(name16 | string | 'string'),]
      [RESOURCE_TYPE(name8 | string | 'string'),]]
      [TIME_UNIT(SECOND|MILLI_SECOND),]
      [WLM_WAIT_TYPE,]
      [OUT,
      RESPONSE(name1 | *),
      REASON(name1 | *)]

Start of changeThis command is threadsafe.End of change

ECB_ADDRESS(name4 | (Ra))
specifies the address of the ECB to be waited on.
name4
The name of a location that contains an ECB address.
(Ra)
A register that contains the address of an ECB.
ECB_LIST_ADDRESS(name4 | (Ra))
specifies the address of a list of ECB addresses to be waited on.
name4
The name of a location that contains an ECB address, possibly followed by more ECB addresses. The last address word in the list has the high-order bit set to 1.
(Ra)
A register pointing to an address list as described above.
INTERVAL(name4 | (Rn))
specifies in seconds or milliseconds the time after which the task is automatically resumed and given a RESPONSE value of ‘PURGED’ and a REASON value of ‘TIMED_OUT’. The time unit used on the INTERVAL option depends on the setting of the TIME_UNIT option.

The INTERVAL value overrides any time-out (DTIMOUT) value specified for the transaction.

name4
The name of a 4-byte area, which is interpreted as a binary fullword
(Rn)
A register containing the interval value, a binary fullword.
PURGEABLE(YES|NO)
specifies whether your code can cope with the request being abnormally terminated as a result of a purge. There are four types of purge, as shown in Table 18. Specifying PURGEABLE(NO) tells the dispatcher:
Table 18. WAIT_MVS call - RESPONSE(PURGED)
REASON TASK_CANCELLED TIMED_OUT
CONDITION PURGE FORCEPURGE DTIMOUT INTERVAL
PURGEABLE (NO) Canceled Proceeds normally Canceled Proceeds normally
PURGEABLE (YES) Proceeds normally Proceeds normally Proceeds normally Proceeds normally
Note:
A FORCEPURGE always assumes that the user wants the task to be purged, and so overrides the PURGEABLE(NO) option. If the user has set an INTERVAL, then this, too, overrides the PURGEABLE(NO) option.
RESOURCE_NAME(name16 | string | "string")
specifies a 16-character string that can be used to document and trace the resource involved in suspend and resume processing. You cannot use register notation to specify the address of the string.
name16
The name of the location where a 16-byte value is stored.
string
A string of characters without intervening blanks; if it is not 16 bytes long, it is extended with blanks or truncated as required.
"string"
A string of characters enclosed in quotation marks. Blanks are permitted in the enclosed string. If you want to document a name (label) in your program, use this form.
Note:
CICS does not use the RESOURCE_NAME information but includes it in trace entries, and displays it on appropriate CEMT screens to help you to see what your task is doing. CICS internal requests specify values, and you should use different values to avoid ambiguity. CICS internal request values are documented in the CICS Problem Determination Guide.
RESOURCE_TYPE(name8 | string | "string")
specifies an 8-character string that can be used to document and trace the resource involved in suspend and resume processing. You cannot use register notation to specify the address of the string.
name
The name of the location where an 8-byte value is stored.
string
A string of characters without intervening blanks; if it is not 8 bytes long, it will be extended with blanks or truncated as required.
"string"
A string of characters enclosed in quotation marks. Blanks are permitted in the enclosed string. If you want to document a name (label) in your program, use this form.
Note:
CICS does not use the RESOURCE_TYPE information but includes it in trace entries, and displays it on appropriate CEMT screens to help you to see what your task is doing. CICS internal requests specify values, and you should use different values to avoid ambiguity. CICS internal request values are documented in the CICS Problem Determination Guide.
TIME_UNIT(SECOND | MILLI_SECOND)
specifies the time unit used on the INTERVAL option.
SECOND
The INTERVAL option specifies the number of seconds before timeout.
MILLI_SECOND
The INTERVAL option specifies the number of milliseconds before timeout.
WLM_WAIT_TYPE(name1)
specifies, in a 1-byte location, the reason for suspending the task. This indicates the nature of the task’s wait state to the MVS workload manager.

The equated values for the type of wait are as follows:

CMDRESP
Waiting on a command response.
CONV
Waiting on a conversation.
DISTRIB
Waiting on a distributed request.
IDLE
A CICS task, acting as a work manager, that has no work request that is allowed to service within the monitoring environment. For example, journaling code that suspends itself when there are no journaling I/O operations to perform.
IO
Waiting on an I/O operation or indeterminate I/O-related operation (locks, buffer, string, and so on).
LOCK
Waiting on a lock.
MISC
Waiting on an unidentified resource.
Note:
This is the default reason given to the wait if you suspend a task and do not specify the WLM_WAIT_TYPE parameter.
OTHER_PRODUCT
Waiting on another product to complete its function; for example, when the workload has been passed to DB2.
SESS_LOCALMVS
Waiting on the establishment of a session in the MVS image on which this CICS region is running.
SESS_NETWORK
Waiting on the establishment of a session elsewhere in the network (that is, not on this MVS image).
SESS_SYSPLEX
Waiting on establishment of a session somewhere in the sysplex (that is, not on this MVS image).
TIMER
Waiting on the timeout of a timer (for example, a task that puts itself to sleep).

If you are running CICS in an MVS goal-mode workload management environment (that is, you are using goal-oriented performance management), you are recommended to specify the reason for suspending the task on the WLM_WAIT_TYPE parameter.

RESPONSE and REASON values for WAIT_MVS:

RESPONSE REASON
OK None
EXCEPTION None
DISASTER None
INVALID None
KERNERROR None
PURGED TASK_CANCELLED
TIMED_OUT
Notes:
  1. For more detail, refer to the explanation of RESPONSE and REASON in Making an XPI call.
  2. ‘TIMED_OUT’ is returned if the INTERVAL expires, or if a deadlock time-out interval expires.
  3. ‘TASK_CANCELLED’ means that the task has been canceled by operator action or by an application command.

The CHANGE_PRIORITY call

CHANGE_PRIORITY allows the issuing task to change its own priority. It cannot be used to change the priority of another task. This command causes the issuing task to release control, and so provide other tasks with the opportunity to run.

CHANGE_PRIORITY

DFHDSATX [CALL,]
      [CLEAR,]
      [IN,
      FUNCTION(CHANGE_PRIORITY),
      PRIORITY(name1 | (Rn) | decimalint | literalconst),]
      [OUT,
      [OLD_PRIORITY(name1 | (Rn)),]
      RESPONSE(name1 | *),
      REASON(name1 | *)]

Start of changeThis command is threadsafe.End of change

OLD_PRIORITY(name1 | (Rn))
returns the previous priority of the issuing task.
name1
The name of a 1-byte field where the task’s previous priority is stored
(Rn)
A register in which the low-order byte receives the previous priority value and the other bytes are set to zero.
PRIORITY(name1 | (Rn) | decimalint | literalconst)
specifies the new priority to be assigned to the issuing task.
name1
The name of a 1-byte field, with a value in the range 0 through 255.
(Rn)
A register with the low-order byte containing the new priority value.
decimalint
A decimal integer not exceeding 255 in value. Neither an expression nor hexadecimal notation is allowed.
literalconst
A number in the form of a literal, for example B'00000000', X'FF', X'FCF4', "0" or an equate symbol with a similar value.

RESPONSE and REASON values for CHANGE_PRIORITY:

RESPONSE REASON
OK None
DISASTER None
INVALID None
KERNERROR None
Note:
For more detail, refer to the explanation of RESPONSE and REASON in Making an XPI call.

Related concepts
Overview of the XPI
Global user exit XPI examples, showing the use of storage
Related tasks
Making an XPI call
Writing global user exit programs
Writing a task-related user exit program
Related reference
The XPI functions
[[ Contents Previous Page | Next Page Index ]]