Conference 7.286::digital

Thankfully, when Mentec opened up in Lowell a few months ago, they staffed
the PDP-11 effort with four folks who had been TFSO'ed from my old group a
year ago (we used to own all of the PDP-11 layered products). They have
some very capable people handling the business down there.

-Jack

    Didn't we farm out some chunk of the PDP-11 hardware business a while back?
    
    dave

    It would be interesting to find out if money passed in this deal...
    and which way.  kb

    
    The Corporation is to End of Service Life the PDP 1145, PDP 1150 and 
    PDP 1155 hardware on the 31st of July 94.
    
    It seems that these products are profitable, they certainly are in the
    UK. Further, with the SW support announcement between Digital and Mentec 
    it seems in my opinion, unreasonable to retire these products. 
    
    Any ideas why this was done ?
    
    Toze
    
     
    
    
    

    >The Corporation is to End of Service Life the PDP 1145, PDP 1150 and
    >PDP 1155 hardware on the 31st of July 94.
    
    I remember these machines; the 11/55 was the OEM version of the 11/45;
    it had pi-polar memory and it would fly!
    
    But those are some *very* old machines, and probably very difficult
    to get parts for (not to mention finding someone who knows how to fix
    them). I doubt that these models have been sold for 15-20 years.
    
    To my knowlege the company isn't end-of-service-lifing the hardware on
    more recent models, are they? 
    
    
    Deb																																																													

 >   I remember these machines; the 11/55 was the OEM version of the 11/45;
 >   it had pi-polar memory and it would fly!
    

 Pi-polar memory?  Is that about 3.14159/2 times faster
 than bipolar memory?

    I think the 11/45 had a very important feature: supervisor mode; but
    lacked extended physical addressing which the 11/70 had and then the
    11/44.  By the time I arrived at Digital in 1978 the /45 was being
    displaced by the /70, and I think the /44 really did it in around 1980.
    
    So, I think it's been 16 or more years since it was a 'latest
    generation' machine.  DEC_HISTORY probably has the exact dates.
    
    	/john

    	re: .5
    		Is there any official communication on the end of life for
    the 1155's.  I service the Personal Rapid Transit that move up to
    15,000 students between the two campuses at West Virginia University. 
    There are two 1155's that are the main computers and 12 1140's at six
    stations that control the driverless vehicles.  Could any communication
    be posted here or sent to me at csoa1::leslie?
    
    		Yes parts can be a problem.  CPU backplanes and front
    panels to name a couple.
    
    Thanks,
    
    Kenley

    I apologize for not knowing the answer to this, but do we still
    manufacture PDP-8 CPU boards for OEM's to use in industrial
    controllers, etc...  I know we did for a long time after we
    discontinued selling PDP-8s, as such.
    
    Thanks in advance.

                      <<< Note 3239.6 by HELIX::SKALTSIS "Deb" >>>
    
    >The Corporation is to End of Service Life the PDP 1145, PDP 1150 and
    >PDP 1155 hardware on the 31st of July 94.
    
    I remember these machines; the 11/55 was the OEM version of the 11/45;
    it had pi-polar memory and it would fly! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      
    
    
    	Rubbish! (Don't take that personally, of course)  Fly it (11/55)
    certainly did.  In its day, it was the third fastest machine in the
    world running Fortran!  That was after some other manufacturers machine
    then the DECsystem 10.
    
    	The PDP11/55 was not an OEM machine (although it may ALSO have been
    sold as such).  It was an 11/45 with the PDP11/70 Floating Point unit
    (FP11-C if I remember correctly) with optional MOS or Bi-Polar memory
    up to 32 kilo words and only 18 bit addressing.  I spent many happy
    hours fixing these machines - I had six of them on one site plus
    others!  Most common fault was the PSUs.
    
    				Malcolm (ex-FSE).

    1170 came out in 1976 as I remember.  As a field service rep. I was
    trained on it then and then installed a couple of them (#116 and 147 if
    memory serves me right).
    
    1145 was it's predecessor, with a lot of similarities but cache memory
    being the big delineator.  1145 with MOS memory (16k max) made the
    machine an 1150.  Bipolar memory (8k max) made it an 1155.
    
    Clever programmers could load segments of code into the bipolar (or
    MOS) and have the instruction cycle take 125 nsec. The were some flight
    simulators made which ran on bipolar only.  The whole application
    loaded and running in bipolar.  Didn't do much but did it in a hurry.

                  <<< Note 3239.9 by CSOA1::LESLIE "KENLEY" >>>
                     -< ??Official statemnet by Digital?? >-

    	re: .5
    		Is there any official communication on the end of life for
    the 1155's.  I service the Personal Rapid Transit that move up to
    15,000 students between the two campuses at West Virginia University. 
    There are two 1155's that are the main computers and 12 1140's at six
    stations that control the driverless vehicles.  Could any communication
    be posted here or sent to me at csoa1::leslie?
    
    		Yes parts can be a problem.  CPU backplanes and front
    panels to name a couple.
    
    Thanks,
    
    Kenley


	But you guys did finally get rid of that pair of 45's over at 
	the WV St Police...thank the gods...spent a week onsite there one
	night...fixed the BP by beating it with a broom stick as I recall!

    Re: .13-
    
    	Stu, you got a lotta nerve beatin' on that poor ol' 11/45 like
    that in front of W.V.'s finest no less! I used to take a soldering iron 
    out and plug it in to intimidate them. Those systems used to run in
    85 or higher ambient temps. in the summer before they enclosed them and
    added a dedicated A/C. I had to PM the backup system with minimal
    power-on time since it would raise the room temp. too much.
    
    Re: .9-
    
    	Kenley, the WVU PRT is too much of a money maker to walk away from 
    esp. since there's no way they can realistically replace the h/w. We
    should buy a heap of used spares before they all disappear and
    negotiate a best effort maintenance contract. It's hard to believe that
    it's difficult to maintain ~20 year old computers when you can
    still locate vacuum tubes for '50s Hi-Fi equipment...
    
    Phil_who_has_repaired_his_share_of_PDP11_classics.
     

    
    1145 was it's predecessor, with a lot of similarities but cache memory
    being the big delineator.  1145 with MOS memory (16k max) made the
    machine an 1150.  Bipolar memory (8k max) made it an 1155.
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    
    	Can't agree there!  The 11/55 was available without either MOS or
    Bi-Polar memory.  The differentiator to the 11/45 and 11/50 was the
    fact that it had the 11/70 Floating Point Unit - unless someone knows
    better.  Not only that, the MS11-C (I think it was), were 4K Word Memory
    boards and you could fit eight of them which is 32K Words.  I remember
    the number of times I used to argue with FS Logistics 'cos they
    repeatedly sent the 1K Word boards (MS11-A?).  These Bi-Polar memory
    boards and the controllers were a pig to set up having so many jumpers
    to set up the memory size, memory start address, etc. etc. etc.  They
    caught out many on out of hours calls who were not familiar with the
    modules.
    
    				Malcolm.

    
    
    re .5   
    
       The Corporation is officially retiring the PDP 1145, 1150 & 1155.
       on the 31st July 94.
    
    re .9
    
       Kenley, I will send you the Corporate official communication by
               VAXmail.
    
    
    Regards,
    Toze 
    
    

I just attended the opening of TOEM training in Nashua and was privlidged to hear
TOEM leader and new VP Bill Armitage address the VERY LARGE crowd. His remarks 
were upbeat and positive but by far the most interesting comments came around 
the exisiting PDP business and what he intended to get from it. Seems that the
corporations  newest top measurement is not revenue or even contribution margin
but rather its  CASH FLOW. Armitage pointed out that with a gross margin of some
70 odd percent, and almost no cost of sales, the PDP business for which his 
business unit has claimed, exceeds his total cash flow budget for the year!!!
He instructed all of the sales reps not to try and convert PDP customers to 
Alpha unless it was their idea and they demanded to migrate and  further not to
give up the 40% margin to the distributor for a sale which is basically a no
brainer anyway. He didn't come right out and suggest they sign up new PDP11
OEM's, I guess no one is that foolish, but they are sure waking up to realize
how to milk the cash cow.

My hat is off to the stratigists in TOEM who finally found out how to satisfy
the customer base and to bring in some badly needed profit to this company.

BRAVO

Joel

    
    Anybody remember what the PDP 11/44 was for?
    
    I still carry around that penknife.  (;^)
    
    Cindy

    FFTs and other such thing?
    
    rww

    Woopppppssssss.   I am thinking of the 11/55.
    
    rww

    I have an even more obscure one. How about the pdp 11/48. I'll bet
    there are less than 10 people in the company that know this one.

	How about the 11/74 (Hydra)?

That's easy - the PDP-11/74 was a machine for the
RSX-11M/M-Plus dev group and the DECnet-RSX dev group
to use.

(Did anyone else have one?  How many existed at peak?)

    I use to build PDP 11/44's, but then I also built PDP 15's and PDP
    10's and PDP 8's. Those were the days when DEC was the place to work.



    Jim

re .23

Yeah.  Alberta Government Telephones (the phone company) had one.

/john

    re: .18
    
    TRAX used to run on an 11/44, I think.  One of the first projects I
    worked on at DEC was editing the TRAX installation guide.  The
    installation asked what kind of CPU you were running on, and you had to
    answer with one particular model even if you had one of the other
    supported models.  So if you were installing on an 11/70 you still had
    to say it was an 11/44, I think.  (I'd have to dig the thing out to see
    what the exact numbers were. )
    
    The writer and I got the engineers to change the installation by
    pointing out that if there was only one correct answer and in the
    majority of cases people were going to have to enter the wrong answer,
    they really should get rid of the question.  It took some arguing,
    though . . . 
    
    --bonnie

 >   TRAX used to run on an 11/44, I think.  One of the first projects I
 >   worked on at DEC was editing the TRAX installation guide.  The
    
    Ah... who does not remember the ever so recognisable dark green
    'TRAX Marketing Guide'. It's fun to silently walk by the cubicles
    holding one up and see how many  aggresive crossed fingers you
    get back spelling a big X for get out of my life now please...
    
    
 >   supported models.  So if you were installing on an 11/70 you still had
 >   to say it was an 11/44, I think.  (I'd have to dig the thing out to see
    
    I think it was the other way around and IMHO it was 'simple' 
    questions like this that spelled the demise of the product.
    
    It should have never been an cloned RSX-11M-PLUS operating system. 
    It should always have been designed as a layered product and
    instilled its requirements on RSX making both better products
    It should never have cared what CPUs / DISKs it was running on
    because that will hold it back. If it needed to know anything 
    about the lower levels, it should have made the OS provide
    that info dynamically. Oh well, we learned since..
    
    Grins,
    	Hein.
    
    
    
    

    
    Ah! that beloved TRAX,  the only operating system I knew that HAD to use
    block mode terminals..... And if they were not all powered up and
    connected Trax refused to boot.  It was a b****r going round a LARGE
    user's offices and trying to find the switched off terminal! Many many
    happy nights were spent trying to understand the crptic crash messages,
    (most of them seemed to relate to probs with running out of pool and
    overrunning the stack) I think we sold three systems in the UK!
    
    Patrick,
    

We had one in single processor setup that we ran RSTS/E on.  Rumor at the time
was that it ran faster than a 780, and that could not be allowed.

    I *believe* that there is an 11/74 right at this moment running in
    colorado springs at the CSC.

>
>    I *believe* that there is an 11/74 right at this moment running in
>    colorado springs at the CSC.

That is where the RSX 11/74 ended up.  Dave Carroll had been making good use
of it out there.

Re: .29

Ah yes - and then there's the 200MPH carburetor which the oil companies
squashed...  Conspiracy theories are such fun, aren't they?


From a recent discussion in comp.sys.dec, it would seem that there are 
several 11/74s outside Digital.

					Steve

>     <<< Note 3239.29 by NYAAPS::CORBISHLEY "David Corbishley 323-4376" >>>
>We had one in single processor setup that we ran RSTS/E on.  Rumor at the time
>was that it ran faster than a 780, and that could not be allowed.
    
    As I remember it, this rumor probably derives from how the 11/74
    Commercial Instruction Set add on processor ran COBOL faster than a
    780.  For whatever reason, it was "never offered for sale".  To be
    fair, the CIS was more boards than the 11/74 processor itself.  Can't
    remember how it compares to a 780 processor.

    re: .27
    
    >>> I think it was the other way around and IMHO it was 'simple' 
    >>> questions like this that spelled the demise of the product.
    
    You're probably right about it being the other way around -- it's been
    a l-o-n-g time.  I agree that the simple questions like that were the
    demise of the product.  It was a good slick system, did a lot of things
    really well, and could have been a success.  
    
    Another problem was the documentation.  When we got the installation
    guide, it had about three NOTEs and a WARNING on every page.  And all
    but a handful of them were because somebody forgot to explain something
    where it should have been explained, or the installation wasn't doing
    something at the point where it should have done it (like checking for
    that low-level information).  So you'd get to the point in the
    installation where it was going to break if you hadn't done something
    right earlier, and you'd get this big NOTE: IF YOU DIDN'T ENTER THE
    RIGHT DEVICE NAME IN STEP 2, THE INSTALLATION WILL FAIL HERE!  And
    you'd think, huh? Step 2 didn't say anything about device names.  The
    writer on the project spent several weeks just putting the information
    in where it belonged. 
    
    This was after the government of Ireland threatened to sue us if we
    didn't fix things . . . 
    
    --bonnie

RE: faster than a 780...

I was the debug tech on the PDP 11/74 CIS (Commercial Instruction Set) project. 
According to the folks who ran the US Steel benchmark in our lab in Tewksbury,
we *were* faster (on that benchmark) than a 780.  Of course, we had a five
board CIS accelerator, which helped (it was supposed to be four, but the
microcode ROMs got too hot, so we spread them across two boards).

I also delivered an early machine (a prototype) to Merrimack.  I was told it
was for the COBOL group to use in debugging the new PDP11 compiler that would
take advantage of the CIS, which was going to be available on other PDP11s as
well.  As I remember it, they really liked the machine:  it was very quick.

I think the extra cost of the accelerator did the most to kill off the CIS
portion of the project.  Relative to the base machine, it was an expensive
add-on.

FWIW.


								John
    

    	The 780 was designed to take a variety of accelerators, including
    one for its CIS. With the indecision whether there should be a CIS
    accelerator, improved microcode, compilers avoiding the packed decimal
    instructions, software emulation of some instructions, ... it was a
    long time before any VAX had reasonable Cobol performance. The original
    target for the 780 was that it should have Cobol performance
    competitive with the IBM 370/158.

    RE: .23
    
    We had a half of one in the COG/Real Time Team in PK2; Basicly,
    we had two single processor setups, SHADOW and OBELIX; we used shadow
    for M-PLUS support, and OBELIX for IAS support and development.
    
    Deb

As it was explained to me, the "Commercial" product line people expressed
no interest in the VAX - the PDP-11s running RSTS/E was just fine for them.
Therefore the emphasis was on FP performance for Fortran, and for that
the 780 was a screamer (compared to its integer performance, with the FP780).

It took several years for the COBOL interests to recognize what they had
missed out on.

				Steve

P.S.  My reference to conspiracy theories was not meant to suggest that the
11/74 wasn't faster (I didn't know if it was or not), but rather the notion
that it was cancelled because it was faster than the 780 was ridiculous.

P.P.S.  And yes, I had meant to say "200MPG carburetor".

    I sold the first VAX-11/780 running COBOL (with a lot of help from some
    benchmarking that was done with a pre-release of the software) as well
    as FORTRAN and we BEAT the IBM 370/158 that the VAX replaced, running 
    the same applications that had been developed for the 370, even in 
    single stream batch.  The "conventional wisdom" in Digital at the time 
    was that we would lose in all aspects of performance relative to the 
    370/158, the only question was how badly.  The REVERSE proved to be true.
    I was also informed in every sales training class in those days that
    "you can't replace an IBM mainframe outright, and no one has".  Wrong.
    
    I also distinctly remember the 11/74 project, and while the VAX-11/780
    was a GREAT COBOL machine at the time, I don't doubt that an 11/74 with
    the CIS would beat it in the U.S. Steel benchmark.  
    
    Cheers,
    Ken
    

    Steve,
    
    I agree with you.  I always felt that the price of the option was what 
    killed it.
    
    
    								John

    Re .39
    
    So how many IBM mainframes *did* the 780 replace outright?
    
    Dave
    

    I still have the *Sales Update* in which TRAX was
    announced...definitely not printed on glossy paper.
    
    Jim
    
    PS I also have a VAX 11/780 poster that says "The Personal VAX" with
    this big mother VAX, a guy in a pith helmet, some nerdy kid, RK's and
    an LA of some sort.

    Re: .41
    
    Not enough!  The conventional wisdom of the day was "don't even try!". 
    Only those that were directly involved with individual sales would
    know.
    
    The one mentioned replaced not only a 370/158, but also a GE 415 (which
    was a serious museum piece by the late 70's).
    
    Cheers,
    Ken
    
    

Bizarre.  Having worked on a 360/44, I would have expected any DEC product
to beat any IBM product costing/weighing up to 10x as much...

	paul

    	I used to work with a PDP-8 which had a direct memory-to-memory
    link with an IBM 360/30. We couldn't afford disks for the PDP-8, so we
    used it to do the computations at which it was faster than the IBM, and
    used the IBM as a storage controller. I don't know about relative
    weights - the bottom 3 foot of the PDP-8 was taken up with power
    supplies, and it took 3 of us to move it along a corridor even though
    it had castors. The price was pretty high too - it was bought when DEC
    had a European staff of 3 - a salesman, a field service engineer and a
    software specialist, and you could buy a large number of AXP
    workstations today for that amount of money.

                    <<< Note 3239.33 by JAMMER::JACK "Marty Jack" >>>
                             -< I think it's just the CIS >-
    
    >     <<< Note 3239.29 by NYAAPS::CORBISHLEY "David Corbishley
    323-4376" >>>
    >We had one in single processor setup that we ran RSTS/E on.  Rumor at
    the time
    >was that it ran faster than a 780, and that could not be allowed.
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    	Quite a few good things were sacrificed on the VAX altar!  Anyone
    remember the DECsystem 2020?  Came out around or even a touch before
    the VAX 11/780, but in order to stop it competing with the VAX, which was
    comparable in power but nearly double the price, they doubled the price
    of the 2020!
    
    				Malcolm.

>  <<< Note 3239.46 by SUBURB::POWELLM "Nostalgia isn't what it used to be!" >>>
>                     -<     Anyone remember the 2020?     >-
>
>                    <<< Note 3239.33 by JAMMER::JACK "Marty Jack" >>>
>                             -< I think it's just the CIS >-
>    
>    >     <<< Note 3239.29 by NYAAPS::CORBISHLEY "David Corbishley
>    323-4376" >>>
>    >We had one in single processor setup that we ran RSTS/E on.  Rumor at
>    the time
>    >was that it ran faster than a 780, and that could not be allowed.
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    
>    	Quite a few good things were sacrificed on the VAX altar!  Anyone
>    remember the DECsystem 2020?  Came out around or even a touch before
>    the VAX 11/780, but in order to stop it competing with the VAX, which was
>    comparable in power but nearly double the price, they doubled the price
>    of the 2020!


	I am a big TOPS-10/20 fan and I do remmember the 2020.  I believe
	that it did ship before the VAX 11/780.  The story however, I
	heard goes more along the lines of the VAX 11/780 with the 
	floating point processor was faster than the 2020, which was not 
	allowed at the time.  So, in order to ship the 780, the original
	version was shipped without the FPU, so it would not perform as
	well as the 2020.  However, this story is second hand, so you could 
	be correct.

				_Anthony Rizzolo

    I have maintained computers from 1960.  I started with a Bendix G-15D,
    which had a lot of vacume tubes, and 4 k of drum memory.  I have
    enjoyed fixing a lot of different computers, Bunker Ramos, CP-642B,
    PDP and Vaxes.  I did not enjoy working on the LCG machines, as the 
    backplanes were just plain crap.  I spent one entire night on a KL10 
    (1090) at Western Michigan University... the other engineer worked the 
    following day, and at about 4:30 pm he just reseated all the modules
    for (about) the 4th time, and the SB started running again.
    
    I do not mourn the demise of the LCG's including the 2020's.  Pieces
    of doogie doo doo in my book.  
    
    I REALIZE THAT I have probably stepped on a lot of toes, but that is
    just my opinion.   
    
    Dave

Bendix made computers?  It puts a whole new meaning on disks, drums, and the
halt instruction.

    Re.48
    
    	We are all entitled to our opinions!  What we shouldn't do is try
    to pursuade others that they are fact - that is called "Pontifying" in
    my dictionary!
    
    	Not that I am suggesting that you are doing that .48!
    
    	I seem to remember that the KL10 was a load of trouble when it
    first came out too, didn't work on them, only KA10 and KI10s.  I think,
    upon reflection, that there *was* a lot of trouble with the KL10
    backplanes as you write.
    				Malcolm.

    RE: .37
    
    OBELIX was an 11/70.  The IAS group also had an 11/55.
    
    Robin
    An ex-IAS engineer

    Robin,
    
    You are partly right; it had the 11/70 CPU in it, as what the 11/74 was
    was a machine with 4 11/70 cpus in it; The CPU in OBELIX (and in
    SHADOW) were from one of the 11/74s that never made it to market. 
    
    Deb - who was there when it arrived
    
    

    Bendix made a G-15 and a G-20 computer... the G-20 was transistorized,
    and when CDC bought out the computer division, that was a big boost to
    the CDC computer industry.  
    
    
    Dave

    Re: .44
    
    Sometimes, in I/O intensive applications, an IBM machine fared
    pretty well in spite of low CPU power, provided it had good
    I/O bandwidth.
    
    Dave

Ah, yes, LCG!

{{ I never had occasion to judge a machine by its backplane.     }}
{{ I doubt if any of the comments about the KL-10 would apply    }}
{{   to the KI-10, the KA-10, or any of the DEC-20s.             }}

I remember the LCG machines well! They were fun to program, fun to use,
and even almost fun to manage!

The cutover to a single architecture was bumpier for those of us
in MR1 than for the folks elsewhere.  At first, the party line
was "the VAX is going to be aimed at the scientific and technical
community, while the DEC-20 will continue to be the flagship
for the commercial market."

When we found out about VAX COBOL, we knew we had been betrayed.
Then, Rose Ann Giordano was sent off to DECUS to explain to the
customers.  Was that fun!

I also remember minicomputer types gushing at me "It has everything
you ever wanted in a PDP-11, and more!" and then going to explain
the great novelty of a paging map!  I didn't have the heart or the
nerve.  Meanwhile operators kept telling me there was no way
to do things like pull a given print job out of the queues and print
it next, etc.

In retrospect, after getting over the lumps, I think the following:

Going to a single corporate architecture was a good move at the time.
That single decision probably brought Digital more earnings than all
the earnings up to that time combined.

32 is a better choice than 36.  Numbering bits from LSB up makes sense.
HEX is more concise than octal.

The LCG architecture was doomed by an 18 bit virtual address space.
The VAX architecture was dammned good at scalability.

The VAX had fewer silly instructions, and a few really useful ones.
The VAX had better stack management, addressing modes, multiple operands,
etc.  The calling sequence could be more standard than was possible with 
LCG machines.  (obscure technical issue here).

VMS was more thoroughly engineered for resource management than
TOPS-10 or TOPS-20.  (but not as easy to manage, unless you like
referring people to figure 1).

DCL was great! (but no "ESC-?" guide mode)

Compatibility with PDP-11s was more important than with LCG machines.

Here are some things that I still regret, after all these years:

There was no decent migration path for customers and employees.
The timing wasn't done right.

There should have been special courses for the LCG programmers,
system managers, etc.

And, especially, the corporation should not have expunged, Orwellian
style, all of the accumulated learning from 15 years of timesharing
experience.

There were a lot of issues that have to do with managing a system
that has to support hundreds of concurrent users and thousands of
authorized users. People familiar with RSTS and RSX just didn't know
all this stuff.   VMS had to reinvent most of that stuff, version by 
version, over the years. It would have been available if the company
had been as integrated as the architecture.

They kept announcing Digital "firsts" that weren't firsts:  SMP for
example.  Insult upon injury.

One of the TOPS-10 heavies (sorry, the name is lost to me)
went off to WANG in a huff.  They must have reassured
him:  "We would *never* stop making a product just because it was 10
years old!"    <ducking>
                
My "smooth sailing through the 80's" coffee mug broke in about
1989.  I'll try to be more careful with my AVASTOR coffee mug!
<ducking again>

Cheers, 
Dave
    

RE: .55

	Hey, I still have my "Smooth Sailing thru the 80's!" mug!! I
	wouldn't drink anything out of it as it was used for pens and
	pencils for years, but other than that, it's in decent shape.

							mike

    
    	Anyone remember the problems that ex-PDP11 FSEs had in grasping
    what a BYTE was in DEC10 land?
    
    	A Byte was anything from 1 to 35 bits longs anywhere in the 36 bit
    word!  Threw them every time - "But a Byte is 8 bits" - NOT in DEC10
    land sir!
    
    	Also, I remember that the customer for whom I was the site FSE, had
    a dual KI10 set up and wanted to upgrade the power of the system (each
    KI10 was about 2.0 to 2.5 VUPS! if I remember correctly) and was offered
    a VAX11/780!!!!!!!  They moved to IBM - what a surprise!  We didn't even
    offer them a KL10 (5 or 6 VUPS) upgrade which was still available at the
    time due to the pressure to sell VAXs.  Clusters hadn't been introduced
    at the time, I think.
    
    				Malcolm.
    
    				Malcolm

    I remember teaching a DEC-10 Admin course where the following happened:
    
    A couple of IBM customers wanted to know if TOPS-10 COBOL supported
    reading IBM magtape volumes.  I replied with a firm and friendly
    "yes".
    
    A little while later, a PDP-11 customer wanted to know how to
    read data written by a PDP-11 on the DEC-10.  Backpedaling furiously,
    I told him that either he could write an IBM tape on the 11, or, I
    thought there was a could utility available from DECUS that would
    read 11 format magtapes into a DEC-10.
    
    The PDP-11 customer was happy.  He knew DECUS.  He knew he was likely
    to get an excellent solution for free.  But meanwhile, the IBM 
    customers were turning various shades of purple.  I knew what
    was bothering them.  Sure enough, at the next break they cornered me,
    and said:  "How *dare* you assure us that you can read our tapes from
    a mainframe, when you don't even offer a supported solution to your
    own minicomputer customers!"
    
    What could I say?
    
    Dave

    a DEC-10??  Wasn't that the peripheral they attached to a bunch of
    PDP11's?
    
    My apologies ... I couldn't resist.

    	A PDP-11  was a terminal controller that was highly convenient when
    a DEC-10 needed to handle more than a few hundred terminal lines or
    other types of communications interfaces.
    
    	Cray upgraded to use VAX machines for this type of interface, but
    the LCG product line was prevented from using VAX machines by internal
    politics.  ;-)

	Do any of the ex-PDP11 FSE's remember how the LCG tech's hated to work
on the 11's? Our's would not go within ten feet of anything with an PDP11 for a
CPU.

 Keith    

    PDP-11? wasn't that a disk controller for a PDP-15?
    
    ed

    
    Dupont use the 11's to control Milcron's package robots.
    
    Cooper River Plant

	PDP-10 types did not like the PDP-8 or PDP-11 because there were 
	not enough lights to help them find the problem.

	I don't recall the PDP-11 front-ending a LCG machine until the KL10.

	Cray used multiple PDP-10's as front ends much like the PDP-11 was
	used on the KL10.

	Also, the KI10 was under-used; even by DEC.

	The thing that really killed LCG was the stringent requirements the
	product line placed on them.

    >	I don't recall the PDP-11 front-ending a LCG machine until the KL10.
    
    Actually, the KI-10 was front-ended by a DC76 which was a pdp 11/40
    which talked to the KI-10 memory via a DL-10.
    
    Unfortunately, the DC-76 interrupted TOPS-10 for each character instead
    of buffering them.
    
    

    

    re .64
    
	>The thing that really killed LCG was the stringent requirements the
	>product line placed on them.
    
    I heard that what killed LCG was the fact that Digital (K.O.?) wanted
    to move away from the big "hummer" machines and move more towards
    distributed computing.
    
    Frank M.

    Speaking of front ending.  
    
    I was working at Pitt, many years ago, when our lead 10 type went
    west to work on the KA-10(s?) used to front end the ILLIAC-IV.  Shortly
    the terminal concentrator guru for the 11s (yes we were doing this in
    the early 70s) left to go to the same place to work on the 11s
    frontending the 10s front ending the ILLIAC.
    
    Now, if we han only had an 8 type, this might have gotten even more
    interesting }8-)
    
    

