IBM 9020 FAA/ATC Systems from 1960's
Daniel House
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
Michael J Kingston
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
Daniel House
"Michael J Kingston" <mikeki...@cix.co.uk> wrote in message
news:memo.20010727...@mikekingston.compulink.co.uk...
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.
John Varela
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
John Varela
> 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
Daniel House
"John Varela" <jav...@earthlink.net> wrote in message
news:vd2NzVOTNb7v-p...@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
John Varela
> 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
Nick Spalding
<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
Anne & Lynn Wheeler
>
> 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/
Joe Morris
>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
Anne & Lynn Wheeler
> 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
John Varela
> 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
John Varela
> 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
Brian Boutel
>
>
> 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
John Varela
(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
Jim Saum
>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
Julian Thomas
<vd2NzVOTNb7v-p...@dialup-63.208.164.65.Dial1.Washington2.Level3.net>,
on 07/27/01
>> 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.
John Varela
> >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
Michael J Kingston
Boutel) wrote:
Not that I can see, but TS is certainly covered in the Formal Description
(flowchart?) and the tables in that paper.
Perhaps the place to look for an earlier reference is the 7030, which I
believe was more than just a bigger and better 7090, or even related
closely to the latter. I worked in 1965 as an SE at a 360/75 account, with
monthly OS/360 updates and vestigial documentation. My lead SE, who
formerly worked on a Stretch account, told me that OS/360 owed a lot to
the Stretch operating system. Not sure whether those were meant to be
words of comfort, or just shared woe.
Mike Kingston
Julian Thomas
<vd2NzVOTNb7v-p...@dialup-64.157.62.31.Dial1.Washington1.Level3.net>,
on 08/02/01
>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.
John Varela
> 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
CBFalconer
>
> 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.
On that date I had a breadboard of a desktop computer running
(remember DTL from components), and no handy Variac. I had
designed for operation down to 90 V., and the initial five or ten
minutes of the blackout had all sorts of low voltages. I hung a
Simpson on the A.C. and ran around frantically trying things.
They were all still working at 75 V. but the fluoroscents were
behaving badly.
--
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)
Heinz W. Wiggeshoff
>
...
> 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.
So for once in a long time, the burghers saw the night sky in all its
glory, plus the blue fairies along the runways, and the twinkling of
aircraft wing lights as they arrived or left. How romantic. Was there
a run on the maternity ward nine months later?
John Varela
> 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.
Oh, I understand now from Chuck F's post that you meant THAT blackout. Not
one the 9020 caused, one it responded--or failed to respond--to.
There was no UPS that was part of the 9020. There were non-standard battery
packs in each cabinet, as I recall, but I forget why, since FAA went to a lot
of trouble to install critical power systems (AKA UPS) at each Center. There
had been diesel back-ups all along, but the switch from analog to digital
equipment caused a need for uninterrupted power.
Perhaps there were batteries in the 9020 because the decision to procure an
UPS was made after the 9020 was already specified; I don't recall but it
sounds right. The decision to replace the analog display system with an all
digital system [1] was made after the 9020 was in procurement, and then the
realization would have come that other equipment than just the 9020 needed an
UPS.
[1] One of my career achievements was leading the effort at MITRE to convince
the FAA to dump the analog radar displays.
--
John Varela
Charles Richmond
I guess it's like the little Martian with the Roman helmet who said:
"I am going to destroy the Earth because it obscures my view of Venus."
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Daniel House
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-p...@dialup-209.244.224.188.Dial1.Washington1.
Level3.net...
John Varela
> 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
Joe Morris
>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
Daniel House
"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
John Varela
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
Chris Bigos
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)
John Varela
> > "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
Charlie Gibbs
Chris...@COLDmail.com (Chris Bigos) writes:
>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.)
How would this compare with the infamous SLT (search list) instruction,
which was available on certain 360s by RPQ. If anyone is interested,
I might be able to dig up a couple of write-ups, one serious and one
tongue-in-cheek. SLT's many implied operands gave the latter write-up
its subtitle of "And you thought BXLE was bad?"
Sperry->Unisys introduced (and quickly withdrew) a few microcoded
monstrosities on their System 80 line of 370 workalikes in the '80s.
I hung on to the pages which were to have been deleted by a subsequent
update to the assembler manual.
--
cgi...@nowhere.in.particular (Charlie Gibbs)
I'm switching ISPs - watch this space.
Daniel House
"Chris Bigos" <Chris...@COLDmail.com> wrote in message
news:6aie7.52269$e%3.82...@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.
Anne & Lynn Wheeler
> How would this compare with the infamous SLT (search list) instruction,
> which was available on certain 360s by RPQ. If anyone is interested,
> I might be able to dig up a couple of write-ups, one serious and one
> tongue-in-cheek. SLT's many implied operands gave the latter write-up
> its subtitle of "And you thought BXLE was bad?"
misc. search list reference
http://www.garlic.com/~lynn/93.html#26 MTS LLMPS?
http://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
http://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001d.html#23 why the machine word size is in radix 8??
http://www.garlic.com/~lynn/2001d.html#33 Very CISC Instuctions (Was: why the machine word size ...)
on 360/67s that didn't have the SLT RPQ, & if CP/67 was generated to
use the instruction in the kernel ... the kernel would take an invalid
instruction interrupt. CP/67 then had a kernel routine that would
simulate the instruction.
from cp/67 reference (pg. 252)
Module name: SLTSIM
Entry point: SLTSIM
Purpose: Simulation of the SLT (search list) instruction on those
360/67s which do not have the RPQ.
Entry conditions:
gpr 0, bits 16-23, contains the key mask.
bits 24-31, contains the count of the number of elements to be searched
gpr2: contains the address of the first element (which must be on a doubleword
boundary)
gpr3: contains the number of bytes to be compared for the data match (1 through 4)
gpr4: contains the value of the offset for the data check
gpr5: contains the value of the offset for the key check
gpr14: contains a pointer to the instruction being simulated
exit conditions
0 - unsuccessful comparion and key test with completion due to count
1 - succesful comparison and unsuccesful key test
2 - unsuccesful comparison and succesful key test
3 - succesful comparison and key test
gpr0: contains the number of elements unchecked
gpr1: contains the predecessor element
gpr2: contains the matched element
========
also misc. sie ref.
http://www.garlic.com/~lynn/94.html#37 SIE instruction (S/390)
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Joe Morris
>How would this compare with the infamous SLT (search list) instruction,
>which was available on certain 360s by RPQ. If anyone is interested,
>I might be able to dig up a couple of write-ups, one serious and one
>tongue-in-cheek. SLT's many implied operands gave the latter write-up
>its subtitle of "And you thought BXLE was bad?"
Implied operands are (to put it politely) no fun whatever. In at least
one case they bit IBM in the pocketbook: the 360/91 was a non-microcoded
system (everything hardwired, which is probably why it didn't have the
decimal arithmetic instructions). Several years after the last unit
rolled off the assembly line and the designers were dispesed to other
projects, the /91 at Oak Ridge National Labs was found to have a design
defect in the TRT instruction (which has an implied destination operand
of GPR1) if the explicit source operand used GPR1 as a base register.
This usage was consistent with the PoO, and the /91 was on maintenance.
I'm told that there was lots of unhappiness when the hardware designers
had to be brought back to the /91 project to redesign that part of the
logic and verify that the fix didn't screw up something else.
Joe Morris
Guenther Vieth
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!).
>
...
Richard C. Steiner
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.
Heinz W. Wiggeshoff
> 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.)
In the very early 70's, I read about a GE 6xx(?) list processing machine
instruction. Someone commented that complier writers like those types
of instructions. Any GE experts in a.f.c-land?
Daniel House
"Guenther Vieth" <guenthe...@d.kamp.net> wrote in message
news:3B7BD024...@d.kamp.net...
> 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
CBFalconer
>
> In article <6aie7.52269$e%3.82...@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.
Anne & Lynn Wheeler
>
> In the very early 70's, I read about a GE 6xx(?) list processing machine
> instruction. Someone commented that complier writers like those types
> of instructions. Any GE experts in a.f.c-land?
some where in early '90s(?), the ibm mainframe added instructions
supporting luther woodrums radix partition tree stuff
misc. ref
http://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
http://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2001.html#2 A new "Remember when?" period happening right now
from ibm pinciples of operation
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.7
and for even more complex stuff there is the whole (supervisor state)
infrastructure controlling access to multiple address spaces along
with the program call mechanism (access registers). The idea behind
program call was to try and have the efficiency of branch and link
while trying to preserve some authentication & access control checking
that would be possible with a kernel call (aka but w/o the overhead).
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.4
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.5
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.6
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.7
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.8
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.9
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.10
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.11
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/5.12
and then there is poor SIE instruction ref'ed in previous posting.
Mark Smotherman
> instruction. Someone commented that complier writers like those types
> of instructions. Any GE experts in a.f.c-land?
Perhaps you mean an instruction using indirection and then index tally words?
I have a GE 635 manual to check the details if we can identify the instruction.
Or perhaps it was an EIS instruction (a commercial inst. set added to the base
accumulator machine architecture).
I don't believe the 645/Multics added anything like this.
IBM 1401
|
625 (1964) |
/ | \ |
635 | 615 Honeywell 200
.------' | | |
transistors 645 | 605 (military) |
- - - - - - - - | - - - - | - - - - - - - - | - - - - - - - - - - -
integrated | 655 (1969) |
circuits | | | IBM S/3
(wire wrap) 6180 6000 | |
- - - - - - - - | - - - - | - - - - - - - - | - - - - - - | - - -
printed Level 68 Level 66 Level 64 Level 62
circuit | | |
boards DPS-8 DPS-6 DPS-7
Model designators for the Series 6000
non-EIS EIS EIS = extended instruction set,
------- ---- supported business d.p. (COBOL)
slower / 6010 6020
versions\ 6030 6040
standard 6050 6060
w/cache 6070 6080
The non-Multics 6xx series had 18-bit addressability (the granularity of
which was 36-bit word), and used the relocation register. There were
two modes of execution: master/slave. OS entry was accomplished by a
MME instruction (master mode entry).
645 Multics used 24-bit addressability and added a third execution mode:
absolute. Absolute mode used physical addressing, while master and
slave used virtual addressing via the segmentation and paging scheme.
Non-Multics 6xx addressing modes
R - register - use index register specified in tag field
RI - register then indirect (multiple levels of indirection possible)
IR - indirect then register (multiple levels of indirection possible)
IT - indirect then tally (tally controlled character manipulation in
this word-oriented machine)
6xx added several interesting "meta" instructions:
execute, execute double
repeat, repeat link, repeat double
Non-Multics 6xx Registers
72-bit AQ
eight 18-bit index registers Xn
8-bit exponent register
18-bit indicator register
24-bit timer register
18-bit instruction address register
18-bit base address register BAR (relocation register)
0 7 9 16
+-------+-+--------+-+
| base |0| blocks |0| blocks = # 1024-word blocks allocated
+-------+-+--------+-+
645 Multics added eight 24-bit base registers linked in four pairs (these
were locked to prevent access in slave mode), an 18-bit procedure base
register, an 18-bit temporary base register, and a 29-bit descriptor
base register.
Level 66 extended the relocation register by 6 bits to achieve a 16M
physical address space, although user processes still had an 18-bit
limit.
--
Mark Smotherman, Computer Science Dept., Clemson University, Clemson, SC
http://www.cs.clemson.edu/~mark/homepage.html
Alan T. Bowler
The 600 Series had (has? since the architecture lives on)
3 "repeat" instructions that were sort of a poor man's
vector mode. You can arrange that the next instruction
is repeatedly executed until a count is reached, or a
condition code satisfied. An index register is advanced
so that you step through memory.
RPT repeats one instruction,
typical use add up a set of numbers of do a linear search
RPD "repeat double" repeats two instructions
if the instructions were load and store this could be used
for a block move. This use was generally superceded when
character and bit vector block move instrctions were added
to the architecture.
RPL "repeat link"
This was the primary list processing variation.
With effort you can also use the repeat double to run down a list.
I don't know of any compiler that uses repeat link, for generated
code, and RPT and RPD are sometimes generated to do the case lookup
for B/C/Pascal switch statements. Other than that compilers generally
can't find a use for these instructions. There is some library code
that uses them. The C library memory allocator is the principal
user of RPL and RPD to manage its free list.
None of the repeat instructions is particulary complex, and they are
all a lot simpler than the "move edit" instruction which is used
by the Cobol compiler. Even more complex is the interdomain
call/return instruction. (Calls to the OS for supervisor services
are just part of its use.)
Mel Wilson
ab...@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) wrote:
> In the very early 70's, I read about a GE 6xx(?) list processing machine
> instruction. Someone commented that complier writers like those types
> of instructions. Any GE experts in a.f.c-land?
There were three instructions: Repeat, Repeat Double and
Repeat Linked, coded RPT, RPD and RPL. The effect was to
exceute the following one or two instructions up to a set
number of times, with address modification between
executions. Execution was faster because the instructions
were executed out of the processor's instruction registers,
without being re-fetched.
Typical uses:
Presetting a memory buffer to a fixed value (two words at a time):
LDA FIXVAL initializing value
LDQ FIXVAL again
EAX1 BUFFADR address of the buffer
RPT BUFFLEN/2,2 repeat_count and address increment
STAQ 0,X1 repeat this instruction to fill buffer
Block move of words in memory, one at a time:
EAX3 FROMBUF address of sending field
EAX6 TOBUF address of receiving field
ORPD BUFFLEN,1 count and address increment
LDA 0,X3 load from sending area
STA 0,X6 store into receiving area
The 'O' in 'ORPD' was an assembler directive which forced
the RPD instruction to an odd address, because the
instructions being repeated had to occupy an even-odd pair,
so that they would occupy the 72-bit-wide instruction
register together.
The only reserved register for the repeat instructions
was X0 which always held the running repeat-count, and a
whack of control bits, which were filled in from optional
fields in the RPx instruction that I no longer rememeber.
One option caused the existing contents of X0 to control
the process, so that repeat-counts could be computed at
run-time. There were alse options to suppress modification
of either operand address during the repeat, and options to
stop repeating on various indicator register flags. This
let you repeat a compare instruction to do, e.g. a
sequential scan down a table, which might have looked
something like:
EAX5 0 prepare address reg
LDA HILIM look for an entry > this value
RPT TABLENG/6,6,TRC check each 6-word entry for word 1 > hilim
CMPA TABLE+1,X5 compare table word with A reg
TTF FOUNDIT transfer on tally-runout flag Off
... fall through if the search failed
with the effect of running down a table of 6-word entries to
find the first one whose second word exceeded a given value.
IIRC, if the repeat count ran out, the Tally Runout
indicator was set, so the not-found condition could be
handled, as hinted above. On the found condition, the
working address reg. would point at the last operand word.
There was no typical use for the Repeat Linked (RPL)
instruction. Nobody of my acquaintance ever found a use for
it, and we tried. Rather than adding an increment, It would
load the operand address for the next repetition from the
high-order 18 bits of the current operand. You were pretty
much stuck with testing bits in the low-order half of the
word, and any possible application always seemed to need a
little more.
The repeat instructions always ran with interrupts
inhibited because there was no way to save enough processor
state to restart the instruction after an interrupt. This
caused trouble trying to run GCOS code in a Multics system:
a page-fault turns out to be, fundamentally, an interrupt
you don't dare inhibit. Native Multics programs never used
RPT, RPD or RPL; the newer Extended Instruction Set
instructions could do the same things, arguably better. I
never saw enough of virtual-memory GCOS to know if it had
another solution.
All the above IIRC, of course.
Regards. Mel.
J Ahlstrom
Do you - or does anyone - have any documentation
on the Honeywell New Architecture that was ultimately
released as (part of?) the level6x family?
JKA
--
The stock market is no longer about investing in a company,
sharing in it's profits, while sheltering yourself from its losses.
It's all about speculation on the price of a stock,
which may or may not have ANY connection to its fundamentals.
F Kleinsorge
Alan T. Bowler
>
> There was no typical use for the Repeat Linked (RPL)
> instruction. Nobody of my acquaintance ever found a use for
> it, and we tried. Rather than adding an increment, It would
> load the operand address for the next repetition from the
> high-order 18 bits of the current operand. You were pretty
> much stuck with testing bits in the low-order half of the
> word, and any possible application always seemed to need a
> little more.
I use it for the memory allocator in the single segment (unpaged,
small-model) C library, also in the print image writers for
the list of overstruck characters.
>
> The repeat instructions always ran with interrupts
> inhibited because there was no way to save enough processor
> state to restart the instruction after an interrupt. This
> caused trouble trying to run GCOS code in a Multics system:
> a page-fault turns out to be, fundamentally, an interrupt
> you don't dare inhibit. Native Multics programs never used
> RPT, RPD or RPL; the newer Extended Instruction Set
> instructions could do the same things, arguably better. I
> never saw enough of virtual-memory GCOS to know if it had
> another solution.
Essentially repeats are not used in that mode. The NS mode C
memory allocator uses essentially the same data structure
as the SS mode one, but uses a loop instead of an RPL.
I sometimes debate restoring the repeats and taking a user
level fault since although the repeat can't be restarted,
I know where the algorithm can. However, it is probable
that I really should investigate a completely different
algorithm.
Alan T. Bowler
>
> Mark:
>
> Do you - or does anyone - have any documentation
> on the Honeywell New Architecture that was ultimately
> released as (part of?) the level6x family?
Yes. You should be able to order the Gcos8 documentation
on CD (67 X4 42CD) from Bull. Included is the manual for the
latest version of the hardware.
John Varela
> 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
John Varela
> 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
Frank McConnell
> 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
CBFalconer
Shades of MPE and SPL. Does HP still maintain those machines?
Anne & Lynn Wheeler
> 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
> 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
Frank McConnell
> 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
Chris Bigos
> "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.
Chris Bigos
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.
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
Chris Bigos
> > 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
Frosted Flake
>
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
> Regards, Chris.
>
> Email: Chris...@COLDmail.com
> (Make the obvious temperature change to the spam deflector)
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... -----------------------+
Eric Fischer
> 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
CBFalconer
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.
John Varela
> 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
Chris Bigos
> 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).
Mel Wilson
ma...@hubcap.clemson.edu (Mark Smotherman) wrote:
>Perhaps you mean an instruction using indirection and then index tally words?
>I have a GE 635 manual to check the details if we can identify the instruction.
Great chart. I've saved it. Thanks.
>Model designators for the Series 6000
>
> non-EIS EIS EIS = extended instruction set,
> ------- ---- supported business d.p. (COBOL)
>slower / 6010 6020
> versions\ 6030 6040
>standard 6050 6060
>w/cache 6070 6080
The 6180 was also an EIS machine. In fact the pointer
registers used by Multics for segment/offset addressing
were combined with the EIS address registers used for
word/character/bit addressing.
I don't know if this fits with your over-all scheme; I'm
mentioning it just in case.
Regards. Mel.
Anne & Lynn Wheeler
> 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
> 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.
Joe Morris
>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
mpar...@gmail.com
> 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
JimP
>?? ??????, 26 ??????? 2001 - 4:12:35 ?.?. UTC+3, ? ??????? Daniel House ??????:
Al Kossow
> 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.
dank...@gmail.com
dank...@gmail.com
John Levine
In article <a8f5c0f1-4000-4705...@googlegroups.com>,
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Jon Elson
buch of custom hardware, and several modified IBM 360 mainframes. The 9020D
Diaplay Element was a modified 360/50 with some additions to microcode and a
slightly different front panel. The 9020E Compute Element was a modified
360/65 also with added microcode and a slightly different front panel.
There ARE some pictures of the machines on the net.
Jon
Anne & Lynn Wheeler
> I don't know where this message came from, but the 9020 was composed
> of a buch of custom hardware, and several modified IBM 360 mainframes.
> The 9020D Diaplay Element was a modified 360/50 with some additions to
> microcode and a slightly different front panel. The 9020E Compute
> Element was a modified 360/65 also with added microcode and a slightly
> different front panel.
https://www.amazon.com/Brawl-IBM-1964-Joseph-Fox/dp/1456525514
Two mid air collisions 1956 and 1960 make this FAA procurement
special. The computer selected will be in the critical loop of making
sure that there are no more mid-air collisions. Many in IBM want to not
bid. A marketing manager with but 7 years in IBM and less than one year
as a manager is the proposal manager. IBM is in midstep in coming up
with the new line of computers - the 360. Chaos sucks into the fray many
executives- especially the next chairman, and also the IBM president. A
fire house in Poughkeepsie N Y is home to the technical and marketing
team for 60 very cold and long days. Finance and legal get into the fray
after that.
Joe Fox had a 44 year career in the computer business- and was a vice
president in charge of 5000 people for 7 years in the federal division
of IBM. He then spent 21 years as founder and chairman of a software
corporation. He started the 3 person company in the Washington
D. C. area. He took it public as Template Software in 1995, and sold it
and retired in 1999. With 34 years of management, his enumeration and
depiction of the talents and traits that are to be recognized and
rewarded at all levels of management merit perusal - and even study. He
is also the author of Software and its Development published by Prentice
Hall in 1982, and two paperbacks, What If in 1979 and Trapped in the
Organization in 1980, both published by Price Stern Sloan. His software
book was translated into Russian, and his Executive Qualities was
translated into Spanish. Joe Fox grew up in Brooklyn N.Y., graduated
from St. John's University in Queens, N.Y. with a degree in Mathematics,
and joined IBM in 1956. Twenty years later, still in IBM, he had his
book Executive Qualities published by Addison Wesley in 1976. IBM, not
mentioned nor identified in the book, did not see it before
publication. IBM was not identified as the venue for the management
ideas and concepts. After 9 printings, the publisher discontinued the
book, but it still sells in book form on the Amazon used book
service. Mr. Fox frequently presented the traits, talents, trials and
tribulations detailed in his Executive Qualities book several times at
IBM's Sands Point executive month-long training, and at CIA management
meetings in Langley, Virginia. Mr. Fox chaired several committees for
DOD during his career.
... snip ...
I don't remember running into Joe in IBM ... but after leaving IBM and
working in financial industry ... we had a big contract with Template
and spent lots of time with Joe and some other former IBMers. The Amazon
reviews has some mention of this 2nd part.
https://www.sebokwiki.org/wiki/Federal_Aviation_Administration_(FAA)_Advanced_Automation_System_(AAS)
while we were doing HA/CMP product, past posts
http://www.garlic.com/~lynn/subtopic.html#hacmp
we participated in some reviews of AAS.
--
virtualization experience starting Jan1968, online at home since Mar1970
Chris Bigos
Also a LOT of of other 9020 documentation.
JimP
That person might still be around.
--
Jim
JimP
wrote:
interested in the document.
--
Jim