RIP Compuserve Classic

55 views
Skip to first unread message

Sam Weiner

unread,
Jun 30, 2009, 8:05:20 PM6/30/09
to
I'm amazed no one has mentioned it but
AOL is shutting the last remnants of
the TOPS-10 based Compuserve service
today. Most services had migrated to
the web over the last few years but a
few had remained on TOPS-10 including
billing and the personal file area
which included getting to a command
prompt.

It had a good run.

Sam

Mark Crispin

unread,
Jun 30, 2009, 9:47:58 PM6/30/09
to
On Wed, 1 Jul 2009, Sam Weiner posted:

> I'm amazed no one has mentioned it but
> AOL is shutting the last remnants of
> the TOPS-10 based Compuserve service
> today.

A sad day indeed. My main contact with CompuServe was when it was a
PDP-10 timesharing service bureau (remember those?) in the mid 1970s. I
will never forget its "funky" variant of TOPS-10.

-- 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.

Paul Rubin

unread,
Jun 30, 2009, 10:11:21 PM6/30/09
to

Wow. Were they actually running on real DEC PDP-10 hardware?

Mark Crispin

unread,
Jun 30, 2009, 11:18:30 PM6/30/09
to
On Tue, 30 Jun 2009, Paul Rubin posted:

> Wow. Were they actually running on real DEC PDP-10 hardware?

They were in the 1980s. I've been to their Columbus facility. I wrote
Ampex's memory diagnostic for the KL10, and it was tested at CompuServe.
It's been nearly 30 years, and I've forgotten most of the details.

By the 1990s most of their PDP-10s were probably Systems Concepts
machines. Since a KLH10 based system is faster than any SC machine (and
much faster than any XKL or DEC machine!), it's possible that they may
have ended up on KLH10.

Pat Farrell

unread,
Jul 1, 2009, 12:21:00 PM7/1/09
to
Mark Crispin wrote:
> A sad day indeed. My main contact with CompuServe was when it was a
> PDP-10 timesharing service bureau (remember those?) in the mid 1970s. I
> will never forget its "funky" variant of TOPS-10.

They had hacks to TOPS-10, for sure, but what was really weird to a
normal 10/20 person was the way they setup their network. It was nearly
all half duplex, line oriented -- a big change from the character
interrupt style of every other PDP-10 on the planet.

They were still a generic PDP-10 timesharing service into 83/84, the
consumer PC stuff was just a way to sell nights and weekend times, when
the big iron was idle since the customers were business. But by that
time, it was clear that the PC stuff was the future, home of all the
revenue growth....

--
Pat Farrell
http://www.pfarrell.com/

Rich Alderson

unread,
Jul 1, 2009, 5:59:59 PM7/1/09
to
Mark Crispin <m...@panda.com> writes:

> On Tue, 30 Jun 2009, Paul Rubin posted:

>> Wow. Were they actually running on real DEC PDP-10 hardware?

> They were in the 1980s. I've been to their Columbus facility. I wrote
> Ampex's memory diagnostic for the KL10, and it was tested at CompuServe.
> It's been nearly 30 years, and I've forgotten most of the details.

> By the 1990s most of their PDP-10s were probably Systems Concepts
> machines. Since a KLH10 based system is faster than any SC machine (and
> much faster than any XKL or DEC machine!), it's possible that they may
> have ended up on KLH10.

It's possible, but they were still using SC boxen just a few years ago.

--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless

Sarr J. Blumson

unread,
Jul 2, 2009, 9:25:44 AM7/2/09
to
Pat Farrell <pfar...@pfarrell.com> wrote:

: Mark Crispin wrote:
: > A sad day indeed. My main contact with CompuServe was when it was a
: > PDP-10 timesharing service bureau (remember those?) in the mid 1970s. I
: > will never forget its "funky" variant of TOPS-10.

: They had hacks to TOPS-10, for sure, but what was really weird to a
: normal 10/20 person was the way they setup their network. It was nearly
: all half duplex, line oriented -- a big change from the character
: interrupt style of every other PDP-10 on the planet.

For a long time we did the same thing at ADP. For a couple of reasons:

IBM 2741s and there clones only worked that way, and

When we started this (1970) the 10 and the PDP-8 the users were actually
connected to were thousands of miles apart and network connections were
slow. The packet that identified the connection was a lot of overhead to
pay for a single character, so we had the 8 do echoing and simple line
editing (when necessary) on it's own and sent the whole line as a single
packet.

--
--------
Sarr Blumson sarr.b...@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/

Rob Warnock

unread,
Jul 2, 2009, 10:22:21 PM7/2/09
to
Sarr J. Blumson <sa...@alum.dartmouth.org> wrote:
+---------------
| Pat Farrell <pfar...@pfarrell.com> wrote:
| : [CompuServe] had hacks to TOPS-10, for sure, but what was really weird to

| : a normal 10/20 person was the way they setup their network. It was nearly
| : all half duplex, line oriented -- a big change from the character
| : interrupt style of every other PDP-10 on the planet.
|
| For a long time we did the same thing at ADP. For a couple of reasons:
|
| IBM 2741s and there clones only worked that way, and
|
| When we started this (1970) the 10 and the PDP-8 the users were actually
| connected to were thousands of miles apart and network connections were
| slow. The packet that identified the connection was a lot of overhead to
| pay for a single character, so we had the 8 do echoing and simple line
| editing (when necessary) on it's own and sent the whole line as a single
| packet.
+---------------

Sometime in the early/mid-1970's we at DCA[1] added "remote echo" to
our terminal network products, but only when the host was a PDP-10
that had our special SCNSER installed[2]. It *exactly* duplicated
the -10's own full-duplex echoing, though to achieve that the remote
had to be very conservative and stop echoing the instant it was unsure
it could match the -10's behavior, e.g., whenever the user typed *any*
control character (especially <CR>, <ESC>, <^C>... and if the user was
running DDT, "/"!), or whenever the host emitted unexpected output.
During such periods we let the host do its normal full-duplex echo
processing. We couldn't go back into remote echoing mode until the
entire round-trip pipeline had been cleared out and the host's TTY DDB
could be proved to be back in "remote echo" state.

So... A couple of years later, Bill Weir (sp?) of Tymshare & I were
having drinks in the conference hotel bar at some DECUS or other
[I forget when/where, precisely... Dallas, maybe?], and we got to
talking about remote terminal echo on our respective networks, even
to the point of drawing little state diagrams on cocktail napkins! ;-}
Turned out that we used *exactly* the same remote echo algorithm
as their Tymnet network, except that they called their little marker
control packets "red balls" & "green balls" while we called ours
"ACKs" & "RACKs" (reverse-ACKs). [ISTR they also had "yellow balls",
used for some other purpose, that we didn't have a direct equivalent
for.] I was initially quite proud of that [Tymshare being *so* much
bigger than DCA!], until I realized that anybody else's implementation
would probably have been isomorphic to the Tymnet/DCA solution(s)
as well. The constraints of the problem practically force such a
convergence.


-Rob

[1] Digital Communications Associates in Atlanta, not the ".gov" one.

[2] Hmmm... Actually, it may have been only our modified DC86A driver,
which reached over into SCNSER's tables and twiddled status bits
to make our ports look like "enhanced" DC76 ports, capable of local
echo and speed change [for auto-baud detection] and other fun stuff.

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Reply all
Reply to author
Forward
0 new messages