My opinion is that what killed LCG is that they could not compete with
the folks in Hudson and Littleton.  JUPITER didn't work, the VAX 9000 was
late and expensive.  LCG was run as if it were the "Marlborough Computer
Company" and, towards the end, was not doing anything useful for Digital.
Their time had passed.

					Steve

	Re .64

	The PDP-8/I had more that enough lights on it. 

	Yeah, PDP-11's did handle the terminal lines and there was
	another variation that did the networking.

    The PDP117 had lots of lights, and if you were running RSTS it ran in a
    great pattern - until we installed the RDC Panel.  We had some
    customers refuse to have a panel installed because they could not see
    the lights running.

    of course, that should have read PDP1170 ...

                                               
    Lights were fun.  On the PDP-10 back in college (oh...18 years ago
    now), several of us students who spent a fair amount of time in the
    computer lab decided to program the lights so that they would do
    strange and interesting things.
    
    The computer was glassed in, so we positioned ourselves in a darkened
    room across the hallway with visual access to the light panel.  When
    the night computer operator went in to mount tapes, we had the lights
    run back and forth across the console.  The reaction of the operator 
    (who was almost always under the influence of a smokable substance) 
    gave us one of the best laughs we ever had.  
    
    Cindy

    
    	They DID use PDP8s to front end the KI10 Comms.  Can't remember
    much about it now, but they had one on the KI10 at Hatfield Poly many
    years ago.
    
    	The neat thing about using PDP8s and PDP15s (and their
    predecessors) was the way that 12 bit and 18 bit words mapped neatly
    into 36 bit words making transfers between them, and the DECsystem 10
    very convenient.
    
    	I've got one of those old white on blue "decsystem10" stickers in
    my cube.  Mighty proud of it too!
    
    				Malcolm.

    	Does anyone know the order of appearance of light patterns? I
    believe RSX-11M and RTS-8 were the earliest (in that order). Later I
    saw a DECsystem 10 where someone had programmed the lights on the top
    of each cabinet to run a pattern rotating right round the room. I also
    saw a room full of video terminals (VT52s) with a little train that ran
    off one screen on to the next right round the room. That was on the
    TPM70 operating system on a PDP-11/70. I liked the RT-11 light pattern,
    but a little train running round the room has to beat that.
    
    	For those who think the light patterns were just toys, they were a
    very effective system monitoring tool. A corner-of-the-eye glance would
    tell you if the system was operating normally, and approximately how
    heavily it was loaded.

