Commonly asked TapeSHARE questions and answers

This appendix contains answers to commonly asked questions regarding TapeSHARE operation. For more information, contact BMC Customer Support.

Question: How can users turn off TapeSHARE without stopping the BBI-SS PAS?

Answer: Create an AAOTSPxx member and specify a single partner statement that refers to the BBI-SS PAS. Activate the member using the .RESET BBI control command or through the Dynamic Parameter Manager application. All current tape activity continues without interruption.

For the MainView AutoOPERATOR running at the 3.1.0 level, you must have PTF BPO3114 applied before you can specify a single partner statement that points to the local BBI-SS PAS.

Question: How can I dedicate specific tape devices to a specific MVS image at a specific time of day?

Answer: Follow these instructions:

1. Create an AAOTSP xx member for the partners where the drives will NOT be dedicated and define those drives as NOTAKE.

2. Create an AAOTSP xx member for the partner where the drives will be dedicated and define those drives as NOGIVE.

3. Create a time-initiated Rule that issues the ACTIVATE command and puts these two parameter members in place at the desired times.

When these parameter members are active, TapeSHARE moves the drives over to the partner where they will be dedicated as jobs require them, and the NOTAKE setting disallows the drives from being taken back for as long as the configuration is in place and active.

When you want to return to “share all” mode, the same time-initiated Rule can activate an AAOTSP xx member without the NOGIVE and NOTAKE specifications.

Question: How much additional ECSA is needed for TapeSHARE?

Answer: MainView AutoOPERATOR needs 3K of ECSA for TapeSHARE.

Question: Since MVS rejects a VARY ONLINE command against a drive that is currently online on another MVS system, why does the TapeSHARE Workstation provide a MULTi command?

Answer: It is possible for 3480, 3490, 3410, and 3420 tape drives to be VARYed ONLINE to more than one MVS system. It can be done at the console when the VARY command is used with the SHARED parameter.

Because a tape drive, which is ONLINE to more than one MVS system, is incompatible with the way TapeSHARE operates, the MULTi command allows you to list any drives that are online to more than one system.

If this situation arises, you should immediately determine which partner should have the device and then issue the OF(fline) line command against the device on the partner that should not have it (refer to Chapter 2, “Controlling Tape Activity from a Single Point with TapeSHARE”).

Question: If a partner in a TapeSHARE Plex is re-IPLed, how can it start with the same drives ONLINE as it had before the IPL?

Answer: MVS controls what drives are ONLINE when MVS image is IPLed. If you notice that some drives are OFFLINE after an IPL, you can use the TapeSHARE Workstation and issue the (ON)LINE command. Then you might want to review the IPL procedure and include these drives in the list containing drives that should be online after an IPL. You can contact IBM for more information.

Question: Can the RETRY count maximum value be increased to more than 10?

Answer: The maximum value for the RETRY count is 10. If there are not enough drives in the TapeSHARE PLEX to satisfy the outstanding allocation requests, 10 RETRYs might not be sufficient for the jobs to receive the needed drives.

Raising the RETRY count to more than 10 can adversely affect the system and cause both MVS ALLOCATION and TapeSHARE not to work as designed.

At times, when there are more tape allocation requests than there are tape drives, maximum tape throughput can be accomplished with the default TapeSHARE RETRYCNT and RETRYINT values by specifying a tape allocation/recover action (either through the ACTION parameter in BBPARM member AAOTSP xx or through the analogous MVS parameter) to HOLD or NOHOLD.

This allows TapeSHARE to function as designed; it switches tape drives as needed when there are drives available on remote partners. When there are no drives available on remote partners, control is returned to MVS ALLOCATION, which attempts to satisfy the outstanding allocation requests with drives on the local partner (whose drives might have become available while TapeSHARE was retrying for devices from the remote partners).

In general (and especially in small TapeSHARE PLEXes), it is not recommended that RETRY count be raised higher than the default (which is 2) or that the retry interval be changed from the default (which is 30 seconds)

Question: Can TapeSHARE coexist with other ALLOCATION exits?

Answer: Yes, TapeSHARE can coexist with other ALLOCATION exits.

Question: If a job requests UNIT=3480 or UNIT=SILO, will TapeSHARE honor the request and attempt to get a 3480 or SILO type device?

Answer: Yes, MVS passes information to TapeSHARE (which includes the specific device type from the job) and TapeSHARE attempts to satisfy the Allocation Request with the specified device type.

Question: If a device does not have a PATH to MVS image, after the PATH is established, TapeSHARE still shows that device with OFFLINE status although the device is ONLINE after activating the PATH. Why doesn't TapeSHARE reflect the new status of the device?

Answer: TapeSHARE does not detect dynamic PATH changes. To display the path change, you can either issue the BBI command

.E TS,VALIDATE

or activate the BBPARM member AAOTSP xx with the Dynamic Parameter Manager application. Both actions cause the path status to be refreshed.

You can also automate this procedure by creating a Rule that is triggered by a message ID indicating a PATH change (for example, IEE302I) and the Rule can issue the BBI command

.E TS,VALIDATE

