🚀 go-pugleaf

In article <7HU77.9333$TM5.9...@typhoon.southeast.rr.com>, 
d.h...@computer.org (Daniel House) wrote:

> Having recently discovered a salvage case, I'm interested in this 
> system.
> Is there any online information about it? Google/image searches came up 
> very
> light.  I located Vol.6, No.2 of the IBM Systems Journal (from 1967)
> describing the system and programs for it, but I'd like more, including
> pictures if there are any to be found. There are only a few drawings in 
> the
> SJ.
> 
> Thanks, Dan House
> 
> 
> 
I recollect reading that the 9020 was, or at least started as a 
multiprocessor version of the S/360 Model 40. No doubt there were changes 
and additions to the instruction set. This would have been very easy, as 
the Model 40, and most of the 360 line at that time, had microprogram 
control. In the case of the model 40 (and 30, following the abandonment of 
another technology), the microprogram was stored in a transformer 
read-only memory whose physical design (at least) allowed easy changes.

It would be interesting to learn what changes other than the mechanics of 
shared memory were made.

Mike Kingston

"Michael J Kingston" <mikeki...@cix.co.uk> wrote in message
news:memo.20010727094436.36989A@mikekingston.compulink.co.uk...
> In article <7HU77.9333$TM5.9...@typhoon.southeast.rr.com>,
> d.h...@computer.org (Daniel House) wrote:
>
> I recollect reading that the 9020 was, or at least started as a
> multiprocessor version of the S/360 Model 40. No doubt there were changes
> and additions to the instruction set. This would have been very easy, as
> the Model 40, and most of the 360 line at that time, had microprogram
> control. In the case of the model 40 (and 30, following the abandonment of
> another technology), the microprogram was stored in a transformer
> read-only memory whose physical design (at least) allowed easy changes.
>
> It would be interesting to learn what changes other than the mechanics of
> shared memory were made.
>
> Mike Kingston

According to the IBM System Journal, Vol.6, No.2, Figure 1, p.82, the 9020
complex had 3 "computing elements," 3 "IO control elements," and lots (9) of
shared storage elements.  There is discussion in the text of flexibility in
configuration (and dynamic reconfiguration--required by FAA availability
goals).  The Journal discusses a shared configuration register used to
inform each element of its status in the configuration.  Other changes
discussed include a different set of PSW bits and IO addressing.

>From the only pictures I have seen, the control panel for a computing
element looks amazingly like the operator control panel of a System 360
Model 65. The 9020 control panel for an IO control element looks, again
amazingly, like the operator control panel from a System 360 Model 50. The
Journal doesn't mention these amazing similarities, nor did I see mention of
specific 360 models.

On Fri, 27 Jul 2001 08:44:00, mikeki...@cix.co.uk (Michael J Kingston) 
wrote:

> I recollect reading that the 9020 was, or at least started as a 
> multiprocessor version of the S/360 Model 40.

50 and 65.

> No doubt there were changes 
> and additions to the instruction set.

Principally to manage the multiprocessor configuration.  Test Config, Set 
Config, that sort of thing.  The 9020E, which was used as a display processor,
had some additional instructions but I forget what they were.  Line intercept 
sort of things, to determine what was outside the view of the display, I 
think.  Maybe some special block moves.  The E also had display refresh 
memory.

There were also "Peripheral Adapter Modules" to interface to teletypes, radar 
digitizers (12-bit bytes), and like that.

A typical configuration was three 65s, three 50s (serving as I/O processors), 
and three PAMs.  Plus a display system, either Raytheon or a 9020E, with 
Raytheon consoles.

> It would be interesting to learn what changes other than the mechanics of 
> shared memory were made.
  
The System Journal article ought to say.  The multiprocessor was hardware 
configured into online and offline systems.  The online system did air traffic
control and the offline system did offline kinds of things.  Offline hardware 
could not interfere with nor reconfigure the online.  When the online system 
detected a failure, it configured out the failed unit and brought in a unit 
from the offline system.

All that hardware has been replaced, but the software, which first went 
operational in the early 70s, is still in use but now in duplexed 370s instead
of multiprocessor 360s.  The multiprocessor was always a rotten idea, since 
there wasn't enough hardware to configure two complete systems.  This was done
supposedly for efficiency, but the consequence was that there was no way to 
test a new software delivery except to take the system down.  We told them 
that but the guy in charge wouldn't listen.

-- 
    John Varela

On Fri, 27 Jul 2001 13:20:43, "Daniel House" <d.h...@computer.org> wrote:

> lots (9) of shared storage elements.

Oops.  I forgot to mention them.  Can't run a system with no memory, can you?

Note the original system had no disks.  Guy in charge distrusted "rotating 
memory"--he had experience with drums in the early 50s.  I wrote a report 
around 1965 that led to the addition of disks.

> From the only pictures I have seen, the control panel for a computing
> element looks amazingly like the operator control panel of a System 360
> Model 65. The 9020 control panel for an IO control element looks, again
> amazingly, like the operator control panel from a System 360 Model 50.

This was not a coincidence.

There were also all-Model 50 systems at the smaller installations.

-- 
    John Varela

"John Varela" <jav...@earthlink.net> wrote in message
news:vd2NzVOTNb7v-pn2-vdi55dTSr5Cy@dialup-63.208.164.65.Dial1.Washington2.Le
vel3.net...
> On Fri, 27 Jul 2001 08:44:00, mikeki...@cix.co.uk (Michael J Kingston)
> wrote:
>
> > I recollect reading that the 9020 was, or at least started as a
> > multiprocessor version of the S/360 Model 40.
>
> 50 and 65.

That matches with the pictures--50 and 65 panels.

>
> > No doubt there were changes
> > and additions to the instruction set.
>
> Principally to manage the multiprocessor configuration.  Test Config, Set
> Config, that sort of thing.  The 9020E, which was used as a display
processor,
> had some additional instructions but I forget what they were.  Line
intercept
> sort of things, to determine what was outside the view of the display, I
> think.  Maybe some special block moves.  The E also had display refresh
> memory.
>

Was Test and Set invented for this purpose? Several articles in
the System Journal (Vol.6, No.2, 1967) mention that instruction repeatedly.
It surprised me--I thought TS had to be older than that.

One last question about this machine (I promise--for now)... Was there
a separate principles of operations published for it, since it introduced
a number of instructions (whether or not TS)?

Regards, Dan House

On Sun, 29 Jul 2001 13:50:07, "Daniel House" <d.h...@computer.org> wrote:

> Was Test and Set invented for this purpose?

I believe yes.

> It surprised me--I thought TS had to be older than that.

I don't think so.
 
> One last question about this machine (I promise--for now)... Was there
> a separate principles of operations published for it, since it introduced
> a number of instructions (whether or not TS)?
 
Sorry, I don't recall.

-- 
    John Varela

John Varela wrote, in
<vd2NzVOTNb7v-p...@dialup-63.208.164.94.Dial1.Washington2.Level3.net>:

> On Sun, 29 Jul 2001 13:50:07, "Daniel House" <d.h...@computer.org> wrote:
> 
> > Was Test and Set invented for this purpose?
> 
> I believe yes.
> 
> > It surprised me--I thought TS had to be older than that.
> 
> I don't think so.

My Green Card GX20-1703-9 has TS on it.  Anyone know what date the -9
represents?
-- 
Nick Spalding

Nick Spalding <spal...@iol.ie> writes:
> 
> My Green Card GX20-1703-9 has TS on it.  Anyone know what date the -9
> represents?

nope, but it is also in my -7. it seems to have been in all the
original 360s.

I did alta-vista search on 9020 and came up with a couple hits.

http://www.faa.gov/apa/speeches/aoa/FWINGS.htm

Automation of en route ATC began with the installation of IBM's
prototype 9020 system at the Jacksonville Center in 1967. Designed to
provide automated flight data processing and radar tracking at all en
route centers and major terminals, this was the most complex computer
application ever undertaken up to that time. Its half million commands
required more than twice the amount of memory originally planned, a
complication which caused the project to fall behind schedule. The
installation at all 22 en route centers was not completed until the
end of the 1970s.

