Does anyone still use (real) DEC line printers?
Rich Alderson
I have been asked to find out whether anyone still uses line printers on
their DEC systems. I'm not sure why the question came up, exactly, though
we have just sent a board design out for manufacture for a replacement
M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
JF Mezei
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems.
I recently moved my still functional LA75 from a VAX to my Xserve. It is
used to print labels. I got the foomatic plug in to CUPS (common unix
printing system) which invoked ghostscript (which I had to tweak to get
the right scaling for LA75 output).
So I can now print postscript to the LA75 either from postscfript source
or from any application on the macs.
On the VAX, I used the old DECprint for postcript to sixel printing
utility ( I think I was the only one in the world to purchase this).
So technically, I no longer have a dec line printer attached to a DEC
system.
Richard
Rich Alderson <ne...@alderson.users.panix.com> spake the secret code
<mddzksi...@panix5.panix.com> thusly:
>I have been asked to find out whether anyone still uses line printers on
>their DEC systems. [...]
I wonder how many people had an actual line printer and not an LA36 or
LA120. I have the terminals but not a line printer. I don't recall a
line printer being installed on the PDP-11/70 I used at UDel, but even
if it was installed it was in the machine room on the other side of
town. We used printing terminals for local printouts and a Xerox
laser printer (driven by 9-track tapes) for fancy printouts.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
FrankS
wrote:
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems.
Yes. I have a client that has two of them still running, plus an LG06
in storage.
Richard B. Gilbert
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
>
Do you mean "impact printers"?
I've been using LASER Printers almost exclusively for the last ten or
twelve years! The output is better looking, they are quiet, they are
fast and they are low maintenance.
H Vlems
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
>
> --
> the russet leaves of an autumn oak/inspire once again the failed poet/
> to take up his pen/and essay to place his meagre words upon the page...
Rich, could you clarify the question? Because I found "(real) DEC
line printers" somewhat vague.
To me the term lineprinter means : the ability to print one line (some
print an entire page) in one step, usually these
printers have a parallel interface (e.g. the LP11).
The point is: I have an LA75 which is IMHO *not* a lineprinter so I
didn't respond. It was used until 2000.
Then I learned that running DECnet on a pc allowed me to print from a
VMS queue to a pc with a printer connected to it.
At that time we had a Canon LBP660 which was a "Windows printer", i.e.
the printing logic was done by the pc not by the printer so only
Windows systems could use it.
It was replaced with an HP2100 and an HP1010, both behind an IP
printserver so VMS systems can print directly to it.
Unfortunaltely that trick doesn't work to a Samsung color laserjet,
but that is another story...
I still have the LA75 with a spare printhead and 5 ribbons (original
DEC!).
Which brings me to another point: how many printers were really
manufactured by DEC? I guess none, at least not those with a parallel
interface.
Hans
Neil Rieck
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
>
> --
> the russet leaves of an autumn oak/inspire once again the failed poet/
> to take up his pen/and essay to place his meagre words upon the page...
Sort of. We don't use the LP27 (which, IIRC, was a very cool line
printer employing a spinning band). We do still use an LA120 which
some people think of as a line printer although it is really a dot-
matrix printer with a keyboard.
NSR
billdeg
> I wonder how many people had an actual line printer and not an LA36 or
> LA120. I have the terminals but not a line printer. I don't recall a
> line printer being installed on the PDP-11/70 I used at UDel, but even
> if it was installed it was in the machine room on the other side of
> town. We used printing terminals for local printouts and a Xerox
> laser printer (driven by 9-track tapes) for fancy printouts.
> --
UDel? I teach there now and recently a la36 turned up. I teach
computer history.
Personally I have one line printer given to me with the pdp 8 I bought
in 08...I have not tested it. I do use a la36 as a terminal on my
IMSAI 8080.
I plan to install the line printer soon just to have it available for
printing if needed.
Bob Koehler
> Rich, could you clarify the question? Because I found "(real) DEC
> line printers" somewhat vague.
I think the classic menaing of "line printer" was a big heavy printer
that quickly printed an entire line at a time, such as the many LP11 we
had years ago.
Ben Myers
Ben Myers
Dennis Boone
> that quickly printed an entire line at a time, such as the many LP11 we
> had years ago.
A lot of people who never met a real line printer in person tend to
associate the term with anything that is wide carriage and prints
only text. The disease seems related to calling anything bigger than
a deskside chassis a "mainframe".
I prefer:
Line printer - Has a chain or band embossed with typewriter-style
characters, strikes multiple characters at a time with hammers. E.g.
the LP05.
Line matrix printer - Forms characters from individual dots, prints
parts of multiple characters at the same time by firing multiple
pins on a shuttle roughly the same width as the paper which moves
side-to-side along the paper. E.g. the Printronix P300.
Dot matrix printer - Forms characters from individual dots, prints
part of a single character at a time by firing one or multiple pins
on a print head a fraction of the width of the paper which moves
side-to-side along the paper. E.g. the ksr decwriters commonly used
as printers.
I tend to think of laser printers as "page printers".
No doubt someone will find an example which blows my neatly organized
universe all to hell. :)
De
Richard
billdeg <bil...@aol.com> spake the secret code
<073c9a1b-f815-486e...@l8g2000yqh.googlegroups.com> thusly:
>> [...] I don't recall a
>> line printer being installed on the PDP-11/70 I used at UDel, but even
>> if it was installed it was in the machine room on the other side of
>> town.
>
>UDel? I teach there now and recently a la36 turned up. I teach
>computer history.
I learned to program at udel, first in the computer center's terminal room
on open "demo" accounts and then later on my own account through
project Delta. <http://www.eecis.udel.edu/~mader/delta/>
They had a "PLATO @ 50" conference at the computer history museum
recently, and udel featured in some of the panels. I wrote an article
about it here:
<http://legalizeadulthood.wordpress.com/2010/06/28/plato50-conference/>
Richard
(Richard) legaliz...@mail.xmission.com spake the secret code
<idlujp$5qg$1...@news.xmission.com> thusly:
>I learned to program at udel, [...]
Also: I have at least one of most of the terminals I encountered at
udel at the time:
Smith Hall terminal room:
- Tektronix 4010
- HP2648A
- LA36 (don't have one with the APL character set, though)
- Zenith Z-29
- HP2621A
- HP2621P (with thermal printer in top)
Project Delta additionally had some Beehive CRT terminals. While I
have some Beehive terminals, I don't quite have complete functioning
terminals of the same model that Delta had. For a brief time, Delta
had a VT-52 and I don't have one of those, although I have several
VT-100s. Delta also had a modified IBM Selectric style printing
terminal for letter quality printer output, at a massive 34.5 baud.
Bob Koehler
>
> A lot of people who never met a real line printer in person tend to
> associate the term with anything that is wide carriage and prints
> only text. The disease seems related to calling anything bigger than
> a deskside chassis a "mainframe".
>
> I prefer:
>
> Line printer - Has a chain or band embossed with typewriter-style
> characters, strikes multiple characters at a time with hammers. E.g.
> the LP05.
I would also include those with a rotating character drum.
fishtoprecords
> their DEC systems.
Wow, we stopped using DEC line printers by 1980.
Were any of them really DEC designs? or were they all just OEM'd and a
DEC label put on them?
(OEM used in the proper sense, not the backward way DEC used the term
in the late 70s. Dana makes OEM axles used by Ford or GM)
Tim Shoppa
Some of them were Dataproducts printers with slightly modified
interfaces, others were engineered-from-scratch DEC designs.
I used to remember exactly what was tweaked between the DEC cabling
and the standard Dataproducts interface... they were very close but
something was inverted relative to the other? Maybe.
We kept a LP29 going (with some improvised spares) up through 2004 or
so. Print quality with a good ribbon on greenbar was outstanding.
Tim.
Tim Shoppa
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
Looking at the EOML... was the LP20 logic really a 4-board set? Wow.
It looks like a little microcoded processor in its own right. (I
suppose the same guy who did the RX02 did the LP20.) Did the LP20 try
to do hardware translation from every possible character set to every
possible band or something?
Tim.
John Wallace
Koehler) wrote:
The aforementioned LP05 was one of those with a rotating drum, was it
not? Some number of lines per minute using the big-letters-only drum,
or rather less lines per minutes with the alternate drum that included
lowercase, because the inter-character timing had to remain the same?
My current employers still have a couple of mature DEC-supplied
Mannesmann line matrix printers, connected to VMS boxes via the
DECserver 250 (which includes a DEC parallel line printer port). They
used to be used for things that still required multipart ("carbon")
forms. I don't think they've been used for two or more years, and
afaik there aren't any other printers onsite capable of doing
multipart forms, so I assume the requirement no longer exists at that
site. The industry they are in changes its practices somewhat slowly,
so if even they no longer use multipart, it seems likely not many
others do either. (They were still occasionally using paper tape for
data interchange in the 1980s, much to the disgust of the DEC field
service engineers tasked with fixing the high speed paper tape punch
in preparation for its annual exercise).
Inkjet printer ink has become a very profitable business sector.
glen herrmannsfeldt
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
All my printers are now connected to print servers, not to actual
computers. For DEC systems that have ethernet, that would seem to
be a fine way to me.
Or are you asking about "line" printers, that is, not page printers
or character (at a time) printers? I still have the Epson MX-100
that I got while still in grad school, though I haven't used it
in a long time. It has a line buffer and prints whole lines
at a time.
-- glen
Rich Alderson
> On Dec 6, 5:58=A0pm, Rich Alderson <n...@alderson.users.panix.com>
> wrote:
It's a three-board set (M8585, M8586, M8587 replaced by M8571). We've had no
luck with either the M8587 or the M8571, so our EE sat down with his CAD tools
and worked one up from the engineering drawings in our collection; it differs
from the original in having the ECOs applied pre-manufacture.
I don't think it's smart enough to do an everything to everything translation.
Rich Alderson
> Do you mean "impact printers"?
> I've been using LASER Printers almost exclusively for the last ten or
> twelve years! The output is better looking, they are quiet, they are
> fast and they are low maintenance.
Yes, impact printers capable of printing an entire line at a time, with a
print chain, train or band moving past fixed-position hammers.
Rich Alderson
Precisely.
--
Rich Alderson ne...@alderson.users.panix.com
Rich Alderson
>> I think the classic menaing of "line printer" was a big heavy printer
>> that quickly printed an entire line at a time, such as the many LP11 we
>> had years ago.
> A lot of people who never met a real line printer in person tend to
> associate the term with anything that is wide carriage and prints
> only text. The disease seems related to calling anything bigger than
> a deskside chassis a "mainframe".
> I prefer:
> Line printer - Has a chain or band embossed with typewriter-style
> characters, strikes multiple characters at a time with hammers. E.g.
> the LP05.
Or the LP27 which we have refurbished here at the museum and want to attach
to our KL-10 (2065) running Tops-10.
> Line matrix printer - Forms characters from individual dots, prints
> parts of multiple characters at the same time by firing multiple
> pins on a shuttle roughly the same width as the paper which moves
> side-to-side along the paper. E.g. the Printronix P300.
We had three of these at LOTS.[1] I once had to repair the 50-pin connector
on one--one or more wires in the cable had broken. Couple of days of pin
crimping and it was good (?) as new.
> Dot matrix printer - Forms characters from individual dots, prints
> part of a single character at a time by firing one or multiple pins
> on a print head a fraction of the width of the paper which moves
> side-to-side along the paper. E.g. the ksr decwriters commonly used
> as printers.
> I tend to think of laser printers as "page printers".
So did Xerox, in the days of the 8700 and 9700. We had one of the latter
at the UofChicago Comp Center: 60 pages/minute duplexed behemoth.
> No doubt someone will find an example which blows my neatly organized
> universe all to hell. :)
That's the entire point of taxonomies, isn't it?
[1] The Low-Overhead Timesharing System was the academic computing center
at Stanford University from 1976 till some time in the 1990s or early
in the 21st Century. It grew from a single DECSYSTEM-2040 to three
2065s and a Systems Concepts SC-30M running TOPS-20 in 1990, along with
a VAX 8650 running Ultrix (replaced by an 8800 for students and a 3600
for staff) and an IBM 4381 running VM/CMS. The low overhead was that
professional staff was minimal (prior to the IBM gear showing up, 2.5
FTE technical staff). I was the last TOPS-20 systems programmer there,
from 1984 to 1991.
--
Rich Alderson ne...@alderson.users.panix.com
glen herrmannsfeldt
(snip)
> Were any of them really DEC designs? or were they all just OEM'd and a
> DEC label put on them?
I have a Colorwriter 1000, which I believe is an OEM printer
with a new name stuck on it. I have had it for years, after someone
gave it to me, and still haven't used up the roll of ink.
It is pretty nice for solid colors, not not so good for shading.
I suppose I thought that DECwriters were DEC designs, but I
don't know about others.
-- glen
fishtoprecords
> I suppose I thought that DECwriters were DEC designs, but I
> don't know about others.
I think the LA36 was a real DEC engineered design. But the subject
line at started this is about line printers, and the LA36 and similar
devices were character printers.
Richard
fishtoprecords <pat2...@gmail.com> spake the secret code
<5a77acc7-46ed-42c8...@u9g2000pra.googlegroups.com> thusly:
Worse, the LA36 is a character *terminal*, not just a printer.
glen herrmannsfeldt
The LA36 and such were, but were there line buffered versions?
I do seem to remember ones that were used as line printers,
and didn't have keyboards, but I don't remember if they were
line buffered.
-- glen
Eric Smith
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems.
Threw away a couple of LP26 line printers a few years back, as it
didn't seem that anyone wanted them. (I certainly didn't!)
Richard
glen herrmannsfeldt <g...@ugcs.caltech.edu> spake the secret code
<idn47a$ugt$1...@news.eternal-september.org> thusly:
>I do seem to remember ones that were used as line printers,
>and didn't have keyboards, but I don't remember if they were
>line buffered.
The printers and terminals handbook from 1983 lists the printer-only
version of the LA120 as having a 1000 character line buffer.
<http://vt100.net/docs/tp83/chapter14.html>
jmfbahciv
> [Please do not mail me a copy of your followup]
>
> fishtoprecords <pat2...@gmail.com> spake the secret code
> <5a77acc7-46ed-42c8...@u9g2000pra.googlegroups.com> thusly:
>
>>On Dec 7, 8:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>> I suppose I thought that DECwriters were DEC designs, but I
>>> don't know about others.
>>
>>I think the LA36 was a real DEC engineered design. But the subject
>>line at started this is about line printers, and the LA36 and similar
>>devices were character printers.
>
> Worse, the LA36 is a character *terminal*, not just a printer.
It was never meant to be a printer.
/BAH
Paul Anderson
Rich Alderson <ne...@alderson.users.panix.com> wrote:
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
When Digital sold the printing business to Genicom in 1997, the LA dot
matrix, LG line matrix and LP line matrix lines went with it.
Genicom sold LA, LG and LP printers but I don't know how many models of
which lines survived all the way to Printronix. I doubt anyone still
makes line printers, as line printers have been functionally replaced by
line matrix printers.
Genicom later merged with Tally to become TallyGenicom, which was later
purchased by Printronix.
Dataproducts is now owned by Clover Technologies Group.
Dataproducts and Printronix supplied Digital with these printers but
they were all modified to Digital's specifications, mostly for DEC ANSI
support.
Paul
Richard
jmfbahciv <See....@aol.com> spake the secret code
<PM000496E...@ac8136d8.ipt.aol.com> thusly:
>Richard wrote:
>> Worse, the LA36 is a character *terminal*, not just a printer.
>
>It was never meant to be a printer.
That didn't stop people from using it that way. We had a DECwriter
LA36 hooked up to a modem and used it as a spooling printer on RSTS/E.
Steven Underwood
working on moving jobs over to the laser printers for about a year now.
Ours is connected to our VAX 7000-630 via a DECServer 250.
Certain of our users are dragging their feet on approving the new version or
converting to PDF and management has not pushed hard enough yet. Reasons
for moving away are difficulties getting ribbons, paper, and bands and the
$200/month maintenance cost.
Steve Underwood
"Rich Alderson" wrote in message news:mddzksi...@panix5.panix.com...
NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
I have been asked to find out whether anyone still uses line printers on
their DEC systems. I'm not sure why the question came up, exactly, though
we have just sent a board design out for manufacture for a replacement
M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
--
H Vlems
One pin on the parallel port was inverted on the parallel interface of
the DMF-32.
A simple inverter fed from the +5V pin fixed that. I can't remember
the name of the signal,
printer read perhaps?
Hans
jmfbahciv
> [Please do not mail me a copy of your followup]
>
> jmfbahciv <See....@aol.com> spake the secret code
> <PM000496E...@ac8136d8.ipt.aol.com> thusly:
>
>>Richard wrote:
>>> Worse, the LA36 is a character *terminal*, not just a printer.
>>
>>It was never meant to be a printer.
>
> That didn't stop people from using it that way.
I understand that. :-)
> We had a DECwriter
> LA36 hooked up to a modem and used it as a spooling printer on RSTS/E.
Slllooooowwwwww...... ;-)
Did you put a max on the page limits?
/BAH
jbriggs444
>
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
>
> --
> the russet leaves of an autumn oak/inspire once again the failed poet/
> to take up his pen/and essay to place his meagre words upon the page...
Could you not go with a serial to parallel converter? And if your
serial ports
are too slow, with a LAT solution. Or if that's unacceptable, using
an external
print server? [Mind you, I haven't investigated whether anyone does
serial to
parallel with the LP27 pinout any more]
Richard
jmfbahciv <See....@aol.com> spake the secret code
<PM000496F...@ac813eae.ipt.aol.com> thusly:
>Richard wrote:
>> We had a DECwriter
>> LA36 hooked up to a modem and used it as a spooling printer on RSTS/E.
>
>Slllooooowwwwww...... ;-)
All our access was at 300 baud, except for a few CRT terminals
connected at 1800 baud. Everything was slow. The physical machine
was on the other side of town in a secured building to which we didn't
have access except with special permission.
>Did you put a max on the page limits?
Nope.
Rich Alderson
> On Dec 6, 5:58=A0pm, Rich Alderson <n...@alderson.users.panix.com>
> wrote:
>> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>> I have been asked to find out whether anyone still uses line printers on
>> their DEC systems. I'm not sure why the question came up, exactly, though
>> we have just sent a board design out for manufacture for a replacement
>> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
> Could you not go with a serial to parallel converter? And if your serial
> ports are too slow, with a LAT solution. Or if that's unacceptable, using
> an external print server? [Mind you, I haven't investigated whether anyone
> does serial to parallel with the LP27 pinout any more]
The point is to drive the printer from Tops-10 and TOPS-20 on a
DECSYSTEM-2065. The operating systems' printer drivers know about the LP20
interface in the PDP-11/40 which makes up the front end of the system. Since
this is in a museum setting, it rather vitiates the point to do something
else.
The question arose in a "Can people see this kind of thing elsewhere?" moment.
--
Rich Alderson ne...@alderson.users.panix.com
jmfbahciv
> [Please do not mail me a copy of your followup]
>
> jmfbahciv <See....@aol.com> spake the secret code
> <PM000496F...@ac813eae.ipt.aol.com> thusly:
>
>>Richard wrote:
>>> We had a DECwriter
>>> LA36 hooked up to a modem and used it as a spooling printer on RSTS/E.
>>
>>Slllooooowwwwww...... ;-)
>
> All our access was at 300 baud, except for a few CRT terminals
> connected at 1800 baud.
1800? I never heard of that value.
> Everything was slow.
My condolences. What did you do when waiting? Knit socks? :-)
> The physical machine
> was on the other side of town in a secured building to which we didn't
> have access except with special permission.
That will put a crimp in your style.
>
>>Did you put a max on the page limits?
>
> Nope.
and you never lost a box of paper?
/BAH
Richard
jmfbahciv <See....@aol.com> spake the secret code
<PM0004970...@aca3ebba.ipt.aol.com> thusly:
>Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> jmfbahciv <See....@aol.com> spake the secret code
>> <PM000496F...@ac813eae.ipt.aol.com> thusly:
>>
>>>Richard wrote:
>>>> We had a DECwriter
>>>> LA36 hooked up to a modem and used it as a spooling printer on RSTS/E.
>>>
>>>Slllooooowwwwww...... ;-)
>>
>> All our access was at 300 baud, except for a few CRT terminals
>> connected at 1800 baud.
>
>1800? I never heard of that value.
Tehcnically the "high speed" modems were only rated at 1200, but 1800
is a supported baud rate and they worked at 1800 reliably. At 2400
they were unreliable.
>> Everything was slow.
>
>My condolences. What did you do when waiting? Knit socks? :-)
Most people can't read faster then 300 baud and when you never knew
anything different, it didn't feel slow.
>> The physical machine
>> was on the other side of town in a secured building to which we didn't
>> have access except with special permission.
>
>That will put a crimp in your style.
We rarely needed to do anything with magtapes or whatnot. When we did,
we would call the operators and have them mount or unmount the tape.
The system was a PDP-11/70 with lots of modem lines, lots of users and
a reasonable disk quota for each account. Most users were on LA36
terminals, so if they needed a printout, they did it themselves and
the reasonable disk quota meant that they didn't need tape access very
often.
>>>Did you put a max on the page limits?
>>
>> Nope.
>
>and you never lost a box of paper?
We had our own private terminal room and no, for the people that had
access to that room noone was stealing boxes of paper.
Even in the public terminal room which had many LA36s multiplexed
through a port selector allowing you access to many kinds of machines
(PDP-11/70 w/unix, PDP-11/70 w/RSTS/E, Burroughs B6700, HP2000), I
don't recall there ever being a problem with people stealing boxes of
paper.
Richard
(Richard) legaliz...@mail.xmission.com spake the secret code
<idtn5o$o5$1...@news.xmission.com> thusly:
>Even in the public terminal room which had many LA36s multiplexed
>through a port selector allowing you access to many kinds of machines
>(PDP-11/70 w/unix, PDP-11/70 w/RSTS/E, Burroughs B6700, HP2000) [...]
I forgot the DECsystem-10 or 20 running TOPS-10 or TOPS-20, I can't remember
which.
Bob Koehler
>
> My condolences. What did you do when waiting? Knit socks? :-)
Slow serial printers are a pain. But did you ever try to type
at over 300 baud?
OBTW, slow printers will teach you to write compact code. I think
COBOL was the orginal cause of gaster printers.
Dennis Boone
> We had our own private terminal room and no, for the people that had
> access to that room noone was stealing boxes of paper.
> Even in the public terminal room which had many LA36s multiplexed
> through a port selector allowing you access to many kinds of machines
> (PDP-11/70 w/unix, PDP-11/70 w/RSTS/E, Burroughs B6700, HP2000), I
> don't recall there ever being a problem with people stealing boxes of
> paper.
I think he was referring to the inevitable accident with the file
containing a few ream-feed and jam-tractor control characters. And
lots of BELs.
De
Richard
d...@ihatespam.msu.edu (Dennis Boone) spake the secret code
<3IydnTo19pu58p_Q...@giganews.com> thusly:
We were sitting in the same room and mostly using it to print out our
source code or TECO manuals. I suppose someone occasionally tried to
print a binary file, but this was quickly recognized and easily
stopped long before anything like an entire box of paper would be
consumed.
The printer queue on this terminal was not open to the general public,
only those of us that had access to the room.
jmfbahciv
Or issuing a print command for a non-ASCII file or the output of
a COBOL listing with a million errors because of a missing period.
/BAH
jmfbahciv
> [Please do not mail me a copy of your followup]
>
> d...@ihatespam.msu.edu (Dennis Boone) spake the secret code
> <3IydnTo19pu58p_Q...@giganews.com> thusly:
>
>> > >and you never lost a box of paper?
>>
>> > We had our own private terminal room and no, for the people that had
>> > access to that room noone was stealing boxes of paper.
>>
>> > Even in the public terminal room which had many LA36s multiplexed
>> > through a port selector allowing you access to many kinds of machines
>> > (PDP-11/70 w/unix, PDP-11/70 w/RSTS/E, Burroughs B6700, HP2000), I
>> > don't recall there ever being a problem with people stealing boxes of
>> > paper.
>>
>>I think he was referring to the inevitable accident with the file
>>containing a few ream-feed and jam-tractor control characters. And
>>lots of BELs.
>
> We were sitting in the same room and mostly using it to print out our
> source code or TECO manuals. I suppose someone occasionally tried to
> print a binary file, but this was quickly recognized and easily
> stopped long before anything like an entire box of paper would be
> consumed.
>
> The printer queue on this terminal was not open to the general public,
> only those of us that had access to the room.
So, either the room was manned 7x24 or you shut down the print spooler
when the room was vacant of two-legged critters?
/BAH
jmfbahciv
> In article <PM0004970...@aca3ebba.ipt.aol.com>, jmfbahciv
<See....@aol.com> writes:
>>
>> My condolences. What did you do when waiting? Knit socks? :-)
>
> Slow serial printers are a pain. But did you ever try to type
> at over 300 baud?
Yes. When you have to use a line editor such as SOSX and your
OS provides type-ahead, you can do some editing and then wait
for 5 mintues for the TTY printing to catch up and stop. Then
you can go to the next page of the listing and do those edits.
>
> OBTW, slow printers will teach you to write compact code. I think
Sometimes, perhaps :-) There is compact code w.r.t. the number of
characters in the source and then there is compact code w.r.t.
the machine lanugage the source generates. The two are orthogonal
in my experience with HLLs.
> COBOL was the orginal cause of gaster printers.
>
Gaster?
/BAH
Richard
jmfbahciv <See....@aol.com> spake the secret code
<PM0004972...@aca2c0ea.ipt.aol.com> thusly:
>So, either the room was manned 7x24 or you shut down the print spooler
>when the room was vacant of two-legged critters?
As I said, the printer wasn't open to anyone who didn't have a key to
the room. And yes, we turned things off when we left the room.
Johnny Billquist
Um... Who printed if there was noone there? (Yes, I know you can request
a spooler to process a job at a later time, but that seems like an
unlikely scenario for printing a binary file.)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist
> jbriggs444<jbrig...@gmail.com> writes:
>
>> On Dec 6, 5:58=A0pm, Rich Alderson<n...@alderson.users.panix.com>
>> wrote:
>
>>> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>
>>> I have been asked to find out whether anyone still uses line printers on
>>> their DEC systems. I'm not sure why the question came up, exactly, though
>>> we have just sent a board design out for manufacture for a replacement
>>> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
>
>> Could you not go with a serial to parallel converter? And if your serial
>> ports are too slow, with a LAT solution. Or if that's unacceptable, using
>> an external print server? [Mind you, I haven't investigated whether anyone
>> does serial to parallel with the LP27 pinout any more]
>
> The point is to drive the printer from Tops-10 and TOPS-20 on a
> DECSYSTEM-2065. The operating systems' printer drivers know about the LP20
> interface in the PDP-11/40 which makes up the front end of the system. Since
> this is in a museum setting, it rather vitiates the point to do something
> else.
Curios. I wonder why you would have a special line printer interface in
the 11/40 when it served as a FE in a DEC-20. After all, the LP11 can
run an LP27 just fine as well...
I would guess Tops-10 and TOPS-20 spoke with the LP20 through the FE
anyway, so the actual device driver is something on RSX-20F after all,
and then you have some abstract device presented to the DEC-20?
(I haven't really examined enough of how the interaction between the
11/40 and the DEC-20 works to really know anything here.)
Rich Alderson
> On 2010-12-09 23:33, Rich Alderson wrote:
>> The point is to drive the printer from Tops-10 and TOPS-20 on a
>> DECSYSTEM-2065. The operating systems' printer drivers know about the
>> LP20 interface in the PDP-11/40 which makes up the front end of the
>> system. Since this is in a museum setting, it rather vitiates the
>> point to do something else.
> Curios. I wonder why you would have a special line printer interface in
> the 11/40 when it served as a FE in a DEC-20. After all, the LP11 can
> run an LP27 just fine as well...
Because that's what DEC decided to do to the front end?
> I would guess Tops-10 and TOPS-20 spoke with the LP20 through the FE
> anyway, so the actual device driver is something on RSX-20F after all,
> and then you have some abstract device presented to the DEC-20?
> (I haven't really examined enough of how the interaction between the
> 11/40 and the DEC-20 works to really know anything here.)
The printer handlers in Tops-10 and TOPS-20 are hardware aware, regardless
of whether RSX-20F is between them and the printer or not.
jmfbahciv
If the machine was running and on a network, a print request could
come from the outside.
/BAH
Richard
jmfbahciv <See....@aol.com> spake the secret code
<PM0004974...@aca2aea4.ipt.aol.com> thusly:
>If the machine was running and on a network, a print request could
>come from the outside.
Machine was available 24/7 by modem. No network. (This was
1979-1980; networking was a luxury on RSTS/E at that time.)
At any rate, as I've said, the last person to leave the room would
shut off all the terminals.
Alan Frisbie
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
>
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
Does a Printronix P-300 count? We (my client) bought one for our
PDP-11 in 1987. When we bought a VAX in 1989, we moved the P-300
to it. In 1996 we bought an AlphaServer 1000A and it got the
P-300. We then upgraded to an ES45 in 2007, the P-300 moved again.
It has outlasted multiple other printers and still keeps printing along.
Actually, the P-300 only physically moved once, when we got a new
building. :-)
Alan
Johnny Billquist
> Johnny Billquist<b...@softjar.se> writes:
>
>> On 2010-12-09 23:33, Rich Alderson wrote:
>
>>> The point is to drive the printer from Tops-10 and TOPS-20 on a
>>> DECSYSTEM-2065. The operating systems' printer drivers know about the
>>> LP20 interface in the PDP-11/40 which makes up the front end of the
>>> system. Since this is in a museum setting, it rather vitiates the
>>> point to do something else.
>
>> Curios. I wonder why you would have a special line printer interface in
>> the 11/40 when it served as a FE in a DEC-20. After all, the LP11 can
>> run an LP27 just fine as well...
>
> Because that's what DEC decided to do to the front end?
Obviously. :-D
I guess the question was almost rhetorical, since I suspect noone around
here knows why DEC actually did this.
>> I would guess Tops-10 and TOPS-20 spoke with the LP20 through the FE
>> anyway, so the actual device driver is something on RSX-20F after all,
>> and then you have some abstract device presented to the DEC-20?
>> (I haven't really examined enough of how the interaction between the
>> 11/40 and the DEC-20 works to really know anything here.)
>
> The printer handlers in Tops-10 and TOPS-20 are hardware aware, regardless
> of whether RSX-20F is between them and the printer or not.
Hmm. Do the 11/40 allow totally transparent access to the Unibus from
the DEC-20?
Rich Alderson
The particular question had to do with the line-at-a-time things. However,
I just wanted to say that I'm impressed beyond all measure that yor P-300
has lasted so long. We had three at LOTS (Stanford), one on each KL-10, and
they were a bit dodgy. Of course, when you use a printer in a 24x7 student
facility, it's going to get pounded on...
Lawrence D'Oliveiro
<5a77acc7-46ed-42c8...@u9g2000pra.googlegroups.com>,
fishtoprecords wrote:
> On Dec 7, 8:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> I suppose I thought that DECwriters were DEC designs, but I
>> don't know about others.
>
> I think the LA36 was a real DEC engineered design. But the subject
> line at started this is about line printers, and the LA36 and similar
> devices were character printers.
LA180, then.
jmfbahciv
> [Please do not mail me a copy of your followup]
>
> jmfbahciv <See....@aol.com> spake the secret code
> <PM0004974...@aca2aea4.ipt.aol.com> thusly:
>
>>If the machine was running and on a network, a print request could
>>come from the outside.
>
> Machine was available 24/7 by modem. No network. (This was
> 1979-1980; networking was a luxury on RSTS/E at that time.)
Huh. I thought network software came with the OS. Do you remember
if it was an option when buying the hardware?
>
> At any rate, as I've said, the last person to leave the room would
> shut off all the terminals.
Dang. Missed that thought. the queue would just wait until
you turned the printer back on. Sorry. My brain isn't what
it once was.
/BAH
Bob Koehler
>
> Hmm. Do the 11/40 allow totally transparent access to the Unibus from
> the DEC-20?
No. The 11 handled all the DMA setup, programmed I/O operations,
and interrupts. The main CPU talked to the 11 in more of a network
fashion (long before DECnet): send this data to device X, get that
data from device Y.
Bob Koehler
>
> Huh. I thought network software came with the OS. Do you remember
> if it was an option when buying the hardware?
OS have been around a lot longer than networks. Even today
you can add on networking to most OS, since not all OS come
with all network stacks.
Richard
Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> spake the secret code
<ie77ua$g29$1...@lust.ihug.co.nz> thusly:
The LA180 is also a character printer and not a line-at-a-time printer.
Richard
jmfbahciv <See....@aol.com> spake the secret code
<PM0004975...@aca38a9c.ipt.aol.com> thusly:
>Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Machine was available 24/7 by modem. No network. (This was
>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>
>Huh. I thought network software came with the OS. Do you remember
>if it was an option when buying the hardware?
While I was there, we never had networking. I don't know when
networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
was first made available in RSTS/E. One guy homebrewed file transfer
between systems by writing his own program that acted kind of like
zmodem file transfer between a PC and a BBS. He hooked up the two
systems by connecting two modems together, each connected to the sytem
and then controlling the file transfer on a third terminal.
>> At any rate, as I've said, the last person to leave the room would
>> shut off all the terminals.
>
>Dang. Missed that thought. the queue would just wait until
>you turned the printer back on. Sorry. My brain isn't what
>it once was.
I think the print queue might have been homebrewed and not part of the
OS; I can't recall the particulars. If it was homebrewed, then there
wasn't any "queue" when the program wasn't running.
Johnny Billquist
> [Please do not mail me a copy of your followup]
>
> jmfbahciv<See....@aol.com> spake the secret code
> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>
>> Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Machine was available 24/7 by modem. No network. (This was
>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>>
>> Huh. I thought network software came with the OS. Do you remember
>> if it was an option when buying the hardware?
>
> While I was there, we never had networking. I don't know when
> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
> was first made available in RSTS/E.
I think there might have been DECnet for RSTS/E in that timeframe, but
no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
DECnet was only running over point-to-point interfaces, or multidrop.
DECnet was, and still is, optional for RSTS/E. Not something delivered
with the OS as such.
> One guy homebrewed file transfer
> between systems by writing his own program that acted kind of like
> zmodem file transfer between a PC and a BBS. He hooked up the two
> systems by connecting two modems together, each connected to the sytem
> and then controlling the file transfer on a third terminal.
KERMIT anyone?
>>> At any rate, as I've said, the last person to leave the room would
>>> shut off all the terminals.
>>
>> Dang. Missed that thought. the queue would just wait until
>> you turned the printer back on. Sorry. My brain isn't what
>> it once was.
>
> I think the print queue might have been homebrewed and not part of the
> OS; I can't recall the particulars. If it was homebrewed, then there
> wasn't any "queue" when the program wasn't running.
RSTS/E had/has a great spooling system, so I would be a little surprised
if someone bothered to write his own... However, 1979 is before I used
RSTS/E, so it might not have existed back then. I only started with
RSTS/E in 1982. I *think* it was V7.1 at the time. '79 would probably
mean something like V6 in that case.
Johnny Billquist
> [Please do not mail me a copy of your followup]
>
> Lawrence D'Oliveiro<l...@geek-central.gen.new_zealand> spake the secret code
> <ie77ua$g29$1...@lust.ihug.co.nz> thusly:
>
>> In message
>> <5a77acc7-46ed-42c8...@u9g2000pra.googlegroups.com>,
>> fishtoprecords wrote:
>>
>>> On Dec 7, 8:49 pm, glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>>>> I suppose I thought that DECwriters were DEC designs, but I
>>>> don't know about others.
>>>
>>> I think the LA36 was a real DEC engineered design. But the subject
>>> line at started this is about line printers, and the LA36 and similar
>>> devices were character printers.
>>
>> LA180, then.
>
> The LA180 is also a character printer and not a line-at-a-time printer.
Well, technically, a line printer did not print a line at a time either.
You had one hammer per character position, and then the chain (or
whatever) moving characters along, and the hammer hit when the right
character was in front. That means the same character was not available
at other positions. Now, as anyone with a small sense of mathematics can
figure out, on a 132 column printer, with a chain going around, you'll
have room for 264 characters on the chain, minimum (there are some more,
since the chain needs some space to turn around as well). The alphabet
have fewer number of characters, so characters are repeated several
times on the chain. More common characters occur more often, but it
would be a very specific line that would allow a line printer to print
the whole line on one punch. But it could never do that anyway. The
power surge from trying to fire all 132 hammers at the same time would
blow fuses, and burn wires. In reality, the printer was limited to not
fire more than around 6 hammers (maximum) at the same time.
The biggest differences between LP and LA printers would, I'd say, be
the fact that LA printers used a moving head, and a dot matrix design,
to print, while LP printers used hammers and types on a chain (or
similar device) to print. The speeds of the LP printers are way higher
than LA printers, but they didn't print the whole line in one punch.
If you mean line-at-a-time in any other sense, then LA and LP are pretty
much equally much line-at-a-time printers. They both normally print one
line before advancing to the next one, even if some LA printers could
reverse the feed (usually with bad results though).
Both type of printers also buffered data, usually a couple of K on LA
printers. Exactly how much an LP printer would buffer I don't know, but
atleast one line of data, or else it wouldn't be able to work efficiently.
Johnny Billquist
As I thought. Which makes it in a way more weird why DEC decided to
manufacture a special LP controller for the DEC-20, when they also have
the LP11, which also sits on the Unibus, and talks to any line printer.
It would appear that one would have worked just as well, and you could
have presented the same kind of interface to the DEC-20.
glen herrmannsfeldt
>> The LA180 is also a character printer and not a line-at-a-time printer.
> Well, technically, a line printer did not print a line at a time either.
> You had one hammer per character position, and then the chain (or
> whatever) moving characters along, and the hammer hit when the right
> character was in front. That means the same character was not available
> at other positions. Now, as anyone with a small sense of mathematics can
> figure out, on a 132 column printer, with a chain going around, you'll
> have room for 264 characters on the chain, minimum (there are some more,
> since the chain needs some space to turn around as well).
The IBM line printers are chain or train printers, but the DEC
printers I remember are drum printers, which could possibly print
a whole line at once. It would seem easiest for a drum printer
to have the same at the same rotational position for all columns,
in which case it would for a whole row of the same character.
> The alphabet
> have fewer number of characters, so characters are repeated several
> times on the chain. More common characters occur more often, but it
> would be a very specific line that would allow a line printer to print
> the whole line on one punch. But it could never do that anyway. The
> power surge from trying to fire all 132 hammers at the same time would
> blow fuses, and burn wires. In reality, the printer was limited to not
> fire more than around 6 hammers (maximum) at the same time.
The IBM chain/train printers have a different spacing for the
characters and print columns, which naturally limits the number.
I don't know about drum printers.
> The biggest differences between LP and LA printers would, I'd say, be
> the fact that LA printers used a moving head, and a dot matrix design,
> to print, while LP printers used hammers and types on a chain (or
> similar device) to print. The speeds of the LP printers are way higher
> than LA printers, but they didn't print the whole line in one punch.
> If you mean line-at-a-time in any other sense, then LA and LP are pretty
> much equally much line-at-a-time printers. They both normally print one
> line before advancing to the next one, even if some LA printers could
> reverse the feed (usually with bad results though).
Ones that I know, such as, I believe, the Epson MX-100 that I
still have, buffer a whole line before printing. That is, no printing
until the CR and/or LF. That doesn't work well for an interactive
terminal, though, but is a little more efficient for non-interactive
printing. Also, in bit graphics mode such printers buffer a whole row.
> Both type of printers also buffered data, usually a couple of K on LA
> printers. Exactly how much an LP printer would buffer I don't know, but
> atleast one line of data, or else it wouldn't be able to work efficiently.
-- glen
fishtoprecords
> Huh. I thought network software came with the OS. Do you remember
> if it was an option when buying the hardware?
On Tops-20, all networking (except TTY into RSX-20F) was ala-carte.
Decnet, IBM RJE, etc. Don't know about TCP/IP for the Tops-20AN, our
sales droid would never talk about what that was. Sigh.
We also took an attached PDP-11 and ran Univ of Utah's X.25
networking.
jmfbahciv
> On Dec 14, 9:08 am, jmfbahciv <See.ab...@aol.com> wrote:
>> Huh. I thought network software came with the OS. Do you remember
>> if it was an option when buying the hardware?
>
> On Tops-20, all networking (except TTY into RSX-20F) was ala-carte.
> Decnet, IBM RJE, etc. Don't know about TCP/IP for the Tops-20AN,
That was an extra option.
> our
> sales droid would never talk about what that was. Sigh.
>
> We also took an attached PDP-11 and ran Univ of Utah's X.25
> networking.
Sure. But I was talking about RSTS/E in the late 70s.
/BAH
jmfbahciv
> On 2010-12-14 19:37, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> jmfbahciv<See....@aol.com> spake the secret code
>> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>>
>>> Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> Machine was available 24/7 by modem. No network. (This was
>>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>>>
>>> Huh. I thought network software came with the OS. Do you remember
>>> if it was an option when buying the hardware?
>>
>> While I was there, we never had networking. I don't know when
>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>> was first made available in RSTS/E.
>
> I think there might have been DECnet for RSTS/E in that timeframe,
There was.
>but
> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
> DECnet was only running over point-to-point interfaces, or multidrop.
>
> DECnet was, and still is, optional for RSTS/E. Not something delivered
> with the OS as such.
OK. I just don't remember RSTS/E having it as an extra.
>
>> One guy homebrewed file transfer
>> between systems by writing his own program that acted kind of like
>> zmodem file transfer between a PC and a BBS. He hooked up the two
>> systems by connecting two modems together, each connected to the sytem
>> and then controlling the file transfer on a third terminal.
>
> KERMIT anyone?
>
>>>> At any rate, as I've said, the last person to leave the room would
>>>> shut off all the terminals.
>>>
>>> Dang. Missed that thought. the queue would just wait until
>>> you turned the printer back on. Sorry. My brain isn't what
>>> it once was.
>>
>> I think the print queue might have been homebrewed and not part of the
>> OS; I can't recall the particulars. If it was homebrewed, then there
>> wasn't any "queue" when the program wasn't running.
>
> RSTS/E had/has a great spooling system, so I would be a little surprised
> if someone bothered to write his own... However, 1979 is before I used
> RSTS/E, so it might not have existed back then. I only started with
> RSTS/E in 1982. I *think* it was V7.1 at the time. '79 would probably
> mean something like V6 in that case.
IIRC, it did have spooling but I don't remember the particulars about
that feature.
/BAH
Bob Koehler
> The IBM line printers are chain or train printers, but the DEC
> printers I remember are drum printers, which could possibly print
> a whole line at once. It would seem easiest for a drum printer
> to have the same at the same rotational position for all columns,
> in which case it would for a whole row of the same character.
DEC had both drum and band printers. If you wanted to actually
print a whole line at once on a drum printer, you'ld better check
out the drum first, the letters were aranged in a spiral.
Most of the time when we think of dot-matrix printers, we think of
vertically aranged pins scanning across the witdh of each letter as
the head moves horizontally. (How many of us had Epsons on an MS-DOS
system?) But if you looked inside a Printronix, it had a fixed long
horizontal line of pins that were timed to paper movement.
So to literally print a line at a time on a Printronix, it would
have to be one pixel high, such as 132 of -, _, or .
Ah, yes, the sound of a band printer overprinting a row of _ for a
while. Who needs scissors?
glen herrmannsfeldt
> In article <ie91b0$cj2$1...@news.eternal-september.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>> The IBM line printers are chain or train printers, but the DEC
>> printers I remember are drum printers, which could possibly print
>> a whole line at once. It would seem easiest for a drum printer
>> to have the same at the same rotational position for all columns,
>> in which case it would for a whole row of the same character.
> DEC had both drum and band printers. If you wanted to actually
> print a whole line at once on a drum printer, you'ld better check
> out the drum first, the letters were aranged in a spiral.
That way it isn't so hard to figure out when to trigger the
hammer based on the character and drum position. I never saw
a drum printer inside while it was off.
The usual train for the IBM train printers has, if I remember
it right, five of the more popular characters (I believe the 48
characters of Fortran), and one copy of the less popular
characters (to make up the 60 character set for PL/I).
Then there was also a 120 character train including lower case
letters and some other unusual characters, such as superscript
digits, and the cent sign.
> Most of the time when we think of dot-matrix printers, we think of
> vertically aranged pins scanning across the witdh of each letter as
> the head moves horizontally. (How many of us had Epsons on an MS-DOS
> system?) But if you looked inside a Printronix, it had a fixed long
> horizontal line of pins that were timed to paper movement.
I seem to remember a horizontal row dot matrix printer that didn't
have enough pins for the whole width, but would vibrate an array
of pins back and forth fast enough to print.
> So to literally print a line at a time on a Printronix, it would
> have to be one pixel high, such as 132 of -, _, or .
I meant more in the logical sense than the physical sense.
The MX-100 prints with the head moving in alternate directions,
at least when that allows it to print faster. I believe it starts
each line at the end that is closer to the head position at
the end of the previous line.
So, the logic for a line printer is: buffer a line, print the
line in whatever order is convenient, repeat.
Then there is the page printer like the IBM 3800, where the
logic is to buffer a whole page, then print it. It can only
stop the paper movement between pages though, as you said above,
it prints vertically. According to IBM, the 3800 can print 20000
lines per minute, though as I remember it the paper speed is constant,
so the line rate depends on the line pitch of 6, 8, or 12 lines/inch.
(And 10, 12, or 15 characters per inch horizontally.)
Richard
Johnny Billquist <b...@softjar.se> spake the secret code
<ie8vhs$jek$1...@Iltempo.Update.UU.SE> thusly:
>On 2010-12-14 19:34, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Lawrence D'Oliveiro<l...@geek-central.gen.new_zealand> spake the secret code
>> <ie77ua$g29$1...@lust.ihug.co.nz> thusly:
>>
>>> In message
>>> <5a77acc7-46ed-42c8...@u9g2000pra.googlegroups.com>,
>>> fishtoprecords wrote:
>>>
>>>> On Dec 7, 8:49 pm, glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>>>>> I suppose I thought that DECwriters were DEC designs, but I
>>>>> don't know about others.
>>>>
>>>> I think the LA36 was a real DEC engineered design. But the subject
>>>> line at started this is about line printers, and the LA36 and similar
>>>> devices were character printers.
>>>
>>> LA180, then.
>>
>> The LA180 is also a character printer and not a line-at-a-time printer.
>
>Well, technically, a line printer did not print a line at a time either.
>[...]
The point was that the LA180 was not fundamentally different from an
LA36. If an LA36 doesn't qualify for the discussion, then neither
does an LA180.
John Santos
legaliz...@mail.xmission.com says...>
>
> jmfbahciv <See....@aol.com> spake the secret code
> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>
> >Richard wrote:
> >> [Please do not mail me a copy of your followup]
> >>
> >> Machine was available 24/7 by modem. No network. (This was
> >> 1979-1980; networking was a luxury on RSTS/E at that time.)
> >
> >Huh. I thought network software came with the OS. Do you remember
> >if it was an option when buying the hardware?
>
> While I was there, we never had networking. I don't know when
> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
> was first made available in RSTS/E. One guy homebrewed file transfer
V6B in 1976 supported DECnet, which was an extra-cost option. I think
it was Phase III.
Phase IV & LAT (and Ethernet) came with V9.x. (I think it was V9.0,
but it might have been that just the hooks were there, and it wasn't
actually supported until V9.1 or V9.2)
TCP/IP has never been available on RSTS/E, AFAIK, though someone may
have hacked up some primitive support for PING, Telnet and FTP at
some time. You could write a program to receive various Ethernet
protocols and forward the packets (via send/receive?) to other
server or client processes.
(Process Software had a TCP/IP stack for RSX-11(M?), and possibly
for RT-11, but AFAIK, never did one for RSTS/E.)
Lots of other obscure networking was available for RSTS/E at various
times, such as HASP, IBM RJE (2780 emulation), etc., some from DEC and
some from 3rd parties. We did 2780/3780/BISYNC using DV-11's and
X.25 using KMD-11's, among other things. (The X.25 was specialized for
certain Telco apps, but you could emulate just about any BISYNC-based
protocol with the BSC driver.) We also did customized network support
for RSTS/E for a big international bank that had BBN design a variant
of ARPAnet for them... Other vendors wrote drivers and network apps
for other O/Ses (RSX, IBM, whatever DG was supporting at the time,
PrimOS (IIRC), and others.) The PDP-11/Unibus systems first used a
custom-designed board from a 3rd-party vendor, the VDH-11, and later
used custom firmware on a KMD-11.
> between systems by writing his own program that acted kind of like
> zmodem file transfer between a PC and a BBS. He hooked up the two
> systems by connecting two modems together, each connected to the sytem
> and then controlling the file transfer on a third terminal.
>
We did that too, but later adopted Kermit.
> >> At any rate, as I've said, the last person to leave the room would
> >> shut off all the terminals.
> >
> >Dang. Missed that thought. the queue would just wait until
> >you turned the printer back on. Sorry. My brain isn't what
> >it once was.
>
> I think the print queue might have been homebrewed and not part of the
> OS; I can't recall the particulars. If it was homebrewed, then there
> wasn't any "queue" when the program wasn't running.
RSTS/E had an original batch/print queuing system from way back (V4
V5, I think, before my time), that was pretty high overhead. In V9.0,
it got a vastly improved batch/print system, modeled closely on the
one in VMS.
--
John Santos
Evans Griffiths & Hart, Inc.
John Santos
g...@ugcs.caltech.edu says...>
> > On Dec 7, 8:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> >> I suppose I thought that DECwriters were DEC designs, but I
> >> don't know about others.
>
> > I think the LA36 was a real DEC engineered design. But the subject
> > line at started this is about line printers, and the LA36 and similar
> > devices were character printers.
>
>
> I do seem to remember ones that were used as line printers,
> and didn't have keyboards, but I don't remember if they were
> line buffered.
>
> -- glen
IIRC, an LA35 was an LA36 without a keyboard (i.e. printer-only.)
Between the LA35/36 and the LA120 was the LA180, which was basically
the LA120 print mechanism (no keyboard), but without the fancy
software that did bidirectional printing and lots of optimizations
that allowed the 120 to print about twice as fast. This was at the
dawn of the 8080/Z-80 era that allowed much more sophisticated
software in a hardware device. We had an LA180 and, later a couple
of LA120s, which IIRC looked pretty similar mechanically, and I
think took the same ribbons, but I don't know if they were identical.
They were all significantly beefed up from the LA36, which took
different ribbons.
There was also an LS180, which I think was an LA180 with a parallel
(line printer style) interface.
And there were LA120's without keyboards (LA120-RO, IIRC). AT&T
or Teletype or Western Electric (these were all parts of TPC) sold
rebadged LA120-RO's as TP1000's; I saw lots of these at various
Telco sites.
glen herrmannsfeldt
(snip, someone wrote)
>> >Huh. I thought network software came with the OS. Do you remember
>> >if it was an option when buying the hardware?
As far as I know, it was Sun that first supplied network software
included with the OS, no extra charge.
>> While I was there, we never had networking. I don't know when
>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>> was first made available in RSTS/E. One guy homebrewed file transfer
> V6B in 1976 supported DECnet, which was an extra-cost option.
> I think it was Phase III.
I remember people talking about DECnet in the 1970's, but as
something so expensive that people wouldn't buy it. Up
until the mid-80's systems I knew used terminal multiplexers
like Gandalf instead of network based terminal servers.
> Phase IV & LAT (and Ethernet) came with V9.x. (I think it was V9.0,
> but it might have been that just the hooks were there, and it wasn't
> actually supported until V9.1 or V9.2)
> TCP/IP has never been available on RSTS/E, AFAIK, though someone may
> have hacked up some primitive support for PING, Telnet and FTP at
> some time. You could write a program to receive various Ethernet
> protocols and forward the packets (via send/receive?) to other
> server or client processes.
I also remember the days when Ultrix hosts would gateway between
DECnet and TCP/IP, even without an account on the gateway system.
That was especially important for mail forwarding, but I think
somewould do it for telnet also.
> (Process Software had a TCP/IP stack for RSX-11(M?), and possibly
> for RT-11, but AFAIK, never did one for RSTS/E.)
-- glen
Johnny Billquist
> In alt.sys.pdp10 Johnny Billquist<b...@softjar.se> wrote:
>> On 2010-12-14 19:34, Richard wrote:
> (snip)
>>> The LA180 is also a character printer and not a line-at-a-time printer.
>
>> Well, technically, a line printer did not print a line at a time either.
>> You had one hammer per character position, and then the chain (or
>> whatever) moving characters along, and the hammer hit when the right
>> character was in front. That means the same character was not available
>> at other positions. Now, as anyone with a small sense of mathematics can
>> figure out, on a 132 column printer, with a chain going around, you'll
>> have room for 264 characters on the chain, minimum (there are some more,
>> since the chain needs some space to turn around as well).
>
> The IBM line printers are chain or train printers, but the DEC
> printers I remember are drum printers, which could possibly print
> a whole line at once. It would seem easiest for a drum printer
> to have the same at the same rotational position for all columns,
> in which case it would for a whole row of the same character.
Well, technically, under optimal circumstances, both types can print a
whole line at one punch. For drums, the characters are usually
staggered, so that a whole line of dashes (for instance) don't cause all
hammers to want to punch at the same time.
But the LP I remmeber used a chain, and not a drum. Don't remember for
sure which model it was anymore, though...
But as I also noted further down, even if you had the optimal layout, so
that the whole line could have been printed at one blow, limitations on
current meant you couldn't anyway. The most hammers that I seem to
remember that could be hit at the same time was around six or so.
(I might remember the number wrong, but I definitely remember seeing a
number somewhere, sometime, and for some reason six pops into my head.
However, it would be pretty obvious that firing 132 solenoids at the
same time would cause a huge power surge, probably causing none of the
hammers to hit fast or hard enough to cause a usable effect.)
>> The alphabet
>> have fewer number of characters, so characters are repeated several
>> times on the chain. More common characters occur more often, but it
>> would be a very specific line that would allow a line printer to print
>> the whole line on one punch. But it could never do that anyway. The
>> power surge from trying to fire all 132 hammers at the same time would
>> blow fuses, and burn wires. In reality, the printer was limited to not
>> fire more than around 6 hammers (maximum) at the same time.
>
> The IBM chain/train printers have a different spacing for the
> characters and print columns, which naturally limits the number.
> I don't know about drum printers.
Not sure how you mean this? It's fixed spacing, determined by the
placement of the hammers. Or are you talking about character
distribution on the chain? That was based on statistical analysis of how
common characters was. Obviously characters that were more common made
sense to have at more places on the chain.
>> The biggest differences between LP and LA printers would, I'd say, be
>> the fact that LA printers used a moving head, and a dot matrix design,
>> to print, while LP printers used hammers and types on a chain (or
>> similar device) to print. The speeds of the LP printers are way higher
>> than LA printers, but they didn't print the whole line in one punch.
>
>> If you mean line-at-a-time in any other sense, then LA and LP are pretty
>> much equally much line-at-a-time printers. They both normally print one
>> line before advancing to the next one, even if some LA printers could
>> reverse the feed (usually with bad results though).
>
> Ones that I know, such as, I believe, the Epson MX-100 that I
> still have, buffer a whole line before printing. That is, no printing
> until the CR and/or LF. That doesn't work well for an interactive
> terminal, though, but is a little more efficient for non-interactive
> printing. Also, in bit graphics mode such printers buffer a whole row.
Right. Since they print in both directions, many printers needs the
whole line before it knows where to print if going "backwards" with the
head.
Johnny Billquist
> In article<ie8dht$6og$2...@news.xmission.com>,
> legaliz...@mail.xmission.com says...>
>> [Please do not mail me a copy of your followup]
>>
>> jmfbahciv<See....@aol.com> spake the secret code
>> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>>
>>> Richard wrote:
>>>> [Please do not mail me a copy of your followup]
>>>>
>>>> Machine was available 24/7 by modem. No network. (This was
>>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>>>
>>> Huh. I thought network software came with the OS. Do you remember
>>> if it was an option when buying the hardware?
>>
>> While I was there, we never had networking. I don't know when
>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>> was first made available in RSTS/E. One guy homebrewed file transfer
>
> V6B in 1976 supported DECnet, which was an extra-cost option. I think
> it was Phase III.
>
> but it might have been that just the hooks were there, and it wasn't
> actually supported until V9.1 or V9.2)
>
> TCP/IP has never been available on RSTS/E, AFAIK, though someone may
> have hacked up some primitive support for PING, Telnet and FTP at
> some time. You could write a program to receive various Ethernet
> protocols and forward the packets (via send/receive?) to other
> server or client processes.
I have a friend who have hacked in ARP, ICMP, IP and UDP for RSTS/E. He
never got around to TCP though... He did some programs using UDP though.
I think that was for V8, but it might be that it would work fine with
just a little hacking on newer versions too.
> (Process Software had a TCP/IP stack for RSX-11(M?), and possibly
> for RT-11, but AFAIK, never did one for RSTS/E.)
No, I don't remember seeing anything for RSTS/E from Process Software
either.
Rich Alderson
> On 2010-12-14 19:37, Richard wrote:
>> jmfbahciv<See....@aol.com> spake the secret code
>> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>>> Richard wrote:
>>>> Machine was available 24/7 by modem. No network. (This was
>>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>>> Huh. I thought network software came with the OS. Do you remember
>>> if it was an option when buying the hardware?
>> While I was there, we never had networking. I don't know when
>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>> was first made available in RSTS/E.
> I think there might have been DECnet for RSTS/E in that timeframe, but
> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
> DECnet was only running over point-to-point interfaces, or multidrop.
?????
I'll grant you that work on TCP/IP was in its very early stages at that
time. Ethernet, on the other hand, had been in existence for years.
Or does "not invented yet" == "not available to systems I knew then"?
fishtoprecords
> The usual train for the IBM train printers has, if I remember
> it right, five of the more popular characters (I believe the 48
> characters of Fortran), and one copy of the less popular
> characters (to make up the 60 character set for PL/I).
> Then there was also a 120 character train including lower case
> letters and some other unusual characters, such as superscript
> digits, and the cent sign.
Our IBM shop had a bunch of the train printers. The operators hated
changing chains, so they would put off printing that used lower case
until 3rd shift.
The programmers quickly learned that to get any decent turn around on
their jobs, it had to be all upper case.
I was hired at AMS because I had years of Tops-10 experience and
nearly six months on Tops-20. Probably the first day that I was at
AMS, new hire and all that, they took me on a tour of the "terminal
room" that all the programmers were so proud of. It had a half dozen
Model 29 key punches, and two RJE terminals connected to the IBM
mainframes six blocks away.
I nearly quit on the spot. I was used to a "terminal" being a VT52
running 9600.
Mark Crispin
>>>>> 1979-1980
>> I think there might have been DECnet for RSTS/E in that timeframe, but
>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>> DECnet was only running over point-to-point interfaces, or multidrop.
> time. Ethernet, on the other hand, had been in existence for years.
Say what?
Ethernet was a PARC internal experiment with PUP protocol in the 1970s,
contemporary with ChaosNet/LCSnet at MIT. Stanford was one of the first
entities outside of PARC to get 3MB Ethernet (on thick-wire coax) along
with a bunch of Altos.
Metcalf left PARC to form 3COM in 1979. The DEC/Intel/Xerox Ethernet
specification for 10MB Ethernet (more or less modern Ethernet) was
published by IEEE in 1980; and 3COM's first Ethernet controller came out
in 1981.
Work on TCP started at about the same time as Ethernet, and the modern
protocol was there by 1980. The later date that you may be thinking of
was the TCP/IP transition on January 1, 1983, when DCA forced ARPAnet to
convert from NCP to TCP by instructing the IMPs not to pass NCP packets
any longer.
32-bit addressing on ARPAnet was quite a bit earlier. I wrote the first
PDP-10 implementation of 32-bit addressing in spring 1978 for WAITS,
followed quickly by Dave Moon's implementation for ITS. This rather
embarassed BBN, which had been dragging its feet on a Tenex
implementation.
Admittedly, my task on 32-bit addressing was made a lot easier by the IMP
interface that we used on WAITS. It was a DATAI/DATAO device, meaning
that I could have the interface in 32-bit mode for two DATAIs (first 64
bits of IMP leader), switch to 36-bit mode for the next two words (last
32 bits of IMP leader, 40-bit NCP leader), then switch back to 32-bit mode
if the connection was 8-bit or 32-bit instead of 36-bit and read the rest
of the packet with BLKI in the interrupt location.
IIRC, BBN's IMP interface allowed only one mode switch per packet, so to
do 32-bit addresses it had to read the entire packet in 32-bit mode and do
ridiculous shifting in software without using the IMP interface's 36-bit
mode. That made Tenex network I/O embarassingly slow, and perhaps that is
why TCP didn't have a 36-bit data transfer mode.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
H Vlems
> On 2010-12-14 15:01, Bob Koehler wrote:
>
Performance considerations could have been an issue?
Hans
glen herrmannsfeldt
> Well, technically, under optimal circumstances, both types can print a
> whole line at one punch. For drums, the characters are usually
> staggered, so that a whole line of dashes (for instance) don't cause all
> hammers to want to punch at the same time.
> But the LP I remmeber used a chain, and not a drum. Don't remember for
> sure which model it was anymore, though...
If you stagger by a fraction of a character height, then yes it
will never print a whole line at once.
> But as I also noted further down, even if you had the optimal layout, so
> that the whole line could have been printed at one blow, limitations on
> current meant you couldn't anyway. The most hammers that I seem to
> remember that could be hit at the same time was around six or so.
> (I might remember the number wrong, but I definitely remember seeing a
> number somewhere, sometime, and for some reason six pops into my head.
> However, it would be pretty obvious that firing 132 solenoids at the
> same time would cause a huge power surge, probably causing none of the
> hammers to hit fast or hard enough to cause a usable effect.)
Well, you could probably put capacitors on each driver so that
it could, but not doing it means that you can share the select
logic, which keeps hardware costs down. For 132 columns and six
hammers going at once, then you stagger them by 6/132 of the
vertical character spacing on the drum. You then need a rotational
position sensor that can sense to that resolution. It seems to
me that the limit is on the position sensor and, at some point,
on logic speed. As the IBM 1403 was introduced in 1959, that would
be before TTL. The 1403 is supposed to be able to print 1400
lines per minute with the Universal character set.
(snip, I wrote)
>> The IBM chain/train printers have a different spacing for the
>> characters and print columns, which naturally limits the number.
>> I don't know about drum printers.
> Not sure how you mean this? It's fixed spacing, determined by the
> placement of the hammers. Or are you talking about character
> distribution on the chain? That was based on statistical analysis of how
> common characters was. Obviously characters that were more common made
> sense to have at more places on the chain.
As I said above for the drum, where you stagger the print positions
by fractions of a character, the spacing of the characters on the
train is different from the 0.1in column spacing. It seems that the
chain units each hold two characters, but there has to be space for
the flexible link between them. If the spacing on the chain is
23/22 column widths, or 23/220 of an inch, then only six will be
positioned aligned with a hammer at a given time. More details are
in GA24-3073-8 from www.bitsavers.org, though I don't see the exact
spacing discussed.
(snip)
>> Ones that I know, such as, I believe, the Epson MX-100 that I
>> still have, buffer a whole line before printing. That is, no printing
>> until the CR and/or LF. That doesn't work well for an interactive
>> terminal, though, but is a little more efficient for non-interactive
>> printing. Also, in bit graphics mode such printers buffer a whole row.
> Right. Since they print in both directions, many printers needs the
> whole line before it knows where to print if going "backwards" with the
> head.
A character printer, especially if used for interactive use, needs
to be able to print characters as they arrive. A line printer is
optimized for printing whole lines, not necessarily all characters
at exactly the same time. A page printer is optimized for whole
pages, though not printing the whole page at once.
-- glen
none Morten Reistad
In article <981ebb80-1277-461e...@j25g2000vbs.googlegroups.com>,
fishtoprecords <pat2...@gmail.com> wrote:
>On Dec 15, 1:18 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> The usual train for the IBM train printers has, if I remember
>> it right, five of the more popular characters (I believe the 48
>> characters of Fortran), and one copy of the less popular
>> characters (to make up the 60 character set for PL/I).
>> Then there was also a 120 character train including lower case
>> letters and some other unusual characters, such as superscript
>> digits, and the cent sign.
>
>Our IBM shop had a bunch of the train printers. The operators hated
>changing chains, so they would put off printing that used lower case
>until 3rd shift.
>
>The programmers quickly learned that to get any decent turn around on
>their jobs, it had to be all upper case.
Ditto on one ppoe. They had DP train printers in a network, very
early on. (primenet, 1984). Two 600 lpm printers with "commercial"
bands, and one 300lpm "letter" band. The "commercial" band did
have lowercase, but only one set per band; while there were three
uppercase and 6 digit occurrances. The "letter" one had more
even layouts, ISTR they had extra lowrcase instances of the
6 most common letters. ISTR tat one had 2x all ascii symbols,
1x extra ebcdic, and 4x numbers + 6 extra lowercase letters.
The 600lpm printers went slow as daisy-wheels when they got
lowercase documents. So submissions were scanned. More than 40 lines
with more than 5 lc letters or unusual symbols, and the job went
to the 300lpm printer.
>I was hired at AMS because I had years of Tops-10 experience and
>nearly six months on Tops-20. Probably the first day that I was at
>AMS, new hire and all that, they took me on a tour of the "terminal
>room" that all the programmers were so proud of. It had a half dozen
>Model 29 key punches, and two RJE terminals connected to the IBM
>mainframes six blocks away.
>
>I nearly quit on the spot. I was used to a "terminal" being a VT52
>running 9600.
With hindsight it was amazing how modern the tools we kept were.
-- mrr
Johnny Billquist
> On Wed, 15 Dec 2010, Rich Alderson posted:
>>>>>> 1979-1980
>>> I think there might have been DECnet for RSTS/E in that timeframe, but
>>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>>> DECnet was only running over point-to-point interfaces, or multidrop.
>> I'll grant you that work on TCP/IP was in its very early stages at that
>> time. Ethernet, on the other hand, had been in existence for years.
>
> Say what?
>
> Ethernet was a PARC internal experiment with PUP protocol in the 1970s,
> contemporary with ChaosNet/LCSnet at MIT. Stanford was one of the first
> entities outside of PARC to get 3MB Ethernet (on thick-wire coax) along
> with a bunch of Altos.
>
> Metcalf left PARC to form 3COM in 1979. The DEC/Intel/Xerox Ethernet
> specification for 10MB Ethernet (more or less modern Ethernet) was
> published by IEEE in 1980; and 3COM's first Ethernet controller came out
> in 1981.
>
> Work on TCP started at about the same time as Ethernet, and the modern
> protocol was there by 1980. The later date that you may be thinking of
> was the TCP/IP transition on January 1, 1983, when DCA forced ARPAnet to
> convert from NCP to TCP by instructing the IMPs not to pass NCP packets
> any longer.
Yes, partly I was thinking of the big switch to TCP from NCP, which
happened in 1983. Experimental 3Mbit/s ethernet did exist in that
timeframe, but that was, as you say, rather internal to PARC.
Looking at RFCs, you have RFC 793, which is the standard for TCP as we
use it today (well, the starting point anyway). But that one is only
dated 1981-09. An earlier version exists in RFC 761, dated 1980-01. I
can't find anything reliable from before that, even though some stuff is
referenced from RFC 761.
The same goes for IP, for which the earliest RFC I can find is RFC 760,
also dated 1980-01. It has some differences from IP as we know today,
but it's more or less the same protocol anyway.
So, with RSTS/E in the 1979-1980 timeframe as the context, I'd concede
that ethernet and TCP/IP had been invented.
> 32-bit addressing on ARPAnet was quite a bit earlier. I wrote the first
> PDP-10 implementation of 32-bit addressing in spring 1978 for WAITS,
> followed quickly by Dave Moon's implementation for ITS. This rather
> embarassed BBN, which had been dragging its feet on a Tenex implementation.
I seem to have read about that in the past. :-)
What documents did you use to write the implementation, though? Very
curious now.
> Admittedly, my task on 32-bit addressing was made a lot easier by the
> IMP interface that we used on WAITS. It was a DATAI/DATAO device,
> meaning that I could have the interface in 32-bit mode for two DATAIs
> (first 64 bits of IMP leader), switch to 36-bit mode for the next two
> words (last 32 bits of IMP leader, 40-bit NCP leader), then switch back
> to 32-bit mode if the connection was 8-bit or 32-bit instead of 36-bit
> and read the rest of the packet with BLKI in the interrupt location.
>
> IIRC, BBN's IMP interface allowed only one mode switch per packet, so to
> do 32-bit addresses it had to read the entire packet in 32-bit mode and
> do ridiculous shifting in software without using the IMP interface's
> 36-bit mode. That made Tenex network I/O embarassingly slow, and perhaps
> that is why TCP didn't have a 36-bit data transfer mode.
Fun.
Johnny Billquist
> Johnny Billquist<b...@softjar.se> writes:
>
>> On 2010-12-14 19:37, Richard wrote:
>
>>> jmfbahciv<See....@aol.com> spake the secret code
>>> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>
>>>> Richard wrote:
>
>>>>> Machine was available 24/7 by modem. No network. (This was
>>>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>
>>>> Huh. I thought network software came with the OS. Do you remember
>>>> if it was an option when buying the hardware?
>
>>> While I was there, we never had networking. I don't know when
>>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>>> was first made available in RSTS/E.
>
>> I think there might have been DECnet for RSTS/E in that timeframe, but
>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>> DECnet was only running over point-to-point interfaces, or multidrop.
>
> ?????
>
> I'll grant you that work on TCP/IP was in its very early stages at that
> time. Ethernet, on the other hand, had been in existence for years.
>
> Or does "not invented yet" == "not available to systems I knew then"?
I wrote before checking anything up, and as usual, got things wrong. :-)
I was mostly just thinking of the big switch to TCP/IP that happened on
the internet in 1983, and didn't think any further than that.
Bob Koehler
>
> As far as I know, it was Sun that first supplied network software
> included with the OS, no extra charge.
I think folks loaded BSD UNIX on thier VAXen, complete with TCP/IP,
before Sun's first ship.
jmfbahciv
> Johnny Billquist <b...@softjar.se> writes:
>
>> On 2010-12-14 19:37, Richard wrote:
>
>>> jmfbahciv<See....@aol.com> spake the secret code
>>> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>
>>>> Richard wrote:
>
>>>>> Machine was available 24/7 by modem. No network. (This was
>>>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>
>>>> Huh. I thought network software came with the OS. Do you remember
>>>> if it was an option when buying the hardware?
>
>>> While I was there, we never had networking. I don't know when
>>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>>> was first made available in RSTS/E.
>
>> I think there might have been DECnet for RSTS/E in that timeframe, but
>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>> DECnet was only running over point-to-point interfaces, or multidrop.
>
> ?????
>
> I'll grant you that work on TCP/IP was in its very early stages at that
> time. Ethernet, on the other hand, had been in existence for years.
>
> Or does "not invented yet" == "not available to systems I knew then"?
>
years was Phase II, IIRC.
/BAH
jmfbahciv
<GRIN> Big culture shock. That's why people bought DEC gear in
those days.
/BAH
jmfbahciv
/BAH
glen herrmannsfeldt
Well, there was that, and we know where SunOS came from, too.
I am not sure by now how BSD Unix was sold at the time, though.
-- glen
Mark Crispin
> Looking at RFCs, you have RFC 793, which is the standard for TCP as we use it
> today (well, the starting point anyway). But that one is only dated 1981-09.
> An earlier version exists in RFC 761, dated 1980-01. I can't find anything
> reliable from before that, even though some stuff is referenced from RFC 761.
There were a series of IN-NOTES that preceded the RFCs.
>> 32-bit addressing on ARPAnet was quite a bit earlier. I wrote the first
>> PDP-10 implementation of 32-bit addressing in spring 1978 for WAITS,
>> followed quickly by Dave Moon's implementation for ITS. This rather
>> embarassed BBN, which had been dragging its feet on a Tenex implementation.
> I seem to have read about that in the past. :-)
> What documents did you use to write the implementation, though? Very curious
> now.
BBN Report 1822 had everything that was needed; or rather the chapter
devoted to the host/IMP protocol.
fishtoprecords
> fishtoprecords wrote:
> > I nearly quit on the spot. I was used to a "terminal" being a VT52
> > running 9600.
>
> <GRIN> Big culture shock. That's why people bought DEC gear in
> those days.
For sure. I was used to working for the timesharing company and having
direct RS232 lines to whatever front end was on the KL. For years, at
AMS, we used dial up. It was a big deal to upgrade to 2400 bps.
Probably was 3 years before I moved into the same building as the KLs
and had a hard wired, non-modem connection.
But to veer back OT, we did not use printouts (and thus line printers)
as much as one would expect. Interactive programming meant interactive
editing and using a debugger. I don't remember what the COBOL
programmers used, but real men used DDT
Mark Crispin
> Interactive programming meant interactive
> editing and using a debugger. I don't remember what the COBOL
> programmers used, but real men used DDT
This puts me in mind of a discussion Messrs. Paetzold, Grossman(?), and
Crispin got into once upon a time, over large pitchers of beer at a
Marlboro watering hole, about what Real Men used.
We dismissed EXEC and DDT early on as being for wusses.
Ultimately, we ended up with a bare metal Frankenstein-lab type switch,
carrying 50KV, which would be toggled in binary (don't need no stinkin'
lights, a Macho Programmer knows what the state of things are).
And when you logged off, you really logged off! :p
fishtoprecords
> Ultimately, we ended up with a bare metal Frankenstein-lab type switch,
> carrying 50KV, which would be toggled in binary (don't need no stinkin'
> lights, a Macho Programmer knows what the state of things are).
>
> And when you logged off, you really logged off! :p
So simple examine and deposit directly with octal values into running
monitor was for wimp, eh? Must have been a lot of beer.
Probably was pre-KL, as at least with KA and KI you could toggle up
values and addresses, not a proper lab switch that would kill you, but
at least real switches. The KL had such a blank face, made real men
cry.
Mark Crispin
> monitor was for wimp, eh?
Octal?? Wusses. Macho programmers don't need no stinkin' octal, they do
binary. And they don't need no stinkin' lights, 'cuz they know what the
values are. And they don't need no stinkin' multiple switches, they just
need one that they toggle at the correct bitrate...
> Must have been a lot of beer.
It was. :p
> Probably was pre-KL, as at least with KA and KI you could toggle up
> values and addresses, not a proper lab switch that would kill you, but
> at least real switches.
This conversation was in the 1980s. But I have talked at some length with
KA, KI, and even PDP-6; own a KA and KI front panel and two working PDP-8.
The Panda panel was originally going to be both switches and lights but it
proved to be impractical to have the necessary number of DIP switches.
> The KL had such a blank face, made real men
> cry.
True.
jmfbahciv
<GRIN> And bit gods used EDDT.
We had complete listings and FILCOMs of each monitor edit (which was
done every Tuesday). I would make a listing of each CUSP I developed
and/or maintained.
did you use the fiche we shipped?
/BAH
Bob Koehler
>
> I am not sure by now how BSD Unix was sold at the time, though.
Since the B stands for Berkley, I'll give you one guess who was
selling it.
Mark Crispin
> <GRIN> And bit gods used EDDT.
TOPS-10 never had MDDT as far as I knew.
You could DDT the monitor standalone with EDDT, or you could patch files
and the running monitor with FILDDT. But only MDDT let you call routines
in the running monitor while other users were doing work!
Just one wrong character...
> did you use the fiche we shipped?
Digital was very stingy with its fiche. Not even source customers got
TOPS-20 monitor fiche. We got to see it, and handle it, during monitor
internals class, but only the SWSes got to take their set with them
afterwards.
It was one of the crass stupidities that made Digital be Digital and not
DEC.
fishtoprecords
> Digital was very stingy with its fiche. Not even source customers got
> TOPS-20 monitor fiche. We got to see it, and handle it, during monitor
> internals class, but only the SWSes got to take their set with them
> afterwards.
We were a source site, and never cared about the Dec fiche. For
unrelated reasons, we owned a large fiche and COP (big computer output
to printer) shop, so we just sent our spooled listings down the hall
and got as many fiche as we wanted.
Alan Frisbie
> The particular question had to do with the line-at-a-time things. However,
> I just wanted to say that I'm impressed beyond all measure that your P-300
> has lasted so long. We had three at LOTS (Stanford), one on each KL-10, and
> they were a bit dodgy. Of course, when you use a printer in a 24x7 student
> facility, it's going to get pounded on...
The only problem we have is that ribbons are getting hard to find.
One of my clients was a mailing house. They had four P-600 (twice the
speed of a P-300) banging out mailing labels all day long. They were
even equipped with the optional carbide-tipped print shuttles for extra
life.
Alan "The Other AEF" Frisbie
glen herrmannsfeldt
> In article <ieddue$q5f$1...@news.eternal-september.org>, glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>> I am not sure by now how BSD Unix was sold at the time, though.
> Since the B stands for Berkley, I'll give you one guess who was
> selling it.
I believe it was more complicated than that, though I don't
know the details much at all. At that time, Unix was still
licensed from Bell labs, as I understand it. It took some time
to get all the original code out such that FreeBSD could be
distributed freely. My understanding, partly from reading the
Wikipedia page, is that the BSD code was free, but you needed
a license from AT&T.
Also, I am not so sure by now how Sun did its licensing.
I believe it was at least no-charge for academic owners
of Sun machines. There were also Sun clones, which may have
had to buy a license for SunOS. In any case, as far as I know
the SunOS license always included the networking code for
no extra charge.
Around that time, I had OS/2 running on my machine at home,
and IBM did charge for the TCP/IP code for that. I had a
subscription to the DevelopersConnection, mostly so that I
could run the TCP/IP that came with it. But that would have
been in the late SunOS 3.x and early 4.x years.
MS charges for "client licenses" to use its networking products,
including TCP/IP access to web servers. (That is, one has to
license for the number of possible simultaneous connections
to a web server. (I believe that is still true, though I haven't
been interested in running MS based web servers for years now.)
I believe that Solaris was much more popular for web servers
than NT because of different licensing rules.
In addition, note that much of the Sun originated code has
been freely available, such as RPC, XDR, and, I believe NFS.
(Though usually with the requirement to give the appropriate
copyright notice.)
-- glen
Bob Koehler
>
> I believe it was more complicated than that, though I don't
> know the details much at all. At that time, Unix was still
> licensed from Bell labs, as I understand it. It took some time
> to get all the original code out such that FreeBSD could be
> distributed freely. My understanding, partly from reading the
> Wikipedia page, is that the BSD code was free, but you needed
> a license from AT&T.
UNIX breathers swear that at the time AT&T was barred from selling
UNIX due to being a utility/monopoly, gave it to BSD, who added
TCP/IP, ported it to VAX, and got so many requests for copies that
they started selling them. I was told $40K US, but not from a
reliable source.
Rich Alderson
> On Wed, 15 Dec 2010, Rich Alderson posted:
>>>>>> 1979-1980
>>> I think there might have been DECnet for RSTS/E in that timeframe, but
>>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>>> DECnet was only running over point-to-point interfaces, or multidrop.
>> I'll grant you that work on TCP/IP was in its very early stages at that
>> time. Ethernet, on the other hand, had been in existence for years.
> Say what?
"only limited, experimental availability" != "not invented yet"
That was my primary objection.
--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
Mark Crispin
> Mark Crispin <m...@panda.com> writes:
>> On Wed, 15 Dec 2010, Rich Alderson posted:
>>>>>>> 1979-1980
>>>> I think there might have been DECnet for RSTS/E in that timeframe, but
>>>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>>>> DECnet was only running over point-to-point interfaces, or multidrop.
>>> I'll grant you that work on TCP/IP was in its very early stages at that
>>> time. Ethernet, on the other hand, had been in existence for years.
>> Say what?
> "only limited, experimental availability" != "not invented yet"
> That was my primary objection.
TCP/IP and Ethernet were in more or less the same state in the 1979-1980
timeframe.
I was there. In fact, I fought (and lost) a battle to deploy TCP/IP at
once on Stanford's nascent 3MB Ethernet, rather than waste time with PUP.
The PARC fanboys shouted me down, insisting that PUP had a great and
glorious future.
By 1984, PUP was dead legacy technology.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
glen herrmannsfeldt
> NB: Follow-ups set to comp.sys.dec as the most neutral place on the list.
alt.sys.pdp10 restored, otherwise I won't see replies.
> I have been asked to find out whether anyone still uses line printers on
> their DEC systems. I'm not sure why the question came up, exactly, though
> we have just sent a board design out for manufacture for a replacement
> M8571 (which appear to be unobtainium) in order to hook an LP27 to a 2065.
So, why not an ethernet attached print server instead of direct
interface to the system? I don't know if that is easier than recreating
the M8571, though.
-- glen
jmfbahciv
> On Fri, 17 Dec 2010, jmfbahciv posted:
>> <GRIN> And bit gods used EDDT.
>
> TOPS-10 never had MDDT as far as I knew.
It did not.
>
> You could DDT the monitor standalone with EDDT, or you could patch files
> and the running monitor with FILDDT. But only MDDT let you call routines
> in the running monitor while other users were doing work!
EDDT.REL was loaded with monitor.
>
> Just one wrong character...
>
>> did you use the fiche we shipped?
>
> Digital was very stingy with its fiche. Not even source customers got
> TOPS-20 monitor fiche. We got to see it, and handle it, during monitor
> internals class, but only the SWSes got to take their set with them
> afterwards.
Software support and field service were shipped fiche (I'm now talking
about TOPS-10 distribution). I don't know if customers ever used
fiche because they could generate their own hard copy listings, along with
all their mods.
>
> It was one of the crass stupidities that made Digital be Digital and not
> DEC.
That was the TOPS-20 mindset. It went to extremes when VMS started
shipping.
/BAH
Mark Crispin
>> You could DDT the monitor standalone with EDDT, or you could patch files
>> and the running monitor with FILDDT. But only MDDT let you call routines
>> in the running monitor while other users were doing work!
> EDDT.REL was loaded with monitor.
Yes, but EDDT is not the same.
MDDT was a system call (JSYS 777) and you could play in MDDT while other
users were innocently working, utterly unaware of what wicked things you
might be doing.
> Software support and field service were shipped fiche (I'm now talking
> about TOPS-10 distribution). I don't know if customers ever used
> fiche because they could generate their own hard copy listings, along with
> all their mods.
Fiche is convenient becase of size (complete monitor listings are huge
unless you get can them printed on small-sized paper) and also it is
useful to have a "vanilla DEC" listen as a baseline.
>> It was one of the crass stupidities that made Digital be Digital and not
>> DEC.
> That was the TOPS-20 mindset. It went to extremes when VMS started
> shipping.
Not the TOPS-20 development team. They thought that it was stupid too.
It must have been marketing.
Rich Alderson
Because the system does not have an NIA20, and Tops-10 does not support
TCP/IP printing, and we're not going to run DECnet for other reasons?
It really is easier to recreate a single board for the front end than to
find a rare multi-board piece of hardware, then write the operating system
code to use that hardware, then write the print spooler code to talk to the
operating system about using a printer at the other end of the network.
Johnny Billquist
> Rich Alderson wrote:
>> Johnny Billquist<b...@softjar.se> writes:
>>
>>> On 2010-12-14 19:37, Richard wrote:
>>
>>>> jmfbahciv<See....@aol.com> spake the secret code
>>>> <PM0004975...@aca38a9c.ipt.aol.com> thusly:
>>
>>>>> Richard wrote:
>>
>>>>>> Machine was available 24/7 by modem. No network. (This was
>>>>>> 1979-1980; networking was a luxury on RSTS/E at that time.)
>>
>>>>> Huh. I thought network software came with the OS. Do you remember
>>>>> if it was an option when buying the hardware?
>>
>>>> While I was there, we never had networking. I don't know when
>>>> networking (of any variety, DECnet, LAT, TCP/IP, etc.) of any variety
>>>> was first made available in RSTS/E.
>>
>>> I think there might have been DECnet for RSTS/E in that timeframe, but
>>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>>> DECnet was only running over point-to-point interfaces, or multidrop.
>>
>>
>> I'll grant you that work on TCP/IP was in its very early stages at that
>> time. Ethernet, on the other hand, had been in existence for years.
>>
>>
> DECnet Phase IV was DEC's ethernet implementation. RSTS/E during those
> years was Phase II, IIRC.
Well, it was rather that ethernet support didn't appear until DECnet
phase IV. But DECnet is not really some ethernet "implementation".
Ethernet is just one medium over which DECnet communication can take place.
I think that 1979-1980 would probably be DECnet phase III, by the way.
But I might be wrong.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist
> Mark Crispin<m...@panda.com> writes:
>
>> On Wed, 15 Dec 2010, Rich Alderson posted:
>
>>>>>>> 1979-1980
>
>>>> I think there might have been DECnet for RSTS/E in that timeframe, but
>>>> no LAT, nor TCP/IP. Neither had even been invented yet. Nor ethernet.
>>>> DECnet was only running over point-to-point interfaces, or multidrop.
>
>>> I'll grant you that work on TCP/IP was in its very early stages at that
>>> time. Ethernet, on the other hand, had been in existence for years.
>
>> Say what?
>
> "only limited, experimental availability" != "not invented yet"
>
> That was my primary objection.
Yeah. Sorry for that. Wrote without thinking... (What was I thinking of...)
glen herrmannsfeldt
>> So, why not an ethernet attached print server instead of direct
>> interface to the system? I don't know if that is easier than recreating
>> the M8571, though.
> Because the system does not have an NIA20, and Tops-10 does not support
> TCP/IP printing, and we're not going to run DECnet for other reasons?
Well that is a pretty good reason. Does TOPS-20 have TCP/IP print
support?
You could, though, go out the serial port and then through a
terminal server to a spooler. I don't know if there is software
to do that, but it should be pretty simple on a unix system.
The complicated part is always finding the separation between
print jobs.
> It really is easier to recreate a single board for the front end than to
> find a rare multi-board piece of hardware, then write the operating system
> code to use that hardware, then write the print spooler code to talk to the
> operating system about using a printer at the other end of the network.
If you have a museum full of systems, though, the convenience of
network attached printers is that each system can print to it.
Well, you could also network spool between similar systems
until you get to one that can support TCP/IP or other protocol
with available print servers.
-- glen
Rich Alderson
> If you have a museum full of systems, though, the convenience of
> network attached printers is that each system can print to it.
> Well, you could also network spool between similar systems
> until you get to one that can support TCP/IP or other protocol
> with available print servers.
The point of the systems in the museum is to work as they did when in full
use, with original software, rather than making them all look "just like
your iHack". :-)
But thanks for the suggestion!
glen herrmannsfeldt
>> If you have a museum full of systems, though, the convenience of
>> network attached printers is that each system can print to it.
>> Well, you could also network spool between similar systems
>> until you get to one that can support TCP/IP or other protocol
>> with available print servers.
> The point of the systems in the museum is to work as they did when in full
> use, with original software, rather than making them all look "just like
> your iHack". :-)
> But thanks for the suggestion!
How about spooling from TOPS-10 to TOPS-20 through a serial port,
and from there to something else network attached? Or maybe
a PDP-11?
But yes there is something to historical accuracy in a museum, but
always the question how far you can go. When you get the new boards
make, do you use old PC board blanks and old solder? Check the date
code on all the ICs?
I know some people replace the old power supplies with modern
switching supplied, posibbly to save on power costs. Do you wire
the building with old wire, and use only old power transformers for
your building power source?
Anyway, the subject of the thread is present tense.
-- glen
jmfbahciv
Sorry, I wasn't clear. DECNET Phase IV implemented ethernet.
> Ethernet is just one medium over which DECnet communication can take place.
IMO, it was the only working medium for DECNET. Everything else sucked.
>
> I think that 1979-1980 would probably be DECnet phase III, by the way.
> But I might be wrong.
It's possible, but I don't remember doing Phase III certification on RSTS/E
in 1981 and 1983. When TOPS-10 and TOPS-20 shipped DECNET, we had to
pass the internal certification tests. That meant running scripts on all
OSes DEC supported against the -10 and -20 software. RSTS/E was one
of the OSes I had to do.
/BAH
Robert Bonomi
Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
>In article <PM0004970...@aca3ebba.ipt.aol.com>, jmfbahciv
><See....@aol.com> writes:
>>
>> My condolences. What did you do when waiting? Knit socks? :-)
>
> Slow serial printers are a pain. But did you ever try to type
> at over 300 baud?
300 baud is the equivalent of _three_hundred_ words per minute. nobody
types that fast. World's fast typist is in the mid 200's.
Robert Bonomi
Bob Koehler <koe...@eisner.nospam.encompasserve.org> wrote:
>In article <ieghb1$m77$1...@news.eternal-september.org>, glen
>herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>>
>> I believe it was more complicated than that, though I don't
>> know the details much at all. At that time, Unix was still
>> licensed from Bell labs, as I understand it. It took some time
>> to get all the original code out such that FreeBSD could be
>> distributed freely.
U.C. Berkeley _never_did_ get a 'complete' operational software release
out that was totally free of the need for an AT&T license.
The final BSD release, when the CSRG was disbanded was 'close to complete'
but there were come critical pieces that anyone wanting to build an
operational O/S had to provide themselves, "somehow".
>> My understanding, partly from reading the
>> Wikipedia page, is that the BSD code was free, but you needed
>> a license from AT&T.
>
> UNIX breathers swear that at the time AT&T was barred from selling
> UNIX due to being a utility/monopoly, gave it to BSD, who added
> TCP/IP, ported it to VAX, and got so many requests for copies that
> they started selling them. I was told $40K US, but not from a
> reliable source.
"Not Exactly". AT&T was barred by an anti-trust 'consent decree', from
selling things, commercially, "at a profit" outside of their core line of
business. If it was 'non-commercial', and 'at cost', "no problem". So, for
academia, a couple of hundred dollars or so, got you an academic
right-to-use license, a tape with the source code on it, and a few pages of
basic installation documentation. For everything else, you were strictly
"on your own", -zero- official support from AT&T. This was one of the big
driving forces behind the first UUCP networking, all these 'unsupported O/S'
users being able to cry in each others beer when an unexpected problem arose.
UCB had an operating systems 'research' group that took the base AT&T product
and (a) added a bunch of functionality, (b) made some major performance i
improvements. A large part of the work was considered a 'derivative work' of
the AT&T intellectual property, so they (UCB) couldn't provide their
improvements to anyone who didn't also have an AT&T license.
Eventually AT&T got out from under the court order, and started offering
Unix licenses commercially. $25k, for full source, and unlimited runtime
RTU. runtime licensing was freely transferable. When AT&T started to
offer 'commercial' licenses, the commercial buyers were those who had
experience with it in the academic environment. Thus an 'instant'
commercial demand for the BSD enhancements as well. UCB was not slow in
adapting to the situation, and a 'commercial use' BSD license was developed.
Unlike the AT&T pricing, _I_ never saw an official quote for the BSD
distribution, but I heard considerable conversation, admittedly, from not
necessarily reliable sources, about a $15k price-tag in the early commercial
days.
Time passes, and At&T introduces its own set of semi-incompatible improvements
to UNIX and declares that to be the one "true UNIX". A large part of the
world didn't s see things the same way. Enter the Open Systems Foundation.
The Berkeley vs. AT&T schism widens. UCB throws gasoline on the fire,
announcing the intent to produce a completely "AT&T free" version of _their_
concept of what UNIX looks like.
Robert Bonomi
Johnny Billquist <b...@softjar.se> wrote:
>On 2010-12-14 19:34, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Lawrence D'Oliveiro<l...@geek-central.gen.new_zealand> spake the secret code
>> <ie77ua$g29$1...@lust.ihug.co.nz> thusly:
>>
>>> In message
>>> <5a77acc7-46ed-42c8...@u9g2000pra.googlegroups.com>,
>>> fishtoprecords wrote:
>>>
>>>> On Dec 7, 8:49 pm, glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>>>>> I suppose I thought that DECwriters were DEC designs, but I
>>>>> don't know about others.
>>>>
>>>> I think the LA36 was a real DEC engineered design. But the subject
>>>> line at started this is about line printers, and the LA36 and similar
>>>> devices were character printers.
>>>
>>> LA180, then.
>>
>> The LA180 is also a character printer and not a line-at-a-time printer.
>
>Well, technically, a line printer did not print a line at a time either.
>You had one hammer per character position, and then the chain (or
>whatever) moving characters along, and the hammer hit when the right
>character was in front. That means the same character was not available
>at other positions.
True of a 'chain train' printer. *NOT* true of all line printers.
Specific reference to the DataProducts 'drum' printers, which had a wheel
with the complete character set at each print position. Depending on the
drum, and the character set, the characters might be offset at successive
print positions or they might not. I, personally, used on where the
characters on the drum were in the -same- slot at all character positions.
Printing a row of minus signs, or equal signs. across the entire page
sounded almost like a gunshot: "braaapbraaapbraaap*WHAM*braaapbraaap...."
We also found out you could blow a circuit breaker that way. <wry grin>
> The
>power surge from trying to fire all 132 hammers at the same time would
>blow fuses, and burn wires. In reality, the printer was limited to not
>fire more than around 6 hammers (maximum) at the same time.
*NOT* true on the DataProducts units (a "B600", IIRC). We managed to blow
a mains breaker once, but only because there was other load on the circuit.
And we had print runs that did *boxes* of wide paper with half-a-dozen or
so 'rules' across the entire page. It was doing a "WHAM" every second or
two, for hours at a time. You could _see_ the printer shudder when one of
those lines printed.
I'll admit I nearly jumped out of my skin the first time I was in the
computer room and one of those jobs started printing.
Robert Bonomi
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:>(snip)
>>> The LA180 is also a character printer and not a line-at-a-time printer.
>
>> Well, technically, a line printer did not print a line at a time either.
>> You had one hammer per character position, and then the chain (or
>> whatever) moving characters along, and the hammer hit when the right
>> character was in front. That means the same character was not available
>> figure out, on a 132 column printer, with a chain going around, you'll
>> have room for 264 characters on the chain, minimum (there are some more,
>> since the chain needs some space to turn around as well).
>
>The IBM line printers are chain or train printers, but the DEC
>printers I remember are drum printers, which could possibly print
>a whole line at once. It would seem easiest for a drum printer
>to have the same at the same rotational position for all columns,
>in which case it would for a whole row of the same character.
I think those were rebadged DataProducts units.
>I don't know about drum printers.
Drum printers almost invariably have one instance of each character around
the drum.
Richard
glen herrmannsfeldt <g...@ugcs.caltech.edu> spake the secret code
<ieppjf$nno$1...@news.eternal-september.org> thusly:
>But yes there is something to historical accuracy in a museum, but
>always the question how far you can go. When you get the new boards
>make, do you use old PC board blanks and old solder? Check the date
>code on all the ICs?
>
>I know some people replace the old power supplies with modern
>switching supplied, posibbly to save on power costs. Do you wire
>the building with old wire, and use only old power transformers for
>your building power source?
I've been to their museum. They try to use original equipment as much
as possible, falling back to replicas (as in the case of this board)
when necessary. They have upgraded the power supplies to more
efficient supplies in such a way that the original supplies could be
reinserted into the machine to restore it to original condition.
They aren't a couple of goobers tinkering around in a basement; they
have real world period experience with the machines that they restore
to functioning condition for present use. They have done museum
training that most people don't bother with when they setup their
"vintage computer museum".
So yes, for the things that matter, they are paying attention.
However, some of your questions border on the insane and I'm glad that
they don't pay attention to items like that.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
glen herrmannsfeldt
(snip)
> 300 baud is the equivalent of _three_hundred_ words per minute.
> nobody types that fast. World's fast typist is in the mid 200's.
Maybe not, but I do remember the story about someone who could
type fast enough to overflow the KA-10/TOPS-10 TTY input buffer,
I believe on a 300 baud line. That would have been before 1976
if that matters.
-- glen
glen herrmannsfeldt
>>The IBM line printers are chain or train printers, but the DEC
>>printers I remember are drum printers, which could possibly print
>>a whole line at once. It would seem easiest for a drum printer
>>to have the same at the same rotational position for all columns,
>>in which case it would for a whole row of the same character.
> I think those were rebadged DataProducts units.
>>I don't know about drum printers.
> Drum printers almost invariably have one instance of each character
> around the drum.
It might be that one would build a numeric only drum printer with
more than one copy. IBM had numeric only trains, well, maybe 16
characters so add +, -, comma, and two others.
-- glen
Richard
glen herrmannsfeldt <g...@ugcs.caltech.edu> spake the secret code
<ieqtfn$sol$3...@news.eternal-september.org> thusly:
IIRC, on RSTS/E the input buffer can be filled while the output buffer
is being emptied. It wouldn't be hard to just keep typing while the
output flowed and the program wasn't yet ready to read input and you
eventually fill up the input buffer.
glen herrmannsfeldt
> [Please do not mail me a copy of your followup]
>>But yes there is something to historical accuracy in a museum, but
>>always the question how far you can go. When you get the new boards
>>make, do you use old PC board blanks and old solder? Check the date
>>code on all the ICs?
(snip)
> I've been to their museum. They try to use original equipment as much
> as possible, falling back to replicas (as in the case of this board)
> when necessary. They have upgraded the power supplies to more
> efficient supplies in such a way that the original supplies could be
> reinserted into the machine to restore it to original condition.
I am only across the lake, but still haven't been over to see it.
I do have an account so that I can logon, though.
> They aren't a couple of goobers tinkering around in a basement; they
> have real world period experience with the machines that they restore
> to functioning condition for present use. They have done museum
> training that most people don't bother with when they setup their
> "vintage computer museum".
> So yes, for the things that matter, they are paying attention.
> However, some of your questions border on the insane and I'm
> glad that they don't pay attention to items like that.
I didn't include finding a power generation station with
appropriately old generators. Well, power gets mixed up enough
in the grid that it isn't easy to figure out where it comes from.
Matching the color of the PC board material doesn't seem so bad.
Though one might want to intentionally indicate the parts that
are not original by using a distinctive material. Not being
a specialist in museum restoration, (that is, in general) I
believe that some do something similar.
-- glen
glen herrmannsfeldt
(snip, I wrote)
>>Maybe not, but I do remember the story about someone who could
>>type fast enough to overflow the KA-10/TOPS-10 TTY input buffer,
>>I believe on a 300 baud line. That would have been before 1976
>>if that matters.
> IIRC, on RSTS/E the input buffer can be filled while the output buffer
> is being emptied. It wouldn't be hard to just keep typing while the
> output flowed and the program wasn't yet ready to read input and you
> eventually fill up the input buffer.
Oh, I forgot the end. When you did fill up the buffer, the
system crashed. I don't know enough about TOPS-10 internals
to know why that might happen, though. The story might have
been that no-one could type that fast such that they didn't
need to test for it.
-- glen
Patrick Scheible
Nobody types that fast *sustained speed*, but they do for short
bursts. If there's a small or nonexistent buffer that empties at 300
baud, a good typist can overflow it if they hit a fast burst --
familiar words that are typed with alternating hands.
-- Patrick
Lawrence D'Oliveiro
> ... or the output of a COBOL listing with a million errors because of a
> missing period.
“PROCEDURE DIVISON” would send the RSTS/E compiler into an endless loop.
Lawrence D'Oliveiro
Robert Bonomi wrote:
> 300 baud is the equivalent of _three_hundred_ words per minute. nobody
> types that fast. World's fast typist is in the mid 200's.
I remember we ran our VT52 terminals in “split speed” for this reason: 300
transmit, 2400 receive.
People can read much faster than three hundred words per minute.
Lawrence D'Oliveiro
wrote:
> When you did fill up the buffer, the system crashed. I don't know enough
> about TOPS-10 internals to know why that might happen, though. The story
> might have been that no-one could type that fast such that they didn't
> need to test for it.
It was easy enough to create that situation: just short the transmit and
receive lines together. :)
John Francis
IIRC there was a fencepost error in the buffer management code
in SCNSER, so you could get a (one-character) buffer overrun.
It's even remotely possible that the fix for it was first
published as part of one of my SPRs - UMIST, where I was working
at the time, was one of the earlier places to hook up high-speed
terminals to a KA-10 (initially Adage ARDS-1s, later followed by
Tektronix 4010s and 40104s, and one Tektronix 4012).
Any terminal capable of responding to an INQ by transmitting an
identification string can fill the buffer faster than any human
typist. Sending garbage character sequences to such a terminal
can sometimes have surprising consequences ...
Johnny Billquist
> Johnny Billquist wrote:
>> Ethernet is just one medium over which DECnet communication can take place.
>
> IMO, it was the only working medium for DECNET. Everything else sucked.
You have a sather limited view on what "worked" means, in that case.
Speaking as one who occasionally still use DECnet over asynch serial
lines, using DDCMP, I can testify that it works just fine.
And one commercial site that I know of ran DECnet over DMV-11 (I hope I
remember that right) until until last year.
And there was, of course, the places that ran DECnet over X.25 or X.29
networks. Never saw any multidrop usage myself, though. But I'm sure
that was/is used too.
>> I think that 1979-1980 would probably be DECnet phase III, by the way.
>> But I might be wrong.
>
> It's possible, but I don't remember doing Phase III certification on RSTS/E
> in 1981 and 1983. When TOPS-10 and TOPS-20 shipped DECNET, we had to
> pass the internal certification tests. That meant running scripts on all
> OSes DEC supported against the -10 and -20 software. RSTS/E was one
> of the OSes I had to do.
I'm curious if they somehow managed to still do that in 1999, when the
latest (last?) version of DECnet-RSX was released. There were
compatibility notes in the release notes for VMS, RSTS/E, RT-11 and
TOPS-20 (nothing on TOPS-10 though). It could be that they just kept the
same notes that had been around for the last ten years or so... Although
I seem to remember some Y2K comments in there...
Charles Richmond
300 baud may be 300 *characters* per minute, but in typing, the
average word is considered 5 characters (six if you count the
space after the word). So 300 baud would be more like 60 words per
minute... which *is* achievable by a good typist.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Charles Richmond
> On 12/21/10 9:05 AM, Robert Bonomi wrote:
>> In article<1kep21...@eisner.encompasserve.org>,
>> Bob Koehler<koe...@eisner.nospam.encompasserve.org> wrote:
>>> In article<PM0004970...@aca3ebba.ipt.aol.com>, jmfbahciv
>>> <See....@aol.com> writes:
>>>>
>>>> My condolences. What did you do when waiting? Knit socks? :-)
>>>
>>> Slow serial printers are a pain. But did you ever try to type
>>> at over 300 baud?
>>
>> 300 baud is the equivalent of _three_hundred_ words per minute.
>> nobody
>> types that fast. World's fast typist is in the mid 200's.
>>
>>
>
> 300 baud may be 300 *characters* per minute, but in typing, the
> average word is considered 5 characters (six if you count the
> space after the word). So 300 baud would be more like 60 words per
> minute... which *is* achievable by a good typist.
>
300 words a minute. 30 characters a second times 60 seconds per
minute = 1800 characters. Divided by 6 characters per word = 300
words per minute.
glen herrmannsfeldt
(snip)
> 300 baud may be 300 *characters* per minute, but in typing, the
> average word is considered 5 characters (six if you count the
> space after the word). So 300 baud would be more like 60 words per
> minute... which *is* achievable by a good typist.
300 baud is 30 characters per second, 1800 characters per
minute, and so 360 words per minute.
According to wikipedia, the space counts in WPM calculations.
-- glen
jmfbahciv
> On 2010-12-21 15:40, jmfbahciv wrote:
>> Johnny Billquist wrote:
>>> Ethernet is just one medium over which DECnet communication can take
place.
>>
>> IMO, it was the only working medium for DECNET. Everything else sucked.
>
> You have a sather limited view on what "worked" means, in that case.
I had to wrestle with the MCB too often. My perspective was from the
PDP-10 side of DECnet. The only DECnet which worked well as comm and
networking on the PDP-10 was the ethernet implementation.
RSTS was a PITA, too. IIRC, I had to do all kinds of magic incantatations
just to get a network connection working...I"ll get this wrong...I think
the comm gear was a KMC-11. On the days when my magic incantations
didn't work, I'd have to wait for RDH to come in (his shift was 15:00 or 16:00
to midnight or so) and have him look at the KMC. That's all it needed to
for its lights to begin flashing. I kid you not.
> Speaking as one who occasionally still use DECnet over asynch serial
> lines, using DDCMP, I can testify that it works just fine.
> And one commercial site that I know of ran DECnet over DMV-11 (I hope I
> remember that right) until until last year.
>
> And there was, of course, the places that ran DECnet over X.25 or X.29
> networks. Never saw any multidrop usage myself, though. But I'm sure
> that was/is used too.
>
>>> I think that 1979-1980 would probably be DECnet phase III, by the way.
>>> But I might be wrong.
>>
>> It's possible, but I don't remember doing Phase III certification on RSTS/E
>> in 1981 and 1983. When TOPS-10 and TOPS-20 shipped DECNET, we had to
>> pass the internal certification tests. That meant running scripts on all
>> OSes DEC supported against the -10 and -20 software. RSTS/E was one
>> of the OSes I had to do.
>
> I'm curious if they somehow managed to still do that in 1999, when the
> latest (last?) version of DECnet-RSX was released. There were
> compatibility notes in the release notes for VMS, RSTS/E, RT-11 and
> TOPS-20 (nothing on TOPS-10 though). It could be that they just kept the
> same notes that had been around for the last ten years or so... Although
> I seem to remember some Y2K comments in there...
If DEC hadn't changed the ship criteria, any DECnet release would have
had to be certified. I would imagine that the same compatibility issues
would exist since the asspects would not have been fixed.
/BAH
jmfbahciv
The OS would shut down the line in that case as an "open" TTY line.
I believe Glen is talking about the bug in 4S72 or earlier. The result
was the creation of the IRMA bit. If you're nice and plead a lot,
/RCC might read this and tell the story again, putting into machine
readable form for the nth generation to rediscover and implement ;-).
It was a firefight.
/BAH
jmfbahciv
> On Sat, 18 Dec 2010, jmfbahciv posted:
>>> You could DDT the monitor standalone with EDDT, or you could patch files
>>> and the running monitor with FILDDT. But only MDDT let you call routines
>>> in the running monitor while other users were doing work!
>> EDDT.REL was loaded with monitor.
>
> Yes, but EDDT is not the same.
>
> MDDT was a system call (JSYS 777) and you could play in MDDT while other
> users were innocently working, utterly unaware of what wicked things you
> might be doing.
>
>> Software support and field service were shipped fiche (I'm now talking
>> about TOPS-10 distribution). I don't know if customers ever used
>> fiche because they could generate their own hard copy listings, along with
>> all their mods.
>
> Fiche is convenient becase of size (complete monitor listings are huge
> unless you get can them printed on small-sized paper) and also it is
> useful to have a "vanilla DEC" listen as a baseline.
>
>>> It was one of the crass stupidities that made Digital be Digital and not
>>> DEC.
>> That was the TOPS-20 mindset. It went to extremes when VMS started
>> shipping.
>
> Not the TOPS-20 development team. They thought that it was stupid too.
>
> It must have been marketing.
Who listened to the development team.
/BAH
jmfbahciv
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
>> In alt.sys.pdp10 Rich Alderson <ne...@alderson.users.panix.com> wrote:
>
>
>> alt.sys.pdp10 restored, otherwise I won't see replies.
>
>>> I have been asked to find out whether anyone still uses line printers on
>>> their DEC systems. I'm not sure why the question came up, exactly,
>>> though we have just sent a board design out for manufacture for a
>>> replacement M8571 (which appear to be unobtainium) in order to hook an
>>> LP27 to a 2065.
>
>> So, why not an ethernet attached print server instead of direct
>> interface to the system? I don't know if that is easier than recreating
>> the M8571, though.
>
> Because the system does not have an NIA20, and Tops-10 does not support
> TCP/IP printing, and we're not going to run DECnet for other reasons?
Why aren't you using ANF-10?
>
> It really is easier to recreate a single board for the front end than to
> find a rare multi-board piece of hardware, then write the operating system
> code to use that hardware, then write the print spooler code to talk to the
> operating system about using a printer at the other end of the network.
>
You can put the printer on any -11 or -8, load it with the appropriate
ANF-10 driver and make a TWINKY node. ;-)
/BAH
Bob Koehler
>
> Maybe not, but I do remember the story about someone who could
> type fast enough to overflow the KA-10/TOPS-10 TTY input buffer,
> I believe on a 300 baud line. That would have been before 1976
> if that matters.
And there was the case of the PDP-11 OS, which couldn't handle
communication at high speeds over a serial line. While tracking
down the problem the engineer found a comment about high speed
handling code being not right, but nobody can type that fast anyhow.
The problem only showed up when another computer actually sent
characters at full speed.
Bob, K1BC
Man, is this garbled.
There was a bug, which I called "the Irma bug", because it seemed to
reliably hit this poor woman in Salt Lake City.
It caused a single TTY line to hang. Not a system crash. It happened
with normal human-speed typing. Not full-speed input.
The fix was to discover (the hard part) and fix the code with the
race condition. There was no "Irma bit" added, or involved at all.
The bug was that the TTY code assumed DEVIOS(DEVDAT) was being
handled safely by existing monitor routines. But SETIOD (not in
the TTY code) was not interrupt safe, so it was clobbering a bit
that the TTY code used (safely) at both interrupt and non-interrupt
levels.
/Rcc
Mark Crispin
> The bug was that the TTY code assumed DEVIOS(DEVDAT) was being
> handled safely by existing monitor routines. But SETIOD (not in
> the TTY code) was not interrupt safe, so it was clobbering a bit
> that the TTY code used (safely) at both interrupt and non-interrupt
> levels.
I thought that SETIOD was only called at interrupt level, and didn't
mangle the DEVIOS (or anything else in the DDB)? You called it by first
doing MOVE IOS,DEVIOS(DEVDAT) and IOS was only looked at.
At least that's the way it was on WAITS.
Hmm. I see that 3.19 works as in WAITS.
However, 7.02 does a MOVEM S,DEVIOS(F) after first possibly turning off
IOW. In the main flow, that's just to turn off IOW. So the obvious fix
is just
MOVEI S,IOW
ANDCAB S,DEVIOS(F)
But then there's this STPIOD entry point, which is called from SWPINT in
SWPSER, which is called by DONE in VMSER, and somewhere way back there S
got set up with who-knows-what.
Yuck.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Bob, K1BC
> So the obvious fix is [...]
Indeed. As I implied, the fix was not hard. The hard part was
finding the problem. Which required going to Salt Lake City,
since nobody else but Irma (or her TTY or her machine) was hitting
the race condition. And watching her and her coworkers suffer
through repeated debugging sessions. And trying to dope it out
with the customer looking over my shoulder.
/Rcc
jmfbahciv
> jmfbahciv wrote:
>> Lawrence D'Oliveiro wrote:
>>> In message <ier1u6$b3l$3...@news.eternal-september.org>, glen herrmannsfeldt
>>> wrote:
>>>
>>>> When you did fill up the buffer, the system crashed. I don't know
enough
>>>> about TOPS-10 internals to know why that might happen, though. The story
>>>> might have been that no-one could type that fast such that they didn't
>>>> need to test for it.
>>> It was easy enough to create that situation: just short the transmit and
>>> receive lines together. :)
>>
>> The OS would shut down the line in that case as an "open" TTY line.
>>
>> I believe Glen is talking about the bug in 4S72 or earlier. The result
>> was the creation of the IRMA bit. If you're nice and plead a lot,
>> /RCC might read this and tell the story again, putting into machine
>> readable form for the nth generation to rediscover and implement ;-).
>>
>> It was a firefight.
>
> Man, is this garbled.
<grin> Of course.
>
> There was a bug, which I called "the Irma bug", because it seemed to
> reliably hit this poor woman in Salt Lake City.
>
> It caused a single TTY line to hang. Not a system crash. It happened
> with normal human-speed typing. Not full-speed input.
>
> The fix was to discover (the hard part) and fix the code with the
> race condition. There was no "Irma bit" added, or involved at all.
Oh, that's interesting. IIRC, I heard the story in the 5.06 monitor
course given by Nancy <mumble> Mcnulty?
>
> The bug was that the TTY code assumed DEVIOS(DEVDAT) was being
> handled safely by existing monitor routines. But SETIOD (not in
> the TTY code) was not interrupt safe, so it was clobbering a bit
> that the TTY code used (safely) at both interrupt and non-interrupt
> levels.
Thanks.
/BAH
Rich Alderson
> Rich Alderson wrote:
>> Because the system does not have an NIA20, and Tops-10 does not support
>> TCP/IP printing, and we're not going to run DECnet for other reasons?
> Why aren't you using ANF-10?
Because we don't have another -10 to connect to?
>> It really is easier to recreate a single board for the front end than to
>> find a rare multi-board piece of hardware, then write the operating system
>> code to use that hardware, then write the print spooler code to talk to the
>> operating system about using a printer at the other end of the network.
> You can put the printer on any -11 or -8, load it with the appropriate
> ANF-10 driver and make a TWINKY node. ;-)
We don't have printer interfaces for any -11 or -8 at the moment. That's
why we're building one.
The boards are back from the board house, and are being stuffed. Me, I'm on
vacation 1200 miles east of the museum.
--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
jmfbahciv
> jmfbahciv <See....@aol.com> writes:
>
>> Rich Alderson wrote:
>
>>> Because the system does not have an NIA20, and Tops-10 does not support
>>> TCP/IP printing, and we're not going to run DECnet for other reasons?
>
>> Why aren't you using ANF-10?
>
> Because we don't have another -10 to connect to?
You don't need another -10. :-)
>
>>> It really is easier to recreate a single board for the front end than to
>>> find a rare multi-board piece of hardware, then write the operating system
>>> code to use that hardware, then write the print spooler code to talk to
the
>>> operating system about using a printer at the other end of the network.
>
>> You can put the printer on any -11 or -8, load it with the appropriate
>> ANF-10 driver and make a TWINKY node. ;-)
>
> We don't have printer interfaces for any -11 or -8 at the moment. That's
> why we're building one.
Ah.
>
> The boards are back from the board house, and are being stuffed. Me, I'm on
> vacation 1200 miles east of the museum.
>
<grin> another few miles and you could visit.
/BAH
Johnny Billquist
> Johnny Billquist wrote:
>> On 2010-12-21 15:40, jmfbahciv wrote:
>>> Johnny Billquist wrote:
>>>> Ethernet is just one medium over which DECnet communication can take
> place.
>>>
>>> IMO, it was the only working medium for DECNET. Everything else sucked.
>>
>> You have a sather limited view on what "worked" means, in that case.
>
> I had to wrestle with the MCB too often. My perspective was from the
> PDP-10 side of DECnet. The only DECnet which worked well as comm and
> networking on the PDP-10 was the ethernet implementation.
> RSTS was a PITA, too. IIRC, I had to do all kinds of magic incantatations
> just to get a network connection working...I"ll get this wrong...I think
> the comm gear was a KMC-11. On the days when my magic incantations
> didn't work, I'd have to wait for RDH to come in (his shift was 15:00 or 16:00
> to midnight or so) and have him look at the KMC. That's all it needed to
> for its lights to begin flashing. I kid you not.
Well, DECnet-10 would then perhaps have been a more proper designation
than just "DECnet"? :-)
>>>> I think that 1979-1980 would probably be DECnet phase III, by the way.
>>>> But I might be wrong.
>>>
>>> It's possible, but I don't remember doing Phase III certification on RSTS/E
>>> in 1981 and 1983. When TOPS-10 and TOPS-20 shipped DECNET, we had to
>>> pass the internal certification tests. That meant running scripts on all
>>> OSes DEC supported against the -10 and -20 software. RSTS/E was one
>>> of the OSes I had to do.
>>
>> I'm curious if they somehow managed to still do that in 1999, when the
>> latest (last?) version of DECnet-RSX was released. There were
>> compatibility notes in the release notes for VMS, RSTS/E, RT-11 and
>> TOPS-20 (nothing on TOPS-10 though). It could be that they just kept the
>> same notes that had been around for the last ten years or so... Although
>> I seem to remember some Y2K comments in there...
>
> If DEC hadn't changed the ship criteria, any DECnet release would have
> had to be certified. I would imagine that the same compatibility issues
> would exist since the asspects would not have been fixed.
The twist here (of course there is a twist) is that by 1999, it was not
"DEC" anymore. Or "Digital". DEC sold off the PDP-11 software to Mentec
in 1994. So the 1999 release, including the release notes, comes from
Mentec Inc... Now, did they test against some TOPS-20 system or not? And
if they did, where did they find one to do that testing?
jmfbahciv
> On 2010-12-22 15:54, jmfbahciv wrote:
>> Johnny Billquist wrote:
>>> On 2010-12-21 15:40, jmfbahciv wrote:
>>>> Johnny Billquist wrote:
>>>>> Ethernet is just one medium over which DECnet communication can take
>> place.
>>>>
>>>> IMO, it was the only working medium for DECNET. Everything else sucked.
>>>
>>> You have a sather limited view on what "worked" means, in that case.
>>
>> I had to wrestle with the MCB too often. My perspective was from the
>> PDP-10 side of DECnet. The only DECnet which worked well as comm and
>> networking on the PDP-10 was the ethernet implementation.
>> RSTS was a PITA, too. IIRC, I had to do all kinds of magic incantatations
>> just to get a network connection working...I"ll get this wrong...I think
>> the comm gear was a KMC-11. On the days when my magic incantations
>> didn't work, I'd have to wait for RDH to come in (his shift was 15:00 or
16:00
>> to midnight or so) and have him look at the KMC. That's all it needed to
>> for its lights to begin flashing. I kid you not.
>
> Well, DECnet-10 would then perhaps have been a more proper designation
> than just "DECnet"? :-)
I don't think we designated OS names to the product. All of the
implementations came from the same spec. I also certified TOPS-20's.
>
>>>>> I think that 1979-1980 would probably be DECnet phase III, by the way.
>>>>> But I might be wrong.
>>>>
>>>> It's possible, but I don't remember doing Phase III certification on
RSTS/E
>>>> in 1981 and 1983. When TOPS-10 and TOPS-20 shipped DECNET, we had to
>>>> pass the internal certification tests. That meant running scripts on all
>>>> OSes DEC supported against the -10 and -20 software. RSTS/E was one
>>>> of the OSes I had to do.
>>>
>>> I'm curious if they somehow managed to still do that in 1999, when the
>>> latest (last?) version of DECnet-RSX was released. There were
>>> compatibility notes in the release notes for VMS, RSTS/E, RT-11 and
>>> TOPS-20 (nothing on TOPS-10 though). It could be that they just kept the
>>> same notes that had been around for the last ten years or so... Although
>>> I seem to remember some Y2K comments in there...
>>
>> If DEC hadn't changed the ship criteria, any DECnet release would have
>> had to be certified. I would imagine that the same compatibility issues
>> would exist since the asspects would not have been fixed.
>
> The twist here (of course there is a twist) is that by 1999, it was not
> "DEC" anymore. Or "Digital". DEC sold off the PDP-11 software to Mentec
> in 1994. So the 1999 release, including the release notes, comes from
> Mentec Inc... Now, did they test against some TOPS-20 system or not? And
> if they did, where did they find one to do that testing?
DECNET was "separated" when Jim was still alive so that would have been
around 1993 or so. IIRC, they had to build a wall in the buiilding
so that people couldn't walk from "DECNET" to Digital floor plan.
ISTM that DECNET might not have been part of the IP sold to Mentec.
But I don't know; it's an educated guess.
/BAH
Lawrence D'Oliveiro
> Lawrence D'Oliveiro wrote:
>
>> In message <ier1u6$b3l$3...@news.eternal-september.org>, glen herrmannsfeldt
>> wrote:
>>
>>> When you did fill up the buffer, the system crashed. I don't know
>>> enough about TOPS-10 internals to know why that might happen, though.
>>> The story might have been that no-one could type that fast such that
>>> they didn't need to test for it.
>>
>> It was easy enough to create that situation: just short the transmit and
>> receive lines together. :)
>
> The OS would shut down the line in that case as an "open" TTY line.
I don’t think RSTS/E, which we were using at the time, was that smart. :)
Lawrence D'Oliveiro
> Bob Koehler wrote:
>
>> COBOL was the orginal cause of gaster printers.
>>
> Gaster?
Could be short for “Drosophila melanogaster”, much beloved of geneticists
with a fondness for creating frankenfruitflies. Though printing them—who
knows what people are getting up to with their RepRaps these days...
Sorry, wrong geeks...
jmfbahciv
All systems had to deal with open lines. It was a common hardware problem
with any terminal concentraters. On TOPS-10 at boot time, INITIA, which is
a CUSP, was run on all TTY lines to ID the open lines and shut them down.
The rest of the lines got a banner shoved down the line to announce that
the -10 was available.
/BAH
Lawrence D'Oliveiro
> It really is easier to recreate a single board for the front end than to
> find a rare multi-board piece of hardware, then write the operating system
> code to use that hardware, then write the print spooler code to talk to
> the operating system about using a printer at the other end of the
> network.
Some people are no fun at all.
Johnny Billquist
> Lawrence D'Oliveiro wrote:
All systems can suffer from this. Not all systems dealt with it
gracefully. RSTS/E did not, as far as I remember. RSX don't either. You
have to manually set lines that act up or are broken to a disabled
state. In RSX the system will not directly crash, but you can run out of
pool (kernel dynamic memory) pretty fast, which cause the system stop
working right.
Besides, how do you know that characters looped right back really is a
"broken" line to be disabled?
It is one thing to perheps try and detect this at boot time, but it's
very difficult to do during normal operation.
Johnny Billquist
> Johnny Billquist wrote:
>> On 2010-12-22 15:54, jmfbahciv wrote:
>>> Johnny Billquist wrote:
>>>> On 2010-12-21 15:40, jmfbahciv wrote:
>>>>> Johnny Billquist wrote:
>>>>>> Ethernet is just one medium over which DECnet communication can take
>>> place.
>>>>>
>>>>> IMO, it was the only working medium for DECNET. Everything else sucked.
>>>>
>>>> You have a sather limited view on what "worked" means, in that case.
>>>
>>> I had to wrestle with the MCB too often. My perspective was from the
>>> PDP-10 side of DECnet. The only DECnet which worked well as comm and
>>> networking on the PDP-10 was the ethernet implementation.
>>> RSTS was a PITA, too. IIRC, I had to do all kinds of magic incantatations
>>> just to get a network connection working...I"ll get this wrong...I think
>>> the comm gear was a KMC-11. On the days when my magic incantations
>>> didn't work, I'd have to wait for RDH to come in (his shift was 15:00 or
> 16:00
>>> to midnight or so) and have him look at the KMC. That's all it needed to
>>> for its lights to begin flashing. I kid you not.
>>
>> Well, DECnet-10 would then perhaps have been a more proper designation
>> than just "DECnet"? :-)
>
> I don't think we designated OS names to the product. All of the
> implementations came from the same spec. I also certified TOPS-20's.
Eh... The spec is one thing. An implementation is something else. And it
was implementations that DEC sold as products...
And DECnet-10 is definitely a different implementation and product than
DECnet-RSX, DECnet/E or DECnet for VMS.
Eh? What DECnet are you talking about now? The various DECnet
implementations for the PDP-11 line were always separate products.
They were sold separately, both from each other, and from the OS. The
testing against other DECnet implementations must obviously have been
done at some point, since the release notes and manuals goes through the
different DECnet implementations, mentioning incompatibilities and
restrictions when communicating with other systems.
Since the DECnet-11M-PLUS V4.6 release (done in 1999) also list some new
issues and points in relation to (among others) DECnet-20, I is a bit
curious if they actually tested against some TOPS-20 machine, and if so,
where they found one to test against at that point.
> But I don't know; it's an educated guess.
Indeed. A guess is all it was. And wrong.
DECnet for both RSX and RSTS/E were among the things DEC sold to Mentec.
Rich Alderson
Yeah, that's me, boring old stick in the mud, nothing much happening here.
Just have to get a group of HP 3000s, a DG MV 15000, an HP 1000, a PDP-12,
a 7094 with two 1401s, and assorted other systems, up and running. Plenty
of time to write new software for all of them if hardware can't be had one
way or another. Oh, and new stuff arriving all the time. Can't forget that...
;->
jmfbahciv
I don't remember the specifics. You can read (I would guess) INITIA.MAC
to find out.
>
> It is one thing to perheps try and detect this at boot time, but it's
> very difficult to do during normal operation.
ANF-10 could figure it out.
/BAH
jmfbahciv
And, before they were signed off to ship, all had to pass certification
against all other field image implementations of DECnet. This means that
the implementations had to be so similar that they could talk the same
protocols with the same data in the same fields.
I'm talking about the product called DECnet which ran on all the OSes
being separated from the company called DEC.
> The various DECnet
> implementations for the PDP-11 line were always separate products.
Yes, but were under the same "roof" until the deal with Compaq was going
to be done.
> They were sold separately, both from each other, and from the OS. The
> testing against other DECnet implementations must obviously have been
> done at some point, since the release notes and manuals goes through the
> different DECnet implementations, mentioning incompatibilities and
> restrictions when communicating with other systems.
> Since the DECnet-11M-PLUS V4.6 release (done in 1999) also list some new
> issues and points in relation to (among others) DECnet-20, I is a bit
> curious if they actually tested against some TOPS-20 machine, and if so,
> where they found one to test against at that point.
In Marlboro.
>
>> But I don't know; it's an educated guess.
>
> Indeed. A guess is all it was. And wrong.
> DECnet for both RSX and RSTS/E were among the things DEC sold to Mentec.
And that happened before Compaq bought out DEC.
/BAH
Johnny Billquist
> Johnny Billquist wrote:
>> very difficult to do during normal operation.
>
> ANF-10 could figure it out.
ANF-10 is a network, not a terminal interface. Big difference.
Johnny Billquist
Yes. And that is what was/is a little curious about. How did they do
that in 1999?
But your comments was that DECnet only worked over ethernet, to which I
objected, since DECnet-RSX as well as DECnet VMS worked very well over
DDCMP lines, DMV-11, and a bunch of other physical connections as well.
Your comment about DECnet only working over ethernet might very well be
true for DECnet-10, but it is definitely not true for DECnet in general,
so stop using the term "DECnet" when you talk about a specific
implementation.
DECnet as a concept itself, was specified for a number of different
physical connections. And it worked just fine, thank you. Like I said, I
know of atleast one site who only moved away from DMV-11 (if I remember
the designation right) a year or so ago, but they had used that for
about 20 years. Working just fine.
There was no product called "DECnet". You had DECnet-RSX, DECnet/e,
DECnet VMS, DECnet-20 (and I assume DECnet-10), but no "DECnet". DECnet
was/is a specification, and it was/is free for anyone to read.
The products were the specific implementations done by DEC for the
various platforms.
So, "DECnet" itself is free, and have always been. The DECnet products
that were associated with the OSes DEC sold to Mentec were sold along
with all the other software to Mentec at the same time.
>> The various DECnet
>> implementations for the PDP-11 line were always separate products.
>
> Yes, but were under the same "roof" until the deal with Compaq was going
> to be done.
No.
DECnet/e and DECnet-RSX were sold along with the rest of RSTS/E, RSX and
RT-11 to Mentec in 1993. The Compaq deal was in 1999.
>> They were sold separately, both from each other, and from the OS. The
>> testing against other DECnet implementations must obviously have been
>> done at some point, since the release notes and manuals goes through the
>> different DECnet implementations, mentioning incompatibilities and
>> restrictions when communicating with other systems.
>> Since the DECnet-11M-PLUS V4.6 release (done in 1999) also list some new
>> issues and points in relation to (among others) DECnet-20, I is a bit
>> curious if they actually tested against some TOPS-20 machine, and if so,
>> where they found one to test against at that point.
>
>
> In Marlboro.
No.
All PDP-11 software development moved to Colorado Springs, CO already
around 1990. In 1993 (or was it finalized in 1994?) all of it was sold
to Mentec, who continued to do the development in Colorado Springs.
>>> But I don't know; it's an educated guess.
>>
>> Indeed. A guess is all it was. And wrong.
>> DECnet for both RSX and RSTS/E were among the things DEC sold to Mentec.
>
>
> And that happened before Compaq bought out DEC.
Yes.
jmfbahciv
Sigh! I didn't say that or you misunderstood what I meant. Let me
try to restate what I wrote: The performance of DECnet sucked on everything
but the ethernet.
>to which I
> objected, since DECnet-RSX as well as DECnet VMS worked very well over
> DDCMP lines, DMV-11, and a bunch of other physical connections as well.
No, it didn't work _very well_. Performance sucked rocks.
>
> Your comment about DECnet only working over ethernet might very well be
> true for DECnet-10, but it is definitely not true for DECnet in general,
> so stop using the term "DECnet" when you talk about a specific
> implementation.
ANF-10 worked very well on TOPS-10.
And, when I type DECnet, I mean all the DECnet implementations.
>
> So, "DECnet" itself is free, and have always been. The DECnet products
> that were associated with the OSes DEC sold to Mentec were sold along
> with all the other software to Mentec at the same time.
>
>>> The various DECnet
>>> implementations for the PDP-11 line were always separate products.
>>
>> Yes, but were under the same "roof" until the deal with Compaq was going
>> to be done.
>
> No.
> DECnet/e and DECnet-RSX were sold along with the rest of RSTS/E, RSX and
> RT-11 to Mentec in 1993. The Compaq deal was in 1999.
>
>>> They were sold separately, both from each other, and from the OS. The
>>> testing against other DECnet implementations must obviously have been
>>> done at some point, since the release notes and manuals goes through the
>>> different DECnet implementations, mentioning incompatibilities and
>>> restrictions when communicating with other systems.
>>> Since the DECnet-11M-PLUS V4.6 release (done in 1999) also list some new
>>> issues and points in relation to (among others) DECnet-20, I is a bit
>>> curious if they actually tested against some TOPS-20 machine, and if so,
>>> where they found one to test against at that point.
>>
>>
>> In Marlboro.
>
> No.
The PDP-10 which could have been used for that certification was located in
Marlboro.
> All PDP-11 software development moved to Colorado Springs, CO already
> around 1990. In 1993 (or was it finalized in 1994?) all of it was sold
> to Mentec, who continued to do the development in Colorado Springs.
Mentec may have not used the same ship criteria. which would explain
why the old comments were merely cut/pasted in their notes.
>
>>>> But I don't know; it's an educated guess.
>>>
>>> Indeed. A guess is all it was. And wrong.
>>> DECnet for both RSX and RSTS/E were among the things DEC sold to Mentec.
>>
>>
>> And that happened before Compaq bought out DEC.
>
> Yes.
/BAH
jmfbahciv
> On 2011-01-05 15:42, jmfbahciv wrote:
>> Johnny Billquist wrote:
>>> It is one thing to perheps try and detect this at boot time, but it's
>>> very difficult to do during normal operation.
>>
>> ANF-10 could figure it out.
>
> ANF-10 is a network, not a terminal interface. Big difference.
I don't think you know what you're talking about. Look at all
the code found on the second save set of the TOPS-10 Monitor
Distribution tape.
/BAH
Bob Koehler
>
> But your comments was that DECnet only worked over ethernet, to which I
> DDCMP lines, DMV-11, and a bunch of other physical connections as well.
So did DECnet-20, not surpizing since it used a PDP-11 front end.
We had VAXen, PDP-11, and DECSYSTEM-20 all interconnected via DECnet
Phase 2 and/or 3, years before we even heard of Ethernet.
Since DECnet-20 ran prior to ethnet, I'd be surprized if DECnet-10
didn't.
In fact, I recall a TOPS-10 update shipping years after TOPS-10 was
supposed to be frozen, just so DEC could add Ethernet support for
DECnet-10 for a major customer. I don't think DEC had to add the
rest of DECnet at that time.
Bob Koehler
>
> Sigh! I didn't say that or you misunderstood what I meant. Let me
> try to restate what I wrote: The performance of DECnet sucked on everything
> but the ethernet.
Well, Ethernet was faster than the 9600 baud lines we ran most of
our DDCMP connections over. But between some of our VAXen, long
before Ethenet, we had a version of the UNIBUS DDCMP board (DMC-11?),
and it was much faster than 9600 baud.
So what speeds were available on supported TCP/IP NICs prior to
Ethernet?
Bob Koehler
>
> Well, Ethernet was faster than the 9600 baud lines we ran most of
> our DDCMP connections over. But between some of our VAXen, long
> before Ethenet, we had a version of the UNIBUS DDCMP board (DMC-11?),
> and it was much faster than 9600 baud.
That should read "we had a coax version".
jmfbahciv
Working well didn't have to do with speeds available. DECnet Phase II
and Phase III implementations on the PDP-10 (that's both TOPS-10 and
TOPS-20) used the puir, puir PDP-11 which was named the MCB. Not
only did it have to service users' traffic but it also had to do
all the routing and other tasks required by the DECnet specs for
Phases II and III. It sucked for anybody who was used to using
ANF-10. -20 users wouldn't mind (much) because all they had before
DECnet was the -20F tty lines.
/BAH
Bill Pechter
On 2011-01-06, Johnny Billquist <b...@softjar.se> wrote:
>
> DECnet as a concept itself, was specified for a number of different
> physical connections. And it worked just fine, thank you. Like I said, I
> know of atleast one site who only moved away from DMV-11 (if I remember
> the designation right) a year or so ago, but they had used that for
> about 20 years. Working just fine.
>
> Johnny
Couldn't kill it if the boards didn't get hit by lightning. (A common
failure in the field in the NJ shore area).
Secure. Point to point, no need for VPN with leased lines.
> There was no product called "DECnet". You had DECnet-RSX, DECnet/e,
> DECnet VMS, DECnet-20 (and I assume DECnet-10), but no "DECnet". DECnet
> was/is a specification, and it was/is free for anyone to read.
> The products were the specific implementations done by DEC for the
> various platforms.
>
> So, "DECnet" itself is free, and have always been. The DECnet products
> that were associated with the OSes DEC sold to Mentec were sold along
> with all the other software to Mentec at the same time.
And DECnet was available from a number of vendors of Unix systems.
Masscomp had it. I believe it was also available on other platforms
that were common with VAX sites. I bet Sun also had it.
All the non-DEC DECnet implemetations I've seen were ethernet only.
Bill
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org
Bob Koehler
>
> And DECnet was available from a number of vendors of Unix systems.
> Masscomp had it. I believe it was also available on other platforms
> that were common with VAX sites. I bet Sun also had it.
Sun was one of the other vendors that had their own DECnet
implementation. KiResearch implemented DECnet on just about any
platform you could buy. CDC provided DECnet on a few others. We
had a thrid part DECnet on our IBM mainframes, don't recall the
vendor's name (wasn't one of the above). Linux folks have
implemented DECnet.
DECnet is an open spec (DNA), anyone can write to it. Many have.
LAT, MOP, and VMScluster are not DECnet and not open, but lots
of folks reverse engineered LAT and MOP anyhow, and lots of DECnet
vendors included LAT and MOP in their "DECnet" products.
jmfbahciv
That was Phase IV of the DECnet spec. I never understood why the
OSes couldn't skip a phase or two.
/BAH
Johnny Billquist
Your original quote is still in this thread. Just look above.
"IMO, it was the only working medium for DECNET. Everything else
sucked." is what you said.
I find that totally unfounded.
You then said (also in the quotes above):
"I had to wrestle with the MCB too often. My perspective was from the
PDP-10 side of DECnet. The only DECnet which worked well as comm and
networking on the PDP-10 was the ethernet implementation."
Which is perfectly fine, but then we are talking about a specific
implementation, and not DECnet in general.
Now, could we stop this silly discussion. DECnet worked fine on various
transports. The fact that DECnet-10 didn't is irrelevant to the
discussion of DECnet as a whole. You cannot make general claims about
DECnet based only on your experience of a specific implementation.
>> to which I
>> objected, since DECnet-RSX as well as DECnet VMS worked very well over
>> DDCMP lines, DMV-11, and a bunch of other physical connections as well.
>
> No, it didn't work _very well_. Performance sucked rocks.
No, it did not. It worked, and still work just fine, and performance is
just fine. As long as you don't expect miracles. If you run it over a
9600 bps asynch serial line you will not have the same speed as over a
10 Mbit/s ethernet (obviously).
>> Your comment about DECnet only working over ethernet might very well be
>> true for DECnet-10, but it is definitely not true for DECnet in general,
>> so stop using the term "DECnet" when you talk about a specific
>> implementation.
>
>
> ANF-10 worked very well on TOPS-10.
Yes. And...?
This makes no sense. You say that DECnet was "separated" in 1993. What
DECnet? DECnet as a product have been "separate" from the OS for the
PDP-11 line since inception, in the late 70s.
DECnet for RSTS/E and RSX was sold to Mentec in 1993, but not DECnet for
VMS or TOPS-20. So what separation are you talking about?
DECnet was, and still is, a standard part which is always shipped as a
part of a VMS distribution. So it's still in house for that product.
(Although inhouse is now India, I would suspect.)
So, DECnet was not even treated the same way for different platforms.
Your comment about "separation" seems totally confused.
>>>> They were sold separately, both from each other, and from the OS. The
>>>> testing against other DECnet implementations must obviously have been
>>>> done at some point, since the release notes and manuals goes through the
>>>> different DECnet implementations, mentioning incompatibilities and
>>>> restrictions when communicating with other systems.
>>>> Since the DECnet-11M-PLUS V4.6 release (done in 1999) also list some new
>>>> issues and points in relation to (among others) DECnet-20, I is a bit
>>>> curious if they actually tested against some TOPS-20 machine, and if so,
>>>> where they found one to test against at that point.
>>>
>>>
>>> In Marlboro.
>>
>> No.
>
>
> The PDP-10 which could have been used for that certification was located in
> Marlboro.
How can you tell? Are you saying that in 1999 there was only one,
canonical, PDP-10 on which all certifications were done? Do we know if
that machine was still around?
Anyway, the RSX development was done in Colorado Springs. I know that
much for a fact.
Did DEC/Compaq still have some DECnet certification process still in
place, with different machines to test against? Anyone have any facts here?
>> All PDP-11 software development moved to Colorado Springs, CO already
>> around 1990. In 1993 (or was it finalized in 1994?) all of it was sold
>> to Mentec, who continued to do the development in Colorado Springs.
>
> Mentec may have not used the same ship criteria. which would explain
> why the old comments were merely cut/pasted in their notes.
It was not just a cut/paste, which I have pointed out. There were some
new Y2K compatibility issues in the release notes, which had not been
there in the previous release. RSX got some additional Y2K fixes itself
in the 4.6 release.
Johnny Billquist
Those ran up to 1 Mbit/s unless I remember wrong. Pretty nice thing, and
very fine to run DECnet over.
Johnny Billquist
And you know what? DECnet over a serial lines worked, and still work
just fine, using two PDP-11s. Whatever suckage was exposed on the
TOPS-10 DECnet implementation has little bearing on wether it was usable
on other platforms. And by extension, have little bearing on wether it
was working well in the general sense.
Johnny Billquist
> ["Followup-To:" header set to comp.sys.dec.]
> On 2011-01-06, Johnny Billquist<b...@softjar.se> wrote:
>>
>> DECnet as a concept itself, was specified for a number of different
>> physical connections. And it worked just fine, thank you. Like I said, I
>> know of atleast one site who only moved away from DMV-11 (if I remember
>> the designation right) a year or so ago, but they had used that for
>> about 20 years. Working just fine.
>>
> <snip>...
>> Johnny
>
> Couldn't kill it if the boards didn't get hit by lightning. (A common
> failure in the field in the NJ shore area).
Funny you should say that. We had a board break down not long ago. :-)
> Secure. Point to point, no need for VPN with leased lines.
>
>> There was no product called "DECnet". You had DECnet-RSX, DECnet/e,
>> DECnet VMS, DECnet-20 (and I assume DECnet-10), but no "DECnet". DECnet
>> was/is a specification, and it was/is free for anyone to read.
>> The products were the specific implementations done by DEC for the
>> various platforms.
>>
>> So, "DECnet" itself is free, and have always been. The DECnet products
>> that were associated with the OSes DEC sold to Mentec were sold along
>> with all the other software to Mentec at the same time.
>
> And DECnet was available from a number of vendors of Unix systems.
> Masscomp had it. I believe it was also available on other platforms
> that were common with VAX sites. I bet Sun also had it.
Yes, I actually know that Sun had an implementation at one point. So did
Symbolics (for their Lisp machines).
Cisco still support DECnet as well.
I think that SGI also had an implementation, but I'm not 100% sure there.
> All the non-DEC DECnet implemetations I've seen were ethernet only.
Me too.
Johnny Billquist
Yes. Ethernet didn't exist before phase IV.
What do you mean by "skip a phase or two"?
Johnny Billquist
> Johnny Billquist wrote:
>> On 2011-01-05 15:42, jmfbahciv wrote:
>>> Johnny Billquist wrote:
>>>> It is one thing to perheps try and detect this at boot time, but it's
>>>> very difficult to do during normal operation.
>>>
>>> ANF-10 could figure it out.
>>
>> ANF-10 is a network, not a terminal interface. Big difference.
>
> I don't think you know what you're talking about. Look at all
> the code found on the second save set of the TOPS-10 Monitor
> Distribution tape.
I've used ANF-10, thank you.
Bob Koehler
> Working well didn't have to do with speeds available. DECnet Phase II
> and Phase III implementations on the PDP-10 (that's both TOPS-10 and
> TOPS-20) used the puir, puir PDP-11 which was named the MCB. Not
> only did it have to service users' traffic but it also had to do
> all the routing and other tasks required by the DECnet specs for
> Phases II and III. It sucked for anybody who was used to using
> ANF-10. -20 users wouldn't mind (much) because all they had before
> DECnet was the -20F tty lines.
I don't know about AFN. But DECnet on PDP-11 was notoriously
faster than DECnet on VAXen, even for significanlty faster VAX CPUs.
DECnet on -10 and -20 was able to take advantage of the performance
of the PDP-11, even though ours were 11/34A, hardly the fastest of
the -11.
Johnny Billquist
He... Not exactly true when you ran a DEC-2060 with a NIA-20... All
DECnet traffic went straight to the KL-10, without passing by the
PDP-11. And network traffic could quickly bring the machine to its knees...
Bob Koehler
>
> He... Not exactly true when you ran a DEC-2060 with a NIA-20... All
> DECnet traffic went straight to the KL-10, without passing by the
> PDP-11. And network traffic could quickly bring the machine to its knees...
Our 2060 had a PDP-11/34A front end for DECnet (PDP-11/60 for the
console). Worked great.
Our 2050 also had an 11/34A for DECnet, but an 11/40 fo the console.
So what is the heart of an NIA-20?
Rich Alderson
Three boards in a black box bolted into the I/O bay and cabled up to replace
RH20s 560 and 564; it's addressed as 564.
Two of the boards are common between the NIA-20 and the CI-20, which similarly
replaces 570 and 574.
Johnny Billquist
No idea exactly what was inside the black box. But Rich answered that
one already.
However, if you wanted Ethernet on your DEC-20, I think the NIA-20 was
the only way. The PDP-11 FEs couldn't handle ethernet for you, could they?
Bob Koehler
>
> However, if you wanted Ethernet on your DEC-20, I think the NIA-20 was
> the only way. The PDP-11 FEs couldn't handle ethernet for you, could they?
>
The PDP-11 front ends that I saw were all UNIBUS modules. At the
time DEC brought out Ethernet support, most VAXen were still UNIBUS
capable, or UNIBUS based. I'm quite sure DEC sold Ethernet for
PDP-11 and supported DECnet on it, so why not use that for PDP-10
front ends?
fishtoprecords
> However, if you wanted Ethernet on your DEC-20, I think the NIA-20 was
> the only way. The PDP-11 FEs couldn't handle ethernet for you, could they?
Not quite right. We ran DECnet for years without an NIA-20.
Yes, the FE 11 could not do it. or perhaps DEC would not agree to let
it try. So for DECnet phase 2, you had to have yet another PDP-11
connected to the KL. It ran the DECnet code. If I remember correctly,
it was a lobotomized version of the then current RSX version of
DECnet, with no routing, and a very limited number of connection
options.
DECnet Phase 3 was so late for the Tops-20 line that we didn't care
what it did (Post-Jupiter cancellation, etc.)
Rich Alderson
> However, if you wanted Ethernet on your DEC-20, I think the NIA-20 was
> the only way. The PDP-11 FEs couldn't handle ethernet for you, could they?
No, there was the Stanford (later 'cisco Systems) MEIS[1] (Massbus-Ethernet
Interface Subsystem), which pre-dated the NIA-20 by several years and was a
much better device. (For example, the MEIS had internal loopback circuitry
which allowed it to talk to itself; the NIA-20 could not do this.)
The MEIS pre-dates the DIX 10Mbit Ethernet standard on which 802.3 was based;
the original campus network at Stanford was thick coax, running at 3Mbit/sec.
The 10Mbit/sec MEIS came out shortly after I got to Stanford, so I got to
work with both.[2]
Despite the name, the XNI-1 Ethernet interface card in the XKL Toad-1 was based
on the MEIS rather than the NIA-20.[3]
[1] Rhymes with "maze" and "maize".
[2] We ran PUP and TCP/IP on both interfaces. DECnet was not wanted by the
implementors, but could have run there, too.
[3] Not surprising, when you know the history. ;-)
Johnny Billquist
I agree that it would be technically possible, but I don't think DEC
implemented that.
A reason not to would perhaps be that the bandwidth of the DTE-10 would
have been a problem?
And yes, DECnet over ethernet on a PDP-11 works just fine, and is
supported. (There are actually two ethernet controllers for Unibus, the
DEUNA and the DELUA.)
Johnny Billquist
> On Jan 12, 4:06 am, Johnny Billquist<b...@softjar.se> wrote:
>> However, if you wanted Ethernet on your DEC-20, I think the NIA-20 was
>> the only way. The PDP-11 FEs couldn't handle ethernet for you, could they?
>
> Not quite right. We ran DECnet for years without an NIA-20.
Yes. But now I was talking ethernet, not DECnet.
> Yes, the FE 11 could not do it. or perhaps DEC would not agree to let
> it try. So for DECnet phase 2, you had to have yet another PDP-11
> connected to the KL. It ran the DECnet code. If I remember correctly,
> it was a lobotomized version of the then current RSX version of
> DECnet, with no routing, and a very limited number of connection
> options.
>
> DECnet Phase 3 was so late for the Tops-20 line that we didn't care
> what it did (Post-Jupiter cancellation, etc.)
Ethernet didn't arrive until DECnet phase IV.
And as far as I know, if you ran a DEC-20 with DECnet, and wanted to use
ethernet, the NIA-20 was your only option.
Bob Koehler
>
> DECnet Phase 3 was so late for the Tops-20 line that we didn't care
> what it did (Post-Jupiter cancellation, etc.)
We had a hub-and-spoke layout (over synchronous DDCMP lines) with
a DECSYSTEM-20 at the center, and everything other than the DECSYSTEM-20
running Phase 3. This met all our operational needs, but those of us
who knew did a lot of poor man's routining on our VAXen to get things
done that were convenient, but not operationally required.
It was such an improvement when DECnet-20 got Phase 3 and all our
systems could simply talk to each other.
George Cornelius
> In article <slrniiejpa....@tucker.pechter.dyndns.org>, Bill Pechter <pec...@tucker.pechter.dyndns.org> writes:
>>
>> And DECnet was available from a number of vendors of Unix systems.
>> Masscomp had it. I believe it was also available on other platforms
>> that were common with VAX sites. I bet Sun also had it.
>
> Sun was one of the other vendors that had their own DECnet
> implementation. KiResearch implemented DECnet on just about any
> platform you could buy. CDC provided DECnet on a few others. We
> had a thrid part DECnet on our IBM mainframes, don't recall the
> vendor's name (wasn't one of the above). Linux folks have
> implemented DECnet.
> implemented DECnet.
Thursby Software Systems was one of the players. If you google
their name, with the word DECnet appended, you find that they
claim they got their start providing protocol stacks for Unix and
for Macs, and the two examples of stacks provided are LAT and DECnet.
George Cornelius
George Cornelius
> In article <igjqu8$l10$2...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>>
>> However, if you wanted Ethernet on your DEC-20, I think the NIA-20 was
>> the only way. The PDP-11 FEs couldn't handle ethernet for you, could they?
>>
>
> time DEC brought out Ethernet support, most VAXen were still UNIBUS
> capable, or UNIBUS based. I'm quite sure DEC sold Ethernet for
> PDP-11 and supported DECnet on it, so why not use that for PDP-10
> front ends?
The standard Unibus and Qbus boards - DEUNA, DELUA, DEQNA(ugh), DELQA -
were supported. Don't believe there was ever a Massbus variant, though.
George Cornelius
Johnny Billquist
Massbus variant of ethernet?
No, I had never heard of it before Rich mentioned one.
As far as I know, noone ever did that to the PDP-11 Massbus.