John A Pershing Jr <[email protected]> writes: > However, it's all a very fuzzy area. E.g., is CP an "Operating System", > since it is dependent on CMS for development? Or, is it, perhaps, > merely a Kernel on steroids? > > -jp > > And, yes, TPF transactions clearly can drive a printer -- e.g., to print > out an airline ticket or a baggage tag.
CP/40 was "control program" ... for 360/40 that had customed modified hardware providing virtual memory. CP/40 morphed into CP/67 when 360/67 with standard virtual memory became available. CP/40 (and then CP/67) development went on in parallel with CMS (when it was still called "cambridge monitor system") ... with CMS originally running stand-alone on 360/40 ... which went on in parallel with CP/40 using the 360/40. When some people from the science center came out to the univ. to install CP/67, CP/67 source was still being kept on OS/360, assembled on OS/360 ... and physical "TXT" decks punched ... with cards for kernel build being kept in card tray (individual TXT decks had colored markers across the top to selective replace the TXT cards for specified routines. It wasn't until later in '68 that the CP/67 group felt that CMS was stable enough to move CP/67 over to CMS (and off OS/360). For some trivia ... the claim is that the person responsible for CP/M (early personal computer system) ... had cribbed the name from CP67/CMS ... he had used CP67/CMS at NPG school at Monterey in early 70s. other CMS trivia was that in the transition from CP67 to VM370, CMS had its name changed to "conversational monitor system" ... and artificially crippled so it would not longer boot/ipl on the bare hardware. One of the problems over the decades was having people from traditional operating system backgrounds come to work on VM ... was that the CP heritage from the earliest beginnings was constantly removing stuff from the kernel ... while people with traditional operating system backgrounds would be taking shortcuts and be constantly putting things into the kernel. I had done detailed structural and code-flow analysis of CP kernel structure in early to mid 80s and there were huge amount of things (that never belonged) had been added to the kernel and it was turning into a mess of spaghetti code ... old post with some discussion of the analysis http://www.garlic.com/~lynn/2001m.html#53 move recent posts about removing stuff from cp kernel to make things run faster: http://www.garlic.com/~lynn/2009l.html#36 Old-school programming techniques you probably don't miss http://www.garlic.com/~lynn/2009l.html#44 SAN: conflicting opinions so part of the reason for taking a large component from the vm370 kernel and moving it into virtual machine ... while increasing thruput by possibly factor of 100 times ... was partly to make HSDT links run faster http://www.garlic.com/~lynn/subnetwork.html#hsdt and partly to demonstrate that lots of the code in the kernel wasn't justified being there. early days of TPF (not long after the name change) ... was that TPF didn't support multiprocessors ... and the 3081 was originally to be a multiprocessor only machine ... eventually a partially crippled 3081 uniprocessor was produced, 3083 ... primarily for TPF market ... however, until that happened, for TPF to run on 3081s, it had to run under vm370. wiki acp page: http://en.wikipedia.org/wiki/IBM_Airline_Control_Program wiki tpf page: http://en.wikipedia.org/wiki/Transaction_Processing_Facility For environment that was nearly all TPF execution ... that resulted in the 2nd processor being idle (unless two TPFs were run concurrently). The originally vm370 multiprocessor support came from a design/project that I had done in 1975 for a 5-way SMP (that was never announced or shipped) ... which I claimed had the optimal kernel pathlength overhead for supporting multiprocessor operation (at least for an environment with enough virtual machines to keep all processors running at 100% utilization). lots of past posts mentioning SMP support and/or the compare&swap instruction http://www.garlic.com/~lynn/subtopic.html#smp In any case, for the (3081, multiprocessor) TPF market segment ... one of the vm370 releases had a major change in the way multiprocessor support was implemented ... which enable a lot of cp kernel code to be executed concurrently/asynchronously on the 2nd (idle) processor, overlapped with TPF virtual machine execution. This significantly increased the multiprocessor kernel pathlengths ... but was traded off with gaining a little TPF increased throughput (since the increased pathlengths was offset with asynchronous use of the 2nd/idle processor). The TPF market segment thot it was great ... however, all the other VM370 (multiprocessor) customers saw a ten percent throughput degradation. One of the issues with ACP uses of TPF ... was that the data management facilities are rather primitive and they have had to take the system down on regular basis for major updates (potentially once a week). We had been brought in to one of the major res. systems to look at "fixing" their "ten impossible" problems (including the scheduled outages). Some recent posts on the subject: http://www.garlic.com/~lynn/2009l.html#25 http://www.garlic.com/~lynn/2009l.html#54 we had another episode with (different) res. system ... for a short stint my wife was chief architect for amadeus (the major european res system that started off being built from the old eastern airline res system). One of the problems was that my wife sided with most of europe choosing x.25 as major terminal connectivity. This led to the SNA forces getting her replaced ... however, it didn't do any good, Amadeus went with x.25 anyway. wiki amadeus pages: http://en.wikipedia.org/wiki/Amadeus_CRS http://en.wikipedia.org/wiki/Amadeus_IT_Group current amadeus web page: http://www.amadeus.com/amadeus/amadeus.html other wiki res system pages: http://en.wikipedia.org/wiki/Sabre_%28computer_system%29 http://en.wikipedia.org/wiki/Galileo_CRS http://en.wikipedia.org/wiki/Worldspan -- 40+yrs virtualization experience (since Jan68), 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
