Suggested Services for a Work Manager Calling a Data Manager

If you have a work manager that calls a data manager, and you are on the same MVS™ image, you could use the combination of services suggested in this section. If you would like to do the following:

• Associate work coming into the subsystem with a service class
• Goals vs. actual information for reporting
• Response time information for work requests
• Execution delay information about work
• Track work from a work manager to a data manager

consider using the services shown in Figure 4.

Figure 4. Services for a work manager that uses a database manager.

Because the transaction manager is using the work manager services, it must issue the IWM4CON at address space initialization. In this example, the transaction manager is using monitoring environments, so it issues an IWM4MCRE at address space initialization time to create the monitoring environment. Similarly, the database manager is also using monitoring environments, so it issues IWM4MCRE at its address space initialization.

Assuming that the database manager uses a dedicated dispatchable unit, it should also create one monitoring environment per task or SRB that it uses. The transaction manager and the database manager could be running in different, or the same tasks. The tasks in the figure (one in the work manager, and one in the database manager) could be the same one.

However, the database manager, instead of using IWM4MINI, issues IWM4MRLT (relate monitoring environment) when it is called by the transaction manager task. The relate monitoring environment service associates the database manager's monitoring environment for the work request to the transaction manager's monitoring environment for the same work request. Because the relate service requires the token and key identifying the transaction manager's monitoring environment, the transaction manager should pass the token and key to the database manager. In this example, the transaction manager monitoring environment is called the parent environment, and the database manager that issues the relate service is called the dependent environment.

After the database manager has related to the work manager, it can be called to process a specific data base request. Each such call should begin with a transfer (IWM4MXFR) service with a FUNCTION=CONTINUE parameter, and end with a transfer (IWM4MXFR) with a FUNCTION=RETURN parameter.

When the work manager issues a call to the database manager, the database manager issues a IWMMXFER. The work manager state can be either active, or waiting throughout the transfer. The IWM4MXFR FUNCTION=CONTINUE indicates that the real state for the work request now resides in the data manager monitoring environment. From that point on, the database manager should use change state (IWM4MCHS) as its view of the work request changes. You should issue IWM4MRLT and IWM4MXFR in pairs for each data base call or return.

The transfer with the FUNCTION=RETURN parameter resets the dependent monitoring environment state to free. At this point, workload management recognizes that the dependent monitoring environment no longer represents the work request. The parent and dependent monitoring environments are still related, for any future transfers, such as with a second call to the database manager. When the database manager is done with any work requests that require related monitoring environments between the parent and the dependent, it should issue the IWM4MRLT with the FUNCTION=DELETE parameter. This disassociates the parent and dependent monitoring environments.