Non-Subsystem Operations

Operations of this type, containing requests named UXxxxxxx, allow you to perform commands that are independent of a specific subsystem.

Figure 1 shows the flow for these types of operations.
Figure 1. User Exit UXxxxxxx Flow
User Exit UXxxxxxx Flow

TWS Automation uses this type of exit for several purposes. At any point in the production cycle, TWS Automation allows you to invoke a user CLIST or procedure that can interact with system resources, such as the storage management subsystem.

Let’s consider an example. Suppose, in a specific application flow within TWS, return codes show action that is taken by operations. When a specific job in this application completes, one of several user completion codes can result.

  • A completion code of 0 indicates that application processing is to continue to the next operation.
  • A user completion code of 50 indicates that the next two operations are skipped.
  • A user completion code of 70 indicates that the application is completed at this operation.
Any other completion codes are treated as errors. Figure 2 shows the subject operations in this application, and the desired flow of control on the basis of the completion codes of the job that runs as part of the CPU_20 operation.
Figure 2. Completion Code Driven Application Flow
Completion Code Driven Application Flow

In the preceding example, TWS handles all completion code situations, except 50 and 70, which it intercepts. TWS accomplishes this interception in several fashions, such as user code in a JJC error exit. This code could then drive TWS Automation with a user exit (UXxxxxxx) request. This request would be passed to the specified NetView to drive a user-written script. In the user script the INGTWS REQ=MOD could then be used to modify the current plan for the application in question on the basis of the completion code received as part of the user exit request.