From: Anne & Lynn Wheeler on 5 Apr 2007 18:09 Rich Alderson <news(a)alderson.users.panix.com> writes: > Yes, people did, and do. And I mean besides me. > > On the hardware side, there are bits of code in the beginning of several of the > diagnostics that determine what hardware platform is under test, for example by > checking the result of > > MOVE 1,[-2,,777777] > AOBJN 1,.+1 > SKIPE 1 > <branch to code for KA-10 processor> > > since the KA-10 actually adds 1,,1 to the AC so that the carry out of the right > half propagates to the left. > > There are programmatic ways to detect the Model 166 processor (PDP-6), > the KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume > that there were checks for various Foonly and Systems Concepts boxen. 370 introduced store cpuid ... which included processor model number as well as processor serial number. current description of the instruction http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/10.58?SHELF=DZ9ZBK03&DT=20040504121320 the problem was then you still needed (potentially new) software that had the processor specific logic one of the things that vm370 had was a table of processor cpuids and associated values. when i was doing with dynamic adaptive control algorithms and the resource manager product ... was to be able to have completely dynamic adaptive values ... w/o requiring a (software lookup) table of all possible cpuids (with corresponding values). in theory the idea was that i could ship the resource manager ... and it could adapt to whatever processor and resources there were .... regardless of what happened ... (in theory) w/o requiring changes/updates to the software (and/or processor tables) ... even if new processor models subsequently came out. I had done packaged internal product releases ... before the resource manager officially shipped to customers. old email with reference: http://www.garlic.com/~lynn/2006w.html#email750430 i've made reference before to AT&T longlines signing some sort of agreement and also getting a copy of the enhanced code (even prior to the internal package release mentioned in the above referenced email). part of the issue was that nearly a decade later, the national marketing rep for longlines tracked me down and wanted help with the customer. Longlines had continued to run the "custom" kernel that had been supplied them ... and over the years moving it to newer and newer processors. There was nearly two orders of magnitude difference between the slowest machine that the software ran on (at the time the longlines initially obtained the software) and the fastest machine that longlines was running (at the time of the later contact). the "problem" was that the base kernel software originally given to longlines didn't have multiprocessor support. at the time I was contacted, the marketing team wanted to sell the customer a high-end multiprocessor machine ... which would would require migration to a (current) multiprocessor kernel and the customer had all these modifications (in-use) ... that weren't in the standard kernel. and making the issue somewhat more complex was that "OCO" (object code only) policy had been announced by that time ... recent post/reference http://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits? misc. past posts mentioning the longlines situation: http://www.garlic.com/~lynn/95.html#14 characters http://www.garlic.com/~lynn/96.html#35 Mainframes & Unix (and TPF) http://www.garlic.com/~lynn/97.html#15 OSes commerical, history http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century) http://www.garlic.com/~lynn/2000b.html#74 Scheduling aircraft landings at London Heathrow http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.) http://www.garlic.com/~lynn/2001f.html#3 Oldest program you've written, and still in use? http://www.garlic.com/~lynn/2001g.html#52 Compaq kills Alpha http://www.garlic.com/~lynn/2002.html#4 Buffer overflow http://www.garlic.com/~lynn/2002.html#11 The demise of compaq http://www.garlic.com/~lynn/2002b.html#62 TOPS-10 logins (Was Re: HP-2000F - want to know more about it) http://www.garlic.com/~lynn/2002c.html#11 OS Workloads : Interactive etc http://www.garlic.com/~lynn/2002i.html#32 IBM was: CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002k.html#66 OT (sort-of) - Does it take math skills to do data processing ? http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958? http://www.garlic.com/~lynn/2003.html#17 vax6k.openecs.org rebirth http://www.garlic.com/~lynn/2003d.html#46 unix http://www.garlic.com/~lynn/2003j.html#76 1950s AT&T/IBM lack of collaboration? http://www.garlic.com/~lynn/2003k.html#4 1950s AT&T/IBM lack of collaboration? http://www.garlic.com/~lynn/2003n.html#25 Are there any authentication algorithms with runtime changeable http://www.garlic.com/~lynn/2003p.html#23 1960s images of IBM 360 mainframes http://www.garlic.com/~lynn/2004.html#35 40th anniversary of IBM System/360 on 7 Apr 2004 http://www.garlic.com/~lynn/2004e.html#32 The attack of the killer mainframes http://www.garlic.com/~lynn/2004m.html#58 Shipwrecks http://www.garlic.com/~lynn/2005o.html#25 auto reIPL http://www.garlic.com/~lynn/2005p.html#31 z/VM performance http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor http://www.garlic.com/~lynn/2006o.html#36 Metroliner telephone article http://www.garlic.com/~lynn/2007d.html#55 Is computer history taugh now?
From: jmfbahciv on 6 Apr 2007 06:27 In article <mddhcru5xde.fsf(a)panix5.panix.com>, Rich Alderson <news(a)alderson.users.panix.com> wrote: >jmfbahciv(a)aol.com writes: > >> Our attitude was to provide a documented way to query the system both >> software and hardware. If there is disagreement, we wanted to know about it. >> It was called a sanity check. Please not that ITS, TOPS-20, TOPS-10, and >> something else OSes each have a value assigned to them. Any software could >> write a UUO asking the system which OS it thought it was running. Then the >> code could then branch to the appropriate section of code that knew how to >> interface with the returned OS. This was a design feature and allowed any >> app code to interface with any PDP-10 OS without rebuilding. > >That's software. > >> I don't know if anybody wrote code that used this feature. > >Yes, people did, and do. And I mean besides me. > >On the hardware side, there are bits of code in the beginning of several of the >diagnostics Oh! Of course! Stupid me...diags. > that determine what hardware platform is under test, for example by >checking the result of > > MOVE 1,[-2,,777777] > AOBJN 1,.+1 > SKIPE 1 > <branch to code for KA-10 processor> > >since the KA-10 actually adds 1,,1 to the AC so that the carry out of the right >half propagates to the left. > >There are programmatic ways to detect the Model 166 processor (PDP-6), the >KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume that there >were checks for various Foonly and Systems Concepts boxen. There was also a need to put the setting in software, too. Imagine a development shop that has four OS development projects going on at the same time and one person is working on all four. It makes interesting problems if the developer has to have stand-alone packs to do the development. /BAH
From: jmfbahciv on 6 Apr 2007 06:36 In article <m3lkh6eamk.fsf(a)garlic.com>, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: > >Rich Alderson <news(a)alderson.users.panix.com> writes: >> Yes, people did, and do. And I mean besides me. >> >> On the hardware side, there are bits of code in the beginning of several of the >> diagnostics that determine what hardware platform is under test, for example by >> checking the result of >> >> MOVE 1,[-2,,777777] >> AOBJN 1,.+1 >> SKIPE 1 >> <branch to code for KA-10 processor> >> >> since the KA-10 actually adds 1,,1 to the AC so that the carry out of the right >> half propagates to the left. >> >> There are programmatic ways to detect the Model 166 processor (PDP-6), >> the KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume >> that there were checks for various Foonly and Systems Concepts boxen. > >370 introduced store cpuid ... which included processor model number as >well as processor serial number. How did you ship the software if it had numbers "hardwired" in the software? We had to be generic with all the specifics because our customers also had multiple systems running software built from the same distribution tapes. > >current description of the instruction >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/10.58?SHE LF=DZ9ZBK03&DT=20040504121320 > >the problem was then you still needed (potentially new) software that >had the processor specific logic > >one of the things that vm370 had was a table of processor cpuids and >associated values. when i was doing with dynamic adaptive control >algorithms and the resource manager product ... was to be able to have >completely dynamic adaptive values ... w/o requiring a (software lookup) >table of all possible cpuids (with corresponding values). Do you and I have different defintion of processor ID? Each of our processors had its own number assigned to it. (yea, yea, the KS was different and that caused tonnes of trouble so I dismiss it). > >in theory the idea was that i could ship the resource manager ... and >it could adapt to whatever processor and resources there were >.... regardless of what happened ... (in theory) w/o requiring >changes/updates to the software (and/or processor tables) ... even if >new processor models subsequently came out. We shipped [what I think of as] a CPU driver. If CPU-dependent code was anywhere else it was put under the appropriate feature test switch KA, KI, KL, KS. One of the goals was to make it possible for most applications to not have a need to know about processors. With the exception of KA-floating point instructions, I can't think of anything else that would cause app troubles. > >I had done packaged internal product releases ... before the resource >manager officially shipped to customers. old email with reference: >http://www.garlic.com/~lynn/2006w.html#email750430 > >i've made reference before to AT&T longlines signing some sort of >agreement and also getting a copy of the enhanced code (even prior >to the internal package release mentioned in the above referenced >email). > >part of the issue was that nearly a decade later, the national marketing >rep for longlines tracked me down and wanted help with the >customer. Longlines had continued to run the "custom" kernel that had >been supplied them ... and over the years moving it to newer and newer >processors. There was nearly two orders of magnitude difference between >the slowest machine that the software ran on (at the time the longlines >initially obtained the software) and the fastest machine that longlines >was running (at the time of the later contact). > >the "problem" was that the base kernel software originally given to >longlines didn't have multiprocessor support. at the time I was >contacted, the marketing team wanted to sell the customer a high-end >multiprocessor machine ... which would would require migration to a >(current) multiprocessor kernel and the customer had all these >modifications (in-use) ... that weren't in the standard kernel. > >and making the issue somewhat more complex was that "OCO" (object code only) >policy had been announced by that time ... recent post/reference >http://www.garlic.com/~lynn/2007f.html#67 The Perfect Computer - 36 bits? Oh! That must have caused a bit headache. <snip ref list> /BAH
From: Del Cecchi on 6 Apr 2007 09:32 Anne & Lynn Wheeler wrote: >>Actually boeblingen was paired in some way with Sifi (singlefingen or >>something like that) > > > Sindelfingen & Boeblingen ... that is somewhat like saying the old > endicott manufacturing plant downtown was paired with the > endicott/glendale lab. > > Boeblingen wiki page > http://en.wikipedia.org/wiki/Boeblingen > > from above: > > Böblingen/Sindelfingen can be called a center of both automobile and > computer industries. Daimler-Chrysler develops and manufactures its > Mercedes brand of luxury cars here. > > .... snip ... > > Sindelfingen wiki page > http://en.wikipedia.org/wiki/Sindelfingen > > from above: > > Neighboring towns and cities: Böblingen, Stuttgart, Leonberg. Note that > there is no gap between Böblingen and Sindelfingen. > > .... snip ... > > earlier than these series of trips in the mid-70s > http://www.garlic.com/~lynn/2007g.html#42 1960s: IBM mgmt mistrust of SLT for ICs? > http://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of SLT for ICs? > http://www.garlic.com/~lynn/2007g.html#46 1960s: IBM mgmt mistrust of SLT for ICs? > > starting in the very early 70s ... i got to go around doing CP/VM > consulting and/or installs at various places around the world > .... including some number of HONE clone installs (online interactive > support for world-wide sales, marketing and field people) > http://www.garlic.com/~lynn/subtopic.html#hone > > as well as visits to Boeblingen lab. Very early 70s trips to the > Boeblingen lab ... was before a lot of "americanization" (didn't find > all the other american/computer companies, american hotels, etc, that > started showing up in the 80s). they put me up in a small 3-4 story > "business traveler" hotel in Sindelfingen where nobody spoke English and > I had to get by on very bad college German. But they were considered separate sites, like POK and EF or POK and Kingston, at least in the part of IBM I was familiar with. del -- Del Cecchi "This post is my own and doesn�t necessarily represent IBM�s positions, strategies or opinions.�
From: krw on 6 Apr 2007 10:25
In article <ev57r8$8qk_001(a)s875.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <m3lkh6eamk.fsf(a)garlic.com>, > Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: <snip> > >370 introduced store cpuid ... which included processor model number as > >well as processor serial number. > > How did you ship the software if it had numbers "hardwired" in the > software? We had to be generic with all the specifics because > our customers also had multiple systems running software built > from the same distribution tapes. Hardware. > > > > >current description of the instruction > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/10.58?SHE > LF=DZ9ZBK03&DT=20040504121320 > > > >the problem was then you still needed (potentially new) software that > >had the processor specific logic > > > >one of the things that vm370 had was a table of processor cpuids and > >associated values. when i was doing with dynamic adaptive control > >algorithms and the resource manager product ... was to be able to have > >completely dynamic adaptive values ... w/o requiring a (software lookup) > >table of all possible cpuids (with corresponding values). > > Do you and I have different defintion of processor ID? Each > of our processors had its own number assigned to it. (yea, yea, > the KS was different and that caused tonnes of trouble so I dismiss > it). Same. <snip> -- Keith |