The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (McKown, John) writes: > What do you mean by "OMVS is not unix"? I'm more curious than anything > else. If you're talking about the TSO OMVS command, then it is every bit > as much "unix" as the original TTY terminals (anybody else every use a > KSR-33?). Also, z/OS UNIX System Service is also UNIX. It has been so > branded by the owner of the UNIX trademark (The Open Group?) three people from the science center http://www.garlic.com/~lynn/subtopic.html#545tech came out the last week of jan68 to install cp67 (predecessor to vm370 that ran on 360/67) at the univ. at the time, cp67 only supported 1052 and 2741 terminals. the univ. was getting some ksr-33 terminals and so i had to add ascii/tty support to cp67. 2702 supported SAD command that allowed terminal line-scanner to be associated with specific ports under program control. the science center had done support to dynamically determine whether it was dealing with either a 1052 or 2741 ... and use the SAD command to associate with the different ports as appropriate. so as part of adding ascii/tty support ... i figured i could do the same thing with ascii/tty support. well, it initially seemed to work ... however, the scenario that i really wanted to handle ... a single dialin phone number (for rotory pool) that could be used regardless of the terminal type ... failed to actually work. The problem wasn't with the SAD command and the line-scanner ... it was that the telecommunication controller took a short-cut and hardwired line-speed oscillator to each port. I needed to be able to both change the line-scanner and the oscillator line-speed on a port-by-port basis. this short-coming helped precipitate a project at the univerisity to build our own clone controller. started with a interdata/3 minicomputer, that was programmed to scan the port signal rise/fall to dynamically determine terminal line speed. also had to reverse engineer the 360 channel interface and build a channel interface board for the interdata/3. this was subsequently expanded to a cluster of interdata/4 handling the channel interface with multiple interdata/3s handling the port line-scanner interface. this project was written up somewhat blaiming four of use for the clone controller business. misc. past posts http://www.garlic.com/~lynn/subtopic.html#360pcm and, of course, the clone controller business is blaimed for motivation behind the future system project ... recently mentioned here http://www.garlic.com/~lynn/2008e.html#31 IBM announced z10 ..why so fast...any problem on z 9 and this reference mentions Fergus & Morris book attributing the distraction of the future system project providing the entre for the clone processors (as well as having long term dampening effects on corporate innovation). http://www.garlic.com/~lynn/2001f.html#33 and this recent post http://www.garlic.com/~lynn/2008d.html#16 more on (the new 40+ yr old) virtualization references this article that also discusses future system project http://www.ecole.org/Crisis_and_change_1995_1.htm numerous other posts mentioning future system http://www/garlic.com/~lynn/subtopic.html#futuresys as to Fergus & Morris reference to dampening effects on corporate innovation ... i've periodically speculated that the person responsible for 801/risc ... was attempting to go to the exact opposite exterme (in terms of hardware complexity) as what had been going on in the future system effort http://www.garlic.com/~lynn/subtopic.html#801 ---------------------------------------------------------------------- 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
