[email protected] (David Andrews) writes: > Perhaps TCPIP autolog would do the trick as well? Does your product run > all the time?
I had originally created the *autolog* command for automated benchmarking ... near the end of the system boot/ipl process, it would autolog a generic id (*autolog1*). For benchmarking, *autolog1* would have script that autolog'ed the benchmarking ID ... which had a script controlling which processes to *autolog* and which synthetic workload each process should run. At the end of the benchmark, it would update the script for the next benchmark, and do an auto shutdown/reboot ... which would invoke the next benchmark. This would be repeated as long as needed. For instance, for the final validation for my resource manager, over 2000 automated benchmarks were run, taking 3 months elapsed time. Some past posts mentioning automated benchmarking http://www.garlic.com/~lynn/submain.html#bench some old email mentioning migrating a whole lot of code from cp67 to vm370 ... and features that were in my internal csc/vm release (product for internal datacenters) starting out with release 2 of vm370. http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 we had collected lots of workload and configuration profile information from both internal and customer datacenters ... and built graph depicting normal range of operations. The first 1000 benchmarks were manually defined to evenly cover the wide variety of configurations and workloads (along with numerous benchmarks way outside normal observed operations). The final 1000 was an intelligent automated program that included sophisticated analytical system model ... which would "look for" interesting operating points (based on all benchmark data todate; it would also predict what the resulting benchmark should be and compare the actual results with the predicted; interesting that it was used to help calibrate actual operation as well as the analytical system model). some of the items (including *autolog*) were picked up and released in the standard vm370 release 3 ... and other features were packgaged and released in my resource manager. misc. past posts mentioning my resource manager http://www.garlic.com/~lynn/subtopic.html#fairshare for production operation, while cp67 got auto-reboot fairly early ... it still required (operator) manual initiation of lots of the services (like networking). autolog became the standard process for starting all these standard processes (back then they were referred to as "service virtual machines" ... the current nomenclature seems to be "virtual appliance"). One of the issues for virtual machine based system use for 7x24 online timesharing operation ... both dedicated corporate use as well as commercial timesharing service bureaus (the '60s & '70s version of "cloud computing") was cutting datacenter costs for offshift, usually light useage. In the early days, machines were leased and monthly datacenter charge was based on hrs taken from the cpu meter, which ran when the cpu and/or any channel was active (and could continue to run for 400ms after all activity had ceased). A very early trick in cp67 was how to leave an active channel program (to accept incoming terminal activity) ... and still allow the channel to go to sleep when no data was actually being transferred. The later trick was increasing "dark room" operation for lots of offshift (not only auto-boot, but also have all the expected services to be back up and running). misc. past posts mentioning early online commercial timesharing service bureaus: http://www.garlic.com/~lynn/subtopic.html#timeshare part of picking up lot of stuff I had been doing on 370 for release 3 ... and then also releasing a lot of the rest of stuff as resource manager ... was getting stuff back into the 370 product pipeline after the failure of FS ... misc. past posts mentioning Future System effort http://www.garlic.com/~lynn/submain.html#futuresys i.e. FS was radically different from 370 and was going to completely replace it; as a result lots of work had ceased on 370 related products (I continued to work on 370 and made critical observations about reality of what was going on in FS). Recently I ran into description of OS/VS2 SVS & MVS that were supposedly just on the "glide-path" to the FS operating system ("OS/VS2 Release 3"). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- 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
