Exit Processing
This section gives an overview of how ISPW handles different processing requirements through the use of Exits.
How Exit Processing Works
ISPW Exit Processing determines the operations performed against tasks and is key in providing the power whereby users can issue the same operation against any type of object and have the appropriate processing take place.
In the Topaz Workbench - ISPW Eclipse interface, regular Exits are supported. However, Exits that are interactive are not supported except for when performing Checkout and Approval Notification. To enable interactive Exits for Checkout and Approval, you will need custom exits by using an FX task.
When does Exit Processing take place?
Any time that an operation is issued against a Task (for example, “S”, “B”, “G”), ISPW looks for any exits that exist for that operation code. Both the Standard ISPW processing and other special processing are defined in the Exits Table.
Where are Exits defined?
Exits are defined in option EX as part of the Maintenance Functions. See EX – Exits for more information on defining M.EX data.
What types of Exits are there?
There are two types of Exits defined in M.EX:
- Base processing to define the Operation
- Extended processing in addition to that defined for the base operation.
Base Operations
An entry identified with an exit key of ‘$$$$’ is a base operation exit. ISPW looks for the base exit first because it contains information about the type of exit. ISPW then does a lookup for Global exits (those that have an exit key of ‘####’) and, lastly, looks for exits that may pertain specifically to the Technology or Component Type.
Example
The standard exit (identified by “$$$$”) for the Select for Edit routine has a pre-op value of “ISPEXEC SELECT CMD(%WZZPSS# &DEBUG)”. This is executed when a user types ‘S’ against a task.
Extended Processing
Special processing requirements may need special exits that are executed for all Technologies and Component Types or are driven by the contents of the Technology or Component Type fields. The pre-op and post-op routines specify these special routines. The following figure shows an example of a special exit for a QMF Technology type.
Extended Processing
For the (C)heckout of a QMF object, ISPW will see that there is an exit specified for the technology QM and, if there is a pre-op specified, will run this before base checkout processing (subject to the return codes mentioned in the next section). If there is a post-op specified, it will be run after standard ISPW processing.
Controlling Processing From Within User Exits
If a pre-op exit for a Component Type or technology exists, it controls the subsequent processing by passing the return codes listed in the following table.
Controlling Processing
Return Code | Description |
|---|---|
0 | Pre-op worked. Standard processing continues. |
2 | Pre-op worked. Standard processing is omitted. |
Other values | Pre-op failed. Standard processing and possible post-op processing is not executed. |
For certain technologies or operations, being able to replace standard ISPW processing completely by using the proper return code is sometimes useful.
Example
For Telon, the “S” exit takes the user directly into the TDF facility, and so the base exit that takes the user into ISPF Edit is not invoked.
Post-op Exits
If a post-op exit for a Component Type or technology exists, it will be executed only if all the processing to that point has worked. If the post-op encounters a problem, the operation is still processed as successful. This is required because post-ops cannot always back out the changes made by standard processing. Therefore, any critical processing should not be in a post-op.
ISPW Task Data Available Within an Exit
When an exit is called, certain information for the Task in the way of variables is available to be used. Two categories of data are available:
- Read-only variables
- Update variables (only for Update Operations). See EX – Exits.
Calls to ISPW From Within an Exit
It is possible to make calls from within an exit to get further information from the server. The REXX function WZZTSI is used for this, but make sure that only the external calls (starting with “#”) are used, because the other calls may change between ISPW versions. See Reference-Data-Calls for a description of what Reference Data Calls are available and what information is returned in them.
Read-Only Variables
The information listed in the following table is available to the exit.
Read-Only Variables
Read-Only Variable | Description |
|---|---|
WTMNAME | Component Name |
WTAPPLID | ApplicationID |
WTSTRM | Stream Name |
WTCLVL | Current level |
WTMTYPE | Component Type |
WTCSLIB | Source library name for component version |
WTCSLIBT | Source library type for component version (for example, PDS) |
WTCLLIB | Load library name for component version |
WTCLRTN | Retain Flag for Load |
WTCGMTS1 | Library name for GMT1 Seq 1 Association |
WTCS1RTN | Retain Flag for GMT1 Seq 1 Association |
WTCGMTL1 | Library name for GMT1 Seq 2 Association |
WTCL1RTN | Retain Flag for GMT1 Seq 2 Association |
WTCGMTS2 | Library name for GMT2 Seq 1 Association |
WTCGMTL2 | Library name for GMT2 Seq 2 Association |
WTCL2RTN | Retain Flag for GMT2 Seq 2 Association |
WTCGMTS3 | Library name for GMT3 Seq 1 Association |
WTCS3RTN | Retain Flag for GMT3 Seq 1 Association |
WTCGMTL3 | Library name for GMT3 Seq 2 Association |
WTCL3RTN | Retain Flag for GMT3 Seq 2 Association |
WTTENV | Target Environment |
WTNLVL | Next level |
WTPLVL | Previous level |
WTSLVL | Start level |
WT0LVL | Prod level |
WTLVLS | String containing levels in the Path |
WTPSLIB | Source library for previous level |
WTPSLBT | Source library type for previous level |
WTPLLIB | Load library for previous level |
WTPLLBT | Load library type for previous level |
WTNSLIB | Source library for next level |
WTNSLBT | Source library type for next level |
WTNLLIB | Load library for next level |
WTNLLBT | Load library type for next level |
WZVPS01 | Extension variable 1 – ISPW use only |
WZVPS02 | Extension variable 2 – ISPW use only |
WZVPS03 | Extension variable 3 – ISPW use only |
WZVPS04 | Extension variable 4 –ISPW use only |
WZVPS01U | User Extension variable 1 |
WZVPS02U | User Extension variable 2 |
WZVPS03U | User Extension variable 3 |
WZVPS04U | User Extension variable 4 |
Update Variables
The variables listed in the following table can be set in an exit.
Update Variables
Update Variables | Description |
|---|---|
WZVPS01U | User Extension variable 1. This variable acts as a whitelist filter for Deploy Sub Environments for any deploys done on this component. At SET LOCK time, Deploy Sub Environments are determined for each Component based on the value of WZVPS01U. If WZVPS01U is not specified, then no filtering will be done and all Sub Environments will be used as expected. |
WZVPS02U | User Extension variable 2 |
WZVPS03U | User Extension variable 3 |
WZVPS04U | User Extension variable 4 |
WTTENV | Target Environment |
LOADNAME | Load name for component version |
GMT1NAME | Component Name for GMT 1 Seq 1 Association |
GMT2NAME | Component Name for GMT 2 Seq 1 Association |
GMT3NAME | Component Name for GMT 3 Seq 1 Association |
GMT1LNAM | Component Name for GMT 1 Seq 2 Association |
GMT2LNAM | Component Name for GMT 2 Seq 2 Association |
GMT3LNAM | Component Name for GMT 3 Seq 2 Association |
Why create new Exits?
Exits are generally created for two reasons:
- To extend the processing of a base exit for a specific Component Type or Technology
- Creation of a completely new ISPW Operation.
Extend Processing
The steps listed in the following table should be followed when writing an exit to extend the functionality of an existing operation.
Extend Processing
Step | Action |
|---|---|
1 | Write the routine that will be invoked to execute the operation. Review any ISPW standard processing CLIST or REXX (for example, WZZPSB#) to see how best to write an exit, giving special consideration to the beginning of the exit with respect to tracing in debug mode. |
2 | Update the exit table under option M.EX to add an exit for the operation, but with an “Exit Key” value applicable to the type of exit being created. This “Exit Key” value will either be a Component Type or Technology. See EX – Exits for a description of the attributes. |
Creating New Operations
The M.EX maintenance option is used by ISPW to control its own operations and is also the place where new operations can be defined. The codes used for ISPW’s own operations should not be changed.
The steps listed in the following table should be followed when creating new ISPW Operations.
Creating New Operations
Step | Action |
|---|---|
1 | Write the routine that will be invoked to execute the operation. Review any ISPW standard processing CLIST or REXX (for example, WZZPSB#) to see how best to write an exit, giving special consideration to the beginning of the exit with respect to tracing in debug mode. |
2 | Update the exit table under option M.EX to create the new operation value with an exit key of ‘$$$$’ to establish a ‘standard’ exit. All ISPW exits, whether they are supplied as base ISPW processing or user-written, must have a ‘$$$$’ definition because it describes basic behavior of the exit apart from the routine to call. It is best to select an existing operation whose behavior most resembles the requirements of the new option, then overtype the key value to add the new entry. For standard exits, the routine to be invoked will be coded in the Preop Routine field, and the Postop Routine field is left blank. See EX – Exits for a description of the attributes. |
3 | In M.ER, update the variables WVOPALL (for non-update operations) and WVOPSOME (for update operations) to reflect the new operation. |
4 | Update the WZZPS## help panel (WZHPS2#) to add the new operation. Create and tie in a help panel for the operation itself. |