http://www.aero-space.nasa.gov/library/ch1.htm

Automation of en route ATC began with the installation of IBM's
prototype 9020 system at the Jacksonville Center in 1967. The system
was designed to provide automated flight data processing and radar
tracking at all en route centers and major terminals. The system was
delivered behind schedule, which created significant frustration
within FAA, the aviation community and IBM. The system would not be in
place at all 22 en route centers until the end of the 1970s. However,
indicative of the complex nature of automating the en route
environment, the 9020 system proved to be the most complex computer
application in the world at the time, with more than half a million
commands. When the program was completed, IBM had more than doubled
the amount of memory the company had first thought the program would
require.

http://api.hq.faa.gov/96sp-fin.htm

http://catless.ncl.ac.uk/Risks/5.67.html

http://home.columbus.rr.com/lusch/index.html

HOCSR (Host and Oceanic Computer Replacement System)
http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm

A system-wide upgrade completed in 1999 at the 20 Air Route Traffic
Control Centers. It is the heart of the system in that it receives,
processes, coordinates, distributes and tracks information on aircraft
movements throughout domestic and oceanic airspace. It replaced the
HOST computers that ten years earlier had replaced the old IBM 9020
computers. [Back]

HOST

A system-wide computer upgrade completed in 1989 at the 20 Air Route
Traffic Control Centers. HOST replaced the old IBM 9020 computers. It has
since been superseded by HOCSR. [Back]

http://www.faa.gov/aua/ipt_prod/enroute/hocsrfct.htm

--
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/

jav...@earthlink.net (John Varela) writes:

>On Sun, 29 Jul 2001 13:50:07, "Daniel House" <d.h...@computer.org> wrote:

>> Was Test and Set invented for this purpose?

>I believe yes.

>> It surprised me--I thought TS had to be older than that.

>I don't think so.

John, I think I'll disagree with you here; my recollection (not parity-
checked!) is that TS was part of the original design.  It certainly
was in the original PoO that I worked with in the mid-'60s, although
I do recall at the time being unable to find anyone who could produce
a credible suggestion for any siuation in which it could be used.

If TS was added to support the ATC requirements, why was it the only
one of those specialized opcodes to make it into the standard PoO?
(Perhaps because it alone did not rely on any particular data
structure that was unique to the FAA software?)

Looking back at what I just wrote, I think I should add that John worked
on the machines, but the only time I ever got up close and personal
to a 9020 system was an impromptu tour I was given of the system
at ZTL one day when I flew down to Atlanta with an Air Force officer
investigating a fatal military airplane crash.  After the interviews
with the controllers were finished I had a chance to look around the computer
room while directly filing an IFR flight plan (which was especially
convenient since I totally bypassed the IFR plan reservation system
that was still in place after the FAA controller's strike).

Joe Morris

jcmo...@mitre.org (Joe Morris) writes:

> If TS was added to support the ATC requirements, why was it the only
> one of those specialized opcodes to make it into the standard PoO?
> (Perhaps because it alone did not rely on any particular data
> structure that was unique to the FAA software?)

TS was used for multiprocessing support in both 360m65 (os/360) and
360m67 (tss/360 & cp/67). Both predated the ATC work (although ATC may
have taken advantage of some of the 360m65 multiprocessor work).

my understanding was that the 65 & 67 were originally going to be
360m60 and 360m62 ... but somewhere along the line, there was an
upgrade to the memory technology (to 750ns) and the numbers got
changed.

as an aside, the work at cambridge on fine grain locking with cp/67
directly led to compare&swap instruction in 370 (in fact, "CAS" are
the person's initials that did most of the work at cambridge, and
the trick was to come up with a mnemonic that was his initials;
it got modified to CS & CDS tho).

random refs:
http://www.garlic.com/~lynn/subtopic.html#smp

-- 
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/ 

On Mon, 30 Jul 2001 12:24:07, Anne & Lynn Wheeler <ly...@garlic.com> wrote:

> I did alta-vista search on 9020 and came up with a couple hits.
> 
> http://www.faa.gov/apa/speeches/aoa/FWINGS.htm
 
> Automation of en route ATC began with the installation of IBM's
> prototype 9020 system at the Jacksonville Center in 1967.

I was traveling to ZJX weekly during testing circa 1968.  The 9020 was not a 
prototype.  The *system* of which the 9020 was a part was sort of a prototype.
 I say "sort of" because Raytheon was having difficulty delivering the display
system, so we were using an entirely different kludge of Haseltine and 
Raytheon analog display gear.

The Jacksonville system had a lot of problems, foremost being an inability to 
process a second's worth of radar data every second.  JAX had four radars at 
the time, but we had only two digitizers because the Air Force requisitioned 
two of them for use in Viet Nam.  The real-time problem was a consequence of 
poor software design and also of writing the radar processing software in 
JOVIAL.  In the redesign, some of the processing was moved into the I/O 
Control Units (360/50s) and all of it was rewritten in BAL.  Actually, what 
IBM did was to take the BAL code produced by the JOVIAL compiler and hand 
optimize it.  Thereafter and until this very day it has been maintained in 
BAL.

Besides learning definitively that JOVIAL was unsuited to real time radar data
processing, the main thing we learned in JAX was the deficiencies in our 
design for flight plan processing and posting. 

> Designed to
> provide automated flight data processing and radar tracking at all en
> route centers and major terminals, this was the most complex computer
> application ever undertaken up to that time.

Maybe.

> Its half million commands
> required more than twice the amount of memory originally planned, a
> complication which caused the project to fall behind schedule. The

It wasn't the size of the code.  It was Raytheon's display system problems, 
the radar processing software design problems (IBM's fault) and the flight 
data processing specification deficiencies (MITRE and FAA's fault) noted 
above.  We really did learn a lot at JAX.

> installation at all 22 en route centers was not completed until the
> end of the 1970s.

Much earlier.  The 9020s were all installed by about 1968.  The software was 
fielded in a series of packages:  flight data processing without real-time 
interaction from the sectors (this was called "CUEless"), real-time flight 
data processing, basic radar processing, and the final system.  The last 
Center went operational around 1973.  If anyone really cares I could probably 
find the actual date.
 
> http://www.aero-space.nasa.gov/library/ch1.htm
> 
> Automation of en route ATC began with the installation of IBM's
> prototype 9020 system at the Jacksonville Center in 1967. The system
> was designed to provide automated flight data processing and radar
> tracking at all en route centers and major terminals. The system was

Wrong.  The 9020 was part of the system called NAS (National Airspace System) 
En Route Stage A.  It was installed only in Air Route Traffic Control Centers.
 The terminal system was an entirely different system made by Univac.  There 
were grandiose plans for a Stage B but it never happened.  Oh well.

> delivered behind schedule, which created significant frustration
> within FAA, the aviation community and IBM. The system would not be in
> place at all 22 en route centers until the end of the 1970s. However,

Wrong again about the date.

> indicative of the complex nature of automating the en route
> environment, the 9020 system proved to be the most complex computer
> application in the world at the time, with more than half a million
> commands. When the program was completed, IBM had more than doubled
> the amount of memory the company had first thought the program would
> require.

These guys must be getting their misinformation from a common source.
 
-- 
    John Varela

On Mon, 30 Jul 2001 13:43:51, jcmo...@mitre.org (Joe Morris) wrote:

> John, I think I'll disagree with you here; my recollection (not parity-
> checked!) is that TS was part of the original design.  It certainly
> was in the original PoO that I worked with in the mid-'60s, although
> I do recall at the time being unable to find anyone who could produce
> a credible suggestion for any siuation in which it could be used.

I have no idea what came first or why.  But this is the chronology of the 
9020:
 
We (MITRE) wrote the specification for the Central Computer Complex (the 
official name of the 9020, commonly referred to as the CCC [1]) in the spring 
and summer of 1963.  The spec pretty much demanded a multiprocessor because 
the guy in charge at FAA had fallen in love with the Burroughs computer used 
in BUIC. (What was it called?  D850?)

The contract was awarded to IBM in the summer of 1964 and the first one, a 
9020A all 360/50 system, was delivered to the National Aviation Facilities 
Experimental Center (NAFEC) near Atlantic City in the summer of 1965, and 
software development started.

[1]  I named the CCC.  It happened this way.  In February of 1963 we started 
work on the spec for a computer for the new system.  We quickly realized we 
had a problem discussing it because we didn't have a name for it.  There was a
meeting in Howard Kirshner's office in MITRE/Bedford to decide on a name.  
Various options were kicked around but none made a satisfying acronym.  My 
boss was politically very liberal, a declared socialist, ACLU member, etc., 
while I was a Goldwater conservative.  We regularly good-naturedly sparred and
needled one another about politics.  Suddenly I had an inspiration, looked my 
boss in the eye, and said, "If we name it the Central Computer Complex then we
could call it the CCC."  He immediately picked up on the joke (the Civilian 
Conservation Corps was a Roosevelt New Deal program) and supported my 
suggestion.  We carried the day and the CCC was in due course followed by the 
CDC, the DCC, the ACC, and the TCCC.

-- 
    John Varela

Nick Spalding wrote:
> 

> 
> My Green Card GX20-1703-9 has TS on it.  Anyone know what date the -9
> represents?
> --

Mine is an X20-1703-6, also with TS. No date information, though.


The Original Bell and Newell gives a reference to a 1964 paper (Falkoff,
Iverson, and Sussenguth, A Formal Description of System/360 , IBM System
Journal Vol 3 No 3 pp198-261), so it seems TS dates from the beginning
of the 360, if not before. Perhaps that paper cites an earlier use.

--brian

On Tue, 31 Jul 2001 00:56:11, jav...@earthlink.net (John Varela) wrote:

	(Responding to my own post.)

> The contract was awarded to IBM in the summer of 1964 and the first one, a 
> 9020A all 360/50 system, was delivered to the National Aviation Facilities 
> Experimental Center (NAFEC) near Atlantic City in the summer of 1965, and 
> software development started.

I should have mentioned that, when the system was delivered in the summer of 
1965, it came with its operating system, including multiprocessing fault 
detection and recovery.  As best I can recall, there were never any problems 
with the multiprocessing features of the OS.

-- 
    John Varela

In article <9k3oan$t35$1...@top.mitre.org>, jcmo...@mitre.org wrote:

>John, I think I'll disagree with you here; my recollection (not parity-
>checked!) is that TS was part of the original design.  It certainly
>was in the original PoO that I worked with in the mid-'60s, although
>I do recall at the time being unable to find anyone who could produce
>a credible suggestion for any siuation in which it could be used.

