On Tue, 2007-07-17 at 07:25 -0400, Bill wrote: > > IBM's answer was that the control unit must be within > 400 feet of the CPU or there would be I/O errors due to the control unit's > not getting the next CCW in time.
And the Blue equipment tended to be at the "slack" end of the timing window. And the O/S software was written accordingly. I well remember an outage of more than a day after a microcode update to a PCM (not Amdahls, who I was with at the time) DASD controller. Nothing would IPL. The story I heard was they were at the "sharp" end of the timing window. Eventually had to put sufficient delay in the line so the (host) code could keep up. > Software access methods still assume the physical DASD is CKD, they build > CCWs that act as if there were gaps and CKD on the tracks, the control units > decode all these legacy CCW commands, they convert them into disk actions > that > reflect the reality of the physical FBA disks, the entire track is probably > in > high-speed control unit cache so there is no need at all for gaps, and > finally they convert the I/O request's ending status back into virtual CKD > status > information for more legacy IOS code to use in handling any possible error. > There is a LOT of code still supporting the CKD structure and CKD gaps that > have not existed for perhaps 15 years now. Which takes us back to the thread of a day or two ago - why don't we have native FBA support ???. Even if only for OE ... er, OMVS, ... er (non-USS) USS, er ....*nix-ish filesystems (initially). Shane ... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