Question: If a device has to be set to OFFLINE manually (outside of TapeSHARE), how can I be sure that TapeSHARE will not attempt to use this device to satisfy an Allocation Request?

Answer: To be sure that TapeSHARE reacts correctly for a device that has been manually VARYed OFFLINE, BMC Software recommends that you define the device to TapeSHARE as NOGIVE/NOTAKE and issue the OFFLINE command. For example, you can create a Rule that issues the BBI command

.G devnum ,NOGIVE,NOTAKE

and issues the VARY OFFLINE command.

When this Rule fires, it ensures that TapeSHARE will not be confused if it attempts to GIVE this device at the same time you manually issue the VARY OFFLINE command for the device.

Question: Can TapeSHARE function on MVS SP 4.2 system?

Answer: Yes.

Question: Can TapeSHARE perform Allocation Influencing (for example, specifying a specific device range for specific jobs)?

Answer: TapeSHARE does not have the capabilities to perform Allocation Influencing by itself. However, this can be achieved with another BMC Software MainView product: PRO/SMS. PRO/SMS version 3.5.1 (and higher), when used in conjunction with TapeSHARE, creates a powerful tool for device management

Question: How can you set TapeSHARE so it does not retry for a specific device type (for example, 3480)?

Answer: To prevent TapeSHARE from retrying for a specific device type, define all devices of this type as NOTAKE on the local system.

If TapeSHARE on the local system detects a device that can satisfy the Allocation Request and this device is available for taking, it assumes that it can take the device from another partner. In this case, it will RETRY the other partners.

Question: What happens to TapeSHARE when RDS is started?

Answer: If, after IPL, MainView AutoOPERATOR is started first and RDS becomes active later, the status of the units is not correct. You issue the BBI command

.E TS VALIDATE

or

.E PARM AAOTSP00

to correct the status.

If RDS is bounced, it is normal to see that on the remote system all the units are offline and on the local system all the units are online. When RDS is not active, TapeSHARE is not aware of a device until the .E TS VALIDATE command is issued.

Question: What do I do when I receive an abend S0C1 when trying to use TapeSHARE?

Answer: For MainView AutoOPERATOR version 3.1, apply APAR zap BAO2955 or BPO3305. For MainView AutoOPERATOR version 4.1, apply BPO3306.

Question: Is there a command that will GIVE all devices ONLINE from SYSA to SYSB or SYSC?

Answer: There is no single command that will GIVE all devices from one system to another, but there are a few ways to accomplish that:

• You can use the TapeSHARE Workstation application to give the devices to another system

• You can schedule an EXEC on the system that issues the .G commands. For example:

'IMFEXEC SELECT EXEC( execname ) TARGET(SYSB)'

with a WAIT(YES) or WAIT(NO) specified. The EXEC issues commands in the format:

.G dddd,ONLINE

• You can create two Rules on each system.

Create Rule 1 with the following specifications:

Rule GIVE (Type CMD):
S1 : Command ID ==> GIVE
A1 : Reject Command ==> YES
WTO ==> &IMFTEXT *** COMMAND INTERCEPTED BY TAPESHAREAA : Function ==> ADD
Key ==> GET&WORD2.&IMFOTIME
Text ==> GET &WORD2 (requested by &QIMFID on &IMFODATE)
Queue ==> GET&QIMFID
Target ==> &WORD3

where

Create Rule 2 with the following specifications:

Rule GET (Type ALRT):
S1 : Text ID ==> GET
Queue ==> GET*
A1 : Command (Type MVS) ==> F BBI,.GET &WORD2

where

Now you can use commands such as GIVE unitaddr ssid, which cause the Rules to take action.

Question: Why do I still receive the WTOR IEF238D when I specify WAIT/NOWAIT in TapeSHARE?

Answer: This result is normal and expected because of the way MVS Allocation works. The sequence of the events that occur if there are no available devices to satisfy the job's requests is

1. MVS ALLOCATION cannot find a device.

2. Alloc passes control to Dynamic Exit Handler.

3. Dynamic Exit Handler passes control to each exit.

4. No devices could be found and the exit returns to Allocation specifying WAIT/NOHOLD.

5. Allocation issues: “IEF289E waiting for volumes or units” and waits.

6. Allocation wakes up and goes back to step 1.

This entire sequence is repeated for each time specified in the SYS1.PARMLIB member ALLOC xx. The default is 5 times.

When that number is exceeded, MVS Allocation issues the IEF238D WTOR in SYSLOG.

You can find a sample ALLOC xx member in SYS1.SAMPLIB(ALLOC00). For documentation on how to code ALLOC xx, refer to the IBM publication MVS Initialization and Tuning Guide.

If you review the SYSLOG for the time of the failure, you can see the IEF289E waiting for volumes or units message being issued. This is a result of the exit telling MVS Allocation to WAIT.

BMC Software recommends that you alter ALLOC xx to indicate a higher value for max-times. In addition, a Rule can be created to automatically respond to the WTOR if it is generated. By watching the fired count of the Rule, you can determine if the number of times specified in ALLOC xx is resolving mo