I remember using TS for inter-partition locking in DOS/360, which had
no equivalent of ENQ/DEQ (mutex, in non-OS/360-speak).

I always assumed TS was part of the S/360 definition at the start, but
just noticed that there's no TS (X'93') in the opcode table published
in an early journal paper about S/360:

  G. M. Amdahl, G. A. Blaauw, F. P. Brooks, Jr., "Architecture of the
  IBM System/360", IBM Journal of R and D, 8:2, 1964, pp. 32-34.

There's a scanned PDF of this paper (reprinted in IBM JR&D 44:1-2) at

  http://www.research.ibm.com/journal/rd/441/amdahl.pdf

But TS is in an instruction table in an IBM Systems Journal article by
two of the same authors (Blauuw and Brooks), also published in 1964.

Since the first 360 customer shipment was a year after the April 1964
announcement, evidently the TS addition to the architecture happenned
after announcement but before any customers got their hands on a
machine.

How soon after announcment was the first rev of the PoO published?

- Jim Saum

In
<vd2NzVOTNb7v-p...@dialup-63.208.164.65.Dial1.Washington2.Level3.net>,
on 07/27/01 
   at 08:17 PM, jav...@earthlink.net (John Varela) said:

>> I recollect reading that the 9020 was, or at least started as a 
>> multiprocessor version of the S/360 Model 40.

>50 and 65.

Initially Mod 50.  The 65 version came later.
 
--
 Julian Thomas: jt . jt-mj @ net  http://jt-mj.net
 remove letter a for email (or switch . and @)
 In the beautiful Finger Lakes Wine Country of New York State!
 Boardmember of POSSI.org - Phoenix OS/2 Society, Inc 
http://www.possi.org
 -- --
 2 + 2 = 5 for extremely large values of 2.

On Wed, 1 Aug 2001 16:03:07, ja...@jata-mj.net (Julian Thomas) wrote:

> >50 and 65.
>  
> Initially Mod 50.  The 65 version came later.

IBM's proposal included models 9020A, B, C, and D.  The A was all model 50s, 
the D was 50s and 65s.  I forget what the B and C were; none were bought.  
Maybe they included slow core memory; I know that was in the proposal 
somewhere.

You are correct that the first purchases were As, but as the software grew 
some As were changed to Ds before delivery, under the original contract 
provisions.

The 9020E was added to the series a couple of years later, when Raytheon 
started having trouble developing the display system.  IBM was contracted to 
develop the 9020E hardware and software to replace the Raytheon central 
equipment and Sanders was contracted to build a substitute radar display 
console.  In the upshot, Raytheon succeeded.  The Sanders console never went 
into production for FAA, but I think they sold some spin-offs commercially.  
9020Es were installed in about a half dozen of the busiest Centers; the others
had all-Raytheon display systems.

-- 
    John Varela

In
<vd2NzVOTNb7v-p...@dialup-64.157.62.31.Dial1.Washington1.Level3.net>,
on 08/02/01 
   at 12:17 AM, jav...@earthlink.net (John Varela) said:

>You are correct that the first purchases were As, but as the software
>grew  some As were changed to Ds before delivery, under the original
>contract  provisions.

Also, the mod 50 version (A) was the first to be developed and tested.

My favorite 9020 story was about the day of the great blackout (was this
1965?) when earlier that day they had hooked up the UPS feature (it had a
different name then), tested it, and then disconnected it again - before
the blackout hit Poughkeepsie.
 
--
 Julian Thomas: jt . jt-mj @ net  http://jt-mj.net
 remove letter a for email (or switch . and @)
 In the beautiful Finger Lakes Wine Country of New York State!
 Boardmember of POSSI.org - Phoenix OS/2 Society, Inc 
http://www.possi.org
 -- --
    Uncle Ed's Rule of Thumb:  Never use your thumb for a rule.
    You'll either hit it with a hammer or get a splinter in it.

On Sun, 5 Aug 2001 20:53:49, ja...@jata-mj.net (Julian Thomas) wrote:

> My favorite 9020 story was about the day of the great blackout (was this
> 1965?) when earlier that day they had hooked up the UPS feature (it had a
> different name then), tested it, and then disconnected it again - before
> the blackout hit Poughkeepsie.
 
I don't know what incident you're referring to.  The one I know of occurred at
the Denver ARTCC in Longmont, CO.  They were running system tests, which 
involved a lot more than the 9020: specifically, some 20 or 30 Raytheon Plan 
View Display radar consoles and their central equipment (I forget if that was 
a 9020E or Raytheon) as well as sector terminals (Controller Update Equipment 
= CUE), printers, etc.  This would have been around 1970.

One night when they were running a test, the headquarters guy on site, a 
fellow named Chick Wright, decided to test the UPS, so he threw the system off
of local power.  The batteries picked up the load while the diesels fired up 
and took over.  So everything worked except for one thing: the back EMF from 
the sudden removal of all that load blacked out the entire town of Longmont.

At least, that's the story that came back East.

-- 
    John Varela

John, This has been a wealth of great information on the 9020 system(s).
How is your way-back machine? At the following URL is a picture of a 9020E
salvage case (it is only the op ctl panel for one of the 3 computing
elements--very clearly a 360/65 derivative):

http://home.nc.rr.com/deh/GALLERY/9020E_2.JPG

About 1/4 the way down the left hand side is a square hole.  It's where a
lighted button went.  Any idea what the button was (vainly hoping I can find
the correctly labeled button somewhere)?  I don't think it was "Power On",
as there is a switch on the lower right quadrant labeled that.