And RSTS/E could rotate a pattern through the *address 
lights* on an 11/70.

Now *that* was the product of a seriously deranged mind.
Whoever it was, I salute you (if you're still around
and reading this).

    	The RTS-8 pattern rotated through the address lights, too, and the
    TOPS-10 one was going through memory controllers, disk controllers, ...
    since they all had a row of lights across the top of the cabinet. The
    RTS-8 pattern rotating through the address lights was courtesy of
    Richard Lary, who I think is still around. I last heard of him in disk
    engineering.
    
    	The interesting thing about these is that most of them were
    counter-intuitive in their behaviour on a time sharing system. They
    "counted" every interrupt, so on an idle machine they would run fairly
    slowly, since only the clock would be interrupting. On a busy machine,
    particularly with a lot of terminal line and disk interrupts, they
    would be running much faster. Many users wondered why the "null job"
    ran faster when the machine as a whole was running their job slower ;-)

    
    I have about 170 1184s and 1183s running RSTS 9.5 and the 7-segment 
    LEDS on the front panel rotate during idle time.

    The Orion Project was the 11/73, 83 and 84, both box, cab and pedistal
    versions, the display was a one of the fun things we had to work with
    during development and intro. Bending air was the other fun thing.

	I just finished a contract about a month ago and the board had
