Deciding which APPC/MVS LUs should be Members of a Generic Resource Group

Although the use of generic resource names for APPC/MVS LUs can benefit your installation, the mix of transaction programs that your installation uses, and the complexity of the APPC/MVS configuration, affect how easily you achieve those benefits. For example, your installation's current set-up might include many TPs that are handled by one APPC/MVS LU on a single z/OS system in a sysplex. With generic resource support, it is relatively easy to distribute this work among additional LUs on the same z/OS system, or among additional LUs on other systems in the sysplex. To do so requires the following steps:

With LUADD statements in parmlib member APPCPMxx, define the additional LUs, using the original LU's specific name as the generic resource name for the group.
Modify the LUADD statement for the original LU, using its original name as the generic resource name, and supplying a new specific name.

No changes to the TPs are necessary.

For another example, suppose your installation has multiple LUs in the sysplex that process the same work. In this case, using one generic resource name for the group of LUs requires more work than the preceding example:

Use the specific name of one of the LUs as the generic resource name for the group.
Modify the LUADD statement for each LU, adding the generic resource name. For the one LU, supply a new specific name as well.
Modify the TPs and side information for these LUs, replacing specific LU names with the generic resource name for the group.

Your installation may define more than one generic resource group in its APPC/MVS configuration, but not all APPC/MVS LUs have to belong to a group. Those LUs in a group, however, must have access to all the same resources; they should:

Have the same, if any, transaction scheduler associated with them.
Use the same TP profile data set, or use TP profile data sets that contain the same TPs.

For the TPs running on LUs in a generic resource group, make sure that all the TPs specify the generic name of the MVS LU on the Allocate request. Otherwise, if you allow some TPs to use the generic name, and others to use the specific name, timing becomes the key to successful allocation requests, even for TPs that ran reliably before.

For example, suppose your installation has set up a configuration like the one in Figure 1, which shows two TPs that run on the workstation:

Timecard logs the hours an employee works; it allocates a conversation with a specific APPC/MVS LU.
E-Mail retrieves mail from the host system; it allocates a conversation with an APPC/MVS LU by using a generic name

On the host, two APPC/MVS LUs share a generic resource name: LUA and LUB are both known by the generic name MVSLU.

Figure 1. APPC/MVS Configuration with a Mix of Allocate Requests to Specific and Generic LU Names

To understand the problem with allowing the use of a mix of specific and generic LU names on Allocate requests, consider the following sequence of events:

On Monday, John arrives at work and invokes Timecard to enter the hours he worked on Friday and over the weekend. Under the covers, a session is established between the workstation LU and the LU specifically requested on the Allocate request, LUA.
While checking his recollection of the hours he worked, John also invokes E-Mail to receive his mail. Under the covers, a session is established between the workstation LU and one of the LUs in the generic group. LUA is not available, because a session is already established between the workstation LU and LUA, under its specific name; so LUB is selected for the E-Mail Allocate request. So both conversations are successfully allocated.
On Tuesday, John is worried about input that he is expecting from a co-worker, so he invokes E-Mail as soon as he arrives at work. A session is established between the workstation LU and one of the LUs in the generic group— this time, LUA is selected.
While waiting for his mail to arrive, John invokes Timecard to enter the hours he worked on Monday. Today, Timecard fails, not because of an error in its own processing, but simply because it wasn't the first TP to allocate to LUA from this workstation LU. Once the workstation LU establishes a session with LUA using LUA's generic name, the workstation LU cannot allocate to LUA using the specific name, while the first session is still bound.

Other timing problems might result because, with generic resource groups, the system fails the Allocate request when both of the following are true:

Another TP has already successfully issued an allocation request using the specific LU name for an LU in the generic resource group
No other LUs in the generic resource group are available.

To prevent such failures because of timing, make sure you assign several LUs to the same group, and make sure all the TPs that run on LUs in the group use the generic resource name on the Allocate request. To reduce the amount of work required for the latter step, use an existing, specific LU name as the name for the generic resource group.