Regards, Dan


"John Varela" <jav...@earthlink.net> wrote in message
news:vd2NzVOTNb7v-pn2-PBomleKh1jJS@dialup-209.244.224.188.Dial1.Washington1.
Level3.net...
> On Tue, 31 Jul 2001 00:56:11, jav...@earthlink.net (John Varela) wrote:
>
> (Responding to my own post.)
>
> > The contract was awarded to IBM in the summer of 1964 and the first one,
a
> > 9020A all 360/50 system, was delivered to the National Aviation
Facilities
> > Experimental Center (NAFEC) near Atlantic City in the summer of 1965,
and
> > software development started.
>
> I should have mentioned that, when the system was delivered in the summer
of
> 1965, it came with its operating system, including multiprocessing fault
> detection and recovery.  As best I can recall, there were never any
problems
> with the multiprocessing features of the OS.
>
> --
>     John Varela

On Wed, 8 Aug 2001 22:32:42, "Daniel House" <d.h...@computer.org> wrote:

> About 1/4 the way down the left hand side is a square hole.  It's where a
> lighted button went.  Any idea what the button was (vainly hoping I can find
> the correctly labeled button somewhere)?

I have no idea.  I never worked directly on or with the 9020E.  I've forwarded
your question to someone who did, but I doubt he'll recall any details of the 
control panel this many years later.

-- 
    John Varela

"Daniel House" <d.h...@computer.org> writes:

>About 1/4 the way down the left hand side is a square hole.  It's where a
>lighted button went.  Any idea what the button was (vainly hoping I can find
>the correctly labeled button somewhere)?  I don't think it was "Power On",
>as there is a switch on the lower right quadrant labeled that.

My vague recollection is that the left-middle panels on the plain-vanilla
/65 were blank; I dug out my ancient FETOM for the box last night, but
the only picture of the front panel in it is from a very oblique angle
and it appears to be empty.

One possibility would be that the lights and buttons on those panels
were for the backup batteries that were unique to the 9020.  What are
the legends on the indicators and switches below the empty socket?

Also...on the lower left front panel there is a row of lever switches.
On a normal 360/65 the rightmost switch (just above and to the right
of the RATE switch, which is over the green START button) was unused,
and at many shops bogus legends were added (such as "EXTRA SUGAR").
Is there a legend on your panel?  I can't see it clearly in the picture;
the upper legend appears to be blank but the switch is in the down
position and obscures the lower legend.

Joe Morris

"Joe Morris" <jcmo...@mitre.org> wrote in message
news:9l0m6j$la3$1@top.mitre.org...
>
> My vague recollection is that the left-middle panels on the plain-vanilla
> /65 were blank; I dug out my ancient FETOM for the box last night, but
> the only picture of the front panel in it is from a very oblique angle
> and it appears to be empty.
>

I have a picture of a regular 360/65 and you are right--that frame of the
vanilla panel is empty.

> One possibility would be that the lights and buttons on those panels
> were for the backup batteries that were unique to the 9020.  What are
> the legends on the indicators and switches below the empty socket?
>

The switch directly below the empty socket says "Test".  The indicators are
in a painted box labeled "State" and the indicators themselves are labeled
"Three", "Two", "One", and "Zero"  (no Blast-Off).

> Also...on the lower left front panel there is a row of lever switches.
> On a normal 360/65 the rightmost switch (just above and to the right
> of the RATE switch, which is over the green START button) was unused,
> and at many shops bogus legends were added (such as "EXTRA SUGAR").
> Is there a legend on your panel?  I can't see it clearly in the picture;
> the upper legend appears to be blank but the switch is in the down
> position and obscures the lower legend.

The rightmost switch above the Rate dial has no legend but two switch
positions labeled: "L-Reg" and "M-Reg"

Thanks for any info -- it's tough to find working way-back machines.  Dan




> Joe Morris

	(responding to my own post)

On Thu, 9 Aug 2001 23:17:20, jav...@earthlink.net (John Varela) wrote:

> On Wed, 8 Aug 2001 22:32:42, "Daniel House" <d.h...@computer.org> wrote:
> 
> > About 1/4 the way down the left hand side is a square hole.  It's where a
> > lighted button went.  Any idea what the button was (vainly hoping I can find
> > the correctly labeled button somewhere)?
> 
> I have no idea.  I never worked directly on or with the 9020E.  I've forwarded
> your question to someone who did, but I doubt he'll recall any details of the 
> control panel this many years later.
 
He came back with "I can't answer that one."  He suggested another name, but I
don't have his email address since he joined us over-60 retirees.

-- 
    John Varela

Dear Dan / transatlantic cousins,

I hope I can add my little bit to the shared knowledge in this thread:

> "the 9020E, which was used as a display processor, had some additional
instructions but I forget what they were."

The 9020D and 9020E Compute Elements (CEs as they were always known) were
*identical*; a plug card told the CE whether it was in a D or an E system.
It's just that the *software* used in the 9020D CCC didn't make use of the
instructions that the 9020E DCC used. See below for the additional
instructions.

> "Was there a separate principles of operations published for it, since it
introduced a number of instructions (whether or not TS)?"

Yes - "IBM 9020D and 9020E System Principles of Operation", Form A27-2734-X
(mine is -2, dated June 1st 1971, 627 pages. I'm pretty sure this was the
final version).

> "The last Center went operational around 1973. If anyone really cares I
could probably find the actual date."

There was a 23rd 9020 centre (sorry - center!) at West Drayton in the UK.
The CCC was installed during 1973 and accepted from the FAA on 31st January
1974, though it was a while before it went operational. There were actually
two separate 9020D systems at West Drayton, a Simplex (used like a
mini-NAFEC) and a Triplex - four CEs (S/360-65s) in total. They remained
operational until April 1990 when the UK Host Computer System took over, but
the PAMs remained for much longer. It's a shame the rehost wasn't on to a
9021, a S/390 mainframe! Interestingly, the 9020 designation wasn't used in
the S/390 range.

There are references to both 20 and 22 ARTCCs in this thread. Am I right in
thinking there were 20 ARTCCs + NAFEC + OKC + UK = 23 'centers'?

> "About 1/4 the way down the left hand side is a square hole. It's where a
lighted button went. Any idea what the button was (vainly hoping I can find
the correctly labeled button somewhere)? I don't think it was "Power On", as
there is a switch on the lower right quadrant labeled that."

This was the '360 compatibility mode' button. I recall it was translucent
green and engraved "360" rather than "360 MODE" (p/n 5383203 - I have one
somewhere, perhaps I could JPEG it if you're bent on an accurate
restoration). The pushbutton was backlighted when 360 compatibility mode was
active, which could only be whilst in state 1, 0, or Test in either
Supervisor or Problem mode. When not in 360 mode the CE was in 9020 mode (we
only ever took our CEs out of 9020 mode when running the diagnostic that
checked that 360 mode worked!).

Placing the CE in 360 mode inhibited certain 9020 actions that were not
compatible with IBM System/360 architecture. These were (I could explain the
acronyms if anyone's *really* interested):

1) PSBAR stepping inhibited and LOS can't be sent to an SE.
2) Logical PSBAR cleared and Physical PSBAR set to the value in ATR slot 1.
3) PSA lockout and SE stopped result in checkstop, rather than an interrupt.
4) Bits 16-19 of PSW are part of interrupt code rather than an extension of
the system mask.
5) Only IOCE 1 channels can be used - IOCEs 2 and 3 not usable.
6) Storage protect operates differently. In 9020 mode, storage key = 0 is a
key match.
7) IOCE processor is hardware-stopped when part of a 360 mode system.
8) System IPL and PSW restart can't be used as they force state 3.
9) Certain 9020 op codes became invalid, as follows:

01 SCON - Set Configuration
02 CSS  - Convert and Sort Symbols*
03 CVWL - Convert Weather Lines*
0B DLY  - Delay
0C LI   - Load Identity
0D SATR - Set Address Translation Register
0E IATR - Insert Address Translation Register
0F RPSB - Repack Symbols*
52 LC   - Load Chain*
9A SPCI - Set PCI
A0 SPSB - Store PS Base address
A1 LPSB - Load PS Base address
D8 MVW  - Move Word
   * = Display Instruction, only _used_ in 9020E system.

Also, the 9020 Direct Control feature had extensions to that of regular 360
architecture, but these were not disabled in 360 mode. Direct Control was a
byte-wide bus between CEs that could transfer data by way of RDD (Read
Direct) and WRD (Write Direct) instructions. (I wrote a BAL program running
in the CE that used this port to interface to a PC!)

> "The rightmost switch above the Rate dial has no legend but two switch
positions labeled: "L-Reg" and "M-Reg".

The CE FEMDM, fig 6-1, shows the upper legend for this switch as "IND RLR
1", the lower legend as "INDICATE RLR 1 POSITION 6". The key itself is
labelled "L REG" (up) and "M REG" (down). The photo I have of our CEs shows
that only the lower legend has been applied, though I can't make out the
exact wording (the documentation - whilst generally excellent - doesn't
always reflect reality!). I would have imagined the FAA CEs to be the same -
obviously not.

The function of the switch is - you guessed it - to display either the L or
the M register in roller 1 position 6. The L and M regs were an addition (?)
to standard 360, and were part of the set of 'Display Registers' (L, M, XY,
K, N, Mixer). They were used (exclusively?) by the display instructions
above. There obviously wasn't enough room on the rollers to display all the
necessary information, hence this toggle.

[Set Answermode = Off]

The 9020D/E CEs (360-65s) were referred to as 7201-02s in much of the IBM
documentation, following the standard IBM nomenclature. The Input Output
Compute Elements or IOCEs (360-50s) were 7231-02s. The CEs in the 9020*A*
systems (360-50s) were 7201-01s. This is most confusing, as the 'box' number
7201 without the model number refers to both a 360-50 and a 360-65! The
basic difference is that 360-50s were 32 bit machines, and 360-65s were 64
bit machines. The regular (non-9020) 360-50 was box number 2050, and the
360-65 box number 2065.