a row of 8 leds to be used in the event of a crash. I put the old RSX
rotateing pattern there and everyone old enough knew what it was !!

    I used to work on a KA10 that had some awful terminal multiplexer
    on it (DC10?).  This was replaced by something driven by a PDP-8/i
    with some special boards in it, build by a company in Georgia.
    (DCA?)  This was able to keep up with all those swift 300b terminals
    without bringing the KA10 to its knees with interrupts.
    
    There was no on-site support for this thing, of course, as the
    company I worked for did not want to pay for it.  I remember one
    evening sitting on the floor of the computer lab, surrounded by
    circuit diagrams, probing the multiplexer board with an oscilloscope,
    with the phone in one ear talking to the engineer in Atlanta.
    
    We finally figured out that the capacitors in the main clock
    multivibrator had gone bad.  I tried getting replacements from a
    lab in another part of the building where they designed electronic
    stuff, but they could not find any, or had no process for giving me
    any, or some such thing.  So I went across the street to Radio
    Shack and bought a bag of capacitors and made the repair.
    
    I was on staff as a system programmer, not a repair man.
    
    Oh yeah: I diagnosed and repaired a fault in the KA10s comparator
    logic, and another in the floating point unit.  A complete set of
    circuit diagrams for a KA10 was a rather slim volume.

