Program 1 Program 2
Application programs can use the CMS work unit facility, which supports the following DB2 Server for VM functions:
| Note: | You should not use the CMS SUBSET function if the WORKUNIT option in SQLINIT/SQLGLOB is set to NO. |
Associated with each work unit is a unique work unit id assigned by CMS. When you invoke your program, a default work unit id identifies the currently active work unit for your program. To switch to a new work unit, you must explicitly change the currently active work unit.
Use the CMS routines shown in Figure 90 to manage work units:
Figure 90. Routines to Manage Work Units
| CSL Call | Function | Description |
|---|---|---|
| DMSGETWU | Get
work unit id | Obtains and reserves a work unit id from CMS. You must invoke this routine for each separate work unit you wish to manage. |
| DMSPUSWU | Push
work unit id | Pushes the work unit id onto the work unit stack. Makes the pushed work unit the currently active one. |
| DMSPOPWU | Pop
work unit id | Pops the work unit id from the top of the stack. The next work unit on the stack becomes the currently active one. |
Although a work unit may have been established and made the currently active work unit, it is not known to the database manager until the first SQL statement in the work unit is executed. When this SQL statement is processed, the work unit id is obtained from CMS, a logical path (work unit) is established between the application and the DB2 Server for VSE & VM resource, and the user is connected to either the default application server or the explicitly connected application server. (The default application server is the one established by the SQLINIT EXEC.) The CONNECT statement can be used to connect to the desired application server.
If the work unit id is already known, no change occurs in the database to which the user is connected in that work unit, unless the user explicitly issues a CONNECT to change the database.
One DB2 Server for VSE & VM application can be invoked from another. By starting a separate CMS work unit before invoking the second application, the calling application will not be affected by any COMMIT or ROLLBACK statement issued from the called application. When the called application pops its work unit id from the top of the stack, control is returned to the first application. The calling application is in the same state as it was before it called the other application. The calling application and the called application can access the same database or different databases.
Figure 91 illustrates how the calling program can be isolated from the work committed or rolled back by the called program.
Figure 91. Program Transitioning Using CMS Work Units
Program 1 Program 2
A DB2 Server for VSE & VM application (for example ISQL) can interrupt processing of its logical unit of work to go into CMS SUBSET and invoke another DB2 Server for VSE & VM application. The processing done by the invoked application does not affect the invoking program. When control is returned to the invoking program, the LUW is in the same state as it was before going into CMS SUBSET.
To prevent the application in the CMS SUBSET from affecting any work done by the invoking application in normal CMS, the SQLRMEND EXEC cannot be used with the COMMIT ALL or ROLLBACK ALL parameters while in CMS SUBSET mode. (See the DB2 Server for VSE & VM Database Administration manual for more information on the SQLRMEND EXEC.)
More than one DB2 Server for VSE & VM application can concurrently process against the same DB2 Server for VSE & VM database or different DB2 Server for VSE & VM databases. The application server ensures that processing done by one application is independent of that done by another. In order to do this, the server acquires and manages work units for each application.
By acquiring two or more work units, an application can logically access the same database from different points in the application. These work units (and their paths into the database) cannot be processed concurrently.
Applications can copy data from one database to another by following these steps:
If an active work unit requests a SHARE lock on a DB2 Server for VSE & VM resource, and a suspended work unit has an EXCLUSIVE lock on the same resource, the active work unit has to wait until the EXCLUSIVE lock is released.
Since the suspended work unit cannot resume processing until the active work unit is released or suspended, the user will be in an infinite wait state unless a cancel is issued or the agent is forced off.
This same locking problem will occur if the suspended work unit has a SHARE lock on the resource and the active work unit requests an EXCLUSIVE lock on the same resource.
To use CMS work units, your CMS virtual machine and the database virtual machine must be running under the VM/ESA operating system, the application server must be running in multiple user mode, and the Work Unit option in the SQLINIT EXEC must be set to yes (the default) at initialization time. See the DB2 Server for VSE & VM Database Administration manual for more information on SQLINIT EXEC.
The database manager does not reuse links for different work units. If you no longer need a work unit, you should enter either COMMIT RELEASE or ROLLBACK RELEASE, to free the (APPC/VM) path for reuse.
There is a degradation in performance when SQLINIT WORKUNIT (YES) is specified either directly, or indirectly as the default. This applies even if the application is not using multiple work units.