Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP Path: utzoo!watmath!watdcsu!herbie From: herbie@watdcsu.UUCP (Herb Chong [DCS]) Newsgroups: net.unix Subject: Re: Re: IBM to support UNIX on 4300 Message-ID: <1058@watdcsu.UUCP> Date: Sat, 2-Mar-85 20:19:34 EST Article-I.D.: watdcsu.1058 Posted: Sat Mar 2 20:19:34 1985 Date-Received: Tue, 5-Mar-85 14:14:43 EST References: <801@sdcsla.UUCP> <424@lsuc.UUCP> <990@watdcsu.UUCP> Reply-To: herbie@watdcsu.UUCP (Herb Chong [DCS]) Organization: U of Waterloo Lines: 55 Summary: In article <759@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >> With all this talk about IBM's port of UNIX to the 370's, what about the >> version done at ATT? It is described in pretty good detail in the Oct 84 >> BLTJ. Essentially, they got IBM to make some mods to TSS, and then put >> Unix on top of it. TSS deals with the i/o hardware and paging, Unix does >> everything else. This isolates Unix from different hardware configurations >> (I/O channels, etc). > >You must be kidding if you are proposing to run anything except >VM/CP on a 370 type machine. How many machines run TSS? Very few >I bet. i know of a few machines running TSS/360. aside from running on a faster on a s/370 machine, you gain almost nothing. you lose capabilities of having more than 6 channels, hardware support of virtual addressing, and other performance enhancements that work in microcode. in short, you run TSS/360 because you have to and not because you want to. IBM no longer supports it so you live with all the bugs unless you want to fix them yourselves. there are compelling reasons for running IX/370 in a VM environment. there are only a few possible types of interrupts that a virtual machine receives: i/o, timer, svc (traps), diagnose (for VM services) and external (console commands). receiving any other types of interrupts is a fatal error that indicates something drastically wrong in the CP component of VM that manages the real machine. thus, all code to do with error recovery in the unix kernel that are hardware related can be completely thrown out as they will never be needed. IX/370 doesn't have any and probably never will. why duplicate function when that sort of code is completely redundant. also, the spool manipulation commands of CP are heavily used to handle real i/o to printers and other such devices. again, more code is redundant and not included in IX/370. the CP environment insulates the IX/370 machine from both hardware problems and changes in hardware. the device driver interface assumes that it is working with real disks that are physically blocked at 4K no matter what device it's on and the real devices can be shared with other virtual machines running other systems. there are facilties builtin to communicate with other virtual machines whether they are running IX/370 or not. IX/370 will run on VM in a 370-XA environment which has a drastically changed I/O architecture from S/370. the VM interfaces ensures transparent I/O functions while providing many of the benefits of the new structure. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu