z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Description

z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN
SA23-1372-00

The CSVDYNEX macro defines exits. It also controls their use and associates exit routines with those exits. You might be familiar with system installation exits that offer an installation an opportunity to modify the system's own processing. CSVDYNEX allows you to offer exits within your own programs. Additionally, the CSVDYNEX macro allows you to associate exit routines with system exits, such as the SMF and allocation exits.

As used here, an exit point is a location in a program's processing where the system transfers control to (or calls) another piece of code, known as an exit routine. An exit routine can give information to the caller that allows the caller to do additional processing. An exit is simply a set of information that includes:
  • Criteria for exit routines that are to get control at the exit point
  • Directions for how the system is to transfer control to an exit routine, process the exit routine, and handle recovery.

There are ten CSVDYNEX requests, issued through the REQUEST parameter on CSVDYNEX; for example, you issue the LIST request by specifying CSVDYNEX REQUEST=LIST with appropriate parameters.

Through the DEFINE request, you define an exit; that is, you give the exit a unique name and specify its characteristics. Through the ADD request, you add or associate an exit routine with an exit. More than one exit routine can be associated with an exit. The location of the exit point (the point at which control passes to the exit routine) is determined by the placement of the CALL request. The CALL request names the exit; the system finds the set of information known as the exit, and finds the exit routine or routines that are associated with the exit. The system then passes control to those exit routines; it processes them, handles any recovery, and returns control to the caller. It performs these actions according to information you provide on the DEFINE, ADD, and CALL requests.

The MODIFY and ATTRIB requests make certain changes to the exit routines and the exits.

The DELETE request deletes or disassociates an exit routine from an exit. The UNDEFINE request removes the exit from the system.

The LIST and QUERY requests return information about exits and exit routines.

The RECOVER request provides recovery for an exit routine that is called with FASTPATH processing in effect.

For ease of use, the standard form of the macro is shown for each CSVDYNEX request. The ten requests are described on the following pages, with the standard form syntax diagrams, descriptions of the parameters, environment, programming requirements, and restrictions:
Following the descriptions of the standard forms of all requests are:

Input register information for CSVDYNEX

With the exception of the CSVDYNEX QUERY request and the CSVDYNEX CALL request with FASTPATH=YES, the caller does not have to place any information into any general purpose register (GPR) or access register (AR) unless using it in register notation for a particular parameter, or using it as a base register.

Before issuing the CSVDYNEX QUERY request or the CSVDYNEX CALL request with FASTPATH=YES, the caller must ensure that the following GPR contains the specified information:
Register
Contents
13
Address of a standard 72-byte save area in the primary address space. You can use this same address for GPR 13 in the register update block (RUB). For more information about the RUB, see the description of the RUB parameter on the CSVDYNEX CALL request.

Output register information for CSVDYNEX

When control returns to the caller, the GPRs contain:
Register
Contents
0
Reason code, if GPR 15 is not zero
1
Used as a work register by the system
2-13
Unchanged
14
Used as a work register by the system
15
Return code
When control returns to the caller, the access registers (ARs) contain:
Register
Contents
0-1
Used as a work register by the system
2-13
Unchanged
14-15
Used as work registers by the system

Some callers depend on register contents remaining the same before and after using a service. If the system changes the contents of registers on which the caller depends, the caller must save them before calling the service, and restore them after the system returns control.

Performance implications

None.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014