On Feb 13, 2013, at 12:57 PM, Johnny Billquist wrote:
On 2013-02-13 18:52, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 11:12 AM, Johnny Billquist wrote:
...
Fun detail: when devices want to MOP boot on a network where you have both a VAX and a PDP-11, the PDP-11 normally ends up serving the image, since it responds much faster than the VAX.
That's because the VMS MOP server did its lookup for a match in the node database by a linear search. I never could convince the engineer responsible for that code to use a better algorithm.
Which is silly in it self. Why even search the node database? After all, the MOP request holds all the information needed to serve it. RSX don't do a lookup at a boot request. It just serves it.
I thought at least primary boot requests tend to just say "help me" so you need a lookup to find the name of the file to load.
paul
On Wed, Feb 13, 2013 at 1:21 PM, Johnny Billquist <bqt at softjar.se> wrote:
I know of plenty of PDP-11s still running in production
No doubt. They were (are) excellent systems and used in amazing places. I know of newspaper system that used PDP-11's to control the presses and a VAX to link it all up. I know the Vax was replaced by a Unix box a few years ago, but last I knew the PDP-11s were still running the presses.
Can't say I've stumbled into any Masscomp machines,
I still see them in pictures that run in Mission Control at NASA (they are the consoles that the controllers are using - I have one of them in collect - its the machine I have here with a working 9 track drive). I believe that a number of places in the US and in NATO with names like "Federal Technologies" still have them ;-). To this day, they are unmatched in analog I/O. They had a standard a piece of hardware LDP wanted to make for DEC but never did (a bus with a microcoded controller that could sample analog I/O at an incredible rate).
As a company, Masscomp actually still exists, unlike DEC sadly. The company is now called Concurrent Computer (CCUR), but Masscomp was surviving legal entry when the Masscomp BoD decided to buy Perkin-Elmer's computer Division in the early 1990s. I still have some wall paper that has only sentimental value after all of the reverse splits etc.
Clem
Fun fact:
Many people never knew it, but if you looked under the disk cabinet on the later 500s and 5000s there are screw mounts on every rack mount system that did not seem to be used. They were for the "optional" C4 charges that certain customers needs to mount when there was not enough time to erase the disk but ensure it was unreadable. Although I got to see them in a deployed system in the UK, I never saw that C4 option actually "exec'ed."
bash-4.0# ncl < start_routing.ncl
Node 0 CSMA-CD
AT 2013-02-13-13:27:14.048-05:00I-----
FAILED IN DIRECTIVE: Create
DUE TO: Error specific to this entity's class
REASON: Already Exists
Description: Already Exists
Node 0 CSMA-CD Station csmacd-1
AT 2013-02-13-13:27:14.062-05:00I-----
FAILED IN DIRECTIVE: Create
DUE TO: Error specific to this entity's class
REASON: Already Exists
Description: A Station with this name already exists
Node 0
AT 2013-02-13-13:27:14.091-05:00I-----
FAILED IN DIRECTIVE: Create
DUE TO: No such Entity Instance exists
Node 0 Routing
AT 2013-02-13-13:27:14.114-05:00I-----
FAILED IN DIRECTIVE: Set
DUE TO: No such Entity Instance exists
Node 0 Routing
AT 2013-02-13-13:27:14.121-05:00I-----
FAILED IN DIRECTIVE: Set
DUE TO: No such Entity Instance exists
Node 0 Routing
AT 2013-02-13-13:27:14.126-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: No such Entity Instance exists
bash-4.0# cat start_routing.ncl
create csma-cd
create csma-cd station csmacd-1 communication port tu0
enable csma-cd station csmacd-1
create routing circuit circuit-1 type csma-cd
#
# The following command sets the inactive area address, which is used
# to enable transmission and receipt of ISO 8473 Inactive Subset PDUs,
# also known as Null Internet. This functionality is disabled by
# default. To enable Null Internet, remove the comment character
# from the following command.
#
create node 0 routing type endnode
set node 0 routing phaseiv address = 9.3
enable node 0 routing
set node 0 routing circuit circuit-1 enable phaseiv address true
set node 0 routing circuit circuit-1 data link entity csma-cd station csmacd-1
enable node 0 routing circuit circuit-1
If the stuff already exists, why is the second half of the script failing?
----- Original Message -----
From: "Kari Uusim ki" <uusimaki at exdecfinland.org>
To: hecnet at Update.UU.SE
Sent: Wednesday, February 13, 2013 1:39:27 PM
Subject: Re: [HECnet] DECnet-Plus and Phase IV Issues
On 13.2.2013 20:23, b4 at gewt.net wrote:
------------------------------------------------------------------------
*From: *b4 at gewt.net
*To: *hecnet at update.uu.se
*Sent: *Wednesday, February 13, 2013 1:09:03 PM
*Subject: *[HECnet] DECnet-Plus and Phase IV Issues
Hello!
I (think) I am following the correct NCL syntax here...but..
ncl> create node 0 routing circuit csmacd-0 type = csma-cd
ncl> set node 0 routing circuit csmacd-0 data link entity csma-cd
Here should be the data link entity defined completely as is done below.
It would be more clear if you use another name for the routing circuit
entity than is used for the csma-cd station entity.
ncl> set node 0 routing circuit csmacd-0 enable phaseiv address true
ncl> enable node 0 routing circuit csmacd-0
Node 0 Routing Circuit csmacd-0
AT 2013-02-13-13:05:26.514-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: Error specific to this entity's class
REASON: Open Port Failed
Description: The Open Port call to the specified Data Link failed
Any ideas what i'm doing wrong?
____
This is the script:
create csma-cd
create csma-cd station csmacd-1 communication port tu0
enable csma-cd station csmacd-1
create routing circuit circuit-1 type csma-cd
#
# The following command sets the inactive area address, which is used
# to enable transmission and receipt of ISO 8473 Inactive Subset PDUs,
# also known as Null Internet. This functionality is disabled by
# default. To enable Null Internet, remove the comment character
# from the following command.
#
create node 0 routing type endnode
set node 0 routing phaseiv address = 9.3
enable node 0 routing
set routing circuit circuit-1 enable phaseiv address true
set routing circuit circuit-1 data link entity csma-cd station csmacd-1
enable routing circuit circuit-1
On 13.2.2013 20:23, b4 at gewt.net wrote:
------------------------------------------------------------------------
*From: *b4 at gewt.net
*To: *hecnet at update.uu.se
*Sent: *Wednesday, February 13, 2013 1:09:03 PM
*Subject: *[HECnet] DECnet-Plus and Phase IV Issues
Hello!
I (think) I am following the correct NCL syntax here...but..
ncl> create node 0 routing circuit csmacd-0 type = csma-cd
ncl> set node 0 routing circuit csmacd-0 data link entity csma-cd
Here should be the data link entity defined completely as is done below.
It would be more clear if you use another name for the routing circuit entity than is used for the csma-cd station entity.
ncl> set node 0 routing circuit csmacd-0 enable phaseiv address true
ncl> enable node 0 routing circuit csmacd-0
Node 0 Routing Circuit csmacd-0
AT 2013-02-13-13:05:26.514-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: Error specific to this entity's class
REASON: Open Port Failed
Description: The Open Port call to the specified Data Link failed
Any ideas what i'm doing wrong?
____
This is the script:
create csma-cd
create csma-cd station csmacd-1 communication port tu0
enable csma-cd station csmacd-1
create routing circuit circuit-1 type csma-cd
#
# The following command sets the inactive area address, which is used
# to enable transmission and receipt of ISO 8473 Inactive Subset PDUs,
# also known as Null Internet. This functionality is disabled by
# default. To enable Null Internet, remove the comment character
# from the following command.
#
create node 0 routing type endnode
set node 0 routing phaseiv address = 9.3
enable node 0 routing
set routing circuit circuit-1 enable phaseiv address true
set routing circuit circuit-1 data link entity csma-cd station csmacd-1
enable routing circuit circuit-1
From: b4 at gewt.net
To: hecnet at update.uu.se
Sent: Wednesday, February 13, 2013 1:09:03 PM
Subject: [HECnet] DECnet-Plus and Phase IV Issues
Hello!
I (think) I am following the correct NCL syntax here...but..
ncl> create node 0 routing circuit csmacd-0 type = csma-cd
ncl> set node 0 routing circuit csmacd-0 data link entity csma-cd
ncl> set node 0 routing circuit csmacd-0 enable phaseiv address true
ncl> enable node 0 routing circuit csmacd-0
Node 0 Routing Circuit csmacd-0
AT 2013-02-13-13:05:26.514-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: Error specific to this entity's class
REASON: Open Port Failed
Description: The Open Port call to the specified Data Link failed
Any ideas what i'm doing wrong?
____
This is the script:
create csma-cd create csma-cd station csmacd-1 communication port tu0 enable csma-cd station csmacd-1 create routing circuit circuit-1 type csma-cd # # The following command sets the inactive area address, which is used # to enable transmission and receipt of ISO 8473 Inactive Subset PDUs, # also known as Null Internet. This functionality is disabled by # default. To enable Null Internet, remove the comment character # from the following command. # create node 0 routing type endnode set node 0 routing phaseiv address = 9.3 enable node 0 routing set routing circuit circuit-1 enable phaseiv address true set routing circuit circuit-1 data link entity csma-cd station csmacd-1 enable routing circuit circuit-1
On 2013-02-13 19:12, Clem Cole wrote:
On Wed, Feb 13, 2013 at 11:12 AM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
DEC let the PDP-11 live as a niche product for small realtime use,
where they did recognize that the VAX just could not compete because
of price. But faster and larger PDP-11 models would have cut into
their VAX business, and thus it did not happen, even though
customers wanted.
Oh, how I know. (more in a minute).
Fair enough, but I really think it was a little different as I lived
that era. From talking to them, as I understand it a number of DEC
folks in Laboratory Products Division (LDP) very much wanted the Vax
line to be able to sell into the RT business and deal with some of the
issues you expressed. But I don't think DEC was afraid of the 11
moving up, but more that they started to walk away from the RT business.
They wanted the commercial customer and with the VAX they were
starting to be competitive there and basically stopped investing.
I was one of the early Masscomp guys, which was made up a lot of folks
who had been in LDP, a number of ex-CPU guys from Vax (780, 750, 730),
and the PDP-11 (at least the 34), a number of ex-DEC SW types who had
done RSX, RT11, VMS, the compilers etc. Masscomp built the first Real
Time Unix machine (and the first commercial UNIX multiprocessor but
that's another story). The sales guys were always trying to get us to
add RSX or RT11 "features" (inc DECNet) We did build ASTs but never
did QIO, although tjt did build a solution that offered the same effect
with slightly different semantics. I'm the one that blocked DECnet and
said - IP/TCP was the way to go (which would prove to be the right choice).
But the real key was when Masscomp got a number of the old DEC compiler
team back together and built the original Masscomp FORTRAN compiler what
could accept VMS FTN syntax, we never lost a competitive sale to RSX (or
RT11), and usually beat the Vaxen of that day [and was always why we
were 10-20% faster than Sun for the longest time using the same 10Mhz
68000 chip - we had a better compiler].
I remember that around that time we got a nasty gram from KO [I wonder
who has that letter these days].
Dave Cane (who had been the 750 lead) once said that the MC-500 (the
original Masscomp machine) was what he had hope the 750 could have been;
but DEC would not let him.
Anyway - my point is that it was the compilers, more than the HW or the
OS that actually was the key feature the traditional RT customer really
care about -- no matter if it was a VAX and 11 or one of the 68K base
systems; and what DEC did was lose focus for that customer - hence the
value of doing some of the things you mentioned was lost.
Well. Customers staying with PDP-11 and not upgrading to VAXen was not because of compilers.
And it was not because the customers didn't want faster machines either, easily proved by the large aftermarket for upgrading PDP-11s. Some of that market still lives, even though both the PDP-11 and DEC have officially been dead for over 10 years now...
You are not the only one who lived in that era...
Face it - DEC wanted customers to buy VAXen, if at all possible. Lots of customers stayed with PDP-11 anyway. I know of plenty of PDP-11s still running in production. Can't say I've stumbled into any Masscomp machines, but I admit that I have not been looking.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Wed, Feb 13, 2013 at 11:12 AM, Johnny Billquist <bqt at softjar.se> wrote:
DEC let the PDP-11 live as a niche product for small realtime use, where they did recognize that the VAX just could not compete because of price. But faster and larger PDP-11 models would have cut into their VAX business, and thus it did not happen, even though customers wanted.
Oh, how I know. (more in a minute).
Fair enough, but I really think it was a little different as I lived that era. From talking to them, as I understand it a number of DEC folks in Laboratory Products Division (LDP) very much wanted the Vax line to be able to sell into the RT business and deal with some of the issues you expressed. But I don't think DEC was afraid of the 11 moving up, but more that they started to walk away from the RT business. They wanted the commercial customer and with the VAX they were starting to be competitive there and basically stopped investing.
I was one of the early Masscomp guys, which was made up a lot of folks who had been in LDP, a number of ex-CPU guys from Vax (780, 750, 730), and the PDP-11 (at least the 34), a number of ex-DEC SW types who had done RSX, RT11, VMS, the compilers etc. Masscomp built the first Real Time Unix machine (and the first commercial UNIX multiprocessor but that's another story). The sales guys were always trying to get us to add RSX or RT11 "features" (inc DECNet) We did build ASTs but never did QIO, although tjt did build a solution that offered the same effect with slightly different semantics. I'm the one that blocked DECnet and said - IP/TCP was the way to go (which would prove to be the right choice).
But the real key was when Masscomp got a number of the old DEC compiler team back together and built the original Masscomp FORTRAN compiler what could accept VMS FTN syntax, we never lost a competitive sale to RSX (or RT11), and usually beat the Vaxen of that day [and was always why we were 10-20% faster than Sun for the longest time using the same 10Mhz 68000 chip - we had a better compiler].
I remember that around that time we got a nasty gram from KO [I wonder who has that letter these days].
Dave Cane (who had been the 750 lead) once said that the MC-500 (the original Masscomp machine) was what he had hope the 750 could have been; but DEC would not let him.
Anyway - my point is that it was the compilers, more than the HW or the OS that actually was the key feature the traditional RT customer really care about -- no matter if it was a VAX and 11 or one of the 68K base systems; and what DEC did was lose focus for that customer - hence the value of doing some of the things you mentioned was lost.
Clem
Hello!
I (think) I am following the correct NCL syntax here...but..
ncl> create node 0 routing circuit csmacd-0 type = csma-cd
ncl> set node 0 routing circuit csmacd-0 data link entity csma-cd
ncl> set node 0 routing circuit csmacd-0 enable phaseiv address true
ncl> enable node 0 routing circuit csmacd-0
Node 0 Routing Circuit csmacd-0
AT 2013-02-13-13:05:26.514-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: Error specific to this entity's class
REASON: Open Port Failed
Description: The Open Port call to the specified Data Link failed
Any ideas what i'm doing wrong?
On 2013-02-13 18:52, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 11:12 AM, Johnny Billquist wrote:
On 2013-02-13 16:09, Clem Cole wrote:
On Tue, Feb 12, 2013 at 8:08 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Well, the 11/70 easily outlived the 11/44, in that 11/70 machines
were still sold after the 11/44 was terminated, as far as I know.
Interesting data. I'm a little surprised to hear it because DEC was
clearly trying to get the traditional 11/70 customer to move to the VAX
line in those days.
Oh, DEC tried. It was just that the VAXen didn't deliver the goods for all customers. The real pain point was realtime stuff. Interrupt latencies on a VAX is horrible compared to a PDP-11. And VMS don't help.
I still have an RT-32 button from when the RT-11 folks were subversively pushing the notion that they could make a VAX do realtime.
:-)
I've posted it before, but the current comment in the RSX sources are fun:
;+
; If we cannot process a clock interrupt within 10 seconds, we are
; no longer processing in real time, and we may as well become
; a VAX ... Call an end to this ... NOW!
;-
BGCK$A BF.SAN,BE.IDC,<FATAL> ;;; System massively confused
Fun detail: when devices want to MOP boot on a network where you have both a VAX and a PDP-11, the PDP-11 normally ends up serving the image, since it responds much faster than the VAX.
That's because the VMS MOP server did its lookup for a match in the node database by a linear search. I never could convince the engineer responsible for that code to use a better algorithm.
Which is silly in it self. Why even search the node database? After all, the MOP request holds all the information needed to serve it. RSX don't do a lookup at a boot request. It just serves it.
But even so, it is surprising that even a fairly modern VAX can't keep up with a PDP-11 here.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-13 17:58, Bill Pechter wrote:
On Wed, Feb 13, 2013 at 10:09 AM, Clem Cole <clemc at ccc.com
<mailto:clemc at ccc.com>> wrote:
On Tue, Feb 12, 2013 at 8:08 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Well, the 11/70 easily outlived the 11/44, in that 11/70
machines were still sold after the 11/44 was terminated, as far
as I know.
Interesting data. I'm a little surprised to hear it because DEC
was clearly trying to get the traditional 11/70 customer to move to
the VAX line in those days. I wonder if the 70 was used in some
commercial settings where they wanted a real duplicate. Unlike the
Nova/Esclipe the VAX had a "compatibility mode" but it was a tad
impure. The OS was different and binaries did not work with some
assistance. Other than running Dungeon and few other games, I
never knew a customer that used compatibility mode in production -
it was a great sales tools, but once folks got their VAX they tended
to do a "full port" of the code. So swapping a VAX besides
costing more, meant some systems/SW work on the customers part.
That was not true of the 11/44.
I remember buying an 11/44 for use where we did not need (could not
afford an VAX for that use) but wanted the larger address space over
the 40 class machines. We had a very large 11/70 and were also
buying Vaxen at the time,
That particular machine was the last 11 I ever personally was part
of the purchase and I moved on to other things, so I sort of stopped
watching the progress of the PDP11 line. I know the QBUS gave the
11 some amount of resurgence, although by then most of us were using
Vaxen or 68K based UNIX boxes.
Thanks for the information.
Clem
I thought the 11/70 couldn't be sold past about 1984 or 85.
Some FCC Regulations on emissions blocked new ones. They didn't want to
reengineer and retrofit them.
As far as I remember and understand, that was the case for the original 11/70. And I understood it that the DEC DATASYSTEM 570 (ie, the 11//0 in a corporate cabinet) was done to solve the FCC issues.
They pulled back all the ones they could from the field and regional
offices (replacing some with the rare 11/74 KB11Cm boxes) so they could
sell refurbs to AT&T (who purchased a ton for COSMOS and other network
functions).
I worked at DEC in 1986, and we had at least four 11/70 machines (all corporate cabinets) running at that point in the office.
I know and heard of lots of other 11/70 machines out in the field way later than that too. I think it was something like 911 in Los Angeles who ran on a couple of 11/70 into 2000 or beyond, for example.
I had the fun of troubleshooting an 11/74 single cpu and parts were
really rare.
I bet. I wish I had one. I've seen the pictures of CASTOR, with all four CPUs, but the whereabouts of that machine now is unknown. It was dismantled in 2000 or 2001, if I remember right.
I seem to remember 11/44's being sold until the 11/84 came out. A
google search said it was in '88, two years after I left DEC...
The 11/84 came out way earlier.
The technical manual for it that I have is dated 1985.
(See http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1184/)
I can believe that the 11/84 made the 11/44 obsolete, however. They fulfill the same niche, with the 11/84 being faster, smaller and probably cheaper.
I'm pretty sure the 11/70 may have outlived the 11/44 on used and refurb
boxes, only.
That might be.
Funny thing. I just read a little in the 11/44 Technical Manual, and it says it is meant for (among other things), TRAX, and refers to TRAX V2.0. That sounds like it must have been a product for more than a week, or else they released V2 super fast.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
