Richard,
CP is probably expecting to see an unsolicited x'80' status from the tape device, indicating that it is ready. But since the device isn't really a tape it may never provide an attention when it's ready to read or write, which results in the devices showing I/R from CP's perspective. The vendor would have to better emulate a tape device, providing the attention when it's ready and also no-op any of the several other tape commands like rewind unload etc. it doesn't support. The device could simply provide CE/DE status to any of the basic tape commands it can't perform to no-op them, making CP happy. Otherwise you may have to define address ranges of unsupported device types. (my posts have had long delays - this one was sent 12:17pm CT on 9/25) Regards, Mike ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, September 25, 2008 11:21 AM To: [email protected] Subject: Re: Error Flags No, READY does not help, it only works on virtual devices that have a pending interrupt. The only things I know of that do affect it, and I have been going down the list, are SET RDEVICE cuu CLEAR, which requires that the devices be varied offline, and an IPL of VM. From looking at the CP code, about the only way to clear this other than the two previously mentioned would be for there to be a clean, unsolicited, device end from the device. The devices really are not virtual tape devices, they are special processors that are written to and read from. I presume that tape was chosen as the medium to masquerade as because it is the simplest device that has the ability to do both. You probably cannot consider a printer, even though it is possible to read the print buffer on at least some of the models available, so you are left with tape and dasd., and tape is simpler to emulate. The problem is that the vendor chose to not handle things quite right when CP issues a RUN command at DETACH time. Their previous model never told CP that the devices were NOT READY, so they do not have this effect. Since the device never pays attention to the I/R condition and neither does TPF, the equipment is usable under VM. However, it should behave better. Unwanted conditions, ones that cannot be handled by the equipment, should never purposefully be reflected to CP by the devices. I could call the devices unsupported class tape devices. If I could count on their staying at the same addresses, that might be OK. Unfortunately, I just found out this week that 16 of them had been readdressed a month ago, so I cannot count on it. I do not like playing catch up with the device configuration when it comes to strange devices. It gives me too many chances for error, too many chances to screw up my SYSTEM CONFIG. And besides, the vendor had it right and chose to mess it up. Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rydberg Sent: Wednesday, September 24, 2008 2:58 PM To: [email protected] Subject: Re: Error Flags Richard, Does the CP READY vdev command have any effect on these virtual tape devices? Mike ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, September 24, 2008 4:45 PM To: [email protected] Subject: Error Flags Why does the RDEVINTR flag in RDEVRFLG persist, as evidenced in the messages below, even though the device has been attached to a user and is actively being used? Examination of the RDEV confirms that the bit is on. q 69e 69f A tape 069E intervention required. TAPE 069E ATTACHED TO JOEUSER 069E R/W A tape 069F intervention required. TAPE 069F ATTACHED TO JOEUSER 069F R/W Note: These are not real tape drives, so it is not possible to actually load a tape. Also, the TAPSENSE command that comes with the VSSI VTAPE product indicates that, at least in the virtual machine to which they are attached, they are ready with tapes at load point and they appear to have autoloaders which contain tapes. Related question, Is there any way to clear the bit other than varying the devices off and entering a SET RDEVICE 62E-62F CLEAR command? Storing into memory does not count. Regards, Richard Schuh