I think all PDP11 operating systems other than DOS had light patterns,
each different (so you could tell the OS from the lights).  But I don't
remember what Mumps or Unix lights looked like...

My PRO (running RSTS) displays the RSTS lights patterns on the LK201 
keyboard lights when it has nothing better to do... :-)

	paul

    
.65>  >	I don't recall the PDP-11 front-ending a LCG machine until the KL10.
.65>  
.65>  Actually, the KI-10 was front-ended by a DC76 which was a pdp 11/40
.65>  which talked to the KI-10 memory via a DL-10.
.65>  
.65>  Unfortunately, the DC-76 interrupted TOPS-10 for each character instead
.65>  of buffering them.
    
    The first sentence uses "front-ending" in terms of the console, not
    user terminal communications. KA's and KI's had lights and switches;
    the KL had an 11 in their place. After you got used to reading the
    indictors and playing the octal keyboard, switching over to a "smart"
    console was initially a lot like driving with boxing gloves, mukluks
    and cheap sunglasses.
    

re .81

Reminds me of the case, where I had to prove to our service engineer, that
something was wrong in our PDP-11's HW by showing him from a crash dump,
that instructions weren't executed logically as they should. Otherwise,
it had been my system level code, which were to be blamed about repeated 
crashes.

He finally believed me, checked the system again and found a blown
condensator from the power supply, which allowed pikes from the electricity 
network to pass to system logic. Replacing that fixed the problem.

