From: Anne & Lynn Wheeler on

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
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
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
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
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