I wouldn't be surprised if the RPSB instruction (Repack Symbols) takes the
prize for the most complex instruction ever implemented in the history of
mainframe computing - certainly of the era. Any comments? (I guess this
should be a new thread - if there isn't one on this topic already.)

Regards

Chris Bigos

FAA Academy 9020 Class of 79/80

Email: Chris...@COLDmail.com
(Make the obvious temperature change to the spam deflector)

On Tue, 14 Aug 2001 22:51:29, "Chris Bigos" <Chris...@COLDmail.com> wrote:

> > "The last Center went operational around 1973. If anyone really cares I
> could probably find the actual date."
> 
> There was a 23rd 9020 centre (sorry - center!) at West Drayton in the UK.

Yes and no.  The LATCC system didn't use the Raytheon or DCC display 
system--it used one built by Plessey.

> The CCC was installed during 1973 and accepted from the FAA on 31st January
> 1974, though it was a while before it went operational.

Because of having to design, build, code for, and test a new display system.

> There are references to both 20 and 22 ARTCCs in this thread. Am I right in
> thinking there were 20 ARTCCs + NAFEC + OKC + UK = 23 'centers'?

In the 9020 days there only 20 ARTCCs in the US.  Besides which NAFEC had I 
forget how many 9020s: an A, a D, an E, and a simplex A at least.

There are 21 ARTCCs today, through the addition of Anchorage.  See 
http://www.ama500.jccbi.gov/factbook/ click on Current - July 2001, click on
Air Traffic, then move down one page for a list of ARTCCs.  Guam is listed 
with the ARTCCs, making 22, but as the footnote says, it's still a CERAP.  I
thought they were going to make Honolulu an ARTCC but I guess not.

-- 
     John Varela

"Chris Bigos" <Chris...@COLDmail.com> wrote in message
news:6aie7.52269$e%3.8225465@news2-win.server.ntlworld.com...
> Dear Dan / transatlantic cousins,
>
> I hope I can add my little bit to the shared knowledge in this thread:
>

A WEALTH of great information followed !

>
> > "About 1/4 the way down the left hand side is a square hole. It's where
a
> lighted button went. Any idea what the button was (vainly hoping I can
find
> the correctly labeled button somewhere)? I don't think it was "Power On",
as
> there is a switch on the lower right quadrant labeled that."
>
> This was the '360 compatibility mode' button. I recall it was translucent
> green and engraved "360" rather than "360 MODE" (p/n 5383203 - I have one
> somewhere, perhaps I could JPEG it if you're bent on an accurate
> restoration). The pushbutton was backlighted when 360 compatibility mode
was
> active, which could only be whilst in state 1, 0, or Test in either
> Supervisor or Problem mode. When not in 360 mode the CE was in 9020 mode
(we
> only ever took our CEs out of 9020 mode when running the diagnostic that
> checked that 360 mode worked!).
>

Yikes.  I've never seen a button like that.  My hopes of finding one dimmed.

>
> I wouldn't be surprised if the RPSB instruction (Repack Symbols) takes the
> prize for the most complex instruction ever implemented in the history of
> mainframe computing - certainly of the era. Any comments? (I guess this
> should be a new thread - if there isn't one on this topic already.)
>

I always thought SIE (start interpretative execution) was the most complex
instruction.  As I recall it had its own PoP, or at least a separate
multi-page document.  I don't know how far back it went though.  I ran into
it in the late '80s so perhaps it isn't of the same era.

> Regards
>
> Chris Bigos
>
> FAA Academy 9020 Class of 79/80
>
> Email: Chris...@COLDmail.com
> (Make the obvious temperature change to the spam deflector)
>
>

A picture of a 9020 panel is published in the book of

Paul E. Ceruzzi
A History of Modern Computing
MIT Press 1998
ISBN 0-262-03255-4
(Page 150)

The panel look not like a 50 or 65.
No rollers !

Can anyone comment this ?

gv


Chris Bigos wrote:
> 
> Dear Dan / transatlantic cousins,
> 
> I hope I can add my little bit to the shared knowledge in this thread:
> 
...
> > "About 1/4 the way down the left hand side is a square hole. It's where a
> lighted button went. Any idea what the button was (vainly hoping I can find
> the correctly labeled button somewhere)? I don't think it was "Power On", as
> there is a switch on the lower right quadrant labeled that."
> 
> This was the '360 compatibility mode' button. I recall it was translucent
> green and engraved "360" rather than "360 MODE" (p/n 5383203 - I have one
> somewhere, perhaps I could JPEG it if you're bent on an accurate
> restoration). The pushbutton was backlighted when 360 compatibility mode was
> active, which could only be whilst in state 1, 0, or Test in either
> Supervisor or Problem mode. When not in 360 mode the CE was in 9020 mode (we
> only ever took our CEs out of 9020 mode when running the diagnostic that
> checked that 360 mode worked!).
> 
...

In article <6aie7.52269$e%3.8...@news2-win.server.ntlworld.com>, 
Chris Bigos wrote:

>I wouldn't be surprised if the RPSB instruction (Repack Symbols) takes the
>prize for the most complex instruction ever implemented in the history of
>mainframe computing - certainly of the era. Any comments? (I guess this
>should be a new thread - if there isn't one on this topic already.)

I'm still curious how it compares to the Sperry UNIVAC 1100/80's "EDIT"
instruction (which I mentioned last time the topic of complex mainframe
instructions were talked about here).  That one was ugly.  ;-)

-- 
     -Rich Steiner  >>>--->  rste...@visi.com  >>>---> Eden Prairie, MN
                     Written online using slrn 0.9.5.4!
                   The Theorem Theorem: If If, Then Then.

"Richard C. Steiner" wrote:
> 
> In article <6aie7.52269$e%3.8...@news2-win.server.ntlworld.com>,
> Chris Bigos wrote:
> 
> >I wouldn't be surprised if the RPSB instruction (Repack Symbols) takes the
> >prize for the most complex instruction ever implemented in the history of
> >mainframe computing - certainly of the era. Any comments? (I guess this
> >should be a new thread - if there isn't one on this topic already.)
> 
> I'm still curious how it compares to the Sperry UNIVAC 1100/80's "EDIT"
> instruction (which I mentioned last time the topic of complex mainframe
> instructions were talked about here).  That one was ugly.  ;-)

I believe the HP3000 circa 1980 had a 'schedule' instruction
micro-programmed.  This could be used to voluntarily relinquish
the CPU, or by the op-sys on the appropriate timer interrupt.

-- 
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:u...@ftc.gov  (for spambots to harvest)

On Thu, 16 Aug 2001 01:01:44, "Daniel House" <d.h...@computer.org> wrote:

> Yikes.  I've never seen a button like that.  My hopes of finding one dimmed.
  
This is a story that I've told on this news group before, but it's worth 
repeating.

We had a lab at MITRE that used a Raytheon minicomputer that came in an 
orange box and had model number 704.  (To Chris Bigos: the same machine that
was used in DARC.)  It was subsequently upgraded to some other model number,
I forget what.  Anyway, the lead software guy was convinced that when he ran
certain programs he had to have the system in 704 mode and he started 
opening panels to throw switches.  The lead hardware guy had a padlock put 
on the panels, and he also had a technician mount a toggle switch on one of 
the panels and label it "704".  Whenever the software guy came in to run one
of his old programs he would dutifully throw that switch to 704 and when he 
was done he would just as dutifully throw it back.  Of course the toggle was
wired to nothing.

When the lab was decommissioned they cut out the part of the panel that 
contained the switch, framed it, and presented it to the software guy.  We 
have all now retired, but I saw the framed switch panel hanging in the 
software guy's den about a year ago.

-- 
     John Varela

On Tue, 14 Aug 2001 22:51:29, "Chris Bigos" <Chris...@COLDmail.com> wrote:

> The 9020D and 9020E Compute Elements (CEs as they were always known) were
> *identical*; a plug card told the CE whether it was in a D or an E system.
> It's just that the *software* used in the 9020D CCC didn't make use of the
> instructions that the 9020E DCC used. See below for the additional
> instructions.

I forwarded your note to the friend who didn't remember what that switch was
for, and he responded with this:

"I remember those special display processing op codes like 
"Convert and Sort" and "Convert Wx Lines", and "Repack Symbols".  These 
special micro-coded instructions were the equivalent of 2 racks of CDC 
equipment in the hard wired logic of the 60s.  I was in awe, and still am, 
of 
the engineering and test that went into these display oriented microcoded 
instructions."

-- 
     John Varela

CBFalconer <cbfal...@yahoo.com> wrote:
> I believe the HP3000 circa 1980 had a 'schedule' instruction
> micro-programmed.  This could be used to voluntarily relinquish
> the CPU, or by the op-sys on the appropriate timer interrupt.

DISP, and its disable/enable pair PSDB and PSEB.  All privileged
instructions, not intended for user code, although I have read and
written privileged non-system code use PSDB/PSEB to stall the
dispatcher.  DISP effectively causes an interrupt (either when the
DISP instruction is executed, or when a later PSEB returns the
pseudo-disable count to 0), and that gets the actual MPE dispatcher
code involved.

(Present tense: some of us still have runnable and/or running classic
3000s!)

-Frank McConnell

Frank McConnell wrote:
> 
> CBFalconer <cbfal...@yahoo.com> wrote:
> > I believe the HP3000 circa 1980 had a 'schedule' instruction
> > micro-programmed.  This could be used to voluntarily relinquish
> > the CPU, or by the op-sys on the appropriate timer interrupt.
> 
> DISP, and its disable/enable pair PSDB and PSEB.  All privileged
> instructions, not intended for user code, although I have read and
> written privileged non-system code use PSDB/PSEB to stall the
> dispatcher.  DISP effectively causes an interrupt (either when the
> DISP instruction is executed, or when a later PSEB returns the
> pseudo-disable count to 0), and that gets the actual MPE dispatcher
> code involved.
> 
> (Present tense: some of us still have runnable and/or running classic
> 3000s!)

Shades of MPE and SPL.  Does HP still maintain those machines?

-- 
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:u...@ftc.gov  (for spambots to harvest)

Frank McConnell <f...@reanimators.org> writes:

> DISP, and its disable/enable pair PSDB and PSEB.  All privileged
> instructions, not intended for user code, although I have read and
> written privileged non-system code use PSDB/PSEB to stall the
> dispatcher.  DISP effectively causes an interrupt (either when the
> DISP instruction is executed, or when a later PSEB returns the
> pseudo-disable count to 0), and that gets the actual MPE dispatcher
> code involved.

VAMPS was a multiprocessor version of 370/125. The 370/115 & 370/125
had somewhat unique internal architectures (for 370). They consisted
of a 9port (370) memory bus and several microprocessor engines
installed on the memory bus ports.

In the 370/115, all the microprocessors were identical ... they just had
different programs loaded that were function specific ... i.e. emulate
370 processor, disk controller, unit record controller, tape
controller, telecommunication controller, etc.

The 370/125 differed from the 115 in that the engine used for the 370
emulation was about 50% faster than the other engines.

VAMPS was a 370/125 project to install up to five "370 engines" in the
same configuration (in max. 370 configuration, it only left four ports
for controller engines).

For the VAMPS project, migrated the VM/370 dispatcher, much of the
first level interrupt handlers, and much of the page I/O supervisor
into "mirocode" of the various engines; and of course there were the
corresponding (privilege) instructions to interface to these migrated
functions ... i.e. add task to dispatching queue, add page request to
page I/O queue, etc.

The 370 "engines" also had an enhanced version of VM microcode assist
(in part because I was also concurrently working on ECPS for
virgil/tully).

The 370 "microcode" engine would attempt to perform all functions ...
including various microcode assist operations. If it found that it
could not complete an operation and needed survices of the (software)
kernel, it would check to see if any processor was already operating
in kernel mode, if so it would just queue a light-weight request with
sufficient information to invoke the necessary processing and go
looking for some other work. If there was no processor already in
kernel mode, it would just enter kernel mode.

The point was that 1) the then existing VM/370 kernel didn't have full
symmetric multiprocessing support 2) the changes for the above
amounted to relatively trivial number of lines of code in the kernel
software, 3) the measured percent kernel time (based on the enhanced
microcode assist) was much less than 20% (so a five engine
configuration might have something like total max of 80% a single
engine in kernel mode).

When the VAMPS project was terminated, in part because the processing
power overlapped the virgil/tully configurations ... we adopted the
microcode design to kernel software. 

High-activity paths of the kernel that received control directly from
the first level interrupt handlers were modified to support fine-grain
locking symmetrical multiprocessing. However, the majority of the
kernel (in terms of total code size, but not in terms of percent
pathlength) was behind a single "kernel" lock.

The traditional IBM mainframe approach to symmetric multiprocessing up
until that time was single "kernel" lock where a processor would
"spin" on the kernel lock until it was available.

Adopting the VAMPS microcode dispatcher design to the software kernel,
resulted instead something that I called a "bounce" lock; aka if the
processor didn't obtain the "kernel" lock, it would queue a
light-weight request for kernel lock/services and go off to the
dispatcher to find some other work to do.

This implementation provided the absolute maximum symmetric
multiprocessor thruput per line of SMP code modifications.

random refs:
http://www.garlic.com/~lynn/subtopic.html#smp Multiprocessor, tightly-coupled, SMP, compare&swap
http://www.garlic.com/~lynn/subtopic.html#fairshare Performance and/or Scheduling

http://www.garlic.com/~lynn/95.html#5 Who started RISC? (was: 64 bit Linux?)
http://www.garlic.com/~lynn/95.html#6 801
http://www.garlic.com/~lynn/99.html#149 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2000.html#11 I'm overwhelmed
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
http://www.garlic.com/~lynn/2000c.html#30 internal corporate network, misc.
http://www.garlic.com/~lynn/2000c.html#49 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000e.html#7 Ridiculous
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#40 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001h.html#69 Very CISC Instuctions (Was: why the machine word size ...)

