Bruce Black wrote: > One of my jobs at Univac/RCA was maintaining the error recovery routines > for I/O devices, incluing the RACE. Luckily, the system was so flakey > that it was easy to generate errors to test with. Unluckily, there was > little you could do to recover from a card that got crunched going down > the raceway.
i had a similar but different experience in the dasd engineering lab (bldg. 14) and dasd product test lab (bldg. 15). they had all these (dasd) "test cells" that periodically needed connection to mainframe channel/processor for various testing. note that test cells are not directly related to datacell/2321, test cells were security operation ... they were approx. 6-to-7ft cubes, steel wire mesh cages with special combination lock door (that housed equipment in development), located inside a secure machine room, inside a secure bldg, etc. they had tried running mainframe under an operating system ... but found that MTBF for MVS was on the order of 15 minutes (i.e. single dasd testcell could generate more errors ... including all sorts of architecture violations ... in 15 minutes than most shops would experience in years). as a result, they had to resort to doing all testing with dedicated, stand-alone processor time on a testcell by testcell basis. as a fun exercise, i undertook to rewrite i/o supervisor (including error recovery and recording) so they could concurrently test multiple testcells in normal operating system environment (w/o having to take all the machines down for stand-alone, dedicated machine time) ... which drastically increased productivity (i/o supervisor was bullet proof and never failed) misc. collected postings about bldg. 14 and 15 work http://www.garlic.com/~lynn/subtopic.html#disk ---------------------------------------------------------------------- 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
