Making TapeSHARE work with MVS allocation more effectively

TapeSHARE does not alter or replace MVS Allocation processing. It works with MVS Allocation to ensure that the maximum number of tape device allocation requests are satisfied.

The default settings for the TapeSHARE retry and recovery parameters (such as retrycnt, retryint, and action) have been calculated to achieve maximum tape-dependent throughput in most installations.

Before you make adjustments to these parameters, you should try to determine that operating TapeSHARE with the default settings does not achieve the desired results.

• TapeSHARE through the BBPARM member AAOTSP xx member
• MVS Allocation through the SYS1.PARMLIB(ALLOC xx) member

Specifically, BMC recommends the following settings:

• Use the TapeSHARE default settings of retrycnt=5 and retryint=30 (seconds)

  The retry parameter processing causes MVS Allocation to single-thread activity so increasing the time between RETRYs or the number of RETRYs can negatively impact system throughput.

  The default value, which cause TapeSHARE to RETRY five times with a 30-second WAIT between retries, is optimal in most cases and should be altered only after careful consideration.

• Specify action=nohold in BBPARM member AAOTSP xx

  This setting tells MVS Allocation to allow the requestor to WAIT (subject to the conditions outlined in this section) and go through Allocation again (subject to the conditions outlined in this section) when another device becomes available.

  The action=hold setting is not recommended. When HOLD is specified, MVS Allocation Recovery is single-threaded and no other Allocations will complete recovery processing until this request is satisfied. Use of HOLD should be carefully considered.

  The BMC suggestion for MVS Allocation customization is that you modify SYS1.PARMLIB(ALLOC xx) to increase the number of retries for MVS Allocation. The default value is 5 and the maximum allowed is 255. Determine and specify the value that best suits your site.

  After you have customized both TapeSHARE and MVS Allocation as previously outlined, it is still possible to receive the IEF238D WTOR. This response can occur under the following circumstances:

• MVS Allocation will only allow waiting if there are online tape devices that are not allocated to the requesting job.

  Therefore, even with a TapeSHARE action=nohold specification, if there are currently no tape devices available on the local partner’s system and TapeSHARE fails to get a device from a remote partner, MVS Allocation will not allow a WAIT (which is implied in NOHOLD) and will take the action defined by the MVS SYS1.PARMLIB(ALLOC xx) POLICYNW parameter in use for that system.

• During normal Allocation processing, MVS will go into Allocation Recovery when it finds no online tape device to satisfy the request.

  At that point, TapeSHARE is given control and attempts to get a device from its partners. TapeSHARE retries as many times as is specified in the AAOTSPxx member in use for that system.

  If TapeSHARE fails to get a device, it returns to MVS Allocation with the action specified on the action= parameter in AAOTSPxx for that system. If the action is HOLD or NOHOLD (which both imply a WAIT), and a WAIT is permitted, MVS Allocation will cause the requestor to wait until either MVS Unallocation is driven on that system or a device is varied online.

  At that point, the requestor goes through Allocation processing again, and, if it fails to obtain a device, TapeSHARE will be redriven by MVS Allocation. This process is repeated the number of times specified in the MVS SYS1.PARMLIB(ALLOCxx) member in use on this system at that time. The default value is 5. When that value is exceeded, MVS Allocation takes the action defined in SYS1.PARMLIB(ALLOCxx) (where the default action is to issue the IEF238D WTOR).

  Finally, BMC also recommends that you implement automation to handle the WTOR IEF238D with MainView AutoOPERATOR Rules to automate those situations when the IEF23