I think I agree with most of what's already been said. I'll add a few additional thoughts, but my point of view is really from the device perspective and not how you manage volumes in the library or your tape catalog, etc.
The system will initially put the device in the autoswitchable (or not) state as you defined it in HCD. The system doesn't require any special serialization to do that. You can VARY them AUTOSWITCHable later, but the system does have to get some ENQs to do that. Also keep in mind that a device has to be offline to change the autoswitchable attribute, so depending on how the devices are defined, that might mean VARYing them OFFLINE, then VARYing them AUTOSWITCH,ON, then VARYing them ONLINE again. So consider when you are doing this - for example, if you were planning to put these in COMMNDxx, keep in mind that these commands are fighting over serialization while the system is trying to start up everything else. Autoswitch processing really was intended to work within a sysplex/monoplex. Each system within the sysplex knows what the other systems are doing with individual tape drives, so if system 1 is trying to allocate a drive, it knows that system 2 has specific drives allocated and can avoid choosing them. That communication doesn't extend past the sysplex/monoplex. It will handle your cross-monoplex environment, but it isn't very efficient, and you will get the IEF292I/IEF294I messages (as was previously stated.) Basically, each monoplex doesn't know what the other is doing with the drives. During allocation, we pick a drive that is not in use in this monoplex, try to use it, and if it is in use by the other monoplex, we undo everything and try again. Each allocation request could be slower (because the system may through a lot of processing just to find out that a drive isn't available.) One other thing to keep in mind, if we find that all of the drives enter that AFH (assigned to foreign host) state, then the system cannot allocate a device. That might be unlikely, based on the number of available drives and what the tape workload looks like on each system. You might also consider splitting the drives between the two monoplexes (so half are online to monoplex A and half are online to monoplex B) as was also previously suggested. - Scott Ballentine (sbal...@us.ibm.com) z/OS Allocation, Scheduler, SMF ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