I didn't have HW diagrams, but I did have an operating system listing ;-).

--Ritva 

    I wrote a small, very simple minded lights program to
    display in the accumulator lights of the PDP-10.
    (excu-u-u-u-se me DECsystem-10!)
    
    Nothing very great, but it got a rise out of operations!
    
    Dave

>     <<< Note 3239.67 by STAR::PARKE "True Engineers Combat Obfuscation" >>>
>
>    Speaking of front ending.  
>    
>    I was working at Pitt, many years ago, when our lead 10 type went
>    west to work on the KA-10(s?) used to front end the ILLIAC-IV.  Shortly
>    the terminal concentrator guru for the 11s (yes we were doing this in
>    the early 70s) left to go to the same place to work on the 11s
>    frontending the 10s front ending the ILLIAC.
    
	It was a KI10.  All the magtape and other peripherals were run off
	PDP-11s to the KI10 which also had a huge laser-type (write once read 
	many) storage array.  All the data was collected by the PDP-11s and
	fed to the KI10.  The KI10 would then feed a Burroughs 6600 THROUGH a
	PDP-11/40.  The 6600 had three huge (physically) disks that were
	electronically synchronized to feed the ILLIAC in the fastest possible
	way.

    I have in my office a rack mounted 2100 with a 16 segment alpha-numeric
    display on the front. You can alter the text displayed with a console
    command. Does anybody know if you can alter it from VMS?
    
    rgds ted 