-- 
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/ 

Anne & Lynn Wheeler <ly...@garlic.com> writes:

> The 370 "engines" also had an enhanced version of VM microcode assist
> (in part because I was also concurrently working on ECPS for
> virgil/tully).

oh yes, and some misc. ECPS, virgil/tully, microcode, etc refs:
http://www.garlic.com/~lynn/subtopic.html#360mcode 370/370 m'code

http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#51 Rethinking Virtual Memory
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#148 OS/360 (and descendents) VM system?
http://www.garlic.com/~lynn/2000.html#12 I'm overwhelmed
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout?
http://www.garlic.com/~lynn/2000e.html#6 Ridiculous
http://www.garlic.com/~lynn/2000f.html#55 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
http://www.garlic.com/~lynn/2000f.html#57 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
http://www.garlic.com/~lynn/2000f.html#63 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#7 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#29 z900 and Virtual Machine Theory
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#48 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#26 why the machine word size is in radix 8??
http://www.garlic.com/~lynn/2001d.html#54 VM & VSE news
http://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?
http://www.garlic.com/~lynn/2001f.html#16 Wanted other CPU's
http://www.garlic.com/~lynn/2001h.html#59 Blinkenlights

-- 
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/ 

CBFalconer <cbfal...@yahoo.com> wrote:
> Frank McConnell wrote:
> > (Present tense: some of us still have runnable and/or running classic
> > 3000s!)
> 
> Shades of MPE and SPL.  Does HP still maintain those machines?

