Modifying user arguments
User exit programs can modify user arguments as follows:
v For input arguments, your exit program should obtain sufficient storage to hold
the modified argument, set up the required value, and set the associated pointer
in the parameter list to the address of the newly acquired area.
v For output and input/output arguments, your exit program can update the
argument in place, because the area of storage is represented in the application
by a variable that is expected to receive a value from CICS.
Adding user arguments: Your exit program can add user arguments, provided
that it is allowed to modify the corresponding existence bit in the EID. Assuming
that the argument to be added does not already exist, your exit program must:
1. Obtain storage for the argument to be added
2. Initialize the storage to the required value
3. Select and set up the appropriate pointer from the parameter list
4. Select and set up the appropriate existence bit in Arg0
5. If necessary, modify the parameter list to reflect the new end-of-list indicator.
Removing user arguments: Your exit program can remove user arguments,
provided that it is allowed to modify the corresponding existence bit in the EID.
Assuming that the argument to be removed exists, your exit program must:
1. Switch the corresponding argument existence bit in Arg0 to zero
2. Modify the parameter list to reflect the new end-of-list indicator.
File control file state program exits XFCSREQ and XFCSREQC
Two user exits are provided in the file control state program. You can use
XFCSREQ, which is invoked before a file ENABLE, DISABLE, OPEN, CLOSE, or
CANCEL CLOSE request is acted on, to gather information about the state of the
file—for example, which file requests (SERVREQs) are valid, which journaling
options are set. Based on this information, you can suppress the request, if
appropriate. (See return code UERCBYP.)
You can use XFCSREQC, which is invoked after the file request has been acted
on, to gather information about the data set associated with the file—for example,
which recovery options are set. Note that XFCSREQC is invoked even if you have
used XFCSREQ to suppress the file request.
For ENABLE, DISABLE, OPEN, and CANCEL CLOSE requests, each exit is
invoked only once. However, for CLOSE requests, because a file can be quiesced
before actual closure, the exits might be invoked more than once, as described
below.
For a single CLOSE request, XFCSREQ and XFCSREQC are invoked more than
once if closure is attempted while the file is being accessed by other tasks. For
example, the result of a CLOSE NOWAIT command in these circumstances is that
XFCSREQ is invoked before the closure is attempted. Because there are still users
of the file, the closure is delayed. However, because it specified NOWAIT, the
CLOSE request completes, and invokes XFCSREQC with UEPFSRSP set to
‘UEFSPEND’, meaning closure is pending. When all activity against the file is
complete, the file is closed, and XFCSREQ and XFCSREQC are invoked under the
task that actually closed it.
Chapter 1. Global user exit programs 111