I used to be involved with DECsystem-10s for many a year.


As was mentioned before, the PDP-6, KA-10, and KI-10 used a "real" console of
lights and switches.  The KL-10 used a PDP-11/40 as a smart front end, running a
bastardized version of RSX called RSX-20F.  The KL10 had connections for up to
four PDP-11 based front ends - the console, and three for communications. Each
connection was called a DTE-20.

On "high-boy" KL10s (1080, 1090), the CFE [console front end] connected all the
unit-record devices: card punch, card reader, line printer.  Terminals were
_not_ supported (although they did work if plugged in, at least from TOPS-10
7.01/RSX-20F 14-45 and on.)

The extra DTE-20s could be connected to PDP-11 based systems running ANF-10, a
networking OS that supported unit record devices, terminals, and
point-to-point/multipoint networking lines. (On KI10s you used DL10 adapter
boxes to do the same thing.  These allowed a piece of -10 memory to be
double-mapped between the two systems.) 

These features allowed sites to create remote terminal clusters - yet another
PDP-11 with card reader and/or one or more lineprinters - miles away from the
actual systems, connected up by one or more point-to-point lines.

The ANF-10 software in the remote node would allow the terminal user to choose
what TOPS-10 system s/he wanted to connect to.  The -10 noted where you were,
and set things up so that when you typed "PRINT foo.bar", it printed at your
_local_ printer instead of at the far-off computer center's printers.  Same with
batch job output.

One nice thing about ANF-10 that DECnet didn't have for the longest time is that
if you had two or more comm lines of identical capacity between nodes, ANF-10
would split the network traffic evenly among them -- thus giving you very high
capacity.  

You could create a rather elaborate network of 10s and variously-configured
PDP-11s.


When I arrived in 1983, Digital had an _extremely_ elaborate ANF-10 network
connecting up all of our worldwide manufacturing sites, as well as the machines
that ran Payroll, Personnel, the Dick Best list, etc.  We had _just_ started to
dismantle it in favor of a DECnet-based setup.  A shame...

On "low-boy" KL10s (1091, 2040 through 2060), the CFE supported both unit record
equipment and terminal lines.  ANF-10 was not supported by TOPS-20, so the
remote computing prospects for -20s weren't as great until DECnet came along.


John

     
    There are still a couple of Decsystem 20's running in Detroit. They
    are scheduled to be unplugged in a couple of weeks, at which time they
    will be sold for 20 dollars a ton.  There are about 40 RP06's and RP07's,
    and a few RP20's, so we're talking some real tonnage here.
    
    
    
    bill
    

    I still remember the day, many years ago in another life, when the
    nasty man came and took all our PDP 11/70's lights away, and replaced
    them with a dead-looking remote diagnostics gizmo.
    
    Laurie.

    RE: .90
    
>   I still remember the day, many years ago in another life, when the
>   nasty man came and took all our PDP 11/70's lights away, and replaced
>   them with a dead-looking remote diagnostics gizmo.
    
    Yeah I hated that too.  So did dozens of others I spoke to at DECUS.
    
    I could have made a KILLING if I'd had the smarts to fabricate a
    Y-Cable device to allow BOTH the lights panel and the RDC panel 
    to operate together.  'Surprised no 3rd-party h/w companies ever did it.
    
    Rick

	The thing that many people did not realize about the RDC panel was the
added features it gave the FE. Things that required a scope could be displayed
via command. Having been part or the original DDC and working through the 
RDC panel I gained a different mode of troubleshooting that helped out later
when the light were removed from all devices.  The blinking lights were great,
but the noise they generated put an end to their use on future product. If I'm
not mistaken a FCC edict to the industry put an end to light panels.


Keith

    Re .92-
    
>	The thing that many people did not realize about the RDC panel was the
>added features it gave the FE. Things that required a scope could be displayed
>via command. 
    
    	Yeah, cute feature, but we were used to the "Rolling Arm" method of
    flipping the front panel switches and CoUlDnT TyPe WeLl. This "feature"
    took a while to get used to. 
    
    >						The blinking lights were great,
