This reminds me: I remember that back when Amdahl was trying to get their Unix system working on the 580 dual processor they had problems with the MVCL. Actually I think this is why I knew that MVCL was a problem in multiprocessor systems.
It may be that Amdahl didn't implement MVCL properly. There were some variances between IBM hardware and Amdahl hardware. The UTS group also had problems with the implementation of channels on the 580 and the asynchronous terminal controller (not the 3270 controller). I don't remember much detail, but it had to do with when interrupts occurred. When testing UTS under VM it worked, but when running native it failed. Sometimes VM can mask these kinds of problems. -----Original Message----- From: Phil Payne [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 5:15 AM To: [EMAIL PROTECTED] Subject: Re: Technical Specs > I wonder what the significance of being interruptible is if not garbling results. MVCL came along with System/370 - at that time uniprocessors were more common and a lot of IBM hardware had strict timing considerations - 1419 interrupts HAD to be handled within so many milliseconds or you "lost" the document - sometimes literally. So an instruction with a potentially long duration HAD to be interruptible for I/O interrupts to be handled in time. I'm not sure what the current situation actually is - the time-critical peripherals have gone and most systems are multi-CPU with the SAP offloading a lot of I/O processing. I doubt that MCVLs get interrupted much these days. > I imagined that MVC was "atomic" in nature meaning that the second processor couldn't "garble" things until the MVC had run it's course. I think that's "implementation-dependent", as IBM would say. Unwise to rely on it. -- Phil Payne http://www.isham-research.com +44 7785 302 803
