Using the TAPEMGR Process.
Article ID: 29385
Updated On:
Products
Issue/Introduction
Using the TAPEMGR Process.
Environment
Component:
Resolution
Effects of Using the TAPEMGR Process
The TAPEMGR process keeps track of tape drive usage and displays pending drive allocation and mount messages as held lines in its associated window. The TAPEMGR process is unique in that it can act as its own window manager or it can be a background process defined in another window, typically the SYSTEM window. The TAPEMGR process obtains information by trapping messages (for example mount messages) that CA VM:Tape periodically sends to the operator. Since changes in drive status can also occur without operator notification, the TAPEMGR process issues a VMTAPE QUERY ALLOC and a VMTAPE QUERY TAPES command whenever it writes or updates a held line.
CA VM:Operator is delivered with a default MAINOPER console definition that includes two TAPEMGR processes. One displays CA VM:Tape messages in the SYSTEM window as held lines and the other operates its own VMTAPE window which displays the same held messages but also has a static display of the tape drive status that can be paged via PF keys. In this default configuration of the MAINOPER console with two TAPEMGR processes, two VMTAPE QUERY ALLOC and VMTAPE QUERY TAPES commands will be issued every minute or following the writing or updating of a held message. This can cause significant CA VM:Tape activity and contention, particularly when STAM is being used to manage tape drives shared between multiple CA VM:Tape systems, therefore customers are advised to use the TAPEMGR process sparingly.
CA VM:Operator may be configured with multiple consoles including temporary consoles that are implemented by the VMYIAMOP command. These consoles are typically used by system programmers who need to access the operator console, particularly with the REVIEW window, in order to determine what is happening on their z/VM system.
CA recommends that the TAPEMGR process not be used at all with VMYIAMOP consoles and, when its use is desirable on other consoles, that only one TAPEMGR process be defined per console. If you have operator consoles that are dedicated to tape operators, then configure those consoles with the VMTAPE window as the primary window. If you have operators that monitor the SYSTEM window and occasionally handle mount requests, then the TAPEMGR process can be run in the SYSTEM window without the VMTAPE window being defined.
You can easily configure VMYIAMOP console definitions without any TAPEMGR processes. To do that you should create a new INCLUDE file based on the SYSTEM INCLUDE file that is supplied with CA VM:Operator. Simply remove the PROCESS TAPEMGR record from the new INCLUDE file and specify it in all of your USERID files instead of the default INCLUDE SYSTEM record. While changing these USERID files you should also check for, and remove any INCLUDE VMTAPE records that may be present.
Similarly you can configure your CONSOLE file definitions to use either the PROCESS TAPEMGR record in the SYSTEM window or the INCLUDE VMTAPE record to define a VMTAPE window. If the console is for a tape operator you can remove the INCLUDE SYSTEM record and make the INCLUDE VMTAPE record define the primary window for that console. Also be aware that when changing or removing windows in a USERID or CONSOLE files you may also need to change or remove PF key definitions that directly reference windows by name to avoid console initialization errors.
CA recommends that the TAPEMGR process not be used at all with VMYIAMOP consoles due to the increased usage of CA VM:Tape that it causes. This is particularly important when CA VM:Tape is configured to use the Shared Tape Allocation Manager (STAM) feature.
Feedback
