t...@tombrennansoftware.com (Tom Brennan) writes: > Yep - I'm hoping they'll like the batch facilities in MVS which in my > opinion are far beyond unix. This might be a spot where a history > lesson is needed, but I wasn't around in the early days: > > From what I've read, MVS started with nothing but batch jobs and later > grew into online systems. So TSO is just another batch job that > happens to communicate with a terminal. On the unix side though, it > seems they started with online terminals first, so a batch > (background) job was later created as a terminal session with no > terminal.
I've pointed that out before ... CTSS was conversational online default from the start, then some of the people went to the 5th flr and did Multics (and folklore is that some of the Bell Labs people went back home and did a simplified Multics, calling it unix) ... and other of the people went to the science center on the 4th flr and did CP/40-CMS (making hardware modifications to 360/40 to support virtual memory), which morphs into CP/67-CMS when standard 360/67 with virtual memory standard comes available .... precursor to VM/370-CMS (cms originally stood for "cambridge monitor system" ... is renamed "converstational monitor system" for vm/370). some cambridge science center posts http://www.garlic.com/~lynn/subtopic.html#545tech I've periodically mentioned Kildall working with CP/67-CMS at NPG school, before doing CP/M, which then morphs at Seattle Computing, and leads to ms/dos. os/360 assumed batch ... and had to provide increasing about of contingency handling capability ... while conversational started out assuming responsible human was there to handle the contigency cases. we were working with director of NSF and were suppose to get $20M to tie together the the NSF supercomputer centers. Then congress cuts the budget, some other things happen, and then they release an RFP ... but internal politics prevent us bidding on the RFP (director of NSF tries to help by writing the corporation a letter, but that just makes internal politics worse). As regional networks tie into the centers, it morphs into NSFNET backbone, precursor to modern internet some old email http://www.garlic.com/~lynn/lhwemail.html#nsfnet We do get TCP/IP product for mainframe but there are quite a few issues ... getting 44kbytes/sec using near full 3090 processor. I do the enhancements to support RFC1044 and in some tuning tests at Cray Research get full sustained channel speed throughput between 4341 and a Cray, using only a modest amount of 4341 (possibly 500 times improvement in bytes moved per instruction executed). some past posts http://www.garlic.com/~lynn/subtopic.html#rfc1044 Late 90s, a senior disk engineer gets a talk scheduled at annual, world-wide, internal communication group conference, supposedly on 3174 performance ... but opens the talk with statement that the communication group was going to be responsible for the demise of the disk division. The issue was that the communication group had strangle hold on datacenters with corporate strategic ownership of everything crossing the datacenter walls, and were fiercely fighting off distributed computing and client/server (trying to preserve their dumb terminal paradigm and install base). The disk division was starting to see data fleeing the datacenter to more distributed computing friendly platforms with drop in disk sales. The disk division had come up with a number of solutions to reverse the process, but were constantly being vetoed by the communication group. some past posts http://www.garlic.com/~lynn/subnetwork.html#terminal In the late 60s, increasing number of cp/67-cms customers were extending to 7x24 availability (including some number of commercial online service bureaus). One of the issues in the 60s mainframes were rented and initially, it was hard to promote offshit use enough to recover system costs. There was a lot of work done to reduce system costs (especially offshift). Part of system rental costs were based on the system meter that ran whenever the processor or any channel was running. All processor and channel activity had to be quiet for at least 400ms before system meter would stop. Special terminal CCWs were created to allow channel to stop ... but immediately start ondemand when characters were coming in ... some of the stuff sort of analogous being done for on-demand cloud computing (trivia long after mainframes had converted from rental to sales, MVS still had timer task that woke up every 400ms ... making sure that system meter never stopped). Other stuff to further minimize offshift costs was eliminating operator requirements. Another early CP/67 enhancement in the 60s was automatic re-ipl after failure (system come up and available w/o needing any human intervention). In the early 70s, as environments became more complex, increasing amount of CP/67 services were provided by "service virtual machines" (analogous to demons ... the current cloud virtual machines are referring then to virtual appliances) that are not connected to any real terminal. In the early 70s, I do the autolog command for CP/67 ... which is used for a wide variety of automation ... including automatically bringing up "service virtual machines" at an automatic IPL (w/o human intervention). At the IBM Pisa Science Center they implemented SPM for CP/67 ... which allowed software running in virtual machine to handle all interactions that would normally involve real terminal. This was used in conjunction with service virtual machines to implement "automated operator". This was moved to VM/370 ... but for some reason was never released to customers. Over time, various VM/370 features were released to customers like IUCV and SMSG ... but in aggregate they are still a subset of the full SPM facility. A trivial example was that the author of REXX wrote a multi-user spacewar game that relied on SPM ... and since the internal network software supported SPM ... any number of players around the network could play. There was a problem that some number of people started writing player 'BOTs that would beat the human players. The game was then enhanced so that energy use increased non-linearly as time between moves decreased below some (human) threshold ... trying to level the playing field between BOTs and humans. old email about moving lots of stuff from CP/67 to VM/370 including SPM and autolog http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 By the early to mid-70s, vm/370 automated operator facilities and service virtual machines were getting increasingly sophisticated. We leave IBM in the early 90s and later are brought in as consultants to a small client/server startup that wanted to do payment transactions on the server (the two people responsible for the "commerce server", we had previously worked with when they were at Oracle and we were at IBM), the startup had also invented this technology called "SSL" they wanted to use, the result is now frequently called "electronic commerce". I had absolute authority on the server to payment network side ... but could only make recommendations on the browser side. A big part of my time was developing compensating processes to do various kinds of contingency automation (a lot of which were decades old from mainframe environment) -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