I think they're all off maintenance now.  HP have moved MPE to PA-RISC
(in the late 1980s), with a compatibility mode that simulates enough
of the classic 3000 environment to run most executable code compiled
since 1974 or so, added Posix (so it's now MPE/iX), and that's what
current e3000s are made of.

And I expect there are still parts of MPE/iX that are written in
(probably several) flavors of SPL, and running in compatibility mode!

-Frank McConnell

> "I remember those special display processing op codes like
> "Convert and Sort" and "Convert Wx Lines", and "Repack Symbols".  These
> special micro-coded instructions were the equivalent of 2 racks of CDC
> equipment in the hard wired logic of the 60s.  I was in awe, and still am,
> of the engineering and test that went into these display oriented
microcoded
> instructions."
>
> --
>      John Varela

To my mind "awesome" is exactly the right adjective to use! However, I am
rather blinkered as the only mainframes I have knowledge of are the 360-50
and 360-65 as used in the 9020, and I was a maintenance engineer rather than
a software/systems engineer. That's why I posed the question in the first
place.

In the next couple of weeks I'll OCR the write-up of the Repack Symbols
instruction from the FETOM and post a link to it. Then the real experts can
judge and give their opinion. Of course, a lot depends on the definition of
'complex'. I guess I was using the length of the instruction write-up in the
FETOM as an indicator. The RPSB instruction has about 28 pages of
small-print double-column text - far more than most of the other
instructions!

Not sure why it was called Repack Symbols. The primary function was to
update a block of data on the controller's PVD (radar tube) to show current
real time aircraft position and other data of interest. Not exactly a
general purpose instruction, but still a bona-fide 360 op code.

Chris.

Email: Chris...@COLDmail.com
(Make the obvious temperature change to the spam deflector)

> > A picture of a 9020 panel is published in the book of
> >
> > Paul E. Ceruzzi
> > A History of Modern Computing
> > MIT Press 1998
> > ISBN 0-262-03255-4
> > (Page 150)
> >
> > The panel look not like a 50 or 65.
> > No rollers !
> >
> > Can anyone comment this ?
> >
> > gv
> >
>
> I've seen 3 separate "large" control panels for 9020E.  First looks to be
> 360/65 derivative (Computing Element for 9020E--there were 3 of these in
an
> installation and each had 6 rollers).  Second looks to be 360/50
derivative
> (IO Control Element--there were 3 of these in an installation and each had
4
> rollers).  The third type is, I believe, a peripheral adapter module
control
> panel.  It has no rollers, but looks vaguely like a 360/40 panel (without
> the voltmeter).
>
> As a funny aside, I was sent a picture of the 3rd type of panel and a
> closeup of a price tag still attached on it.  It shows $2,213,784.15.  It
is
> dated March, 1970.  Not exactly pocket change today, much less 1970.
>
> Regards, Dan
>

The only "large" control panel in a 9020 system, other than the CE and IOCE
control panels, was the overall system control panel. This was called a
System Console (SC) in a 9020A/D CCC and a Configuration Console (CC) in a
9020E DCC. I've never seen a Configuration Console in the flesh, as we only
had a CCC at West Drayton. (I tell a lie - I would have seen one at
Oklahoma, but I don't recall what it looked like). I do have some
documentation, however, especially on the CCC. I now posses the old System
Console from the West Drayton CCC, but it's been wrapped up and in storage
for 10+ years. Without looking in the books, which I don't have to hand, I'm
trying to think of how to distinguish an SC from a CC. The SC had a black
'Mode Indicator' panel about 2" high by 6" long in the centre top position.
>From memory, the Config Console didn't have this (I'll check).

The most important bits of the System Console were the buzzer and the bell.
As far as I recall, the buzzer was triggered by software, and used to
indicate operator intervention required, and the like. It buzzed frequently,
and we soon became pretty indifferent to its operation. The bell was a
different matter, however! There was a watchdog circuit that rang the bell
when it timed-out. The operational NAS programme had a low-priority
subroutine that reset the watchdog timer. If the bell went off, 99 times out
of 100 it meant the system had crashed (or FLOP'ed, as we called it -
Functional Lapse of the Operational Programme). We could go weeks without
hearing the bell (other than after pressing "All Stop" on the System Console
after a routine shutdown at night), and hearing its distant ringing during
the day whilst having a cup of tea in the ready room always set the heart
racing and the adrenalin flowing - time to earn our pay!

I'm pretty sure the third panel you refer to isn't off the PAM. This box
didn't have an exterior 'control panel' as such (except for a tiny panel
with on/off, EPO, and state indicators). It had an internal CE ('customer
engineer' this time!) panel, but no-one would call this a "large" control
panel. I have one of these buried away somewhere too.

    Regards, Chris.

Email: Chris...@COLDmail.com
(Make the obvious temperature change to the spam deflector)

On Sun, 19 Aug 2001 16:46:37, "Chris Bigos" <Chris...@COLDmail.com> wrote:

> Not exactly a
> general purpose instruction, but still a bona-fide 360 op code.
 
Are you sure about that?  I think those instructions were designed and 
microcoded specifically for the 9020E to interface with the Raytheon PVD.  I
have a vague recollection that some standard 360 instructions had to be 
deleted to make room in ROS for the display-oriented instructions.

-- 
     John Varela

> > Not exactly a
> > general purpose instruction, but still a bona-fide 360 op code.
>
> Are you sure about that?  I think those instructions were designed and
> microcoded specifically for the 9020E to interface with the Raytheon PVD.
I
> have a vague recollection that some standard 360 instructions had to be
> deleted to make room in ROS for the display-oriented instructions.
>
> --
>      John Varela

I'm pretty sure the 9020s had the full complement of standard instructions,
as evidenced by the 360 compatibilty mode mentioned elsewhere. In this mode
the machines complied with the 360 PoO instruction set. I've a vague idea
that the 9020 -65s *may* have had a larger ROS address space. They used the
maximum 16 ROS planes, anyone know if the standard -65s used less than this?

I'm sure you're right about the display instructions being specific to the
9020E (and D) - but that was still a large number of processors(*1). What I
meant by "bona-fide" is that they were (are) 'official' op codes (not RPQs)
factory installed in S/360 machines. Of course, this assumes that the 9020
processors are eligible for membership of the 'S/360 Club' in the first
place. IMHO they are, but I'm biased! I'd hate for them to be orphaned.

(*1) How many 9020 360-65s were made? Educated guesstimate by me - say 15 x
9020Ds and 15 x 9020 Es, assume all are Triplex (were there any Quad
systems - the design maximum?), that comes to 90. Add 10(?) for NAFEC, OKC,
and UK (4), giving ~100 in total.

John, it's really good to talk to someone who was around when these things
were being put together. I just fixed them (most times) when they went
wrong - I really admire you guys for your foresight in providing all those
systems tools that you did to assist us. FLTs, microtrace, blinkenlights,
logouts, marginal voltages, etc., etc.

    Regards, Chris

Email: Chris...@COLDmail.com
(Make the obvious temperature change to the spam deflector)

Chris Bigos wrote:
> 
SNIP
> >
> 
> The only "large" control panel in a 9020 system, other than the CE and IOCE
> control panels, was the overall system control panel. This was called a
> System Console (SC) in a 9020A/D CCC and a Configuration Console (CC) in a
> 9020E DCC. I've never seen a Configuration Console in the flesh, as we only
> had a CCC at West Drayton. (I tell a lie - I would have seen one at
> Oklahoma, but I don't recall what it looked like). I do have someSNIP
>     Regards, Chris.
> 
> Email: Chris...@COLDmail.com
> (Make the obvious temperature change to the spam deflector)
As I recall, the System Console had two fairly large red 'eyes' near
the top center.  They displayed some type of state indication, perhaps
in binary, I don't really remember.
Back in the late 60's, early 70's, I designed the manufacturing tests
for the 7289 (PAM) and 7265 (System Console).  Incidentally, IBM sold
a similar system to NASA, the PAM was called the MLA (Multiplex Line
Adapter).  A lot of the devices were the same of similar to those in
the PAM.  I was told by someone that the name was changed so the NASA
would pay for new development of the MLA even though it was
essentially a PAM.  I don't recall the model number for the MLA, it
was NOT 72xx though.

-- 
John C. Steffens                                         Frosted Flake
N32°19.018' W110°48.953' 2700'
+----------------------- Kill the .S.P.A.M... -----------------------+

Jim Saum <js...@world.std.com> wrote:

> Since the first 360 customer shipment was a year after the April 1964
> announcement, evidently the TS addition to the architecture happenned
> after announcement but before any customers got their hands on a
> machine.
> 
> How soon after announcment was the first rev of the PoO published?

Based on what's in the Stanford University card catalog, there
seem to have been incremental revisions issued September 18, 1964,
May 24, 1965, and July 30, 1965 after the initial publication.  I
haven't seen the book with my own eyes, though, so I don't know
what changed in each of these.

eric

Frosted Flake wrote:
> 
> Chris Bigos wrote:
> >
> SNIP
> > >
> >
> > The only "large" control panel in a 9020 system, other than the CE and IOCE
> > control panels, was the overall system control panel. This was called a
> > System Console (SC) in a 9020A/D CCC and a Configuration Console (CC) in a
> > 9020E DCC. I've never seen a Configuration Console in the flesh, as we only
> > had a CCC at West Drayton. (I tell a lie - I would have seen one at
> > Oklahoma, but I don't recall what it looked like). I do have someSNIP
> >     Regards, Chris.
> >
> > Email: Chris...@COLDmail.com
> > (Make the obvious temperature change to the spam deflector)
> As I recall, the System Console had two fairly large red 'eyes' near
> the top center.  They displayed some type of state indication, perhaps
> in binary, I don't really remember.
> Back in the late 60's, early 70's, I designed the manufacturing tests
> for the 7289 (PAM) and 7265 (System Console).  Incidentally, IBM sold
> a similar system to NASA, the PAM was called the MLA (Multiplex Line
> Adapter).  A lot of the devices were the same of similar to those in
> the PAM.  I was told by someone that the name was changed so the NASA
> would pay for new development of the MLA even though it was
> essentially a PAM.  I don't recall the model number for the MLA, it
> was NOT 72xx though.

And then there was the machine that used two of the old 'tuning
eye's to indicate the data and address bus contents.  They were
driven by simple r/2r ladders off the bits.  The r's were 5%
carbon, so accuracy and monotonicity were not especially good. 
The point was that response was MUCH faster than incandescent
pilot bulbs, and LEDs didn't exist.

-- 
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:u...@ftc.gov  (for spambots to harvest)

On Sun, 19 Aug 2001 22:49:48, "Chris Bigos" <Chris...@COLDmail.com> wrote:

> I'm sure you're right about the display instructions being specific to the
> 9020E (and D)

The D didn't have the extra display instructions.  The E was specified a 
couple of years after the D was contracted for, when it began to appear that
Raytheon might fail to deliver the CDC.  I forget if it was a new contract 
or an extension to the old one.  But the display functions were definitely 
added requirements.

>John, it's really good to talk to someone who was around when these things
>were being put together.
  
You bet.  There are a couple of other MITRE retirees who were a lot closer 
to the 9020E than I ever was and I've forwarded them some of these postings,
hoping to lure them onto the news group but with no luck so far.  Also I 
forwarded your post in which you mentioned LATCC to a friend still at MITRE 
who worked on the NAS installation at West Drayton.  There was a coal 
miner's strike or something while they were working on that project and they
told about working by candle light and wearing gloves at their desks.

-- 
     John Varela

Responding to my own post:

> I've a vague idea  that the 9020 -65s *may* have had a larger ROS address
space.
> They used the maximum 16 ROS planes, anyone know if the standard -65s used
less > > than this?

I've now checked and the standard and 9020 processors had the *same* ROS
address space. Where did the room for the extra instructions come from?
There must have been a lot of unused ROS addresses in the standard 360-65. I
know there were a few in the 9020 (all zeroes with good parity).

     Regards, Chris

 Email: Chris...@COLDmail.com
 (Make the obvious temperature change to the spam deflector)

"Chris Bigos" <Chris...@COLDmail.com> writes:

> I've now checked and the standard and 9020 processors had the *same* ROS
> address space. Where did the room for the extra instructions come from?
> There must have been a lot of unused ROS addresses in the standard 360-65. I
> know there were a few in the 9020 (all zeroes with good parity).

360/65 (& /67) had all that 709x emulation ros. if you didn't have
that (at least), there would be at least that room left over.


-- 
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/ 

"Chris Bigos" <Chris...@COLDmail.com> writes:

> I've now checked and the standard and 9020 processors had the *same* ROS
> address space. Where did the room for the extra instructions come from?
> There must have been a lot of unused ROS addresses in the standard 360-65. I
> know there were a few in the 9020 (all zeroes with good parity).

plus the fact, the 65 had enuf ROS also for all the '67 stuff as well
as extra instructions like search list.

-- 
Anne & Lynn Wheeler   | ly...@garlic.com -  http://www.garlic.com/~lynn/ 

"Chris Bigos" <Chris...@COLDmail.com> writes:

>I've now checked and the standard and 9020 processors had the *same* ROS
>address space. Where did the room for the extra instructions come from?
>There must have been a lot of unused ROS addresses in the standard 360-65. I
>know there were a few in the 9020 (all zeroes with good parity).

Recall that the /65 had numerous extra-cost features such as 709x
emulation; since I doubt that the 9020 boxes needed to pretend to
be an old 709x machine that address space would have been available
for use.

Of course, the extra goodies in the 9020 would require additional ROS
planes, but it wouldn't necessarily have required expanding the
address space available to them.

Joe Morris

Τη Πέμπτη, 26 Ιουλίου 2001 - 4:12:35 μ.μ. UTC+3, ο χρήστης Daniel House έγραψε:
> Having recently discovered a salvage case, I'm interested in this system.
> Is there any online information about it? Google/image searches came up very
> light.  I located Vol.6, No.2 of the IBM Systems Journal (from 1967)
> describing the system and programs for it, but I'd like more, including
> pictures if there are any to be found. There are only a few drawings in the
> SJ.
> 
> Thanks, Dan House

This is an email of yours, long time ago. Are you still interested in IBM9020? If you are, I have come accross most of its schematic diagrams that explain almost everything you need to know and I am thinking of selling those (at a very reasonable price) since there is no more space available in my storage room. Please let me know.
Regards
Michael