>but the noise they generated put an end to their use on future product. If I'm
>not mistaken a FCC edict to the industry put an end to light panels.
    
    	IMHO, the FCC and (especially) the EPA (currently) edicts have made
    cost of maintenance for old high-tech equipment reach an impasse where it
    is more acceptable to trash it than make it comply with the rules.
    
    	My solution? Simple. Freight all "trash" technology to them
    anonomously. Why? They offer no solutions, merely "rules" for use &
    disposal. Kind of like getting rid of used motor oil. You _should_
    recycle it, but no one openly accepts it.
    
    	Comments on this welcome.
    
    Phil

    I wrote the idle loop for MUMPS-11. It was a long time ago.
    I believe the lights started in the middle and worked out in
    both directions. It was alright but RSX-11/M and RSTS/E had the
    best in my mind but they got to pick first. It was just not the
    thing to do to copy someone elses pattern.
    
    	Ed
    

    I also remember our PDP 11/70s at Oxford Regional health Authority have
    the RDC module put in instead of the light panel. I still remember the
    boot command (I think):
    
    17765744G
    
    
    Simon

    I wrote the "RSTS/E rotates the memory address lights" routine during
    an especially boring meeting in the 70's. You had to set the memory
    address light display to "Supervisor virtual" -- displaying arbitrary
    physical address was impossible, arbitrary virtual addresses merely a
    challenge. A PC address could never be odd on a -11 so the bit 0 light
    could never get turned on. For symmetry I decided to disallow turning
    on the bit 15 light a well (though that was an arbitrary decision). The
    memory management on an -11 dealt with physical memory in 64-byte
    chunks. So I used a 64-byte piece of memory and placed the right
    instructions (a WAIT and then (as I recall) a RETURN (aka RTS PC)) in
    the right locations, adjusted the Supervisor memory mapping, and let
    the -11 to the display work (the WAIT displayed R0 in the data lights
    and the PC address +2 in the address lights until the next interrupt).
    
    The actual pattern used by RSTS/E was just a random choice. The above
    memory address light stuff worked with any pattern. Of course, each -11
    operating system had its own unique pattern. It was the way we told
    what was running by simply walking up and looking at the front console.
    
    When the 7-segment LEDs were introduced they displayed whatever you
    dialed up and they displayed in octal. We built a count down null job
    for those but, of course, octal would never do -- the job counted down
    in decimal. All it took was finding the right combination of octal
    digits to quickly flash between for the eye to integrate it into the
    right decimal digit for the missing 8 and 9. Again, a simple technique
    that mystified many...

    These notes (and some of the names associated with them) bring back
    fond memories.
    
    Thanks everyone.
    
    Bob
    

    
    re .96 and the lights - way back in the PDP-1 days, one of our favorite
    hacks (back when "hacking" meant playing) was to write a short program
    that would stop with a message spelled out in the front panel lights.
    On the PDP-1 there were 5 16 bit registers displayed on the front
    panel, so you could spell out a 4 letter word in 3x5 "dot matrix"
    cells.  If I recall correctly, the 5 registers were the accumulator
    (AC), the i/o register (IO), the program counter (what "PC" used to
    stand for), the memory address register (MA), and the memory buffer
    register (MB).
    
    len.
    

    RE: .98
    
    The funniest PDP-1 lights hack I ever saw, was a program called:
    
    "Not Running".  
    
    It typed out on the SOROBAN typewriter, over and over again:
    
    	Kindly notice that the machine is not running.
    
    If you looked at the run light, sure enough, it was true!
    The run light was off!  Not only that, but it was real hard
    to stop!  (I'm not kidding... There's a story here, of course)
    
    Dave
    

    A friend of ours over in AKO -- Dave AKOCOA::FARMER -- wants to know
    how fast, in MIPS equivalent, the PDP11/20 was.  I took a fast look at
    my copy of DIGITAL AT WORK (edited by Jamie Parker Pearson) but it
    doesn't include that spec.  Anyone with reliable info -- please, if you
    want, post your answer here; but it'd be best to EMail it to Dave.
    
    Tnx!
    
    (Cross-posted in HUMANE::DIGITAL, BACK40::SOAPBOX, TURRIS::WOMANNOTES-V5)
    

  And, of course, the obligatory pointers:

  If you don't already have PROXY::PDP_11 in your notebook and
  would like to add it, press <KP7> or <Select> or type "SELECT"
  and the conference will be added to your notebook.

  Another good resource would be MSDOA::PDP_HOME_COMPANION

                                   Atlant
                              (Moderates both)

Speaking of slow instructions,
you didn't include WAIT in your calculations.

It could take up to 20mS to execute (or even longer if
the line-frequency clock interrupts weren't enabled).

That makes a RESET seem positively zippy.

    	Ah, yes, I remember the FUD from DG, that some PDP-11 instructions
    can take up to 20mS to complete. They never seemed to catch on to the
    fact that some VAX instructions could take up to 53 page faults to
    complete.

    
    Of course, that's lightning compared to the PDP-10 which
    could operate at tending-to-zero-instructions-per-
    second without actually being halted.
    
    In		Z @.
    
    the CPU never finishes the effective-address computation, so
    never gets round to executing the instruction.  Any instruction
    will do in place of the Z (opcode zero; don't think it did anything)
    since it won't get executed.
    
    Fortunately, effective address computation was interruptible
    so you'd eventually use up your CPU quota and the monitor would
    kill your program.   You could use up say 30 secs of CPU without
    having finished a single instruction!
    
    
                                        

Re .105:

>Any instruction
>    will do in place of the Z (opcode zero; don't think it did anything)
>    since it won't get executed.

It would ILLUUO (unless your O/S ascribes a meaning to the opcode).
				/AHM

    	You *can* produce an instruction with VAX/VMS that never completes.
    As implied in .104, you can construct an instruction that requires more
    than 50 pages in the working set to complete. This is around the
    maximum needed for full address resolution of the instruction, but if a
    page fault occurrs before address resolution is complete the
    instruction is restarted on completion of the page fault. If you try to
    run such an instruction in a working set of less than 50 pages then you
    go into a continuous cycle of 
    pagefault, restart instruction, pagefault, restart instruction, ...
    
    	For those who want intellectual amusement, or maybe want to
    challenge my "53 pages" figure, this is the way you start.
    You JMP to an instruction that is not in memory, so you trigger a page
    fault. To fault in a page the page table that maps that page must be in
    memory, and by chance, in this case it is not, so that fault must be
    taken first. You have two page faults just to get the opcode in memory.
    Obviously it is not a 1 byte instruction, and it happens to cross a
    page boundary, and neither the following page nor *its* page table page
    are in memory, so you now have 4 page faults just to get the
    instruction into memory. Apply similar logic to all of the parameters
    of one of the more complex instructions...