The following message is a courtesy copy of an article that has been posted to alt.folklore.computers,bit.listserv.ibm-main as well.
re: http://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted http://www.garlic.com/~lynn/2007m.html#66 Off Topic But Concept should be Known To All part of the new, old things are called "virtual appliances" ... but in the good old 60s & 70s ... they were called "service virtual machines" some recent posts mentioning the virtual appliance genre http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC http://www.garlic.com/~lynn/2006x.html#6 Multics on Vmware ? http://www.garlic.com/~lynn/2006x.html#8 vmshare http://www.garlic.com/~lynn/2007i.html#36 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation http://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies cp67 had fairly early implemented fast, automated dump&reboot. That along with the change-over to using 2702 "prepare" command helped contribute to round-the-clock, 24x7 cp67/cms online, timesharing services. The issue was that 360/67 were leased ... and charge for was based on system meter running ... and having the system up 3rd/4th shift might have the meter running ... but light load charges might not be able to cover the off-shift lease rate. The system "meter" would run, even when the operating system was in wait state, but there was I/O "active". The use of the 2702 "prepare" command for terminal I/O would effectively suspend "I/O" and the system "meter" would stop. The other part as the fast, automated dump&reboot helped make practical to run cp67 3rd&4th shifts w/o any human (operator) present (aka "dark room") ... eliminating another expense that light-load offshift useage might not cover. The combination helped encourage both internal 7x24, around-the-clock online, timesharing cp67 operation ... as well as help make various commercial cp67 timesharing offerings more viable http://www.garlic.com/~lynn/subtopic.html#timeshare however, one of the short-comings with unattended, offshift operation was that the "service virtual machines" still required human intervention. as part of lots of work on performance tuning, dynamic adaptive dispatch/scheduling, virtual memory optimization, workload profiling http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.html#wsclock and other stuff I was doing at the science center http://www.garlic.com/~lynn/subtopic.html#545tech I was having to do a lot of benchmarking http://www.garlic.com/~lynn/subtopic.html#benchmark and as part of the benchmarking, I worked on being able to automate the whole process. One of the issues was being able to generate a new/different kernel and automatically reboot ... and start the next sequence of benchmarks. cp67 had morphed into vm370 and inherited the automatic reboot operation. The issue then was how to get all the benchmarks kicked off. I created a "autolog" command that emulated the manual login process ... and added one such command late in the system bringup/boot process. The resulting process that was automatically logged on then could execute scripts with autolog commands for large number of other processes. I initially used it for implementing the benchmarking process. For instance, in the final sequence before release of the "resource manager" ... there was a sequence of something like 2000 (automated) benchmarks that took 3months elapsed time to run. However, it was quickly realized that the autolog process (for benchmarking) ... would also extremely useful for automating the startup of "service virtual machines" ... as part of automated system reboot. The burlington development group was one of the organizations that had been distracted by the future system project http://www.garlic.com/~lynn/subtopic.html#futuresys after FS was killed (and before burlington was put on notice that they were being shutdown and everybody being transferred to POK to support mvs/xa development) ... they had crash program to turn out items in vm370 release 3 ... and picked up a lot of stuff from the science center (including the autolog command) where we had continued to work on (360/370) virtual machine activity. ---------------------------------------------------------------------- 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
